A design system should standardise decisions, not just components

Run this audit on your own design system. Open it and count how much of it is, honestly, a well-organised screenshot collection.

Buttons in every size. Inputs in every state you remembered to draw. A colour page.

A type scale. All neatly named, all beautifully arranged.

Now try to answer a question a designer on your team will actually face this week: when a user starts a multi-step workflow and abandons it halfway, what happens to their data?

Where does the system say what a destructive action confirmation looks like, and when one is required? What does this table do when the user has no permission to see half its columns?

If the system goes quiet, you have a component library. That's not nothing. But it's not a design system, and the difference starts to hurt the moment your product grows past simple pages.

Where component libraries break

I've worked on design system foundations at LeadGenius and I'm currently building a reusable Figma and React system aimed at small B2B SaaS teams.

Both experiences taught me the same thing from different angles: components standardise output, but the expensive inconsistencies in a product were never really about output. They're about decisions.

A component answers "what does a button look like?" It cannot answer "should this action be a button or a menu item, does it need confirmation, and what does the user see while it's processing?" Those are decisions, and in most teams they get remade from scratch every time they come up.

Designer A puts the confirmation in a modal. Designer B uses an undo toast. Designer C, under deadline, skips it.

All three shipped consistent buttons. The product still feels like it was built by strangers.

This is why complex SaaS products with beautiful component libraries can still feel incoherent. The library made every screen look related. Nothing made them behave related.

The layers that actually matter

The way I think about it now, a working system has at least four layers, and the component library is only the second.

Foundations are tokens: colour, type, spacing, elevation. Necessary, and the easiest layer to build, which is why so many systems stop here.

I've asked myself directly whether a solid token setup makes a system, and the honest answer is no. It makes a palette.

Components are the reusable objects. Buttons, fields, tables, cards. Most teams have this layer and most tooling supports it well.

Patterns are where decisions start getting standardised, and where most systems go silent. A pattern says: this is how forms handle validation in our product, always.

This is how destructive actions work, always. This is what an empty state contains, always: what happened, why, and the next action.

Patterns are recorded decisions, made once by someone with time to think, so nobody has to remake them at speed.

Workflows are the top layer and the rarest: how multi-step processes behave. How a setup flow saves progress. How a wizard handles going back.

What happens on abandonment. In B2B SaaS this is where users spend their whole day, campaign builders, configuration flows, reporting setups, and it's precisely where most systems offer nothing.

The states deserve their own mention because they're where quality quietly dies. Empty, loading, error, no-permission, destructive-pending.

Every screen has them and almost no system documents them, so every designer improvises and every improvisation is different.

If I could add one thing to every component library on earth, it would be this: for each component and pattern, what does it look like when things aren't fine?

Document the boundaries, not just the anatomy

Most system documentation describes what a component is. The more valuable documentation describes when not to use it.

"Use a modal for decisions that block progress; never for information the user might want to reference while working." That sentence prevents more inconsistency than forty pages of modal anatomy, because it standardises a judgment. Anti-patterns, usage boundaries and worked examples of wrong usage are the difference between a system that informs and a system that guides.

The other non-negotiable is that the system has to survive the trip into code. A Figma library that doesn't correspond to what engineers actually build isn't a system, it's a brochure.

This is why I'm building the current work as Figma and React together, variables mapped to code tokens, component APIs mirroring Figma properties.

If the two sides drift, designers are designing fiction and every handoff becomes a small negotiation.

Why I'm building this now

The system I'm working on is intended for small SaaS teams and, increasingly, for AI builders, and that second audience has sharpened my thinking about what a system is for.

AI tools can now generate screens fast. What they generate reflects what they're given, and what they're mostly given is generic: default component kits with no product logic attached.

The result looks polished and behaves like nothing in particular. Screens that don't share workflow logic. Flows that handle errors three different ways.

Interfaces that photograph well and fall apart under a week of real use.

A system that encodes decisions, not just components but patterns, states and workflow rules, becomes something you can point a generation tool at. The constraint layer is the value.

Speed of production was never the bottleneck for small teams; quality of the hundred small decisions was.

That's true whether the screens are drawn by a designer or generated by a model, and it's about to become much more visible.

I want to be careful not to oversell where I am. The system is in progress, not proven. What I can share is the reasoning driving it, and the reasoning is this article.

How to know if any of this is working

One trap to avoid: measuring a system by its size. Component count, page count, coverage percentages. All of it rewards building more library, which is the layer that was never the problem.

Better questions. Has cycle time dropped for common product work? Do design reviews still relitigate the same decisions, or does someone just cite the pattern and move on?

Are the same defects, the missing loading state, the inconsistent error handling, still recurring in QA? Do designers and engineers actually reach for the system, or work around it?

Decision speed is the metric underneath all of these. A good system makes the recurring decisions instant so the team's judgment is spent on the decisions that are genuinely new.

Start with one workflow

If your system is currently a component library and you want to move it towards being a real system, don't start a documentation project. Start with an inventory.

Pick your product's one most important complex workflow.

Go through it screen by screen and list every decision that was made by hand: how errors show, how steps confirm, how progress saves, what empty looks like, what happens when permissions bite.

Then compare across screens and count how many times the same decision was made differently.

Every entry on that list is a candidate for your system, and unlike another button variant, each one you standardise removes a debate from every future project. Components make your screens match.

Decisions make your product coherent. Build the layer that's missing.