How do you design a mobile app?

In short

App design isn’t a shrunk-down version of a desktop screen. A phone has no mouse, and so no menu that opens on hover. The user taps with a finger, and a finger is a much coarser tool than a mouse pointer.

When I look at a mobile screen, I ask four questions. Are the targets big enough for a finger? Are the main tasks where the thumb can reach? What happens when the task is interrupted? What does the screen show when the network slows down?

Then there are the platform rules. Apple and Google each publish their own design guidelines. And users bring habits from the other apps on their phone. An app that follows those habits doesn’t have to be learned first.

• Touch targets: 44 × 44 pt on iOS, 48 × 48 dp on Android. On the web, at least 24 × 24 CSS pixels.
• Navigation: a few main sections, at the bottom and always visible.

What is different on a phone

At a desktop the user usually sits and has both hands free. On a phone none of that is certain. Most of my design decisions follow from this difference.

Tapping

The finger covers part of the screen, and the user can’t see the point it touches. Small, tightly packed targets therefore lead to mis-taps. There is no hover either, the state when the pointer sits over an element. A hint that appears with the mouse on desktop never appears on a phone.

The most common example in my audits is a small trash icon in a list row. The icon is small, and a tap on the row opens the detail. The user wants to delete and ends up in the detail, or the other way round.

One hand

Someone standing on a bus holds the phone in one hand and uses it with the thumb. The top corners are then the hardest to reach. I put frequent actions in the lower half of the screen.

Putting a main button such as payment confirmation in the top right corner forces the user to take the phone in their other hand. Put the same button full width at the bottom and it can be pressed one-handed.

Interruption

Mobile use happens in pieces. A notification arrives, or the user gets off at their stop. If the form is empty when they come back, the work starts over.

That is why I split long forms into steps and save the input on the device. When the user comes back, they see the step where they stopped. With long tasks such as a loan application or a government form, you feel the difference immediately.

Keyboard and forms

When the keyboard opens, it covers a large part of the screen. A “Next” button at the bottom can disappear behind it. When designing a form, I draw the open-keyboard state as a screen of its own.

Opening the right keyboard is a design job too. The phone number field brings up the number pad, the email field the keyboard with @. A wrong keyboard means a few extra taps in every field. I describe this in the keyboard in mobile forms pattern.

I leave autofill on. For fields such as address or one-time code, the phone can suggest the value itself. Don’t break these fields with custom components.

Network

In a lift or on the subway, the phone loses its connection. The design has to cover that moment too. I draw “Loading” and “No connection” as screens of their own and put a “Try again” button in the second.

The most dangerous moment is a dropped connection in the middle of a transaction such as a transfer. If the user doesn’t know whether it went through, they press the button again. The screen has to state the status clearly and prevent the second press.

Touch target size

A touch target is the area the user can press with a finger. The visible icon can be small; the tappable area is larger. Three sources give three different sizes for that area.

• 24 × 24 CSS pixels. WCAG 2.2, 2.5.8 (AA)
• 44 × 44 pt. Apple, default on iOS
• 48 × 48 dp. Android and Material

Figure: the squares on this page are drawn in CSS pixels. pt and dp are different units; I only put them side by side to give an idea.

Apple: 44 × 44 pt

The accessibility section of Apple’s Human Interface Guidelines has a table. According to the table, the default size of a control on iOS and iPadOS is 44 × 44 pt and the minimum is 28 × 28 pt. Apple recommends meeting the recommended minimum size on every platform.

The same section also gives spacing between controls. It recommends about 12 pt around bezeled elements and about 24 pt around the visible edge of elements without a bezel. The aim is to lower the risk of the user hitting the wrong element.

Android and Material: 48 × 48 dp

The Android Developers documentation recommends a touch area of at least 48 × 48 dp for every interactive element of a touch interface. It adds that larger is better. The Compose documentation ties this 48 dp limit to Material Design’s accessibility rules.

Ready-made Material components bring this size with them. An interactive checkbox, for example, reaches at least 48 dp through extra padding. If you build your own component, you have to set the size yourself.

WCAG 2.2: 24 × 24 CSS pixels

For the web and for apps with web views, the W3C’s WCAG 2.2 standard applies. Success criterion 2.5.8 Target Size (Minimum) is level AA. It requires a target to be at least 24 × 24 CSS pixels.

The criterion has five exceptions. It doesn’t apply when small targets have enough spacing, when another suitable control performs the same function, or when the target is a link within a sentence. Controls whose size is set by the browser and cases where the presentation is essential are exempt too.

There is also a stricter criterion: 2.5.5 Target Size (Enhanced). This level AAA criterion requires 44 × 44 CSS pixels. The W3C recommends aiming for this stricter criterion for important links and controls.

Which size to use?

For me, 24 pixels is the floor and 44 and 48 are the goal. In a native iOS app I use 44 pt, on Android 48 dp. In a web-based or cross-platform app I pick 48, because it sits above both platforms. More on this in the touch target pattern.

When a screen is full, I first try to reduce the tasks on it before shrinking icons. Making targets smaller is usually the answer to the wrong question.

The difference between iOS and Android

The rules of the two platforms are similar but not the same. Users don’t switch from iPhone to Android every day, so they expect the habits of their own phone.

Topic	iOS	Android
Touch target.	44 × 44 pt by default.	At least 48 × 48 dp.
Bottom navigation.	Tab bar, floats above the content.	Navigation bar, three to five destinations of equal importance.
Back.	Standard back button, at the top.	System back gesture or button.
Title.	Large title, shrinks as you scroll.	Title in the top bar.

How back works

The biggest difference is in back behaviour. Apple recommends using the standard back button and not writing “Back” on it. Users know this button takes them one level back in the information hierarchy.

