App Design How to Build Products Users Stick With.

You've signed off the feature list, the designer has opened Figma, and engineering is asking questions nobody has answered yet. Which user problem comes first? What happens when the network fails? Who owns the content, analytics and accessibility decisions? Many teams discover at this stage that they have a feature list, not a product design process.

A useful app design how-to process connects discovery, research, information architecture, visual design, testing, engineering and live measurement. It gives every handoff a clear output, while leaving enough room for assumptions to change when evidence challenges the original idea.

Key takeaways

• Discovery comes first: Start with user needs, business constraints and evidence from real behaviour.
• Research shapes structure: Turn interviews and observations into opportunity maps, not decorative personas.
• Wireframes settle journeys: Prove navigation and task order before investing in visual polish.
• Accessibility belongs in the system: Define accessible components, states and content patterns from the start.
• Testing is a loop: Prototype, observe, analyse and revise before the build hardens decisions.
• Handoff is collaborative: Treat design and engineering as an ongoing working relationship.
• Launch begins the next cycle: Measure engagement, identify friction and feed the findings into discovery.

What End-to-End App Design Looks Like in 2026

A Manchester-based fintech founder has just approved a feature list and is preparing a designer briefing. The first meeting goes well until engineering asks which assumptions have been tested, product asks which feature is essential for the first release, and compliance asks how consent will work. Nobody is disagreeing about the ambition. They do not share a process.

That gap matters more now because teams can move from idea to working interface quickly with AI-assisted tools, shorter build cycles and increasingly capable prototyping workflows. Speed makes weak decisions arrive sooner. It doesn't remove the need for judgement around privacy, accessibility, content, data and user trust.

The UK audience is large and mature. The UK app market generated $4.8 billion in 2024, up 9% year over year after $4.4 billion in 2023. UK users downloaded apps 2.3 billion times during that period, while the country had 50.8 million smartphone users in 2023, equivalent to 75.8% of the population. Those conditions reward teams that make the first-use journey, core task and return experience clear.

The seven phases and their handoffs

1. Discovery and research produce a prioritised problem frame, evidence and hypotheses.
2. Information architecture turns those findings into a feature inventory and navigation model.
3. Wireframing makes the main journeys discussable before visual detail obscures structural problems.
4. Visual design and systems establish components, content patterns, motion and accessibility rules.
5. Prototyping and testing exposes misunderstandings while the cost of change remains low.
6. Engineering collaboration translates design intent into buildable states, tokens and behaviours.
7. Launch and iteration uses live evidence to decide what deserves the next research cycle.

At Arch, the boundaries overlap deliberately. Researchers need technical context, designers need to understand data and edge cases, and engineers should see the reasoning behind a flow rather than receive unexplained screens. A practical digital product design process gives those conversations a shared language.

Discovery and User Research That Actually Informs Design

Discovery isn't a workshop that produces a polished slide deck and disappears. It's the point where a team tests whether it understands the problem well enough to invest in a solution.

The UK Government Digital Service recommends starting with user needs and researching real-world behaviour from existing services. Its model moves through discovery, alpha, beta and live, which is useful for commercial teams too. Discovery establishes the problem and constraints, alpha explores possible approaches, beta validates a service in realistic conditions, and live keeps learning after release. The Government Design Principles provide a strong foundation for this evidence-led sequence.

A focused discovery sprint may include stakeholder interviews, competitor teardowns, user interviews and a jobs-to-be-done synthesis. The exact duration depends on access, risk and scope, but the work should end with decisions, not just observations.

What to collect before drawing screens

• Stakeholder evidence: Capture commercial goals, operational constraints, regulatory concerns and existing product assumptions.
• Behavioural evidence: Ask users to describe recent behaviour and, where possible, observe how they complete the task today.
• Market evidence: Compare competing journeys for clarity, trust signals, account creation, pricing and recovery from failure.
• Opportunity evidence: Group recurring problems into opportunities that the product could credibly address.
• Delivery evidence: Identify platform, integration, data and content constraints before they become late-stage surprises.

Avoid manufacturing precision. A persona doesn't become useful because it has a name, age or stock photograph. It becomes useful when it captures a meaningful difference in needs, context or behaviour that changes a product decision.

