Design Systems in Practice: What to Standardize and What to Leave Flexible

The problem

Design systems usually fail in two extremes.

In the first one:

• they try to standardize everything
• they become visual bureaucracy
• they block product evolution

In the second one:

• they become a loose collection of components
• each squad uses them differently
• consistency becomes an illusion

In both cases, the team loses.

Either through useless rigidity.

Or through expensive divergence.

Mental model

A design system is not a library meant to control the team’s creativity.

It is also not a repository of disconnected components.

Short version:

a good design system standardizes what reduces recurring friction and leaves flexible what still depends on product context.

That helps move away from the vague discussion of “do we have a design system or not?”

The better question becomes:

• what deserves a stable contract?
• what still deserves room?

Breaking the problem down

What is usually worth standardizing

It makes sense to standardize more strongly when:

• the pattern shows up across many screens
• accessibility needs to stay consistent
• the repeated decision costs time every week
• implementation variation creates bugs or visual noise

Examples:

• button
• form field
• modal
• tooltip
• basic grid
• color and spacing tokens

What is usually worth leaving more open

Not everything needs to become a shared component early.

It is often better to leave something more open when:

• the pattern is still evolving
• product variation is high
• the cost of abstraction is higher than the gain
• the team still does not know which API is worth stabilizing

Classic example:

moving a very specific feature into the design system too early and then carrying years of compatibility for something that never truly repeated itself.

The danger of the component that does everything

When the team wants to absorb every exception into one component, the monster appears:

• dozens of props
• too much conditional behavior
• an API that is hard to explain
• documentation nobody wants to read

That looks flexible at first.

But it becomes permanent maintenance cost.

A good pattern needs contract and limits

Standardizing is not only about saying “use this component.”

It needs to be clear:

• what it is for
• what it is not for
• which variations are supported
• when the solution should stay local instead of becoming systemic

Without limits, the design system becomes a vacuum cleaner for every problem.

Simple example

Imagine each squad implements modals differently.

It makes sense to standardize:

• focus handling
• escape behavior
• scroll lock
• accessible structure
• common variations

But that does not mean every content need inside a modal should become a prop on the same shared component.

Sometimes the right contract is:

• shared structure and behavior
• free content inside

That cut avoids both too much rigidity and too much chaos.

Common mistakes

• Moving any pattern into the design system after it appears twice.
• Trying to solve an exception with another prop instead of revisiting the boundary.
• Confusing consistency with total uniformity.
• Ignoring accessibility while discussing only aesthetics.

How a senior thinks

People who think well about design systems usually ask:

• is this recurring enough to deserve a contract?
• does repetition here create real cost or only superficial difference?
• are we stabilizing a mature pattern or freezing something too early?
• does the cost of maintaining this shared API pay back the benefit?

Those questions prevent a lot of expensive abstraction disguised as organization.

What this changes for the team

When the design system gets standardization right:

• less time goes into rediscovering decisions already solved
• accessibility and consistency improve
• review becomes less subjective
• the product still keeps room to experiment where needed

In the end, a useful design system does not try to decide everything.

It chooses carefully where the team should stop re-deciding the same thing every week.

Standardizing everything suffocates.

Standardizing nothing spreads cost.

The real work is figuring out what deserves a stable contract.