Design Systems at Scale // Episode 1: The Heartache of Design at Scale

I often think of Gall's Law. John Gall was a pediatrician, of all things, who said something to the effect that every complex system that works was invariably created from a simple system, and that every complex system that was created from scratch as a complex system always breaks and fails and cannot be patched to work.

I'm Brad Frost and I'm a front end developer by trade. And I like to say that I make websites and I help other people do the same. So a lot of what I focus on is crafting front end code that is scalable, that is flexible, that is performant, that is accessible. I'm concerned with how these UI components find their way into actual working software products.

I'm Dan Mahl. I'm a designer and a creative director from Philadelphia. I run a design collaborative called Super Friendly. My job will be to help designers understand how to work with design systems, what their roles actually are, how to collaborate better and really be in tune with all the other people working on the project.

My name is Josh Clark and I'm a product director and interaction designer. I run a design studio called Big Medium in Brooklyn. It's focused on design for what's next. I'm here to help people understand how to create a design system as a product when one that really matches the DNA of an organization, so that it dovetails not only with how a company designs products, but with how they want to design products. As digital design has just become part of the fabric of business and of organizations, design has become as complex as the organizations themselves. And what that means is that design now is full of all of the dysfunction and problems and wonder and joy of any large organization. So what I'm seeing more and more is that there is this challenge, particularly for larger organizations, but really for anybody who's working on a large project or a large series of projects or products is what I call the heartache of design at scale. When you have a small team working on something, you know, everybody on the team knows how something works. Like the three of us working on a project, we have intimate familiarity of how the system that we're creating works. We can have all that in our conversations or just in our common work together. And it seems like as things get larger and larger, necessarily, we aren't able to keep up with the project or the team that's working on something over here at the exact same time. And this is something that I think a lot of companies beat themselves up over. But it's sort of natural that the more people that you have working on stuff the more sprawl that you're going to get and the more inefficiencies.

It's also a lot more stuff now, too. I remember when I first started doing design, whatever, 15, 20 years ago, the inquiries that I would get are from a company that goes, help me to make our website the one thing, the one website. And now I can't think of that time. I can't think of a client that has said, oh, we need a website now. It's. They're managing, they have a dozen microsites and they have their corporate website and they have a bunch of apps and then they've got their intranet and their extranet and they're realizing, well, we don't really know how to manage all of these things. And so it's not just them working on lots of people working on the one thing, it's lots of people working on lots of things. And I think that lots of organizations are finding themselves in that mode where they're just like, how do we do this intelligently, efficiently and all of that.

So what I'm seeing more and more is that there is this challenge, particularly for larger organizations, but really for anybody who's working on a large project or a large series of projects or products, one hand doesn't know what the other hand is doing, even when they're my own hands. And imagine what happens when you multiply that. Times many people, times many projects, times many teams, times many years. And so what we get is this sprawl of design solutions where I have an idea and I implement it, but somebody across the hall or across the building, or even across the world comes up with a similar solution. Same product, the same company, maybe on a different page, it looks sort of the same, but it's a little through the looking glass. But in any case, we've built this thing twice. We've done the same work for the same result, maybe with uneven results multiple times. It's a waste of energy and effort and frankly of creativity and talent, because we have great people solving the same problem over and over and over again.

There's a ton of different benefits of having a design system. They promote UI consistency and cohesion, allowing users to get done what they need to get done. It allows for faster production, it allows teams to produce higher quality production. It establishes a shared vocabulary between disciplines and different processes, products, makes things easier to test, so you're able to create sturdier, more resilient solutions. It creates a useful reference to keep coming back to as your teams do their product Design work. And lastly, it provides a future friendly foundation to grow and evolve the system over time.

We believe that design systems are a way to solve that problem by essentially pulling together the best solutions so that we can all profit from them.

The design system can include things like design principles, design tokens, high level UX guidelines, development guidelines, the UI patterns, of course, but even going so far as to sort of put those together into common page templates and user flows, sort of baking things into design tools like, you know, Envision Studio or Sketch libraries. I can include things like brand guidelines and voice and tone guidelines. Writing guidelines and processes are a big one. So including things like how you deploy the system into individual applications and how you contribute back into the system, and also internal and external resources, things like links out to internal wikis and stuff like that, but also industry best practices sort of articles, links out to smashing magazine or CSS tricks to help understand why things are designed the way they are. And so all of these ingredients sort of work together to help tell that canonical story of here's how our organization designs and builds products.

We work with a lot of designers and design teams, and their first inclination is that might be part of a design system. But just having a Sketch UI kit or Photoshop UI kit or Studio UI kit, that's only one tool, that's only one piece that only designers can use. Part of a good design system is that it's a tool that everyone on the team can use. And the fact that a UI kit is locked up in a certain tool that other people aren't familiar with means it's not accessible to everyone. So by definition, it's not really a design system, it's part of one. It could help you make one. But really we should be liberating all of our design tools from outside of a particular environment where it's locked down, and instead working on something that everybody can kind of touch.

