Design Systems Prepare You for Change

The moment where a design system proves its value most.

By Dan Mall — 10 December 2021 at 01:42:03 am

There’s a specific moment where everyone clearly realizes the value of having—or not having—a design system. It’s the largest test of a design system’s effectiveness.

What’s the moment? It’s when something changes… especially drastically.

Let’s set the scene.

First: definitions. “Design system” here doesn’t mean Figma or Sketch files, or brand/design languages. “Design system” means a version-controlled, package-managed, software product that’s a dependency in websites and apps.

Many organizations try to spark the flywheel that is the virtuous cycle between design system and product(s) releases, often using a method like the Measuring Spoon Cycle.

The Measuring Spoon Cycle for Design Systems. Step 1: make a product. Step 2: extract and abstract components from that product into a library. Step 3: make another product using the components you previously extracted. Then go back to Step 2. Rinse and repeat.

And it works! They use the flywheel to continue creating and releasing new and updated features and products. Essentially, they use it to continue what they’ve already been doing… except faster, more consistently, and at higher quality—the typical promises of a design system.

The return on investment is slow at first. At the beginning, using a design system might take the same time as not using one. Eventually though, the marginal gains start to add up. Teams start saving a week at a time, then 2 weeks, then 4 weeks. That increase in efficiency might take a year or two to start seeing.

Suddenly, something changes. Those changes usually come with these kinds of watershed events:

These changes can be local to a team or be organization-wide. They’re often unplanned, so they bulldoze established roadmaps. Even when they are planned, they’re not trivial to pull off, much less pull off well.

In these scenarios, a design system (along with an established design system practice) is a pivotal factor. These processes sometimes take years where a connected design system would make it take weeks.

Two quick examples of how it often works in each of those scenarios:

Change TaskEffort
RebrandingWithout a design systemFeature teams try to find spare sprint cycles to re-acclimate to and update old code2 weeks × # of teams
With a design systemSmall team changes a few design token aliases. All apps npm update to “receive” the rebrand.2 days
MergerWithout a design systemAll teams update their product’s header and footer with a new logo2 weeks × # of teams
With a design systemSmall team updates global header and footer components OR updates token alias/logo path served by digital asset manager2 days

This is where connected systems shine and really prove their value. This is where the ROI is much clearer: do you want this task be months of complicated code updates or days of relatively easy configuration changes?

Not surprisingly, these events often inspire people to think, “While we’re doing this, let’s look into creating a design system too.” Creating a design system at one of these inflection points ideally makes the next one easier and smoother.

The true test of a design system is how it works at scale, specifically making changes at scale. Organizational change tests design systems more than the product creation process does. The product creation process is simply practice and muscle-building for organizational change at scale. If a team isn’t set up to quickly change, say, the density within a particular screen of an application, that doesn’t bode well for their ability to change the density within a whole application or an entire suite of products.

The most important part of design systems isn’t the components; it’s the connections. In connected organizations, change is smooth. In disconnected organizations, change is disruptive and often destructive.

In summary, design systems prove their value most in how well they prepare your organization for change.