If you are commissioning an app, you may think of app design as the step in which the app is “made to look good”. In fact, this phase is where the decisions are made that determine all further effort: which tasks the app solves, in which order users move through the screens, and what happens when an error occurs or there is no network. A change to a wireframe is quick to make. After development, the same change affects code, tests and often the backend as well.
This article describes the six phases, their deliverables, the sign-offs and the realistic effort for a typical mid-sized company project. Brand development and the design of the store listings are not covered; for the latter, see the article on App Store review and ASO.
Wireframe, mockup, clickable prototype: the terms
In app design, four terms are often used interchangeably, although they describe different deliverables with different purposes. This has practical consequences: if you sign off mockups when the flow is what should actually be checked, you approve colours and icons and only notice the unnecessary confirmation step once it has been programmed.
A wireframe is a greyscale structural sketch of a screen. It shows which content and controls go where and deliberately leaves out colours, fonts and images. This keeps the discussion focused on content and flow.
A mockup is the static, visually finished version of the same screen: final colours, typography, icons, real copy. It shows what the app will look like, but you cannot interact with it.
A clickable prototype (also called a click dummy) links the screens so that you can tap through them on a smartphone as if it were a real app. There is no program logic and no database behind it. Each button simply leads to the next prepared screen.
Prototype is the umbrella term for any testable preliminary version, from linked wireframes (low fidelity) to a clickable prototype built from final mockups (high fidelity).
| Deliverable | Answers the question | Level of detail | Signed off by |
|---|---|---|---|
| Wireframe | What goes where, which steps are there? | low, greyscale | business department, product owners |
| Mockup | What does it look like? | high, static | product owners, marketing (corporate identity) |
| Clickable prototype | Do users understand the flow? | medium to high, clickable | client, after the usability test |
| Design System | How will it be built? | components and Design Tokens | development |
The app design process in six phases
The six phases build on one another. Each ends with a deliverable that someone signs off before the next one begins. That sounds like waterfall, but in practice it is iterative: a usability test in phase 5 regularly sends individual flows back to phase 2 or 3. What matters is that these loops happen before development starts.
Phase 1: Goals, users and core tasks
Before the first screen come three questions. Who uses the app, and in what situation? A warehouse worker wearing gloves, a field sales rep with a poor connection and a consumer on the sofa need very different interfaces. Which three to five tasks must the app handle reliably? And how will you measure after launch whether it does, for example by time per transaction or the number of completed orders?
The deliverable is a short, prioritised list of core tasks plus the constraints: platforms, systems to integrate and accessibility requirements. If a requirements specification already exists, it is the input for this phase. Which of these tasks belong in the first version is a scoping decision, described in detail in the article on MVP development.
Phase 2: Information architecture and user flows
The information architecture defines which areas the app has and how they relate to one another: what sits in the main navigation, what is one level down, and what can only be reached via search? The result is a screen list, which is also the most important basis for any effort estimate.
Next, a user flow is drawn for each core task, i.e. the path from entry point to goal. This includes the awkward branches: what happens if the login fails, camera permission is denied or the connection drops halfway through a form? These cases never appear in a mood board. If, for instance, there is no rule for a lost connection, a half-completed form is lost, and gaps like this often lead to rework when they only surface during development.
Phase 3: Wireframes
Now the screens on the screen list are drawn as wireframes, first roughly and often on paper, then neatly in the design tool. Two rules save time here. First, use real content instead of placeholder text. A product name with 60 characters or a German error message will break a layout that looked perfect with “Lorem ipsum”. Second, design every screen in all its states: empty, loading, populated, error and offline.
Signing off the wireframes is the most important approval in the entire process. The business department checks whether all the information is there and whether the order of steps is right. What gets reviewed is the flow, not the individual screen. The section on typical sticking points below explains why this makes the difference.
Phase 4: UI design and mockups
In UI design, the wireframes take on their visual form: colours and fonts from the corporate design, icons, spacing, imagery. The platform conventions apply here. Apple describes them in its Human Interface Guidelines, Google in Material Design.
With iOS 26, Apple introduced the Liquid Glass design language, and with an Android 16 update in September 2025, Google introduced Material 3 Expressive. For design work, this means that navigation bars, tab bars and dialogs look different under iOS 26 and Android 16 than in older UI kits. If you design on outdated templates, you create discrepancies that will surface in development at the latest.
For cross-platform apps built with React Native or Flutter, the question is whether iOS and Android should look identical. Our recommendation: brand elements such as colours, typography, imagery and content are the same on both platforms. System patterns such as back navigation, date pickers and permission dialogs follow the respective platform, because users know them from every other app on their device. The article Flutter vs. React Native compares which framework suits which project.
Accessibility belongs in this phase. For iOS, Apple specifies a default size of 44 × 44 points for controls and 28 × 28 points as the minimum. For Android, Google recommends touch targets of at least 48 × 48 dp. For web apps, WCAG 2.2 requires at least 24 × 24 CSS pixels in success criterion 2.5.8. For normal text, WCAG 2.2 (success criterion 1.4.3, level AA) requires a contrast ratio of at least 4.5:1, and 3:1 for large text. Apple's guidelines recommend the same values.
For apps through which consumers enter into contracts, such as shopping, banking or ticketing apps, the German Accessibility Strengthening Act (BFSG, implementing the European Accessibility Act) has also applied since 28 June 2025. Micro-enterprises providing these services are exempt, i.e. companies with fewer than ten employees and an annual turnover or balance sheet total of no more than €2 million. Pure B2B and internal apps do not fall into this category. Accessible design is still worthwhile there, because the same rules also help users wearing gloves, in bright sunlight or on a small display.
Phase 5: Clickable prototype and usability test
The mockups become the clickable prototype: the screens are linked in the design tool and opened on real smartphones. For early tests, a clickable prototype built from wireframes is often enough. It answers the question that no review in a meeting room can answer: do people who don't know the app understand the flow without explanation?
The test itself is manageable. You give test participants from the target group specific tasks (“Create a new order for customer Müller”), ask them to think aloud and don't help. In 2000, Jakob Nielsen set out why five users per test round are enough: according to his model, they uncover around 85% of usability problems.
This figure applies to a homogeneous user group. For two clearly different target groups, Nielsen recommends three to four people per group. He also explicitly advises several small rounds rather than one large one, because every fix can create new problems.
The deliverable is a test report with prioritised findings. An entry might look like this: task “Save order”, observation “Save button is hidden by the keyboard, three out of five people search for it”, severity critical, returned to phase 3. Critical findings go back to phases 2 to 4, ideally followed by a second, shorter round.
Phase 6: Design system and handover to development
The end result is a component library. Every button, input field and list is defined once, with all its states (default, pressed, disabled, error). Colours, spacing and font sizes are stored as named values, known as design tokens.
The benefit: if a brand colour changes, it is changed in one place and reaches all screens and platforms via the token pipeline, provided design and code use the same tokens.
Since 28 October 2025, there has been an open standard for the format: the Design Tokens Community Group at the W3C published the first stable version, 2025.10, of its specification. Tools such as Style Dictionary generate code for iOS, Android, web and Flutter from it. Figma, Penpot and Sketch already support the format or are implementing it.
The handover continues throughout development. In Figma's Dev Mode, developers see dimensions, spacing and assets directly on the design.
Even so, questions arise during implementation that the design has not answered: what happens when the keyboard hides the save button? How does a list behave that has twelve entries in the mockup and 500 in live operation? So plan for the designer to remain available during development and to check the implemented screens against the design before release.
What level of detail does your project need?
How deep each phase goes depends on how costly an error in the flow would be and who uses the app.
An internal app with few screens and known users, such as a data capture tool for the warehouse, can often manage with wireframes, a low-fidelity clickable prototype and a short test with three colleagues. The UI design can build on an existing component library such as Material Design (Material 3) instead of designing every component from scratch.
A consumer app in the App Store, by contrast, goes through all six phases, with a high-fidelity clickable prototype and at least two test rounds. Here, the first use decides whether the app stays installed.
If a budget first needs internal approval, for example from the management board or an advisory board, a clickable prototype of the most important flow is often a better basis for the decision than a concept paper. In that case, the design system can wait. When revising an existing app, it makes sense to start the process with a usability test of the current version, so that it is clear what the new one needs to do better. The fundamental choice between revising and rebuilding is covered in the article App update or rebuild (in German).
Tools for wireframes and clickable prototypes
Two questions decide the choice of tool: where are the designs allowed to be stored, and who needs to see them?
Figma is considered the de facto standard in app design. Wireframes, mockups, clickable prototype and handover all happen in one tool. Clients can view prototypes via a share link or with a free Figma account, without a paid seat. The list prices on the Professional plan, billed annually, are 16 US dollars per month for a Full seat, 12 US dollars for a Dev seat and 3 US dollars for a Collab seat (as of October 2026). Dev Mode for the handover is only available with a Dev or Full seat.
Since 24 July 2025, Figma Make has also been generally available. The tool generates interactive prototypes from a text description. This is useful for quick variants in the wireframe phase. It does not replace testing with real users, and the generated code is not a planned app architecture.
Penpot is the open-source alternative under the Mozilla Public License 2.0. Penpot can be self-hosted, works with open formats such as SVG and CSS and supports design tokens natively. This is relevant if designs must not leave your own infrastructure, for example for public-sector apps or sensitive internal processes.
Sketch can only be edited on a Mac; viewing and commenting work in the browser. Adobe XD has been in maintenance mode since 2023 and is no longer an option for new projects. For the first rough sketches, paper remains a serious tool: faster than any software and with no invitation to debate pixels.
Effort and duration: a model calculation
How long the app design process takes depends on the number of screens and the speed of sign-offs. The following model calculation assumes a cross-platform app with around 20 screens and three core tasks. A corporate design already exists, and the work is done by one designer with part-time project management. The figures are guide values for orientation, not a price list.
| Phase | Deliverable | Effort (person-days) |
|---|---|---|
| 1. Goals and core tasks | prioritised task list, constraints | 2–4 |
| 2. Information architecture and user flows | screen list, flow diagrams | 2–4 |
| 3. Wireframes | around 20 screens including states | 4–7 |
| 4. UI design and mockups | finished screens for iOS and Android | 6–12 |
| 5. Clickable prototype and usability test | prototype, one test round with five users, corrections | 4–7 |
| 6. Design system and handover | component library, design tokens, handover | 4–8 |
| Total | – | 22–42 |
The calculation includes one test round. A second round, as is advisable for consumer apps, adds roughly two to four person-days. Not included are the recruitment of test participants and any incentives paid to them. The article Having an app developed: costs and process shows where design fits into the overall budget of an app.
In calendar time, 22 to 42 person-days usually correspond to six to ten weeks. The greatest uncertainty lies on the client side, with the sign-offs. A simple example: the process has six sign-off points. If the team waits one week for a decision at each of them, the project is extended by six weeks without any change in design effort. Fixed sign-off dates with all decision-makers, entered in the calendar at project kick-off, are therefore the most effective measure against delays.
Where app design projects typically stall
A common reason for delays is signing off individual screens. If you approve twenty mockups as images by email, you won't see that the path from shopping cart to order has seven steps. Sign-offs therefore take place on the clickable prototype and along the user flows.
Missing content is just as common. If product copy, error messages or legal notices are only delivered after the design, they rarely fit into the space provided. At best, this means rework; at worst, development decides what it looks like.
A third pattern is design without technical feedback. An elaborate animation or a custom-designed date picker looks good in the mockup but can cost many times as much to implement as a standard component. If a developer joins the discussions from phase 3 onwards, such issues come to light before implementation.
Frequently asked questions about app design
What is a clickable prototype? A clickable prototype, also called a click dummy, is a prototype made of linked screens that you can tap through. It is used to test flows with users and to validate decisions before any code is written.
How long does the app design process take? For an app with around 20 screens, six to ten weeks is a realistic timeframe, with an effort of roughly 22 to 42 person-days. Smaller internal apps are quicker; apps with several target groups and many states take longer.
Can the clickable prototype later be reused as the app? As a rule, no. A clickable prototype consists of linked designs in the design tool. What is reused are the mockups, the component library and the design tokens, from which development builds the real app.
Conclusion: test the flow, schedule the sign-offs
In six phases, the app design process clarifies what the app must do, how users operate it and how it will be built. The clickable prototype with a usability test is the step at which these decisions are tested with real users for the first time; in the model calculation, the clickable prototype, one test round and the corrections together cost four to seven person-days. Calendar time is determined mainly by the sign-offs, which is why fixed sign-off dates belong in the calendar from project kick-off.
The first concrete step does not need a design tool yet: a prioritised list of core tasks and a screen list. If you then need wireframes and a testable clickable prototype before deciding on the development budget, you will find our approach on the page on prototyping and wireframing. For the complete UI design including a design system, see the App UX/UI Design page.
