Selling a Design System at Your Company
By: Nick Stamas
Tags: Design Thinking, Design, Design Systems, Design Process, UX

Find common pain

At WeWork, the first app I opened when we started wasn’t Sketch. It was Google Docs. You need to clearly articulate the problems first, with words and sentences. Be specific. Where are things breaking down? Where are the biggest pain points, not just for you, but for the whole team? A design system doesn’t exist in a vacuum, it needs to solve problems for everyone. Find the common pain. For example:

Your team is spending a lot of time doing painstaking visual QA.

Pain: Developers hate pixel-twiddling. Product managers hate moving slowly.

There’s strife when your beautiful mocks somehow morph into mutant bastard-children on their way into production.

Pain: Developers hate to make guesses about fuzzy mocks and specs. Product managers hate shipping broken features that no one feels good about.

Your product has 12 different types of dropdown menus that all behave slightly differently.

Pain: Developers hate reinventing the wheel. Product managers hate inconsistencies.

Fail to plan or plan to fail

Once you’ve articulated pains, and framed them in ways that speak to your stakeholders, you need to develop a way forward. You don’t have to have all the right answers. The goal isn’t necessarily even to end up with a “design system”.

The goal is to develop a specific, realistic plan that addresses the pain points of your team.

For Plasma, I worked with our project manager to lay out a five-week plan, broken down into weeks, and then into days. We weren’t going to be able to stop working on the normal flow of product work, so we accounted for that.

We started with info gathering, research, inspiration, making a thorough audit of our current products and brainstorming ideas. In this phase the goal was to refine our understanding of the problems and create a divergence of solutions.

Next we started to narrow our focus, forming a higher-resolution picture of where we could add value. It became clear: we didn’t have a design problem; we had a communication problem. Our designers and developers weren’t speaking the same language. This became a guiding principle behind where we focused the Plasma system.

Sell the vision

When you’re starting this process, you won’t know exactly where you’ll end up. And a design system isn’t a silver bullet for fixing all design-related problems. You should be honest about that.

But it’s crucial that you continue to do the work of selling a vision that everyone can buy in to. Selling is a process, probably more than a single meeting. Look for teaching moments. Use your storytelling skills. Show your team that a better way is possible. Come up with a memorable name and say it a lot. Get people excited with a splashy presentation. Channel your inner Don Draper or 2007 Steve Jobs.

For Plasma I created a short keynote early on that I presented to several different groups of engineers. I focused on how Plasma would unify design and development, allowing us to speak a common “UI” language. I used their words: it would be declarative, composable, testable, and source controlled in Git.

Despite your best efforts, you’ll run into skepticism. Here’s a few things I’ve encountered:

An engineer thinks a design system needlessly creates more work for them, or will be a technical liability long-term.

Find the engineer who seems most excited about the idea. They’re your new best friend. The most effective design systems have both “design” and “code” components. Work with them to find solutions for bridging the design/code gap. At a minimum they can help you “speak engineer” and win over skeptics on the team.

A product manager thinks a design system is too costly to develop and roll out.

Involve your product manager early on. Product managers think in terms of cost versus benefit. How can you spend a little to deliver a lot of value? What can you do incrementally? Work with them to develop goals and timelines.

Someone thinks a design system is just about creating a “prettier” product.

Design systems are created for many reasons, but rarely just for aesthetic purposes. A design system can create value on at least two levels. At the team level it can create a more streamlined, predictable process that reduces design and engineering time. At the user experience level it helps to deliver consistency and predictability in the interface, and to raise the quality of the experience overall when designers and engineers are freed up to think about higher-order tasks.

Someone wonders why you don’t just use something off-the-shelf?

This actually might not be a bad idea if you’re working with a young team or product and don’t yet know where a more custom system can add value. But design systems aren’t one-size-fits-all. And sometimes an overly rigid or complicated system can be worse than no system at all, narrowing thinking or being a weight around your collective necks.

Conclusion

As designers, we prefer design-centric solutions. Design systems can be a wonderful tool, but starting with a Sketch file is putting the cart way before the horse.

There’s a lot of work to do first. The hard stuff, like finding common pain and framing it in ways that will resonate with developers and PMs. And creating a realistic plan that can deliver value incrementally. And selling skeptical engineers on a better, more collaborative vision for the future. Creating beautiful pixels is just one step, and certainly not the first.

And if you’d like to read more about how we’re designing our system at WeWork, my colleague Andrew Couldwell has an in-depth look here.