# ihumane · UX design · v0.1 You are an agent about to design or build something a person moves through: a sign-up, a checkout, a booking, onboarding, a settings change, a section of a product with several pages. This module is about the path between and around the screens. It is written for you, not for a human reader. The UI design module covers each screen on its own. Product thinking covers who it's for and what problem it solves. This module covers how the person gets from where they start to the job done, and what happens when they don't go the way you expected. Read this file fully. Read the other files when the step below tells you to. --- ## Why this exists You build one screen at a time, usually the ones the request names. Each screen can look finished while the path between them was never designed. That gives four failures: 1. **Dead ends.** A screen with no next step, an error with no way out, a "Thanks!" page that doesn't say what happens now. 2. **No way back.** Back loses what they typed, there's no Cancel, or the browser's back button throws them out of the flow. 3. **Only the happy path works.** The card is accepted, the email arrives, the connection holds. The first real person who does something else gets stuck. 4. **Lost people.** Steps come in an order that makes no sense to them, pages don't say where they are, and links from emails land somewhere unrelated. Each of these is a person giving up half-way through something they wanted to do. Your goal is a path that works from every place they might start to the end, including the ways it goes wrong. --- ## Size the job first | Size | Looks like | Do | |---|---|---| | **Small** | One step added to an existing flow, a change to one screen inside a flow, a new menu item or link, a new email that links into the product | Name the flow it sits in. Write a three-line note: **From:** where people arrive · **Change:** what's different · **Then:** where they go next, and where they go if it fails. Check the way forward, back and out of the step you touched (F3), and its failure path (F4). Ask **0** questions unless you hit a fork (F7). Walk that part once as the person (T1). | | **Large** | A new flow (sign-up, checkout, booking, onboarding), a new section or product navigation, anything that spans sessions, devices or emails | The full workflow below, every step. | A single screen with no path into or out of it isn't UX design work: use the UI design module. If unsure between small and large, treat it as small, and say in your report that the whole flow needs mapping before more is built. --- ## The workflow For large jobs, do these in order. For small jobs, see the table above. | Step | What you do | File | |------|-------------|------| | 0. Remember | Read `DESIGN.md` and `PRODUCT.md` if they exist. Follow the flows and patterns already recorded. | UI design `6-memory.md` | | 1. The job | Take the person and their job from Product thinking (W1, W2) or the UI brief. Name where they start and what "done" means to them. | `1-flow.md` F1 | | 2. Map the flow | Write the flow map before any screen: steps, decisions, failure branches, exits. | `1-flow.md` F2–F9 | | 3. Forks | Collect every pattern fork in the map and ask about them once, with a recommendation. | `1-flow.md` F7 | | 4. Structure | Decide where things live, what they're called and how people find their way back. | `2-structure.md` | | 5. Journey | Think past one sitting: first visit and return, emails and other messages, interruptions, onboarding, changing their mind. | `3-journey.md` | | 6. Build | Build the screens with the UI design module. | `ui-design/START.md` | | 7. Test | Walk it as the person, step by step, then check the build against the map. Write a test script if people will test it. Fix before reporting. | `4-test.md` | | 8. Remember | Save the flow map and the answered forks in `DESIGN.md`, so the next agent extends the flow instead of rebuilding it. | UI design `6-memory.md` | **Questions:** the forks you ask in step 3 share the budget of the brief: at most 3 questions in one message, each with your default (UI design `1-brief.md` Step 3). Don't open a second round. --- ## The format of every rule Rules in this module use the same fields as the other ihumane modules: - **Rule:** what to do, as specifically as possible. - **Why:** what happens to a real person if you don't. This lets you handle cases no rule covers. - **Agent trap:** the specific way agents like you get this wrong. - **Check:** how to verify it, ideally something you can run, click or count. - **Limit:** where the rule stops, when it could be applied too far. Rules from other modules are named by module and ID, for example "UI design B2b" (in its `3-humans.md`) or "Product thinking W1". Runnable checks live in `checks/`. Run them on the rendered page, on every step of the flow; don't trust your reading of the code. | Check | Finds | |---|---| | `checks/wayfinding.js` | Pages that don't say where you are or give a way back: no clear heading, a generic page title, navigation with no current item, a breadcrumb that links to itself, a step with no Back, a page with no way out | --- ## Five rules that matter most If you remember nothing else: 1. **Map the path before the screens.** Every step, decision, failure and exit, written down before you build. (F2) 2. **Every step has a way forward, a way back and a way out.** The end included. (F3) 3. **Design what happens when it goes wrong.** Declined, timed out, cancelled, expired, sold out, offline. (F4) 4. **Never lose what someone entered.** Not on Back, not on an error, not after sign-in, not after a break. (F5, J3) 5. **Walk it as the person, step by step, in the build.** From a cold start, on the unhappy paths too. (T1) --- ## Precedence The human's instructions, an existing `DESIGN.md` and the project's own flows come before this module. If a rule here conflicts with them, follow them, and mention the conflict once in your report. When the person knows how their users move through the product (from support tickets, analytics or watching them), that beats any rule here.