Building a Successful Design System — 3 Lessons for Design Managers
There’s been a boom of great writing over the past couple of years on the topic of design systems. Mainly these writings skew towards the topic of craft: how and why to engineer and/or design them. Much less has been written on the topic of what it’s like to support and invest in a design system from the perspective of design management. So, please allow me to offer up a few thoughts that may help to fill that void. But first, a quick piece of history.
When I joined Zendesk in 2014 as VP of Product Design, we had no design system apart from some shared illustrator files (button styling and the like) and the well-intentioned beginnings by a couple designers to inventory our existing use of common UI elements. The company was growing like crazy and it was clear that we were at a point where designing for scale was essential and a design system was needed. Jonathan Zempel, a talented full-stack engineer whom I had worked with for many years, was hired to lead this technical undertaking.
Over the next two years, Jonathan and I pursued a strategy of trial and error in terms of how to instrument the adoption of a design system at our 2,000 person company. It wasn’t easy. Jonathan did all the real work and was the architect of the design system, which we would dub “The Garden”. For my part, I did my best to socialize the value of the initiative to other executives, provide funding for it, remove roadblocks and do anything I could to help think through the strategy of how to get people to use it. We made countless mistakes and learned a ton of interesting stuff along the way. The following are three guidelines which were born out of our mistakes.
Rule #1. Don’t Underfund it
It sounds strange saying this now, but simply having a full-time engineer on our design team invited a moderate level of skepticism when we were first starting out. People were doubtful that I could put a senior level engineer to good use if he was seated within the Design department. Many were even more skeptical that we could create a design system that Zendesk’s engineers would ever want to use. Looking soberly at the obstacles in front of us, I justified my plan for the design system as an “R&D experiment” and told people they could blame me if things didn’t work out.
For the next two years, while we struggled to crack the code of adoption, I constrained the design systems team to just one person, Jonathan. Jonathan struggled to do his best as a one-man design systems band — simultaneously appeasing the fickle demands of our engineering team while at the same time building a thoughtful partnership with our product designers.
One day, after nearly two years of struggling to get adoption, I asked a senior engineering manager for his thoughts on why my design system project was failing. He looked at me and said “your project doesn’t pass the bus test”. Puzzled, I asked him to explain. “If Jonathan gets hit by a bus, the design system goes away. You need more people.” he told me. A light went off in my head. It was so obvious. In my conservative underfunding of the work, I was failing to create confidence around the project. I needed more design systems people in case Jonathan were ever to leave or god forbid, get whacked by a bus. I had been holding back on funding the project more bullishly until I saw more signs of success, but by holding back, I wasn’t seeing success. After this epiphany, we quickly grew the Zendesk design systems team 500% from a team of one, to five. Don’t underfund yours like I did mine in the early days.
Rule #2: Hire for Empathy
The correlation between empathy and good design has been well documented, but your design systems team needs to be the most empathetic group in your whole design org. That’s because building a design system requires a lot of good listening skills. With any design system, engineers will scrutinize the technical infrastructure and designers will at first resist what they perceive as an infringement on their creativity.
So why do they need to be such great listeners? A design systems staff produces work at the intersection between design, engineering and the customer and it’s critical that they put a healthy amount of debate and socialization into every component they ship. Without debate, and without demonstrating empathy through inclusive and rigorous conversation, trust will never materialize and your designers and engineers will be far less willing to adopt the solutions provided by your system. Insist on hiring selfless and empathetic communicators — you’ll be thankful you have them around when the debates get a bit heated or you’re needing someone to win-over a grumpy holdout who doesn’t want to adopt the new way of working.
Rule #3 Deliver the Right Work at the Right Time
For anyone rolling out a design system, there is a classic chicken/egg problem to contend with. Until you have a large library of valuable components, what designer or engineer will want to go through the hassle of adopting your design system? But, without people adopting your design system, how can you justify creating a large valuable library of components? That’s why it’s so important for your team to deliver the right components at the right time. By planning closely and strategically with the needs of your organization, you can make your design systems team look like heroes by having them deliver time-saving design components that align perfectly with an urgent company goal. We call this the right work at the right time and you will be amazed at how much more motivated your organization will be to adopt a design system when it solves an urgent problem for them.
Today, I’m happy to report that our design system and the team behind it are both thriving. The team is well-funded and using their strength in numbers to focus even more energy on serving the engineers and the designers around them. Empathetic communication is what’s expected on the team, and I continue to see more people become believers in our system simply because they are included in the decisions. Lastly, the team is getting increasingly sophisticated at injecting themselves into product planning at earlier and earlier phases which is allowing them to plan for the needs that are coming around the corner so they can deliver the right work at the right time.
No matter how well you end up funding your design systems project, keep your team away from those fast-moving buses.
