or the past seven years, I’ve worked on design systems at IBM, Airbnb, and Shopify. I’ve spent hundreds of hours with teams learning about how they use systems. My job, and the job of any good design system, is not to prescribe solutions. It’s to describe relationships between parts of a whole, to connect the dots between things so teams can make the best decisions possible.
What I’ve experienced over and over again is a mindset where teams across domains, brands, or businesses tend to think their products are unique. The truth is they’re far more alike than different.
Like a broken record, my advice is, “You should talk to team A, B, and C. They’re all working on something similar.”
The thing teams all have in common is context. They might share a similar audience, environment, device, or task they design for, but don’t know it.
Why not? Because today, design systems are made of the LEGO pieces we use to build products. These colors, components, and code bring unity to the UI.
Yet, these building blocks are not the full picture of design systems. There’s a world beyond UI kits that’s missing in our documentation today. This world isn’t made up of components. It’s built from the context of our users’ worlds.
Showing teams the context behind their design decisions in the system enables them to apply the system in a way that best meets their users’ needs. It also saves teams from my mediocre matchmaking services where I tell them who they should collaborate with.
A world without context
A few years ago, I opened a UI kit at Airbnb to discover some components with a dark teal gradient applied while others had none. When I asked the Design System team when I should use gradients, they told me, “They’re for special moments.”
But a special moment for whom? I asked for examples, only to find out the decision had been made years back. The use case for a special moment wasn’t written down, and nobody ever asked why gradients existed. Gavin Owens, our design technologist, called this case of missing context, institutional amnesia.
Institutional amnesia happens when an organization forgets what it has learned. It occurs when people don’t reflect on their work, don’t document it, and don’t stay at the company for very long. It’s a dangerous pitfall when the direction set by a few individuals is being upheld by everyone, but nobody knows how it got there.
Once a set of components becomes standardized in the system, teams tend to unconsciously assume the decisions behind them are valid and continue to use them, rather than question if they still meet the need.
In a world without context, teams can’t learn how to best apply the system to their specific use case. They lose their confidence to make good decisions, which slows them down. They end up scaling risky gut calls across the organization because there’s no way to understand why decisions are made, much less challenge them.
Examples of context
In Shopify’s Design System, Polaris, we have a date picker that allows for multi-month mode. This enables users to select two months at a time. During tax season, a business owner downloading documents might need to choose bills for more than two months. Some bills are sent out quarterly. Because the billing team shares context about these tasks in the Polaris Design System, we can make the date picker more flexible for tax-specific use cases.
At Airbnb, we designed everything from a marketing email to a statistics dashboard for expert hosts. We changed our tone of voice based on what we wanted to express to hosts. One tone felt more celebratory, the other more trustworthy. These specific examples demonstrate how systems aren’t one-size-fits-all. They’re meant to be interpreted in each situation so teams can decide what’s most appropriate for users.
Making context visible
How do we bring context into design systems? One approach is to systematize context just as we’ve systematized our products.
At Shopify, we bring context into Polaris using a storytelling method. We write scenarios with teams that help get the context out of their head and documented into the Design System.
To explore what that sounds like, read the scenario created by our Retail team. To gather context, this team visited multiple stores and interviewed retail staff. Their UX guidance in Polaris is influenced by what they learn about how staff runs brick and mortar stores.
Imagine walking into a noisy store with customers standing in long lines. Staff members are quickly moving from checking out customers in a brightly lit storefront to managing inventory in a dimly lit back office. As they go back and forth, the screens on their card readers and tablet displays become hard to read.
This scenario provides deeper empathy for what it’s like working in Retail. Because lighting conditions vary greatly in a store, the Retail team created a high-contrast dark mode in their design system to support staff as they go between environments on multiple devices.
Having learned the context for why the Retail team created a dark mode, our Shipping team is now piloting the same high-contrast dark mode in warehouses where variable lighting is also a big challenge.
In this example, context helped teams leverage each other’s work. They understand why designs are created to support certain use cases, and not others. They use context to diagnose when a design is not working well, which ensures we avoid repeat mistakes. On the system team, context helps us determine if we should extend existing designs to work for a new use case.
In the future, we want to highlight variables in a scenario, the changing context in a users’ world which become design constraints. At Shopify, one variable we’ve identified is split focus.
Local delivery drivers have split focus, where their attention is divided between the road and their phone. Pickers also experience split focus, when their attention is divided between scanning rows of heavy boxes and inputting data into robots that move around the warehouse floor.
These are two very different experiences which both share split focus as a variable we design for across the products we make. Our hypothesis is that teams who share common variables likely have insights or components to leverage from one another.
Context first, system second
Context is critical for teams using design systems. Without it, they either force fit user needs into components that don’t scale or surrender to the technical debt of making everything from scratch. Both of these approaches create more silos than collaboration, and exacerbate institutional amnesia.
The products we design are always influenced by the users’ world where they are situated. By bringing context into design systems first, before building the components which result from it, we enable teams to make more confident decisions and deliver the best outcomes for their users.
Resources
Shopify’s Selling-in-Person Experience
Google’s Design for Driving
IBM’s Universal Experiences
This perspective on systems is created in partnership with many teams at Shopify. In sharing this, I hope to foster more conversations about the role of design systems within teams and organizations. Thank you Josh Cusick, Amy King, Jason Custer, and Mirko Azis for editing, illustrating, and shaping this piece.