Design for how the phone is held
A phone app is used with one hand, in short sessions, often while the person is doing something else, and sometimes on a weak connection. Write down the one job people open the app to do, and design that path first. Everything else sits behind it.
Thumb reach
On a phone held in one hand, the thumb reaches the lower middle of the screen easily and the top corners poorly. Put the primary action and the main navigation near the bottom, keep actions that delete or cancel away from where the thumb rests, and do not hide an essential control in a corner.
Touch targets
Apple's Human Interface Guidelines suggest controls of at least 44 by 44 points, and Google's Material Design suggests 48 by 48 density-independent pixels. Treat those as a floor. The tappable area can be larger than the visible icon, and neighbouring targets need space between them so a thumb does not hit the wrong one. Every gesture, such as swipe to delete, needs a visible button as an alternative.
Navigation patterns and when each fits
Choose navigation by how many top-level places the app has and how often people move between them.
| Pattern | Fits | Watch out for |
|---|---|---|
| Bottom tab bar | Three to five top-level places that people switch between often | More than five tabs crowd the bar and shrink the targets. Put a label under every icon. |
| Stack (drill-down) | Moving from a list to a detail and back | Make the way back obvious and keep the person's place in the list. |
| Navigation drawer | Many secondary places that are rarely visited | Hidden destinations are used less. Keep the main journey out of it. |
| Modal or bottom sheet | A focused task that returns to where the person was | Always show how to close it, and do not stack sheets on sheets. |
Rule of thumb: if you can name the three places people visit most, they belong in the bottom bar. Everything else can sit one level deeper.
iOS and Android conventions: what to follow and what to share
People bring habits from the phone they own, so a screen that fights those habits feels wrong even when it looks good. Share your brand, your content and your flows across both platforms. Follow the platform where the behaviour is expected:
- Going back. iOS users expect a back button at the top and a swipe from the edge. Android users expect the system back gesture or button to work on every screen and to step back through the app before it closes.
- System controls. Date pickers, share sheets, switches and permission dialogs look and behave differently on each platform. Use the system ones when you can.
- Gestures. Do not add a gesture that collides with a system one, such as the edge swipe for back.
A framework that draws its own interface, such as Flutter, turns these differences into decisions you make on purpose. Record each one in the design system; the build side is covered in iOS and Android development.
Onboarding and permissions
Show the value before you ask for anything. A first run of two or three screens at most, a visible skip, and sign-up deferred until the person needs an account keep people moving. If an account is required, say why and offer the quickest way in, such as a one-time code.
Ask for permissions in context
Ask for the camera when someone taps to scan, and for location when they search nearby, not at first launch. Put a short screen of your own before the system dialog that explains the benefit, because the system dialog is hard to get a second chance at. Notifications follow the same rule: ask after the app has proved useful.
Design the refusal
Some people will say no. Design what the screen does when access is denied: a clear message, an alternative such as typing an address, and a link to the system settings.
Offline, loading and error states
A connection that drops in a lift, a car park or between cities is normal. Design these states as part of the product, not as leftovers:
- Empty. What a list shows before it has content, with the next step.
- Loading. Skeleton screens or placeholders that keep the layout steady, instead of a spinner over a blank page.
- Offline. Show the last data you have, say how old it is, and say which actions will wait.
- Error. Say what happened in plain words and what to do next, and offer a retry. Never show a raw code.
Imagine a delivery app where a driver marks a parcel as delivered in an underground car park. The app saves the action, shows "waiting to send" and sends it when the connection returns. Agree that behaviour with engineers before the build.
Accessibility on a phone
Phones ship with accessibility features that many people rely on, and the design has to work with them.
- Text size. Dynamic Type on iOS and font scaling on Android can enlarge text well past the default. Test the layout at the largest sizes, let text wrap and avoid fixed-height containers.
- Screen readers. VoiceOver on iOS and TalkBack on Android read labels aloud. Every control needs a meaningful label, a role and a sensible reading order.
- Contrast and colour. Meet the contrast ratios in WCAG, and never use colour alone to show an error or a state.
Keep contrast pairs, focus styles and the minimum target size in your design system, so nobody has to remember them screen by screen.
Mirroring for Arabic and right-to-left
In an Arabic app the whole layout reads from the right. Native iOS and Android components can mirror themselves when the device language is right-to-left, but custom components, icons, images and gestures need your own decisions.
- Mirror the order of tabs, the back arrow, progress bars, sliders and swipe directions.
- Keep logos, clocks, check marks, maps and media controls as they are.
- Choose Western or Arabic-Indic digits once for the product and apply them everywhere.
- Give the Arabic font a taller line height and test with long names, because Arabic strings can run shorter or longer than the English.
Design the Arabic screens as their own frames, not as a flipped export. The detail is in our page on Arabic and RTL design.
Prototyping and testing on real devices
A prototype viewed on a laptop hides most of what matters on a phone. Build a clickable prototype in Figma and run it on real phones early, so people feel the reach, the scroll and the transitions. Then test in conditions that match real life:
- Complete real tasks with one hand, standing and walking.
- Use a small phone, a large phone and an older, slower Android device.
- Try bright light, the largest text size and a screen reader switched on.
- Run the Arabic version with native readers, using long and mixed-direction text.
Tools such as Maze can test a prototype remotely, but they do not replace watching someone use a real build. Repeat the tests on the first working builds.
Handoff to engineers
Handoff works when engineers receive decisions, not pictures. For each screen we provide:
- Components and tokens from the shared design system, named the same in Figma and in code.
- Every state: default, pressed, disabled, loading, empty, offline and error.
- Layout rules instead of fixed sizes: how the screen behaves on small and large phones, in landscape, with the keyboard open and around notches and the home indicator.
- Motion notes: what moves, for how long, and what happens with reduced motion.
- Vector assets, an icon set with a mirrored flag on each icon, and copy in both languages, including the longest strings.
Designers and engineers review the same build together at the weekly demo, so gaps show up while they are still cheap to fix. Our mobile development work follows the same tokens, whether the app is native, Flutter or React Native.