Design
Mobile App Design
Different from web design in the constraints that matter: one hand, small screen, interrupted attention, and platform conventions users already know.
Mobile app design produces interfaces that follow iOS and Android conventions rather than fighting them. The Nexclick designs for one-handed use, tests on a real mid-range device in daylight, and designs every state — because an app is judged on the fortieth use, not the first.
Is this you?
What usually prompts the call
- Your app was designed as a website and behaves like one on a phone.
- Users install it, complete onboarding, and never open it again.
- The same design was shipped to iOS and Android and neither feels native.
- Key actions sit at the top of the screen where nobody can reach them one-handed.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Platform convention research
- What iOS and Android users already expect — navigation patterns, gestures, system controls. Fighting these makes an app feel wrong in a way users cannot articulate but do act on.
- One-handed reach mapping
- Primary actions placed within thumb reach. A button at the top of a modern phone screen is genuinely difficult to press while holding it, and this is designed around rather than noticed later.
- Onboarding designed for value, not tour
- Getting someone to a first useful outcome quickly. Multi-screen feature tours are where most installs are lost, and they are the default nobody questions.
- Every state designed
- Loading, empty, error, offline, permission-denied and no-results. Apps are used on unreliable connections, so these are not edge cases here — they are normal.
- Platform-specific adaptation
- Shared structure, adapted components. iOS and Android differ on navigation, typography, controls and back behaviour, and ignoring that produces something that feels foreign on both.
- Testing on real mid-range hardware
- On an actual phone, outdoors, one-handed. Simulators on a large monitor hide almost every problem worth finding.
- Developer handoff with specifications
- Spacing, states, animation timing and platform differences documented, so the build matches without a fortnight of clarifications.
Comparison
iOS and Android differences that matter to a design
Shipping one design to both platforms produces something that feels foreign on each. These are the differences worth adapting for — the rest can usually be shared.
| Element | iOS convention | Android convention | Adapt? |
|---|---|---|---|
| Primary navigation | Tab bar at the bottom | Bottom navigation or navigation drawer | Yes |
| Back behaviour | Back button top-left, plus edge swipe | System back gesture or button | Yes — Android must respect system back |
| Typography | SF Pro | Roboto | Yes — use the platform face |
| Action placement | Top-right for primary action | Floating action button | Yes |
| Modals and sheets | Sheets slide from the bottom | Dialogs and bottom sheets | Mostly |
| Switches and controls | iOS-style toggle | Material switch | Yes — use native controls |
| Date and time pickers | iOS wheel picker | Material picker | Yes — always use the system picker |
| Confirmation of destructive action | Action sheet from the bottom | Dialog | Yes |
| Icon style | SF Symbols | Material Symbols | Yes |
| Layout, spacing and grid | Broadly similar | Broadly similar | No — share this |
| Brand colour and imagery | Yours | Yours | No — share this |
| Content and copy | Identical | Identical | No — share this |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Understand the task and the context
What users are doing, where and under what conditions. An app used on a building site has different requirements from one used on a sofa.
- 02Week 2–4
Structure and prototype
Navigation model and flows, prototyped and tested on a real device rather than in a browser window.
- 03Week 4–8
Design both platforms
Shared structure with platform-specific components, every state included, with two review rounds.
- 04Week 8–10
Specify and support the build
Handoff documentation and availability during development for the questions that always arise.
What you get
Reporting and ownership
- Designs for both platforms, adapted rather than duplicated.
- Every state designed, including offline and permission-denied.
- Evidence of testing on real mid-range hardware, not a simulator.
- A handoff specification covering spacing, states, animation and platform differences.
- Editable source files transferred to your ownership.
Tools and platforms
- Figma
- Real device testing (iOS and Android, mid-range)
- Apple Human Interface Guidelines
- Material Design guidelines
- Usability testing on device
Timeline
How long this actually takes
Eight to ten weeks for a substantial app across both platforms. Designing one platform and adapting is faster than designing both from scratch, and it is not free — the adaptation is real work rather than a rename. One honest question worth asking before commissioning any of this: does it need to be an app at all? A progressive web app avoids app store review, install friction and dual-platform cost, and for many businesses it is the better answer. We will raise it if your requirements do not genuinely need native.
Pricing model
Fixed-price project
Fixed price by screen count and platform coverage. Designing one platform first and adapting later is a legitimate way to stage the cost.
Questions
Mobile App Design questions
Do we need separate designs for iOS and Android?
Not separate designs — adapted ones. Structure, content, spacing and brand are shared. Navigation, system controls, typography and back behaviour should follow each platform. Shipping one design to both is why some apps feel subtly wrong without users being able to say why.
Should we build an app at all?
Often not. If the requirement is content, forms or a dashboard, a progressive web app avoids store review, install friction and dual-platform cost entirely. Native earns its cost when you genuinely need device capabilities, offline operation or push as a core mechanic. We will raise this before designing.
Why does onboarding matter so much?
Because it is where most installs are lost. A multi-screen feature tour before anyone has experienced anything useful is the default pattern and it performs badly. Getting someone to one genuine outcome quickly, and explaining features when they become relevant, works considerably better.
How do you test app designs?
On a real mid-range device, held one-handed, ideally outdoors. Simulators on a large monitor hide reach problems, contrast problems in daylight and the effect of a slow connection. Almost every serious finding comes from the physical device rather than the prototype on a desk.
Do we need a design system for an app?
If the app will keep growing and more than one person will design it, yes. For a first version with a defined scope, a component set within the design file is enough. Building a full system before the product has settled tends to systematise decisions you are about to change.
What about tablets and larger screens?
Worth deciding early rather than treating as an afterthought. Some apps need genuine tablet layouts; many are fine scaled up. Doing nothing produces a stretched phone interface, which App Store review sometimes objects to and users always notice.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.