User flows, wireframes and every state of a screen

Before a screen is drawn, you need to know the path a person takes through it and every state it can be in. User flows map the path, wireframes test the structure, and interaction design decides how the interface responds along the way.

Skipping this step is the most common reason a polished design falls apart in build: the happy path looks great, and then nobody has designed what happens when the network drops or the list is empty.

Three kinds of flow diagram

A simple notation

Any notation works if the team shares it. This one is common and easy to sketch by hand or in FigJam:

( Start / End )     rounded shape
[ Screen ]          rectangle
< Decision? >       diamond, with Yes and No branches
{ System action }   an API call, an email sent
──▶                 direction of travel

Example: creating a database

A cloud console where someone creates a managed database shows why flows matter. The work is long-running and can fail after the user has already left the form, so the flow has to cover more than the form itself.

(Start: Dashboard)
   ▼
[Create database] ──▶ [Choose engine: Postgres / MySQL / MongoDB]
   ▼
[Configure: version, replicas, storage]
   ▼
<Valid?> ── No ──▶ [Inline errors] ──┐
   │ Yes                             │
   ▼                  ◀──────────────┘
[Review and confirm]
   ▼
{Provision} ──▶ [Status: Provisioning…] ──▶ <Ready?>
                                              │ Yes        │ No
                                          [Success]   [Error + Retry]
                                              ▼
                                            (End)

Draw the happy path first, then walk it again asking what can go wrong at each step:

• What if a field is invalid, or the request times out?
• What if the user doesn’t have permission for this action?
• What if the network drops halfway through?
• What happens on Back? Is the form kept?
• If the user leaves midway, is a draft saved?
• What does the screen look like the very first time, with nothing in it?

Wireframe fidelity

• Use real content, not lorem ipsum. Real names, long labels and actual numbers are what break a layout, and it is better to find out in a wireframe.
• Keep mid-fidelity in greyscale. Without colour, stakeholders comment on structure instead of debating the shade of a button.
• Start from components. When a design system exists, even a mid-fidelity wireframe can use its real components, and the step to high fidelity becomes small.

Information architecture

Information architecture (IA) is how content is organised and labelled. Three tools cover most of the work:

• Card sorting. Users group topics into categories that make sense to them, which shows how they expect the content to be organised.
• Tree testing. Users try to find items in a text-only version of the menu, which shows whether the labels and hierarchy work.
• Sitemap. A diagram of every page and how they connect, used to agree on the structure.

The five dimensions of interaction design

Interaction design (IxD) is often described in five dimensions, a framework that grew out of work by Gillian Crampton Smith and Kevin Silver:

1. 01Words: labels, button text, messages.
2. 02Visual representations: icons, images, typography.
3. 03Physical objects and space: mouse, touch, keyboard and the device itself.
4. 04Time: animation, duration and how long the system takes to respond.
5. 05Behaviour: how the system reacts to people, and how people feel in return.

Every state of a screen

A screen is not one design; it is a set of states. Listing them up front is one of the cheapest ways to avoid surprises in build.

Common interaction patterns

• Progressive disclosure. Show the essentials and tuck rare options behind “Advanced settings”.
• Inline validation. Check a field when the user leaves it (on blur), not on every keystroke, so nobody is told off while still typing.
• Optimistic UI. Update the screen before the server confirms, and roll back with a clear message if the request fails.
• Undo or confirm. If an action can be reversed, do it at once and offer Undo in a toast. If it can’t, ask for confirmation first.
• Bulk actions. When rows in a table are selected, an action bar appears with what can be done to all of them.

Next in the series

A wireframe sets the structure; visual design makes it readable. Part 8 covers hierarchy, type scales, spacing on a 4 and 8 point grid, colour palettes and layout grids.