Unity, Not Uniformity With Design Systems

Hayley Hughes at UXDX Europe. Video: https://youtu.be/LWgJVmXe8dc

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 versus uniformity

[00:00:00] Hi, I'm Hayley. Thanks so much to the organizers of UXDX for hosting this wonderful event. I'm really looking forward to having a conversation today about design systems. To tell you a little bit about me, I currently work on the Polaris design system at Shopify, and prior to Shopify I worked at Airbnb and IBM on design language systems. Today I'm going to be talking about why it's important to bring unity, not uniformity, to 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, the author of Thinking in Systems, once said, "We tried to control systems. It turns out we can't, but we can dance with them." No matter how many boxes you try to draw around design systems, they always seem to do their own thing.

IBM: a design language without a component library

[00:00:51] At IBM, I was asked to create a design language that would unify a software portfolio of over 3,000 products. Surprisingly, we ended up taking an approach that didn't involve building a component library, because IBM had tried that before, and while it had certainly created a lot of consistency, the product quality and the brand expression left a lot to be desired. There was a set of plug-and-play widgets that had been created that produced products with a uniform look and feel, where everything felt the same as everything else, yet things were still cluttered and busy and really hard to use.

[00:01:37] Back in the seventies, 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 about a family of ideas with a distinctive character that are held together by excellence. On the other hand, uniformity is about following a consistent style, kind of like being in a military branch. This is the design language approach that we wanted to avoid: consistency in the absence of good design can lead to consistently undesirable outcomes.

[00:02:15] Instead of coding components, what I was asked to do was 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 IBM's DNA. One book that I ran across gave specific principles and success criteria for what IBM should look like, what it should sound like, what it should think like and perform like, guiding the experience around a set of principles and recommendations without being too 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 typewriters and magnetic tape reels, and we used that as inspiration for our animation guidelines. The speed and accuracy of the machine motion aligned with the sense of efficiency and effectiveness that we wanted to provide our users. We also found posters hanging on the wall, and punch cards from the old magnetic machines that had big and small data sets on them, which could be translated conceptually into how our users wanted to be able to zoom in and zoom out of data visualizations in their software tools.

[00:03:59] Creating a foundation for our design language that was built on the rationale and the aesthetic of the brand was kind of like designing a game of soccer. We were making this field of colors and typography and iconography, and inviting product teams in to play. Their job was to combine the brand values and concepts and the design elements in 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. They created what we called design guides, which served as the place for these context-specific patterns and principles across the experiences that teams were designing for.

[00:04:46] As teams at IBM invested in design and grew their designer population into the thousands across the company, we worked with newly assembled teams, like our brand team and our content team, to evolve and really push our design language. We created a new brand philosophy. We had different values that we wanted to stand for, things like partnership, progress and serving society. And most importantly, we wanted to show in the designs the relationship between people and machines.

[00:05:21] So IBM created this open-source typeface called IBM Plex, in many global languages. You can check it out on Google Fonts, download it and use it in your projects; it's available to the world. You can see in the architectural details of the typeface that there are these hard and soft edges: these machine-like precision pieces, and then these more natural, organic, rounded corners. Those things were also used to influence the look and feel of our iconography. Each of the icons had a set of key shapes, again with these hard and soft edges, that could be applied to different metaphors as a sort of visual grammar that kept our icon set harmonious.

[00:06:09] This was also something that we extended into our machine motion, which was boiled down to productive and expressive easing curves that helped us be more opinionated about how we move. And IBM, obviously, is known for being Big Blue, so our color blue became the primary action color in our products, making it pretty obvious, at any point in the software, what was there to guide you through your work. The end-to-end experience meant that no matter how a person interfaced with IBM, whether they were at one of our events, on our websites, or even talking to an IBM employee, there was a set of values in place to move people thoughtfully forward.

[00:06:58] With my first design language, designing a system for 3,000 products felt more like a rodeo than a dance. Telling stories and giving rationale that inspires the why behind the design is the key to unlocking flexibility, creativity and unity, while enabling teams to stay on beat and connect with the system. Yesenia Perez-Cruz is our senior UX lead for Polaris at Shopify, and she nicely sums up in her book, Expressive Design Systems, what 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 others won't? At IBM, what I learned is that your design system is only as strong as your brand's philosophy.

Airbnb: love letters, break-up letters and contribution

