For a design system to benefit a company’s experience design strategy, employees must use — and embrace — it. This is why design leaders must be careful during the rollout about anything that could discourage adoption. That’s the advice of Jeoff Wilks, director of IBM’s Carbon Design System. In this interview, Wilks shares effective ways to encourage adoption of a design system (hint: Avoid top-down mandates).
Why is a design system so crucial to the customer experience today?
To me, it’s an operating system for experiences. An OS like Windows or Linux requires user interface guidelines, toolkits, and libraries. To get cohesive experiences in an OS, you need a set of guidelines that apply across applications. A design system solves this challenge for companies across websites, mobile devices, and multiple software platforms. It’s not tied to a specific software platform like an OS might be. Rather, it’s trying to produce consistent shared experiences across products to create continuity for users.
With an OS, you don’t have to relearn the meaning of the OK button, the file menu, and the dialog box. They’re all familiar to you. Habituation to these OS elements makes everything go faster for the user. A design system tries to do the same thing for a company.
How are you driving adoption of IBM’s design system?
We’re planting a seed inside each business unit at IBM that gives them a vision of how the system helps them. We show how it accelerates development times and improves quality. Once someone in a business unit sees that, they tend to tell others about it and help them solve problems.
I find that it helps to let market forces encourage adoption: Start with something small and make it really valuable to one group of people. If it proves its value, then you expand it. So, you’re adapting to feedback from a market — even if it’s just internal people. Market forces help adoption grow faster on its own through better quality, support, and self-service documentation.
I’m a huge proponent of discoverable self-service, not just in end-user experiences, but also in the design system itself. If someone has to have a meeting with you to figure out how to get onboarded with your design system, then you don’t have a design system — you just have some assets people have to be introduced to.
When we started our design system, we knew it had to be discoverable. It can’t just be some hidden asset that nobody knows about. So, we made a website that people could find. We open sourced it to make it even more discoverable. IBM has 400,000-plus employees, and we’re helping everybody at the company find it.
How do you feel about top-down mandates to adopt the design system?
We were given the option to “lay down the law and just make all the teams adopt.” We had a few business units that were skeptical, thinking we were going to suffocate them or dump a bunch of new requirements on them.
But I prefer using champion projects, where we work as advocates to help designers and developers succeed. The people who do that often catch the fever and want to promote it to the rest of their business unit. They want to be seen as the expert on the design system and they become its champion.
A mandate is a seductive trick because user experience can’t be forced. People who haven’t totally bought into the system will do the minimum to meet the mandate and then blame you for wasting their time because you didn’t solve their UX problems.
It all comes down to quality. A mandate gives you the power to force people to use a low-quality product. Then you lose trust and drive bad outcomes at scale. We instead take a customer service–oriented approach and focus on quality and self-service. Voluntary adoption is the feedback mechanism to tell us how we’re doing. That doesn’t work by force.
What do you think people often misunderstand about design systems?
A lot of people think a design system is a library of components or patterns they can grab. But to me, the system’s guidelines are just as important. The guidelines introduce the relationships between all the parts of the design system and explain how to use components related to each other individually, together, and in patterns.
Here’s an analogy: Think about all the different parts in a set of Lego toys. Arguably, all those parts are a kind of design system because you can make beautiful things with them. But you also can jam a bunch of Legos together and make something with no form, character, or beauty. In my mind, the guidelines are what sets a design system apart.
How do you measure the impact of the design system?
We look at metrics on adoption and system quality. How many bugs do we have? How many support questions do we get? Are those going up or going down? Why? Support questions might be rising because of a jump in adoption or a loss of quality.
We measure how many teams and products use the design system in their production code. Our code is in their product. We track that and look for ways to grow it. We also have user experience measurements to track improvements in products. So, we do sequential walk-throughs of products, from discovery through in-depth use.
What impact do you ultimately hope the design system has on collaboration at IBM?
We have lots of collaborators across business units. We’ve also told people they can go beyond using the design system’s components and actively contribute to it. The people who took us up on that have become even deeper collaborators.
I like to look at what has happened in open source software development. There’s an incredible flourishing ecosystem of collaborators that have produced incredible achievements like the Linux kernel, which runs a lot of the things we do online.
Design has not achieved that yet, but it can. Designers often want to hide their work until they feel it’s perfect. Then they’ll have a big reveal. That happens in software, too.
What we’ve seen with the open source movement is that what begins as buggy, incomplete software eventually evolves into something of incredibly high quality — as long as people stick with it. I think design can do the same thing.
If designers can get comfortable working in the open and contributing to something larger, they will have a few moments of embarrassments and backlogs of bugs, but over time they can produce really high quality with broad, deep participation from a variety of people.
If we could even get a fraction of our community — 1%, 5%, or 10% — to actively contribute to our design system, we could see really awesome growth. I would consider that a huge success.