I confess that I don’t care all that much about the corner radius on buttons, but this was the third discussion that week on the subject. Me and a team of talented, passionate product designers were sitting in a conference room, discussing some of the most basic components needed for the design system we had just begun designing. We were trying to build consensus around the initial batch of components. And we couldn’t get past the corner radius on buttons.

This was how the enterprise design system for Liberty Mutual began. It was an inauspicious start. It would take a lot of restarts and revisions and bringing in outside experts to give talks and trainings before we got to a point where we had a first version of the design system live, deployed, and used by most (but not all) engineering teams across the digital org. Our big mistake, the one I’ve seen committed at several organizations, is that we were focused on the wrong thing. We focused on the design of the thing when we should have been focused on process.


Why design systems

It should be apparent to every product team out there why they should build and maintain a design system. The benefits are clear: design consistency, development efficiency, scalability, accessibility compliance, and elimination (mostly) of design debt. The investment in building and adopting a design system are quickly recouped and supercharge the team’s ability to move quickly and effectively. But the initial effort can be daunting, and a team can quickly find the effort stalled. The team can find itself going round and round on things with little to no progress. It’s understandable when the team finds itself here that the organization decides to postpone the work. Hold off until the team has more time to tackle the work, start fresh.

The effort has most likely stalled out because you’re focused on the wrong thing: design. It’s counterintuitive but the design part of a design system is less important than the establishment of a design system and its adoption. Mature designs can come later. Getting a first version live is your goal.

With that in mind, here are three rules to keep in mind when starting a design system.


Engineering buy-in and advocacy is critical

A design system is the marriage of design and code. That’s it in the simplest of definitions. In that room at Liberty Mutual discussing button corner radius we had no developers. We had told them we’d get a first pass of base components and get back to them. We had effectively sidelined them. Similarly, when I was at DraftKings and we were starting our design system, we had begun it as a side project amongst the design team. We’d put something together and then show engineering and get buy-in. We didn’t get very far.

A design system without code is a style guide. And while that has value, it doesn’t bring you any of the benefits of a design system. Start with your engineering team. The benefits of a design system are as much for the engineering team if not more than the design team.

Additionally, you need them to build the components and then use them. Identify those within the engineering org that will support the effort, and advocate for it. They’ll be more successful than designers convincing other engineering teams to adopt the design system.


Perfect is the enemy of good

Once you’ve gotten engineering support and you’re getting to the hard work of designing components, remember one thing: the actual design doesn’t matter.

Well, maybe that’s an exaggeration, but it is absolutely true that you should not let perfect be the enemy of good. The faster you get a design system live and adopted, the better off you will be. Holding it up for additional rounds of exploration and revision of the design is not worth it.

Craft — Drizly design system v1

I did not care for the first version of the design system we built at Drizly. It lacked polish and was somewhat overwrought. It led some clunky interactions across the mobile and web platforms. We struggled sometimes to make the different components work together from a design perspective. But getting it live was more important for us than making it exceptional. And that was the right focus.

Over time we would strip the designs down and ultimately elevate the design. We would try new styles and deploy them quickly. We were able to tinker and experiment more effectively once the design system was live. If we had done this in the opposite order — perfect the design before going live — I don’t think we would have succeeded.

And this is an important thing to keep in mind as you’re working through the designs: your DS is a living thing. It will go through iterations, small and large. The design you launch with is not where you’ll end up (another benefit of design systems!). Having it live and in the hands of the product teams throughout your organization will greatly improve your ability and cycle time of experimentation.

Lastly, I’ll add that with new design systems, design teams sometimes struggle working with the components. They don’t fully work for all the scenarios. That’s normal. It takes time to understand how best to assemble the pieces, perhaps the need to sand down some edges and figure out new ways to put them together. This design exploration — with real DS components is an important step.


Process over pixels

Above all, focus on process. How will requests for new components be handled? What criteria will be used to determine if the request will be satisfied with a one off component, or the adoption of a new component? What is the method for making changes to new components? How will you monitor adoption? Who will be responsible for designing and building new components? What sort of governance will you put in place and how comprehensive is it?

At Liberty Mutual we really started making headway when we began mapping out the rules of the design system. We hired a product manager (design ops) to focus solely on the design system and the processes around it. We also hired an exceptional principal designer to head of design and work with the various design teams to help them understand the DS and think systematically in component development. We were investing our time and energy in the processes that mattered for design systems to thrive.

Think about your processes and governance. Here’s a great post by Brad Frost on the subject. This, more than beautifully designed components will power your design system adoption.


In conclusion

Start with process, not pixels. Build strong engineering partnerships before you perfect your components. Focus on adoption before achieving design excellence. And most importantly, remember that a design system is a living thing that will evolve far beyond its first iteration. The time you invest in governance, processes, and cross-team collaboration will pay far greater dividends than hours spent debating design details. Because ultimately, the most beautiful design system is the one that actually gets used.