Primitives Are Leverage
Most UI systems do not fail because of poor styling or inconsistent spacing. They fail because the primitives are too specific.
When primitives encode product concepts instead of capabilities, the system becomes rigid. Every new requirement forces either duplication or exceptions, and over time the UI layer turns into a graveyard of one-off components.
Strong primitives are boring by design-and that is precisely why they scale.
What Makes a Good Primitive
A good primitive has three defining properties:
- Reusable: it can appear in multiple contexts without modification
- Composable: it gains meaning when combined with other primitives
- Context-agnostic: it does not encode business intent
Primitives should describe what something is, not why it exists.
The moment a primitive starts answering product questions, it stops being a primitive.
The Cost of Specificity
Specific primitives feel productive at first. They move fast and read well in code.
They also lock you in.
Bad Primitives
HomeHeroCardTrendingDestinationTilePromoBannerV3
These names embed:
- Placement
- Intent
- Versioning
Each of those dimensions eventually changes. When they do, the primitive becomes either misleading or unusable.
Specificity does not age well.
Boring Primitives Win
Good primitives are intentionally generic:
- Card
- Media
- Title
- Action
- Badge
On their own, they feel underwhelming. Together, they are expressive.
Meaning emerges from composition, not specialization.
A “Trending Destination” is not a primitive. It is a
Card with Media, a Title, a few Badges, and an Action. If the concept changes tomorrow, the primitives remain intact.Primitives Enable Everything Else
Once primitives are well-designed, a surprising number of higher-level capabilities fall out naturally:
- Server-Driven UI: primitives form a stable rendering vocabulary
- Cross-platform rendering: primitives map cleanly to platform-specific views
- Agent-driven interfaces: agents reason in primitives, not screens
- Faster experimentation: composition changes without touching infrastructure
This is why primitives are not a design system concern. They are infrastructure.
Evolution Without Rewrites
One of the most important properties of a good primitive system is asymmetry:
Primitives change slowly. Composition changes fast.
This is not accidental.
When primitives are stable:
- Experiments become cheap
- Features evolve without rewrites
- Old layouts can coexist with new ones
Most UI rewrites are not caused by design changes, but by primitives that were too specific to survive change.
Designing for Longevity
If you feel the need to version primitives (
V2, New, Updated), that is usually a signal that the abstraction is wrong.Primitives should be:
- Minimal
- Predictable
- Hard to misuse
If they are easy to misuse, they are probably too powerful.
Key Takeaways
- Primitives are infrastructure, not components
- Specificity kills reuse
- Composition creates meaning
- Stability is what enables speed