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 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.

But their case studies are the ones that get written up and presented at Figma Config, Clarity, and every major design conference. 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.

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. And you need someone with enough organizational authority to enforce consistency.

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.

The Broken Implementation Most Teams Actually Live With

The failure mode is predictable. The system doesn't handle edge cases well. 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. And now there is a layer of process sitting between a designer and the work — overhead that adds cost without adding value.

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.

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 — that's when systematizing makes genuine sense.

Before recommending any degree of systematization, 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.

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. 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.

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.