The wrong way to start a design system
Most design systems start with components. Someone opens Figma, creates a button, creates a card, creates a nav. They build a sticker sheet. They call it a system.\n\nWhat they've actually built is an inventory. An inventory is useful. A system is something different — it's a set of decisions that generate consistent outputs when applied to new problems. The difference matters enormously when you're building for a technical product at speed.\n\nWhen I joined Loft Labs to lead the vCluster rebrand, the design 'system' was a collection of assets in various states of coherence. There was no shared source of truth. There was no documented logic. There were just files, some of them more current than others, none of them trustworthy.\n\nMy first instinct was to start with components. My second instinct — the right one — was to start with constraints.
"A design system isn't a library. It's a language. Build the grammar first, then the vocabulary."
Constraints before components
Before I created a single component for vCluster, I spent two weeks on three questions: What does this brand need to communicate? Who is it communicating to? What are the non-negotiables?\n\nThe answers shaped everything. vCluster's users are DevOps engineers and platform teams — people who trust precision over aesthetics, who read dense technical documentation for fun, who are suspicious of interfaces that feel more designed than useful. The brand needed to feel credible, precise, and confident without feeling corporate or decorative.\n\nFrom those answers I derived a set of constraints: a severely limited color palette (high contrast, functional, no gradients that couldn't be justified). A monospaced secondary typeface for technical content. A grid system that could accommodate dense information without feeling cramped. Motion only for state changes, never for decoration.\n\nThose constraints weren't aesthetic preferences. They were design decisions derived from understanding the audience. Every component I built later was just a materialization of those decisions.
"Constraints are design decisions made early, at the system level, so you don't have to make them over and over at the component level."
The five things every system needs
After building and inheriting systems at multiple companies, I've landed on five things that make the difference between a system that scales and one that gets abandoned:\n\nA clear decision log. Not just what the decisions are, but why they were made. When a new designer joins, they need to understand the reasoning, not just the output. Reasoning survives the original context. Rules don't.\n\nA named hierarchy. What's a global token? What's a component token? What's a local override? When you have three levels of specificity and no names for them, every discussion about changing something becomes a negotiation about scope.\n\nA contribution protocol. Who can add to the system? What's the process for promoting a one-off solution to a systemic one? Without this, the system calcifies and the team works around it.\n\nAn honest scope. A system that claims to cover everything covers nothing well. Define what the system owns and what it explicitly doesn't own.\n\nA maintenance commitment. Systems decay. The team that built vCluster's system understood that the work doesn't end at launch — it enters a different phase.
What shipped and what it changed
The vCluster system launched with the full homepage redesign in late 2024. Within sixty days, the demo request rate had increased three times over. That outcome wasn't primarily a design win — it was the result of the whole team being able to move faster and more consistently once the system was in place.\n\nThe most valuable thing the system delivered wasn't the components. It was the shared vocabulary. When designers and engineers could talk about 'a tier-1 surface' or 'a technical callout block' and both know exactly what that meant, decisions got faster. Reviews got faster. Handoffs got cleaner.\n\nBuild the language first. The components follow.