User Journey

Origin & evolution

The lineage runs through service design. G. Lynn Shostack introduced service blueprinting in the Harvard Business Review article "Designing Services That Deliver" (1984), mapping a service as a sequence crossing a line of visibility between what the customer sees and what the organisation does behind it. Ron Zemke and Chip Bell developed adjacent thinking through the 1980s. The specific practice of customer journey mapping was introduced by Oxford Corporate Consultants, now OxfordSM, in 1998 for Eurostar, to align a brand promise with the lived experience of a rail passenger.

The idea matured as digital experience grew more fragmented. Jim Kalbach's *Mapping Experiences* (2016) consolidated the field, distinguishing the variants🆎VariantGrowthA variant in an A/B testView reference → that had proliferated: the journey map centred on a persona🎭PersonaUserAn archetype representing a user segmentView reference →'s emotional path, the experience map that abstracts across people, and the service blueprint🟣Service BlueprintCustomer SuccessA blueprint of the full service deliveryView reference → that adds the backstage organisation. Kalbach's framing was that these are alignment artefacts whose value comes from building shared understanding, and that a map disconnected from a real persona and a real goal is decoration.

A useful split emerged between current-state maps, which document the journey as it is, warts and drop-offs included, and future-state maps, which propose the journey as it should be. The first is a diagnostic; the second is a design target. Confusing them is how teams end up mapping an aspiration and mistaking it for reality.

How it works in practice

A team maps the current-state onboarding journey for a primary persona, the time-starved solo operator. Five phases: discover, sign up, connect data, first value, habit. Each phase records the persona's action, their emotional state, and where they stall. The map exposes a seam invisible at the screen level: sign-up and data-connection each test well in isolation, but between them the user is asked to leave the product to find an API key, and thirty per cent never return. No single screen owns that failure; the journey does. The fix, an in-flow credential paste, targets the seam, and the future-state map records the intended path so the team can measure against it.

User journey vs. its neighbours

• User flow🔀User FlowExperience DesignA navigation path through the productView reference →: a flow is the screen-by-screen click path through one task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →; a journey is the broader arc across time, channels, and emotional states, often spanning sessions. A flow lives inside a journey. The graph connects them with user_flow_maps_user_journeyUser FlowmapsUser Journeycross-domain.
• Service blueprint: a blueprint extends a journey with the backstage processes, systems, and staff that deliver each step. The journey is the customer's view; the blueprint adds the organisation's. The graph treats the blueprint as a journey_type rather than a separate node.
• Job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → to be done: a job is the timeless progress a person seeks, independent of any solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →; a journey is the actual path they take through your specific product to get there. The journey addresses a job through user_journey_addresses_jobUser JourneyaddressesJobcross-domain; one job can be served by many journeys.

In the graph

In the Unified Product Graph, user_journey🛤️User JourneyExperience DesignAn end-to-end map of a user experience is the anchor of the Experience, Design & Brand region, which makes sense: the journey is the spine that screens, flows, and prototypes📱PrototypeExperience DesignAn interactive mockup for testingView reference → attach to. Its journey_type property carries the current-state, future-state, day-in-the-life, and service-blueprint distinction so the diagnostic and the target never blur. Outbound, user_journey_contains_journey_stepUser JourneycontainsJourney Stephierarchy and user_journey_passes_through_journey_phaseUser Journeypasses throughJourney Phasehierarchy build the temporal structure, while user_journey_maps_personaUser JourneymapsPersonacross-domain and user_journey_addresses_jobUser JourneyaddressesJobcross-domain tie it to the who and the why. Inbound, opportunity_improves_user_journeyOpportunityimprovesUser Journeycross-domain lets a discovery finding point straight at the seam it should fix. A journey mapped to no persona is the most common decoration in product work, and here it is queryably orphaned.