Mobile App Design Process: UI/UX From Wireframe to Handoff

The mobile app design process runs in five stages: discovery, wireframes, a clickable prototype, visual design and developer handoff. Design typically takes 20–25% of the total app budget and 2 to 8 weeks, depending on how many screens and user roles your app has.

Users give your app very little time to prove itself. According to AppsFlyer data compiled by Business of Apps, the average iOS app keeps 25.4% of its users on day one and just 5.3% by day 30. On Android the figures drop to 20.2% and 3.8%. Most of the ad budget you spend per install goes to people you lose within their first few sessions.

Design doesn't cause all of that loss. But the confusion a user feels in the first session is a problem you solve at the design table. Which screen opens first, how many fields the sign-up form asks for, whether the main button sits where a thumb can reach it: you settle these questions during design, not during coding.

We wrote this guide for business owners and founders who plan to commission an app. You don't need to be a designer. For each step, you'll learn what you approve, which deliverable you should receive, and where the money goes.

What's in this guide

• What does mobile app design actually cover?
• Why design comes before code
• Step 1: Discovery and user flows
• Step 2: Wireframes set the skeleton
• Step 3: Clickable prototype and user testing
• Step 4: Visual design and the design system
• Step 5: Developer handoff
• iOS vs Android: design differences that matter
• How much of your budget goes to mobile app design?
• How Figma keeps the process transparent for you
• AI and mobile app design: where it helps and where it fails
• 7 common mistakes in the design phase
• Frequently Asked Questions

What does mobile app design actually cover?

Mobile app design has two layers. The UX (user experience) layer deals with how many steps a task takes and how little effort it demands. The UI (user interface) layer builds the visible surface: color, typography, icons and spacing. We covered the difference, and what it returns to a business, in our UX design guide. This article focuses on how the process runs in a mobile project.

A complete mobile app design engagement produces these deliverables:

• User flows: Step-by-step maps of critical tasks such as sign-up, search and checkout.
• Wireframe set: The colorless skeleton of every screen.
• Clickable prototype: A code-free mock-up of the app that you explore on your own phone.
• Visual design: Final screens that carry your brand, in light and dark themes.
• Design system: A library of repeating components such as buttons, form fields and cards.
• Handoff package: An organized source file where developers pull measurements, color codes and assets.

Logo and brand identity sit outside this scope; the designer adapts your existing identity to the app. Writing code sits outside it too, although a clean design file speeds up development directly.

Mobile app design also isn't a shrunken copy of web design. The screen is narrow. People use it one-handed while walking. The connection drops and a phone call interrupts the flow. System dialogs for camera, location and push permission become part of the journey. iOS and Android each impose their own habits. Every one of these conditions calls for a separate decision during design.

Why design comes before code

The first reason is cost. Moving a button in Figma takes a designer a few hours. Making the same change on a screen that developers have coded, wired to the backend and tested means developer time, QA time and a new store release. Making decisions while they're cheap is the simplest saving in the whole project.

The second reason is scope clarity. A written feature list creates a different app in everyone's head. Once you see screens, questions like "what happens after I add to cart?" surface on their own. Quotes for a project with a fixed screen list also land closer together, because every vendor prices the same thing. Our app development cost guide breaks down the other line items.

The third reason is user loss. AppsFlyer's 2025 app uninstall report shows that in 2024 an average of 46.1% of installed Android apps disappeared from phones within 30 days. Most uninstalls happen on day one, and the report points to unmet expectations as the leading cause. That first-day experience comes down to onboarding, sign-up and home screen design.

Three design decisions shape the first session. The first is sign-up timing: showing a registration form before users have explored the app asks for effort before they've seen value. Guest mode or deferred sign-up reduces that friction. The second is what the first screen shows: people should see the task they came to do, not a promotional banner.

The third is empty screens. A new user has no orders, bookings or favorites, so they see more empty screens than anyone else. Replace "Nothing here yet" with a prompt that shows the first step. None of these decisions needs code; you settle them all in the design file. Discover them after coding and each one becomes its own development task.

The fourth reason is store approval. The design section of Apple's App Store Review Guidelines requires an app to go beyond "a repackaged website." Apps that miss this bar face rejection. We collected the other frequent causes in our article on App Store rejection reasons.

Step 1: Discovery and user flows

A good designer doesn't draw screens in week one; they ask questions. Whose problem does the app solve? How do people handle that task today? Where do competing apps make them struggle? The answers steer the four steps that follow.

Let's carry one example through this guide: a gym chain with three locations commissions an app for its members. Discovery interviews surface three critical tasks: booking a group class, entering the gym with a QR code and renewing a membership. Today members phone the front desk to book; when the line is busy, they give up.

This stage produces four outputs:

