PMaker home
The main path is three to five steps long; every step needs an exitSet the start pointWhere the user enters; a different start means different knowledgeList the main pathEach step on the happy path, kept to three to five stepsMark decision pointsAsk if a branch forms here, and draw both routesMore than five steps is a signal to split the task or merge stepsAdd fallbacksInterrupted, failed, or without permission—each lands somewhereDraw return pathsEvery endpoint must lead back to a stable place, no dead endsAfter the path, add an emotion line and the design decisions surface on their own

The main path is only three to five steps, but every step has exits hanging under it—where they go when it breaks, and whether they can pick up where they left off.

Map the User Journey

Draw one complete task as a line: where users enter, how many steps, and where each step can go wrong.

Draw one complete task as a line: where the user enters, how many steps they take, where each step might branch, and what happens when they can't continue. A journey map turns "the user needs to get something done" into a picture you can point at, and it's the most direct way to find where a flow breaks. journey-map

What you'll run into:

  • The happy path works, but any unexpected move dead-ends
  • A user quits halfway through a form and comes back to find everything gone
  • You have AI build screen by screen; every screen is fine, but chained together a step is missing

How to draw it

The main path is the happy path—the steps when everything goes right—and it should stay within three to five steps. More than five is a signal: either the task should be split into two, or some steps can be merged or skipped with sensible defaults. The drawing order is fixed:

  1. Set the start point. Where does the user come in: home page, search results, a push notification, or a link someone sent them? A different start means they know different things, and the path that follows may differ.
  2. List the main path. Each step on the happy path, one after another until the goal.
  3. Mark decision points. After each step, ask: does a branch form here? Mark it with a diamond and draw both routes.
  4. Add fallbacks. At every step ask: what if they leave halfway, what if it fails, what if they lack permission? Each failure lands somewhere different.
  5. Draw return paths. Every endpoint must lead back to the start or some stable place. No dead ends.

The happy path is the one that goes smoothly, but the experience is really decided by what hangs underneath it. Take the path "pick client — select records — confirm amount — generate statement." Each step has an exception under it: too many clients to find means search and sorting by recent activity; getting interrupted mid-selection means the checked items must survive; a dropped connection means retry without losing the draft. For every step ask three questions: does it branch here, where does the user go if they leave, and how does this endpoint return to a stable place.

Where branches come from

Four places tend to sprout branches. Ask each one as you draw:

  • Different identity. Logged in or not, free or paid, what role. The same button can produce different results for different people.
  • Different data state. First-time or returning user, whether history data exists, what state the current object is in.
  • Operation fails. Network drops, validation fails, permission denied, concurrent edits. Each one lands somewhere different.
  • The user leaves midway. Switches away, closes the page, gets a call. Can they pick up where they left off when they come back?

The last one matters most on mobile. Assume the user will be interrupted at any moment; then every intermediate result must be preserved. That judgment changes your data design directly, because you need somewhere to store the draft.

Add an emotion line

Once the path is drawn, note the user's state under each step: anxious, hesitant, afraid of making a mistake, wanting to be done. That's what an experience map is.

Step What they're thinking So this step should
Pick client Too many clients, annoying to find Support search, sort recent ones first
Select records Don't miss any—starting over is awful Show count and total, support select-all
Unconfirmed records Leaving means reselecting everything Handle in place, or keep the checked state
Generate statement Will the format make sense to my client Preview first, send only after confirmation

The emotion column is not literary decoration—it directly produces the design decisions in the third column. If you can't write the emotion, you usually don't know the scenario well enough yet. Every branch and exception on the path becomes a state checklist once it lands on a real component, and the emotion column itself comes from writing concrete scene anchors.

References

  1. Journey Mapping 101 — Nielsen Norman Group