Practical rule: Every research finding should either change a priority, alter a journey, reveal a risk or create a question for testing.

The handoff into wireframing should be explicit. Give the designer a problem statement, prioritised opportunity map, user segments, evidence excerpts, assumptions and open questions. A good UX research methods and techniques guide can help teams choose an appropriate method, but the important part is connecting the method to a decision.

The UK's mobile environment makes this discipline necessary. Reporting linked to Ofcom found users spent 3 hours 50 minutes per day in mobile applications in 2023, compared with 4 hours daily in 2019, while a 2024 UK mobile statistics report found 96% of adults were mobile phone users, more than 66 million people, and that the average user had 38 apps installed. UK mobile app usage reporting describes a crowded attention environment where clarity and task focus matter. Research tells you which task deserves that clarity first.

Information Architecture and Wireframing Before Pixels

Information architecture is product thinking made visible. It decides what belongs together, what deserves prominence and what users should never have to hunt for.

Start by converting the opportunity map into a feature inventory. Then sort each item into primary, secondary or tertiary tasks. Primary tasks support the product's central promise. Secondary tasks support confidence or account management. Tertiary tasks, such as legal information or rarely used preferences, still need a home, but they shouldn't compete with the main job.

Take a council services app. If residents most often need to report a missed bin collection, that task should be available from the home screen, with a short route from the first tap to the relevant form. The exact number of taps depends on the service and authentication state, but the principle is firm: don't bury the highest-value task beneath an organisational structure that makes sense only to the council.

Choose the structure with evidence

Card sorting can reveal how users group services in their own language. Tree testing can show whether those groups support findability without the distraction of visual styling. A simple paper sketch is often the fastest way to compare navigation ideas with a team. Grey-box wireframes in Figma become more useful when several states, validation messages and failure paths need discussion.

Annotated flows are particularly valuable where a journey depends on data or permissions. Mark the entry condition, system response, empty state, loading state, error state and successful completion. That annotation gives engineering an early view of complexity and stops the visual designer from polishing an incomplete path.

If the wireframe can't explain what happens after the tap, it isn't finished.

Keep the first wireframe set deliberately plain. Colour, imagery and brand expression can make a weak hierarchy feel convincing, which is exactly why they should arrive later. Ask stakeholders to sign off the structure, task order, navigation model and content assumptions before high-fidelity design begins. The approved wireframes then become the contract that visual design inherits, not a disposable stage that everyone forgets.

Visual Design, Systems and Accessibility Built In

A visual layer shouldn't be applied like paint over a completed interface. It should emerge from the wireframes as a coherent set of decisions about hierarchy, interaction, content and feedback.

A small, opinionated component library is usually a better starting point than a catalogue of every possible control. Build the recurring patterns first, such as buttons, inputs, cards, navigation, alerts, toggles and loading states. Eight to twelve well-defined components can expose more design truth than a sprawling library that nobody understands.

Build the system around decisions

Define the component anatomy, supported variants, content limits, interaction states and responsive behaviour. Then connect colour, spacing, typography and elevation through tokens. Figma variables can keep those values consistent across screens, while token names that map clearly to the codebase reduce interpretation during implementation.

A London fintech onboarding concept at Arch illustrates the value of restraint. The initial direction used a flashy motion reel, but the team narrowed it to two controlled micro-interactions that clarified progress and acknowledged a completed action. The point wasn't to make the flow feel less polished. It was to ensure motion supported comprehension instead of competing with the form.

Accessibility requires the same level of design ownership. UK public-sector mobile apps must meet the Public Sector Bodies Accessibility Regulations, and they must publish an accessibility statement. The technical benchmark is EN 301 549 v2.1.2, which maps largely to WCAG 2.1 AA for mobile apps and websites. Separate UK guidance notes that at least 1 in 5 people in the UK are disabled, reinforcing why accessibility is a product baseline rather than a specialist afterthought. UK accessibility guidance also highlights how widespread failures remain across digital experiences.

Before high-fidelity work, define:

