journey-mapping-and-service-design

name	journey-mapping-and-service-design
description	Use when evidence must be synthesised into a persona, JTBD, end-to-end journey, experience map, or service blueprint across channels and frontstage/backstage work. Do not use for a single-screen flow or primary user research collection.
metadata	{"portable":true,"category":"05-ux-process-research-and-psychology","compatible_with":["claude-code","codex"]}

Journey Mapping & Service Design

Use When

• You need an evidence-based persona — a research-grounded archetype with goals, context, and jobs — not a demographic stock photo invented to justify a roadmap.
• You must map a user's or customer's experience over time across stages, touchpoints, and channels: a current-state journey map, a future-state map, or a broader experience map (organisation-agnostic, before a specific product exists).
• You are designing or fixing a service, not just a UI — you need a service blueprint that ties what the customer sees (frontstage) to the staff actions, systems, and processes that deliver it (backstage + support), separated by the line of visibility.
• You need to express what the customer is fundamentally trying to accomplish as Jobs-To-Be-Done ("when I ___, I want to ___, so I can ___") so the design serves the job, not the feature.
• You have research and a map and must produce an alignment diagram (research → map → opportunities) and a ranked opportunity backlog that the team can act on.

Do Not Use When

• You are running the interviews, surveys, or usability tests that feed the map → use the sibling ux-research-and-usability-testing (that skill gathers the evidence; this skill structures it over time). The two pair — see Workflow steps 1 and 8.
• You are designing a single screen's structure, fidelity, or flow → use the sibling wireframing-and-prototyping (a wireflow is one touchpoint's mechanics; a journey map is the experience around it).
• You are applying cognitive/behavioural theory or heuristics to a design (biases, cognitive load, Gestalt, Nielsen) → use ux-psychology.
• You are defining the end-to-end product/discovery operating model, RACI, and rituals → use enterprise-ux-process.

Required Inputs

Input	Source	Evidence
Research observations and segments	Research repository	Traceable quotes, behaviours, and sample limits
Journey scope, actor, and outcome	Sponsor and research lead	Start/end boundary and success definition
Channels, backstage processes, and owners	Operations/service teams	System, policy, handoff, and ownership evidence

• The decision or problem the map must inform. A map with no decision behind it is a poster. Name it: which journey, for whom, to resolve what (drop-off? a broken hand-off? a new service we are scoping?).
• Evidence. Research notes, interviews, support tickets, analytics funnels, frontline-staff input, complaint logs. Personas and emotion curves invented without evidence are slop (see Anti-Patterns).
• The actor and the scope. Who the journey belongs to (one persona, named), and the start/end boundary — where the journey begins (often before your product) and where it ends (often after).
• For a blueprint: the people, systems, channels, and back-office processes that deliver the service — including the parts the customer never sees.
• The channels and touchpoints in play (app, web, phone, in-person, SMS, third parties), because cross-channel seams are where experiences break.

Workflow

1. Anchor to a decision and a persona. State the decision the map will inform and whose journey it is. Build the persona from evidence per references/journey-map-templates.md §Persona — goals, context, jobs, real quotes, and the research behind each. If you cannot cite evidence for a persona trait, mark it an assumption to validate (route to ux-research-and-usability-testing). No invented personas.
2. Frame the Jobs-To-Be-Done. Before mapping the how, state the why as JTBD: "When [situation], I want to [motivation], so I can [outcome]." The job is stable; the solution is not. Use references/journey-map-templates.md §JTBD. The journey then serves the job, so opportunities are judged by "does this advance the job", not "is this a nice feature".
3. Choose the map type. Journey map (one persona, one scenario, your service exists), experience map (broader, organisation-agnostic, problem space before a solution), or service blueprint (you must change how the service is delivered, not just the interface). references/journey-map-templates.md §Choosing the map names which to use when. Picking the wrong artifact is the most common waste.
4. Lay the spine: stages and actions. Break the journey into the actor's stages (their mental phases, named in their words — not your funnel), then the actions/touchpoints within each. Use representative content and real touchpoint names; never lorem, never generic "Awareness → Consideration → Decision" if the real journey isn't that.
5. Add the experience layers. For each stage capture: what they're doing, thinking, feeling (the emotion curve, justified by a quote or datapoint — not a decorative squiggle), the touchpoint/channel, and the pain points & moments of truth. An emotion curve with no evidence under each peak/trough is decoration; cite the source.
6. For a service, blueprint it. Add the swimlanes below the line of interaction: frontstage staff actions, the line of visibility, backstage staff actions, the line of internal interaction, and support processes/systems. Use references/service-blueprint.md. The value of a blueprint is precisely the backstage failure points the customer never sees but always feels — find them.
7. Mark the seams and moments of truth. Cross-channel hand-offs, waits, and ownership gaps (where no team owns the step) are where services fail. Flag each on the map. A blueprint that hides the hand-offs has skipped its only real job.

