A Bad Design System Is Worse Than No Design System

Design systems. There’s no shortage of articles out there detailing the what, how, and why. I’ll skip a retread in favor of some observations, now that we’re a few years beyond their surge in popularity and acceptance.

To start, a quick disclaimer: Design systems are a really good tool. This piece zeroes in on the bad, but isn’t meant as a condemnation; it’s a cautionary tale.

So, origins of the bad. These systems don’t solve the usual, day-to-day challenges that come with web development. There’s no perfect, “right” way to approach building one. Best practices are a moving target. Needs vary by organization. Flaws find their way in, and there’s a point where a design system’s problems can outweigh its utility — and you’re worse off because of it.

That probably sounds ominous, so let’s run through some of the cause and effect around “bad” implementations.

Everything Inherits the Bad

I’ll start with the big, obvious, glowing-red-nose issue facing all design systems: bad stuff proliferates everywhere. That includes:

• Poorly-coded (or naive) components
• Performance woes
• Functionality that doesn’t meet accessibility needs
• Anything unfinished or outright broken
• Look ‘n’ feel that doesn’t live up to your standards

And so on. Reusability is one of the major selling features of this exercise, but reuse of problems only spreads them out. There is one shining upside to hang your hat on, though: If time is actually spent to fix an issue, that fix is also inherited everywhere.

Process Introduces the Bad

The system part of a design system implies order and structure. There’s a cycle of iteration, documentation, and deprecation that comes with centralizing patterns and components. For founders and teams in a “try stuff” mood, though, organizing the pieces is like trying to catch a falling knife.

A full, formal, enterprise-y system isn’t for everyone, especially early in a build (see: overengineering). The compromise here is usually giving an application the chance to stabilize before pulling the pieces out into a framework.

If the team’s always at odds with a design system that otherwise seems right, you may just be up against a process mismatch.

Making Exceptions Because of the Bad

Filling the outside vendor role, we’re regularly called on to take the second shot at a problem. It’s a role that pairs well with a specific bit of direction: “Don’t worry about our existing system — we don’t want it to slow you down or influence you.” Scary stuff.

Are other teams or employees still required to use that design system? How do they feel about the exceptions — and their lack of one?

Selectively applying “the rules” sends a mixed message at best, and fully undermines them at worst. It’s like not having a design system, but with more steps (and a dash of animosity). If you’re actively avoiding the tool, it’s time to either fix it or plan a retirement party.

Implementation Easily Veers Towards the Bad

If your design has exactly one button style, building a button component is pretty easy. Setting that fantasy aside, you’re probably looking at:

• Several different color possibilities
• Functional states, like loading and disabled
• Smaller and/or larger alternatives
• Optional icons and icon-only variants
• Language support with longer-than-anticipated words

And, even with all of that covered, there are still exceptions. Maybe modals have a different kind of button. Maybe dark mode uses an outlined style instead of solid background colors. It’s a fun source of tension between designers and developers: When is more necessary?

Flexibility is fine, but really relies on the quality and approach of implementation. A big, complicated, unruly foundation is tough for developers to learn, use, and update — a recipe for a downhill slide in maintenance and sentiment. If every tool in the box is a Swiss Army Knife with different attachments, every step has its own learning curve.

Libraries Tie You to the Bad

Let’s stay in the implementation lane for a second. It’s a safe bet that your technology choices will eventually change, or you’ll want to develop other applications that may or may not use the same stuff. If your design system is locked into one tech stack, you’ll find yourself handcuffed to libraries, frameworks, and languages.

To that point, third-party setups have been trending towards agnosticism. Storybook, a favorite of ours, started life in the React ecosystem before branching out to cover a wide range of technologies.

Dedicated Teams Have to Fend Off the Bad

A “good” design system comes with a chain of command: an individual or a team that manages the roadmap for your new, vital dependency. Without that sense of ownership, it’ll struggle to:

• Stay up to date. The web is always moving, and best practices shift right along with it. Even when new components aren’t in active development, there’s work to be done behind the scenes to make sure the code and design don’t age poorly.
• Consistently be applied. Having a hammer in the toolbox doesn’t guarantee everyone knows how to swing it. Someone’ll need to review and police how the design system is applied, lest you find someone using the side of the hammer’s head to drive a nail.
• Prioritize documentation. Anything that isn’t coding tends to fall off developers’ to-do lists, and documentation is a common casualty. The wider team — everyone expected to use the system — relies on instructions and a changelog. Leadership needs to help make recordkeeping a priority.
• Keep up with new projects. Eventually, new features or applications will call for new styles, guidelines, and components. If the process and bandwidth isn’t there to support those requests in a timely fashion, the design system becomes a big stop sign.
• Triage feedback. More eyes, more gaps discovered. You’ll need a path for reporting the missing elements, niche problems, and unintended side effects that a larger team will (always) stumble on.
• Maintain a cycle of new and old components. On a long enough timeline, pieces of the system will be added, removed, tested, and changed. Implementations like Shopify’s Polaris deal with deprecations and features that haven’t been finalized quite yet, which calls for more effort and planning than on-the-fly updates.

Taking on a design system adds a new set of ongoing responsibilities. Someone’ll need to sit in the captain’s chair and fend off the challenges that come with time.

Building a Design System to Avoid the Bad

Done well, a design system is the perfect workshop: every tool you could want, how-tos for all the pieces, and a process to get anything missing.

Without some care, though, it’s worse than having one in the first place. Parts strewn about and unfindable, a mess of sawdust everywhere, and a collection of puzzling tools (why does this hammer have a ruler tied to it?) It’d take days to prepare to get some work done.

An ownerless, aging, taped-together design system is a four-letter word that causes strife, avoidance, and waste. Make sure that it’s treated as an ongoing effort, and course correct when the red flags start popping up.