Can your design system say no?

Your design system's job is complicated. It must enforce consistency and it must enforce scalability. For those two things, rigidity tremendously helps. The fewer options you offer, the simpler your rules are, the easier it gets to be consistent and scalable.

But the fewer options your system offers, the more frustrating it is. It limits your product's ability to ship, to build, to innovate.

This friction, this tension even, can lead to the system's pushing back, putting its weight against product choices.

But is that safe? What's the cost of the design system saying "no" to its consumers and backers?

Design systems and legitimate authority

We discussed the need for an external authority to enable the design system. But this authority, once granted, becomes the system's responsibility to wield. It has been given a mission and the means to achieve it.

That is a necessity: without the power to create and enforce rules, no guideline can ever make sense. It's already hard enough to get a company to read its own documentation, but if those specs can be ignored freely, why bother creating them at all?

And yet... Enforcement is always a perilous thing. Say you have a Button component. That component does not support icons on the right hand side of the text. That was a choice made to avoid inconsistent icon placement across all buttons in the product. But one day, one of your feature teams comes knocking at the design system door. They would like to implement a Button, under all accounts a fair use of the pattern, but with an icon on the right hand side of the text.

And they have an argument behind it. All your other competitors do it that way, for the specific feature they are building. Will you say "no"? Will the design system block this?

What happens when you say no

It would be in the interest of consistency and scalability to push back. But if you do, two things happen.

First, you have incentivised your consumers to override or sidestep or otherwise not use the system. Yes, you would expect them to have more maturity than this, but maturity is a relative concept: your organisation may value flexibility or market-standard consistency more than design system purity.

The other thing that happens is that you've now given your consumers reasons not to trust that "the system will provide". Again, this can be legit: the system cannot be a never-ending supply of stuff. It has a mission, and that mission has limits as a price to pay. But in your company, everyone has a mission. Does yours matter more than theirs?

When your system says no, you're putting missions in the balance. Sometimes on a purely emotional front, with high subjectivity reigning supreme. That aforementioned Button could probably work, be understood by users and convert without its icon on the right. Maybe. But would you be willing to risk it when everyone else does it differently? Would you be willing to spend hours debating with an authoritarian design system? Why would you have to fight for the right to own your product? To do it the way everyone else does it? And wasn't that damn system supposed to be here to help?

Enabling the "no"

Is it therefore possible to exercise design system authority? Are guidelines pointless in the face of stakeholders? If they do not fit a common goal, yes they are and design system authority will only drive people away from it.

The best course to enable that authority, that opportunity to enforce guidelines and keep things sane and safe, is to have a "but".

Your stakeholders expect a near comical level of "yes and" (Tobias Fünke forever is a great example of what poorly applying this improv approach means). You can't grant them that, but you can grant them a "no but" (or a "yes if"). Give people an alternative, one you can support.

Sometimes it means accepting change. Sometimes it means providing controlled layers outside of the system (satellite libraries, local compositions based on tokens etc...). And sometimes it's simply providing guidance for the teams to build a viable solution from what's already available. The point is that your "no" disappears as such when you're still opening doors, not closing them. You enable the "no" as a viable tool when...you're an actual enabler.

It is hard. It's a balancing act: wanting to be an enabler all the time is dangerously close to making you say "yes" all the time. And if you do, your system will lose a lot of its value. How do you enforce consistency and scalability when anything goes? You can't. You would enable technical debt, design debt, unscalable solutions. You would weaken even the pillars, the non-negotiable "no" (no buts): accessibility standards, security concerns, performance requirements etc.

On the other hand, if you never find a way to be that enabler, to say "no but", then your system may indeed be forever untainted.

But forever unused.