Home / The Higher Levels of a Design System
The Higher Levels of a Design System.
A design system needs more than components and agreeable principles. It needs an ethos strong enough to guide decisions when nobody is in the room.
Most design system principles are written to be agreed with, not used
"Be clear. Be human. Be consistent." Everyone nods. Nobody knows what to do differently on Monday.
The layer most teams skip is the ethos
The ethos isn't what the product should look like, or how each decision gets made. It's what the product is trying to be. Does it treat the user as someone who needs guidance, or someone who knows what they want? Defining that up front doesn't narrow your thinking. It focuses it. The narrowing comes later, when you put ink to paper and make the small decisions that add up to the experience.
I've seen principles documents survive team consensus because they said nothing specific enough to argue with. Most have no ethos behind them either. Without one, even well-meant principles have no direction.
Useful principles answer the question a designer faces
Instead of "be clear": "when two copy options both work, prefer the one that names what the user is doing over what the system is doing." Instead of "be human": "avoid system-state language like 'invalid input'; write for the person, not the error handler." The first kind gets agreed with. The second gets used.
Here's a test. Could a new designer use a principle to make a decision you weren't in the room for, and reach the conclusion you would have? Most principles fail it.
Slogan-level principles explain why inconsistency persists, even in teams that have invested heavily in design systems. Components govern the visual layer. Principles should govern the decision layer: what the product feels like to use, how trade-offs get resolved, what it's trying to do for a person. When principles are slogans, nobody governs that layer. Designers fill it in themselves, differently, every time.
A decision changelog helps
I don't mean a version log of component changes. I mean a record of reasoning: a date, a decision and what drove it. For example: "Moved away from system-state error language because it doesn't tell users what to do next. Default to an active verb that names the user's action, not the system's state."
Over time that record encodes how the team thinks. When a decision comes up for review, it stops everyone covering the same ground again.
A solo designer can keep the ethos in their head, and it will drift
A thought shifts gradually without you noticing. Words on paper take deliberate effort to change. Writing the ethos down isn't documentation for someone else. It makes your own thinking visible.
The components are the easy part: concrete, shippable and easy to document. Principles feel softer, and the ethos softer still. But the soft layer decides whether the rest holds together.