Service Recovery
Part of Customer experience for digital services
Connecting usability findings with service redesign
Trace a usability finding to its service cause, assign an owner and check whether the redesign improves the customer outcome.
A usability finding becomes a service improvement when the team identifies the cause, changes the part of the service that creates it and checks the customer’s outcome. The cause may sit behind the screen: a service rule, case queue, data hand-off or unclear responsibility. Editing the page helps when the page is the problem.
Trace the finding beyond the interface
Write the finding as an observed barrier to a specific task. For example, someone submits an address change but cannot tell whether future letters will use it. Keep that observation separate from possible explanations.
The confirmation might be unclear, the change might take time to reach another system, or staff might need to approve it. Each explanation calls for a different investigation and possible fix.
Trace an authorised test request or review appropriate service records from submission to the point where the result takes effect. Ask the teams involved what they receive, what decision they make and how the customer learns the outcome. Keep the investigation focused on the observed failure.
Match the intervention to the cause
| If the evidence shows… | Consider testing… |
|---|---|
| Customers misunderstand a label but the request processes correctly | Clearer wording and a task check. |
| Customers submit correctly but receive no meaningful confirmation | A status or confirmation change tied to the real processing state. |
| The request reaches a queue that cannot act on it | A routing or ownership change, then a check of the full task. |
| A rule requires information customers cannot reasonably provide | A review of the rule and a workable alternative route. |
These are possible responses, not diagnoses of a tested service. A finding may need more investigation before a team can choose among them.
Matching Interventions to Root Causes
- Cause: Misunderstanding of label
- Intervention: Clearer wording and task check
- Cause: No meaningful confirmation after submission
- Intervention: Status or confirmation tied to real processing state
- Cause: Request reaches inactive queue
- Intervention: Routing or ownership change, full task check
- Cause: Unreasonable information requirement
- Intervention: Rule review and alternative route
Give the change an owner and a success condition
Record the observation, affected task, possible cause, evidence still needed, responsible owner and intended customer outcome. Include the team that controls the underlying rule or process. A designer can improve an explanation but may not be able to change what happens after submission.
Decide what would count as improvement before changing the service. In the address-change example, customers would need to understand when the new address takes effect, and the service would need to use it at that point.
Check the proposed change in a prototype or controlled release, then review live records when available. Task completion, errors, repeat enquiries and customer feedback can help, but a falling enquiry count alone cannot prove the address was updated correctly.
Measuring Success in Service Redesign
- Task completion rate
- Increase expected
- Error rate
- Decrease expected
- Repeat enquiries
- Reduced count indicates improvement
- Customer feedback
- Positive sentiment on outcome clarity
Close the learning loop
Share what changed and what remains unresolved with the people who observed the research and those who deliver the service. If the first change fails, revisit the possible cause and test again. Keep the original observation connected to decisions, owners and the customer outcome.
