Mobile App Design: A Practical Guide for Startups.

Key takeaways

• Mobile app design is a product discipline, not a visual styling exercise. Measure activation, task completion, retention and reliability from the first release.
• UK smartphone users accessed an average of 41 apps during May 2025, so your product must communicate value quickly and work alongside familiar services.
• Start with discovery, user research and a tightly defined first release before investing in polished screens.
• Use platform conventions thoughtfully. iOS and Android should share a design system, but they shouldn't look like forced copies of one another.
• Build accessibility, permission choices, error recovery and performance into the experience from the beginning.
• Test realistic tasks with users, then use analytics, crash reporting and session evidence to guide the next iteration.

A UK smartphone user accessed an average of 41 apps during May 2025, three more than in the previous year, according to Ofcom's 2025 Online Nation findings. That figure changes the design question. Your app isn't competing only with direct competitors. It's competing with banking, transport, messaging, maps, shopping and utility apps that already teach users how mobile products should behave.

For a startup, that means attractive screens aren't enough. People need to understand the value, complete important tasks and recover from mistakes without friction. The sections below take you from early discovery to launch, using practical decisions you can apply before committing a large budget to development.

Why Mobile App Design Is a Product Discipline

WhatsApp reached 92% of adult smartphone users, Facebook reached 85%, and Google Maps reached 77% in the UK, according to the Ofcom report. Those familiar products shape expectations before someone opens your app. Users already know how common mobile tasks should feel, so every unfamiliar step creates a question your design must answer.

A mobile app is more like a shop visited during a busy commute than a brochure placed on a desk. People arrive with limited attention, a specific job and little patience for unclear choices. For a startup, visual appeal matters, but the product must also communicate value, support task completion and help users recover when something goes wrong.

Reduce cognitive load before adding visual polish. Use familiar labels, predictable navigation and a clear next action. Explain permission requests when the user can understand their purpose, then make the choice and its consequence clear. These decisions connect interface quality with trust and responsible product behaviour. A polished screen that slows a task still produces a poor experience.

Measure the experience, not just the screen

Treat design as a set of product decisions that can be checked after release. Daily active users indicate whether the app supports repeat behaviour. Saving a user's place or reducing sign-in friction may affect whether they return.

Crash-free sessions show whether the experience holds up in real conditions. A convincing prototype provides limited evidence if the released app fails during checkout, upload or payment. Task completion shows whether users can achieve the product's central promise. Abandonment points to a flow problem that colour changes cannot repair.

Use the pattern behind each measure to set priorities. Weak task completion calls for a simpler journey. Weak repeat use calls for a clearer reason to return. Weak reliability requires recovery states and technical performance to be treated as design requirements.

Use these mobile app design best practices to review early decisions, then test whether each practice improves a real outcome. The aim is to find where your app asks users to think harder than necessary.

Starting With Research and Discovery

Small teams don't need a lengthy research department to make better decisions. A founder, designer and engineer can create useful evidence in one or two focused weeks, provided each activity produces an artefact that informs the next decision.

Start with the business boundary

Begin with stakeholder interviews. Ask what the organisation needs to prove, which audience matters first, what the product won't do in its initial release and which business outcome would justify continued investment. Capture the answers in a scope and success brief.

Next, run a competitive scan. Review four to six direct apps and two adjacent products, but don't just collect screenshots. Record how each app handles onboarding, search, primary actions, permissions, errors, pricing and repeat use in a simple comparison matrix. The output is a pattern and gap map.

Talk about behaviour, not opinions

Interview target users about recent experiences. Ask, “Tell me about the last time you solved this problem,” rather than, “Would you use an app that does this?” Follow up on the tools they used, where they became uncertain, what they did next and what they would have changed.

A short discussion guide might include:

• Recent situation: What were you trying to achieve?
• Current workaround: Which app, service or person helped you?
• Friction: Where did the process slow down or become confusing?
• Trust: What made you continue, stop or seek another option?
• Success: What would a satisfactory outcome look like?

