Why design systems fail in product design

When you’ve got a new hammer, everything looks like a nail. The latest and greatest hammer in the designer’s toolbox is a design system. Easily misapplied and often misunderstood, design systems are the latest in an ongoing evolution of artifacts supporting design in software delivery.

In this article, we’ll discuss the three conversations you should have before leveraging a design system for your next digital product.

In practice, building and implementing a design system should be approached with the same measurement of risk and investment as any other product. Whether you’re convincing leadership at your organization or in talks with a product design team, validate your effort with these three questions:

What is the benefit you expect?
Are you prepared to invest in it as a product?
Is the design system positioned for success?

Before talking about what a design system is, let’s discuss what it’s not. A design system does not replace the need for a designer. It does not make everyone on the team a designer. It does not make your application “design itself.” It does not replace essential conversations and validation with the people that will use the product.

A design system is defined as a “comprehensive set of values, semantics, syntax, and context that form the foundation of a shared design language.” The term design system is often used interchangeably with pattern library, style guide, and component library. However, these three terms are actually the pieces that make up a design system.

The benefit of consistent design is validated throughout the history of products. One of the greatest early examples is the NASA Style Guide. The meticulous and thoughtful documentation of the use of NASA’s brand accelerated and cemented it’s iconic role as a symbol of American power.

Before investing in a design system, ask, “what benefit are we hoping to achieve?” The most common goal is a holistic and consistent experience for every user of your product, regardless of device or medium. Design systems aid in organizing assets and patterns by serving as a single source of truth — a living product that can serve the needs of multiple product teams. This is true if you use an external design system, like Google Material Design, or establish your own.

In the midst of all this organization, one fact can fall through the cracks: While consistency can make a good experience even better, consistency alone cannot make a bad experience good. No design system can replace the need for cross-team communication and collaboration.

A design system is not a Band-Aid or magic tonic. Even with a design system, the success of your product still lies in the value it delivers to its users. The value of a design system is that it can enable a team to maintain its focus on the customer, rather than whether or not a development effort utilized the correct font sizes and button placement. The value of a faithfully built and managed design system is that your forest will be a forest, without having to touch every leaf and count every squirrel.

Design systems require flexibility

Like any product demonstrating value, a design system is never meant to be finished and shelved. When people describe them as being “complete” — meaning all-encompassing or cross-platform — there’s a misconception that the work will someday be completed. Just like software updates fix code issues, design updates fix experience issues. Unless you’re completely satisfied with v1, be prepared to iterate.

Maintaining order

Visual design follows user experience. Product designers identify experience problems and then design interfaces that help users. Starting a design system with visual design will limit your ability to solve a problem before one is even identified. Additionally, starting with the smallest level of visual design — which is the development model for Atomic Design — will create even more unnecessary constraints. This is where product design is different. Why should we design a table if we’re never going to use one?

Starting points for a product designer

Where does a product designer start? First, determine a core area of the product and use that as the foundation to begin building a design system. Evaluate that experience and improve the interface to better serve the user. A design system shares hard-won learnings across the experiences leveraging it’s patterns.

Next, take the new UI, language, layout, patterns and components and document them. This gives immediate purpose to the design system because we’ve already started using it to solve experience issues, right from the start. For later features, you might reuse components or you might have to create new ones that are better suited for each experience. Either way, you’re solving design problems — that should be the point. The alternative, removing component variations and replacing with templated patterns for the sake of consistency, undermines the very product you’re trying to improve.

What’s next for design systems

I’m excited to see where design systems are headed and what new techniques emerge. There are additional considerations about governance, maintenance, and implementing your design system on legacy products. At the core of the value is how they are utilized, and how faithfully they are maintained and managed. It’s a great new tool in the toolbox.

I wrote this article for Devbridge Group on March 3, 2018. The original article can be found here.