In this section: Chapters
- Ch.1: The Day After
- Ch.2: Tribal Knowledge Is the Bottleneck
- Ch.3: Contracts Are the Answer
- Ch.4: The Capabilities Graph
- Ch.5: Extraction Over Refactoring
- Ch.6: The Contract Lifecycle
- Ch.7: The Architect
- Ch.8: The Developer
- Ch.9: The PM / PO
- Ch.10: The Designer
- Ch.11: The Leadership Team
- Ch.12: The Company That Gets There First
- Appendix
- Appendix A: Contract Schema Reference
- Appendix B: Legibility Audit Framework
- Appendix C: Extraction Priority Matrix
The Designer
The design review just ended. Laptops are closing. Over the last forty minutes, the designer explained things that live in no file the company keeps. Why a component is named for what it does instead of where it sits on the screen. Why a destructive action renders differently on mobile, not as a style choice but because the confirmation behavior has to change and that rule has never been written down anywhere but her head. Why a verification flow has three steps instead of one, a decision made two years ago with legal, for a reason she's now the only person left who remembers.
Everyone in that room understood what to build. Chapter 10 points out that none of the reasoning that produced that understanding exists in an artifact anyone else can open. The Figma file shows what things look like. The design system documents tokens and components. Neither one was built to carry a behavioral rule forward, let alone hand it to an agent generating a new surface six months later.
This is the chapter about what it means to design an interaction contract instead of just a screen. Not a new set of Figma layers, but a way of writing down the behavioral logic a designer already holds, so the decision doesn't quietly disappear the day she's not in the room to explain it again.