Journey maps and service blueprints

A Ward Desk streetlight complaint takes 11 days to close on average. The product lead says “the form is slow”. Mapping the real journey tells you the form takes 2 minutes — the wait takes 11 days, and most of it happens backstage, where no resident ever looks. Without a map, a team fixes the wrong thing.

Below you will trace one complaint through five journey stages with emotions at each, redraw it as a service blueprintservice blueprint: A diagram that extends a journey map to show the organisation's side: frontstage actions the person sees, backstage actions staff take, and the support systems that make them possible. that exposes what happens behind the line of visibility, identify three failure points that research would catch, and plan for the SMS that arrives 20 minutes late.

Experience maps and journey maps

An experience mapexperience map: A map of the whole problem a person is trying to solve, including parts before and after the service, to show context the service does not yet address. covers the whole problem a person is trying to solve, including parts the service does not yet touch. When the GOV.UK Service Manual asks teams to “map and understand a user’s whole problem”, it means drawing the experience before and after the service: the moment someone notices a broken streetlight, the neighbour they ask about it, the call they make when no SMS arrives. A journey mapjourney map: A visualisation of one persona's experience through a service, with stages, actions, thoughts, feelings and pain points at each step, all backed by research evidence. is narrower: one named persona moving through one flow, from trigger to outcome, with the emotions, thoughts, actions and pain points at each stage.

Both share a structure. Read left to right: stages that name what part of the experience the person is in, not what screen they are on. Read top to bottom: what the person does, what they think and feel, and where the service lets them down. Every pain point is backed by research evidence — an interview quote, an observation note, or a support ticket that names the same problem. An emotion curve drawn from memory is decoration; an emotion curve traced from what eight participants said is evidence.

GOV.UK’s guide on creating an experience map lists what a team brings to the wall: the event cards from research sessions, colour-coded sticky notes, quotes, photos and artefacts. A map built without research is a hypothesis, and the team that ships from it is guessing.

Mapping one complaint through five stages

Ward Desk (warddesk.example) is this track’s invented bilingual municipal complaints service. A resident notices a broken streetlight, reports it through the app, waits for a response, checks the status when none arrives, and finally receives a closure SMS on day 11. Each stage carries an emotion observed in research: anger when the street is dark, confusion when the form does not name the right department, frustration during the silent wait, hope when support says “in progress”, relief when the light comes back on.

Step through the journey below and watch the emotions shift. The branch from Wait to Check status shows what happens when the service fails to communicate: the resident has to call:

Four things the map makes visible that a feature list hides:

1. The service does not start when the app opens. It starts when the resident notices the problem.
2. The wait stage is the longest and carries the worst feeling. No amount of form polish will fix it.
3. The branch is a failure: the service forced the resident to call because status was unclear.
4. Relief at the end does not erase the frustration in the middle.

A journey map is a reading of the research, not a replacement for it. The emotions here came from eight fictional interviews; a real map cites each one. When a stakeholder draws an emotion curve from memory, the first job is to go back and check it against what participants actually said.

Service blueprints add the organisation’s side

Lynn Shostack introduced the service blueprint in a 1984 Harvard Business Review article, arguing that services fail when the processes behind them are not designed with the same care as the customer-facing parts. A blueprint takes a journey map and extends it downward: above a line of visibility sits the frontstagefrontstage: The part of a service the person using it can see: screens, messages, calls and face-to-face interactions., everything the person using the service can see; below it sit the backstagebackstage: The internal actions staff take to deliver a service, hidden from the person using it but visible in a service blueprint. actions staff take, and the support systems — databases, SMS gateways, contractor schedules — that make those actions possible.

The line of visibilityline of visibility: The boundary in a service blueprint between what the person using the service sees (frontstage) and what happens behind the scenes (backstage and support). is not a wall between good and bad. It is where accountability changes. When an SMS is late, the resident blames the service; the blueprint shows that the cause is a support system the resident has never heard of.

Step through the same streetlight complaint as a blueprint. The resident and the app are frontstage; the ward engineer and the ticket system are backstage; the SMS gateway and the contractor sit in support:

Three failure points appear that a journey map would miss:

None of them is visible to the resident. All of them make the wait longer. A team that only maps the frontstage will never see them.

Tracing the blueprint with numbers

The program below holds the seven steps of the blueprint as a list of dicts. Each step has an id, a lane, an action, a day, and an optional failure. Run it to see the blueprint as a table, the days spent in each lane, and the three failure points with a fix for each:

"""
A Ward Desk streetlight complaint traced through a service blueprint.

The blueprint shows 7 steps across 3 lanes: frontstage (resident-facing),
backstage (internal staff actions), and support (systems and contractors).
The line of visibility runs between frontstage and the other two lanes.
Each step has a timing in days. Three failure points are identified.
"""

