If Design Systems Are So Great, Why Do I Want to Break Them?

Bubble buttons. You stared at them for months, wondering why the brand identity had to be stuck in 2012. One day, you couldn’t take it anymore. You changed them to a flat style and showed the product owner. They loved it!

Then the product owner shared your design with another product team. Those designers reasoned that if you were allowed to break the design system, they could too — so they tweaked a few elements of the tab components. But no one relayed those edits back to your team. One small edit led to another but without any collaboration. To make matters worse, you changed the hex value just slightly… and that tiny 10% change caused the new buttons to violate accessibility standards.   

I’ve been the designer who breaks the system. In retrospect, I probably didn't fully understand what it was. For the unfamiliar, here's a quick primer on design systems.

A design system is both the foundational tools and the process a company uses to develop and design its products. Think of it as the what and why of design. The what encompasses all of the brand's visual assets — everything from font, colors, motion, iconography and more. What separates a design system from a pattern library are the documentation and standards baked into these components. By unifying all of these assets under cohesive guidelines, designers hope to reduce inconsistencies, work faster and get the whole team on the same page.That's the why.

In my less-informed days, if a new client brought in their own .sketch library, the first thing we’d do is judge it. The less-than-stellar design systems were all clearly created with one product in mind and didn’t have the flexibility needed to be an enterprise tool. The rules felt like roadblocks to more aesthetically-pleasing results. So we’d start pushing back. After all, isn’t it a designer’s job to create beautiful products?

I’ve also been the designer who builds the system.Creating a good design system from scratch is no easy task. Standardizing the look and feel of a brand across multiple applications requires months of collaboration. And you’re up against teammates pressuring you to tweak the guidelines (just as I did when I was a junior designer) because they think their un-tested, custom solution is better.

Why Do We Create Design Systems?

If design systems are such a royal pain, why use them at all?

Because design systems help us build great digital products.

Everyone can recite the benefits of design systems: they enable integrated user experiences, align internal processes and ultimately save lots of money. You don’t have to be a trendy, design-driven brand like Apple to recognize this need — even the US government gets this.

Why Do We Break Design Systems?

It's not as easy as saying: "because they don't work." Sometimes even the ostensibly good ones get under our skin. By identifying the types of design systems that trigger the deviant itch, we can understand the drive to break them.

●      We break design systems because we can't access them

●      We break design systems because we don't have enough flexibility

●      We break design systems because we have too much flexibility

●      We break design systems because we're pressured by other stakeholders

We break design systems because we can't access them.

A designer breaks the system when they're shut off from resources. Working at a consultancy, I've experienced this frustration first-hand. Designers won’t respect the system if we don’t feel ownership over it.

The most successful design systems I’ve seen have a community behind them, whether that's a Slack channel, a GitHub page or a contact page. Giving designers access to resources can be as simple as Intuit's feedback feature on its design system website.

Communication channels and community resources don't just assure third-party designers that their input is valued. They also help design system owners identify components that needed to be created, modified or added back in.

We break design systems because we don't have enough flexibility.

A designer also breaks the system when they're creatively cornered. But the solution isn’t to break the system. It’s to create one that allows flexibility. It's all about striking a balance between creativity and control.

IBM’s complex, multi-faceted branding didn’t stop it from creating an incredibly thorough design language. Knowing its pictogram library wouldn’t always be exhaustive, IBM published detailed production guidelines for designers to create new pictograms. IBM’s design language ensured that subjective, artistic visual elements like pictograms follow cohesive image styles while remaining open to the designer’s creativity.

A design system might provide an array of color shades but specify exactly which color combinations are acceptable — like Zapier's. Or Mailchimp's, which offers a dazzling buffet of tables. Both Zapier and Mailchimp exemplify how a design system can be firm in framework yet flexible enough to inspire new thinking.

We break design systems because we have too much flexibility.

The inverse is also true: designers will break the system when there's too much flexibility. Good design systems bridge the gap between development and design. Designers should be able to figure out which button to use in five minutes or less. It's not that designers even necessarily intending to stray from the guidelines. It's just that they haven't been given enough direction, and they can't afford to parse through a litany of dialog rules.

