Read time 7 min
Sometimes it takes a year or more for a design system to come to fruition. It’s worth the wait. Here’s how to make sure you build a design system that sticks.
Last year, I was part of a project team that built a design system for the Advanced Advertising department of ViacomCBS, a multinational media conglomerate known for brands like MTV, Comedy Central, and Nickelodeon. The goal of the design system was to speed up the development and unify the appearance of a suite of custom tools for ad sales representatives. The project went smoothly — we delivered on time, within budget, and our client was pleased. A few people started using the design system for their projects, and there was talk of them adding components. We were thrilled! We assumed that the design system would go on to enjoy widespread success in the department.
However, we soon learned that building a robust design system – one that lasts – is not so simple. At ViacomCBS, we worked for teams that were typically made up of people from different parts of the organization as well as other engineering partners. Building consensus among such a disparate group was going to take a lot more than simply building the design system. Six months after our project had ended, the design system had been adopted by a few engineers and designers, but it had been contributed to only once. Perhaps the system isn’t as robust as it needs to be, we thought.
Yet another six months later, well after we’d left the department, that same design system regained momentum and garnered praise from various product managers, stakeholders, and engineers outside our core team. It had proven itself useful. Looking back, we were intrigued: what, exactly, had happened in that year since the completion of the project?
Our design system’s life cycle holds lessons that we think are useful to anyone who is building and sustaining a design system, whether in-house or in a consulting role. Here’s what we’ve learned.
Spread the word
People won’t use the design system if they don’t know about it. It’s important to secure in-house support from the very start — even before you begin building the design system.
After our team finished the initial design system project, we moved on to projects for different clients. At the same time, new engineering partners joined ViacomCBS, so they were not yet familiar with the system we had built. Had we established enough word-of-mouth excitement early on in-house, it’s likely that the adoption of the system would have kept going even as the teams kept changing. But in our case many potential users were not aware of the inner workings of the system, or its uses or benefits, thereby leaving the design system to the side.
It’s important to socialize the design system as soon as possible and to create a fan base of designers, engineers, and product managers. Securing broad executive-level buy-in is key too. These stakeholders are the people who will keep utilizing and supporting the design system even after the initial excitement fades. In-house evangelists are especially important if the design system is built by engineering partners like us, people who will not be around to continue to vouch for its benefits.
Get clear on governance and contributions
When building a design system, one of the things that need to be decided early on is how the system will be governed and maintained. Will it be governed and maintained centrally or by distributed teams? Who pays for it? Who can make changes, and what does that change process look like? It’s not straightforward — or required — for design systems to have a home within an organization: by nature, design systems are meant to serve many types of users, and as a result, they may not have a clear (executive) owner as the steward. While there is no one correct model, it is important to decide on one for a design system. See Nathan Curtis’ article for more on governance models.
While we were responsible for building the foundations of the design system, we did not take the time to decide on a model with the client. There was no clear owner, nor contribution model. Not having a predetermined steward or budget may have been one of the reasons why designers and engineers stopped contributing to the design system: – it wasn’t clear whether they should spend time on improving it. We also did not clearly describe in the design system’s documentation what the contribution process should look like, which increased the threshold for contributing.
Work together with executives to lay down the terms with clarity and then document and communicate them clearly. That will pay off in a big way. Not having clear guidelines can paralyze a design system because no one feels responsible for it, and no one thinks they have the agency to contribute.
The technical choices that you make when building a design system will impact how easy or difficult it will be for users to learn to use it well and to contribute to it successfully.
Our design system has a somewhat steep-ish learning curve, both for designers and engineers. The technology that we chose allows for tremendous flexibility, but not all designers and engineers are used to working in a similar system. It’s true that they will eventually figure out how to use the components, but even then they may not feel confident enough to add new components to the system — especially in cases like ours, where the creators of the design system are no longer around to give feedback and encourage those contributions.
It’s fine to ask users to learn new skills if that means they can get the most out of the design system. However, you should provide them with training materials and documentation if that’s the case. The training materials could be in the form of office hours, training sessions, or short videos. The shorter and more interactive, the better.
Build a solid foundation
While, by nature, a design system has to evolve along with the products that it serves, the design and technology choices you make at the beginning will have to stay useful until there is a concentrated effort to update the design system. In some organizations, you may only get the budget to make significant updates if there is a return on investment in the early versions of the design system.
We stuck to widely adopted practices for both technology and design. We based our choices on researching best practices, researching the existing applications, and talking to the users and stakeholders of the system. We kept the list of components limited and focused on making those components as robust as we could.
Focusing on quality over quantity, and using best practices that are tried and tested, means that the design system can survive lulls in its usage or support in the company. That’s what happened with our project. Our solid foundation ended up driving support for the design system from the bottom up: designers said they like using it because it saved them a lot of time and energy in terms of the thousands of micro-decisions they’d otherwise have to make. And engineers estimated that our design system saved them about 30% of development time. That, in turn, helped spread the word and secure executive support.
Wait it out
It can take time for teams and companies to adapt to big changes. Progress can be slow or even invisible at the beginning, but that doesn’t mean you should abandon the project.
In our case, there were a few evangelists of the design system from the start, but it took a larger fan base to further spread the word and increase visibility. This was a slow process, especially as there were new engineering partners coming in who didn’t know about the design system at first. But over time, the number of fans and tools that used the design system grew. Steadily, the design system became more visible, and its effect on efficiency became impossible to deny.
If your design system does not catch on immediately, you can still keep spreading the word and demonstrate its value by using it. The more the design system is used, the more the stakeholders will start to recognize its worth: designers, engineers, and eventually product managers will understand the system’s benefits when they see them in practice. They will connect the dots between the increased efficiency and consistency and the design system. Sometimes, like for us, that can take a year or more to come to fruition.