The Biggest Enemy of a Design System: Exceptions

• “This screen is a little different.”
• “This one is for a specific client.”
• “Let’s make it different just on this page.”
• “Let’s tweak the padding on this button a bit.”

At first glance none of these seem important. Most of the time they’re even based on sensible reasons. But every exception chips a small piece off the system’s consistency.

Every exception is a new standard

The purpose of a design system is to stop teams from solving the same problem again and again, and to cut costs across the company. But as exceptions pile up, teams start asking:

“Which one do we use here?”

That’s the moment the system stops being a guide and turns into a list of options.

Three different versions of a button, four different spacing values for the same card, or two modals that look almost alike…

None of these is a big problem on its own.

But together they increase the burden of decision-making.

The real cost of exceptions is invisible

Most teams think exceptions only affect design. In reality their impact is much bigger.

Every new exception:

• means a new component or variant to build.
• creates a new scenario for QA to test.
• requires the documentation to be updated.
• adds one more rule for new team members to learn.
• increases maintenance costs.

The cost of an exception doesn’t show up on the day it’s created, but over all the years it keeps living in the system.

Being able to say “no” is a design system’s most important feature

Successful design system teams don’t add every request to the system.

First they ask: Is this really a new need, or can the existing system cover it with a small adjustment?

Because saying “yes” to every request makes the system bigger.

Saying “no” to every unnecessary exception makes it stronger. A design system isn’t meant to cover every scenario. It’s meant to make sure teams speak the same language most of the time.

Conclusion

What keeps a design system standing isn’t having hundreds of components.

What makes it strong is a governance model that decides which exceptions are accepted and which are rejected.

That doesn’t mean saying “no” to every exception.

Sometimes the existing component really doesn’t solve the problem. A new user need may have emerged, accessibility requirements may have changed, or the product may have evolved into a different use case. In those cases, creating a new component or variant is the right call.

But the reason for that decision shouldn’t be “I think it looks better this way.”

Instead, it should be able to answer these questions:

• What problem can’t the existing component solve?
• Which user need does this exception meet?
• Why can’t the existing system meet that need?
• Is there user research, analytics data or a business requirement that supports the change?

In short, exceptions in a design system should be created based on evidence, not opinions.

Because every new exception is a cost added to the system, and that cost only makes sense when it solves a real problem. A good design system’s job isn’t to accept every request, but to bring in the changes that truly create value.