The Problem with Pure Pragmatism
Most developers build interfaces the way they build plumbing — functional, invisible, and forgotten the moment it works. There's nothing wrong with this. Pragmatism ships products. But it also produces systems that are brittle, incoherent, and impossible to reason about at scale.
The alternative isn't aestheticism. It's synthesis — the deliberate act of bringing ideas from different domains into productive tension.
"A design system is not a collection of components. It is a theory of how your product should behave."
When you treat a design system as a philosophical artifact rather than a technical one, something interesting happens: the decisions become easier. Not because there are fewer of them, but because they have a foundation.
What Philosophy Gives You
Philosophy, at its core, is the practice of making implicit assumptions explicit. When you ask "what is a button?" you're not asking a trivial question. You're asking:
- What does it mean for something to be interactive?
- How does affordance communicate intent?
- What is the relationship between visual weight and semantic importance?
These aren't questions that Figma answers. They're questions that your design system either answers implicitly — through inconsistency and accident — or explicitly, through deliberate choice.
// A button that knows what it is
interface ButtonProps {
intent: "primary" | "secondary" | "destructive";
size: "sm" | "md" | "lg";
children: React.ReactNode;
}
export function Button({ intent, size, children }: ButtonProps) {
// The intent drives everything — color, shadow, weight
return (
<button className={resolveIntent(intent, size)}>
{children}
</button>
);
}The intent prop isn't just a style variant. It's a semantic claim about what this action means in the context of your product.
The Three Layers of a Coherent System
I've come to think of design systems as having three distinct layers, each answering a different kind of question:
1. The Atomic Layer (What things are)
Tokens, primitives, base components. This is where you define your color palette, your type scale, your spacing system. The philosophy here is about identity — what makes your product recognizable.
2. The Compositional Layer (How things relate)
Patterns, layouts, compound components. This is where you define how atoms combine into molecules. The philosophy here is about relationship — how elements communicate with each other and with the user.
3. The Intentional Layer (Why things exist)
Guidelines, principles, decision frameworks. This is the most neglected layer, and the most important. The philosophy here is about purpose — why your system makes the choices it makes.
Most teams build the first layer. Some build the second. Almost none build the third. And then they wonder why their design system feels like a collection of parts rather than a coherent whole.
Practical Synthesis
Here's what this looks like in practice. When I'm designing a new component, I ask three questions before I write a single line of code:
- What is this component's single responsibility? Not what it does, but what it is. A card is a container for a discrete unit of information. A modal is an interruption that demands attention. A tooltip is a whisper.
- What is the relationship between this component and the user's mental model? Does it match what they expect? If it doesn't, is the deviation intentional and meaningful?
- What does this component communicate about the product's values? A brutalist border says something different than a soft shadow. Neither is wrong. But both are statements.
These questions don't slow you down. They speed you up — because they eliminate the infinite space of arbitrary choices and replace it with a much smaller space of principled ones.
Conclusion
The synthesis of design and philosophy isn't a luxury for teams with time to spare. It's the foundation that makes everything else possible. Without it, you're not building a system. You're building a pile.
Start with the questions. The components will follow.