• Colour behaviour: Contrast, semantic meaning, dark-mode treatment and non-colour cues.
• Component states: Default, pressed, focused, disabled, loading, error and success.
• Input behaviour: Labels, hints, validation, keyboard type and recovery instructions.
• Navigation support: Focus order, screen-reader labels and predictable back behaviour.
• Content rules: Plain language, truncation, dynamic text and translated-content tolerance.

A useful explanation of how these pieces connect appears in this guide to what a design system is. The system should help the team make consistent decisions, not prevent thoughtful exceptions.

Prototyping and Usability Testing as One Loop

A prototype is valuable because it gives users something specific to react to. Testing is valuable because it converts that reaction into a design decision. Treating them as separate phases creates a delay between learning and changing.

A practical working week can move from a clickable Figma prototype to five moderated sessions, analysis and a revised flow. Recruit participants who match the segments and situations identified during discovery. Give each person one realistic task, ask them to think aloud, avoid rescuing them too quickly and record what they do before recording what they say.

A compact test protocol

1. Prepare the task: Write a scenario with a clear outcome, not a list of interface instructions.
2. Moderate consistently: Use the same opening, task wording and follow-up prompts.
3. Capture evidence: Record hesitation, misinterpretation, navigation errors and workarounds.
4. Cluster observations: Separate repeated behaviour from an isolated preference.
5. Change the design: Link every revision to evidence or mark it as an assumption.

An evidence grid keeps the team honest. Use columns for the task step, observed behaviour, likely cause, severity, confidence and proposed response. Don't turn every comment into a feature request. Some observations reveal a content problem, a missing state or a flawed information hierarchy.

In one product review, three findings challenged a feature the team loved. Users didn't understand its label, couldn't predict what would happen after activating it and ignored it when it appeared beside the primary action. The team removed it from the core flow rather than defending the investment. A fourth finding showed that users understood the next step once the confirmation message made the outcome explicit, so the team changed that small piece of copy and retested the journey.

For teams trying to understand where users abandon a journey, guidance on how to diagnose funnel leaks offers a useful analytical complement to moderated research. Qualitative testing explains why the friction occurs, while product analytics can show where it occurs at scale.

Stop when the core task flow is sufficiently understood and the remaining uncertainty is low enough for the next delivery step. You don't need to resolve every edge case in a prototype, but you do need a plan for the unresolved ones.

Handoff to Engineering Without Losing Fidelity

Design doesn't end when the Figma link enters a ticket. That moment is where an abstract interaction becomes a real product with latency, permissions, keyboard behaviour, device differences and imperfect data.

Engineer-ready design includes the states that teams often forget to show in the happy-path presentation. Annotate component variants, name tokens consistently with the codebase, and use redlines only for cases the shared library doesn't already explain. A short Loom walkthrough can communicate intent, rationale and tricky transitions more effectively than a large specification document.

Make collaboration routine

Create a design-engineering Slack channel for questions that shouldn't wait for a formal meeting. Agree a regular review of shipped screens against Figma, then record gaps as system improvements rather than treating them as personal mistakes. When a component fails to cover a real product case, update the library and its guidance.

An Arch healthcare project exposed the practical value of this approach when QA found a missing loading state. Catching it before release avoided a last-minute release-day fix and revealed a broader issue in the component states, not just a single screen.

The handoff should therefore produce a shared understanding of:

• Behaviour: What the interface does across success, failure, loading and empty states.
• Ownership: Who supplies content, resolves technical questions and approves changes.
• Constraints: Which behaviours depend on APIs, permissions, device capabilities or policy.
• Acceptance: What the team checks before calling the implementation complete.

The best teams don't preserve fidelity by freezing design. They preserve it by keeping designers and engineers close enough to discuss where the implementation has changed and whether that change improves the product.

Your App Design Checklist and What to Do Next

Use the following checklist as a project-board starting point. It keeps the phases connected while making the output of each stage visible to the people responsible for the next one.

Discovery and research

• User needs: Write the primary user problem in observable terms.
• Stakeholders: Capture business, operational, technical and compliance constraints.
• Research plan: Select methods that answer current product decisions.
• Evidence set: Store interview notes, behavioural observations and competitor findings.
• Opportunity map: Group evidence into prioritised opportunities and open questions.

Information architecture and wireframing

