There’s no denying the valuable powerhouse potential of well thought-out design systems. They can provide live, interactive examples of often used components, assist the rapid build of new pages and applications, and ensure brand consistency by providing stable “trickle-down” CSS changes. A design system (or “style guide” or “pattern library”) can change the way a large team builds the web.
In the past, we’ve talked about the many challenges a product team may encounter when choosing to build a design system. But what about the difficulties of a mature design system? Nearly two years and three major versions since beta, the enterprise design system I’ve spent the past 16 months working on still faces the same question: “How do we encourage people to keep using our design system?”
The answer: In order to convince subscribers to use your design system, treat it like a product. This is not a new concept; it’s not even new to The Foundry. Last year, Bryan wrote about how to create a design system with a good chance of adoption. But how do we continue to keep subscribers engaged in our design systems after adoption and as the system grows?
Build Something Desirable (And Get It Funded)
The first step to having a good design system is, well, having a good design system. As Bryan said, find a frustration point your subscribers have, and ease it. If your design system team is separate from your product development team, attend the product team’s standups or feature-planning meetings. Have someone on the ground to identify potential pressure points before they become problems (we call this person an “ambassador”). Develop solutions to these problems or frustration points when possible, and include them in your design system. This has encouraged adoption of our design system by giving our subscribers something they really want.
If you want a team to take your design system seriously, try taking it seriously yourself. Finding the budget to support at least one full-time developer on your “idea” of a system may seem difficult or even impossible at first. Look for funding in interesting places, such as under UX or Research & Development. UX has a potential vested interest as well, because design systems often create consistency throughout branded experiences. If your team has an R&D budget that can be a great place to create “startup” kind of projects. Having a funded product with a committed product owner or development team will help users treat your design system as “real.”
In summary, build something useful, back it with whatever budget you have available, and win trust by solving your subscriber’s problems.
Offer Constant Support
Educate Your Stakeholders
A successful design system team does not “pass off” the system as updates happen; rather, they support subscribers throughout the adoption process. We try to be available to pair with the developers and designers using what we’ve built. Subscriber needs, within reason, are always at the top of our priorities. Teaching people to use a design system takes time and effort. Education pays off, though, as knowledge of your design system becomes ingrained in your subscriber’s team culture. Eventually product teams can teach one another without much intervention. To begin, perhaps run an internal workshop or lunch and learn whenever you have something new to share.
Create an Outlet for Feedback
Provide a path for subscribers to submit feedback and ask questions. Our design system team set up a dedicated channel in Slack and Microsoft Teams, allowing constant contact with subscribers. We’ve also added a link to our documentation site that goes to a Google Form for those who wish to provide anonymous feedback. Full disclosure: Our subscribers rarely submit feedback via the form, as they prefer to reach out personally via chat whenever they have questions.
Document All the Things
Documentation is so, so important. Having an easy-to-use UI to display the content is just as important as writing good developer documentation. Develop a plan for semantic versioning and document it well. Design system teams are often small and a good documentation website (affectionately called “docs site”) often helps users solve their own problems without direct intervention from your team. Luckily for us, our product owner is a fantastic UX designer, as well as our biggest advocate. Being present and available to help your users implement design system components shares the burden of change that often prevents humans from wanting to adopt a new dependency.
Iterate as the Need Arises
On a design system team, some endeavors—even when thoughtfully approached—are guesswork: predicting potential brand updates, estimating upcoming component work, forecasting political decisions, or prioritizing pipeline changes. Chances are, some of those guesses are going to be wrong. What can we do to minimize the guesswork and make educated choices?
For every major decision, our design system team interviews stakeholders to validate assumptions we make. This is especially important if your design system team is not directly implementing the designs, elements, and components in the product environment. For our team, every Tuesday is “Discovery,” where we test an assumption, respond, and prepare for Thursday’s “Planning,” where we determine our next round of work.
The goal is to make well-informed, educated guesses as often as possible. Sparkbox takes great pride in our skills at forecasting and estimating engagements, so it makes sense that when we are building design systems, we aim to correctly forecast our product teams’ work. We get better with every iteration.
Maintain Interest with Marketing
Around Sparkbox, we’ve begun joking that a “pattern library” turns into a “design system” once you give it a name. Well, that’s not far from the truth. When a design system has a name—a brand—it can become a real product. Think “Nachos” from Trello, or Shopify’s “Polaris”. Some of the best names are drawn from punny vernacular relevant to the product your team produces.
Once you have a name, the next step is to brand your domain. An “official” sounding domain, such as “design.trello.com” or “lightningdesignsystem.com” lends instant credibility to your design system. Also, those names are way easier to remember and thus easier for subscribers to use.
Branding your design system is a key step toward marketing. Consistent marketing of a design system—and its updates—helps keep subscribers engaged. One way our design system encourages the adoption of version updates is by creating a “business case” for every major or minor version. We send out email and messaging announcements with links to our release notes, a quick overview of what’s new and what’s changed, and an answer to the question, “Why Should I Update?” Writing a strong, persuasive answer to this question for every release has improved our subscriber buy-in quite a bit.
Let It Bloom
A major risk of building a design system is that no one will use it. This can happen if the system ignores user needs, is not regularly updated, and has no marketing push around it. However, if you invest in your design system, build a network to support stakeholders, and solve the problems of your product teams, then your design system can turn into a useful product. Attempt to validate every assumption with the developers, designers, and content managers who actually use the system you are building, and iterate on the feedback you receive. Toss in a little marketing, and your design system will bloom.
Looking for more on design systems?
Sparkbox is dedicated to sharing our experiences and discoveries about design systems. Sign up to get updates on design system content including our annual Design Systems Survey!
