Make Your Design System Easy to Use 

When it comes to a design system, the work is the deliverable. The layers are the deliverable. The pixels are the deliverable. But a great design system is not just a collection of these layers and pixels — it’s also a robust set of guidelines that convey the intent of the system and a scalable set of rules that facilitate every design choice.

 I’m not an expert on design systems, but I am an expert on using them. Here are some credentials. Over the past eight years, I’ve used Apple’s Human Interface Guidelines and IBM’s IBM Design Language and Carbon in a professional setting. And I’ve created three design systems — the most recent one was for Drizly. All this is to say, I’ve cut my teeth on enough corporate design systems to form an opinion on them, and here’s mine: The biggest issue I’ve observed when it comes to design systems is compliance. You know, getting people — developers and designers, even product owners — to use them correctly. Here’s my advice for making your design system easy to use.

Don’t be a cowboy

A design system is only as powerful as its ubiquity. Apple had a term for failures in this: “cowboy features.” IBM would refer to unique components or experiences as “snowflakes.” There are colloquialisms for them because they’re that common. The problem with cowboy features is that they cause extra manual design labor, manual development labor, and potential disaster for your users. These out-of-compliance occurrences are untested, inconsistent, and undocumented.

I hear the screams of up-and-coming designers ringing in my ears as I type this. But what about innovation?! What about my creativity?! Use your creative genius on amazing information architecture or intuitive UX flows. Product design with a capital ‘P’ is all about consistency, scalability, accessibility, and efficiency, my sweet brothers and sisters. We’re solving real problems for users, not trying to win Webbys. 

If you’re finding that your team, startup, or massive corporation is running into a bunch of randomness between products or even between different pages of a website, it’s probably because your design system hasn’t been optimized to be used by the masses, or your design system needs to be expanded to account for more use cases. How do you optimize or expand? Let’s start with getting your design house in order.

Design like you’re going to die tomorrow

When designing with others, people need to be able to use your files after you’ve wrapped the project or if you’re no longer around to explain them. Scattered artboards, nameless layers, components buried in subfolder atomic hell (stop it with the molecules already, they’re meaningless to anyone that’s not an atomic designer) make it impossible (or at least very time-consuming) to pick up a design file and get to work.

Just like the experiences you’re designing, your design system file should be intuitive without your support. So put yourself in the shoes of a future designer or developer getting their hands on your file. Will they understand the organizational structure you’ve created? Will they be able to find components easily because they’re named simply, with human language? Will they understand how components and templates in your system work because all of your layers are organized, used consistently, and named consistently? 

This kind of feng shui design spirit should be pervasive throughout your work, even beyond a design system. Any deviation from this will cause future folks to misuse your system, or even worse, ignore it altogether due to frustration and confusion. 

Doc talk

If we follow the path of a design system implementation, the next stop is documentation. A great design system in a design tool like Figma or Sketch is not enough. First, it needs to be accessible to any audience. Second, your documentation needs to go beyond the pixels and dig into the philosophy of your system, show interactivity, and provide examples of how the pieces work together to create experiences. 

Apple is clearly a leader when it comes to documentation (its HIG is a freakin’ e-book). But IBM also has an incredible site, both externally and internally, for its design system. If you don’t have the kinds of resources necessary to make documentation like them, keep it simple. For Drizly, I used Confluence. And because our team did such a great job organizing our design system file, I was able to easily lift that organization and use it 1-to-1 as sections in our documentation. The design file combined with this documentation made it incredibly easy for our engineers to build all the components and styles in our system with minimal support from the design team.

Great documentation for your design system will ensure that everyone on your team or in your organization understands not just what the system is, but why it is. This is crucial for compliance. Design systems are not puzzle pieces robotically placed in an experience. They’re collections of pieces that work together with intention to form a cohesive backbone to any experience you’re creating. Additionally, a comprehensive understanding, rather than just a mechanical one, of your system will enable the entire team to contribute to it.

Contribution is innovation

This is the part where I’m going to contradict myself. Remember cowboy features from, like, 700 words ago? Well, to the rebel designer in all black that spat on that paragraph, I say, go for it. But go for it constructively and collaboratively. A successful design system is not just one that is followed by a compliant populace, but one that grows and changes to match new trends, technology, and use cases. And, usually, cowboy features can be a signal for improvement or expansion. Instead of treating them as destructive, it’s vital to review them, legitimize them, and disseminate them.

The concept of contributing to design systems is incredibly important and frustratingly challenging for teams to get right. If you’re creating a design system or currently using one, you need to make sure your process for contributing is as easy and accessible as is your design system. But the reality of this is significant, and ideally requires a dedicated team to maintain your system, which I realize is just not feasible for some companies. 

This is how IBM does it: Somewhere, buried in the internal documentation for the design system, is a link to contribute to the system. Clicking on this link brings you to a GitHub story template, where you can answer a series of questions about your contribution (including pictures and links). Then, some design system governing body reviews your submission, and if approved, they refine your submission and prepare it for development, adding it to the design system backlog. Once it’s developed, this dedicated team adds the design to the design library, the built contribution to the code repository, and eventually someone gets around to adding it to the documentation. 

This process is arduous, manual, and slow. But it works. And that’s the most important takeaway. Even a ~300k employee organization allows a junior designer to contribute to their design system and has figured out a way to release this contribution to the entire organization.

When you begin a design system, don’t forget this crucial piece of the pie. This process needs to be set, and someone needs to own it. I wish I had a perfect solution or even an opinion on this part, but I don’t. Work with your engineers to figure out a process, and iterate from there.

Here’s your TL;DR:

1. Make your design system file pristine, organized, and easy to understand. (If I see “layer 23” anywhere, I’m going to scream and then cry. Your coworkers will, too, if you’re not there to explain it.) 
2. Documentation should be accessible and understandable by anyone in your organization (even non-designers and non-developers).
3. Make it easy to contribute and expand the design system. Assign someone to manage and maintain it.
4. A design system is not a collection of components and styles. It should be the backbone of your company — a representation of your purpose and the foundation for your solution.

Samuel Sholkoff (he/him) is a Lead Product Designer at Postlight. Reach out at samuel.sholkoff@postlight.com.