It's important to reiterate that the kit of parts, the kit of components, isn't necessarily enough on its own. Having a bunch of UI components without any sort of context is like dumping a bunch of IKEA parts on a dining room table and say, okay, time to build this dresser, right?

I think one thing that's dangerous about treating UI kits as design system is it really just reinforces what designers do all the time. And part of having a good design system actually is to get everyone a little bit outside of their comfort zone, to be able to work with each other more, to engage more with each other. And that might mean changing Some process and changing some tooling and changing some of the work dynamic. And so for a designer to have a UI kit and sketch or whatever tool, Illustrator or whatever they want, it really just says, just keep working the way that you're working, keep making comps, keep, keep working in your environment. You don't have to talk to anyone, you don't have to collaborate with them. And I think part of what having a good design system will do is actually just get you outside of that comfort zone. And so rather than working on your UI kit in isolation by yourself or even with the designers, if you could think about, well, what are the things that I actually need to make and what do other people need me to make on this team? It's often not a UI kit.

Interface inventory is really helpful at getting at what the DNA of our organization's products are. Right? And that's going to help dictate and determine the design system's makeup and roadmap. And what an interface inventory is is basically an exercise where we go out and round up and collect all of the instances of UI design patterns across an organization's different products. And that could include different web properties, but also native properties, internal facing applications, and external facing applications. Conducting an interface inventory is really crucial. The first step of conducting an interface inventory is to round up all the troops, is to get all the different disciplines responsible for the success of your design system. So that includes designers, developers, QA people, product people, anyone who's responsible for the success of your digital products. And it's so important to get all of those people in a room together, because oftentimes this is one of the biggest points of conflict is that, you know, these teams and these different disciplines don't speak the same language. And so an interface inventory exercise is one of the first steps to starting to establish that shared vocabulary. It's through the lens of this exercise that each discipline is going to be exposed to sort of why our UIs are inconsistent and incongruent and sort of through that sort of shared realization, through doing that exercise together, everyone's able to sort of recognize the pain and sort of come out the other end with a shared mission of sort of establishing a set of common, consistent, congruent patterns. The second step of conducting an interface inventory is, is to prepare to screenshot. So basically what an interface inventory exercise is is basically just going through a bunch of different products and a bunch of different screens and capturing unique UI patterns. So that really just takes the form of screenshots. So what we need to do is establish a common place to sort of dump and categorize all of these screenshots. We've created a template that you can use using Google Slides, but really the tool doesn't matter just so long as everyone's able to sort of collect these UI pattern and put them together into one giant document at the end of the exercise. Now the fun part is actually doing the exercise is actually combing through these products and looking for patterns. And what we do is we sort of chunk them out based on the kind of category, the UI category that components belong to. So for instance, you know, the product manager might be responsible for finding every instance of the headers and footers across your different properties. The next person might be responsible for finding unique button styles. Another person might be responsible for collecting different form components. So things like radio buttons and checkboxes and form fields and text areas and select menus and things like that. Somebody else might be on typography duty, another person might be on motion duty. So finding all the different ways things sort of fade in and out or slide up and down, things like that. Looking for things like media. So you have embedded YouTube players and embedded content or external third party applications or social widgets and things like that. So the idea is to sort of chunk these out by category and then have everyone go on a big Easter egg hunt. The idea behind this exercise is to go far and wide, to really dive into the dark corners of your web products to hunt for these distinct patterns. The idea is to sort of collect them all under one roof. So once that exercise is done, then we get everybody together and everyone presents what they find. So the person on button duty gets up and sort of presents to the group, here's all the different button components I found and here's these social buttons that we found that look a lot different than these other social buttons, which look a lot different than these other social buttons. And this is an important part of the exercise because it's here where that sort of shared pain and shared language starts coming out. It's in this presentation that teams are able to sort of call things names, right? So it's like, oh, here's this admin bar. And then the rest of the team can chime in and say, oh, admin bar, we call that the gray bar. And then the developers say, oh, we call that the utility bar or something like that, right? So it's, it's through this presentation and conversation that that shared vocabulary starts forming. And then sort of the fifth step is once this is all done you can sort of consolidate all of the UI patterns found in the exercise, put them all into one giant Uber document. And now this is something. This is an artifact you could use to sort of circulate around the organization. This is something you could print out and put on your CPU CEO's desk. And this is where the magic happens. Because you don't have to be a designer to understand that having 70 different button styles is a bad idea, right? So it's by sort of showing this stuff, by sort of consolidating all these inconsistent patterns right beside each other, it becomes very visceral and very real of the heartache of design at scale.

A design system is not about invention, it's about curation.

There's so many different avenues to kick off a design system initiative that it can almost become paralyzing, right? Where do we start? Where do we put this stuff?

How do you actually convince your peers? How do you convince your managers that a design system is worth it?

I think the most exciting design systems are boring. And I don't mean that they create boring products. I mean that they are composed of all of the boring components that we've all built a thousand times.

You have to speak the language of the person that you're talking to.

This is not the time to create something new, but to pull together the best work from across the organization.

It's not that UX design or visual design is no longer important. It's just that you're sort of bypassing a lot of the artifacts that know used to get a lot of attention.