On Android, back is the system’s job. According to Android Developers, most devices have a physical, software or gesture-based back function. That is why the documentation advises against adding a back button of your own in the app in most cases.

Android 13 introduced the predictive back gesture. When swiping back, the user sees a preview of where they will return. From Android 15, these system animations run by default in apps that opt in to the support.

Titles

According to Apple, the title helps users confirm where they are in the app. Apple recommends keeping titles under 15 characters to leave room for the other controls. The large title turns into the standard title as soon as the user starts scrolling.

On Android, the title sits in the top app bar. According to Android Developers, this bar usually carries a title.

The rule is easy to break with labels that describe too much. “Recent account activity” has 23 characters; “Activity” has only 8. I write titles short from the first draft and let the screen’s content add the detail.

Shared or separate design?

In teams with a limited budget, I like to take one design to both platforms. Brand and content stay the same. Navigation and back behaviour follow each platform’s own language.

Navigation patterns

Navigation tells users where they are in the app and where they can go. On phones I mainly use three patterns: the bottom tab bar, stack navigation and the menu.

Bottom tab bar

The app’s main sections sit at the bottom of the screen and are always visible. Apple recommends using the tab bar for navigation, not for actions. For an action on the screen, Apple recommends the toolbar.

Apple also recommends keeping the number of tabs small and avoiding a “More” tab for overflow sections. Content in hidden tabs is harder to reach. On Android, the navigation bar is recommended on compact screens for three to five destinations of equal importance.

There is a visibility rule too. According to Apple, users can forget which section they are in if the tab bar is hidden. The only exception is a modal view that temporarily covers the tab bar.

Stack navigation

The user goes from the list to the detail, from there to a sub-detail, and back out with back. Going from the list of accounts to the receipt of a single transaction in a banking app is an example of this pattern.

Here I watch the depth. If the user is four or five screens deep, they must be able to get back to the main section with one tap. A tap on the tab at the bottom does that.

Hamburger menu

The menu behind the three-line icon saves space but has a price. In the 2016 NN/g study, mobile users used hidden navigation in 57% of cases. In the design that combined visible and hidden navigation, the figure was 86%.

The same article recommends showing the main links visibly if there are four or fewer. I don’t hide main sections behind the hamburger either. Only rarely used pages such as settings or legal texts go into the menu.

In the example below you see the same screen on two platforms.

One screen, two platforms

iOS

‹Back

My cards

• Debit card•••• 4821
• Credit card•••• 0937
• Virtual card•••• 5512

OverviewCardsPayProfile

Android

My cards

• Debit card•••• 4821
• Credit card•••• 0937
• Virtual card•••• 5512

OverviewCardsPayProfile

◁ Back: system gesture or button

The same banking screen on two platforms. Choose iOS or Android: the tab bar, back and title change. The screens are examples and don’t come from any real app.

Content and colours stay the same on both screens. What differs is the shape of the tab bar, the back behaviour and the position of the title. When users see the shape of their own phone, they don’t have to think about what to do.

How do you design a mobile app?

1. 1. TaskWhat the user gets done on the phone
2. 2. FlowOrder of the screens, on paper
3. 3. WireframeOne-handed, at real size
4. 4. PrototypeOn the phone, with a finger
5. 5. TestWith network and interruptions

Figure: my mobile design process in short. The seven steps below describe the same process in more detail.

1. Write down the task. What task does the user want to get done when they open the app? “I pay my bill” is a task; “finance app” isn’t. I write down the three most important tasks in one sentence each.

2. Draw the flow on paper. For each task I draw the order of the screens as boxes. This is where the information architecture decisions are made: which section becomes a tab, which a sub-screen?

3. Make the wireframe at real size. In the wireframe I keep the frame at phone width. I draw targets at 44 or 48 units from the start. Enlarging them later throws the layout off.

4. Try the prototype on the phone. A prototype that looks good on the computer feels quite different in the hand. I open the prototype on the phone and use it one-handed and standing up.

5. Draw the difficult states. Empty list, loading, no connection, error. Each is a state of its own and goes to development as its own drawing.

6. Test with users. I give a few people the task and watch how they do it on the phone. I note where they hesitate and where they mis-tap.

7. Adapt to the platform. I go through the shared design separately for iOS and Android. Back behaviour and the navigation bar part ways at this step.

If you are just starting with app design, don’t skip the first two steps. It is tempting to start drawing screens right away. But if the task and flow aren’t clear, beautiful screens serve the wrong work.

Common mistakes

Shrinking the desktop design. Stacking a three-column panel into one column isn’t mobile design. On a phone you have to decide again which task comes first.

Putting the main action in the top corner. If buttons such as Save or Send stay in the top corner, they are hard to reach with one hand. The main action belongs near the thumb.

Navigating with icons only. Not everyone knows what an icon without a label does, so I put a short text under the icon in bottom tabs.

Forgetting empty and error states. In the design file every list is full. In real life a new user’s list is empty, and that screen shapes the first impression.

Breaking the platform’s back behaviour. If the system back gesture on Android leaves the app unexpectedly, the user loses their work. If there is unsaved input when leaving a form, the app should ask first.

Testing only on new phones. The team usually uses new, fast devices. Some users come with a small, old phone and a weak connection.

My note

The problem I find most often in mobile audits has to do with interruption. The user leaves the app, comes back and starts over. The team never sees this at the desk, in a test without interruptions.

In second place come connection states. The loading icon spins forever, or an error message never appears. I count these screens as part of the real design and draw them in the first draft.

And this is what I recommend: use the design on your phone once a week, on the subway or while walking. Most of the problems you don’t notice at the desk show up there.