Unity, Not Uniformity With Design Systems

Hayley Hughes at UXDX Community: Netherlands. Video: https://www.youtube.com/watch?v=vkHLFUvXpqY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Unity, not uniformity

[00:00:03] Thank you so much to the organizers of UXDX for hosting this wonderful event. I'm really grateful to everyone attending, and excited to have this conversation about design systems. To tell you a little bit about myself, I currently work on the Polaris design system at Shopify, and prior to Shopify I worked on design language systems at Airbnb and IBM. I'm going to talk today about why it's important to create unity, not uniformity, with design systems, and how I've tried to live up to that mantra at every place that I've worked.

[00:00:38] Donella Meadows, author of Thinking in Systems, once said, "We thought that we could control systems. We found out we can't, but we can dance with them." No matter how many boxes you try to draw around them, design systems always seem to do their own thing.

IBM: a design language built on brand philosophy

[00:00:57] At IBM I was asked to create a design language that would unify a portfolio of 3,000 software products. Surprisingly, we took an approach that didn't involve building a component library. IBM had tried that before, and while it certainly created a lot of consistency, the product and brand expression left a lot to be desired. This set of plug-and-play widgets produced products with a uniform look and feel, where everything was exactly the same as everything else, yet things were cluttered and busy and difficult for people to use.

[00:01:38] Back in the 1970s, when IBM's first design program was put in place, design director Eliot Noyes described a subtle nuance between unity and uniformity. He said that unity is a family of ideas with a distinctive character that's all held together by excellence. On the other hand, uniformity is about following a consistent style, like being in a military branch. This design language approach is one that we wanted to avoid. Consistency in the absence of good design can lead to consistently undesirable outcomes.

[00:02:19] Instead of coding components, I was asked to study the brand legacy of a hundred-year-old company, including the designs of Paul Rand and Charles and Ray Eames. Like an ethnographer, I dug through the archives and traveled across the world searching for bits of design DNA, the grammar of what would become our design language. One book that I ran across gave specific principles, success criteria for what IBM should look like, what it should sound like, and how IBM should think and perform, guiding the experience around a set of principles and recommendations without being prescriptive. The only hard rule that I found was no clip art.

[00:03:08] In Germany I visited an office that had a museum of IBM machines. We captured footage of old typewriters and magnetic tape reels and used that as inspiration for our animation guidelines. The speed and accuracy of the machines aligned with the sense of efficiency and effectiveness that we wanted to provide in our users' worlds. We also found posters and punch cards and all sorts of things that had big and small datasets, which could be translated into how our users wanted to zoom in and zoom out of all these different data visualizations in their software tools, creating a foundation built on the rationale of an aesthetic of the brand.

[00:03:53] It's kind of like designing a game of soccer. We were making this field of colors, type and icons, and inviting teams to come and play with them. Their job was to combine the brand values, the concept and the design elements that we were providing into hundreds of different ways that best fit their users' needs. Because we didn't build a component library, teams would make their own using the design language, for all different experiences and contexts, from the past and the designs they were making for the future. They created what we called design guides back in 2015, which served as a context-specific place for patterns and principles across the different experiences that teams were designing for. Today at Shopify we're calling these local design systems, which I'll talk about a bit later.

[00:04:50] As IBM invested in design and their designer population grew to the thousands, we worked with newly assembled brand and content teams to evolve the design language. We built a brand philosophy around the values of partnership, progress, serving society, and most importantly the relationships between people and machines. The team created an open-source typeface called IBM Plex in many global languages, and the architectural details of the typeface were used to influence the look and feel of the iconography. Each icon had a set of key shapes with hard and soft edges that could be applied across different metaphors, which created a sort of visual grammar that could keep the icon set harmonious.

[00:05:39] The machine motion was boiled down to productive and expressive easing curves that helped us be more opinionated about how we move. And the iconic IBM blue became our primary action color in our products, making it obvious that it was there to guide you through your work. The end-to-end experience meant that no matter how anyone interfaced with IBM, at an event, on a screen or with an IBM employee, there was a set of values in place to move people thoughtfully forward.

[00:06:13] With my first design language at IBM, designing a system for 3,000 software products felt more like a rodeo than a dance. Telling stories and giving the rationale that inspired the why behind the things we were making was the key to unlocking flexibility and creativity while enabling teams to stay on beat with systems. Yesenia Perez-Cruz, a senior UX lead on Polaris at Shopify, nicely sums up in her book Expressive Design Systems what my time building concepts at IBM was all about. She says: codify what it means to create a product that feels like your company. What decisions would your company make that other companies wouldn't? At IBM I learned that your design system is only as strong as your brand philosophy.

