How to Decompose a Journey Into Stages Without Faking the Boundaries

A journey stage should mark a shift in what the customer is trying to accomplish or how they feel about accomplishing it — never a shift in which screen, page, or department they happen to be touching. Slice by screens and you get a wireframe with extra steps. Slice by intent shifts and you get a map that predicts behavior.

Draw a stage boundary wherever the customer's underlying question changes — from "should I?" to "which one?" to "did this actually work?" — not wherever your product's screen changes. Most usable journey maps land between five and seven stages. More than that, and you're probably mapping steps, not stages.

What a Journey Stage Actually Marks

A stage is a chapter of shared intent: the customer wants roughly the same thing at the start of the chapter as at the end of it. A step, by contrast, is a single task inside that chapter — filling in an address, choosing a shipping method — and a touchpoint is one moment of contact within a step.

Most first-time journey mappers conflate three different units of analysis, and the confusion shows up the moment they try to draw boundaries.

• Touchpoint — a single moment of contact: a checkout page, a confirmation email, a support call.
• Step — a sequence of touchpoints that completes one task: entering an address, choosing a shipping option, submitting payment.
• Stage — a cluster of steps unified by one underlying customer intent, from the moment that intent forms to the moment it resolves.

If you haven't yet separated these three, our complete guide to customer journey mapping walks through how stages, touchpoints, and emotion sit on the same map without collapsing into each other. The operational detail behind each touchpoint — who on your team handles it, which system fires — belongs to a different artifact; see service blueprint vs journey map for where that line sits.

Alan Cooper's goal-directed design work, laid out in About Face, makes the same argument for interface design generally: design for what someone is trying to accomplish, not for the steps your current system happens to require. Applied to journey mapping, that's the exact difference between a stage and a step — one describes the customer, the other describes your workflow.

Take car insurance shopping: a customer clicking through three separate quote-comparison pages is still in one stage. They're still trying to answer "which insurer will actually pay out." The screen changed three times; the underlying question didn't change once.

Why this distinction gets skipped

Teams skip straight from a touchpoint inventory to a stage list because touchpoints are easy to observe — you can screenshot them — while intent has to be inferred from research, support transcripts, or interviews. Screens are visible; goals aren't. That asymmetry is the entire reason screen-driven decomposition is the default failure mode rather than a rare mistake.

The Boundary Heuristic: Draw the Line Where Intent Shifts

The test for a stage boundary is simple: name the question the customer is trying to answer right now, then check whether that question is different from the one they were answering a moment ago. If the underlying question changed, you've crossed into a new stage. If only the interface changed, you're still inside the same one.

Jobs to Be Done, the framework built by Clayton Christensen and refined with Bob Moesta, offers a sharper version of the same test. Their forces of progress model describes four pressures a customer weighs while moving toward a decision:

• Push — a problem grows painful enough to act on.
• Pull — a new option starts looking appealing.
• Anxiety — doubt about switching away from the current approach.
• Habit — comfort with what they already do, working against change.

A stage boundary is usually sitting exactly where the dominant force changes — push turning into pull, or pull giving way to anxiety. For the full model, see our complete guide to Jobs to Be Done.

Three questions to ask at every candidate boundary

1. Would the customer describe what they're doing differently right before and right after this point — "comparing options" versus "confirming it worked," for instance?
2. Does their emotional register change here — curiosity giving way to anxiety, or anxiety giving way to relief?
3. Would a different role on your team plausibly own the work on each side of the line?

Two or three "yes" answers means you've found a real stage boundary. Zero means you're looking at a step, not a stage — merge it into its neighbor and move on.

Screen-Driven vs. Goal-Driven Decomposition, Same Product

The fastest way to see the difference is to decompose one journey twice. Below, the same product — shopping for and using car insurance — gets mapped first by the screens a team happens to own, then remapped by what the customer is actually trying to resolve at each point.

Counted by screen, this journey is seven or eight "stages" — one per page or channel the org happens to own. Counted by intent, it's five. The three quote-form pages collapse into a single trust-evaluation stage, because the customer's question never changes across them; the claims portal and the adjuster phone call collapse into a single promise-testing stage for the same reason, even though weeks might separate them.

A screen-driven map also hides the moments that matter most. It can't support a meaningful emotion curve, because emotion resets arbitrarily every time a URL changes rather than when the customer's feeling actually shifts. Multiply that across a dozen artificial "stages" and the curve becomes noise dressed up as insight — every dip and rise just tracks page-load friction instead of how the customer actually felt.

The same pattern holds outside insurance

The insurance example isn't a special case. A B2B SaaS trial mapped by screen usually produces something like: signup screen, workspace-creation screen, invite-teammates screen, template picker, dashboard. Mapped by goal, that same sequence is: deciding whether this is worth trying, setting up enough of my own context to judge it fairly, getting my team looped in before I commit further, and seeing enough value to make it part of how we work. Four goal-driven stages, five screen-driven ones — and the gap between them is exactly where a team wastes effort optimizing a page that was never the reason someone stalled.

