Set Your Design System Up for Success
A design system can fail without careful forethought, diligent effort, and support
Design systems are so hot right now — and for good reason. They promote a modular approach to building a product and ensure organizational unity and stability via reusable code snippets, UI components, and utility styles. They make prototyping a breeze and provide a common language for both designers and developers.
A design system is a culmination of several individual components, which can include any or all of the following:
- Style guide or visual pattern library
- Design tooling (Sketch library, for example)
- Component library (where the components live in code)
- Code usage guidelines and documentation
- Design usage documentation
- Voice and tone guidelines
- Animation language guidelines
Design systems are stand-alone (internal or external) products and have proven to be a very effective means of design-driven development. However, in order for a design system to succeed, everyone needs to get on board.
I’d like to go over a few factors that can help ensure — or hinder — the success of your design system. Some of these concepts will be more developer-focused, but most are adaptable across disciplines.
Organizational support
Put simply, any product, including internal products, needs support. Something as cross-functional as a design system, which is used by every vertical project team, needs support from the top and bottom levels of your organization.
Top-level support means everyone from project managers up through VPs understands the value of a design system, provides resources for its implementation, and advocates for its use company-wide. This is especially important in companies where such systems are being put in place on top of existing, crufty codebases, because it may mean some effort needs to be scheduled for refactoring work.
With design systems, small incremental investments over time lead to big gains overall.
Support from the bottom up means that designers and engineers of all levels support this system and feel responsibility for it. A design system is an organization’s product, and everyone should feel confident contributing to it. If your design system supports external clients as well (such as contractors), they too can become valuable teammates.
Investment
A design system needs support and love to grow. It also needs continuous investment of effort and resources. I like to compare this to working out.
You can work out intensely for three months and see some gains, but once you stop working out, those effects will slowly fade away. If you continue to work out, though, even if it’s less often than the initial effort, you’ll see yourself maintaining your fitness.
Similarly, if you spend three months overhauling your design system but neglect to keep it up, you’ll face the same situation. The impact will fade as the system gets out of sync with new designs and you’ll end up with disconnected bits of code and design elements that nobody is using. Your engineers and designers will stop using it as the patterns become outdated, and then you’ll find yourself dreading another round of substantial investment.
With design systems, small, incremental investments over time lead to big gains overall.
With this point, I also want to note that because of how they scale, design systems can make a considerable impact across the platform, making it extremely important to invest in things like accessibility and solid architecture from the start. You don’t want to scale a brittle system that’s not easy to use.
Take care of your design system, and keep working on it to ensure its effectiveness.
Responsibility
One way to do this is to have a dedicated team working on the design system, managing tickets and styling updates that trickle out to the rest of your company. With a specific team to act as owner of the design system, whether it be the design team, engineering team, or a new team made up of both designers and engineers (the best option), your company is more likely to maintain a relevant, up-to-date system that doesn’t break.
This team is responsible for a few things:
- Helping others get set up on the system (support)
- Designing and building components (development)
- Advocating for overall UI consistency and adherence (evangelism)
- Creating a rollout plan and update system (product management)
That’s a lot of roles, so it helps to have multiple people on this team, at least part time. One thing I’ve found to be effective is to hold office hours to help everyone get set up and to answer any questions about using the system. Having an open Slack channel also helps with this, as well as with bringing up bugs/issues/ideas and making announcements like new releases.
Communication
Once you have resources and a plan to invest in a design system, it’s really important that the person or team responsible acts as a bridge between design and engineering. Continuous communication is crucial here, and the way you communicate is even more important.
Remember that nobody wants to be told what to do, especially designers and developers, who are often used to a lot of autonomy. Despite how much or how little control the other stakeholders have over the process, they need to feel like they have input and feel heard.
Building and maintaining a design system is surprisingly a lot of people-ops work. To get buy-in, you need to make people want to use your design system.
This can be challenging, especially since ultimately, some party needs to be making a final decision on direction and execution. Because it’s a hard balance to strike, having open communication channels and being as transparent as possible as early as possible is a good start.
Buy-in
Good communication is also important for getting buy-in from your users (the engineers and designers), as well as from product management.
Building and maintaining a design system is surprisingly a lot of people-ops work.
To get buy-in, you need to make people want to use your design system.
Gather examples and usage wins, because showing is much more powerful than telling.
If you can, have developers use your product in a low-stakes situation where it provides clear benefits. “Hackathons” are a great place to debut your design system. Our internal hackathon at DigitalOcean was a perfect opportunity to:
- Evangelize for the design system
- See what people were using the component library for and what they were struggling with (excellent user testing there)
- Get user feedback afterward on how to improve it in future iterations
- Let people experience the benefits of using it themselves
These kinds of moments, where people explore on their own, are where you can really get people on your side and wanting to use the design system, because they can get their hands on it and draw their own conclusions (and if they don’t love it, listen to them and improve it so that they do). We don’t always get so lucky as to have this sort of instantaneous feedback from our direct users.
Architecture
To make sure your design system is scalable, it’s important to develop a solid architecture early on in the process. Build your design system with growth in mind. What happens if your company acquires a new product? What happens when it develops a new market segment? How can you make sure there’s room for customization and growth?
A few things we’ve found helpful, from a development standpoint, include:
Namespacing
Use namespacing to ensure that the system doesn’t collide with existing styles if applied to an existing codebase. This means prefixing every element in the system to indicate that it’s a part of the design system. To make sure that you don’t break parts of the existing build (which may have styled base elements), you can namespace the entire system inside of a parent class. Sass’s nested structure makes this easy.
This kind of namespacing wouldn’t be necessary per se on new projects, but it is definitely useful when integrating new and old styles.
Semantic versioning
I’ve used semantic versioning on all of the design systems I’ve ever worked on. Semantic versioning uses a system of Major.Minor.Patch for any updates. You can then tag releases on GitHub with versioned updates and guard against someone’s app breaking unintentionally when there is an update, if they are anchored to a specific version (which they should be).
We also use this semantic versioning as a link with our design system assets (our Sketch library) to keep them in sync, with the same version number corresponding to both Sketch and code.
You have to make your design system the path of least resistance, lowering the cognitive overhead of development and design, not adding to it.
Our design system is served as a Node module, but it’s accessible via our CDN as a series of built assets for quick prototyping and one-off projects. For these built assets, we run a deploy script that automatically creates folders for each release, as well as a “latest” folder if someone wants the always-up-to-date version of the design system.
So, semantic versioning is what links our design system Node module assets, Sketch library assets, and statically built file assets. Providing multiple ways of consuming our design system makes adoption easier and reduces friction.
Friction
A while ago, I posed the question of why design systems become outdated and unused, and a major conclusion I drew from the conversation was: If it’s harder for people to use than their current system, people just won’t use it.
You have to make your design system the path of least resistance, lowering the cognitive overhead of development and design, not adding to it. This is vital. A design system is intended to make development and design much more efficient, enforce a consistent style across sites, and allow everyone to worry less about small decisions like font sizes and HTML semantics. These are already sorted out for them, meaning they can focus on building the product.
But if your design system is complicated and over-engineered, they may find it frustrating to use and go back to what they know, even if it’s not the best solution. For instance, if you’re a Sass expert and you base your system on complex mixins and functions, you better hope your developers are also Sass experts, or want to be. This is often not the case, however. You need to talk to your audience and learn about how they work and how they’ll want to use your system.
Reducing friction for adoption should be a major goal of your design system rollout.
Conclusion
Having a design system is enormously beneficial to any product, especially as it grows. In order to have an effective system, it’s important to always keep your user in mind and garner support from your entire company. Once you have support and acceptance, this system will flourish and grow. Make sure someone is responsible for it, and make sure it’s built with a solid foundation with a plan for careful maintenance. Good luck!
Originally published on the 24Ways blog, modified slightly for a Modus audience.
