Interface Patterns for Trust

Part XIII closes on the question the rest of it was in service of: what makes a person willing to use this, and willing to not use it when they should not. That second half is the harder one.

Trust is not the goal

The framing that makes the rest of this chapter coherent, and it is the opposite of how these features are usually pitched:

The goal is calibrated trust, not maximum trust. An interface that makes people trust the agent more than it deserves is a failure with good metrics.

There are two ways to be wrong. Under-trust produces disuse: the agent is correct and ignored, and the investment returns nothing. Over-trust produces misuse: the agent is wrong and believed, which is the confident-wrong-answer failure this book has been circling since Part IV, now arriving through the interface.

Almost all design effort goes into the first. The research literature notes that explainability work has largely emphasised preventing disuse while neglecting the mitigation of overtrust. One finding should be enough to make anyone cautious:

In studies where the model was making incorrect predictions, people performed best in the conditions they preferred and trusted the least, and rated as the hardest to use. Comfort and correctness came apart, and the interface that felt best produced the worst decisions.

The lever those studies were actually testing has a name: cognitive forcing, designs that interrupt automatic acceptance rather than explaining after the fact. Making the recommendation something the user requests instead of something that appears; surfacing the model's uncertainty as part of the decision rather than as a footnote. Against ordinary explain-the-answer interfaces these significantly reduced over-reliance, and the trade-off came out as a clean inverse: the designs that reduced over-reliance most were the ones people rated worst.

Two things follow, and the second is the uncomfortable one. Friction is not a side effect here, it is the mechanism. So an interface review that optimises for "felt smooth" is selecting against the thing that worked. And the benefit was concentrated in people already inclined to think things through, which means the intervention does least for the population most at risk: the reviewer on their ninetieth approval of the morning, who is exactly who this fails.

Provenance, honestly

Start with the pattern this book has advocated hardest, and the finding that complicates it.

Users rarely verify the sources an AI cites, while reporting that those citations increase their confidence. The citation raises trust without being checked, which is precisely the shape of the failure above.

And the thing going unchecked does not hold up well. An audit of generative search engines found only about half of generated sentences fully supported by their citations, and roughly three-quarters of citations actually supporting the sentence they were attached to. Put the two findings together and the picture is worse than either: trust rises on the presence of a citation, checking does not happen, and the underlying support rate is close to a coin flip. Notably, the trust gain held even when the citations were flawed. The marker is doing the work, not the evidence.

That is not an argument against citations, but it does change the argument for them. It is the measured case for the verification the retrieval part builds rather than trusting the marker. Three reasons survive:

They are checkable by the people who matter. Not the user in the flow: the reviewer at an approval gate, the auditor eleven months later, the engineer during an incident. Those readers do check, and for them the link is the whole artifact.

They impose discipline on the system. A pipeline that must produce a citation cannot answer from nothing. Much of the value is extracted before the interface exists, in the retrieval layer that now has to return provenance.

They are the difference between a claim and an assertion in the record. The audit trail needs the source; the UI is just where it also happens to be visible.

The design consequence of "nobody clicks" is specific: put the signal inline, not behind the link. "Policy RET-14 §3, revised March 2026" tells a sceptic more at a glance than a superscript numeral does after a click nobody makes.

Progress

Streaming UX covered the mechanics. The reason it belongs in a chapter about trust is a distinct failure mode with a good name: the black-box launch, a clean interface showing inputs and outputs and nothing in between.

The problem is not that it feels slow. It is that when the agent chooses wrong, the user cannot see which alternatives it considered or why it picked this one, and therefore cannot correct it efficiently. They can only reject the whole answer and start again, which is the expensive kind of disagreement.

Show the path, not just the destination. Not for reassurance. So that disagreement can be specific.

Undo, and the three things it is not

Every consequential action should produce a receipt: what changed, where, the references, the timestamp, which agent did it, and what can be done about it.

But an interface built over Part XI has to be honest about a distinction most UIs collapse:

Showing an Undo button on an email that has been delivered is a lie the interface tells on behalf of the system. The button must inherit its label from the tool's reversibility class, which means the catalogue's classification reaches all the way to the front end. If it does not, someone will add a hopeful Undo to a class ⑤ write.

Confidence, which is the contested one

