A new designer joins a team and wants to change the primary button color from the existing '#2563EB' to a slightly different blue they prefer aesthetically. Which piece of documentation would most effectively prevent this from causing problems?
AA screenshot showing the original button in context across multiple screens
BThe rationale explaining that this specific blue was chosen to meet WCAG AA contrast requirements, was selected after testing three alternatives with users, and aligns with the brand's trust-signaling palette
CA changelog listing every time the button color was previously changed
DA style guide listing all approved colors in the design system
The style guide (option D) tells the new designer what color to use but not why — it cannot explain what they would break by changing it. The rationale (option B) captures the constraints (accessibility compliance), the evidence (user testing), and the alternatives already rejected. With this information, the new designer understands that the color is not aesthetic preference but a functional requirement with documented justification. The 'why' is what transforms a spec into a constraint — and it is exactly what prevents the next designer from unknowingly breaking something that took significant work to get right.
Question 2 Multiple Choice
A designer argues: 'I shouldn't need to write design rationale — the design file is self-documenting because all the specs are visible in Figma.' What is the critical flaw in this view?
AThe designer is right — modern design tools capture all the relevant decision information
BDesign files capture what was decided (the final specs and values), but not why — they show the color but not the accessibility testing, user research, and rejected alternatives that led to it. Without rationale, future designers cannot distinguish intentional constraints from arbitrary choices
CThe designer should document rationale only for controversial or contested decisions
DDesign files are insufficient only for very large systems with more than 50 components
This is the central misconception named in the Core Idea: documentation that only records what was decided is of limited value. The Figma file shows '#2563EB'; it does not show that three alternative blues were tested and rejected, that this specific value was chosen because it passes WCAG AA at 4.6:1 contrast ratio, or that users in testing found it 23% more clickable. Without that rationale, a future designer sees a color and has no way to know whether it is a carefully engineered constraint or an arbitrary leftover. The 'why' is what allows the design system to be maintained intelligently rather than randomly.
Question 3 True / False
Good design documentation should capture not just the final decision but also the alternatives that were considered and the reasons they were rejected.
TTrue
FFalse
Answer: True
True — documenting rejected alternatives is one of the most valuable things rationale can contain. It prevents future team members from independently rediscovering and relitigating decisions that were already thoroughly explored. If three button styles were evaluated and two rejected for specific reasons, recording those reasons means the next designer who thinks 'what about a pill-shaped button?' can immediately see that it was considered, understand why it was rejected, and apply their energy elsewhere. Without this, teams repeatedly revisit the same decisions — a direct source of wasted effort that the Core Idea describes as 'reinvention.'
Question 4 True / False
Design documentation is primarily useful for external stakeholders and can be safely skipped for internal design systems where existing team members already understand the decisions.
TTrue
FFalse
Answer: False
False — internal teams change over time through hiring, departures, role changes, and simple forgetting. The Explainer states this explicitly: 'the moment those people leave, go on vacation, or simply forget why they made a particular decision, the system starts to drift.' Even original decision-makers forget their own reasoning within months. A design system that exists only in team members' heads is fragile and opaque — a problem that compounds over time as decisions accumulate without documentation. The documentation is for the future state of the team, not just its present composition.
Question 5 Short Answer
What is the practical test of whether design documentation is sufficient, and why is this a high bar to meet?
Think about your answer, then reveal below.
Model answer: The practical test is whether a new team member can implement a component correctly, handle edge cases the original designer anticipated, and extend the system in its intended direction — all without asking the original designer a single question. This is a high bar because it requires documentation to capture not just specifications but the complete reasoning: what problem was being solved, what constraints were in play, what alternatives were rejected and why, and which principles guided the final decision. Documentation that only lists specs fails this test entirely — it tells you what to do but not what not to do, why, or how to handle situations the original designer thought about but didn't expose in the final design.
The 'new team member' test is a concrete operationalization of what it means for a design system to be self-sustaining. It separates documentation that feels complete from documentation that actually is — because the test requires the documentation to transfer not just information but judgment. Documentation that passes this test means the system can grow and adapt without requiring access to its creators, which is the whole point of building a scalable design system rather than a personal style guide.