Decision Rules

Condition	Choice	Wrong-choice failure
Goal is customer experience over time	Journey/experience map	Screen flow omits channels, time, and emotion
Goal includes operational causes	Service blueprint	Journey alone hides backstage failure sources
Evidence cannot support a persona	Behavioural segment or proto-persona label	Fictional specificity becomes false research

Capability Contract

• Must read traceable research and operational evidence; synthesis is read-only unless workshop or artefact editing is requested.
• May facilitate mapping, but may not invent user evidence, assign organisational commitments, or publish sensitive maps without authority.

Degraded Mode

• If actor, scope, or evidence provenance is missing, stop the final map and return a proto-map with explicit assumptions.
• Without workshop access, produce an asynchronous draft for owner validation. Recover conflicts by preserving competing evidence, naming the owner, and marking unresolved branches.

Quality Standards

• Every major stage, pain point, and opportunity traces to evidence or is labelled assumption.
• Opportunities identify affected actor, causal layer, owner, expected outcome, and validation need.

Anti-Patterns

• The invented persona. A stock-photo archetype with made-up demographics and a cute name, built to rationalise a decision already made. Personas not traceable to research are confirmation laundering.
• The decorative emotion curve. A smooth sad-to-happy squiggle with nothing under each peak/trough. If a low point has no quote, ticket, or metric beneath it, it is fiction.
• Happy-path-only journeys. Mapping only the smooth path and omitting errors, waits, recovery, and the channel switch — hiding exactly the moments where the experience breaks.
• The wall-poster. A beautiful laminated map with no decision, no owner, and no opportunity backlog. It gets framed and never changes anything (the experience-scale cousin of the shelved research deck).
• Blueprint with no backstage. A "service blueprint" that only redraws the frontstage screens and never models staff actions, systems, or the line of visibility — so the failures that live backstage stay invisible.
• Stages in your words, not theirs. Forcing the customer's lived experience into the company's funnel labels, which hides where their mental model and your process diverge.
• Map as the deliverable. Treating the artifact as the goal. The map is a means; the ranked opportunities are the output. No opportunities → unfinished.
• One persona, one channel, one ability. Mapping the median user on the best device and calling the service designed.

Outputs

Output	Consumer	Evidence and acceptance
Journey map or service blueprint	Product, service, operations	Scope, stages, evidence, channels, pain points, and backstage causes are explicit
Opportunity register	Decision owners	Ranked opportunities include evidence, owner, outcome, and validation requirement

• One or more evidence-based personas (goals, context, JTBD, real quotes, traceable to research).
• A set of JTBD statements framing the journey by outcome, not feature.
• A journey map / experience map: stages (in the actor's words) × layers (doing / thinking / feeling / touchpoint / pain & moments of truth), with an evidence-justified emotion curve.
• Where a service is involved, a service blueprint: frontstage / line of visibility / backstage / support processes, with seams and failure points marked.
• An alignment diagram + ranked opportunity backlog: each opportunity traced to evidence and scored by impact × frequency × feasibility.

Examples

• See examples/journey-map-and-opportunities.md — a worked, evidence-based current-state journey map for Maduuka (a B2B inventory app for small East-African retailers): the persona, the JTBD, the stage-by-stage map with an evidence-backed emotion curve, the cross-channel seams, and the ranked opportunity backlog traced back to research. Representative content throughout — never lorem.

References

• references/journey-map-templates.md — the persona template, the JTBD format, the journey-vs-experience-map decision, the stage × layer map grid, the emotion-curve evidence rule, and the alignment-diagram / opportunity-backlog scoring model.
• references/service-blueprint.md — the blueprint swimlanes (frontstage, line of visibility, backstage, line of internal interaction, support processes), how to find backstage failure points, and how a blueprint differs from and extends a journey map.
• doctrine/design-doctrine.md — §0 Mission (the authored-not-templated moat) and §2 Anti-Slop Charter; an experience that "feels generic / untrustworthy" is a slop signal at journey scale.
• doctrine/references/ai-slop-taxonomy.md — the slop tells; map "felt generic / didn't trust it" troughs here and escalate them as opportunities.
• doctrine/references/wcag-2.2-criteria.md — accessibility/channel-equity gate; a single-channel, single-ability map is incomplete, not done.
• Sibling skills: 05-ux-process-research-and-psychology/ux-research-and-usability-testing (gathers the evidence this map structures), wireframing-and-prototyping (the touchpoint mechanics within the journey), ux-psychology (theory behind the emotion curve), enterprise-ux-process (the surrounding operating model).