The evidence here is genuinely mixed. Confidence scores can help calibrate trust, while explanations can increase trust and over-reliance merely by being present, read as a general signal of competence rather than for their content.

The specific problem with a displayed number is that a confidence value a model produced is not a measurement, and putting it in a UI element that looks like a gauge invites the reader to treat it as one. 0.72 has no denominator, no calibration curve, and no relationship to how often that model is right at 0.72.

The defensible version is to express uncertainty as behaviour rather than as a number:

   ✗  Confidence: 72%

   ✓  Two policies could apply here and they disagree about
      the return window. Escalating rather than guessing.

   ✓  The warehouse query returned no rows for Q2 — that may
      be correct, or the region filter may be wrong. Not sending.

That is the same principle as preferring an architecture whose failure mode is a refusal, surfaced. A stated reason for hesitating is checkable; a percentage is not.

Failure states, the most under-designed surface

Three requirements, and most agent interfaces satisfy none of them:

Say what failed, in the user's terms. Not "something went wrong," and not a stack trace. The error taxonomy from Part VIII has already produced text written for a consumer; the UI's job is not to discard it.

Say what is still true. A partial result is not nothing. "Found the order and the contract; the warehouse is unavailable, so the volume figure is missing" preserves most of the work. Collapsing to a generic failure throws away three successful lookups the user has already paid for.

Say what happens next, and who is doing it. "Escalated to the support queue. Someone will pick this up" is a state. "Please try again" delegates the recovery to the person least equipped to perform it.

A failure state that blames the user, or that says nothing, spends the trust the other four patterns built.

Atlas, concretely

The measurable claim, and the one worth putting on a dashboard instead of a satisfaction score: of the answers Atlas got wrong, how many did a human catch before they reached a customer? That number is what calibrated trust looks like from the outside, and it is the only one that distinguishes an interface that helped from one that merely felt good.

Part XIII ends here. The agent survives crashes, waits for people, streams what it is doing, renders what it found, and can now be disbelieved by someone who should disbelieve it.

References

• To Trust or to Think, Buçinca, Malaya and Gajos, CSCW 2021, cognitive forcing functions, and the gap between what reduced over-reliance and what participants preferred (author copy).
• Evaluating Verifiability in Generative Search Engines, Liu, Zhang and Liang, citation support rates measured in deployed systems.

Takeaways

• The goal is calibrated trust, not maximum trust. An interface that raises trust past what the agent deserves is a failure with good metrics.
• Two failure directions: under-trust produces disuse, over-trust produces misuse. Design effort overwhelmingly targets the first.
• In studies where the model was wrong, people performed best in the conditions they preferred and trusted least. Comfort and correctness came apart.
• Cognitive forcing, making the recommendation requested rather than automatic, putting uncertainty in the decision, cut over-reliance where plain explanations did not, and the designs that cut it most were rated worst. Friction is the mechanism, not a side effect.
• The benefit concentrated in people already inclined to deliberate, so it does least for the rubber-stamping reviewer who needs it most.
• Users rarely verify citations while reporting that citations raise their confidence: the exact shape of over-trust. The gain holds even when the citations are flawed, and audits put full support at around half of generated sentences, so the marker is doing the work rather than the evidence.
• Citations still earn their place: checkable by reviewers and auditors, disciplining on the pipeline, and load-bearing in the audit record. They do not make users verify, and claiming they do is wrong.
• Since nobody clicks, put the signal inline: a policy name, section, and revision beats a superscript numeral.
• The black-box launch shows inputs and outputs and nothing between, which prevents specific disagreement. Show the path so a user can correct rather than reject.
• Undo, reverse, and send-a-correction are three different things. The button label inherits from the tool's reversibility class, or someone will put Undo on a sent email.
• A model-produced confidence value is not a measurement, and a gauge invites reading it as one. Express uncertainty as behaviour: a stated reason for hesitating, or an escalation.
• Failure states need three things: what failed in the user's terms, what is still true, and what happens next with an owner. "Please try again" delegates recovery to the least equipped party.
• Trust theatre raises trust without raising accuracy, and presence alone signals competence. Test it: if this makes the agent no more correct, does it make a wrong answer more likely to be accepted?
• The metric that matters is not satisfaction. It is what fraction of wrong answers a human caught before they reached a customer.

Next: Eval Discipline, Part XIV, and the question this part cannot answer: whether any of it is actually working.