Reference · Chapter 11
The Short List
Seven things to bring to the next build review. Run them before the sprint demo, not after the post-mortem.
- 01
Specify the Trust Architecture before designing the interface.
Name the accuracy requirements, the transparency commitments, the consistency rules, and the alignment constraints. If any layer is absent from the spec, it will be absent from the product. Trust is not a quality attribute layered on after the product works. It is an architectural requirement.
All roles
- 02
Design the failure path before the success path.
What does the product do when it is wrong? What does it do when it does not know? The product's behavior in those moments is its trust character. A system that fails gracefully earns more trust than a system that succeeds 100% of the time in a narrow range and fails badly outside it.
Design, PM
- 03
Put visual confidence in the design tokens.
High-confidence output and uncertain output should not look the same. Decide the typographic system for uncertainty, whether weight, color, or both, and apply it consistently across every surface. The test: can a user, looking at two outputs side by side, tell which one the product is more confident about?
Design, Design Systems
- 04
Audit the qualifications in the product's copy.
Separate the ones that tell the user something specific from the ones that protect the product legally. Remove the theater. Make the earned qualifications precise and actionable. A qualification that pads an answer does nothing for the user. Most products have too much of the second kind.
Prompt Design Engineer, Content
- 05
Define the escalation categories.
Which classes of question is this product not qualified to answer alone? Build the recognition of those categories into the product before launch, not as a fallback but as a designed path. A product that fails a user at a vulnerable moment does not lose only that user.
PM, Design, Engineering
- 06
Design the recovery path.
When a user has acted on a wrong answer, what happens next? How does the error surface? What can be reversed, and how quickly? A product without a recovery path has designed only for success. The interaction that closed, the ticket that was filed, the message that was sent: if the agent did it wrong, the user needs a path back.
Design, Engineering
- 07
Read the Air Canada case to anyone who believes trust is the legal team's problem.
In 2024, Air Canada's chatbot gave a passenger incorrect information about bereavement fares. He relied on it. Air Canada argued the chatbot was responsible for its own outputs. The tribunal disagreed. Air Canada paid. The failure was not that the chatbot was wrong. The failure was that the product was not designed to handle being wrong. That is a design failure, not a model failure.
Everyone in the room
Print it
Bring it to the build review. Run it aloud. If any item prompts a long discussion, that item is the design gap worth fixing.
For the PM
The Short List above is a build review checklist. Run it before the sprint demo, not after the post-mortem. The Trust Architecture spec, the failure path, the escalation categories: these are product decisions that engineering cannot make alone and design cannot make alone. They require the PM to have an opinion and put it in the spec. The PM who brings this list to the build review is the person in the room who prevents the Air Canada outcome.
For the solo practitioner
The Short List is also yours. You bring it to yourself, before you ship. The absence of a build review room does not mean the absence of a build review. It means you are the person in the room. Run through each item before the product goes live. The Air Canada outcome is not a large-team problem. It is a no-one-checked problem.
From the book