Filling the pool with the right components is only the first step. A good design system should also teach you how to swim. Hubspot and IBM do an excellent job of directing when, why and how certain components should be used. For example, Hubspot eliminates confusion by spelling out when exactly an alert style should be used, how it should appear and what it should communicate.

We break design systems because we're pressured by other stakeholders.

Finally, designers break a system if they feel the heat from a different part of the company. When the head of sales doesn’t like a certain design element — or if the dev team claims enforcing a shared library is too much work — you can be sure the design team will hear about it.

How do you pick your battles when the lead developer wants one thing, the product owner wants another, and VP of Sales wants something else entirely? Explaining the value of design systems to non-designers can be a hard sell. When you're pulled between parties, use the omnichannel experience as your trump card.

An omnichannel experience orchestrates consistent communication across independent channels, knowing users tend to engage with many different touch-points (think display ads, e-mail and mobile marketing). A design system is the visual linchpin across those channels. If the VP of Sales is pushing for red buttons in your new mobile app while the rest of the system uses green buttons, the phrase "approved brand color combinations"might not mean anything to them. But they will understand design systems in terms of the customer's experience. To get non-design savvy execs on board, explain that colors, iconography and language need to be consistent across channels at the risk of confusing (and losing) customers who enter through one channel and switch to another.

Why Shouldn’t We Break Design Systems?

While breaking a design system might feel right in the moment, it’s important to consider the consider the bigger consequences of these decisions:

●      Broken systems create inconsistent user experiences

●      One-off designs accrue unexpected costs

●      One-off designs may not have been tested with users

●      One-off designs may not meet accessibility standards

If you feel the urge to diverge, remind yourself: it’s bigger than just you and your product.

Design systems are too valuable to split whenever the mood strikes. Inconsistent design systems result in inconsistent user experiences.

Let’s say your design system always uses green icons to signify that a user action was successfully completed. You decide to change the green to orange in the desktop version to match the product’s orange logo. This could easily throw off someone who’s used to seeing green on the mobile app. On the desktop, your customer wonders, “Did my request go through?”

Good design guidelines have been heavily evaluated to keep confusing UX from slipping through the cracks. When you venture into custom designs, you’re heading into untested territory.

Custom designs also run the risk of accessibility violations. Even changing a button's hex code by 10% could render it indistinguishable to vision-impaired users. Diverging from the established guidelines defeats the entire purpose of having a design system: to serve as a reusable, unifying source of truth.

The very process of building a design system pools an incredible amount of resources. When you create a one-off custom design, you’re not only throwing away months of work and thousands of dollars by defying the guidelines — you’re making a whole new system for the front-end team to develop. It's hard to argue with numbers when those numbers are lost productivity hours.

All of this is not to say that style guides won’t need to be updated eventually. Components might have to be modified when product requirements change. Products have to evolve and upgrade to stay competitive.In the continuum of design, how do you make sure a style guide stays in place?

How Do You Ensure a Design System is Respected?

It’s difficult to get a group of designers to reach a consensus on any topic. Figma or Sketch? Have we officially abandoned drop shadows? Is Proxima Nova really too overused?

As I said before, design systems tend to be successful when they've earned community backing. If you're fighting the impulse to break a design system, the resources or feedback page should be your first stop. If you're fighting to see your design system respected, spinning up a#design-system Slack channel creates a platform to pose questions and feedback.

Team members can start having open conversations, pushing limits and questioning mythology. Most importantly, designers struggling with a certain component or style can raise the issue to management.   Now your team knows: they can hate bubble buttons all they want. They still need consensus before they change them.

It’s important to remember that a design system may not have all the elements it needs when it’s rolled out to the team. Components might need to be altered, swapped out or added in. Sometimes designs don’t behave the way you thought they would, and that’s okay. Re-designing a pre-existing style in the middle of the night is not okay. If you have an issue with an element, get to the heart of the problem. Bring it up at the management level. Design systems are growing, changing tools. Respect them and help them grow with intention.