Episode 1 - The heartache of design at scale

Josh Clark: I often think of Gall's Law. John Gall was a pediatrician who said something to the effect of ‘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.’

MAIN TITLE: DESIGN SYSTEMS—MASTERING DESIGN AT SCALE

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

DAN MALL: I'm Dan Mall. I'm a designer and a creative director from Philadelphia. I run a design collaborative called SuperFriendly. 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.

JOSH CLARK: My name's Josh Clark and I'm a product director and interaction designer. I run a design studio called Big Medium in Brooklyn that's focused on design for what's next. I'm here to help people understand how to create a design system as a product, 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 become part of the fabric of business and organizations, design has become as complex as the organizations themselves. What that means is that design now is full of all the disfunction and problems and wonder and joy of any large organization.
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.
EPISODE TITLE: THE HEARTACHE OF DESIGN AT SCALE

JOSH CLARK: 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. It seems like as things get larger and larger, we aren't able to keep up with the projects or the team that's working on something over here at the exact same time. This is something that I think a lot of companies beat themselves up over, but it's sort of natural that the more people you have working on stuff, the more sprawl you're going to get and the more inefficiencies.

DAN MALL: 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. Now, I can't think of that time. I can't think of a client that has said, ‘Oh, we need a website.’

Now, they're managing a dozen microsites and they have their corporate website and they have a bunch of apps. 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.’
So, it's not just lots of people working on the one thing, it's lot 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 and efficiently?"

JOSH CLARK: 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.
Imagine what happens when you multiply that times many people, times many projects, times many teams, times many years. 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 for the same product, for the same company, maybe on a different page. They look sort of the same, but it's a little through the looking glass. 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 again.

BRAD FROST: There are 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 higher-quality production. It establishes a shared vocabulary between disciplines and different products. It makes things easier to test, so you're able to create sturdier, more resilient solutions.

JOSH CLARK: 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.

BRAD FROST: It creates a useful reference to keep coming back to as your teams do their product design work. Lastly, it provides a future friendly foundation to grow and evolve the system over time.

DAN MALL: We work with a lot of designers and design teams and their first inclination as to what a design system is, is a UI kit. That's not what a design system is. That might be part of a design system, but just having a Sketch UI kit or a Photoshop UI kit or Studio UI kit, that's only one tool. That's only one piece, and one that only designers can use.

Part of a good design system is that it's a tool that everyone on a 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 touch.
SECTION TITLE: IT’S NOT A UI KIT
BRAD FROST: 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 saying, ‘Okay, time to build this dresser.’
DAN MALL: One thing that’s dangerous about treating UI kits as a design system is that it really just reinforces what designers do all the time. Part of having a good design system is that it gets everyone a little bit outside of their comfort zone to be able to work with each other more, to engage more with each other. That might mean changing some process and changing some tooling and changing some of the work dynamic.

So, for a designer to have a UI kit and Sketch or whatever tool or Illustrator or whatever they want, it really just says, ‘Just keep working the way that you're working. Keep making comps. Keep working in your environment. You don't have to talk to anyone. You don't have to collaborate with them.’
I think part of what having a good design system will do is actually just get you outside of that comfort zone. 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 or what do other people need me to make on this team.’ it's often not a UI kit.
BRAD FROST: A 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 put those together into common page templates and user flows and sort of baking things into design tools like InVision Studio or Sketch libraries.
It can include things like brand voice, tone, and writing guidelines. Processes are a big one, and including things like how you deploy the system into individual applications and how you contribute back into the system. Internal and external resources, things like links out to internal wikis and stuff like that, but also industry best practices. Articles, you know, links out to Smashing Magazine or CSS-Tricks to help understand why things are designed the way they are.

All of these ingredients work together to help tell that canonical story of ‘here's how our organization designs and builds products.’

SECTION TITLE: INTERFACE INVENTORY

BRAD FROST: One of the things we do in our process is to kick off an initiative with an interface inventory. An interface inventory is basically an exercise where we round up and collect all of the instances of UI design patterns across an organization's different products—that could include different web properties, native properties, internal-facing applications, and external-facing applications.  

An interface inventory is really helpful at getting at what the DNA of our organization's products are. That's going to help dictate and determine the design systems' makeup and roadmap.

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. That includes designers, developers, QA people, product people—anyone who's responsible for the success of your digital products. It's so important to get all of those people in a room together because this is often one of the biggest points of conflict—these teams and these different disciplines don't speak the same language.

So, an interface inventory exercise is one of the first steps toward establishing that shared vocabulary. It's through the lens of this exercise that each discipline is going to be exposed to why UIs are inconsistent and incongruent.

Through that shared realization, through doing that exercise together, everyone is able to recognize the pain and come out the other end with a shared mission of establishing a set of common, consistent, congruent patterns.

The second step of conducting an interface inventory is to prepare to screenshot, basically just going through different products and different screens and capturing unique UI patterns. That really just takes the form of screenshots. So, we need to establish a common place to dump and categorize all of these screenshots.
I like using Google Slides because it allows teams to dump these screenshots in one place and quickly share a link with the rest of the team. Really, the tool doesn't matter, as long as everyone's able to collect these UI patterns and put them together into one giant document at the end of the exercise.

Now, the fun part is actually doing the exercise—actually combing through these products and looking for patterns. What we do is we sort of chunk them out based on the kind of UI category that components belong to.

So, for example, the product manager might be responsible for finding every instance of 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—things like radio buttons and checkboxes and form fields and text areas and select menus. Somebody else might be on typography duty. Another person might be on motion duty, finding all the different ways things fade in and out or slide up and down. Looking for things like media. Do you have embedded YouTube players and embedded content, or external third-party applications or social widgets and things like that?

The idea is to 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 and collect them all under one roof. Once that exercise is done, we get everybody together and everyone presents what they find.

So, the person on button duty gets up and 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.’
This is an important part of the exercise. It’s where that shared pain and shared language starts coming out. It's in this presentation that teams are able to ‘call things by names,’ right?

It's like, ‘oh, here's this admin bar.’ Then the rest of the team can chime in and say ‘oh, we call that the gray bar.’ Then the developer's say ‘oh, we call that the utility bar.’ So, it's through this presentation and conversation that the shared vocabulary starts forming.

Then the fifth step is, once this is all done, you consolidate all of the UI patterns found in the exercise and put them all into one giant uber-document. This is an artifact you can circulate around the organization. This is something you can print out and put on your CEO's desk. 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.

So, it's by showing this stuff, by consolidating all of these inconsistent patterns right beside each other, that it becomes very visceral and very real—the heartache of design at scale.
SECTION TITLE: NEXT EPISODE PREVIEW
JOSH CLARK: A design system is not about invention, it’s about curation.

BRAD FROST: There are so many avenues to kick off a design system initiative that it can almost become paralyzing. Where do we start? Where do we put this stuff?

DAN MALL: How do you actually convince your peers, how do you convince your managers that a design system is worth it?

JOSH CLARK: I think the most exciting design systems are boring. I don’t mean that they create boring products, I mean that they are composed of all the boring components that we’ve all built a thousand times.

DAN MALL: You have to speak the language of the person you’re talking to.

JOSH CLARK: This is not the time to create something new, but to pull together the best work from across the organization
BRAD FROST: It’s not that UX design or visual design is no longer important, it’s just that you’re bypassing a lot of the artifacts that used to get a lot of attention.