# Blueprint steps: each dict has id, lane, action, day, and optional failure
STEPS = [
    {
        "id": "S1",
        "lane": "frontstage",
        "action": "Resident files complaint via app",
        "day": 0,
        "failure": None,
    },
    {
        "id": "S2",
        "lane": "support",
        "action": "SMS confirmation sent",
        "day": 0,
        "failure": {
            "problem": "SMS delayed up to 20 minutes",
            "fix": "Show in-app confirmation immediately; SMS as backup",
        },
    },
    {
        "id": "S3",
        "lane": "backstage",
        "action": "Ticket assigned to ward engineer",
        "day": 1,
        "failure": None,
    },
    {
        "id": "S4",
        "lane": "backstage",
        "action": "Engineer inspects streetlight",
        "day": 3,
        "failure": {
            "problem": "Engineer re-routed to urgent complaint",
            "fix": "Auto-notify resident of delay with new estimate",
        },
    },
    {
        "id": "S5",
        "lane": "backstage",
        "action": "Engineer logs parts needed",
        "day": 4,
        "failure": None,
    },
    {
        "id": "S6",
        "lane": "support",
        "action": "Contractor notified for repair",
        "day": 7,
        "failure": {
            "problem": "Contractor not called until day 7",
            "fix": "Trigger contractor call when parts logged, not after",
        },
    },
    {
        "id": "S7",
        "lane": "frontstage",
        "action": "Resident receives closure SMS",
        "day": 11,
        "failure": None,
    },
]


def print_blueprint(steps):
    """Print the blueprint as a table with columns."""
    print("=" * 70)
    print("WARD DESK STREETLIGHT COMPLAINT BLUEPRINT")
    print("=" * 70)
    print(f"{'Step':<5} {'Lane':<12} {'Action':<35} {'Day':<5}")
    print("-" * 70)
    for s in steps:
        print(f"{s['id']:<5} {s['lane']:<12} {s['action']:<35} {s['day']:<5}")
    print("=" * 70)


def total_days_by_lane(steps):
    """Calculate total days spent in each lane."""
    lanes = {"frontstage": 0, "backstage": 0, "support": 0}
    prev_day = 0
    for i, s in enumerate(steps):
        duration = s["day"] - prev_day if i > 0 else 0
        if i > 0:
            # Attribute time to the lane of the previous step
            prev_lane = steps[i - 1]["lane"]
            lanes[prev_lane] += duration
        prev_day = s["day"]
    return lanes


def find_failure_points(steps):
    """Return list of steps with failure points."""
    failures = []
    for s in steps:
        if s["failure"]:
            failures.append(s)
    return failures


def print_lane_totals(lane_totals):
    """Print days by lane."""
    print("\nDAYS BY LANE (time from one step to the next):")
    print("-" * 40)
    for lane, days in lane_totals.items():
        print(f"  {lane:<12}: {days} days")
    total = sum(lane_totals.values())
    print(f"  {'TOTAL':<12}: {total} days")


def print_failures(failures):
    """Print failure points with fixes."""
    print(f"\nFAILURE POINTS IDENTIFIED: {len(failures)}")
    print("-" * 70)
    for f in failures:
        print(f"\n[{f['id']}] {f['action']} (day {f['day']})")
        print(f"  Problem: {f['failure']['problem']}")
        print(f"  Fix: {f['failure']['fix']}")


# Run the analysis
print_blueprint(STEPS)

lane_totals = total_days_by_lane(STEPS)
print_lane_totals(lane_totals)

failures = find_failure_points(STEPS)
print_failures(failures)

# Summary
print("\n" + "=" * 70)
print("SUMMARY")
print("=" * 70)
print(f"Total complaint duration: {STEPS[-1]['day']} days")
print(f"Frontstage time: {lane_totals['frontstage']} day(s)")
print(f"Backstage time: {lane_totals['backstage']} days")
print(f"Support time: {lane_totals['support']} days")
print(f"Failure points: {len(failures)}")
_ = print("The form takes 2 minutes; the wait takes 11 days.")

======================================================================
WARD DESK STREETLIGHT COMPLAINT BLUEPRINT
======================================================================
Step  Lane         Action                              Day  
----------------------------------------------------------------------
S1    frontstage   Resident files complaint via app    0    
S2    support      SMS confirmation sent               0    
S3    backstage    Ticket assigned to ward engineer    1    
S4    backstage    Engineer inspects streetlight       3    
S5    backstage    Engineer logs parts needed          4    
S6    support      Contractor notified for repair      7    
S7    frontstage   Resident receives closure SMS       11   
======================================================================

