Most Products Don't Need a Design System. They Need Design Hygiene.
The design system has become one of the most over-prescribed solutions in the product design industry. Somewhere along the way — accelerating through the atomic design movement, the rise of Figma component libraries, and a wave of conference talks from companies with enormous design org budgets — a design system stopped being a tool and became a benchmark of maturity. If you didn't have one, you weren't serious about design.
After working across enterprise software, government-adjacent products, and early-stage SaaS teams, my view is that a full design system is the right answer far less often than the industry suggests. For most small to mid-size product teams, it introduces more complexity, overhead, and organizational friction than it resolves — and teams would be better served by a lighter approach that I think of as design hygiene.
The Survivorship Bias Problem
The classic survivorship bias problem: WWII analysts initially recommended reinforcing the areas of returning aircraft that showed the most bullet damage — until statistician Abraham Wald pointed out that they were only seeing the planes that made it back. The damage-free areas were exactly where the missing planes had been hit. We make the same mistake when we model our design process after the organizations whose stories get told, rather than the far larger number for whom that approach quietly failed.
The case studies we read about design systems come from Salesforce, IBM, Google, and Starbucks. These are companies with hundred-person design organizations, products used by millions of people, and the engineering resources to treat a design system as a product in its own right — with dedicated teams, roadmaps, versioning, contribution models, and governance structures. They are not typical. They are, by almost any measure, extreme outliers in the broader landscape of product organizations.
But their case studies are the ones that get written up and presented at Figma Config, Clarity, and every major design conference. They get pushed through industry newsletters and held up as examples of what design maturity looks like. And so a practice that makes genuine sense at extraordinary scale becomes the default recommendation for a twelve-person startup trying to ship a dashboard by the end of the quarter. The gap between the model and the reality is wide, and most teams are paying for it.
What a Real Design System Actually Requires
A design system, done properly, is not a deliverable. It is a product unto itself — and it demands everything that implies. You need designers who are dedicated to the system and not simultaneously responsible for shipping product features. You need engineers who maintain the component library and close the implementation gap between what lives in Figma and what gets built in production. You need documentation that stays current as the product evolves. You need a contribution model that gives designers working on product problems a way to surface gaps in the system and have those gaps addressed in a reasonable timeframe. And you need someone with enough organizational authority to enforce consistency and say no when teams want to go their own direction.
Strip any of those pieces out and what you're left with isn't a design system — it's a Figma library that goes stale within six months and a set of components that developers implement inconsistently. Which produces the exact kind of incoherence the system was supposed to prevent. I've watched this pattern play out repeatedly, across companies of different sizes and industries: the system gets built with genuine enthusiasm and good intentions, and within a year it has become a source of friction rather than a source of consistency.
The Broken Implementation Most Teams Actually Live With
The failure mode is predictable. The system doesn't handle edge cases well, because no system built for ten contexts serves any of them perfectly. Designers work around it rather than with it, because filing a request and waiting for a component update is slower than solving the problem directly. The feedback loop between product designers and the system team is broken or nonexistent, so neither side has full visibility into what's actually being built or what the system is missing. And now there is a layer of process sitting between a designer and the work — overhead that adds cost without adding value.
This isn't a failure of the designers involved. It's a predictable outcome when a tool that requires substantial, sustained resourcing gets deployed without that resourcing. The design system becomes another form of debt: something the organization is technically maintaining but not actually benefiting from.
Design Hygiene as an Alternative
The alternative I've come to advocate for is something I think of as design hygiene rather than a design system, and the distinction matters. A design system assumes that consistency is a systems problem requiring a systems solution. Design hygiene assumes that consistency is a people problem requiring shared habits and sound judgment.
In practice, design hygiene looks like a shared color palette and type scale documented clearly enough that no one is making arbitrary decisions. A spacing grid that everyone on the team understands and uses. A small set of core interaction patterns — a card, a form input, a data table — captured well enough that junior designers aren't reinventing them and developers aren't making calls that should be design decisions. A naming convention that's consistent and understood. And a lead designer with enough context and taste to notice drift before it compounds into something harder to fix.
None of that requires a dedicated team. None of it needs a contribution model, a versioning strategy, or a governance document. It lives in the flow of the work, which means it actually gets used and actually stays accurate. For small to mid-size teams — and in my experience, especially for teams working on data-heavy or domain-specific products where generic component libraries fit poorly anyway — this approach delivers most of the consistency benefits of a design system at a fraction of the overhead.
Knowing When a Design System is the Right Answer
It's worth being clear that design hygiene has a ceiling. It works because it relies on people who share context and judgment. When the team grows large enough that informal communication can no longer maintain that shared context — when turnover is high, when the product surface is genuinely massive, when the stakes of inconsistency are measurable in customer satisfaction or engineering costs — that's when systematizing makes genuine sense. The threshold is real; it just tends to be further out than most teams assume.
Before recommending any degree of systematization to a client, I've started asking a single diagnostic question: where is inconsistency actually costing you right now? If the answer is "it's not yet, but we're worried about it" — that is a hygiene problem, not a systems problem. Shared foundations and strong design leadership will handle it. If the answer is "our design and development teams have diverged completely and we have no shared language" — there may be a systems problem, but it's almost certainly also a process and communication problem, and a component library alone won't fix either one.
What This Means for How We Advise Clients
As designers, we have a responsibility to recommend what's right for the team and the product in front of us — not what looks most rigorous or sounds most mature. A lot of designers coming into a new engagement will default to recommending a design system because it produces a concrete, substantial deliverable. It feels like the professional answer. But for an early-stage team without the resourcing to maintain what gets built, it can be the wrong answer at a significant cost.
The more useful framing — and the more honest one — is to ask what the minimum structure is that prevents chaos at your current scale. Sometimes that's a design system. More often, it's a solid foundation: tokens, a type scale, a few documented patterns, and a team with shared habits. The goal is a coherent product, not a beautiful component library. You can build one without the other, and for most teams, that's exactly what you should do.
Wrapping Up
Design systems are powerful tools, and the teams that built the canonical examples deserve credit for pioneering infrastructure that changed how product organizations think about consistency at scale. But the industry has overcorrected, turning a specialized solution into a default practice that many teams adopt without the resourcing or organizational maturity to make it work.
If you're working on or advising an early-stage product team, the most valuable thing you can do is resist the pressure to systematize prematurely. Establish good design hygiene — clear foundations, shared conventions, strong judgment — and build more structure only as the product and the team genuinely demand it. The goal is to design the right process for where you are, not to perform the process of a company you aren't yet.
