How to Design a Mobile App: The Full Process From Idea to a Working App
Eight stages in order, a fork at stage seven, and twelve annotated example screens. For the person who owns the app, whether or not they are a designer.
Designing a mobile app is eight decisions made in order: who it is for, what people do in it, how they move around, what each screen holds, how it looks, whether real people can use it, how it gets built, and whether it is ready for the stores. The seventh changes the other seven. If a developer will build the app, you design for a handoff: specifications, assets and a prototype. If you will build it yourself in a no-code tool, you design inside the tool and there is no handoff at all. This guide covers both paths and marks where they split.
What This Guide Covers
- The two paths side by side: design for handoff, or design and build in one tool
- A drawn user flow and a wireframe of the core screen
- The platform numbers that matter, quoted from Apple, Google and the W3C
- Twelve example screens across four app types, each decision annotated
- What app design costs, with the sources named and dated
- Links to eleven deeper guides, one per design component
This is the process guide and the hub. Colour, type, icons, onboarding and the rest each have their own guide, linked from stage 5; this page gives each one a paragraph and sends you there. The example screens and diagrams were drawn for this guide. They are not client apps and they are not output from any generator, and stage 7b says exactly what we could and could not capture first-hand.
TL;DR Quick Summary
To design a mobile app, work through eight stages in order. 1. Write one sentence saying who the app is for and what it lets them do. 2. Draw the user flows: the core loop, the first run, the edge cases. 3. Choose the navigation, with three to five top-level destinations. 4. Wireframe one screen per flow step in grey boxes and real words. 5. Apply the visual design: colour, type, icon, states, with controls at least 44 points on iOS and 48 dp on Android and text contrast of 4.5 to 1. 6. Prototype it and watch five people use it. Our software prototype guide has a test script you can read out. 7. Either prepare a developer handoff, or build the screens directly in a no-code tool. 8. Run the launch checks: icon, store screenshots, dark appearance, larger text. Decide stage 7 first, because it changes what the other stages need to produce.
Try the AI UI design generator →Table of Contents
The fork first, then the eight stages in order, then the examples and the cost.
- The two paths, up front
- Stage 1: Research and the one-sentence purpose
- Stage 2: User flows
- Stage 3: Structure and navigation
- Stage 4: Wireframes
- Stage 5: Visual design
- Stage 6: Prototype and test with five people
- Stage 7a: design for a developer handoff
- Stage 7b: design and build in the same tool
- Stage 8: launch-readiness design checks
- 12 mobile app design examples, annotated
- What it costs to design a mobile app
- Frequently asked questions
The two paths, up front
Most app design guides end at "hand the file to your developers". That is one path. The other, which is what most people building their first app on a no-code platform actually do, never produces a handoff file. Both are legitimate, and they share the first six stages. What differs is how much of each stage has to be written down.
| Design for handoff | Design and build in one tool | |
|---|---|---|
| Who builds it | A developer or an agency | You, in a no-code builder |
| What design produces | Specs, assets, a prototype, a design system file | The screens themselves, inside the builder |
| Typical tools | Figma, Sketch, Uizard | An app builder with an AI generator |
| Where decisions are recorded | In the file, for someone else to read | In the app, where you can see them run |
| Freedom | Any layout you can draw | What the builder's components allow |
| Right when | Custom product, funded build, a team | First app, standard features, one owner |
Neither path removes a stage. People who build in a no-code tool skip the handoff, not the thinking: an app generated from a prompt without stages 1 to 4 behind it is a set of plausible screens for nobody in particular. If you are still deciding whether the first version should be small, the guide to what an MVP is covers the scoping question; this guide assumes you know what you are building and need to design it.
Stage 1: Research and the one-sentence purpose
Design starts with a sentence, not a screen. Write it in this form: this app lets [who] do [what] without [the thing they put up with today]. For the example used through this guide: "this app lets regulars at a coffee shop collect stamps and claim a free coffee without carrying a paper card". Every later decision gets tested against it.
- Who: one person you can describe, not a segment. "Ana, who buys a flat white on the way to work four days a week" settles arguments that "urban coffee drinkers aged 25 to 40" cannot.
- The job: what they are trying to get done when they open the app, in their words. Collecting a stamp takes ten seconds at a till with a queue behind. That one fact shapes the home screen more than any style choice.
- Three competitors: install three apps that do a similar job and use each for a real task. Write down what took more than three taps, what you had to read twice and what you could not find. Describe what you see in words; do not copy their screens.
- The success measure: one number the design is supposed to move. For the loyalty app it is the share of visits where a stamp gets collected. A design that looks better and lowers that number is a worse design.
Keep the output to one page. If the purpose sentence needs an "and", there are two apps in it, and the second one is the first thing to cut.
Stage 2: User flows
A user flow is the sequence of screens someone passes through to get one thing done. Draw three kinds, in this order of importance, as boxes and arrows on paper.
- The core loop: what a returning user does every time. It should be short enough to count on one hand. In the example it is four steps, and the second, showing the code, is one tap from the home screen.
- The first run: what a new user sees before they have any data or any account. The most common mistake is a sign-up wall before the app has shown what it does. In the example the first stamp works without an account, and sign-in is asked for only when there is something worth saving.
- The edge flows: no signal, an empty list, a full card, the wrong location. These are where apps feel broken, and they are cheap to design now and expensive to discover after launch.
From the flows, mark the three screens that carry the app. Those get designed first, tested first and polished most. Everything else (settings, profile, about) can be plain.
Stage 3: Structure and navigation
Navigation is the decision about what is always one tap away. On a phone there are three common structures, and the platforms' own guidance is clear about which to prefer.
| Structure | Use it when | What the platforms say |
|---|---|---|
| Tab bar (bottom) | Three to five sections of equal weight | Material 3: navigation bars hold "three to five destinations". Apple: "it's generally easier to navigate among fewer tabs". |
| Drawer (side menu) | Many sections, used unevenly | Hides everything behind one icon, so nothing in it gets discovered by accident. |
| Stack (list to detail) | One main list that people drill into | Works inside a tab; on its own it suits single-purpose apps. |
Sources: Google, Material 3 navigation bar guidelines; Apple, Human Interface Guidelines, tab bars. Both read 28 September 2026.
The rule that follows: if the app has more than five top-level sections, the answer is fewer sections, not a sixth tab. Apple's guidance warns against overflow, where extra tabs collapse into a "More" item that people rarely open. Give every tab a text label as well as an icon; icons alone get guessed at. The guide to app navigation patterns goes through each structure with its trade-offs; this stage is only the choice.
Stage 4: Wireframes
A wireframe is a screen drawn in grey boxes with real words and no styling. Draw one per step of each flow, starting with the three core screens. Paper is fine. The point is to settle what is on each screen, in what order and at what size, while changing your mind still costs nothing.
- One primary action per screen. If two buttons look equally important, the screen has not decided what it is for.
- Real words, never placeholder text. "4 more for a free coffee" tells you how wide the card has to be. Placeholder text tells you nothing, and the layout breaks the day real copy arrives.
- Area follows importance. The thing the app is for gets the most space and sits where the thumb reaches without stretching.
- Draw the empty and the full version. A list with no items and a list with two hundred are different screens.
If you need to show a client or a partner something that looks finished before the design is, that is a mockup rather than a wireframe, and the AI mockup generator is the quicker route to one. The difference between wireframe, mockup and prototype, and how far to take each, is covered in the app wireframing guide.
Stage 5: Visual design
Visual design is where most guides start and where this one spends the least time, because each part has its own guide. What belongs here is the order, and the platform numbers that are not a matter of taste.
The numbers that are not optional
| Rule | iOS | Android | Source |
|---|---|---|---|
| Tap target size | 44 x 44 points by default, 28 x 28 minimum | At least 48 x 48 dp, about 9 mm | Apple HIG; Android Accessibility Help |
| Text contrast | 4.5 to 1 up to 17 pt; 3 to 1 at 18 pt or bold | 4.5 to 1 for normal text; 3 to 1 for large text | Apple HIG; WCAG 2.2, criterion 1.4.3 |
| Larger text | Let people enlarge text by at least 200 percent | Test at the largest system font size | Apple HIG |
| Top-level destinations | Fewer is easier; avoid an overflow tab | Three to five | Apple HIG; Material 3 |
Sources: Apple, Human Interface Guidelines, accessibility; Google, Android Accessibility Help, touch target size; W3C, Understanding success criterion 1.4.3. All read 28 September 2026.
The components, in the order to decide them
- Colour. One neutral, one brand colour, one accent kept for the primary action, each pair checked for contrast. Mobile app colour schemes has palettes and the checks.
- Type. One typeface, a scale of four or five sizes, body text no smaller than the platform default. The app typography guide covers scales and system fonts.
- Onboarding. The shortest route to the first useful moment; three screens of explanation is usually three too many. See app onboarding best practices.
- Empty states. What a screen says when there is nothing in it yet, and the one action that fills it. See the guide to app empty states.
- Loading states. Skeletons, spinners and what to show while the app waits. See loading states in mobile apps.
- Motion. Animation that explains where something went, and nothing that only decorates. See the mobile app animation guide.
- Accessibility. Screen reader labels, contrast, target sizes and text scaling, designed in rather than audited later. See mobile app accessibility.
- Splash screen. What shows for the second the app takes to open. See app splash screen best practices.
- App icon. The one piece of design every user sees before anything else. See the app icon design guide.
Follow the platform where you can. An iPhone user expects iOS conventions and an Android user expects Material ones, and an app that ignores both has to teach its own. If you would rather start from a generated draft than a blank screen, the AI design assistant is the prompt-based route; bring the decisions above to it, because a generator will pick a palette for you if you have not.
Stage 6: Prototype and test with five people
A prototype is the designed screens linked together so that tapping a button goes somewhere. It does not need real data. It needs to be real enough that someone can try the core loop without you explaining it.
Then watch five people use it. The number is not arbitrary: in Jakob Nielsen's widely cited research, a first study with five participants found 85 percent of the usability problems, and his advice is to spend a testing budget on three small studies rather than one large one, fixing the design between rounds. The exception he names is an app with several highly distinct groups of users, which needs a few people from each.
Source: Jakob Nielsen, Nielsen Norman Group, Why You Only Need to Test with 5 Users, 18 March 2000. Read 28 September 2026.
- Who to test with: people like the person in your purpose sentence. Not colleagues, and not anyone who has seen the wireframes.
- What to ask: give a task, not a tour. "You have just bought a coffee. Get your stamp." Then stay quiet.
- The two questions afterwards: "what did you expect to happen when you tapped that?" and "what would you do next?". Opinions about colour are not findings.
- What counts as a problem: anything two of the five hesitated on. Fix those, then test the fixed version with five new people.
On the handoff path the prototype is built in the design tool. On the single-tool path the first build of the app is the prototype, which is one of the reasons that path is quicker. The AI prototype builder is the route if you want something clickable from a description before either.
Stage 7a: design for a developer handoff
If a developer or an agency will build the app, the design has to survive being read by someone who was not in the room. The handoff is five things.
- Specifications: sizes, spacing and colours for every screen. Modern design tools generate these from the file; your job is to make sure the file is tidy enough that the numbers are consistent.
- Assets at each density: Apple asks for bitmap images at @2x and @3x for iOS. Android sorts resources into density buckets from mdpi, the 160 dpi baseline, to xxxhdpi at about 640 dpi; a launcher icon is 48 x 48 pixels at the baseline and 192 x 192 at the top. Use vector formats wherever the platform accepts them and the question mostly disappears.
- Naming: one convention, applied everywhere. A developer searching for "button-primary-pressed" should find exactly one thing.
- A clickable prototype: the one from stage 6, updated. It answers the questions a static screen cannot, such as what happens after a tap.
- The design system file: colours, type scale, components and their states, in one place. It is what keeps screen forty consistent with screen one.
Sources: Apple, Human Interface Guidelines, images; Google, Support different pixel densities. Both read 28 September 2026.
Figma is the most common handoff format, Sketch is the long-standing Mac alternative, and Uizard is aimed at people who are not designers. Which to use is the developer's preference as much as yours, so ask before you start. If the design already exists in Figma and you would rather not pay for a custom build, the Figma to app converter is the bridge between the two paths.
Stage 7b: design and build in the same tool
On this path there is no file to hand over. You describe the app, the tool generates the screens, and you correct them against the decisions from stages 1 to 6. We ran the first step on Appy Pie AI's AI UI design generator on 28 September 2026, with a brief written from the wireframe in stage 4.
What the generator is, and what we could capture
Two things are worth knowing before you use it. First, the generator sends your brief to the same build service as the app builder. What comes back is a generated app whose screens you then edit in the builder, not a canvas of static frames to export. That is the point of the single-tool path, and it is also why the brief should describe an app rather than a picture. Second, on the account we used, which has no plan, the build stopped at the plan screen: the app appeared in the app list with its dashboard, and the editor and phone preview were not open to it. We showed those screens, captured the same way, in the guide to building an app with AI.
What to check in the generated screens
Whatever tool generates the first draft, the review is the same, and it is where the earlier stages pay for themselves. Go through the draft with the wireframes beside you.
- Is the primary action the most prominent thing on each core screen? Generators favour balance. Your wireframe said one thing matters most.
- Are the tabs the ones you chose in stage 3? Expect a generic set. Rename, reorder and remove until it matches.
- Are the words real? Replace every generated label with the copy from your wireframes.
- Does the palette pass contrast? Check the text and button colours against 4.5 to 1 yourself; do not assume.
- What happens when a screen is empty? Open each list with nothing in it. If it is blank, that is a state to design.
- Does it work on a small phone at the largest text size? Test on a real device, not only the preview.
Then repeat stage 6 on the built app. The advantage of this path is that the thing people test is the thing that ships.
Stage 8: launch-readiness design checks
The last stage is the design work that only exists because of the stores and the devices. None of it is difficult. All of it is easier before submission than after a rejection.
| Check | App Store (iOS) | Google Play |
|---|---|---|
| App icon | 1024 x 1024 px, square, layered; the system applies the rounded mask | 512 x 512 px, 32-bit PNG, up to 1024 KB |
| Store screenshots | 6.9 inch set, for example 1290 x 2796 px; Apple scales it for smaller displays | Up to 8 per device type |
| Store graphic | None required | Feature graphic, 1024 x 500 px, required to publish |
| Dark appearance | Check contrast in both light and dark | Check contrast in both themes |
| Larger text | Enlarge to 200 percent and check nothing is cut off | Set the largest font size and check the same |
Sources: Apple, Human Interface Guidelines, app icons and dark mode, and App Store Connect screenshot specifications; Google, Play Console preview assets. All read 28 September 2026.
- Do not add your own light and dark switch. Apple's guidance is to follow the system setting, because a separate in-app setting makes people adjust two things to get one result.
- Screenshots are design, not documentation. The first two decide whether the listing gets read. Show the core screen doing its job.
- Run the accessibility pass on a device. Turn on the screen reader and complete the core loop with the screen off. Every unlabelled button shows up within a minute.
- Check text expansion. If the app will be translated, German and French run longer than English. Buttons sized to the English word break first.
Where each asset is uploaded is covered in the App Store submission guide, and the order of everything else in launch week is in the app launch checklist.
12 mobile app design examples, annotated
Most people who search for mobile app design want to see some. Here are twelve screens from four kinds of app, each with the three design decisions that matter on it. They were drawn for this guide in plain HTML and CSS, so every decision in them was made on purpose and can be explained. The numbers on each screen match the numbers in the notes below it.
1. A coffee loyalty app
A. Home
1. One filled button, and it is the thing people came to do. 2. Progress is shown as ten cups, not as 60 percent; people count objects faster than they read numbers. 3. Four tabs, each with a label.
B. Menu
1. Category chips filter in place, so there is no second screen to come back from. 2. Every row is 56 points tall and the whole row is the tap target. 3. Prices are right-aligned in figures of equal width, so the column can be scanned.
C. Code
1. The code gets the whole width and the screen brightness is raised, because a scanner has to read it. 2. The confirmation says what happened in words, colour and an icon, never colour alone. 3. One quiet way out.
2. A salon booking app
A. Service list
1. The selected service changes border and fill, so the choice is visible without reading. 2. Duration sits with the name, because length decides a booking as often as price does. 3. The button names the next step, not "Continue".
B. Time picker
1. Five days on one row; most bookings are for this week. 2. Taken slots stay visible and struck out, which tells people the day is busy rather than the app broken. 3. The button repeats the choice back before it is made.
C. Confirmation
1. Success is unmistakable from across the room. 2. The summary answers the four questions people check: what, when, who, how much. 3. Changing or cancelling is offered here, quietly, so nobody has to hunt for it later.
Booking flows have more patterns than three screens can show; the guide to booking app UX patterns covers deposits, reschedules and no-shows.
3. A grocery store app
A. Product grid
1. Categories scroll sideways and the cut-off chip shows there are more. 2. Two columns keep pictures large enough to recognise. 3. Adding to the basket happens on the grid; opening a product is optional.
B. Product detail
1. The picture leads, because food is chosen by eye. 2. The quantity stepper has targets of 44 points or more, side by side with space between. 3. The button states the quantity and the total, so the tap holds no surprise.
C. Basket
1. Each line shows the picture again; people check a basket by recognition. 2. Delivery is shown before checkout, not after. 3. The button carries the final amount.
4. A running club app
A. Home
1. The next run is the largest thing on the screen and both answers are one tap. 2. Later runs are plain rows; they matter less today. 3. Four labelled tabs, the same on every top-level screen.
B. Empty state
1. A picture of what belongs here. 2. One sentence that says why it is empty and when that changes. 3. One button that fixes it. An empty screen is an invitation, not an error.
C. Dark appearance
1. Surfaces are dark grey rather than black, and text is off-white, which keeps contrast without glare. 2. The accent is lightened so it still passes 4.5 to 1. 3. The app follows the phone's setting and says so.
What the four have in common is what modern mobile app design comes down to in 2026: one primary action per screen, large tap targets, labelled navigation, states designed rather than left blank, and a dark appearance that was checked rather than inverted. None of it depends on a trend.
What it costs to design a mobile app
Design is priced by the hour or by the project, and the honest answer is a range. There is no independent survey of app design prices that we could find; the figures below come from two guides published this year by companies that sell design or software, which is worth bearing in mind when you read them. They agree closely enough to be useful.
| What you are buying | Parallel (2 July 2026) | Jotform (21 July 2026) |
|---|---|---|
| Simple app or MVP | $5,000 to $15,000 | $3,000 to $15,000, 5 to 15 screens, 2 to 4 weeks |
| Mid-complexity app | $15,000 to $50,000 | $15,000 to $40,000, 15 to 40 screens, 4 to 8 weeks |
| Complex platform | $50,000 to $150,000 or more | $50,000 to $150,000 or more, 3 to 6 months |
| Freelancer, per hour | $50 to $150 | $80 to $150 in North America and Western Europe; $15 to $40 in South Asia |
| Agency, per hour | $150 to $250; senior studios $200 to $350 | Projects run 20 to 40 percent above a freelancer |
Sources: Parallel, App Design Cost: 2026 Benchmarks; Jotform, How much does it cost to design an app in 2026?. Both are vendor estimates, not surveys. Read 28 September 2026.
The single-tool route
On the single-tool path design is not a separate purchase; it is part of the builder. Typing a brief into the generator is free. Appy Pie AI's pricing page offers a seven-day trial for personal, non-commercial use, and plans start at $16 per app per month billed yearly, or $32 billed monthly, for an Android app, with the plan that supports iOS at $60 per app per month billed yearly. Store fees are separate, and the pricing page says so. Read from the US pricing page on 28 September 2026; prices are shown in local currency elsewhere.
The hidden cost: designing twice
The expensive mistake is not a high hourly rate. It is paying for a full handoff, with a design system and exported assets, for an app that then gets built in a no-code tool where none of it can be imported. The screens are made again inside the builder and the file is never opened. If the single-tool path is where the app is going, stop the paid design work at stage 4: wireframes and a palette are everything the next step can use.
Frequently Asked Questions
How can I design a mobile app?
Work through eight stages in order: write the purpose in one sentence, draw the user flows, choose the navigation, wireframe each screen, apply the visual design, prototype and test with five people, then either prepare a developer handoff or build the screens in a no-code tool, and finish with the launch checks. Decide how the app will be built before you start, because it changes what each stage has to produce.
How much does it cost to design a mobile app?
Two vendor guides published in July 2026 put a simple app at roughly $3,000 to $15,000 and a mid-complexity app at $15,000 to $50,000, with freelancers at about $50 to $150 an hour and agencies at $150 to $250. Those are estimates, not survey data. If you build in a no-code tool, design is part of the builder's plan rather than a separate cost.
How do I create my own mobile app?
Design is one part of it. Creating the app also means choosing how it is built, building it, testing it on real phones and publishing it to the stores. Our ten-step guide to creating an app covers the whole route; this page covers the design stages within it.
What is the best app for designing mobile apps?
It depends on who builds the app afterwards. For a developer handoff, Figma is the most widely used, Sketch is the Mac alternative and Uizard is aimed at non-designers. If you will build the app yourself, a no-code builder with an AI generator, such as Appy Pie AI's AI UI design generator, lets you design and build in one place. Our comparison of AI UI design generators covers the tools in more detail.
Should I design for iOS or Android first?
Design for the phone most of your users carry. If you do not know, design the flows and wireframes once, since they are the same on both, and apply each platform's conventions at the visual stage: tab bars and 44-point targets on iOS, navigation bars and 48 dp targets on Android. A no-code builder produces both from one design.
Do I need Figma to design an app?
No. Figma is the standard when a developer will build from your file. Flows and wireframes can be done on paper, and if you are building in a no-code tool the design happens in the builder. What you cannot skip is the thinking in the first four stages, whichever tool you use.
How long does app design take?
For a first app of about ten screens done by its owner, the stages in this guide add up to roughly eight to ten working days. Agency timelines are longer: one 2026 vendor guide puts a simple app at two to four weeks and a mid-complexity app at four to eight. Testing with real people is the stage most often cut, and the one that saves the most time later.
Can AI design an app?
AI can produce a first draft of the screens from a written brief in minutes, and the draft is usually competent and generic. It cannot decide who the app is for, which action matters most on each screen or what your users found confusing. Use it to skip the blank page, then correct the draft against your own wireframes and test it with people.
Have the Wireframes? Turn Them Into Screens.
Write the brief from your wireframes, naming each screen and its one primary action, and let the AI UI design generator draft the app. The decisions are yours; the first draft does not have to be.
Try the AI UI design generatorCompare AI UI design toolsDesign Is the Decisions. The Tool Comes Last.
Eight stages, one fork. Decide who builds the app, then write the purpose, draw the flows, choose the navigation, wireframe, design, test with five people, build or hand off, and run the launch checks. If the app is still an idea, the ten-step guide to creating an app puts design in its place among the other nine steps. If the wireframes are done, the next step is a draft you can tap.
Try the AI UI design generator →
Aasif Khan
Head of SEO and Growth Marketing Lead at Appy Pie AI with 17+ years in digital marketing and scalable growth strategies.
Abhinav Girdhar
Founder and CEO of Appy Pie AI, one of the largest no-code and AI app platforms, with 10M+ apps and websites created.