11.2 Current- and Future-State Journey Mapping for Design
Key Takeaways
- Current-state journey maps are design inputs: they surface pain, effort, emotion, and moments of truth that become experience requirements—not wall art for the office
- Future-state journeys describe the intended experience after change: stages, emotions, channels, and success criteria aligned to CX strategy and segment needs
- Moments of truth are high-impact interactions that disproportionately shape perception; design attention should concentrate where they fail or where opportunity is greatest
- Experience requirements translate insights into testable design criteria (what must be true for the customer) that guide ideation, prototypes, and blueprints
- On the CCXP exam, distinguish Insights-era mapping (understand today) from Design-era mapping (specify tomorrow and drive implementation)
11.2 Current- and Future-State Journey Mapping for Design
Quick Answer: In Domain 4, journey maps are design tools. Current-state maps extract requirements from lived pain, emotion, and moments of truth. Future-state maps specify the intended end-to-end experience the organisation will prototype, blueprint, and implement—aligned to strategy and validated with customers.
Chapter 3 introduced journey mapping as an insights practice: evidence-based pictures of how customers experience stages today. Domain 4 reuses that artefact for design and innovation. The same map that diagnosed reality becomes the foundation for requirements and for drawing a future-state journey the organisation commits to deliver.
From Insight Maps to Design Artefacts
| Map type | Primary question | Domain role | Typical consumers |
|---|---|---|---|
| Current-state journey | What do customers experience today, and where does it break? | Insights → Design input | Researchers, designers, ops leaders |
| Future-state journey | What should customers experience after we change the system? | Design / strategy realisation | Design, product, ops, tech, training |
| Service blueprint (11.3) | What must happen onstage and backstage to deliver that journey? | Implementation design | Ops, IT, process, HR |
A frequent exam trap is treating current- and future-state maps as interchangeable. They are not. Current-state without future-state leaves teams stuck in complaint catalogues. Future-state without current-state becomes executive fantasy disconnected from real constraints and real pain.
Using Current-State Maps to Define Requirements
A design-ready current-state map does more than list steps. It supports requirement extraction:
- Locate failure and friction — Drop-offs, long waits, repeated contacts, confusing policy, emotional troughs.
- Link to evidence — VoC themes, operational metrics, complaint codes, ethnographic notes (not only workshop opinions).
- Identify moments of truth — Few interactions that dominate memory and loyalty (approval decision, first bill, claim outcome, outage recovery).
- Name experience gaps — Difference between intended brand promise and what customers actually feel.
- Translate to requirements — Statements of what the redesigned experience must achieve for the customer.
Experience requirements vs solution specs
Write requirements in customer outcome language before prescribing channels or tools.
| Weak (solution-led) | Strong (experience requirement) |
|---|---|
| “Build a chatbot on the app home screen” | “First-time applicants know required documents and status without calling within 24 hours of submission” |
| “Add more FAQs” | “Customers resolve billing confusion in one interaction with a clear next step and confirmation” |
| “Train agents to smile more” | “Customers feel heard and leave with an owned resolution path when an error is admitted” |
Solution ideas come later in ideation. Requirements keep prototypes honest: if a chatbot does not deliver the document/status clarity requirement, it fails even if the UI is pretty.
Requirements portfolio from a map
From one current-state journey, design teams often produce a structured set:
- Must-fix pains — Regulatory, safety, or severe loyalty risks.
- Effort reducers — Steps, handoffs, or information gaps that inflate CES.
- Emotion shapers — Anxiety, fairness, confidence, delight opportunities.
- Channel expectations — Where customers prefer to start, continue, and finish.
- Segment variations — Requirements that differ for new vs tenured, digital vs assisted, high-value vs mass.
Prioritise with Domain 3 logic (drivers, impact, frequency, strategic value)—not with “easiest story for the next sprint” alone.
Designing Future-State Journeys
A future-state journey map describes the intended experience after improvements. It is a design specification in journey form, not a wish list.
Core contents of a useful future-state map
- Scope — Persona/segment, occasion, start and end of the journey.
- Stages and goals — What “good” means for the customer at each stage.
- Actions and channels — What the customer does and where (deliberately designed, not accidental).
- Emotion curve (intended) — Where confidence, relief, or pride should land; where anxiety must be reduced.
- Moments of truth design — Explicit treatment of critical interactions.
- Success metrics — Perception and operational measures that will prove the future state is real.
- Assumptions and dependencies — Policy, systems, staffing, partners required for the journey to work.
Design principles for future-state work
- Align to intended experience and brand — Future state realises Domain 2 strategy; it does not invent a parallel brand.
- Be specific enough to build — Vague “seamless omnichannel delight” is not implementable.
- Show trade-offs — If self-serve increases, assisted paths may change; say so.
- Design transitions — Handoffs between channels and teams are where future states often die.
- Validate with customers and employees — Concept tests and walkthroughs before blueprinting and build.
- Keep a gap view — Maintain current vs future comparison so investment cases stay honest.
Current → future bridge table (exam-friendly pattern)
| Stage | Current-state pain | Experience requirement | Future-state design choice | Metric |
|---|---|---|---|---|
| Apply | Unclear documents | Know requirements up front | Dynamic checklist + examples | Completion rate, CES |
| Wait | Anxiety, status calls | Proactive progress visibility | Milestone notifications | Inbound “status” contacts |
| Decision | Opaque decline | Fair explanation + next options | Plain-language decision pack | Complaint rate, trust items |
| Onboard | Fragmented setup | One coherent activation path | Single owner + guided steps | Time-to-value, early churn |
This bridge is the working language between Insights, Design, and Metrics.
Moments of Truth and Perception
Moments of truth are interactions or events that disproportionately shape whether customers trust, stay, expand, or leave. Not every step is equal. Design programmes that spread effort evenly across thirty micro-steps often under-invest in the three moments that define the brand.
Types of moments design teams prioritise
| Type | Example | Design implication |
|---|---|---|
| First impression | Account opening, first delivery | Reduce uncertainty; set accurate expectations |
| Value realisation | First successful use of the product | Accelerate time-to-value; celebrate progress |
| Stress / risk | Claim, outage, fraud alert, medical bill | Clarity, control, empathy, speed of recovery |
| Money moments | Price change, fee, renewal | Fairness, transparency, choice |
| Recovery | Complaint handling | Owned resolution; do not force the customer to re-explain |
Perception research and driver analysis (Domain 3) often confirm which moments matter most. Journey emotion curves and complaint severity help when statistics are thin. Design then allocates prototyping and blueprinting capacity to those moments first.
On the exam: a moment of truth is about impact on perception and relationship, not about which department owns the KPI.
Experience Requirements from Insights
Insights synthesis (Domain 1) should not end in a slide titled “Findings.” Design needs a requirements pack:
- Insight — What we learned (evidence-backed).
- Implication — Why it matters for experience and business.
- Requirement — What must be true for the customer.
- Design opportunity — “How might we…” prompts for ideation.
- Success signal — How we will know we improved.
Mini scenario
A utilities company maps the outage journey. Current state: customers learn of outages from neighbours, wait on hold, receive conflicting ETAs, and get no confirmation when power returns. Drivers show trust and communication clarity dominate post-outage CSAT. Experience requirements include proactive multi-channel alerts, a single ETA source of truth, and a restoration confirmation. Future-state journey stages redesign “detect → inform → update → restore → confirm → learn.” Prototypes test message timing and wording before OMS integration. The map was not the deliverable—the requirements and future-state specification were.
Facilitation Tips for Design Journey Sessions
- Separate current-state validation workshops from future-state design workshops when stakeholders conflate “what is” with “what we wish.”
- Bring raw evidence (quotes, call themes, metrics) so future-state debates stay grounded.
- Include frontline staff who live the handoffs; they spot impossible future states early.
- Time-box “solution brainstorming” until requirements are clear.
- End future-state sessions with open questions and owners, not only a prettier diagram.
- Schedule concept tests before locking the future state into a multi-year programme.
Pitfalls
- Future-state as marketing copy — No operational path to deliver it.
- Ignoring segments — One average journey that fits no real customer.
- Channel myopia — Designing only the app when the moment of truth is a field visit or a letter.
- Metric orphan — Future state with no success measures or baseline.
- Skipping current state — Redesigning based on internal process maps alone ( Domains 1 and 4 both reject this).
Exam Focus
Expect questions that test whether you:
- Use current-state maps to derive experience requirements
- Design future-state journeys as intended-experience specs tied to strategy
- Prioritise moments of truth that shape perception
- Connect insights → requirements → ideation → prototype success criteria
- Distinguish journey maps (customer lens) from process maps and blueprints (delivery lens)
Master this section and you can turn journey evidence into a design brief the organisation can build, test, and measure.
A team drafts a future-state journey that says “delight customers with seamless omnichannel service at every step” but lists no segment, no stage goals, no metrics, and no dependencies. What is the main design problem?
How should a design team primarily use a well-evidenced current-state journey map?
Which example best qualifies as a moment of truth for prioritising design effort?