When more than one person is deciding

This gets harder once more than one person is doing the deciding. Gartner's research on B2B purchasing has repeatedly put the typical buying group somewhere around six to ten stakeholders, each carrying a different intent in parallel — a benefits administrator evaluating a group policy isn't one customer's journey, it's several overlapping ones running at once.

See our breakdown of the B2B buying committee journey for how to decompose stages when intent belongs to a group rather than a single person. Flattening a committee into one customer's stages is its own version of faking the boundaries — just at the actor level instead of the screen level.

Two Failure Modes: Too Many Stages and Too Few

Overcorrecting on granularity produces two opposite failures: a map so fine-grained it's really a flowchart — ten or more "stages" that are actually steps — or a map so coarse it's really a funnel, three stages that hide every moment where a customer's feeling actually changes. Both break the emotion curve.

Nielsen Norman Group's journey-mapping guidance has long cautioned against maps optimized for exhaustiveness. Once a map balloons past seven or eight stages, teams tend to stop acting on it — the artifact becomes documentation nobody reopens. Five to seven stages is a reasonable range to aim for on a first pass, though the right count is always specific to the journey in front of you.

Local mapping is how too-many-stages happens

The too-many-stages failure often comes from mapping locally — one team documents its own handoffs in obsessive detail while ignoring what happens upstream or downstream of it. Zooming out to see the whole loop, not just your team's slice of it, is exactly the discipline our guide to systems thinking covers — the same habit that catches a hidden feedback loop also catches a false stage boundary hiding inside someone's handoff log.

The too-few-stages failure is quieter but just as damaging. A three-stage funnel template feels tidy in a slide deck, but it gives a backlog nothing to attach to — "Consideration" is too broad a target for any single roadmap item, so prioritization work either stalls or gets attached arbitrarily.

A Repeatable Process for Naming and Testing Your Stages

Building a defensible set of stages is a sequence, not a single brainstorm: list every touchpoint first, group them into steps, then test each junction against intent rather than interface. Skipping straight to stage names before doing the grouping is exactly how screen-driven decomposition sneaks back in.

1. List every touchpoint you can think of, in order, without worrying about stages yet.
2. Group touchpoints into steps — which ones complete the same immediate task?
3. Apply the three-question heuristic from the section above at every junction between steps.
4. Name each stage after the customer's goal, not your product's feature — a verb phrase in the customer's voice ("Deciding whether to switch") beats a noun label ("Consideration").
5. Sanity-check against emotion. Does each stage leave room for the customer's feeling to plausibly move across it? A stage that never lets emotion shift is probably too granular; one that swings wildly within itself is probably too coarse.
6. Pressure-test with someone outside the project. If they can't say what the customer is trying to do at each stage from the name alone, rename it.

None of this has to happen in one sitting. Draft the stages, run the three-question test on the shakiest boundaries, and revise — most teams land on a stable set after two or three passes, not one clean draft.

A quick naming check

A useful shortcut: if a stage name could describe a page in your product's navigation menu, it's probably still screen language. If it reads like something the customer would say out loud to a friend — "I'm trying to figure out if switching is even worth the hassle" — it's probably intent language, and it's ready to become a stage name.

Why the Decomposition Decision Comes First

Every later layer of a journey map — the emotion curve, the friction list, the prioritized backlog — is scoped to whatever stages you drew first. An error here doesn't stay contained to a stage's name; it propagates into every artifact derived from that stage.

If a stage boundary is fake — a screen change dressed up as a goal change — the emotion curve drawn across it measures a UI transition, not a customer feeling. Any backlog item prioritized against that curve inherits the same false signal. See turning the emotion curve into a prioritized backlog for how directly that later step depends on the stages underneath it being real.

If the stage is fake, the emotion curve built on top of it is fake too — and so is whatever backlog gets prioritized against that curve.

This is also why Prodinja's Customer Journey tool structures a map as a fixed sequence of discrete stages before it lets you build out the touchpoint grid or plot the emotion curve underneath them. Getting the decomposition right up front — real intent shifts, not screen changes — is what makes the grid and the curve worth looking at once they're built.

Key Takeaways

• A stage marks a shift in the customer's goal or mental state, not a shift in your UI, URL, or org chart.
• Test every candidate boundary against JTBD's forces of progress: a stage usually ends where the dominant force changes.
• Screen-driven decomposition inflates the stage count and buries the moments that matter inside "pages" instead of surfacing them.
• Aim for five to seven stages on a first pass — more is usually steps in disguise, fewer is usually a funnel template.
• Name stages as the customer's goal in their own words, not as your product's feature or a generic funnel label.
• Because the emotion curve and backlog are scoped to your stages, a decomposition error compounds into everything built downstream.
• B2B journeys with multiple stakeholders often need stage boundaries built around a group's overlapping intents, not one person's.