How to Design a Mobile App: The Full Process

Most guides to designing a mobile app stop at “make wireframes, then make it pretty”. That skips the parts that decide whether an app succeeds: who uses it and where, what happens when the network drops, whether someone with low vision can use it, and which App Store and Google Play rules will reject it before anyone sees it. This guide walks through the whole process the way we run it with clients, from the first question to the first release, with the concrete standards at each step. It is written for founders and product owners who are about to commission an app, and for designers who want a checklist that holds up in review.

What “well designed” means for a mobile app

Design is not the visual layer. A well designed app is one where the right person can finish the job they opened it for, quickly, without help, in the conditions they are actually in. Visual polish matters, but it comes last and it cannot rescue a flow that asks for the wrong thing at the wrong moment. Three tests cover most of it:

• Useful: it solves a problem people already have, well enough that they come back.
• Usable: a first time user completes the main task without instructions.
• Fit for its context: it works one handed, in sunlight, on a slow network, with large text turned on, and on the smallest phone you support.

Step 1: Define the problem, the people and the context of use

Before any screen exists, write down answers to these questions. If you cannot answer one, that is the first piece of research to do.

• What job does the app do? One sentence. “Exhibitors scan a visitor's badge and keep the lead” is a job; “an event platform” is not.
• Who does it, and how often? A tool used fifty times a shift is designed differently from an app opened once a month.
• Where and how? Standing or sitting, one hand or two, gloves, noise, glare, connectivity.
• What do they use today? Paper, a spreadsheet, a competitor. Your app has to beat that, not an ideal.
• What does success look like in numbers? Time to complete the task, errors, retention, revenue. Pick the few you will actually measure.

Context changes the design more than any style choice. When we built Leak Survey Sidekick, the users were maintenance crews logging compressed air leaks while moving through a loud, busy plant. That ruled out long forms and small controls and called for a fast, visual logging flow with capture that keeps working without a connection. For GTR Event Technology, the apps ran on trade show floors: thousands of devices in one hall, shared Wi-Fi, concrete and steel. A design that assumed a reliable network would have lost exhibitors' leads.

Methods that work at this stage: short interviews with five to ten real users, watching someone do the job today, reading competitors' store reviews for repeated complaints, and listing the constraints you already know (budget, launch date, regulations such as health or financial data rules). The output is a one or two page product brief that everyone signs off on.

Step 2: Map the flows before you draw screens

A screen is only a stop on a journey, so design the journeys first. Write the main task as a sequence of steps (open app, find provider, pick a time, confirm, get a reminder) and then ask, for each step, what the user needs to see and what they need to decide. Two outputs come out of this:

• User flows for the three to five tasks that matter most, including the branches: not signed in, no results, payment declined.
• Information architecture: what the main sections are and how people move between them.

For navigation, both platforms give clear guidance. Apple's tab bar and Google's Material navigation bar are both meant for a small number of top level destinations, typically three to five. If you need more than five, that is usually a sign the structure needs rethinking rather than a sixth tab. Keep the most frequent action reachable with a thumb: large phones put the top corners out of easy reach for one handed use, which is why primary actions tend to live near the bottom of the screen.

Step 3: Wireframes, fast and ugly on purpose

Wireframes are grey boxes that show what goes where: content, hierarchy and actions, with no colour or brand. Their value is speed. You can draw three alternatives for a checkout in an hour and throw two away, which is impossible once a screen is polished or built. Pen and paper is fine; most teams now work straight in Figma, which also handles the prototype in the next step.

Good wireframes answer, for every screen:

• What is the one thing this screen is for?
• What is the primary action, and is it the most visible element?
• What does the screen look like empty, loading, with an error, and with far more content than expected?
• How does the user get back?

Step 4: A clickable prototype, tested with real users

Link the wireframes (or early visual designs) into a prototype people can tap through on a phone. Then test it with people who match your users, not your own team. Your team knows how the app is meant to work and cannot unsee it.

You do not need a lab. Jakob Nielsen's long standing rule of thumb is that about five participants per round reveal most of the usability problems, and that several small rounds with fixes in between beat one large study. A useful session looks like this:

1. Give a realistic task (“book a session for next Tuesday evening”), not a tour.
2. Ask them to think aloud, and do not help. Where they hesitate is the finding.
3. Record whether they finished, how long it took, and where they went wrong.
4. Fix the worst problems and test again with new people.

This is the cheapest point in the project to be wrong. Changing a screen in a prototype costs minutes; changing it after it is built costs days, and after release it costs a store review cycle and the users who gave up. That is why we put discovery, wireframes and a tested prototype before any production code on every mobile app project.

The most expensive design mistakes are not ugly screens. They are correct looking screens for the wrong task, found after launch.

Step 5: Visual design and a design system

Only now does the interface get its look: colour, type, iconography, imagery and motion. Do it as a small design system rather than screen by screen, so the app stays consistent as it grows and engineers can build it predictably:

• Design tokens: named values for colours, type sizes, spacing, corner radius and elevation, defined once and used everywhere, including dark mode variants.
• Components: buttons, inputs, cards, list rows, sheets and dialogs, each with every state drawn (default, pressed, disabled, focused, error, loading).
• Rules: when to use which component, so the tenth screen does not invent a fourth kind of button.

Respect the platform, then add your brand

iOS and Android users carry different expectations about navigation, back behaviour, typography and system controls. Apple publishes these in its Human Interface Guidelines and Google in Material Design. Both systems moved in 2025: Apple introduced its Liquid Glass design language with iOS 26, and Google released the Material 3 Expressive update. You do not need to copy either system, but where your app departs from platform behaviour it should be for a reason users will feel as a benefit. A shared cross-platform codebase, such as Flutter, makes a single branded design easy; it does not remove the need to handle each platform's back navigation, system dialogs and text scaling.