• Feature inventory: Record every proposed capability and its user purpose.
• Task hierarchy: Separate primary, secondary and tertiary jobs.
• Navigation model: Show how users reach the most important task.
• IA validation: Use card sorting or tree testing where grouping remains uncertain.
• Wireframe sign-off: Confirm journeys, states and content assumptions before visual design.

Visual design and systems

• Component coverage: Identify the recurring patterns and missing states.
• Tokens: Define colour, spacing, typography and semantic naming.
• Accessibility: Check contrast, focus, labels, touch interaction and reading order.
• Motion scope: Keep animation tied to orientation, feedback or comprehension.
• Prototype fidelity: Make the prototype realistic enough to answer the current question.

Testing, engineering and live learning

• Test findings: Cluster observations by task, cause, severity and confidence.
• Design decisions: Record what changed, what stayed and why.
• Engineer specs: Document behaviour, edge cases and implementation constraints.
• Review loop: Compare shipped screens with the intended experience.
• Post-launch metrics: Monitor meaningful engagement and use the findings to start the next discovery round.

The process isn't a waterfall. A launch creates new questions, and the first analytics review should feed the next research sprint. UK government guidance makes the same distinction between downloads and genuine use. GOV.UK app and website usage reporting notes that app-store downloads alone don't show whether people use a product, while usage data gives a better view of engagement. It reports that smartphones accounted for 61% of GOV.UK visits by December 2025, the GOV.UK app had been downloaded more than 316,000 times by the end of 2025, 85% of app users customised their homepage, and 46% were return users.

Start today with three actions: run one stakeholder interview, sketch one core flow on paper, and book a five-user usability test before visual design begins. Those actions create evidence, expose assumptions and give the team something concrete to improve.

For teams planning a custom product, Arch combines discovery, UX and UI design with mobile app development, prototyping and engineering collaboration. Visit Arch to discuss your app idea, map the riskiest assumptions and plan a route from first flow to production-ready launch.

Frequently Asked Questions

What does app design include?

App design includes discovery, user research, information architecture, wireframing, visual design, interaction patterns, accessibility, prototyping, usability testing and collaboration with engineering. It also includes decisions about content, empty states, errors, permissions, loading behaviour and measurement. A polished interface is only one part of the work. Effective design connects the user's goal to a reliable journey that the technical team can build and maintain.

Should app design start with Figma?

No. Figma is useful for exploring and communicating interface ideas, but starting there can make untested assumptions look authoritative. Begin with the user problem, available evidence, constraints and the task you need to understand. Paper sketches, journey maps, feature inventories and annotated flows may answer early questions faster. Move into Figma when a clickable or shareable representation will help the team compare options or test behaviour.

How do you make an app accessible from the start?

Define accessibility at component level before high-fidelity screens multiply. Check colour contrast, focus states, labels, reading order, touch interaction, error recovery and content clarity. Include loading, empty and failure states in the design system, then test with assistive technologies and people with different access needs. For UK public-sector apps, follow the relevant accessibility regulations, publish the required statement and use the applicable technical benchmark.

How many usability tests should an app team run?

The right number depends on the question, audience and risk. A small, focused round can reveal major problems when participants match the research segments and each session centres on a realistic task. Run sessions consistently, capture observed behaviour and distinguish repeated usability issues from individual preferences. Test again after meaningful changes. Stop when the core flow is understood well enough to build, while documenting unresolved edge cases for later validation.

What should an engineer receive from a designer?

An engineer should receive the intended flow, component states, content behaviour, accessibility requirements, tokens, interaction rules and known constraints. Include loading, empty, error, success and permission states, not only the ideal path. A short walkthrough can explain rationale and unresolved questions. The handoff should also create a channel for ongoing discussion, because implementation will expose technical conditions that require collaborative design decisions.

How do you measure whether app design works after launch?

Measure whether users complete meaningful tasks and return for the value the product promises. Downloads can indicate distribution, but they don't prove engagement. Combine product analytics with support conversations, session observation, accessibility feedback and qualitative research. Review the evidence after launch, identify the highest-impact uncertainty and use it to prioritise the next discovery sprint. A good metric framework helps the team learn, rather than merely defend the original design.

About the Author

“Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the transformative potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.”

Hamish's LinkedIn