The artefact from these conversations is a research synthesis, not a collection of interesting quotes. Cluster observations into an opportunity map, write two personas around concrete jobs to be done and turn the strongest opportunity into a first-release problem statement.

Teams often skip this work because they want to start designing. That shortcut usually moves uncertainty into development, where changing scope costs more and disagreements become harder to resolve. A concise guide to the role of this phase is available in what discovery means in product work.

Interaction Design and Core UI Patterns

Good interaction design matches a pattern to a user's task. A component isn't valuable because it's fashionable. It's valuable because it reduces effort without hiding important choices.

Use bottom navigation when users regularly move between three to five primary destinations, such as Home, Search, Saved and Profile. Use tabs within one destination when users are comparing parallel content, such as “Upcoming” and “Completed”. A bottom sheet works well for secondary actions on a focused screen. In a budgeting app, a user could edit a transaction in a sheet without losing their place in the list.

Pull-to-refresh suits time-sensitive content, such as a news feed that needs to synchronise with the latest stories. A floating action button should support one dominant creation task on a screen. In a marketplace, that might be “List an item”. If a screen has several equally important actions, a FAB can create unnecessary competition rather than clarity.

Make the pattern serve the journey

• Bottom navigation: Moving between core areas. Watch for destinations that users visit only occasionally.
• Tabs: Comparing related categories. Watch for labels that become truncated or ambiguous.
• Bottom sheets: Editing, filtering or choosing a secondary option. Watch for actions that require sustained concentration or a large amount of content.
• Pull-to-refresh: Checking for updated information. Watch for interfaces that give no visible confirmation that synchronisation occurred.
• Floating action button: Creating one central type of content. Watch for multiple competing creation actions.

Two judgement calls need particular care. Use a modal when the decision is brief and related to the current context. Use a new screen when the task needs more space, navigation, explanation or the ability to pause and return later.

You can also deliberately break a convention when research shows that users expect something different. A transport app may prioritise a persistent map over a familiar navigation structure because location is the product's central task. The exception should be explained by user behaviour, not personal taste.

For teams preparing large batches of creative assets for product or campaign work, Figma creative bulk upload can help organise production workflows. It doesn't replace interaction decisions, but it can support the delivery process around them.

Following iOS and Android Platform Guidelines

A shared codebase doesn't require identical screens. Users carry platform expectations with them, and ignoring those expectations makes an app feel foreign even when the underlying functionality works.

iOS Human Interface Guidelines generally favour familiar tab-bar navigation, system gestures, SF Pro typography and presentation patterns that feel native to iPhone. Android Material 3 provides its own language around bottom navigation, navigation rails, Roboto typography, system back behaviour and modal surfaces. The right choice depends on the platform, screen size and task hierarchy.

Consider onboarding. An iOS design might place a completion action in the top-right navigation area, while an Android implementation may use a prominent action at the bottom of the screen. Mirroring the same placement pixel for pixel can make both versions less comfortable because each platform teaches users different habits.

Share foundations, adapt the expression

Create one design system for brand principles, content hierarchy, colour roles, spacing logic and component behaviour. Then add platform-specific tokens for typography, corner treatment, navigation, iconography, sheets and system feedback.

Pay special attention to Android's back button and gesture navigation. Every screen should have a clear response to back, including interrupted forms, nested flows and modal states. On iOS, test swipe-back interactions and avoid placing controls where they conflict with system gestures.

Before handoff, confirm:

• Navigation: Users can identify where they are and how to return.
• Gestures: System gestures remain available and intentional product gestures don't conflict with them.
• Icons: Symbols communicate meaning consistently on each platform.
• Feedback: Loading, success, failure and destructive actions receive clear responses.
• Error states: Users can recover without losing work.
• Source of truth: Shared components and platform variants are documented in one maintained system.

Designing for Accessibility From Day One

The UK Government's monitoring programme identified 29,787 accessibility issues across public-sector websites and mobile apps from 2022 to 2024. Organisations fixed 16,482, or 55.3%, while the overall compliance rate reached 70%, up from 59% in the previous monitoring period, according to Government Digital Service monitoring data. These figures make accessibility measurable. They also show why a late audit is a poor substitute for decisions made during product design.