Airbnb: relationships with the teams who use it

[00:07:07] On to lesson number two and company number two. When I joined Airbnb, they had already built a design language system. The team had redesigned the product and out of that they built the system, but trying to build both certainly came with a lot of challenges. The design language system was design templates, a coded library and some tooling. As a new hire you would get a one-hour onboarding and then be sent on your way. If you got stuck, there were weekly office hours for questions and answers, and that was the extent of design system support at Airbnb for almost two years.

[00:07:51] The core team who had designed and built the system knew the guidelines like the back of their hand, but they never wrote them down. So as more teams tried to use it, people started asking questions. People like me: as a new hire to the team, I asked, "When should I use expedience [?]?" and someone would say, "For special moments." To this day I'm still not sure what qualifies as a special moment, and making me guess didn't help me work faster or easier. So out of my own struggle came a refrain for our team's mission, focused not on the product but on the people. How could we operate as system stewards who built trust with the community that is trying to use our work?

[00:08:39] To understand the team's perceptions of the design language system, we asked them to write love letters and breakup letters to it, as if it was a person. We wanted to understand their relationship with the system. Some of the letters read, "DLS, I love you, you make my life so easy, but sometimes adding new components or modifying existing ones is so hard." And, "Dear DLS, I love you, but I need to take a break, because there isn't a clear way to collaborate on changes or make any updates."

[00:09:17] One of the first things that we built to solve those types of problems was the contribution model and a partnership program to hack the system. In the two years prior, designers didn't really have a network of people or a place where they could share local systems knowledge. Nominated by their managers, the designers raised their hands to work on improving the system, and they were given time to co-design new patterns and theming and pretty much whatever else they could dream up. It was not about constraints but innovation. Designers in our program surveyed said that showing up to our partnership program was the best thing about the design system since it had been created.

[00:09:58] As people started to contribute all of these components back to the system, we made shared ownership of the design language part of the career framework at Airbnb. As part of organizational development, teams and individuals were incentivized and rewarded for participating in systems work, not just product work. Having worked on a second design system at Airbnb, the value of unity, not uniformity, unfolded a little bit differently. The goal this time had been to unify the community and then use that to drive contribution and sharing, and you can read more about this program on Airbnb's blog. The contribution model had over a dozen teams contributing to it a few months into the pilot, and it was essential for creating resiliency instead of rigid ways of working. At Airbnb I learned that your design system is only as strong as your relationships with the teams who use it.

Shopify: local design systems

[00:10:59] Nine months ago I joined Shopify to work on the Polaris design system. In 2017 our design system was created to support Shopify's core admin. Its purpose was to create shared understanding across teams and a consistent experience across all of our users' touchpoints. There was a lot of early success with Polaris. Products definitely felt more cohesive, which built trust with our merchants. But there was a new problem: teams felt like the system was limiting their creativity.

[00:11:32] They're designing for a wide range of environments and audiences, making products that serve merchants, partners and store staff. Shopify products live everywhere, from people's homes to brick-and-mortar buildings to warehouses, and we're serving all different kinds of use cases. The tech spectrum also includes mobile, desktop, hardware, virtual reality and even assistive robots. Components in the current system aren't flexible enough to fit all of these different situations, so as a result, teams built systems to fill the gap. Teams are designing for very different experiences, like an in-store selling experience, a store management experience or a conversational experience, and they need a place to document their work.

[00:12:20] As I mentioned earlier in the talk, they're creating what we call local design systems. Local systems enable teams to build intentionally off global foundations, the things I mentioned around type, icons and colors for the smallest elements, while still differentiating on their own experiences. They're structured around the steps of a user's journey. They're definitely not organized by product lines in an org chart. Local systems house things like the principles, the design and the code that are crafted for unique scenarios, and teams are making components and patterns to address needs which the foundations alone can't solve.

[00:13:03] They're often needed to design for experiences that share types of context. A shared audience: the people who use and experience your product. Perhaps it's a person who is picking or packing shipped goods, or a buyer checking in on their delivery. A shared environment: the setting or conditions in the user's world, where they might be facing a range of different distractions, like robot machines or forklifts making really loud noises. Shared tasks: the work to be done, where someone might be extending their arm a hundred times a day to scan a barcode. A shared domain: the knowledge specific to a certain field of study, like data science, where they're building these kinds of dashboards. A shared brand: the values and expressions that truly differentiate an experience and make it stand out against competitors. And a shared platform, where there are certain technologies that underpin an experience. This could be something like a warehouse truck or a certain kind of tablet for in-store checkout.