• User flows: A step diagram from start to finish for each critical task. The "book a class" flow starts with opening the app and ends on a confirmation screen; the target is three taps at most.
• Screen list: An inventory of every screen the flows require. In our example the list comes to 22 screens.
• Navigation decision: Do the main sections live in a bottom tab bar, and how many tabs does it hold?
• Priority ranking: Which features ship in the first release and which ones wait for later phases.

The priority ranking affects your budget more than any other decision. Ideas like a nutrition planner or an in-app shop look tempting, but doing three critical tasks flawlessly in version one carries more value. Our MVP guide explains how to narrow the scope.

Your job at this step is to approve the screen list and the priorities. You can add a screen later, but every addition extends both design and development time. Read the list with your team, walking through a real working day.

Step 2: Wireframes set the skeleton

A wireframe is the skeleton of a screen, drawn with gray boxes and plain text. It carries no color, photos or brand elements. That absence is deliberate: show someone a colorful screen and their attention slides to the shade of the button, while the real question, "does this button belong here?", slips past.

At the wireframe stage, each screen answers these questions:

• Which information appears on the screen, and what sits at the top?
• Does the screen have one primary action? Does "Book" lead, or "Add to calendar"?
• Where does the user arrive from, and where do they go next?
• What does the screen show when the list is empty, the connection drops or an error occurs?

Ask for real content when you review wireframes. A screen filled with "lorem ipsum" always looks tidy. Real content breaks things early: a class called "Adult Reformer Pilates (Intermediate Level)" tests the limits of a card layout on day one. If your app ships in several languages, test the longest one. German and Turkish strings run far longer than English; "Book" becomes "Rezervasyonu Onayla" in Turkish.

This step is the cheapest moment to ask for changes. Moving a box takes minutes. Raise every flow that feels wrong now. Saying "I'll decide when I see it in color" postpones the decision to an expensive stage.

You receive wireframes for every screen on the list, plus a flow map that shows how they connect. Spotting a missing screen is easy here: look for a drawing next to each row of the list.

Step 3: Clickable prototype and user testing

The designer links the approved wireframes into a clickable prototype that you open on your phone. You tap a button and the next screen appears. It contains no code, yet the experience feels very close to the real app.

The real value of a prototype is the chance to test with actual users. Nielsen Norman Group's classic research shows that a test with five users uncovers roughly 85% of usability problems. The same research advises splitting your budget into three small rounds of five people instead of one large study: test, fix, test again.

In the gym example the test works like this: you invite five members one at a time, hand over the phone and state a task. "Book tomorrow's 7 pm pilates class." You don't help; you only watch. You look for three things:

• Did the person complete the task, and in how many taps?
• Where did they hesitate, and which wrong button did they tap?
• Which word confused them? Do they say "session" or "class"?

If three out of five people hunt for the class schedule, the problem lies in your navigation, not in your users. Fixing that finding in a prototype takes a day.

A prototype opens other doors too. When you pitch to investors or a board, a working mock-up persuades better than a fifty-page document. The development team also sees exactly what it will build and sharpens its estimate. QA and beta testing after the code exists is a separate job, which we cover in our mobile app testing guide.

Step 4: Visual design and the design system

Once the skeleton holds, the designer dresses the screens in your brand: color palette, typeface, icon family, spacing, photography and illustration style. You first see a direction study on two or three key screens. After you approve the direction, the designer rolls the same language out to every screen.

Professional teams don't paint screens one by one; they build a design system first. The designer creates components such as buttons, form fields, cards and alerts once, then reuses them on every screen. Colors and sizes connect to variables called design tokens. When your brand color changes, updating a single value updates every screen.

One experiment measured the speed effect of this approach. A study by Figma's data team found that designers with access to a design system completed the same task 34% faster. The researchers note that the system matched the task perfectly, so you should treat the figure as an upper bound.

Readability counts as much as beauty in visual design:

• Touch targets: Apple recommends 44x44 pt for iOS controls, and Google recommends at least 48x48 dp on Android. Smaller buttons produce wrong taps.
• Contrast: Gray text on a light gray background looks elegant and becomes unreadable in sunlight. WCAG asks for a 4.5:1 contrast ratio for normal text. Our web accessibility guide covers the legal side.
• Text size: People enlarge text in their system settings. Your layout has to survive larger type.
• Dark theme: Adding it later is hard; set up your color variables for two themes from the start.

Localization details belong to this step as well. Turkish has a dotted capital İ, so an app that uppercases text with the wrong locale prints "GIRIŞ" instead of "GİRİŞ". Price and date formats change by market: 1,250.00 in one country reads 1.250,00 in another. Consent screens under GDPR, Turkey's KVKK or Apple's tracking prompt also deserve a designed place in the sign-up flow, not a last-minute pop-up.

Step 5: Developer handoff