[00:07:54] On to company number two. When I joined Airbnb, it turned out they'd already built their design language system. The team had redesigned the product first, and then out of that came the system, but trying to build both at the same time certainly came with plenty of challenges. They called it the DLS, the Design Language System, and essentially it was a template, like a UI kit, a component library and a set of tools. As a new hire, I got a one-hour onboarding where I learned all about it, and then I was put on my team. If I got stuck for any reason, I could attend a weekly office hour for Q&A, but that was really the extent of design systems support if you had questions or were trying to apply it, for the first two years that it existed.

[00:08:48] The core team who designed and built the system knew the guidelines like the back of their hand but never wrote them down. As more teams tried to use it, people started asking questions, like me. As a new hire on the team, I asked, "When should I use gradients?" And someone said, "They are for special moments." To this day, I'm still not sure what qualifies as a special moment. Making me guess didn't help me work faster or easier.

[00:09:21] Out of my own struggle came a reframe of our team's mission: not just focusing on a design language system as a product, but really as something that could help enable people within our organization. How could we operate as system stewards who build trust with the community who's trying to use the system? To understand how people were feeling about the DLS, we asked them to write love letters and break-up letters to our design system. We put cookies with hearts out in the kitchens in the Airbnb office, and everyone who wrote a letter and put it in a box could grab a cookie. What we were really trying to do, from a research perspective, was understand their relationship to it.

[00:10:08] Some of the letters read, "DLS, I love you because 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 a break, because there isn't a clear way to collaborate or make changes or updates." So we had to come up with some new solutions for how we could have a more community-driven design language system. One of the things we built was a sustainable contribution model, and also a partnership program, in order to enable people to hack the system.

[00:10:55] In the two years prior, designers at Shopify [?] didn't really have a network of people or a place where they could share local knowledge. Nominated by their managers, different designers would raise their hand if they wanted to work on improving the system. We gave them a time and a place to co-design new patterns together across teams and come up with new themes, pretty much anything that they could dream. It wasn't about constraints; it was all about innovation. After we ran a survey, one of the designers in our program said that showing up to our partnership program was the best thing about the design system since it had been created.

[00:11:39] There were a lot of people who started contributing components back to the system. So we made shared ownership of our design language part of our career framework at Airbnb. We wanted to create incentives for people to really feel like this was something they were going to get personally rewarded for. So we had this category called Organizational Development, where teams and individuals were recognized for participating in systems work, not just shipping their products.

[00:12:12] Having worked on a second design system at Airbnb, the value of unity, not uniformity, unfolded a little differently. The goal this time had been about unifying the community, and using that to drive contribution and sharing. You can read more about that program on Airbnb's blog; we have a case study called Unlocking Systems Thinking. When we ran that contribution model, over 12 teams contributed, even just a few months into the pilot. It was essential for creating this resilient way of working, instead of a rigid way where people couldn't participate. What I learned at Airbnb is that your design system is really only as strong as the relationships you have with the teams who use it.

Shopify: bringing context into Polaris

[00:13:03] Nine months ago, I joined Shopify to work on the Polaris design system. 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, because, like I said, I want teams to be able to make the best decisions possible. What I experience over and over again is a mindset where teams across different domains or brands or businesses tend to think that their products are unique. The truth is they're far more alike than they are different.

[00:13:41] Like a broken record, my advice to them is always: you should talk to Team A, B, C; they're all working on something similar. The thing teams all share in common is context. They might have a shared audience and environment, a device that they're both designing for, or a task that their users are trying to accomplish. They don't know it, because today design systems are made of Lego pieces that we use to build products: again, these colors, components and code that bring unity to the user interface.

[00:14:22] But those 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 the design decisions in the system enables them to apply the system in a way that best meets their users' needs. It also saves them from my mediocre matchmaking service, where I'm trying to tell them who they should be collaborating with.

[00:14:57] In Shopify's design system, Polaris, we have a date picker that allows for something called multi-month mode. What that essentially does is enable users to select two different months at a time on a calendar. During tax season, a business owner might be downloading different documents for bills covering more than two months at a time; some bills are sent out quarterly. Because our billing team shares important context about these types of tasks with us on the Polaris design system, we can work with them to make components like the date picker more flexible for tax-specific use cases.

