Building a local design system
How Polaris for Retail lays the foundation for Shopify’s new POS app
UX manager Ricardo Vazquez and staff product designer Tobias Negele are responsible for building one of the first “local systems” of our Polaris design system, known as Polaris for Retail. We spoke to them about the experience of developing Polaris for Retail, including the recently published selling in person guidelines. The results of their work can be seen in the new Point of Sale app that was released this week. The conversation has been lightly edited for clarity.
You both work on Shopify’s Foundations Retail team. Can you talk a little bit about what that involves?
Ricardo: The Foundations team spans two spectrums. We are an enablement team, in that we provide tools like the Polaris for Retail design system, guidelines, and documentation so that other teams can do their best work. We are also a feature team, focused on shipping features to our merchants. Specifically, we own global features within Retail, such as global search, the smart grid, or notifications — essentially anything that every Retail team will consume, we take ownership of that.
Before we get into the work that you’ve been doing, do you want to talk about Polaris for Admin and how it connects to this project?
Tobias: Polaris was originally Shopify’s design system for the admin (i.e., for managing an online store) and the Retail team is one of many teams that uses this system as a starting point. Since Polaris was initially created for a store management experience, it doesn’t always work for all use cases that we see in retail environments.
We’re helping to evolve Polaris, so it’s no longer one system but many — a system of systems. This means that we can consider local systems of Polaris that are tailored towards specific use cases. This is how we ended up creating Polaris for Retail.
What does that mean in practice? How closely does Polaris for Retail relate to Polaris for Admin?
Ricardo: Initially, Polaris for Admin was designed for different contexts and audiences than we design for. Our users are diverse brick-and-mortar merchants. Some of them own retail stores, some of them participate in pop-ups, and others do both at the same time. These environments are different from what an online merchant uses — they sit at a desk reviewing and monitoring the health of their online store.
A brick-and-mortar merchant is in a constant state of movement, in a perpetually shifting environment. As an example, larger-than-average tap targets not only help merchants (who are usually at arm’s length from a device), but these large targets also help them fulfill local pickups quickly and reliably. Large tap targets also encourage a merchant to maintain eye contact with their customer, as we promote muscle memory throughout the app wherever possible.
Tobias: When you think about working in an e-commerce setting, you’re usually working with your computer or your phone and you’re in an office, or maybe even at home sitting on your couch. That’s just not the case for retail.
In retail environments, we often see merchants who are standing at a counter. They usually use a tablet which is fixed in a stand that is mounted on the counter, and you can’t move the device around other than flipping it towards the customer. When you think about this scenario, a design system for online retail experiences doesn’t translate to physical retail environments. You’re not sitting; you’re at arm’s length away from the device. Everything is further away, everything is harder to read, and everything is harder to identify. It’s hard to interact with the UI because you can’t easily tap on the device that you hold in your hand; you have to reach and aim for things.
As Ricardo said, the environment plays a huge role. We’re oftentimes dealing with very different lighting situations. Some of the stores that we visited are super bright. Others are quite dark, which makes it even harder to identify things that are on the display.
Accessibility also plays a huge role for us. We want to build a product that’s accessible for everyone in all situations. In a physical retail environment, merchants and users are highly distracted, not just by customers coming into the store or by talking to them about products they want to buy, but also by noise, by lighting, by other staff members. These distractions increase a merchant’s cognitive load. When their attention is divided, it makes it challenging to interact with the app.
Ricardo: Another thing that we have explored within our local system is how to change our tone of voice. Our merchants’ livelihoods depend on this app working. They process critical sales through our POS app; if the app goes down they can’t make sales anymore. As a result, the visual tone and the language of Polaris for Retail has a more formal tone, whereas something that you see in your back office software could be more uplifting (with delightful illustrations and microcopy). Through our research, we found out that retail merchants are looking for something that works. In design, the latter presents itself as a pragmatic, no-nonsense system — one that channels feelings of confidence and conviction for those who use it.
Is there also a broader range of users than with Shopify’s store management experience? For example, more staff interacting with the app and customers?
Ricardo: Absolutely. We often talk about there being diversity of location, diversity of setup, and diversity of workforce. For location, we talked about how a merchant can have a pop-up, a single retail store, or a group of stores within a region. That could mean that a merchant can be anyone from a single owner-operator to one that has multiple staff spread across stores.
All these contexts change if you’re in a pop-up. We also have the diversity of setup that Toby mentioned. Sometimes instead of a fixed countertop, merchants take their mobile devices and move around the store. It makes it challenging to design a system that adapts to every use case and every environment. Because of this, our design system is in a constant state of evolution. We continue to improve the design system based on what we hear from our merchants.
Where did you start? How did you begin the process of defining what would need to be different than Polaris for Admin?
Tobias: It all started with research. We started with listening to our merchants.
This app is not brand new. It’s been released for quite some time, iteratively evolving throughout the years. Over time, we would receive feedback from merchants on the app, which gave us a good sense of areas within the app that were not working as expected. They told us about legibility issues, about issues with not being able to identify which items are interactive and which ones are not, among others.
We also received a lot of feedback on the overall visual design of the app being too playful, not being professional enough, as Ricardo mentioned earlier. We used to have tons of illustrations in the app and a lot of iconography. The primary color that we were using was purple, so all of that together kind of added up to a more playful user experience. We took all that feedback, did some more research, and visited merchants in their stores. This all helped to create a foundation for us.
What different forms did that research take?
Ricardo: We primarily spent time at merchant stores. While doing this, we examined their environment while getting a chance to explore some concepts with them and get their feedback. If we couldn’t travel to where they were, we would do a video call, where we would again share the concepts, share the new design language, and get their thoughts.
One thing that we did was not show the design system as a UI kit — “here are some buttons, this is how the text is going to look like,” etc. That would obviously work for us as designers, but a merchant needs to see the system in context. We would always ask them to go through a checkout flow, as it’s the one critical flow a merchant needs to complete fast and reliably. While doing so, we would explore the design system and stretch it within the confines of this one very basic experience. And through that process they were able to see the design system, interact with it, and then offer more meaningful feedback.
Tobias: We also used a tool Shopify calls “merchant frustrations”, which is almost the opposite of user testing. Members of our Support team will get a call from a merchant and log their complaint about the product in a database, which gets sent to us. If we see that there’s a large number of calls about a particular merchant frustration, that issue automatically ranks higher in our priority list. It’s extremely valuable because merchants are being proactive and they’re reaching out to us, sharing ideas, concerns, and requests.
So you took all that research and distilled it into a set of principles. What’s the evolution from applying principles to actually building out Polaris for Retail?
Ricardo: We felt we needed our own set of principles based on the environment that we just discussed, because it’s a different context, audience, and environment. Our three main principles, which extend from Shopify’s experience principles, are that all retail experiences should be fast, reliable, and simple.
Our three main principles are that all retail experiences should be fast, reliable, and simple.
Within a principle such as “fast”, as an example, we have a supporting value of “speed over certainty”. For example, we know that our retail merchants go through a checkout process hundreds of times a day. We wanted that experience, or the experience of adding a customer to your database, to be as fast as possible. When we were working in our design sprints, we were often reminding ourselves of these types of values and principles because it allowed us to tailor the experience towards, in this case, being more effective. It made us think of places where we can do the legwork for them, and maybe we get it right 80% of the time. An example is search. As soon as the merchant taps on the search bar, without them needing to search for anything, we give them a list of the products that they have recently sold, which to us meant, based on the data that we have, that these are the products that a merchant is selling a lot of because they might have some promotion on them, or the products are simply their bestsellers. Why require the merchant to type or barcode search every single time for that product? Using the value of speed over certainty, we were able to defend that design decision, and then of course we will be using data to further inform this decision that we’ve made.
So you took these core functionalities and stress tested them against the principles?
Ricardo: Yes.
What was the process of actually translating those principles into Polaris for Retail?
Tobias: That occurred when we went through a couple of exercises, specifically in design sprints, to design the core flows and features of point of sale. And we mixed those concepts with the feedback that we received from merchants. We then experimented with typography, colors, iconography, even things like emotion, and started exploring different visual treatments for these flows that we’re focusing on in this first round.
For example, we considered the feedback that we received from merchants about things not being legible when you’re at arm’s length away from the device, which means in the design sprints we decided to try to increase font sizes. We tried to increase the weights of fonts to see how far that would get us. We then played around with high contrast colors, and created color palettes for the different states of information that are being displayed on the device. Step by step we went through all the different treatments, patterns, and components that we need for our design system, and started playing around and exploring different approaches.
Sounds very methodical.
Ricardo: You know what? I think hindsight is 20/20. We ended up doing something methodical, but I think back then we just —
Toby: We were not aware of that.
So, to summarize, what are some of the key differences between the Polaris for Retail and the Polaris for Admin systems?
Tobias: From a visual design point of view, we have larger font sizes and font weights are heavier than in Polaris for Admin. We have a color palette that uses higher contrasts and performs great in regards to accessibility. We defined specific guidelines for motion that are aligned with our design principles, especially in regards to speed, which is super important in retail. We created sets of iconography that contribute back into Polaris. We also have a specific style for illustrations that is aligned with what we see in hardware packaging and manuals. This style contributes to the more pragmatic look-and-feel that we’re aiming for in the app.
Ricardo: Spacing systems are increased as well. Merchants, like we mentioned, are at arm’s length. So those tap targets needed to be bigger. In fact, if you take a look at that tablet app and you sit on a couch and you look at it almost feels —
Tobias: Gigantic.
Ricardo: Yeah, It feels like there’s a mistake. But once you stand and put the device on your countertop, the intent behind our choices becomes clear.
It’s a lot harder to design something that doesn’t naturally feel like it should fit. When you’re creating a local system, you always need to ensure that it aligns at the end of the day with the global foundations. Being in constant conversation with the Creative Directions team from Polaris was helpful for us. It gave us both agency and the confidence we needed to be able to innovate beyond what’s in Polaris when we felt we needed to. Having the rationale behind why we needed to diverge from the main system helped us gain momentum. Now we feel very confident about this local system and the value it’s going to bring.
Without research, I don’t think we could have been able to successfully create this design system. We would have been simply living in the land of assumptions.
Tobias: Part of the reason why this whole process felt strange to us was that in the past we’ve always looked at other design systems for inspiration. The Point of Sale app has been built on a combination of the Human Interface Guidelines provided by Apple, on Material Design provided by Google, and Polaris patterns provided by Shopify. We took all of these and mixed them together to create the app we are now calling POS Classic.
Through research, we learned that this was not the right approach, because back then we simply did not consider the specific use case of retail environments.
That almost feels like an internal tension, assessing whether you’ve strayed too far from the Polaris for Admin system. Did you consciously try to find tie-ins back to that system, or was that something that you had to push away and say, “That’s not a constraint that we have?”
Tobias: Something we looked at as an example is Material Design. Google created guidelines that you can rely on depending on the use case that you’re looking at or depending on the environment the user is in. There are specific guidelines for web, guidelines for mobile, but also guidelines for situations where the user is in a car.
So we thought, “Okay, this is interesting. This feels a little bit familiar compared to what we’re trying to do.” The goal you have when you’re driving is to get somewhere and you’re trying to get there safely by paying attention to what’s happening on the road. The device or the app you’re using to get to your destination supports you with that goal and that task. In this situation you’re further away from the display, lighting conditions change, UI becomes harder to interact with, and focusing on what’s happening on your device is not the most important thing.
This is a very similar experience to retail environments when a merchant works with a customer. If making a sale is the destination the merchant wants to get to, then POS is the tool that helps them to get there by supporting them with creating the best experience for their customers.
Ricardo: We’ve also been fortunate enough to be able to contribute back to Polaris, and encourage growth for both systems simultaneously. A great example of this has been our color modes. When we started designing Polaris for Retail, Polaris had only been using a light color mode. As Toby mentioned, the lighting conditions in merchants’ retail stores vary so much that we needed to ensure a proper color mode for contrast and accessibility, which led us to ship the initial release of our app using a dark color mode. As we became more knowledgeable on how to design using dark color modes, we collaborated with the Polaris team on bringing a dark color mode to the main design system.
Are there any lessons that stand out to you about the process of developing your own local system for Polaris?
Ricardo: Always document as you go.
Tobias: Document and share. I remember that we did internal roadshows to communicate what we were doing, why we were doing it, and why it was important.
Ricardo: We knew that the local system was going to be very different. We wanted our teams and stakeholders to hear it from us, to hear the rationale for how it feels to sell in person. We felt it necessary to deliver that narrative so that when it came time for them to see that system at work, and see the system in design prototypes, they would understand the story behind Polaris for Retail. Because we were the first local system at Shopify, we needed, in a way, to pave the way for others in our company to understand the value of a local system. We then worked with the Polaris team to further reinforce the latter, and with their support, we’ve been able to truly begin forming what we envision being a meaningful and purposeful local design system within Shopify for years to come.
