Designing for a product that is sometimes wrong, often slow, and never quite the same twice. The interface carries more weight here than in deterministic software, because it is what converts an imperfect answer into something a person can safely use.
| # | Lesson | The question it answers |
|---|---|---|
| 01 | The Trust Budget | You get a fixed number of wrong answers. How do you spend them? |
| 02 | Streaming and Perceived Latency | How do you make slow feel fast without lying? |
| 03 | Showing Uncertainty | How do you communicate doubt without making the product feel broken? |
| 04 | Designing for Wrong Answers | Undo, edit, diff review, escalate: what has to exist? |
| 05 | The Empty Prompt Box Problem | What does a user do when anything is possible and nothing is suggested? |
| 06 | Feedback Loops in the Interface | How does the interface feed the eval set? |
| 07 | Attribution and Citation in the Interface | How do you show where an answer came from without clutter? |
| 08 | Generative and Adaptive Interfaces | When should the interface itself be generated? |
| 09 | Voice and Multimodal Surfaces | What changes when there is no screen, or more than text? |
| 10 | Progressive Autonomy | How does a product earn the right to do more over time? |
| 11 | Onboarding an AI Feature | How do you teach a capability with no fixed shape? |
| 12 | Worked: A Copilot Surface | One real interface, with the trust decisions named |