How to design an app, screen by screen

People who have never designed an app start with the welcome screen, then the sign-up screen, then the home screen, and run out of energy before the screen that does anything. Designers start at the other end: the one screen where the job gets done, then work outward until there is a way in and a way back. Here is that method, screen by screen, with the rules that keep a first app from turning into a maze.

1. Start with the screen that does the job

Write down the job your app does in one sentence, then design the screen where that sentence comes true. For a bookings app it is the diary for today. For a club app it is the noticeboard. For a menu app it is the menu. Not the splash screen, not sign-in, not settings.

This screen gets the most time because it gets the most use. Everything else exists to get people here and back.

2. One screen, one purpose, one main action

Every screen answers one question and offers one main thing to do. The diary shows today’s bookings and lets you add one. The booking screen shows one booking and lets you change it. If you find yourself adding a second big button, you are looking at two screens.

The trap: the screen that does everything, because it saves a tap. It costs ten. People read a screen by scanning for the one thing they came for, and a screen with six equal things has no one thing.

3. Lists open to details, details go back to lists

Most apps are the same two shapes repeated: a list of things, and one thing. Bookings open to a booking. Members open to a member. Dishes open to a dish. Design the pair together, and make the detail screen say where it came from, with the phone’s own back button, in the phone’s own place.

Do not invent your own back arrow. iPhone and Android each have one, in a position people’s thumbs already know. A custom one is a small, permanent tax on every user.

4. Tabs for places, screens for steps, sheets for quick things

Three kinds of movement cover almost every app, and the phone gives you all three:

• Tabs at the bottom for the three to five places people switch between all day: Diary, Clients, Services, Profile. Never more than five, and never for actions.
• Screens that slide in for steps: a list to a detail, a detail to an edit.
• Sheets that rise from the bottom for quick things that should not take you away: a filter, a date picker, a confirm.

Pick the wrong one and the app feels wrong in a way users cannot name. A settings page as a tab, a confirm as a full screen, a filter as a new place: each is a common first-timer tell.

5. Stop at five, then draw the arrows

Five screens is enough for a first app that does one job: the main screen, one detail, one add-or-edit form, one list of people or things, and a profile or settings. Stop there even if you can think of a sixth. Then draw the arrows between them: which tap opens which screen, and what kind of movement it is. The arrows are the part most first designs skip and most first apps get wrong, because without them a set of screens is a slideshow.

If you want the method with the rules already built in, the App Builder starts from a working app with its tabs and screens in place, and every arrow you draw says whether it opens a screen, raises a sheet or switches tab. Pick the starter closest to your job, open its main screen, and make that one yours first.