The bridge between design and software collapses here more than anywhere else. If the designer delivers only the "happy path" screens, developers fill the gaps with their own guesses. The app that comes out doesn't match the design you approved.

A complete handoff package contains:

• All screen states: Loading, empty list, error, success and offline views.
• Component rules: Disabled, pressed and loading states for buttons; the error state for form fields.
• Design token list: Variables for color, type size, spacing and corner radius.
• Assets: Icons in vector format, photos exported for different screen densities.
• Copy document: Every piece of on-screen text, error message and push message.
• Animation notes: Duration and direction of transitions.
• Edge cases: A 40-character name, a small-screen phone, enlarged system text.

Figma makes this work easier with Dev Mode. When a developer selects an element, they see its measurements, spacing and linked variables. According to Figma's Dev Mode guide, the tool also generates code snippets for platforms such as SwiftUI and Jetpack Compose. Those snippets aren't finished code; they give the developer accurate values to start from.

Handoff doesn't end when the file lands in an inbox. In a healthy process the designer and developer walk through the screens together and discuss what costs the most to build. As development moves forward, the designer places the working build next to the design and lists the differences. We call this check design QA, and it belongs to the pre-release quality round. When you collect quotes, ask whether the price includes it.

iOS vs Android: design differences that matter

Users of the two platforms arrive with different habits. Apple's Human Interface Guidelines (HIG) and Google's Material Design 3 define those habits. Both sides refreshed their visual language in 2025: Apple introduced Liquid Glass with iOS 26, and Google announced Material 3 Expressive.

These differences don't mean you need two separate designs. In projects built with Flutter or React Native you set up one design language, then adapt details such as back behavior, date pickers and permission dialogs to each platform. Your brand stays consistent and people keep the habits of their own phone. If you haven't picked a starting platform yet, read our guide on launching on Android or iOS first.

One fact holds on every platform: the thumb. Steven Hoober's field study, based on 1,333 observations, found that 49% of people touching their screen held the phone in one hand. Another 36% cradled it in one hand and tapped with the other, and 15% used two thumbs. Screens have grown since then, and the top corners have become harder to reach. Place frequent actions in the lower half of the screen, and move hard-to-undo actions such as delete out of the thumb's easy range.

How much of your budget goes to mobile app design?

According to Business of Apps' cost research, the design stage accounts for an average of 20–25% of a mobile app budget. The same compilation assigns 10–15% to discovery, 40–55% to development, 15–20% to testing and 5–10% to deployment. Clutch survey data cited in that research groups design-stage spend into brackets that run from $5,000–$10,000 at the low end to $50,000+ at the top.

If you work with a team in Turkey, the same share applies to a smaller base. Applying 20–25% to the 2026 price bands from our Turkey cost guide gives this planning table:

Treat these amounts as a proportional calculation, not a market survey; use them as a reference point when you read a quote. We derived the timelines the same way, by applying the share to total project schedules. For a quick estimate of your own scope, try our app cost calculator.

Several factors push the mobile app design line item up:

• Number of unique screens: A 20-screen app and a 60-screen app don't take the same design effort.
• Number of user roles: Separate interfaces for customer, courier and admin come close to designing three apps.
• Custom illustration and animation: Brand-specific artwork and micro-interactions demand serious labor.
• Research depth: Field interviews and multiple test rounds extend the timeline but lower your risk.
• Platform-specific design: Asking for fully separate iOS and Android interfaces nearly doubles the effort.

The right way to save money is to narrow the scope, not to skip design. Starting from a ready-made component kit, limiting version one to three to five critical flows and leaving illustrations for phase two all ease the budget. "The developer will handle the design" looks cheap in the short run; you pay for it with rewritten screens and lost users.

How Figma keeps the process transparent for you

The debate over design tools has largely ended. In the 2024 Design Tools Survey by UX Tools, which polled 2,220 professionals, 82.3% named Figma as their primary interface design tool. Market share matters less to you than how visible the tool makes the process.

Figma runs in the browser. Open the link your designer sends and you see the current state of the file without installing anything. The answer to "where do the designs stand?" stops being a PDF attachment and becomes a window that stays open.

That transparency gives you four concrete advantages:

• Comments on the screen: Click the button you dislike and leave your note on that exact spot. Descriptions like "the blue thing on page three" disappear.
• Prototype on your phone: With Figma's mobile app you open the prototype on your own device and try it at real size.
• Version history: You can return to the design you approved last week and compare the difference.
• Single source of truth: Developers work from the same file, so nobody asks which version was current.

Transparency only works if your feedback arrives in an orderly way. Collect your team's opinions through one person and send comments in planned rounds. Conflicting notes from five people on five different days will stall even the best mobile app design process.

