Mobile App Design Services
We design apps the way a team that also builds them designs apps. Flows first, then screens, then a prototype you can hold on a phone before anything gets written.
The difference that makes is mostly invisible in a portfolio shot. It shows up in whether the empty states were designed, whether anyone drew the screen with fourteen items in a list rather than three, whether the loading state exists, and whether the design still works when the connection drops. Those are the screens users spend their lives in and the ones most design handovers skip.
We design for both platforms from one system, because that is how we build. One set of components, iOS and Android behaving the way their users expect, and no drift between the two versions.
What We Design
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
Flows before screens
What the user is trying to do, in what order, and what happens when it goes wrong. We map this first because a beautiful screen in the wrong place is a more expensive mistake than an ugly screen in the right one.
-
Interface design, both platforms
One visual system, rendered with each platform’s conventions where users expect them — navigation patterns, gestures, date and time pickers, share sheets, system dialogs. An iPhone user should not be able to tell the app was designed cross-platform.
-
The screens nobody designs
Empty states, loading states, error states, offline states, and lists at the lengths they actually reach. We draw these as part of the work rather than leaving them to be improvised in code, because they are most of what a daily user sees.
-
Design systems for apps
Components, tokens, spacing and type scales, documented so the build matches the design and so the app can keep growing without the design drifting. See design systems.
-
Prototypes on real devices
Clickable prototypes you hold on a phone, not click through on a monitor. Thumb reach, text legibility and gesture conflicts only become obvious at actual size in an actual hand.
-
Store assets and submission readiness
Icon, screenshots, store listing imagery and the platform-specific sizes required for both stores.
-
Accessibility
Contrast, touch target sizing, dynamic type behaviour, screen reader labelling and navigation order, designed against WCAG 2.1 AA. We scope this as real work with real hours against it, because that is what it is.
-
Handover the build team can use
Specs, states, behaviours and edge cases, in a form developers can implement without a week of clarifying questions. We know what that form looks like because we are usually on the receiving end of it.
When Teams
Come to Us
-
A first app, and no design team in house
You have a web product or a business that needs an app, and hiring designers for one project makes no sense. We take it from flows through to store-ready.
-
Design and build from one team
You would rather not manage a handover between a design studio and a development agency. We do both, and the design is written by people who will have to implement it.
-
An app that already ships and looks its age
A redesign on a live product, done without breaking the parts users rely on. Usually incremental rather than a single relaunch.
-
A second app off the back of the first
A spin-off for a different audience sharing a design system and a backend with the original. We have done exactly this: one product line, two apps in the stores, one account.
-
A design that was never finished
Screens exist for the happy path and nothing else. We complete the set — states, edge cases, and the behaviours the build team is currently guessing at.
Send Us the Product
Send us what you have — a live app, a prototype, or a set of screens. We will tell you what we would change and why, before anyone signs anything.
How We Work
Who uses it, what for, and under what conditions. The output is a scope you can price and argue with.
The journeys through the product, agreed before any screen is drawn.
Interface design across both platforms, including the states most handovers leave out.
Clickable, on a real device, reviewed with you before build starts.
Specs, components and behaviours in a form the build team can work from directly.
We stay available through implementation, because designs always meet questions once they become code.
Stack
- Design: Figma, with components and tokens rather than loose frames
- Prototyping: Figma prototypes reviewed on real devices
- Handover: documented components, states and behaviours, mapped to the build
- Build target: React Native, which the design system is structured around
- Accessibility: WCAG 2.1 AA checks on contrast, targets, type and navigation order
Selected Work
- Duo. Consumer app for scheduling dates through professional planners. Live in both stores.
- Therapist and Client Engagement App. Mental health app connecting therapists with their clients, with guided exercises and between-session tracking — a product where tone and clarity in the interface are part of the clinical experience.
- Vision Care Patient Platform. Patient app for managing a course of eye care, with separate patient and practitioner views of the same data. Later extended into a second wellness app sharing the design system and the backend.
Industries We Design For
Healthcare and wellness is where our app design goes deepest. We also design for booking and scheduling platforms, and travel and mobility.
How We
Work Together
-
Design only
A defined design engagement with a handover at the end, for a product you will build elsewhere or in house. -
Design and build
One team from flows through to store. The most common shape, and the one with the least lost in translation. See -
Ongoing design
A designer working to your roadmap alongside your own team. Suits products that keep shipping. -
Design review
A shorter engagement: we review what exists and give you a written assessment of what to change and in what order. SeeA typical app design engagement runs with a designer, with product input from the team who would build it.We price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
One design system, rendered with each platform’s conventions where users expect them. Not two separate designs, and not one design ignoring the differences. Navigation, gestures and system components follow the platform; the product’s own identity stays consistent across both.
-
Yes. The handover is documented for exactly that case. We will ask who is building it and in what, because a design that assumes React Native and lands on a native team creates work for everyone.
-
Yes, in either direction — our designer working alongside yours, or us taking the build and implementing their design. If we think something in their design will be expensive or awkward to build, we will say so early rather than at implementation.
-
We give you a rough estimate as soon as we understand the product. The detailed number comes after the scope is agreed, broken down by module, so you can see what each part of the product costs to design and decide what belongs in version one.
-
Yes. The Figma file, the components, the tokens and the documentation are yours.
-
Research and usability testing are a separate service, and we will tell you when a project needs it rather than assuming. See UX research & audit.