Review
When I started working through what a proper design system actually requires, this was the book every practitioner pointed me toward. It was published in 2017, and that matters. Not because the ideas have aged badly, but because the tooling chapters describe a workflow that predates Figma, and most teams now live inside a world Figma built.
That gap creates a frustrating read. The conceptual core is strong: what patterns are, why naming them well is a design decision rather than a labeling task, how shared language prevents the slow erosion of a product's visual coherence. Those sections I kept returning to. The tooling chapters I read once and moved past.
The functional versus perceptual pattern distinction is genuinely useful. So is the argument that design principles need to be specific enough to rule something out, not just to sound good in a document. The governance question, whether your system should be centrally curated or distributed across product teams, gets more honest treatment here than in most conference talks on the subject.
I cannot give this book a clean recommendation. The theory is the best account of design systems I have read, and a post-Figma update would make it essential. Until someone writes that book, this is as close to essential as the field currently has.
Key Takeaways
The parts worth keeping:
Design principles that actually work
- Design principles are decision criteria, not decoration. A principle that could appear on any company's wall is not a principle, it is a platitude. Stress-test each one: would the opposite be a reasonable choice for any sensible team? If yes, the principle is too generic to do any work.
- Aim for 3 to 5 principles. Pair each one with a real example from your own product. Keep them visible in daily work. A principle buried in a document influences nothing.
Two kinds of patterns
Kholmatova draws a clean line between functional and perceptual patterns. Both matter; they fail in different ways when poorly managed.
| Pattern type | What it covers | Where it goes wrong |
|---|---|---|
| Functional | Interface building blocks defined by the behavior they enable: buttons, navigation, form inputs, modals | Duplicate components appear when teams build in parallel without a shared inventory |
| Perceptual | Brand expression through sensory elements: color, typography, motion, texture | Personality dilutes when teams apply these inconsistently across surfaces |
- Start a functional pattern audit with an interface inventory: print all your screens, cut the components apart, group by type. Patterns that serve the same purpose but look different are candidates for unification.
- When defining a pattern, name what it does, not just what it is. Knowing the purpose tells you how far it can be modified before it becomes a different pattern entirely.
- Concentrate brand personality in micro-interactions and signature moments. Generic perceptual choices are invisible; distinctive ones are what people remember.
What holds a system together
- A design system is curated patterns plus the practices for creating, sharing, and evolving them. Teams that build pattern libraries without building the practices end up with a library nobody updates.
- Shared language is load-bearing. Without it, teams cannot design coherently together, and the same concept gets named three different things across three different product areas. Naming is not cosmetic. A well-chosen name shapes how a pattern gets used and reduces the chance of duplicates forming in parallel.
- Fragmentation happens silently. A fragmented system produces a fragmented user experience, and that fragmentation tends to be invisible to the people inside it until a new team member or an outside audit makes it obvious.
The governance question
- Three dimensions define what kind of system you have: how strict the rules are (strict to loose), how modular the components are (modular to integrated), and whether governance is centralized or distributed. Each is a spectrum, not a binary. Where your system should sit depends on your product and your org structure.
- Centralized governance gives you cleaner curation and clearer opinions. Distributed governance gives you broader adoption but creative direction dilutes over time. Conway's Law applies either way: your design system will eventually mirror your org chart whether you planned it that way or not.
- Make the business case explicitly. Reusing elements saves time. Visual inconsistency has a quantifiable cost. Site-wide changes get faster. If design system work is treated as a side project, it will be treated as a side project by everyone else too.