Fig. 21 A Guide for Designers

Creation and Change within Design Systems

Creating defined processes that will help your design system project grow and thrive.

Written by Ryan Clark August 02, 2017

By now you’ve probably read all about design systems and how you needed one yesterday. Dozens of articles and documentation show what your system should cover and what tricks can help your Sketch files stay clean, but there’s little direction around the most important part of a system: how it actually works. How does something get into the system in the first place? How do you make changes without regressions across code and design files?

Over the last two years of working on enterprise design systems, we’ve honed our processes to ensure those questions are always answered, agreed upon, and documented. After a lot of trial and error, we’ve defined two main processes that need to be clear for a system to thrive—Creation and Change.

The Process of Creation

The Process of Creation is the process designers think about when creating (and dreaming about) these systems. Picking colors, defining styles, choosing typography—the world is your oyster. And that’s why it quickly becomes a mess.

The goal of the Process of Creation is to define the flow from design to system (and into development specs). Here are some questions that your Process of Creation should answer:

  • How does a design become a system component?
  • What is the criteria for componentization?
  • Where are components derived from?
  • Where are components tracked and stored?
  • Who is responsible for each section of the process?
  • Where is team review necessary?
  • Where is buy-in and sign-off needed, and from whom?

For us, the real crux of this process lies in the responsibilities. Where we continually got tripped up early on was where consensus and sign off is necessary, and by whom. Unless you’re working on a team of one, you’re going to have designs and proposals coming from multiple teams and co-workers. Establishing clear responsibility and ownership of the process is a key to success.

Also, don’t be afraid to use meetings to your advantage here. We’ve found the most valuable tool to creating a functional process is staying on the same page across teams. Using a quick twice-a-week sync to align on current proposals, specs, and implementations can save dozens of hours of wasted time across your team.

The Process of Change

If Creation is the process by which a design system comes to be, Change is the process by which it thrives and grows. One cannot exist without the other. If the goal of your design system is use (and it should be), then creating a system that can grow without breaking or failing is paramount. Without accounting for change, you will soon find yourself neck-deep in Jira tickets for regressions and bugs in the code, and dealing with outdated (or worse, flat-out-wrong) design files—not to mention the army of frustrated co-workers trying to work through these issues.

The goal of this process should be to define the flow from code to system (and then back to design files and documentation). Here’s some questions that your Process of Change should answer:

  • How and where are changes to components captured and tracked?
  • How are changes made to existing code with noted regressions?
  • How and when are design files updated to reflect changed components?
  • Who is responsible for communicating changes to other teams?
  • When is it necessary to review changes with Design and Product?

This is quite literally the single greatest point of failure for any design system, and it’s one that we work to mitigate across all our systems. We do that in large part by directing all the originators of the changes to a single traffic controller. System changes can come from UX, design, product, and engineering—sometimes with careful consideration and sometimes as a hot-fix. This creates a huge game of decentralized telephone unless the funnel for change is well defined and drives towards a single centralized owner. In our biggest system this is taken care of simply with a special change ticket in Jira. Changes are always assigned to the system owner, with outcomes communicated to the necessary teams and tracked. This allows for changes to get pushed all the way back up the stream to design files and prototypes, keeping everyone aligned and in sync.

If you want to see how our process works (or take it and build your own) you’re in luck! You can use our base process Sketch file or check out a PDF here.

As you build your design system, create these processes, and workshop them, make sure they meet the needs of every team your system touches, and then iterate and improve them. Without them, you risk creating a beautiful system that no one uses.