Design for barriers, not just criteria

Public-sector apps are covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. UK Government guidance identifies WCAG 2.2 AA as the required technical standard and recommends testing with screen magnifiers, screen readers, speech-recognition tools and disabled people in research. The official accessibility requirements for public-sector apps explain the wider responsibility.

Private-sector teams operate under a different legal context, but the user evidence remains relevant. Research found that 64% of smartphone users had encountered at least one barrier in mobile digital services. The proportion was 81% among users aged 18 to 24 and 53% among those aged 55 and over. Around 2.7 million people aged 65 and over were unable to find and open different applications or programmes on their devices, according to UK smartphone accessibility research.

Build these behaviours into Figma components rather than adding them after the screens look finished. Include scalable text, meaningful labels, predictable focus order, clear errors, sufficient touch space and alternatives for audio. For a deeper walkthrough of inclusive design choices, see our guide to designing for accessibility. Test VoiceOver and TalkBack while flows remain easy to change, then repeat the checks on the production build.

For startup founders, the public-sector deadline of 23 June 2021 is a useful warning, even where those regulations do not apply. The monitoring record shows what late-stage audits can leave unresolved: fewer than 57% of identified issues were fixed. Treat private-sector expectations as a leading indicator. Public-sector organisations must publish an accessibility statement covering compliance, known failures, alternatives and a contact route, as described in the Government guidance on accessibility statements. Accessibility audits should also occur at Private Beta and Public Beta, with new features treated as an ongoing responsibility under the Government delivery guidance.

Prototyping, Testing and Developer Handoff

Take a representative onboarding flow and move it through four artefacts. The first is a low-fidelity wireframe in Figma. It should establish information architecture, screen order, content priorities and the main action, without encouraging debate about colours or illustration style.

The second is a clickable mid-fidelity prototype. Use it to test whether a person can complete the intended journey, not whether they like the visual direction. A moderated remote test with five users can focus on three tasks, one relevant persona, clear success criteria and a think-aloud instruction. Keep the facilitator quiet enough to observe, but ready to ask what the participant expected when they hesitate.

Increase fidelity only when uncertainty falls

Once the structure works, create the high-fidelity prototype. Include micro-interactions, empty states, validation, loading behaviour, permission denial, offline messaging and recovery after an error. These details reveal whether the product still makes sense when the ideal path breaks.

A developer handoff should contain more than polished screens. Prepare auto-layout frames, component variants, naming conventions and design tokens exported as JSON where that fits the engineering workflow. Add written specifications for session timeout, interrupted uploads, denied push permissions and unsaved form data.

The best handoff answers questions before they become implementation disputes:

• What happens when data is missing?
• What does the user see while the network responds?
• Can the user retry without repeating the entire task?
• Which behaviours are shared across platforms?
• Which behaviours must follow iOS or Android conventions?

Use prototyping in design to align stakeholders before development absorbs the cost of change. After launch, session replays, analytics and support conversations should feed the next research cycle. A prototype is not the end of design. It's an instrument for learning.

Performance, Permissions and Trust

Reliability is part of the interface. A button that appears responsive but fails without any visible indication creates the same user problem as a poorly labelled button.

A UK survey of 2,000 smartphone users found that 85% preferred a basic-looking app without glitches over a visually polished app with occasional problems. Thirty-five per cent would abandon an app within minutes if it failed to function properly, 40% experienced an app crash at least monthly, and 58% would likely abandon a brand after app problems, according to Amplitude's UK consumer app research.

Ask for access when the benefit is clear

Don't request every permission on first launch. Ask for camera access when a user taps “Scan receipt”, explain why the camera is needed and provide a manual alternative where possible. This makes the choice part of the task rather than an unexplained barrier at the beginning.

A Which? investigation into app permissions found that 15 of 20 widely used apps tested requested precise-location access, while 66% of surveyed people were concerned about apps collecting it. The investigation recorded 882 permissions, including 78 classified as risky. The design response is data minimisation, not more elaborate consent copy.

