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.

But before principles, there's a layer most teams skip: the ethos. Not what the product should look like, or how individual decisions should be made, but what the product is actually trying to be. Does it treat the user as someone who needs guidance, or someone who knows what they want? Defining that upfront doesn't narrow your thinking. It focuses it. The narrowing happens later, when you need to put ink to paper and make the small decisions that sum up the overall experience.

I've seen principles documents survive team consensus precisely because they said nothing specific enough to be contested. Most of them have no ethos behind them either. Without it, even well-intentioned principles are directionless.

Useful principles answer the question a designer actually faces. Not "be clear" but "when two copy options both work, prefer the one that names what the user is doing rather than what the system is doing." Not "be human" but "avoid system-state language like 'invalid input'; write for the person, not the error handler." One version gets agreed with. The other gets used.

The test: could a new designer use a given principle to make a decision you weren't in the room for, and reach the same conclusion you would have? Most principles fail that test completely.

Slogan-level principles explain why inconsistency persists even in teams that have invested heavily in design systems. Components enforce the visual layer. Principles should enforce the decision layer: what a product feels like to use, how trade-offs get resolved, what the product is actually trying to do for a person. When principles are slogans, that layer is ungoverned. Designers fill it in themselves, differently, every time.

A decision changelog helps. Not a version log of component changes. A record of reasoning: a date, a decision, and what drove it. "Moved away from system-state error language because it fails to 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 document encodes how the team thinks. When a decision comes up for review, it's what 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 require a deliberate effort to change. Writing the ethos down isn't documentation for someone else. It's what makes your own thinking observable.

The components are the easy part: concrete, shippable, straightforward to document. Principles feel softer. Ethos feels softer still. But without the ethos, you're not making decisions. You're just making rules.

A component library makes things look consistent. A design system makes them make sense.