The stage metaphor that makes the whole topic click (Gecis)

Gecis borrows from theater to explain the difference between journey maps and service blueprints:

Front stage — what the audience (customer) sees. The performance itself. This is what a customer journey map shows.
Back stage — what happens behind the curtain to make the performance possible. Lights, sets, crew. This is what a service blueprint adds.
Behind-the-scenes — everything the organization has to do to make front + back stage possible. Internal processes, systems, employee support.

Journey maps show the customer's front-stage experience. Service blueprints show the whole production.

The Steve Jobs quote worth stealing

"You've got to start with the customer experience and work back toward the technology."

Journey maps and service blueprints are how you actually do that. Everything else is guessing.

Customer Journey Maps — the 5 components

A journey map captures what the user does, thinks, and feels over time as they interact with a service. Five components (Gecis's version, which is a good synthesis of standard practice):

1. Goal — what specific experience are you mapping? Onboarding? First purchase? Support interaction? A "to-be" future experience?

2. Actor — who's this journey about? Grounded in personas from real research.

3. Stages — the phases of the experience. Gecis uses the 5Es framework:

Entice — how does the user become aware?
Enter — how do they begin?
Engage — what's the core of the experience?
Exit — how do they complete/finish?
Extend — what happens after?

4. Touchpoints, emotions, thoughts — narrative of what the actor does, thinks, and feels at each stage. Emotions plotted as a single line across the map (the "emotional curve") showing ups and downs.

5. Opportunities — insights from the map. What needs to happen next? Who owns each change? Where are the biggest opportunities? How will improvements be measured?

Service Blueprints — the extra dimensions

A service blueprint extends a journey map by exposing the back stage. Five swim lanes:

Customer actions — from the journey map
Front stage — what happens in each touchpoint that's visible to the customer (employee interactions, app interactions)
Back stage — invisible-to-customer actions that support the front stage (kitchen prep, back-office processing)
Support processes — internal systems and interactions that support employees
Evidence — tangible elements the customer sees (uniforms, delivery vans, receipts, notification emails)

Plus three lines that separate the layers:

Line of interaction — direct customer/organization interactions
Line of visibility — visible vs. invisible activity
Line of internal interaction — customer-facing employees vs. back office

The Uxeria examples piece — what to take from it

Uxeria's article is a gallery of 10 real-world journey maps from various companies. Not much analytical content, but useful for:

Visual vocabulary — seeing how different teams visualize the same idea
Format inspiration — what to include, what to leave out, how to lay it out
Realistic complexity — real journey maps are messier than tutorial examples

Standout example types you'll see: LEGO's "Adventures in Experience Land" (very story-driven), Adaptive Path's Rail Europe journey (detailed and analytical), Starbucks (playful and brand-heavy). The pattern: no single "correct" format — pick the visual style that fits your organization and audience.

The Sailthru piece — marketing-flavored version of the same

Sailthru's article covers the same territory (define stages, capture touchpoints, identify emotions, spot opportunities) with a marketing lens rather than a UX one. Similar output, slightly different vocabulary (they talk about "conversion" more than "delight"). Nothing here that Gecis doesn't cover more thoroughly.

Two useful marketing-flavored additions from Sailthru:

Cross-channel emphasis — journey maps should span email, web, mobile, in-store, support — not just your app
Data-driven vs. assumption-driven maps — if it's not built on real behavioral data, it's a hypothesis map, not a journey map

The rules that keep journey maps useful

One persona, one journey per map. Trying to fit everyone on one map = unreadable.
Ground it in research. Same rule as personas, scenarios, empathy maps, mental models. Assumption-based maps are just team wishful thinking with nice graphics.
Include emotion. The emotional curve is often where the design opportunity is loudest. A functional-but-frustrating step deserves as much attention as a broken one.
Make opportunities actionable. Every low point should map to a specific opportunity, owner, and metric — otherwise the map is decoration.
Update as the product changes. Journey maps age fast. Living document or dead artifact.

When to use which

Situation	Tool
Understanding customer experience end-to-end	Journey map
Understanding a specific task or flow	User flow (see Cluster 1)
Exposing internal operational gaps behind the experience	Service blueprint
Understanding the reasoning behind behavior	Mental model

| Aligning stakeholders around who you're designing for | Personas + scenarios |