# 4 · Test: walk it as the person, then let people try it You can't watch a stranger use what you built. You can do the next best things: walk every step as the person would, check the build against the map you wrote, and, when real people will try it, write a test script that finds problems instead of confirming your hopes. A **usability test** is watching real people try to do real tasks with the product, without help, to see where they get stuck. A **cognitive walkthrough** is the version you can do alone: going through each step and asking, from the person's point of view, whether they'd know what to do. Do this before you say done on any flow. Fix what you find before reporting, unless fixing it needs a choice from your human. --- ### T1 · Walk it as the person, step by step **Rule:** Do a cognitive walkthrough in the rendered build, not the code. Take the person from Product thinking W1, with realistic data, from a cold start: a fresh tab, signed out, and from each way in (F1), not only the front door. At every step of the main path and of each unhappy path (F4), answer four questions as that person: 1. **Will they know what to do here?** Does the step match what they're trying to do at this point? 2. **Will they see how to do it?** Is the control visible, without hover or scrolling or knowing where to look? 3. **Will they match the control to their goal?** Is it labelled in their words (N1)? 4. **After acting, will they know it worked**, and what comes next? Every "no" or "maybe" is a finding (T5). Product thinking K1 walks the whole job once; this is the same walk, slowed down to one step at a time, and repeated on the paths where things go wrong. **Why:** You know what every label means and where every button is, because you put them there. Asking the four questions forces you out of your own head and into theirs, at the exact step where a person would stall. **Agent trap:** walking it as yourself. You know "Workspace" holds billing, so question 3 passes. Or you walk only the happy path, with the test card that always works, so the declined-card step is never seen. **Check:** a short table for each path: step, the four answers, and a fix for every "no". At least one unhappy path walked for every step that can fail. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - T2 · Check the build against the map > - T3 · A test script gives a goal, never the route > - T4 · Don't lead the participant > - T5 · A finding is what someone did, at a named step ## Template: usability test script ``` Test: Round: <1, 2…> Who: <5 people like Product thinking W1; how they'll be found> Set up: Device: , Opening (read out): "Thanks for helping. We're testing the product, not you: there are no wrong answers. Please think aloud as you go: what you're looking at, what you expect, what's confusing. I can't help during the tasks, but I'll answer questions at the end." Task 1 · warm-up Say: "" Success: Watch: Task 2 · core job Say: "..." Success: ... Watch: ... Task 3 · something goes wrong (seeded) Say: "..." Success: Watch: If they ask for help: "What would you expect?" / "What would you try?" If stuck for 2 minutes: note it, then "Let's move on to the next one." After the tasks (ask, don't lead): - "What was that like?" - "Was there a moment you weren't sure what to do?" - "What did you expect to happen when you ?" Findings (one line each): ``` --- ## Review: before you say done - [ ] The flow map exists and every step has Next, Back, Fails and Leaves (F2). - [ ] Every way in lands somewhere that makes sense on its own (F1). - [ ] Back, the browser's back button and Cancel work on every step and keep what was entered (F3, F5). - [ ] Every failure in the map was caused in the build and recovered from (F4). - [ ] Steps that do several things have a clear part-done screen, and retrying is safe (F8). - [ ] The end says what happened, what's next and how to change it (F9). - [ ] Every page says where you are, and a deep link opened cold still makes sense (N3). - [ ] Going back to a list keeps filters and place (N4); main views have their own URL (N7). - [ ] Empty account and busy account both walked (J1); every outgoing message's link opened (J4). - [ ] Every way in has a way out of about the same length (J5). - [ ] `checks/wayfinding.js` run on every step, at phone and desktop width. - [ ] Walkthrough done on the main path and the unhappy paths, with the four questions (T1). - [ ] Every fork is marked asked or assumed, and answers are in `DESIGN.md` (F7). ## Report Add to your usual report (UI design `5-review.md` Step 3): 1. **The flow map**, or a link to where it's saved. 2. **Unhappy paths covered**, and any you didn't build or couldn't test. 3. **Forks**: asked (with the answer) or assumed (with your pick). 4. **Findings**, marked predicted (your walkthrough) or observed (people), with what you fixed and what's left.