# The Trust Repair Sequence

> The thirty seconds after your product is confidently wrong decide whether the
> user keeps using it. Almost nobody designs this moment, which is why it is the
> most available advantage in the field right now. Six steps, in order, with the
> copy and the ownership for each.

---

## What this covers

Not outages. An outage is honest: the product is down, everyone knows, and trust
takes almost no damage because nothing was claimed. This is the other failure,
the one where the product asserted something specific and wrong, in a confident
voice, and the user acted on it.

That failure damages trust differently. The user does not just doubt the answer,
they doubt every previous answer they did not check. Repair has to address the
back catalogue, not only the current mistake.

---

## The sequence

Order matters more than eloquence. Out of order, even good copy fails.

### 1. Detect

Before anything else, know it happened.

Sources, roughly in order of how bad it is that this is how you found out:

- The system's own check caught it.
- The user corrected it in-product.
- The user complained.
- Somebody outside noticed publicly.

**Design job:** make in-product correction the easiest path available. Every
correction is a detection you would not otherwise have had. If reporting a wrong
answer takes more effort than shrugging and moving on, you have chosen not to
know.

**Owner:** design owns the correction affordance. Engineering owns automated
detection.

### 2. Admit, in the same place

The correction appears where the wrong answer appeared. Not in an email, not in a
changelog, not in a banner on a different screen.

> "This was wrong. The figure shown here came from the wrong date range."

Two rules. Say "wrong," not "may not have been fully accurate." And do it in the
first sentence. Users have already decided how they feel by the second one.

**Owner:** design writes this copy in advance, not during the incident.

### 3. Contain

Tell them the blast radius before they ask, because the unasked question is
always "what else was wrong."

> "This affected the usage summary between the 3rd and the 9th. Your billing and
> exports were not affected."

Naming what was *not* affected does more work than naming what was. Without it,
the user assumes everything.

If you do not know the radius yet, say that and say when you will know. A stated
"we are still checking, update by 4pm" holds far better than silence.

**Owner:** engineering determines the radius. Design owns how it is stated.

### 4. Correct

Fix it, and show the fix in a way the user can verify.

- The corrected value, visibly labelled as corrected.
- What changed, not just the new state.
- If the user acted on the wrong answer, the path to unwind that action.

Never quietly replace the wrong value with the right one. Silent correction is
the single fastest way to lose a user who noticed, because they now know the
product edits history without telling them.

**Owner:** design owns the corrected-state treatment.

### 5. Prevent, visibly

The step teams skip, and the one that does most of the repair.

> "We added a check that catches date-range mismatches before the summary
> renders."

One sentence about the mechanism, not a promise about caring more. "We take
accuracy seriously" repairs nothing. A named check repairs a lot, because it
tells the user the class of error is closed, not just this instance.

**Owner:** design owns whether the prevention is visible in the product itself.
The strongest version is not a message, it is a new state the user can see: a
confidence signal where there was none, a source citation, a confirmation step.

### 6. Adjust the confidence posture

After a confident error, the product's voice on that surface changes. Not
forever, and not everywhere, but on that class of output for a while.

Concretely: move up a rung on the disclosure ladder, add the source, drop the
assertive phrasing. When the eval shows the class is fixed, move back.

This is the step that separates repair from apology. It costs something, which is
why it is believable.

**Owner:** design, and it goes in the decision record with a date to revisit.

---

## The thirty-second script

Write this per surface, before you need it. It is four sentences.

```
1. <Plain statement that this was wrong.>
2. <What was affected, and explicitly what was not.>
3. <The corrected state, and how to unwind anything done on the old one.>
4. <The specific check now in place.>
```

Have it written and approved before launch. During an incident, nobody writes
good copy, and the version that ships is the one somebody typed in a hurry with
legal reading over their shoulder.

---

## Severity, and what changes with it

| Severity | Definition | Admit where | Who signs off |
|---|---|---|---|
| Low | Wrong, easy to spot, no action taken on it | In place, inline | Design |
| Medium | Wrong, user likely acted, recoverable | In place plus notification | Design and PM |
| High | Wrong, irreversible action taken, or affects money, access, or safety | In place, notification, direct contact | Named exec |

Decide the tiers now. During an incident this table stops an argument about
process at exactly the moment you cannot afford one.

---

## Two things that make repair fail

**Repairing in a channel the user does not read.** A status page is not a repair.
It is a record of one.

**Apologizing more than correcting.** The ratio people notice is how much of the
message is about the fix versus how much is about how sorry you are. Aim for
three to one in favour of the fix.

---

## The one thing to do this week

Write the four-sentence script for the surface where a confident error would cost
you the most. Show it to whoever would have to approve it during a real incident.
Getting that approval on a calm Tuesday is worth more than any amount of
polishing the wording.

---

_From "Recovery and Trust Repair", chapter 11 of The Design Operating Model._
_falkster.com/design/recovery-and-trust-repair_