The Myth of the Design System

In this day and age, a design system feels like it is a basic requirement of any design team. In addition to creating a consistent user experience for customers, a design system is also pitched as a way to increase efficiency for the business by promising less time spent creating mockups, writing code, completing QA tasks and even reducing the number of customer support tickets (among other selling points).

The problem is, I've never actually seen a design system help achieve that mythical level of efficiency. The effort usually helps designers think a bit more holistically and make more consistent designs, and often leads to developers creating and documenting some amount of re-usable components that can help sometimes, but in many cases a lot of time and money is invested for a superficial payoff. Designers still encounter situations where the system is inadequate for the product requirements, developers end up creating new components or adding to existing components instead of just being able to re-use existing ones, and the effort to go back and update existing functionality with new components is almost always de-prioritized (if it happens at all).

Now don't get me wrong, I'm not saying that no design system ever works or that they are not worthy of time and investment (quite the opposite!). I'm sure larger organizations with large teams and mature products that have invested the necessary time and effort can boast this level of efficiency, and/or small teams/apps that can make due just fine with an off-the-shelf solution like Bootstrap, Material, Ant, or equivalent.

But many teams miss the opportunity to get the most from their design system by making some common mistakes. After working with teams large and small with varying degrees of a "system" in place, I've recognized a few patterns about why these systems may not live up to their lofty expectations, even if it seems like they do.

It's not an agile project

It's difficult these days to commit to any project that isn't "agile" or "lean" and the creation of a design system is no exception. In almost all cases I can think of, the design system is created on the fly as features come up or in parallel to existing efforts. This sounds reasonable enough but it doesn’t work out for 3 reasons:

1. Initially a subsection of components are created, and for a decent amount of time new re-usable components are written or iterated on with little to no benefit of code-reuse.
2. Components are usually created with the current scope in mind instead of thinking holistically, and often require updating when used again in different settings, sometimes multiple times.
3. By the time you have some good coverage and start to feel good about things, a branding cycle or major feature enhancement occurs often leading to a need to update or overhaul a lot of what you already worked on.

Over a long period of time, things can stabilize and the benefits start to be seen, but most teams expect to see real results in a matter of sprints instead of the months or years it will take.

Lack of Proper Ownership or Process

In most cases, a design system is a democratically owned project with some collection of designers and possibly developers contributing to it. The problem is, many of these individuals possess varying levels of understanding of the entire system or have specific tastes or preferences and as a result design with their current scope in mind. The process for circulating the changes and getting approvals is cumbersome and sometimes skipped altogether, leading to inconsistent experiences or even broken functionality.

Optimizing for development time over user experience

There's no denying that one of the major benefits of a design system is reduced development time due to having a library of re-usable code components. The trouble comes when that is the top or only priority.

Many times when a design system is created the development team chooses an existing framework to work with (like Bootstrap, Material, Ant, Tailwind UI, etc.). The frameworks provide broad coverage of components, and boast about the ability to customize things to make them completely your own, and most of them are "good enough."

But there are still many times where the customization options are clunky and the components are still insufficient to create the ideal user experience. Many of these systems are built for "simple" websites or applications, and lack true flexibility to serve advanced scenarios elegantly. Even if technically it's possible to make the necessary adjustments, if the priority is to have a system that optimizes for as little code written as possible it's difficult to justify investing the development time to get to the ideal experience because there is already something that's technically "good enough."

Not understanding how to design from a system

Most teams think that thorough documentation is enough to help people understand the components and how to use them, but in my experience the documentation is mostly for developers and are usually only consumed when they need to be, if they are read at all.

It's designers that need to do a better job of having a firm grasp on what components are available, how they work, and why are built the way they are so they can be used properly. Just as developers can over-optimize for writing less code, designers are often guilty of overlooking existing solutions and jumping to proposing new elements that aren't necessary, simple based on "feel."

What You Can Do To Set Your Team Up For Success

So how do you combat these forces and create a system that makes everyone's lives easier? Here are some suggestions for how to do it right:

Invest In It For the Long Haul

Sounds obvious but its more important than you realize. In today's "agile" environments, everyone is looking for the low-hanging fruit or how to get maximum impact with minimal investment. Sadly, this is the exact reason things like design systems fail to deliver on their promise.

If you are going to reap the benefits of a proper design system, it needs to have a strong solid base to start from. Not only should a system have a robust set of components, ideally those components are already purpose-built for the specific interactions required by your application and also are flexible enough to adapt to other yet-to-be-discovered situations easily.

In general, the more thoughtful you are up front, the faster you will reap the benefits from the system.

Pay Attention to the Details

This day in age, what you do isn't nearly as important as how enjoyable it is for a customer to do it. Off-the-shelf frameworks check a "good enough" box, but leave a lot to be desired when it comes to creating a delightful user experience. Instead of just adjusting a few colors and a font but applying otherwise default configurations of existing frameworks, spend the time to make sure the spacing is right, the colors are complimentary (and WCAG compliant!), and elements are aligned with intention. You'd be surprised how big of an impact a small amount of attention to detail up front has both in customer's enjoyment of your experience, and the team's interest in applying it.

Assign an Owner

Everyone on the team should have input and be involved in the on going maintenance and upkeep, but having an owner or "decider" that is responsible for keeping the bigger picture in mind can make sure that the system maintains consistency. The owner should also be responsible for making sure documentation and Figma libraries are up to date and in sync, the design team is designing with a "system-first" mentality, and developers are building with the components wherever possible.

Despite the poor track record I've witnessed, I do believe design systems can level up your product design and overall user experience when implemented properly. Hopefully by following some of these tips you can find success with your design system and enjoy the benefits of the increased productivity it can bring.

Has your experience been different? Did I miss anything? Leave a comment below and share your experience!