# 1 · Flows: the whole path, start to end A flow is the path a person takes to finish one job: book a haircut, reset a password, invite a teammate, change a delivery address. It has a start (often more than one), an end, and many ways to go wrong in between. You tend to build the screens a request names and let the path appear between them. This part makes you design the path first, on paper, where changing it costs nothing. This part assumes you know who it's for and the job (Product thinking W1, W2, or the UI brief lines 1 and 2). --- ### F1 · Name the job, every way in, and what done means to the person **Rule:** Before any screen, write three things. **The job**, in the person's words ("move my haircut to Saturday"), not the system's ("update booking record"). **Every way in**: the menu, a link in an email, a reminder text, a search result, a link someone shared, a bookmark, a redirect after sign-in. **The end**, as the person experiences it: what they have and what they know when it's over. **Why:** People don't start where your first screen is. If you only design the front door, everyone who arrives by the side door lands in a step that assumes things they never saw. **Agent trap:** the request says "a booking page and a confirmation page", so your flow starts at the booking page. Half the real people arrive from the reminder email's "Reschedule" link, straight into the middle, with no idea which booking they're changing. And you define the end as "the booking is saved", when for the person it's "I have a new time and I know it's in my calendar". **Check:** can you list every way in, and say in one sentence what the person has and knows at the end? Does each way in land on a step that makes sense without the steps before it? ### F2 · Write the flow map before you build **Rule:** Write the flow as text, using the template below, before you build any screen. One block per step. Every step says what the person sees and does, where it goes next, where Back goes, what can fail and where that goes, and what happens if they leave. Every decision lists all its answers and where each goes. Show the map to your human with the brief, for a large job. **Why:** A flow held in your head gets its order from whichever file you built first. A written map shows the dead ends, missing branches and odd order while they're still one line to fix, and it gives your human something to correct in one reply instead of after the build. **Agent trap:** you build screen by screen and "connect them up" at the end. The connections are whatever the router made easy: Next goes forward, nothing goes back, and errors go nowhere in particular. **Check:** every step has **Next**, **Back**, **Fails** and **Leaves** filled in, or "none" with a reason. Every place the map points to exists in the map. Every path ends at **End** or **Exit**. No step is unreachable. #### Template: flow map ``` Flow: Person: (Product thinking W1, W2) Ways in: Done: Needs: 1. Sees: Does: -> 2 Back: Fails: -> Leaves: 2. Sees: ... Decision: - -> 3 - -> 2a ... End. Exit. Forks: ``` #### Example: password reset ``` Flow: "I can't get in, let me set a new password" Person: a returning customer on their phone, mid-checkout, a bit annoyed Ways in: "Forgot password?" on sign-in · the reset email · sign-in after 3 wrong tries Done: signed in with a new password, back where they were (their basket) 1. Ask for the email Does: enter email, "Send reset link" -> 2 Back: sign-in, email kept Fails: not a valid email -> 1, field error, email kept Leaves: nothing to save 2. Check your email Sees: "We've sent a link to sam@… It works for 1 hour." · "Send again" · "Use a different email" Fails: no email after a minute -> "Send again"; check spam Note: same screen whether or not the account exists (don't reveal who has one) 3. Choose a new password (from the email link) Does: new password, "Save and sign in" -> End Fails: link expired or used -> "This link has expired" + "Send a new link" -> 2 password too weak -> 3, says what's needed, other fields kept End. Signed in, back at the basket, "Password changed" · email confirms the change, with "This wasn't me" Exit. "Back to sign in" on steps 1–2 ``` ### F3 · Every step has a way forward, a way back and a way out **Rule:** Each step inside a flow has: - **one clear way forward**: the primary action (UI design A2); - **a way back** to the previous step that keeps what they entered (F5), placed as UI design B2b says. The browser's back button must do the same thing: from step 3 it goes to step 2, not out of the flow, and never submits anything again; - **a way out**: Cancel or Close, which says where it goes and what happens to their work. The last step is a step too: it has somewhere to go next (F9). No screen in the flow is a dead end. **Why:** People make mistakes and change their minds. With no way back, they can't fix a typo on the previous step. With no way out, they feel trapped and close the tab, and lose everything. **Agent trap:** a three-step checkout built as one page with steps held in JavaScript state. Back in the interface works, but the browser's back button leaves the checkout entirely, and the basket page now shows empty. Or the final screen says "Thanks!" and nothing else, with no link, no summary and no navigation. **Check:** on every step, use the Back control, the browser's back button and Cancel. Write down where each lands and what's still filled in. Run `checks/wayfinding.js` on every step. **Limit:** this is about steps inside a flow, and focused flows that hide the main navigation. An ordinary page doesn't need a Cancel button: its navigation is the way out. ### F4 · Design the unhappy paths, not only the happy one **Rule:** For every step that takes input or talks to a server, list what can go wrong, and give each one a place in the map: - **wrong input** (an invalid date, a postcode they don't deliver to); - **the system fails** (server error, timeout, payment declined); - **the connection drops**; - **they change their mind** (Back, Cancel, closing the tab); - **they leave and come back later** (J3); - **what they need isn't there** (no slots left, sold out, link expired, already used); - **they aren't allowed** (signed out, wrong account, no permission). Every failure says what happened, keeps their work, and offers a way on: try again, choose another option, or reach a person. How the message itself is written and placed is in UI design C4 and C2b; this rule is about where the path goes. **Why:** You test the happy path because it's the one you built. Real people meet the unhappy ones, and that's the moment they're most likely to give up or call support. **Agent trap:** in a booking flow, someone picks 10:30 on Saturday, fills in their details, and pays, but someone else booked 10:30 a minute earlier. Your map has no branch for it, so they get "Something went wrong" after paying, or a double booking. Or a password reset link that has already been used shows "Invalid token" with no way to send a new one. **Check:** count the **Fails** lines in your map. Every step with input or a network call has at least one, each with a destination. Then cause each failure in the build: go offline in the browser's developer tools, enter bad data, use an old link, force a server error. ### F5 · Never lose what someone entered **Rule:** Everything the person typed or chose survives going back, a failed submit, a timeout, a page refresh, and signing in part-way. The only exceptions are secrets (passwords, card security codes): clear those, and say so. When their work really must be thrown away (cancelling a new draft), say so before it happens and offer to keep it. **Why:** Typing it all again is where many people give up. For someone typing slowly, with one hand, on a phone or with a screen reader, it can be the end of the task. **Agent trap:** the form's values live in a component that unmounts when the step changes, so Back shows empty fields. Or the session expires during checkout, sign-in sends them to the home page, and the basket is gone. Or "Check your email to continue" opens a new tab with a fresh, empty form. **Check:** fill every step with realistic data. Go back two steps and forward again, refresh, submit with the network off, let the session expire and sign in. Is everything still there? ### F6 · Put steps in the order people can answer them **Rule:** Order the steps so each one makes sense with what the person knows by then: - **Show what they get before you ask for effort.** Price, availability or a result first; account, personal details and payment after. - **Ask for each thing when it's needed, and once.** Don't ask for a phone number at sign-up if it's only used for delivery. - **Put anything that could stop them as early as it can be known.** If you don't deliver to their area, or the date is full, say so before they've filled in five steps. - **Let them in before asking them to sign up**, where the product allows (a guest checkout, trying it first). This is often a fork (F7). **Why:** People leave when asked for effort before they know it's worth it. And a "no" at the last step wastes everything they did before it, which feels worse than a "no" at the start. **Agent trap:** you copy the order of the database form or of the request's list. A sign-up flow opens with name, company, role, team size and password before the person has seen anything. A checkout asks for the full delivery address, then says on step 4 that it doesn't deliver to Northern Ireland. **Check:** for each step, write one line: what the person knows when they arrive, and why they'd answer. Find the first moment the system could tell someone "no". Is that the first step that tells them? **Limit:** some things rightly come first: an age or eligibility check, a legal requirement, or a product where the account is the point (a bank). Then say at the start why you're asking and what they'll need. ### F7 · Forks in a flow: ask, don't pick **Rule:** Some flow decisions have more than one right answer, and the right one depends on the product and the human's taste. Treat them as UI design `1-brief.md` Step 3b says: ask once, with the options side by side and what each feels like to the person; recommend one; batch them with the other questions; record the answer in `DESIGN.md`; if the human isn't there, build your recommendation so it's easy to switch, and list it under "Assumed". Mark each fork in the map's **Forks** line. #### Common flow forks | Fork | Option A | Option B | A fits when… | B fits when… | |---|---|---|---|---| | When to ask for an account | **Account first** | **Use first**, account later (guest checkout, save your work to keep it) | The product is useless without one (shared data, money) | People need to see the value before committing | | Email verification | **Block** until verified | **Let them in**, verify later with a reminder | A wrong email causes real harm (payments, security) | Getting started matters more and a typo is cheap to fix | | Getting started | **Guided setup** (a few steps before the product) | **Straight in**, with empty states and a checklist | Nothing works until something is set up | The product is useful at once and setup can happen in context | | Leaving with unsaved work | **Keep a draft** silently and say so | **Ask** "Discard changes?" | Drafts are cheap and private | Half-done work would confuse others, or drafts pile up | | After finishing | **Go to the thing made** (the new invoice) | **A confirmation page** with what's next | The result speaks for itself and they'll act on it | Something happens later (delivery, approval) they need to know about | | Paying for a trial | **Card up front** | **No card** until the trial ends | The human wants fewer, more committed sign-ups | The human wants more people to try it | The fork tables in UI design (`1-brief.md` Step 3b) cover one page or steps, toast or dialog, undo or confirm, and autosave or a Save button. Don't ask those twice. **Why:** a silent pick on a fork is a coin toss from the human's point of view. When it lands the other way, they rebuild a whole flow, not one screen. **Agent trap:** treating the common pattern as the right one. Most sign-ups you learned from block until the email is verified, so yours does too, and the human, who wanted people trying the product within ten seconds, has to ask for it to be taken out. **Check:** every fork in the map is marked **asked** (with the answer) or **assumed** (with your pick), and every answer is in `DESIGN.md`. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - F8 · A step that half works says exactly what happened > - F9 · Design the end: what happened, what's next, how to change it