Deliver One Promise at Each Critical Moment
In experience design, loading a single moment with too many benefits leaves people unsure what promise is actually being delivered.
Article Experience & Interaction Technology
Design recovery into the journey; don't improvise it
In the service blueprint, if recovery design still sketches only the happy path, what happens is: one error and everyone improvises; experience depends on who shows up. The steadier way is to design the recovery path and happy path together, then use the recovery path to lock that choice down.
Key points
- In the service blueprint, recovery design shouldn't stay as only designing the happy path.
- Leave it alone, and the same thing keeps happening: one error and everyone improvises; experience depends on who shows up.
- Start over: design the recovery path and happy path together.
- Write the choice into the recovery path—service and brand together.
- After this, review on one question only: is the first step after an error already written down.
01What recovery design must stop
What recovery design must first stop is designing only the happy path. In the service blueprint, if you can't stop that, you get: one error and everyone improvises; experience depends on who shows up.
What you keep doing can be very small. Small is how you hold the line on designing recovery and happy paths together.
Design the recovery path and happy path together. If you can't do this, recovery design is still just the happy path.
02Where recovery design's blur leaks out
Blur usually leaks from well-meaning additions. People add clauses to cover more ground and slip recovery design back into just the happy path.
Every addition that doesn't loop back to the core problem makes the boundary harder to keep. The problem is: one error and everyone improvises; experience depends on who shows up.
03Start with a negative list for recovery design
A negative list works better than adjectives. Write down when recovery design does not apply, and the team knows this isn't a slogan.
Keep the list short—short enough that a blueprint review can see it whole.
04Use tools to keep recovery design from overreaching
The recovery path is for stopping overreach, not collecting inspiration. Out-of-scope ideas can exist, but they can't pose as recovery design.
You stop it because service and brand work together, and they have the right to say no.
05What happens after recovery design crosses the line
When something does overreach, don't just patch one deliverable. Go back to the recovery path and add the condition this time circumvented.
Then review again with the same question: is the first step after an error already written down.
Framework
The four-layer structure of recovery design
From what cannot be traded away to tools ready for the field, each layer answers one question only—and keeps recovery design from becoming just the happy path.
L1First step
This layer names what cannot be compromised in recovery design.
L2What can be said
This layer collects recovery design into checkable conditions.
L3What We Can't Promise
This layer sets what recovery design can vary across different contexts.
L4Who does it
This layer hands recovery design to its users and notes exceptions.
Note: This diagram is a conceptual framework. It explains a way of thinking and is not statistical data. Source: Qingmei Future Insights.
Recommended actions
Action 01
Start from the site
Mark where recovery design is actually called in the blueprint—don't start by rewriting the happy path.
Action 02
Keep it to one page
Replace longer explanations with the recovery path; keep only what supports 'design the recovery path and happy path together.'
Action 03
Judge it by one question
In blueprint review, ask only: is the first step after an error already written down. If you can't answer, it's not yet a decision.
Action 04
Name the owner
Service and brand together. Recovery design without a keeper gets quietly rewritten in conflicts.
Related
All insightsRelated insights
Give Every Touchpoint a Purpose, or the Map Is Just an Inventory
When an experience audit treats a complete touchpoint map as the finished result, the map may be comprehensive while leaving everyone unclear about why each touchpoint exists.
Assess Both Touchpoint Coverage and Depth
In diagnostic projects, if touchpoint audits still only check whether a touchpoint exists, the result is often touchpoints that are present but not deep enough to influence decisions.