Unity, Not Uniformity With Design Systems

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. So, 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.
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. At IBM, I was asked to create a design language that would unify a software portfolio of over 3000 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 plugs and play widgets that had been created that produce 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. Back in the seventies, when IBM's first designed 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. Instead of coding components, what I was asked to do was to study the brand legacy of a hundred-year-old company, including the designs of Paul Brand 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 does it 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. 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 actually 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 out of the old magnetic machines that had big and small data sets on them, which could be translated conceptually into how our users want it to be able to zoom in and zoom out of data visualizations in their software tools. Creating a foundation that was built on the rationale and the aesthetic of the brand for our design language was kind of like designing a game of soccer. We were making this field of colors and typography and I could 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 user's needs because we didn't build a component library teams would make their own using the design language. They created what we call design guides, which served as the place for these context specific patterns and principles across experiences that teams were doing designing for. As teams invested at IBM 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, serving society. And most importantly, we wanted to show in the designs, the relationship between people and machines. So, IBM created this opensource typeface called IBM Plex in many global languages. You can check it out on Google Fonts and download it and use it in your projects - it's available to the world. And you can see in the architectural details of the typeface, there are these hard and soft edges. These machines like precision pieces and then these more natural, organic sort of rounded corners. And 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 eye concept harmonious. 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 that it was there at any point in the software to guide you through your work. The end to end experience meant that no matter how a person interface with IBM, whether they were at one of our events on our websites, or even talking to an IBM employee, there were a set of values in place to move people thoughtfully forward.
So, with my first design language, designing a system for 3000 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 and 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. She nicely sums up in her book, Expressive Design Systems, what building concepts that 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. And IBM, what I learned is that your design system is only as strong as your brand's philosophy.
So, onto company number two, when I joined Airbnb, it turns out they'd already built their design language system. The team had redesigned the product first and then out of that, 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, then I could attend a weekly office hour for Q&A but really that was the extent of Design Systems support. If you had questions or if you were trying to apply it for the first two years that it existed. The core team who designed and built the system knew that 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 to 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. Out of my own struggle came a reframe of our team's mission, not just focused 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 these cookies out in the kitchens, in the Airbnb office with hearts 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. 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 that we built was a sustainable contribution model and then also a partnership program in order to enable people to hack the system. 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 and they wanted to work on improving the system. So, 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. One of them, the designers in our program after we ran a survey set that showing up to our partnership program was the best thing about the design system sensitivity been created. There were a lot of people who started contribute 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 that they were going to get personally rewarded for. So, we have this category called Organizational Development where teams and individuals were recognized for participating in systems work, not just shipping their products.
Having worked on a second design system in Airbnb, the value of unity not uniformity unfolded a little differently. The goal this time had been about unifying the community, and, but 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, it ended up that 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 that you have with the teams who use it.
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. Like a broken record, my advice to them as always, you should talk to them 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 different device that they're both worked designing for or a task that their users trying to accomplish. They don't know it because today Design Systems are made of Lego pieces that we use to build products there. Again, these colors, components, and code that bring unity to the user interface. 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 their design decisions in the system enables them to apply the system in a way that best meets their user's needs. It also saves them from my mediocre matchmaking service, where I'm trying to tell them who they should be collaborating with. In Shopify’s design system, Polaris, we have a date picker that allows for something called Multi-month Mode. What that is essentially enabling users to select two different months at a time on a calendar. During tax season, a business owner might be downloading different documents to choose bills for more than two months at a time. Some bills are sent out quarterly and 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. At Airbnb, we designed everything from a marketing email 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 one was more trustworthy based on what we were designing. These different examples demonstrate how systems aren't one size fits all. So, 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. The question we're asking ourselves with 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 head and documented into the system to explore what that sounds like. You should check out the scenario created by our retail team on polaris.shopify.com/experiences. To gather context, this team visited multiple stores and interviewed retail staff. The UX guidance that they give and Polaris is influenced by what they've learned about how staff run Brick and Mortar stores.
So, 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're going back and forth the screens on their card readers and on their tablet, displays become hard to read between these variable lighting conditions. 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. As you can see in this example, context is what helps teams leverage each other's work. They can understand why designs are created to support certain use cases and not others. They use context in order to diagnose when a design is not working well, which ensures that they avoid repeat mistakes. On the systems team, we use context in order to help determine if 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. In the future, we're hoping to highlight things called variables in a scenario and we call them variables because there are these 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 experienced split focus when their attention is divided between scanning rows of heavy boxes and then inputting data into robots that move around our warehouses. These are two very different experiences, which both share split focus as a variable we designed for across the products that we make. Our hypothesis is the teams who share common variables, likely have insights or components to leverage from one another. 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 components create more silos than collaboration. The products that we design for are always influenced by our users' world, where they're situated by bringing context into Design Systems first before we build components, which result from it. We're enabling teams to create more confident decisions and deliver the best outcomes for their users. 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, 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.
So, as I wrap up here, a few keys takeaways, designing unity, not uniformity is about creating relationships. A unified state system ensures that everything goes with everything else whereas uniformity lacks a point of view and it only uses control to limit creativity so that everything is exactly the same. Philosophy first, system second. Your beliefs, your values, 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. Relationship first, system second. Get to know the people who use your system versus 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, environment. We have to build a deep understanding for how our systems show up in our users' worlds and in our companies ecosystem before we create them.
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 keys to unlocking a unified system. These approaches have helped me get into a grove 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.