Locating Polaris: How we built a style guide for our design system
Design systems — how they’re documented, shared, and maintained — matter because of what they facilitate and represent. If the system is created to enable real work, it should reflect how an organization makes things and what it values. A design system that doesn’t include anything about principles, or an approach to content, for example, may not prioritize thinking about those things in the practical day-to-day.
In The Writing Life, Annie Dillard says,
“How we spend our days is, of course, how we spend our lives. What we do with this hour, and that one, is what we are doing. A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time … Each day is the same, so you remember the series afterward as a blurred and powerful pattern.”
A similar thing can be said about design systems. How we document our system matters because it reflects how we spend our days. And how we spend our days shapes the nature of the products we build.
As a content strategist, I’ve had lots of exposure to systems that don’t value or understand the role of language in product design. I know what it’s like to be brought in late in a project cycle to fix things that are broken, or to just “make it sound better.” This never really works because content is never an effective bandage to hold together a fundamentally broken experience, and most experiences are fundamentally broken when they don’t consider language early on in the design process. This doesn’t mean that everyone needs a content strategist on their UX team, but it does mean that every UX team needs to care about and know how content works in an interface.
Systems are intentional. They’re designed. They defend from chaos and whim. They’re the scaffolding on which we labor and they determine what we prioritize and how we work together. It’s important that our scaffolding is sturdy enough to support all the different kinds of people and skills that go into making a great product experience—design, research, front-end-development, and content.
Our North Star
Polaris is another name for the North Star, which is one of the brightest stars in the sky if you’re in the Northern Hemisphere. Before technology gave us iPhones and GPS, people used the North Star to navigate to their destination. “Polaris stands almost motionless in the sky, and all the stars … appear to rotate around it. Therefore, it makes an excellent fixed point from which to draw measurements for celestial navigation.” (Wikipedia) Polaris was used as a map of sorts.
Our design system is our fixed point and it helps us orient how we work. The style guide we built is the map of our system—at least the parts we’ve already explored and defined. It includes ideals (our principles) and then translates those ideals into practical tools that help people build better experiences more quickly.
The style guide was built with deep involvement from designers, front-end developers, researchers, illustrators, and other people whose work informs the product experience. Since not every project has the benefit of a team of specialists, our Polaris style guide will increasingly help Shopify employees and our partners build more cohesive, useful experiences.
Integrated UX guidelines
It was important that our style guide reflect the multidisciplinary nature of our process here at Shopify. More than any place I’ve worked before, Shopify understands that we build good experiences for merchants by assembling UX teams that consider the product from a variety of perspectives. We have subject matter experts in design, content, research, and front-end development and we expect them to work in an integrated way.
In our style guide this integrated approach really comes together in how we present components. We could have easily shipped a set of components with technical details and a few visual examples. Doing this would have been easier for our team, especially since we only had 10 weeks to build the style guide from start to finish.
A set of basic components would have allowed designers and developers to copy and paste components into their work, but it wouldn’t have helped them think about the purpose of a button in Shopify, or how to consistently apply the different variations of each component. Clarifying the function of each component and associated UX rationales gives people the information they need to think about and use components thoughtfully. When people understand the logic behind design decisions, they’re positioned to build better experiences for merchants. Including this information was fundamental if we wanted our style guide to be a map of our design system and reflect the way we believe product should be built at Shopify.
“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.” Alfred Korzybski, Science and Sanity
Maps are opinionated. The people who make a map decide what’s included, what isn’t, and how different elements are represented. They form a narrative about what matters to a particular group of people at a specific point in time. The same thing can be said about a style guide.
When we were deciding what to include in our component page template we decided on some benchmarks that define utility and quality. Merchants generally have a better experience when the building blocks of our system are:
- Purposeful: Each component should respond to a merchant need and solve a merchant problem. Contextualizing each component around its utility for merchants and providing a list of UX best practices was an important way of orienting builders to think about the right things when assembling an experience.
- Consistent: When different parts of a system look and function in a predictable way, it helps merchants learn how to work more quickly and helps them confidently complete tasks. Our visual guidelines show how to make interfaces that look and act like Shopify so that merchants feel like they’re using a cohesive system, no matter who built each part.
- Reliable: Our components make it easier for designers and developers to build higher quality experiences for merchants in less time. They’re reliable because they’re tested for speed, responsiveness, accessibility, and cross-platform compatibility.
- Clear: It’s impossible to build a product that’s easy to understand without using thoughtful content. In addition to providing high-level product content guidelines, we included advice at the component level about how language elements should be structured to help merchants make decisions, take actions, and manage their business.
Our component library documents many of the building blocks of our system so that instead of spending valuable time reinventing core elements like a date picker, makers can focus their attention on solving the hard, unique problems in an experience. Our merchants benefit because a system that uses the same functional elements is easier to learn and use.
Our design system and the style guide that maps it will always be a work-in-progress. We’ll never be done evolving our design system because we’ll always be stretching to find ways to build better experiences for merchants. The map will continue to grow and change as we explore additional components, discover new ways of working, and uncover new needs we want to support.
Build something. Share it. Learn. Iterate. Share again. Learn some more. This is our roadmap.
It’s all part of how we’re working together to design useful, thoughtful experiences for humans.
It’s how we spend our days.