DAYS BY LANE (time from one step to the next):
----------------------------------------
  frontstage  : 0 days
  backstage   : 6 days
  support     : 5 days
  TOTAL       : 11 days

FAILURE POINTS IDENTIFIED: 3
----------------------------------------------------------------------

[S2] SMS confirmation sent (day 0)
  Problem: SMS delayed up to 20 minutes
  Fix: Show in-app confirmation immediately; SMS as backup

[S4] Engineer inspects streetlight (day 3)
  Problem: Engineer re-routed to urgent complaint
  Fix: Auto-notify resident of delay with new estimate

[S6] Contractor notified for repair (day 7)
  Problem: Contractor not called until day 7
  Fix: Trigger contractor call when parts logged, not after

======================================================================
SUMMARY
======================================================================
Total complaint duration: 11 days
Frontstage time: 0 day(s)
Backstage time: 6 days
Support time: 5 days
Failure points: 3
The form takes 2 minutes; the wait takes 11 days.

The numbers tell a story the journey map only hinted at. Frontstage time is near zero: the resident fills in a form and waits. Backstage time is 6 days; support time is 5. The wait is not in the form; it is in the engineer’s schedule and the contractor’s notification rule.

Each failure point names a fix:

1. Show in-app confirmation immediately; SMS as backup.
2. Auto-notify resident of delay with new estimate.
3. Trigger contractor call when parts logged, not after.

The fixes are hypotheses to test. A future-state blueprint draws what the service could be, with the fixes in place and the wait shorter. The current-state map comes from research; the future-state map is a bet that research will check.

Multi-channel journeys and fallback designs

A touchpointtouchpoint: Any moment where a person interacts with a service: an app screen, an SMS, a phone call, a letter, a counter visit or any other channel. is any moment where a person interacts with a service: an app screen, an SMS, a phone call, a letter, a counter visit. Point 3 of the GOV.UK Service Standard, “provide a joined up experience across all channels”, means a journey that starts in one channel can continue in another without forcing the person to repeat themselves.

The streetlight journey has three channels: app, SMS and phone. The SMS at step S2 is the single point of failure: if it is delayed, the resident has no way to know the complaint was received. A fallback design might show an in-app status screen that updates immediately, with the SMS as a secondary confirmation. The phone call at the Wait stage is a workaround for a channel break: the service did not reach out, so the resident reached in.

A service blueprint can mark each touchpoint with its channel. When two touchpoints in sequence use different channels, the design owes an answer: what happens if the second channel fails?

Practise

The blueprint below is missing its failure points. Add the three the trace found, each with the lane that owns it and a fix the team could test:

"""
Complete the Ward Desk service blueprint by adding backstage actions,
links and failure points.
"""

# Partial blueprint with frontstage and support lanes filled in
BLUEPRINT = {
    "steps": [
        # Frontstage (resident-facing)
        {"id": "F1", "lane": "frontstage", "action": "Resident files complaint via app", "day": 0},
        {"id": "F2", "lane": "frontstage", "action": "Resident receives closure SMS", "day": 11},
        # Support systems
        {"id": "S1", "lane": "support", "action": "SMS gateway sends confirmation", "day": 0},
        {"id": "S2", "lane": "support", "action": "Contractor receives repair notification", "day": 7},
        # TODO: Add backstage actions (B1, B2, B3, etc.)
        # Example: {"id": "B1", "lane": "backstage", "action": "...", "day": ...}
    ],
    "links": [
        # TODO: Link frontstage steps to their backstage counterparts
        # Example: {"frontstage_id": "F1", "backstage_id": "B1"}
    ],
    "failure_points": [
        # TODO: Add 3 failure points with step_id, problem and fix
        # Example: {"step_id": "S1", "problem": "...", "fix": "..."}
    ],
}


def get_lanes(blueprint):
    """Return the set of lanes in the blueprint."""
    return set(s["lane"] for s in blueprint["steps"])


def get_step_ids(blueprint):
    """Return the set of step ids."""
    return set(s["id"] for s in blueprint["steps"])