[00:15:38] At Airbnb, we designed everything from marketing emails to statistics dashboards for expert hosts, and we would change our tone of voice based on what we wanted to express. One tone felt more celebratory and another was more trustworthy, based on what we were designing. These different examples demonstrate how systems aren't one size fits all. I'm circling back to Airbnb just to show you that design systems are meant to be interpreted in each situation, so teams can decide what's most appropriate for their users.

[00:16:17] The question we're asking ourselves at Shopify now is: how do we bring this context into design systems? Currently, the approach we're taking is to systematize context, just like we've systematized the parts of our products. At Shopify, we're bringing context into Polaris using a storytelling method. We're writing scenarios that help people get the context out of their heads and documented in the system. To explore what that sounds like, you should check out the scenario created by our retail team at polaris.shopify.com/experiences.

Scenarios and variables: dark mode and split focus

[00:16:53] To gather context, this team visited multiple stores and interviewed retail staff. The UX guidance that they give in Polaris is influenced by what they've learned about how staff run brick-and-mortar stores. Imagine walking into a noisy store with lots of customers standing in a long line. Staff members are rushing about, moving from checking out a customer in a really brightly lit storefront to managing inventory in their dimly lit back office. As they go back and forth, the screens on their card readers and their tablet displays become hard to read between these variable lighting conditions.

[00:17:38] This scenario provides deeper empathy for what it's like to work in retail. Because lighting conditions vary greatly in a store, the retail team created a high-contrast dark mode in their product, their point-of-sale app, to support staff as they go between environments on multiple devices. Our shipping team learned about the context for why the retail team created dark mode, and now our shipping team is also piloting the same high-contrast dark mode in warehouses, where variable lighting is also a big challenge.

[00:18:14] As you can see in this example, context is what helps teams leverage each other's work. They can understand why designs were created to support certain use cases and not others. They use context to diagnose when a design is not working well, which ensures that they avoid repeat mistakes. On the systems team, we use context to help determine whether we should extend existing smart-default components to work for new use cases. And most importantly, leveraging each other's work can create more unified designs for our users across their end-to-end experience.

[00:18:52] In the future, we're hoping to highlight things called variables in a scenario. We call them variables because they are the changing conditions in a user's world, which for us become constraints in our design. At Shopify, one variable that we've identified is split focus across different experiences. Our local delivery drivers have split focus when 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 our warehouses. These are two very different experiences, which both share split focus as a variable we design for across the products that we make. Our hypothesis is that teams who share common variables likely have insights or components to leverage from one another.

[00:19:49] Context is critical for teams using design systems. Without it, they either force-fit user needs into components that don't scale, or they surrender to the technical debt of making everything from scratch. Both of those outcomes create more silos than collaboration. The products that we design are always influenced by our users' world, where they're situated. By bringing context into design systems first, before we build the components that result from it, we're enabling teams to make more confident decisions and deliver the best outcomes for their users.

[00:20:26] As architect Eliel Saarinen says, it's important to always design a thing by considering it in its next largest 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 into a system of systems. At Shopify, I've learned that your system is really only as strong as the understanding of the context where it lives.

Takeaways: it's a dance

[00:20:53] As I wrap up here, a few key takeaways. Designing unity, not uniformity, is about creating relationships. A unified system ensures that everything goes with everything else, whereas uniformity lacks a point of view and only uses control to limit creativity, so that everything is exactly the same. Philosophy first, system second: your beliefs, your values and your principles should come before you start building a UI kit. They're the rationale that your decisions rely on, so don't skip them.

[00:21:37] Relationships first, system second: get to know the people who use your system as people, instead of as users or adopters. Understand their feelings, their needs and their aspirations, and use those to design a system that meets them where they are and guides them on their path. Context first, system second: systems never live in isolation. There are so many feedback loops across systems and between the things that teams are designing for across experiences. Remember those audiences, tasks, devices and environments. We have to build a deep understanding of how our systems show up in our users' worlds and in our company's ecosystem before we create them.

[00:22:25] Always remember, it's a dance: one, two, one, two, never reverse them. It might take some fancy footwork, but expressing your brand values, creating sharing communities and considering the context for variation in a design language are the keys to unlocking a unified system. These approaches have helped me get into a groove where I've been bringing more unity, not uniformity, to IBM, Airbnb and now Shopify. And I hope that they've given you some new dance moves too. Thank you.