A healthy rhythm has the designer give a short weekly walkthrough: screens finished that week, open questions and the plan for next week. You add your comments to the file before the next session. That rhythm removes the "three weeks of silence, then forty screens at once" surprise. Ask about review frequency and the number of revision rounds at the proposal stage; both belong in the contract.

Finally, ownership. When the project ends, ask for the Figma files to move to your own account, and write that into the contract. The source file lets you keep improving your app even if you work with a different team later. A business that receives only PNG or PDF exports pays to redraw the design at its first major revision.

AI and mobile app design: where it helps and where it fails

Search suggestions for "mobile app ui ux design ai" sit near the top of Google's autocomplete list. The curiosity makes sense: text-to-screen tools produce tidy-looking interfaces in a few minutes.

Professionals report a more cautious picture. In Figma's 2025 AI report, a survey of 2,500 designers and developers, 59% of developers said they use AI for core work, against 31% of designers. Some 78% agreed that AI makes their work more efficient, yet only 32% said they can rely on its output.

AI genuinely saves time on these jobs:

• Producing alternative layouts during the first round of ideas.
• Writing realistic sample copy and content for wireframes.
• Preparing placeholder images and icon drafts.
• Summarizing user test notes and pulling out common themes.

These jobs still need human judgment:

• Flow logic specific to your business. A tool doesn't know whether a member with a frozen membership may book a class.
• Consistency across hundreds of screens and design system discipline.
• Platform rules, touch targets and access criteria such as contrast.
• Empty, error and offline screen states. Generated screens almost always show the happy path.
• The distinctive visual language that separates your brand from a competitor.

General-purpose tools such as Canva can produce presentation-grade screen images too. A real project that needs a component library, variables and developer handoff calls for product design tools. We compared the limits of building apps with AI tools in our article on AI app builders vs a development agency.

7 common mistakes in the design phase

Most mobile app design problems trace back to a handful of avoidable decisions:

1. Skipping wireframes and starting with colorful screens. The discussion drifts to color, and flow problems travel into the coding stage.
2. Designing only the happy path. A design without empty, error and offline states is half a design.
3. Shrinking your website and calling it an app. An app that offers nothing beyond the site earns a place neither in store review nor on a phone.
4. Asking for permissions on first launch. Push and location prompts that appear before people see the benefit mostly collect a "Don't Allow." Ask at the moment you explain the value; our push notification strategy guide explains how.
5. Never testing with real content. Long words overflow buttons, and translated strings break layouts that looked perfect in English.
6. Neglecting touch targets and contrast. Small buttons and faint text strain older users and anyone reading a phone in sunlight.
7. Skipping design QA and never asking for the source file. The released build drifts from the design, and files that stay with the agency turn every revision into a dependency.

Design doesn't stop after launch either. Every change you make without measuring where users drop off is a guess. Our mobile app analytics guide lists the metrics worth tracking.

Frequently Asked Questions

How long does it take to design a mobile app?

Designing a simple app usually takes 2–3 weeks, a mid-scale app 3–5 weeks, and e-commerce or enterprise projects 4–8 weeks. Screen count, the number of user roles and the speed of feedback rounds affect the timeline most.

What percentage of app development cost goes to design?

Data compiled by Business of Apps puts the design stage at an average of 20–25% of the total budget. On a $20,000 project, that means a design line item of $4,000–$5,000.

What is the difference between a wireframe and a prototype?

A wireframe is the colorless skeleton of a single screen and shows layout decisions. A prototype links those screens into an interactive mock-up you tap through on a phone, which lets you test the flow with real users.

Who owns the Figma files at the end of the project?

Ownership depends on your contract, so write the transfer of source files to your account into it. The source file lets you continue with a different team later without paying to redraw the design from scratch.

Do you need separate designs for iOS and Android?

Most projects don't. One design language, with details such as back behavior, date pickers and permission dialogs adapted per platform, protects brand consistency and keeps the design effort reasonable.

Can AI design a mobile app?

AI tools produce first drafts and alternative layouts in minutes, but they don't resolve business-specific flow logic, error states or platform rules on their own. In Figma's 2025 survey only 32% of respondents said they can rely on AI output.

Can you request changes after approving the design?

Yes, but the cost depends on the stage. A change takes minutes at the wireframe stage, hours in visual design and days on a coded screen, so make the big decisions early.

Does using a ready-made UI kit lower design quality?

No. A good UI kit offers a solid start with tested components and eases the budget. Quality depends on how carefully the team adapts the kit to your brand and your flows.

Mobile app design isn't the decorative layer of your project; it's the cheapest risk-reduction tool you have. A team that resolves flows in wireframes, usability problems in the prototype and consistency in the design system enters development without surprises. Once you know what you approve at each step, the process stops looking like a black box.

In our mobile app development projects we run mobile app design in Figma through a transparent process you can follow at every stage. To turn your app idea into screens, get in touch.