def validate_blueprint(blueprint):
    """Check that the blueprint meets the requirements."""
    lanes = get_lanes(blueprint)
    step_ids = get_step_ids(blueprint)
    errors = []

    # Check the three lanes of steps are present (the line of visibility is a boundary, not a lane)
    required_lanes = {"frontstage", "backstage", "support"}
    missing = required_lanes - lanes
    if missing:
        errors.append(f"Missing lanes: {missing}")

    # Check every frontstage step has a backstage link
    frontstage_ids = {s["id"] for s in blueprint["steps"] if s["lane"] == "frontstage"}
    linked_frontstage = {link["frontstage_id"] for link in blueprint["links"]}
    unlinked = frontstage_ids - linked_frontstage
    if unlinked:
        errors.append(f"Frontstage steps without backstage links: {unlinked}")

    # Check failure points reference valid step ids
    for fp in blueprint["failure_points"]:
        if fp["step_id"] not in step_ids:
            errors.append(f"Failure point references non-existent step: {fp['step_id']}")
        if len(fp.get("fix", "")) < 20:
            errors.append(f"Fix for {fp['step_id']} is too short (needs 20+ chars)")

    # Check exactly 3 failure points
    if len(blueprint["failure_points"]) != 3:
        errors.append(f"Need exactly 3 failure points, found {len(blueprint['failure_points'])}")

    return errors


# Run validation and print results
errors = validate_blueprint(BLUEPRINT)
if errors:
    print("VALIDATION ERRORS:")
    for e in errors:
        print(f"  - {e}")
else:
    print("Blueprint is valid!")
    print(f"Lanes: {sorted(get_lanes(BLUEPRINT))}")
    print(f"Steps: {len(BLUEPRINT['steps'])}")
    print(f"Links: {len(BLUEPRINT['links'])}")
    print(f"Failure points: {len(BLUEPRINT['failure_points'])}")

_ = BLUEPRINT

"""Sample tests for the service blueprint exercise."""

from blueprint import BLUEPRINT, validate_blueprint


def test_blueprint_passes_its_own_validation():
    """The validation the file runs finds nothing left to fix."""
    errors = validate_blueprint(BLUEPRINT)
    assert errors == [], f"validate_blueprint still reports: {errors}"


def test_all_lanes_present():
    """Check that frontstage, backstage and support lanes exist."""
    lanes = set(s["lane"] for s in BLUEPRINT["steps"])
    assert "frontstage" in lanes, "Missing frontstage lane"
    assert "backstage" in lanes, "Missing backstage lane"
    assert "support" in lanes, "Missing support lane"


def test_frontstage_steps_linked():
    """Check every frontstage step has a backstage link."""
    frontstage_ids = {s["id"] for s in BLUEPRINT["steps"] if s["lane"] == "frontstage"}
    linked_ids = {link["frontstage_id"] for link in BLUEPRINT["links"]}
    unlinked = frontstage_ids - linked_ids
    assert len(unlinked) == 0, f"Frontstage steps without links: {unlinked}"


def test_failure_points_count():
    """Check exactly 3 failure points."""
    assert len(BLUEPRINT["failure_points"]) == 3, f"Need 3 failure points, got {len(BLUEPRINT['failure_points'])}"


def test_failure_points_reference_valid_steps():
    """Check failure points reference steps that exist."""
    step_ids = {s["id"] for s in BLUEPRINT["steps"]}
    for fp in BLUEPRINT["failure_points"]:
        assert fp["step_id"] in step_ids, f"Failure point references non-existent step: {fp['step_id']}"


def test_fix_text_length():
    """Check each fix is at least 20 characters."""
    for fp in BLUEPRINT["failure_points"]:
        fix_len = len(fp.get("fix", ""))
        assert fix_len >= 20, f"Fix for {fp['step_id']} too short: {fix_len} chars"

{"id": "B1", "lane": "backstage", "action": "Ticket created in system", "day": 0}

{"frontstage_id": "F1", "backstage_id": "B1"}

Then a short round of questions on the whole lesson, which returns to whatever you are least sure of:

Interview questions

A common question for product and UX roles at companies that build public or enterprise services is when to reach for a journey map and when for a service blueprint.

Warm-up (fresher to 2-5 years): How do a journey map and a service blueprint differ, and when would you use each one?

A journey map focuses on one persona’s experience: stages, actions, thoughts, feelings and pain points, all from the person’s perspective. A service blueprint extends that downward to show the organisation’s side: frontstage actions the person sees, backstage actions staff take, and the support systems underneath. Use a journey map when the question is “what does the person feel and where do we let them down?” Use a service blueprint when the question is “why does the service fail here and who owns the fix?”

Key takeaways

• A journey map traces one persona through stages, actions, thoughts, feelings and pain points, with every pain point backed by research evidence — a quote, an observation or a support ticket.
• A service blueprint adds the organisation’s side: frontstage, line of visibility, backstage and support, exposing failures that the person using the service never sees.
• Current-state maps come from research; future-state maps are hypotheses that research checks before the team ships.
• Multi-channel services need fallback designs at every channel handoff; a journey that breaks when an SMS is delayed needs a backup path the person can see.