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.
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:
- Rebranding
- Mergers/acquisitions
- Technology re-platforming
- Migration
- Re-org
- New tool integration, e.g. CMS
- New process change, e.g. agile
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 | Task | Effort | |
|---|---|---|---|
| Rebranding | Without a design system | Feature teams try to find spare sprint cycles to re-acclimate to and update old code | 2 weeks × # of teams |
| With a design system | Small team changes a few design token aliases. All apps npm update to “receive” the rebrand. | 2 days | |
| Merger | Without a design system | All teams update their product’s header and footer with a new logo | 2 weeks × # of teams |
| With a design system | Small team updates global header and footer components OR updates token alias/logo path served by digital asset manager | 2 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.
Read Next