Building a design system in an engineering-driven company: a few lessons learned

Few years ago, a very small team of engineers and designers built Clarity, VMware's first design system. Today, it's one of the most successful open source design systems out there.

I often talk to design leaders across the industry and hear their difficulties in getting a design system off the ground so I thought sharing some lessons here might be helpful.

Know who you're selling to: engineers

As designers and user experience professionals, a big part of our job is to empathize and understand our users. Our power is in our ability to understand the human in "human computer interaction". However, we don't use that skill enough to truly understand the motivations and constraints our partners and cross-functional teams have. We also don't spend enough time understanding and emphasizing with our cross-functional partners in engineering and product management as much as we do with our end users.

As a designer or a design leader in an engineering-driven company, deeply understanding the motivations of engineers is core to your ability to succeed in moving the culture towards user experience. Selling a design system solely on the basis of the values it brings to user experience or to designers is generally a mistake. The goal is to bring front and center the values those in the room care deeply about.

At VMware, one of the areas we focused on the most as we started discussing Clarity is the efficiency Clarity would bring to how we build and design our applications. We focused a lot on our ability to standardize the front-end layer, not just the user experience or visual layer.

We highlighted and spent a significant amount of time on the engineering architecture of Clarity and spoke the language of engineers as we explained it. We had a team of top engineers working and that continue to work on Clarity. We had deep dive discussions on the technology as much as we did on the design.

Success is about adoption not completion

As I sat down with our VP of user interface to discuss possible funding for Clarity to join his team and lead this, we had long and deep discussions about what success means. We were clear on the fact that building a design system is a milestone, not a success in itself. If we had built Clarity, and nobody adopted it, we would've considered it a failure.

We agreed on day one that adoption would be our metric. We both acknowledged that adoption is a tricky metric because we actually don't control all of it. To do this, we looked at what possibilities do we have to ensure initial adoption happens. To do this, we moved in two directions:

1. We aligned Clarity's engineering funding with two important products that our VP of UI owned on the front-end engineering side. In our case, that was vSphere, and a new product at the time: VMware Cloud on AWS.
2. We went on a tour across the company to sell Clarity, a design system that has not even been built yet, to products and services. After weeks of conversations, we were able to successfully sell Clarity to two small product teams. Our sales pitch was around our ability to help them move faster, give them premium support (direct access to me and our developers), and a modern interface that would sell their customers on the future of where VMware's user experience is going. This sounds easy, but it took weeks of conversations, dozens of meetings, and dozens of rejections. I still have some of those rejection emails, all of these teams that initially rejected us are now products that have adopted Clarity.

Although open source has been a huge part of our success and it seems like a vision we had to begin with, it wasn't. We did open source a year or so in, and it's been one of the huge driving factors in accelerating adoption of Clarity, even within VMware. However, it wasn't part of the original vision from day one.

Be independent and opinionated

Having Clarity as an independent team, even outside of the design team at the time, allowed us to operate quickly and be opinionated about the decisions we needed to make to execute. We operated as one team of designers and front-end engineers working closely together. It created a culture like no other. We were one team working in a startup-like culture to survive. And we did.

I look fondly at that time, but at the time, it was a difficult, uncertain, and bumpy journey.

Being opinionated about the style, the code, and the architecture was one of the most difficult things we've done. Many of the rejections we've had were based on an opinion we held that others disagreed with. However, being opinionated and realizing that pleasing everyone isn't our charter was also one of the most important reasons we succeeded in the long run. Pleasing every other engineering, UX, and product management team isn't how you build a system. This does not mean you don't listen to the needs of your customers, it means that you listen and understand but make the final call based on all the information you have including information those teams might not think about. This is especially true considering the fact that you're building a system while your customers are thinking about building their product or service.

I understand that being independent and opinionated is a privilege that not all design teams get. However, if you have a shot at this, take it. Being opinionated specifically isn't easy, it's a battle you need to take every single day. We still do. It doesn't get much easier.

Build it right, and you'll transform design at your company

Clarity, without a doubt, is the reason we're transforming design at VMware. It's a part of why I am leading VMware Design at the moment. It gave us the credibility to lead as we move forward. It's why many of our leadership team members understand the possible impact of design. Our customers now know what design from VMware can do and they know Clarity by name. Clarity has been able to raise the bar for us and for our customers. Because of the foundation Clarity built for us and the layers we've been building on top of it, we've been able to start our transformation and move into an experience-led company.

Design transformation deserves its own post but start your design system journey right, and the impact could go far beyond a design system. You might just build a better design team and a better tech company.

If you found this useful, you can follow me on Twitter here where I continue to share my journey as I lead design at VMware.