journey-mappinglisted

# Journey mapping Before you design a new surface or audit an existing one, you must know where the user came from. Screens designed in isolation leak copy, voice, and chrome appropriate to one surface type onto another — and the bug is invisible to per-screen review. The canonical shape: the onboarding flow greets the user with "Hi — I'm your assistant, let me show you around" (correct); weeks later a daily home banner reuses that same greeting (wrong — the user has known the assistant for weeks; re-introducing is condescending). The screen reads fine alone; only the *journey* exposes the failure. Run this at **both** moments and the verdict is binding at both: - **Design time** — Section 0 of any spec, before proposing a surface. - **Audit time** — first action before grading any captured surface, before any per-screen verdict. Rerunning against the *implemented* surface catches the case where implementation drifted from spec (the spec's intended surface-type classification no longer matches what shipped). Other failures it catches that per-screen review cannot: a "Get started" call-to-action on a daily-driver, re-introducing a concept the user reached *after* using it, apology copy on a success state, tone hopping mid-flow (intimate second-person step 3 → corporate third-person step 4), and a hard cut between two arcs with no transition surface. ## Procedure ### Step 1 — Enumerate prior surfaces Starting from the user's **first interaction with the product** (sign-up