Plan for dark mode from the start (both platforms have offered a system wide dark theme since iOS 13 and Android 10), and test colours in both themes. Retrofitting dark mode onto a palette designed only for white backgrounds is a common and avoidable rework.

Step 6: Design every state, not just the happy path

Mockups usually show the perfect case: signed in, fast network, ideal content. Real use is mostly the other cases, and they are where users decide an app is broken. Draw each of these deliberately:

• First run and empty states: what someone sees before they have any data, with a clear next step instead of a blank screen.
• Loading: skeleton layouts or progress that shows the shape of what is coming, and no spinner that blocks the whole app for a partial update.
• Errors: plain language that says what happened and what to do, never a raw error code; keep what the user typed.
• Offline and slow networks: decide which actions work offline, queue them, and show clearly what has not synced yet.
• Permissions denied: the app keeps working in a reduced way and explains how to turn the permission on later.
• Extremes: very long names, translated text that runs much longer than the English, huge numbers, one item and a thousand items.

Offline behaviour is a design decision, not only an engineering one. On the GTR apps, testing surfaced a case where data captured without a connection could be lost. We shipped an offline cache within 72 hours: the app saves to the device first and syncs when the network returns, so a scan counts even when the venue's Wi-Fi does not cooperate. The design work is deciding what the user sees while that queue exists, so they trust that nothing was lost.

Accessibility is a requirement, with numbers

An accessible app is easier for everyone: larger targets, readable contrast and clear labels help people in bright sunlight or in a hurry as much as people with a disability. It is also increasingly a legal requirement. The widely used benchmark is the W3C's Web Content Accessibility Guidelines (WCAG), which regulators apply to mobile apps as well as websites. The current version, WCAG 2.2, was published in October 2023.

On the legal side: the European Accessibility Act has applied since 28 June 2025 to a range of consumer services sold in the EU, including e-commerce, banking and passenger transport services, and their apps (the smallest businesses providing services are exempt). In the United States, the Department of Justice adopted WCAG 2.1 AA in April 2024 as the standard for the websites and mobile apps of state and local governments. For private businesses there is no single codified technical standard yet, but WCAG AA is the benchmark that accessibility claims and settlements usually point to. Designing to it from the start costs far less than remediating later.

Store rules and privacy that shape the design

Some design decisions are made for you by Apple and Google, and missing them gets a build rejected in review. The ones that most often affect screens and flows:

• Account deletion: since June 2022, an iOS app that lets people create an account must also let them start deleting it from inside the app. Google Play has a similar requirement and also asks for a web link where people can request deletion without reinstalling the app.
• Third party sign in: if you offer login with a service such as Google, Apple's guideline 4.8 requires an equivalent privacy focused option as well, which in practice usually means Sign in with Apple. There are narrow exceptions, such as business apps that require an existing company account.
• Permissions in context: ask for camera, location or notifications at the moment the feature needs it, with a purpose string that says plainly why. A wall of permission prompts on first launch tends to get declined, and declined prompts are hard to win back: on iOS the app cannot show the system prompt again, and on Android it can ask only once more, so after that people have to find the permission in Settings.
• Tracking: on iOS, tracking users across other companies' apps and websites requires Apple's App Tracking Transparency prompt.
• Privacy disclosures: the App Store privacy labels and Google Play's Data safety section must match what the app really collects, so design and engineering need one agreed list of data.

Sensitive categories raise the bar further. For Zant, a mental health app, privacy was a design requirement from the first screen: what is shown on a lock screen notification, what is asked at sign up, and what is never collected at all.

Handoff and design QA

A design is finished when it is built correctly, not when the mockups are approved. A clean handoff gives engineers:

• The design system (tokens and components) as the source of truth, ideally mirrored one to one in code.
• Every screen with all of its states, plus the flows that connect them.
• Specs for behaviour that static frames cannot show: animations, gestures, what happens on rotation, keyboard behaviour on forms.
• The copy, final or clearly marked as placeholder, in every language you will ship.

Then review the build on real devices, including the smallest and oldest phones you support, with large text on, in dark mode, and on a throttled connection. Design QA catches the gap between what was drawn and what was built while it is still cheap to close.

After launch: measure, then iterate

Release is the first real test with every user at once. Instrument the main flows so you can see where people drop off, read store reviews and support requests for repeated themes, and watch crash reports. Then return to Step 4 with the evidence: prototype the fix, test it with a few users, ship it. Apps that keep improving after launch do so because this loop is planned and budgeted, not improvised.

Common mistakes we see when we take over apps

• Designing screens before agreeing on the job the app does and who does it.
• Testing only with the team, or not testing until after launch.
• Only the happy path is designed, so empty, error and offline states get invented by whoever builds them.
• Touch targets and text that fail the platform minimums, found when the first user with large text turns it on.
• Permission prompts and sign up walls before the user has seen any value.
• No design system, so every new feature drifts further from the last one.
• Store requirements (account deletion, sign in options, privacy labels) discovered at review time.

A checklist before you build

1. A signed off brief: the job, the users, the context and the success numbers.
2. Flows for the main tasks, including the unhappy branches.
3. Wireframes for every screen and every state.
4. A clickable prototype tested with at least one round of real users, and fixed.
5. A design system with tokens, components and light and dark themes.
6. Accessibility checked against the numbers above.
7. Store and privacy requirements reflected in the flows.
8. A handoff package and a plan for design QA on real devices.

If you are planning an app and want this process run for you, from discovery and a tested prototype to a released product, tell us what you are building. You can also see the apps we have designed and shipped, or read Flutter vs React Native if you are choosing how to build it.