Design systems are not a fad

By RocketAir Crew
June 26, 2019

They're just a better way of building your product.

Food for thought

If you and your firm are currently in the process of planning a redesign of your flagship product, there’s a good chance you’ve read—or at least heard—something about design systems. Like CBD or Instant Pots, design systems are one of those things you probably start to read about everywhere as soon as you hear about them the first time.

In other words, design systems are very trendy right now. But in the same way that a cliché’ can become a cliché’ because there is an inherent truth to it, design systems have become trendy because they are being recognized as intrinsic to the process of redesigning a legacy product.

Before we take a deeper dive into building a design system, we’d like to point you to a very simple analogy to help you better understand the functions of a design system. Courtesy of Courtney Clark, Vice President of Design at Forum One, we share with you the Taco Bell analogy. Yes, Taco Bell; the purveyor of Mexican and Mexican-inspired food that you may love and regret in equal measure.

Here’s Clark’s explanation:


"

Taco bell has about eight ingredients and yet, they have about 50 items on their menu. And guess what? They're just mixing and matching those same eight ingredients in different ways. With eight ingredients, you can make a taco, a quesadilla, or a [insert your favorite late night Taco Bell treat] same idea applies: this is a design system.

"

Granted, if you’re not well-versed in design systems, Clark’s Taco Bell analogy might not quite register with you just yet. But bear with us and you’ll soon understand how a design system is not too different than a Taco Bell menu that offers you both a Crunchwrap Supreme and a Spicy Loaded Nacho Taco.

Bigger, better, cheaper

In the Design Systems Handbook—published by Design Better and written by Marco Saurez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield—the authors point out one of the more challenging realities of design: Because design is a bespoke service, it makes design “slow, inconsistent, and increasingly difficult to maintain over time.” In other words, by providing “tailor-made solutions for individual problems,” designers can target a specific UI and UX—which is awesome!—but when you are creating a solution tailor-made to address a single problem, it becomes really difficult to scale your design when you begin building multiple applications.


With a design system in place, not only can you scale a legacy product, but you can do it consistently and more efficiently. And whenever a process is more efficient, it will ultimately be more cost-effective. Having a design system in place for legacy products then is good business practice.

So, what exactly is a design system? Well, as Forum One’s Clark notes, there really isn’t a settled-on definition—or even name, for that matter. It’s been called design language, Brad Frost has his Atomic Design, it’s also been called modular design, and so on. But as Audrey Hacq at the UX Collective succinctly puts it, a design system “is not a deliverable, but a set of deliverables. It will evolve constantly with the product, the tools and the new technologies.”

This “set of deliverables” are the reusable components (or reusable code) that make up your design system. But keep in mind these are standardized components—meaning all of these components follow a set of established standards as they are used to build multiple applications. These standards ensure that the product design remains consistent across multiple applications, UIs and teams.

For instance, when you think about the visual or design language you’re using on a product—from colors to typography to spaces to shapes to sounds to animations and beyond—you’re going to need them to be consistent across many different pages. If it isn’t consistent across these multiple UIs then the user experience is obviously going to suffer.

Which means that the language has to be consistent among multiple teams that are working on the redesign—designers, engineers, front-end developers, etc.

 

“Visual language is like any other language,” as Airbnb’s Karri Saarinen explains. “Misunderstandings arise if the language is not shared and understood by everyone using it. As a product or team grows, the challenges within these modalities compound.”

A look underneath the hood

According to UX Collective’s Hacq, the role of a design system is to serve as “the single source of truth which groups all the elements that will allow the teams to design, realize and develop a product.”

Another way to think of it is that it’s the engine that puts your design in motion. What then do we see when we pop the hood and look at our design system? Well, it depends on the system—remember that there isn’t a unified definition to go by—but here are a few things you will probably see:

Standards or Principles

This are sometimes also referred to your team’s values. These are the standards by which all of your components will follow. What do you want your product to achieve? How do you want the end-user to view your product?

Style Guide

This is where you set the guidelines for fonts, colors, spacing, images and all your other visuals. Before you get to this step, we recommend you follow Will Fanguy’s advice and conduct a visual audit of your product, because by taking “inventory of the CSS you’re using and the visual qualities of the elements can help you gauge how much of an undertaking this process might be.”

Components

These are referred to by Hacq as your “LEGO” blocks that are “used in Sketch by designers, and directly in the code by developers.” As part of your standards, you will have to define how these building blocks will be used when redesigning your product.

Pattern Library

The pattern library will be where you keep your components, which “means every button, form, modal, and image. Merge and remove what you don’t need,” as Fanguy notes.

Documentation

This is where you track what each component in your design system is and how it is used within the product.


In terms of what a design system actually looks like, you can head over to Adele, which has a large library of design systems created by a number of different sources.

Menu options

Let’s go back to that Taco Bell analogy from Forum One’s Courtney Clark: While it can sometimes seem as though Taco Bell has a bunch of mad scientists in a laboratory figuring out an endless number of ways to make a taco, with each scientist trying to outdo the other and dream up the craziest snack chip that can be transformed into a taco shell; there is actually a method to the madness.


Say you’re drunk and you’re craving a Crunchwrap Supreme; or say you’re drunk and craving a Spicy Loaded Nacho Taco; whichever one you choose, you’re getting the same main ingredients either way: seasoned beef, cheese, lettuce and a tortilla. The difference in secondary ingredients are minimal—tomatoes here, sour cream there—but they’re all being pulled from those same eight or so ingredients (or components) that Taco Bell’s employees will always pull from regardless of what they’re making. There is an amazing consistency to its menu.

This is what a design system brings to your legacy product: It’s like a menu that provides you with the foundation and the building blocks to scale and redesign your product. It provides order and consistency to your UI and UX. You can add and subtract components, while maintaining order.

Sure, design systems have become trendy; but they’re not a fad. They’re just a better way of building your product.