[00:14:15] If you're in need of just a few extra components, you probably don't need a local design system. The best time to create one would be when you're extending foundations to create offerings that represent new experiences. That can flow all across a range, from more functional products and services to more expressive events and websites.

The feedback loop between global and local systems

[00:14:33] Design systems are meant to support, not stifle, creative expression. One major challenge in working with them is trying to strike that balance between flexibility and consistency. Usually in design systems we tend to have an inside-out approach, where we focus on the artifacts that we are making, like products, flows and components. But these artifacts are just one perspective on systems. They're actually our response to a host of activity happening outside of Shopify, like our audiences' interactions and their environments, the modes of use they're in when they're doing specific tasks, and the experience they have using multiple devices.

[00:15:20] When you flatten those different layers of experience into what we observe and what we make, there's a feedback loop that we're creating by enabling people to explore and experiment at different altitudes. There's this feedback loop between global systems and local systems, a push-and-pull dependency. The loop works when product teams are building local systems that pull in the core principles and elements from the foundations, and then those local system teams start pushing innovations they have in the product, which benefit all teams, back to the global foundations via contribution. Those contributions from local system teams spur an evolution of our global foundations, where core elements get tested again and again and adopted back by the local systems teams.

[00:16:13] While that seems pretty hard to understand, I'd love to give you an example of the push-and-pull relationship in action. Ricardo and Toby, two of our designers who own a local system, realized that the point-of-sale app they were designing for an in-store selling experience would be used in stores with really variable lighting conditions. The conditions were often either too bright or too dim. So they introduced a light and dark mode for their local design system, and then they pushed that work via contribution back to the global foundations.

[00:16:53] The pull in that scenario is where our team, who works on the global foundations, extended the light and dark mode contribution to make it flexible enough for other types of indoor and outdoor contexts, like warehouses, where lighting conditions can greatly vary. Audiences with low vision or eye strain may also have personal preferences for this light and dark UI setting. Some of these modes are things we test across Shopify, in shipping, store management and a lot of other areas, before sharing back out for everyone to pull from.

[00:17:28] While I just described the primary feedback loop between global foundations and local systems, there are also many smaller feedback loops among local systems and product teams. Local systems are owned across teams, and they're interconnected by shared context. As I mentioned, they might have a shared environment, domain or audience, or use the same technologies. So there are a lot of little shared micro-contexts that come up across teams. Are our audiences multitasking, with their attention divided across different areas where focus might be split? Do the platforms that support the same devices need to account for a range of different types of internet availability? Do the environments that our audiences work in have a lot of physically demanding tasks, like repeatedly reaching for a screen or lifting a heavy object?

[00:18:23] These interactions signal where experiences might overlap and where collaboration opportunities exist: cross-pollination of ideas across teams, design solutions they can co-create together, and reusable code that they might be able to share. With many different systems at play, our role is to make sure that we don't put them in separate boxes but instead guide the relationships between them. At Shopify we think of design systems not only as the things that we make but the things that are affected by what we make. Products need to work together within Shopify's ecosystem and our users' world. In order to guide how systems, and by extension products, interact, teams need to connect work through shared context.

[00:19:09] As architect Eliel Saarinen says, it's important to always design a thing by considering it in its next larger context: a chair in a room, a room in a house, a house in an environment, and an environment in a city plan. This is how we intend to evolve Polaris from a North Star to a system of systems. At Shopify I've learned that your system is only as strong as your understanding of the context where it lives.

Key takeaways

[00:19:42] As I wrap up, here are a few key takeaways to remember. Designing for unity, not uniformity, is about creating relationships. A unified system ensures that everything goes with everything else, like a game or a puzzle, whereas uniformity lacks a point of view because it only uses control to limit creativity, where everything is the same as everything else.

[00:20:07] Philosophy first, system second. Your beliefs, your values, your principles should come before you ever start building a UI kit or coding components. They're the rationale that your decisions for each element rely on, so don't skip them. Relationships first, system second. Get to know the people who will use your systems as people, not just as users or adopters. Before making it, understand their feelings, their needs, their aspirations, and use those to design a system that meets them where they are and guides them on a path.

[00:20:51] Context first, system second. Systems never live in isolation. There are many feedback loops across systems and between the things that we observe and make. We must build a deep understanding of how our system will show up in our users' world and our company's ecosystem before we create them.

[00:21:11] Remember, it's a dance: one, two, one, two, never reverse them. It might take some fancy footwork, but expressing brand values, creating sharing communities and considering the context for variation in a design language are keys to unlocking a healthy system. These approaches have helped me get into a groove where I've been able to bring more unity at IBM, Airbnb and Shopify, and I hope they've given you some new dance moves too. Thank you.