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