Journey Step

Origin & evolution

Journey mapping as a structured practice traces to service design in the late 1990s. OxfordSM, then Oxford Corporate Consultants, is widely credited with introducing customer journey mapping around 1998 in work for Eurostar, mapping the rail experience end to end. The step as the journey's atom is implicit in that lineage: to map a journey you have to break it into the discrete actions a person takes, in order.

The grammar of journey maps was later codified by the Nielsen Norman Group, which fixed the now-standard layering. A journey has a few high-level phases. Each phase contains the granular actions, thoughts, and emotions of the user. Those granular actions are the steps. The convention matters because it gives the map two zoom levels: phases for the executive view, steps for the team that has to change something.

The 2009 McKinsey consumer decision journey, by David Court, Dave Elzinga, Susan Mulder, and Ole Jørgen Vetvik, reshaped the phase layer by replacing the linear funnel⬇️FunnelGrowthA conversion funnel tracking user progressionView reference → with a loop of consider, evaluate, buy, and post-purchase experience. That shift left the step intact as the working unit; it changed the shape of the phases the steps live inside, and it made the post-purchase steps matter as much as the pre-purchase ones.

How it works in practice

A team maps the activation journey for a project-management tool. The "set up first project" phase looks healthy in the metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → until they decompose it into steps: create workspace, invite a teammate, create the first task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, assign it, set a due date. Pinning emotion and drop-off to each step exposes the real problem. Ninety-two percent of users clear "create workspace" and "create first task", and only thirty-one percent clear "invite a teammate".

That single step is where the journey breaks. The need it reveals, I do not want to commit my team before I trust this tool, was invisible at the phase level, where "set up first project" reads as one smooth block. The fix is scoped to the step: make inviting optional, defer it past the moment of first value. The step gave the team a place precise enough to attach a need, a metric, and a change.

Journey step vs. its neighbours

• Customer journey stage🚏Customer Journey StageCustomer SuccessA stage in the post-sale customer journeyView reference → is the coarse phase a step belongs to, such as onboarding or renewal. A stage groups many steps; a step is one action inside it. You report on stages and you fix things at steps.
• Touchpoint👆TouchpointCustomer SuccessA customer interaction touchpointView reference → is where the step happens: the channel or interface the user contacts at that moment. One step can span more than one touchpoint, and one touchpoint can host steps from different journeys. The step is the user's intent; the touchpoint is the surface that intent lands on.
• Need is what the user is trying to get done at a step, independent of the product. A journey step is the situated occurrence of that need, fixed to a moment and an order. The graph treats the need as something a step reveals; the step itself is the moment, not the want.

In the graph

In the Unified Product Graph, a journey step sits in the UX-design domain as the atomic element of a user journey. The composition edge is user_journey_contains_journey_stepUser JourneycontainsJourney Stephierarchy, and ordering is carried by journey_step_precedes_journey_stepJourney StepprecedesJourney Stepsemantic, so the sequence is an explicit chain the graph can walk. The step is where needs and solutions🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → meet: journey_step_reveals_needJourney SteprevealsNeedcross-domain and its inverse need_occurs_in_journey_stepNeedoccurs inJourney Stepcross-domain pin a need to the exact moment it surfaces, and journey_step_realised_by_featureJourney Steprealised byFeaturecross-domain connects that moment to the thing built to serve it. Where a journey is organised into phases, journey_phase_has_stepJourney Phasehas stepJourney Stephierarchy nests the step under its phase. The structure keeps two zoom levels live at once: phases for the overview, steps for the work, with needs and features⭐FeatureProduct SpecificationA product capability or featureView reference → anchored to the level granular enough to act on.