Tracking Polaris
Two years after its launch, the team is ready to chart a new course
When Shopify publicly released its design system, Polaris, the goal was to document and align the company’s user experiences. Fast forward to today and the system has grown a lot. It now accepts third-party contributions and has added a growing set of patterns and guides. It’s used by developers to integrate their apps seamlessly with Shopify and it has influenced how other designs systems are built.
To celebrate the system’s two-year anniversary, I sat down with a half-dozen members of the Polaris team to talk about what they’ve learned and what’s next for the design system.
Lesson #1: A flock needs some shepherds
When Ryan Frederick joined the Polaris team as a designer two years ago, he thought about his job very differently.
“I was imagining it was going to be about defining new things and improving the patterns that existed in the product. But I quickly realized that there’s a balancing act between standardizing and documenting what already exists versus inventing new things.”
It’s part of why a full-time team was created to work on the system from the beginning. A big part of their time is spent shepherding the work being done by product teams into guidelines or components that can be contributed back to the design system. While the team does work on designing new things to fill gaps in the system (more on that later), it’s just as often working to amplify the work being done by product teams to benefit the whole organization.
You need a system to connect people with the system
To facilitate this process, the Polaris team has several ways for people to engage with the system beyond the publicly available style guide. Every day, a different member of the team serves as the Polaris ATC (or “Air Traffic Controller”), answering questions on internal Slack channels and monitoring GitHub repositories for incoming issues. These can be anything from implementation questions or bugs to triage, to addressing and cataloguing feature requests.
They also consciously work on building connections with people, to make it as easy as possible for the UX team to work directly with someone from Polaris. For quick questions that are best solved with a conversation, there are weekly office hours where people pose a question in advance and have it answered by the appropriate expert from Polaris. For more involved problems, people can book a 75-minute workshop to collaborate with members of the Polaris team on a problem. People book time to explore improvements to a Polaris pattern or component, or get help building an interactive prototype.
For developers, there are weekly, hour-long pair-programming sessions available, where people can partner with one of Polaris’ UX or web developers. People sign up for help with anything from bug fixes to just getting a second set of eyes on a new feature someone is building using the system. Just maintaining the system is an ongoing process that requires contributions — updating the implementation of React components and keeping component libraries up-to-date.
If all of this sounds very time consuming, it’s because it is. For Ryan, this has changed not only how he’s thought about what a design system does, but what it is:
“It’s at least as much about providing a service, as about building a product.”
For Selene Hinkley, a senior content strategist who’s been part of the Polaris team since the beginning, these community engagement mechanisms are an essential part of an effective system.
“You need to take maintenance and community management as seriously as building components and creating documentation,” says Selene. “If people don’t trust your system, if people don’t feel safe to ask you questions, they’re not going to engage with the system and use it. And then they’re going to create their own solution, which defeats the whole purpose.”
As UX director Kyle Peatt said in his post The System Always Kicks Back, “it turns out that all systems have a life of their own.”
Lesson #2: People will accept what you say, even when they shouldn’t
When Polaris launched in 2017, it was a snapshot in time — the team extracted a design system from the patterns that already existed in Shopify’s admin, the main product used by Shopify business owners.
“The system grew out of backwards documenting the Shopify admin. Essentially let’s take all of our buttons, cards, navigation, and everything else and let’s extract those into a library,” says Tim Layton, a Staff UX developer on Polaris.
The team gave itself just 10 weeks to build a style guide. It would function as a map of what had already been explored and defined, aligning different experiences by documenting them. The goal was to build cohesion and give teams a way to orient themselves in their work.
But the team knew that the initial iteration of the system was always meant to be just that — a beginning. With a strong foundation in place, the system could scale and evolve to meet the needs of different product areas, and those new patterns and components could be fed back into the system. To facilitate this growth, the Polaris team created a set of principles that product teams could follow as they developed solutions for their own specific problems. Embedded in those guidelines was Shopify’s multidisciplinary approach to crafting experiences, a forcing function to help teams consider the product from a variety of perspectives.
They also created a set of contribution guidelines and spread the message that ownership of the system was shared by everyone in UX. People today are encouraged to contribute bug fixes or new components for the Polaris UI Kit through the team’s GitHub repository (and those contributions get public thanks in newsletters and Slack channels). The entire system is open-source and contributions from people outside of Shopify (such as developers who build apps for Shopify businesses) are welcome. Issues are reviewed by members of the Polaris team and, once approved, can be merged directly into the system by the person who made the contribution. A similar process exists for contributing content standards to the system, so that the entire content strategy team at Shopify has a hand in evolving the system.
And the system has evolved. People from the UX team have contributed everything from new guidelines on designing onboarding flows to accessibility recommendations to a guide to designing apps for Shopify. Meanwhile, the Polaris team has focused on documentation and components that have system-wide implications, such as list filters (in development), error messages, and icons. (A full list of updates to the system is available on the team’s What’s New page.)
Barriers to involvement are often invisible
But guidelines and encouragement are often not enough to get people involved. One of the key challenges has been helping the broader UX team — well over 300 people — understand how to use Polaris. Because it introduces a more systematic approach to design, many people use Polaris to move more quickly, confident in the knowledge that their solution will be aligned to Shopify’s design principles. Jesse Bennett-Chamberlain, Shopify’s Principal Designer, believes this has led some people to be reluctant to challenge the assumptions of the system.
“The intent was to have people push on the system and make it better. We wanted it to continuously evolve and raise the quality of everything we did,” says Jesse.
“But we found that in some cases folks just thought ‘Oh, this is documented, so it must be the best solution.’”
This has led to some strange conversations for him.
“At one point I had a conversation about the color of the couches that we were ordering for a new office and what tone of purple they should be,” he remembers. “And I was thinking ‘Oh crap, that was not my intention when I created a purple button!’ But when you don’t clearly define the edges of the system, and what the purpose of it is, it makes some decision-making really fuzzy and unclear.”
While the Polaris team has focused on making sure the process for adding to the system is well-documented, this has not lead to product teams adding components to the UI library as often as expected. While product teams quickly signed on to becoming a consumer of the system, it can still be a challenge for them to have the time or confidence to make contributions.
“Right now, the people who do contribute to the system are those who are uniquely passionate about it, with a high level of confidence,” says Selene. “So it’s like you already have to be confident in your abilities in order to contribute. And that’s not ideal.”
One of the ways that the team is thinking of reducing the time investment to contribute to Polaris is by introducing more building blocks that make the system more flexible for unimagined use cases. According to Yesenia Perez-Cruz, a senior UX manager on the team, introducing more modularity to the system will make it easier for individual components to be combined in new ways.
“Making the components more composable means that you can take two components and put them together to make one, without having to fork that component,” says Yesenia. “I think that also will lead to people not feeling like they need to go rogue in order to create something specific. For instance, a lot of teams have forked the resource list component, just to put headers on it. And in some cases, a team needs that component with the headers, but they’re working on a really tight deadline. And so they have to ship the Polaris version without the header because the one with the header, while already in the admin, hasn’t been pulled back into the system.”
Lesson #3: Real change is hard, but possible
If evolving the system has its challenges, introducing meaningful changes that raise the quality bar can be even harder.
“We’ve been able to spend most of our time on the support side,” says Kyle. “And we’ve spent some time evolving the system, but change has been really difficult to make time for.”
One of the things Polaris has achieved is to raise the “quality floor” (or baseline quality) of the UX team’s output, as well as the efficiency of those teams. But raising the floor has not automatically led to a rise in the “quality ceiling”. As Kyle notes in The System Always Kicks Back,
“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 saw far fewer moon shots.”
So in response the team decided to aim for a “quality elevator” — a system where the floor and ceiling rise together. They started a “concept car” group whose sole job was to create novel concepts that would be an inspiration for product teams. The group split its time between exploratory concepts and embedding with product teams to generate their own novel designs.
The team worked on concepts ranging from improving specific features and introducing new page editing mechanisms, all the way up to a concept for a wholly new version of Shopify. But challenges became clear pretty quickly.
“The concept cars thing didn’t work as a dedicated team,” says Kyle. “I’m not sure that it couldn’t. But it didn’t work because there weren’t good enough tie-ins to outcomes. So it was hard for the team to know when they were done. And it was hard for them to then sell that thing to teams.”
After going back to the drawing board, a second iteration of the idea has generated better results.
“We started doing concept weeks, where we bring in people for a week that have the context on an area. So for a project on merchandising, let’s say, we could bring in some new designers, and then the merchandising designer, and someone who represents a different idea, like, the online store editor designer. We come together for a week, along with some developers, and in a week we build a functioning prototype of our idea,” explains Kyle. “We’ve done that twice now, and they have turned into real projects. Because we had that functioning prototype, it became really easy to shop that around and say `Hey, here’s this thing and here’s why it’s useful.’”
Another activity that the whole Polaris team has become involved in is known as “Frideations”, borrowed from a process used by Shopify’s AR/VR team. Run bi-weekly, it’s a 5-hour session that tackles a project of interest to the team by coming up with novel concepts and developing strong arguments for why they should be pursued. Topics have included mapping the Polaris ecosystem, evolving Shopify’s iconography, and how to expose experimental features in the product.
“So far, it’s been really good,” says Kyle. “It’s been interesting to see the ideas that have come out of that.”
Up next: Evolving from north star to a constellation
As Polaris has become more influential inside Shopify, the team has started to understand its limitations. Two years ago, the goal of the system had been to bring cohesion to the Shopify admin. But two years is a long time at Shopify — the UX team has grown more than 50% since then — and the system now serves a much more diverse set of products. People who run their business on Shopify may now also use Shopify’s Retail hardware, install apps built by Shopify and third parties, or attend a Shopify-hosted event. The teams behind these experiences kept bumping against limitations of an admin-focused system. Their response had been to spin up their own systems or guidelines to suit their more specific contexts. For example, the marketing team has a collection of marketing assets that are documented in an internal style guide, including their own guidelines on logo use, voice and tone, and writing for brochure site audiences. The Polaris team discovered through internal interviews that marketing teams will use whatever components or guidelines help them solve a problem, meaning that some experiences use a combination of marketing, product, and custom components.
After weeks of internal debate, the solution the team arrived at was not to enforce the current Polaris standards across different environments more forcefully, but to rethink how the system itself should work. A consensus quickly formed around a new approach: to make Polaris a family of UX systems for all of Shopify.
“The big challenge is to go from a design system for one product, across a couple of platforms, to many products, many different kinds of experiences, across a much wider range of stuff,” says Ryan.
“We have to do it by taking what’s worked for a bunch of other products and teams and bring it under the same umbrella. So those satellite systems are part of one design system and can start to influence each other and start to become more cohesive in that way,” adds Ryan.
This expanded Polaris will include the core unifying elements of crafting a Shopify experience (a design language, experience guidelines, and product principles), but also unique systems for different audiences, environments, and products. The systems will be linked by core elements that appear in all systems, while still being able to accommodate the specific needs of individual experiences.
“We’re trying to broaden Polaris to make it more flexible, but still opinionated,” explains Yesenia. “The color palette is a really good example of this. It was designed to be used in the admin in a very specific environment. And we found that if teams are creating something in a retail context, under bright lighting, they need a reverse-out palette, but also, that’s not going to be the only use case where a team needs a dark palette.”
Transforming the system will not be an overnight process, given the day-to-day nurturing and maintenance of the system that still needs to continue. The first step will be mapping out the entire Polaris ecosystem as it currently exists and how the elements are connected (or not). This will inform the creation of the information architecture for a new, unified system. But before that system can be built, a strategy for how this family of systems will be maintained and governed needs to created and shared.
“I think that we can add more hierarchy and focus on some smaller building blocks, so that people can create new things more easily. Things like grid and layout, more foundational elements that people can have more creativity and flexibility with,” says Yesenia. “So a lot of what will make this a reality is being able to create those foundational pieces. It’s like trying to slide the foundation under a house. So if we say, okay, we’re going to create a grid, and we’re going to try it out on the admin first, the admin has already been filled with certain layouts. So you’re kind of reverse engineering.
“I really think that hierarchy is very important to make a system that can scale. And I think that that will be a big part of people feeling like they can take bigger risks or create new things.”
While the number of audiences Polaris serves is expanding, the purpose of the system is still to unify sometimes disparate experiences. If anything, expanding its scope will only amplify its importance.
“The more complex an organization gets, the more we need to lean on a system to enable competent, cohesive decisions,” explains Jesse.
The key will be helping teams build experiences that are appropriate for their audience. Consistency, for example, may be applied differently depending on the needs and expectations of a particular audience.
“So for a business owner, whether they’re experiencing something in a retail context, or there’s an app on a desktop computer, it should feel like it’s coming from one place,” says Yesenia. “But for a more niche audience, or for someone buying a product, they might not need the same level of consistency as a business owner might, across all the different touch points.”
If successful, this family-of-systems approach will not only broaden how Polaris can be applied, but help teams think more deeply about the unique requirements of different experiences. That may start very close to home for the Polaris team.
“The website for Polaris doesn’t actually use Polaris. And for a long time, that was considered to be really weird,” says Jesse. “And the response was ‘It was designed for a product experience, not a documentation experience.’ I think now we should be looking at what does Polaris for documentation look like? We have some opinions and ideas around long-form documentation. Let’s document those things and create a section for Polaris for documentation. And maybe in the future our site consumes that subsystem as its primary way of expressing itself. So I think having a clear understanding of what the purpose is for each of these things is going to make our experiences monumentally better.”
You can see all of our guides, resources, and components at polaris.shopify.com.