Make privacy understandable at the decision point. State what you collect, why it's needed, when it will be used and what still works without it. Since 52% of people never read data-collection policies and 46% skip third-party data-sharing policies, long documents can't be your only explanation.

Design the states users meet when something goes wrong. Skeleton screens can keep a loading journey oriented, while a useful offline state should explain what remains available and when synchronisation will resume. Track crash-free sessions, failed transactions, permission acceptance, later revocation, push opt-in and app-store sentiment after launch. Acceptance alone isn't success if users abandon the feature afterwards.

Bringing It All Together and Next Steps

Mobile app design works as a cycle, not a row of departments passing work over a wall. Research shapes flows, flows shape prototypes, prototypes expose assumptions, and shipped behaviour creates evidence for the next research decision.

A founder can use the week before submission to check whether the product is ready for real conditions:

• Research evidence: Archive stakeholder findings, competitive patterns, user observations, personas and the first-release problem statement.
• Core journeys: Test the primary flows with representative users and record where they hesitate, fail or recover.
• Platform behaviour: Review navigation, gestures, typography, system feedback and back behaviour on iOS and Android.
• Accessibility: Complete an audit against WCAG 2.2 AA, test assistive technology and verify that known issues have owners.
• Reliability: Document performance expectations, crash monitoring, loading states, offline behaviour and failed-transaction recovery.
• Permissions: Review every requested scope, its timing, its explanation and the manual alternative.
• Measurement: Confirm that activation, task completion, repeat use, crashes and key feature events are recorded.
• Release assets: Prepare store descriptions, screenshots, preview content, support information and the accessibility statement where required.

The hardest decision is often what to keep in-house. Your team should retain product knowledge, customer insight and the decisions that define your advantage. A specialist studio can accelerate discovery, user flows, interface systems, prototyping and production delivery when hiring a complete product team would add too much overhead.

The right partner won't remove the need for founder involvement. They'll make decisions visible, test assumptions early and connect design choices to the product outcomes you need to improve. That's the difference between ordering screens and building a product discipline.

Frequently asked questions

What is mobile app design?

Mobile app design combines research, interaction design, visual systems, accessibility, prototyping and validation to help people complete tasks on a small screen. It includes decisions about navigation, content, permissions, errors, loading, platform conventions and trust. A successful process doesn't stop at attractive mock-ups. It connects the interface to measurable outcomes such as task completion, repeat use, reliability and reduced support friction.

Should a startup design for iOS and Android separately?

Start with shared product principles, content structure and brand foundations, then adapt platform-specific behaviour. iOS and Android users expect different navigation conventions, typography, gestures, back behaviour and system feedback. Pixel-for-pixel duplication can make an app feel unnatural on both platforms. A shared design system with platform-specific components and tokens gives engineers consistency while allowing each version to behave as users expect.

When should accessibility testing begin?

Accessibility testing should begin during discovery and interaction design, not after development. Ask disabled people to participate in research, test prototypes with VoiceOver and TalkBack, and check content structure, focus order, touch interactions, scaling and error recovery before screens are final. Production testing still matters because implementation can introduce problems that weren't visible in a design file. Treat each new feature as part of the continuing accessibility responsibility.

How many screens should an MVP include?

An MVP should include the smallest complete journey that tests the product's central promise. That might mean several screens, or it might require only a focused flow with supporting states such as loading, empty, error and permission denial. Count decisions and user outcomes rather than screens. Remove features that don't help users reach the first meaningful result or help the team learn whether the proposition works.

What should a founder measure after launch?

Measure whether users understand the value, complete the important task, return when the problem recurs and receive a reliable response. Useful signals include activation, task completion, repeat use, crash-free sessions, failed transactions, permission acceptance and later revocation. Pair quantitative events with support conversations and session evidence. A metric without context can tell you that a flow changed, but not why users struggled with it.

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 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 profile

Arch helps startups and growing teams turn mobile product ideas into researched journeys, accessible interfaces, tested prototypes and production-ready apps. Visit Arch to arrange a 30-minute scoping call and map the first release around your users, risks and measurable goals.