Selling a Design System at Your Company
A brief introduction: I’m Nick Stamas. I created Plasma, WeWork’s design system for our internal tools. You can read more about Plasma here. In the past I worked on Meetup’s ground-up redesign of their new apps and led design at a startup I co-founded.
Maybe you’re like me. Your team always seems to be struggling to ship work you’re proud of under deadlines that always feel too tight.
You’re a good designer. You work with good product managers and engineers. But something is missing. You can feel it, deep down in your bones; there’s a better way to build product. And as a designer, you’ve naturally arrived at a design-centric solution: you need a design system! Maybe you envision something sexy like this:
Unfortunately, no one cares about your precious design system. They don’t get it. How will it help? What’s the value? Won’t it take too long? Won’t it quickly go stale? Aren’t those for more mature teams? Isn’t your job just to make things look pretty?
Maybe you’re tempted to go rogue. But we’ve seen that movie before: a designer gets inspired one caffeine-fueled weekend and comes back Monday morning with a Sketch file full of pixel-perfect buttons and text inputs, a double-stranded perfect-fifth typography scale, and a color palette with seven, irreproachable shades of gray. It will look lovely in your portfolio. But it’s unlikely to make an impact, wasting away in that great big Dropbox folder in the sky.
You feel stuck. What can you do?
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.
Thank you to Deena Edwards, Jesse Lamb, Andrew Couldwell and Stephanie Stamas for feedback on the post.
Fun fact: Our main internal product is called Spacestation, and we have a bit of a space theme going on. Because it’s about managing space…get it? Plasma is derived from Greek, meaning “anything formed” and is one of the four fundamental states of matter. Also, Plasma propulsion engines are a thing. They’re best suited for powering long-distance interplanetary space travel missions.
If you found this interesting, please hit the ♥ button below, and share it :)
