There’s a version of design systems thinking that goes like this: if you document everything, standardise every spacing value, and force every team to use the same components, you’ll get consistency. And consistency, so the thinking goes, is good.
I’ve never found that to be true.
What you actually get, if you’re not careful, is a system that makes everything look the same without making anything feel right. The tokens are correct. The components are technically on-brand. And yet something is off — the product has the texture of a checklist rather than a considered thing.
The thing about defaults
Every design system is, at its core, a set of defaults. What is the default button radius? What is the default spacing between a label and an input? What is the default colour for an informational state?
These feel like small decisions. They are not. Defaults are where taste lives.
A system with generous defaults — rounded, warm, open — creates a different working environment than one built on tight, rectilinear, dense ones. Neither is objectively correct. But one will fit your product better than the other, and choosing wrong means every component your system produces will be fighting the product it lives inside.
Consistency is the wrong goal
Consistency is a symptom of a good system, not the goal. The goal is to make good decisions once and stop re-making them. The goal is to give a team leverage — so that a designer working on a new feature doesn’t have to rethink button states from scratch, but instead gets to apply taste on top of a solid foundation.
When consistency becomes the explicit goal, the system becomes a constraint. Teams start resisting it. They create one-offs. They argue about when it’s acceptable to deviate. The system calcifies into something nobody owns and everyone avoids.
What taste actually means in practice
I’m not talking about aesthetic preference. Taste here means: knowing what the product needs to feel like, and making sure the system produces that feeling reliably.
It means asking: if a component built with our system appeared on a page we’d never seen, would it feel right? Or would it feel like it could belong to any product?
Systems built with taste have a point of view. They make things look like us. They leave room for teams to work fast and still land on something that feels coherent — not because every value was prescribed, but because the defaults were thoughtful enough to point in the right direction.
The best systems I’ve worked on were not the most documented ones. They were the ones where the team trusted the defaults — because the defaults had been made with care.