The system always kicks back
The effort required to build a design system is tiny compared to the effort required to maintain it.
I work at Shopify, and last year we launched Polaris, our product design system. Polaris was a major step forward. Before it existed, we looked like a company that had 300 UXers working on a single product. But Shopify wasn’t internally consistent. And it definitely wasn’t externally consistent.
Everything we’ve launched since June 6th, 2017 uses Polaris. Our teams are all bought in. PM and Engineering understand its value. We also heard from a lot of other UXers that they liked it too. By all quantitative measures, it’s an internal and external success. But this is not an article about success. It’s about surprises and hardships.
And our biggest surprise is that we didn’t plan for the cost of our success. We poured so much energy and thought into how to get our system adopted, how to incentivize its usage, and how to make it great that we didn’t think about how our “system” would operate after we launched.
It turns out that all systems have a life of their own.
Part 1: Before Polaris
When I joined Shopify three years ago, we had a design system — two designers who were in charge of a UI kit and a component library built by a pool of developers. We even had a style guide to help you use those tools. Everything was set up the way the Smart People on the Internet® tell you to set it up. And it worked, kinda.
Designers all used the UI kit — even if they all had their own modified versions of it. Our developers really liked the UI components we had built — even if they always had to change them for every new project. Our style guide was a source of truth — but every component in the UI kit looked a bit different.
That’s a lot of caveats. But our approach worked because it solved a tooling problem for our relatively small team. We needed a consistent way to work, and we wanted to democratize contribution.
But when we went to fix our design system, we ended by scrapping it instead.
We moved the two designers and six developers responsible for our old design system to other projects. We broke the UI kit into pieces and stuck it on GitHub.
I did not expect what happened next.
Over the next six months, the quality of our projects increased. As did contributions to the system. By removing specific owners, we distributed ownership to the entire UX team. Consistency of output became the responsibility of the leads reviewing the work. They began acting as air traffic controllers — seeing similarities in projects and organizing who was working on what together.
The tools are not the system
Our design system isn’t our UI kit or our style guide. It’s the shared language we have when we talk about our work. By placing less emphasis on the tools and how people interacted with them, we forced individuals to think more carefully about how their decisions interrelate and what it means to “feel like Shopify.”
I like to use the literal example of languages to describing this. A language is something we use to communicate with each other. But it’s not rigid. It’s not our records of those words — the dictionaries — that matter. It’s the meaning behind those words. That’s why our languages are constantly evolving — and our shared understanding of the language is what keeps us together.
When it comes to systems, our tools are like dictionaries. They should be representative, but they don’t arbitrate. Systems people need to be observers and ethnographers, not enforcers.
Part 2: Building Polaris
If the knowledge of our system could be decentralized for each of our products, it could also be shared. Instead of assessing each of our products individually, we took a combined look. And when we did, the problems were obvious.
We knew we had this problem already, but local issues took precedence over global issues. Now we were ready to make all of Shopify a consistent experience for our users. We also had a new approach: spend more time on education, observation, and improving the global system like type and space. And less time on the tools.
We re-assembled a small systems team made up of content strategists, designers, and front-end developers. Their explicit purpose: to create an understanding between all of our product teams on how to build something that was consistent across all of our users’ touch points. Our end goal was to be able to look at all of our products and feel like they were following the same design principles and language.
This was the genesis of Polaris. We reached out to every team in the company and shared our rationale for why we should be designing in unison. And, luckily for us, they bought in.
We set a deadline of three months to align all of our products and write the documentation that lives on Polaris today. And, remember, this is not a small team — we’re talking about around 225 UXers at this point across some major products.
We were able to do this in such a short time frame because we used a peer-to-peer network to educate the team on our shared system. We made it a large part of our leads’ role to help the individuals on their teams see the connections between their work and others.
And, we did it. Polaris launched just over a year ago — and we’re very happy with it. But there have been problems.
Part 3: Garbage compactors and quality elevators
We had two major goals with Polaris:
- Raise the baseline quality of all of our projects
- Create a consistent experience for our merchants
By providing a system with clear steps for how to make great Shopify experiences, we thought we would be removing tedious decisions from our UXers lives so they could focus on the more important things.
That’s not exactly what happened.
Sure, the baseline quality definitely increased. And, as a secondary effect, our teams efficiency did too. They were able to make better decisions quicker. But it felt like our teams creativity was decreasing in equal measure.
A quality garbage compactor
There’s a rule in natural systems that’s known as Le Chatelier’s Principle. It states that systems will always try to achieve a state of equilibrium. When we built Polaris, we imagined that we would be raising the quality floor. In other words, it would be easy to improve the general level of our work. We also imagined that by raising the floor, the quality ceiling would also raise. But now we know better. Thanks to Le Chatelier’s principle, our system tried to achieve equilibrium.
By exerting pressure on the teams to follow our guides and use the system, we created an equal pressure to avoid novel solutions or out-of-the-box thinking. We’d still see good designs that didn’t use the system because it wasn’t working for them — and the system would grow to include those things. But there were far fewer moon shots.
We don’t want to play it too safe as a UX team. The system has to change in drastic ways for it to keep getting better. But I’m scared that won’t happen because we poured so much energy into the idea of consistency. As one of my coworkers said to me after I shared my plans for Shopify’s experience this year, “You spent so much time talking about making things the same, I didn’t realize you were interested in changing things.”
Whoops.
Quality elevator
What we really wanted to create was a quality elevator. A floor that constantly rises and a ceiling that’s constantly rises with it. It elevates the entire UX team’s ability to do amazing work.
To do that, we started a concept car team. This is a small team whose sole job is to create novel concepts for our experience. These concepts are never meant to go live, but instead serve as inspiration for other teams. Half of their work is exploratory concepts, the other half is embedding with other teams to help them generate their own concept cars.
We’ve also worked with all of our UX leads and product managers so they understand the value of building concept cars for their products. A siloed team will never be able to come up with the right designs for areas that need deep domain knowledge. But they can help those teams get better at experimenting.
Part 4: Systems are a black hole
Now that Polaris has had some time to mature, our team has as well. We have developers working on components, architecture, and features. We have designers working on large- and small-screen web and native mobile. We have content strategists and researchers. We also have full engineering and product support. Our system has seen a huge investment from the company. And we’re really lucky. But luck isn’t enough.
Systems appear more complete than they are
Our first release of Polaris was held together with spit and tape. Things looked a lot more mature than they were — and you can’t blame us, we literally built it in 3 months. We knew there was a lot wrong with it and we had big ongoing plans for how to improve it.
But to other people in the company, it looked finished. At the same time the Polaris team was stretching like crazy to support the company’s needs, additional pressure was lowered onto the team’s shoulders.
We started seeing decisions get made at an organizational level about alignment that used Polaris as a factor. “Since we have Polaris, we don’t need to worry about UX alignment anymore,” they said. And, jeez, that might be partially true but we did not feel ready for it.
Systems attract systems people
Another problem with our expansion was the people on the team. As it grows, your systems team will attract more systems thinkers, which probably sounds like a good thing.
The problem is your systems team will attract all of the systems thinkers at your company — and hopefully outside of it too. People who love your system will want to work directly on it.
The reality is that you need them everywhere but the system.
It’s important to have people with a product mindset working on the system and people with a system mindset working on the product. The problem with a team full of systems thinkers is that they tend to have the same two problems.
- Systems people put too much trust in the system
- Systems people think way too long term
If your team is full of people who only see the glory of the system, it is way harder to make the right decisions about how it will need to change. What you’d rather have is people that experience and can think about the system from both sides — the long term impact and the short term needs. By mixing all of your teams with product thinkers and systems thinkers, you’ll create the right mindset.
Part 5: Progress and paradox
We decided early on that we wanted Polaris to work exactly like Shopify — continuous improvements, no major releases, just a lot of small work adding up over time. We broke that rule a bit with the first big drop but it was needed to do the full switchover.
What I’ve learned since is that constant progress does not feel like progress to anyone outside of the system. Even if you’re communicating regularly — and we do, we send monthly newsletters, attend product show and tells — other people have more important things to pay attention to.
This isn’t all that bad. The system is still healthy. But adoption of new components or new ideas will be scattershot unless you have a high-bandwidth way to announce them to everyone.
I now believe that big named releases, with a lot of fanfare, are the right way to encourage this. That doesn’t mean stop doing continuous improvements, but pick a cycle and roll up the work you’ve done to that point into a nice big named release. Design a bunch of posters. Put a video together. Do something exciting enough that people will want to dig into it.
If it’s worth doing, it’s worth doing poorly
You’ve heard the other version of this rule: obviously if something is worth doing, we should do it well, right? No, when it comes to this, that’s very wrong. The concept of doing something well is paralyzing. Especially for systems teams.
Our most productive 3 months were the ones with an impossible deadline. The best thing you can do for your system is put imperfect things inside it. Release and test constantly. Get over the idea that everyone is relying on you to be perfect. And encourage contribution by enabling those with less time to feel like they’re just as capable and confident. Start by shipping something good — then make it great.
The system doesn’t work for you. It works for itself.
Your system will take on a life of its own. The weird thing about this is that it takes more people to keep your system alive than it did to build it in the first place. Once your system is up and running, the people on the team will spend more time on system maintenance than they will on improvements.
The Polaris team has definitely grown. We’ve added people. We’re way better than we were. But sometimes it can feel like we get less done. I think there are two reasons for that. One, we spend a lot of time on advocacy and support for other teams. This is a good thing.
The second reason is that we introduced too much structure too quickly. We overthink preventing future maintenance. We tried to limit things to protect ourselves from future failures. This is a bad thing. Your team and your system need the time to evolve on its own. You can’t plan it too far ahead of time. Fail first — then figure out how you can prevent it from happening again.
Part 6: Maybe you don’t need a design system after all
When I talk to a lot of small teams, they’re surprised when I tell them they probably don’t need a design system. Systems are formal implementations of practices and beliefs that your team already holds. They help you spread these beliefs and practices and get everyone bought in on them. But they come at a cost.
When you’re small, you actually don’t need them. If you’re a few designers sitting in the same room, you can get this for free. And you can avoid the rigidity that comes from them. That’s not to say you shouldn’t have a UI kit or a component library. But a whole formal system? Nah.
Do it with a small system if you can
If you still really want a design system, do me a favour and keep it small and organic. Focus it as much as possible on involving people and generating conversation. A small system shouldn’t be about limiting what’s possible. It should be about making more things possible through it. Unlock the quality ceiling for your team.
Design your system to change itself
If you find you do need something the size of Polaris (and, remember, we made do until we were about 150 UXers) then I hope you can use the lessons above. Design it in a way that it constantly feeds back on itself to change in positive ways. Make sure your short term goals don’t counteract your long term ones. Don’t create something that eats itself. And, most of all, build something that enables your designers to create better things faster and doesn’t just police the great designers you already have.
What do I know?
One of the things I love about this industry is how many of us are in it together — that we can share stories like this and progress of each other’s work. And that’s why I wanted to talk about the difficulties we’ve faced and some of the ways we’ve been working on it. So this is my experience — and these are the struggles I’ve faced. Let’s get together and talk about your experience and the struggles you’re facing. DM me on Twitter, send me an email (firstname.lastname@shopify.com), or message me on the design systems slack. Say hi!
This article is based on a talk I gave at the fantastic meetup series Rethink in February. You can watch it here. The framing of this article is borrowed from the excellent book, The Systems Bible by John Gall.
Shopify, and the Polaris team, are hiring. We’re currently looking for a UX leader to help solve these problems. We’re also looking for a developer lead to push our UI development further. Reach out if you’re interested!
Finally, big thanks to Ryan Bigge, Nick Looijmans, and Yang Chen for the editing and emotional support.
