Design leader, web developer, author of seminal design systems book, Atomic Design

Design leader, founder/director of SuperFriendly, co-founder/CEO of SuperBooked

UX design leader, founder of Big Medium, author of Designing for Touch

Build your design system like the pros

Design System Manager - Expert Advice

Would you like to speak with InVision about how to unite your team's workflow using DSM Enterprise?

Brad Frost, Dan Mall, and Josh Clark deconstruct the organizational challenges of scaling digital product design and reveal how design systems can unite teams and provide consistency in the face of growing product demands. Whether you’re starting from scratch or evolving an existing system, this up-close conversation offers real-world insight into modern design systems and [&hellip;]

Brad Frost, Dan Mall, and Josh Clark deconstruct the organizational challenges of scaling digital product design and reveal how design systems can unite teams and provide consistency in the face of growing product demands.
 
Whether you’re starting from scratch or evolving an existing system, this up-close conversation offers real-world insight into modern design systems and what they can solve.

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. &nbsp; 
 
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.

Watch design system experts Brad Frost, Dan Mall, and Josh Clark share best practices for starting design system projects. Learn how to secure funding, calculate ROI, inspire team buy-in, and begin designing at scale.

What does it take to turn your design system vision into a funded project buzzing with excitement? What can you do to justify its value to the executive team, and where do you build early alliances to guarantee success?
 
Brad Frost, Dan Mall, and Josh Clark answer those questions and more as they share practical advice for nailing your pitch, calculating ROI, and inspiring the kind of early internal alignment that leads to long-term investment.
 
Whether you’re beginning your design system initiative or looking to reboot, this intimate conversation covers what it takes to navigate the critical first steps toward designing at scale.

Episode 2 - Selling the value of your design system

Josh Clark: A design system should bear the burden of the boring so the designers and developers don’t have to. What I mean by that is, there are a whole set of common scenarios that any given company will solve over and over again for their products. Let’s solve them once and steadily improve them, rather than constantly invent them over and over again.
 
To do that, we need to bring those solutions into one place where they’re available to all, and create a repository of institutional knowledge for the company and its product organization.
 
MAIN TITLE: DESIGN SYSTEMS—MASTERING DESIGN AT SCALE 
 
Brad Frost: There’s so many different facets and 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?
 
Josh Clark: Building a design system is complicated and as difficult as that can be, sometimes it seems like the hardest thing is just getting the project started; getting everybody on board with the effort, with the investment. How do you sell a design system project within an organization and get it going?
 
Dan Mall: There’s a bunch of levels to it, right? So a lot of it is where you exist on the org chart and what your job is at the organization. So lots of times we see designers and developers who aren’t management, but are the worker bees, the people working on the products. They see the value of a design system, but maybe their manager doesn’t, or maybe their peers don’t. So that’s kind of one level.
 
If you’re a designer or a developer, how do you actually convince your peers, or how do you convince your managers that a design system is worth it?
 
SECTION TITLE: PITCHING THE PROJECT 
 
Dan Mall: I think one of the things that maybe applies to all of the different levels of this is that you have to speak the language of the person that you’re talking to, that you’re selling to. So, if you’re selling to your boss, who is in charge of managing design, maybe one of the languages that you have to speak is the language of efficiency, right? To say, ‘here’s the way that we’re not doing things as efficiently as possible and a design system could be one of the tools that we use to solve that.’
 
I know when I was working with the Seventh Day Adventist Church to help them build a design system, the web manager there, Brent, he did this great exercise that I love referencing. 
 
What he did was, he printed out every website that they made on these little 3x3 inch cards and every website that they made that year, and they printed out. They did a couple hundred. And then he pasted those onto mounting boards, black mounting boards, and then he brought them into his boss’s office, this was about six or seven mounting boards, and he just showed him and he goes, ‘this is how much money we’re wasting.’
 
What he was doing was really just kind of showing, visually, literally showing the pain as like, ‘We could be doing this a lot more efficiently. We’re wasting a lot of money and this is why I need a budget to do a design system.’ 
 
And he walked out of that room with a budget. So I think part of it is depending on where you are in the organization. You have to speak the language of the person that you’re talking to.
 
SECTION TITLE: SHOW ME THE MONEY 
 
Josh Clark: When you’re also going and looking for funding, it’s like when you’re getting down to the brass tax of budget, that’s a different consideration than some of the pain that designers and developers feel from doing reuse or seeing inconsistent work across the board. It’s a different matter than production. 
 
So, when you’re talking about budget and when you’re talking to the people being sort of like, ‘we need a little bit of extra funding for this,’ it really comes down to, ‘How are we going to make more money from this? Or how are we going to save a lot of money from this?’
 
Josh Clark: I think that there are some things, some examples out there that you can really point to. We helped a big retailer create their design system and the before and after of the process that that design system unlocked, as well as having those assets in place, was remarkable. 
 
They now are saying that they are making products ten times faster with teams a quarter of the size. So they can do enormous amount of work now because they can deploy those extra people on to other projects that otherwise would have languished.
 
When we built Exxon Mobile’s Unity design system, in the first ten months, they built fifty new web apps using this system. This is enormous acceleration. So there’s a clear cost savings there. Well, you can take it in one of two ways. Either we can save money or we can do a lot more with our money, right? So that’s a big pitch to make when you’re going for budget.
 
The other thing is—how can the products we make make more money? You know, do more conversions, get more out of it? Or whatever the goal is of the organization. Maybe it’s not specifically about money, but it’s about convincing people of your cause, or whatever the case is. How can we be more effective with our products?
 
I think that clearly one of the big benefits is improved consistency, improved quality, improved accessibility that you get by ... Instead of constantly reinventing, is constantly improving on them, gradually, so that all of your products get those benefits.
 
So I think that those things, ‘here’s the way that consistency and quality will help us make more money and that efficiency and reuse will help us save money,’ are really big, important levers to pull when talking to executives about this stuff.
 
Dan Mall: I think part of the moral of story, too, is not to fall in love with the design system itself. You know, for some people that will be very attractive, but for others it won’t be important at all.
 
We come across a lot of teams that fall in love with the idea of a design system, and that’s not to say that it’s not advantageous, but if you’re selling the design system to someone that doesn’t care about a design system, it’s not going to sell well. 
 
So how do you actually talk to them in a way that speaks their language and gets them to go, ‘Oh, I’ve wanted that for a long time and is this thing going to help me get it? Okay, then now I’m invested in it. Now I’m interested in having it here.’
 
SECTION TITLE: THE CAT IS OUT OF THE BAG 
 
Brad Frost: Now that the design system cat is out of the bag, I mean, you have Material Design out there, there’s freakin’ videos being made about design systems—
 
Josh Clark: Who’s making those?
 
Brad Frost: I know, it’s crazy. But at the same time, now that it’s a thing, people are then selling the thing. So okay, yeah, we need to build this design system and what ends up happening is that you start getting a lot more pushback because it’s not an actual product, right? It’s not an actual thing that you’re going to launch to your end users. Your customers get the benefit of having a design system, but all of that stuff happens behind the scenes.
 
Dan Mall: One of the common stories about say, the jobs to be done framework is that when people are trying to buy a drill, nobody wants a drill. Nobody wants a 1/4" drill, they want a 1/4" hole, right?
 
Brad Frost: Yeah.
 
Dan Mall: And you can take that even further. Nobody wants a 1/4" hole, they want a picture hung on the wall.
 
I think that oftentimes, we forget and the industry forgets, because design systems are becoming more popular and more prevalent, we forget that no one needs a design system, they need the thing the design system makes. It would be like walking in and trying to sell someone on the virtues of Sublime Text Editor. No one cares about Sublime Text Editor. Developers do, but really people want the code that you write and the thing that you make.
 
We’ve experienced that a lot recently where... I can think of one example where the design team at this one organization, they really wanted a design system, and for good reason. For all the reasons that we’ve talked about and all the reasons that we know, and they are making a good pitch for this idea and really working on it in a great way.
 
Then, what they have to do, the hurdle is, ‘Well, now we have to get IT on board.’ So IT’s like, ‘yeah, but we already kinda have something like that. We have mobile developers that have their own library, we have enterprise architects that have kind of their own ... We have some of this stuff already. We don’t really need a design system. We’re actually going to focus our attention on that product that we need to make right now.’
 
The designers are going, ‘Yeah, yeah, but the design system will help us make that product.’ And they’re like, ‘No, no, no, we just need to work on the product.’
 
So the story that we should’ve told to the IT team is, ‘We’re going to help you make the product. If you want to know how, it’s this thing called a design system, but really what we’re going to do is help you make this product.’
 
SECTION TITLE: ASK FOR FORGIVENESS NOT PERMISSION 
 
Brad Frost: You could have all the metrics in the world and other people’s case studies and all of that stuff, talk about the different benefits, all of that stuff is great and important, but they could still go, ‘yeah, no. We got bigger fish to fry and stuff like that, like building this one product.’
 
I think that some teams will get deflated, and we find ourselves sometimes in that boat where we’re like, ‘well, back to the drawing board.’
 
But I don’t think that that has to be the end of the story. There are many things that individuals can do on a team to arrive at more systemic approaches to design and development. And that all works within the constraints of whatever the current budget is, the current scope of the current project that you’re working on. And I think that’s great and I am a huge fan of asking forgiveness, not permission, because at the end of the day, these teams are tasked with building a product, right? How that product gets made is inconsequential, right?
 
So, the cool thing is, that once the launch party happens and everybody’s super happy with the result and the boss and everyone’s thrilled, it’s sort of at that moment you could say, ‘psst, come over here. Let me show you what we actually did to create this thing. Here’s this set of well-constructed, robust, flexible, assessable, performant components that we used and reused and reused across the site to build this thing at a higher quality.’
 
Once you go through the lens of one product, then you can start to say, ‘hey, we have something here. Maybe we want to build on that.’ And that can go up to the higher ups, where you’re not just coming to the people with the money with an idea, but you’re coming with a freaking case study of something that actually worked really, really well for the specific product and you go, ‘okay, here’s how we scale that, and here’s what we need to scale that.’
 
TOP-DOWN OR BOTTOM-UP?
 
Dan Mall: I think it’s important to note, that has to exist within the context of your organization’s culture, right? We’ve seen two ends of the spectrum. One is that sometimes a design system starts really grassroots, where it’s a handful of designers or developers or product people that say, ‘well, let’s come up with a set of standards and principles and maybe a little library of tools that we can use.’ And then it grows from there.
 
Dan Mall: Other times, it’s top down. The CEO or a VP or something says, ‘We’re using this design system. Everyone has to use it now.’ And everybody scrambles a little bit. I think it’s important to understand the culture of your organization and know which approach is going to work with the organization that you have, because they’re not mutually exclusive, they won’t work if the culture of your organization is not set up in that way.
 
Josh Clark: One thing that we’ve noticed is that really high-performing organizations that consistently create new products and new work, almost all of them have a design system of some form.
 
The best organizations have a design system. I think it’s important to understand that a design system will not make you one of the best organizations, right?
 
That part of the reason that these design systems work in these organizations, because they have them because they are naturally suited to them. They have a culture where the design system can take root and process where they can be used.
 
I think one of the things about preparing for a design system is not only how do we convince people to make one, but also how do we make sure that we’re in a good position to use it? That we are in a practice that will be collaborative? That it’s not just designers over here who are enthusiastic about it, but that the designer’s colleagues and development are ready for it, or that the manager’s in product are ready for it.
 
So, I think part of this thing is often not only finding funding or finding resources, but finding allies and kindred spirits and paving the way for a new kind of work.
 
SECTION TITLE: NEXT EPISODE PREVIEW
 
Dan Mall: It reminds me of a Seth Godin quote, that the stuff that makes a museum is the stuff that's not on the walls.
 
Brad Frost: Our bodies, this floor, this stool, the planets, the stars, are all built from the same stuff.
 
SLATE: FROM TEMPLATES TO THE ATOMIC
 
Dan Mall: It's kind of like the pilot for a TV show. The point of the pilot is just test out a concept.
 
SLATE: EPISODE 3. PILOT PROJECTS. TECHNICAL FEASIBILITY. ATOMIC DESIGN. TECHNICAL INDEPENDENCE. 
 
Brad Frost: Buttons, and form fields, and images, and typography headings.
 
SLATE: EPISODE 3. PILOT SCOPE. STYLE GUIDES. AGNOSTIC DESIGN SYSTEMS. 
 
Dan Mall: Trying to design a kit of Legos, and going, well, I guess we have to have wheels in it. But if you're never going to build a car, you don't need to wheels in that kit.
 
Brad Frost: We're able to apply the same process that happens in the natural world to our user interfaces. Hence, atomic design.
 
Josh Clark: Obviously in a perfect world, you would snap your fingers and everything would be—tah dah!

Watch design system experts Brad Frost, Dan Mall, and Josh Clark discuss the early decisions that lead to successful design systems. Learn the criteria for choosing a pilot, and see how atomic design principles help teams design better at scale.

There’s only one “right” way to go about building a design system, and that’s building the one that’s right for you. One that aligns with your products and design practices, even as they evolve.
 
In this episode, Brad Frost, Dan Mall, and Josh Clark dig into the early decisions you need to make in order to build a long-lasting design system that cuts down on operational overhead at scale. The discussion covers the following best practices:
 
<ul><li>Using objective criteria to plan and launch a pilot</li>
<li>Applying atomic design principles</li>
<li>Safeguarding against changing development environments</li></ul>

Episode 3 - Starting strong: applying atomic design and choosing a pilot

Brad Frost: So you might have a blog powered by WordPress, an application built in React, another one built in Vue, another one built in Angular, you have native software in the mix, so iOS and Android. Your users don't care about any of that stuff, right? They don't care where this content was generated from or which framework was used to build which thing.
 
The design system itself needs to be sort of bigger than any one implementation of a technology. Frameworks come and go, it's like summer fashion, fall fashion, spring fashion. Next year there will be some new GitHub repository with more stars and whatever and everyone will be chasing that. And if you sort of put all of your eggs in that one basket, all of a sudden that design system isn't going to be able to travel to the new hotness that's right around the corner.
 
MAIN TITLE: DESIGN SYSTEMS—MASTERING DESIGN AT SCALE 
 
Dan Mall: I think the value of pilots for a design system is kind of like the value for a pilot for a TV show, right? It's like before you know that the audience is going to resonate with this particular show, you do a pilot. And the point of the pilot is just to test out a concept. You don't do the whole show, you just film one episode and you see how people react to the characters and you see how people react to the storyline and the general premise of the show, and if that goes well, the network is usually like, "All right, we'll produce more episodes of the show."
 
SECTION TITLE: PILOT PROJECTS 
 
Dan Mall: I think pilots for a design system should have that same kind of goal and have that same idea to them where you don't need to build a whole thing to see if this is worth having in your suite of products. You just need to build a small thing to go, "All right, can we use this actually in our design system?" Having a pilot that is small in nature is a really important thing to be able to feed your design system.
 
Josh Clark: I love your comparison to a pilot of a TV show because a lot of times also, you have this much-loved show and you go back and you watch the original episode and you don't even recognize it. You're like, "Oh my gosh, this is such a shallow thing." I think that that's an important thing to know too, is you don't have to get it complete or perfect right off the bat. In fact, you just want sort of something to start and know that it's going to grow from there, and then using that as a foundation to build your next project. And so it's sort of both design system and product evolve together. I'm contributing my work to this design system of which applications and websites are individual instances of it. I think that that sort of changes the way that you think of it.
 
There's this really productive, virtuous cycle between product and design system where really it's a single system is the way to think of it, where you are building product and you're extracting useful things for reuse out of into the design system.
 
Dan Mall:
 
I think there's a good cadence that you get into, too. If you do the first couple right, you get some momentum that you're building of pilots. And I think there's the way to choose a right pilot, there's a sweet spot. I also think there's criteria for making a good pilot project, too. I've got seven criteria for that in particular. And you can even create a scorecard of these criteria.
 
It's one thing for the CEO to say, "Well, I think this has great market potential, so we should do this as a pilot," but it scores really low on all the other categories. So the first thing is mixing all the categories together. It's got to do all of these things really well, and then you can evaluate on the same objective scale from project to project. And if you do that for a number of them, you could say, "Well, listen, we're just going to take the top three highest scorers, and those are the first three that we're going to use as pilots for our design system."
 
The first thing on your scorecard is how much of this can be commonly used? That's common components, common flow. So for example, a header is probably something you're going to use on maybe every website that you make. So a header or a footer or cards, that's usually where people start on design systems and pilot projects.
 
The second thing, now, gets a little bit more nuanced. The second thing is, well, how can we have highly-valued components or patterns? Maybe that's only use on one or two products, but you get a lot of mileage out of it. An example of that is a date picker or a calendar widget or something like that. You may only use that on a handful of products, but that goes a long way that if you already have that in the can, you can reuse that on other products. So that's the second criteria.
 
The third criteria is technical feasibility. How possible is it on the technical side to actually accomplish this project? Is it going to require a large refactor to be able to do this? Are you dependent on some technology, you've got to build this augmented reality something to be able to do this pilot? Things like that make this less likely of a good pilot.
 
The fourth thing I think is a really important one, which is the available champion. Design systems are more than just components and patterns and principles, they're really about the people. The people who can champion the stuff. So a good pilot project will usually have a good champion that will, at the end of the pilot, hold this up to the rest of the company and say, "See how we made a really great thing," and actually be kind of an evangelist for it. Projects that have really good champions or a good product manager behind them, those are usually good ones for pilot projects.
 
The next one is scope. A good pilot will take maybe a couple of weeks to do. If you're trying to bite of a project that's going to be months long or years long, you're not really going to see the results fast enough to fold into your design system. So just knowing that something is possible within a short time frame makes for a good pilot project.
 
The next category is technical independence, and this kind of related to technical feasibility, too, but technical independence is about how separate can this project be? You certainly want to be wired into your tech stack, but you don't want to be mired down by the tech stack in order to do this. So if you're, for example, redoing your whole CMS platform, that might not be a good pilot project to be able to do this because there's just so much dependence in other parts of the system.
 
The last criteria is, and maybe this is the most important one, is marketing potential. A good pilot project will be something that other people can look at across the organization and go, "Wow, we want to do something like that, too." So that might be the most visible project at your company, that might be something where the CEO's pet project, it might be something that the favored team in the company's actually working on, but something that actually plays well in maybe marketing videos or something like that makes for a good pilot project.
 
SECTION TITLE: STYLE GUIDES 
 
Brad Frost: It can be overwhelming how many different facets there are to a design system initiative. You have to establish design principles, you need to talk about code conventions, you have to talk about tools and design tokens and components and oh, there's so many moving parts. So we've actually found sometimes it's helpful to just stand up a style guide website from day one of the project, even if it looks like an empty shell with no styling or anything like that, no content. But it's there, and that becomes an opportunity for the team right from day one to start collecting these assets and collecting these things that are floating around the organization and starting to sort of corral them all under the roof of the style guide website.
 
And this helps provide a bit of a roadmap for the design team. As you go through your design system initiative, you're able to poke around your in-progress style guide website and see which aspects of the style guide website are not populated yet. The style guide website can serve as the single source of truth for the design system. It is the thing that you could hold up to the rest of your organization, and even the world, as a way of saying, "Here's how we do things at this organization." It crucially provides a watering hole for all disciplines to come to and get value from. Designers should be able to come to the style guide website and get crucial information about how to design better products. Developers should be able to go to the style guide website and get an understanding of how to utilize certain components and what code conventions they should follow.
 
Product owners can come to the style guide website to have an understanding of what materials they have to work with and what conventions and guidelines they should be following in their own products. A style guide website really does bring everyone together under one roof. It helps break down barriers between discipline silos, product silos, and platform silos.
 
SECTION TITLE: WORKSHOP/STOREFRONT
 
One useful analogy we've found for talking about design system tools is this concept of the workshop and the storefront. My wife is a jewelry designer and a metalsmith, and she has a workshop environment that allows her to be creative and productive. It gives her an environment where she's able to try things, prototype things, burn things, saw things out, get messy, get dirty, experiment, and ultimately come out that process with a new, finished piece. But she also has a storefront environment that allows her to showcase her finished work and also surround it with contextual information that helps potential customers purchase her goods.
 
What does this have to do with design systems? Well, we sort of have a workshop environment and a storefront environment as well. Our workshop environment should be designed for the teams building the design system to be creative and productive, to prototype things, to stress-test things, to fail at things, and iterate over things in order to arrive at sturdy, resilient, robust, assessable, performant UI components.
 
We also need a home for those finished components to live, and that takes the form of a style guide website. The style guide websites are the storefront environments for our design systems. It is the happy home for all of the ingredients that are contained within your design system. You'll see this on sites like lightningdesignsystem.com or carbondesignsystem.com or material.io. So it's in this storefront environment that we're able to showcase and explain the design principles that govern the system. The high-level UX in design guidelines all the way through low-level components like cards and buttons and accordions and things like that. And it's in this environment that we're able to sort of write documentation and show these components in action and show the code and show different resources for those components. This, quite literally, is the instruction manual for how to use these components in products.
 
SECTION TITLE: TECH AGNOSTIC 
 
How do we actually create a technology agnostic design system that also is simultaneously integrated with the tools and technologies that are in play at your organization? It's hard work as it turns out. In our work together, we like to see the sort of canonical technology agnostic design system. In the world of the web, has sort of HTML, CSS, and JavaScript, and a lightweight sort of presentational JavaScript. After all, that's the stuff that gets rendered in the browser. That's the stuff that gets sent down the pipes to actual users.
 
But then from there, what actually sort of renders that markup and those styles and that JavaScript could differ wildly between different products, so some subset of an organization's products might be built on Angular, and another subset might be built on React, and another might be built on Drupal, which uses the Twig templating engine to sort of render its markup. So the idea is that you sort of take this canonical agnostic design system, and then sort of a create a technology-specific flavor of that design system. And then sort of from there, individual applications can take that technology-specific flavor of the design system and plug that into their code base.
 
Then, what ends up happening is that if a change gets made to the system, the change gets made at the top level. So let's say the accordion is broken and none of the accordion panels can open. Well, fix that bug at the highest, most sort of agnostic level, and then sort of make sure that every technology-specific flavor of that gets that fix as well, and then individual applications can sort of pull down the latest and greatest changes.
 
With managing this whole ecosystem requires a great deal of discipline, it means establishing proper workflows and processes around sort of deploying the design system and making changes to the design system and accepting contributions and just sort of managing all the moving parts. And it sounds scary, but really once you establish those conventions and once you codify those processes, it becomes manageable to sort of not just create one great looking design system in the abstract, but also to sort of feed that design system into very real and specific technology implementations, which can then power real products.
 
SECTION TITLE: ATOMIC DESIGN 
 
We created atomic design, which is a methodology for creating thoughtful, deliberate, hierarchical design systems. What atomic design is, is it's a way to step through how our smallest atomic units of a UI is able to sort of build a final product. Atomic design consists of five discrete stages that all happen concurrently. Atoms, molecules, organisms, templates, and pages.
 
Our bodies, this floor, this stool, the planets, the stars, are all sort of built from the same stuff. And actually, so it goes in our UI's. At the end of the day, if you were to blow up any UI, you're going to end up with things like buttons and form fields and images and typography headings and things like that.
 
We're able to sort of apply the same process that happens in the natural world to our user interfaces, hence atomic design. So we have atoms. What are the atomic elements of our UI's? Well, we have things like labels, inputs, buttons, images, headings, things like that. These are things that can't be broken down any further without ceasing to be useful. These are the basic building blocks of our UI's. The problem with atoms, though, is that they're not technically useful on their own. It's whenever we move up a level to molecules where we start to see these things come to life.
 
When we get to the molecule stage, we take a group of atoms, say a label, an input, and a button, and actually put those things together to form sort of a single-field form, like a site search or a newsletter signup form. Now, suddenly, these atoms have meaning. They have utility. This label atom now describes this input atom. Now clicking this button will submit that form. So now we have this nice little encapsulated component that we could drop in anywhere we need this sort of single field form. But again, that's also not terribly useful just as its own sort of little units. And now we can, at the organism level, take these molecules, say like a search form molecule, and plug that into a bigger, more complex component.
 
So a header organism, for instance, you might find on any website. You might see a logo atom, a primary navigation molecule, a search form molecule, all sort of locked up in this discrete chunk of interface. This complex component is what I call an organism. So an organism might be comprised of a bunch of different things like a logo, like a navigation, like a form, or it could be a grid of cards. So it's the same card molecule repeated over and over and over again to form this sort of discrete chunk of UI.
 
The big difference between molecules and organisms is that molecules are simple components and organisms are more complex components. That's really the distinction, but it really sort of lends itself to thinking about UI's as this sort of infinitely nested set of components, almost sort of like Russian nesting dolls. These little things are included in bigger things which are included in even bigger things.
 
So then from there we move up to templates, and what templates do is sort of take these organisms and other molecules and combine them together into a final screen. So here's where we're able to sort of start seeing the UI come together to form a cohesive whole. But it's important to point out that at the template level what we're really doing is establishing the sort of template skeletal system. So we're not focused on the specific content that's going to be poured in to this UI, but rather just sort of scaffolding out the basic shape of the UI. And it's here where we're able to sort of see these patterns start to interplay with one another in the context of a page layout.
 
And then lastly, the fifth and most concrete step of atomic design is the page level. So it's at the page level where we take our template and we pour in real representative content from a real product into that template to bring it to life. Now, this step is hugely important because this is what your end users are going to see and interact with, but it's also here where we're able to sort of see all of the components, the smaller components, come together to form a cohesive whole. It's here where we're able to test the resiliency of these components. 
 
By building the design system using the atomic design methodology, it allows teams to sort of thoughtfully set aside components as you need them, and by sort of building these things and building the actual pilot projects and real product screens under the same roof as the actual components, you're more prone to sort of build for a reuse and you're able to sort of reach for these existing components rather than being tempted to sort of, yet again, build a new version of a card or a new version of a block of some other sort.

A design system is transformational for product teams. Shared patterns and best practices mean designers, developers, copywriters, and product owners can focus on tackling work that truly benefits the business instead of hunting down the latest sticker sheet and endlessly reworking screen design comps. In this episode, Brad Frost, Dan Mall, and Josh Clark explain [&hellip;]

A design system is transformational for product teams. Shared patterns and best practices mean designers, developers, copywriters, and product owners can focus on tackling work that truly benefits the business instead of hunting down the latest sticker sheet and endlessly reworking screen design comps.
 
In this episode, Brad Frost, Dan Mall, and Josh Clark explain how to make this evolutionary leap by treating your design system as a product, with deep empathy for its users. Learn how to make your design system a delight to use for every member of the product team so that good design practices are both “the right thing to do” and “the easiest thing to do.”

Episode 4 - New roles and processes for a thriving design system

Dan Mall: I think design system is a thing that not one discipline could use on their own. If a developer can only use a design system by themselves, they don't need anybody else, perhaps it's not as collaborative as it should be. If a designer can use a design system on their own, maybe it's not as collaborative as it should be. So, I think any good design system will need everybody on it to be able to do their best work.
 
DESIGN SYSTEMS: MASTERING DESIGN AT SCALE 
 
Josh Clark: The very first stage, even almost ahead of or during initial research, is kinda retail politics, of really getting everybody on board whether you're a small organization, maybe a 10 person start-up, to a sprawling enterprise of thousands. In order to make this thing a success, you really have to get allies and champions throughout the organization to carry this through and carry the message through, so that it really does that root. 
 
There's also this, the enormous research effort that goes into this of understanding how will it be used. How should it be used? How can the design system help? There's a real level of humility that goes into building a great design system because it's not gonna work if it is something that it imposed on people. It can, but it's a really slow going thing. 
 
The way that a design system works best and takes root best is when you build it in a way that the right thing to do is also the easiest thing to do. Really what I'm talking about from a product owner point of view, and this is true of any product, is let's make sure we're building the right thing for this organization. 
 
DESIGNING FOR TEAMS 
 
Dan Mall: As designers, one thing that we're supposed to do on every project and every product that we make is to have empathy for the customers and the users using it. What's really great about a design system and what I see that’ss so exciting when I work with design teams is that the empathy for the users that they're supposed to have is for actually developers, product people, UX people, all the other people on the team. 
 
One thing that generally comes with designers in a lot of organizations, design is at the top of the food chain. Designers make comps and everybody else has to build what those comps say. This process of creating a design system is really about thinking about, well, what is everyone else's experience? What do they need in the tooling? And we have to design those things as designers. 
 
So, part of what I love seeing is when designers go, "oh, that's how you build stuff, developer? I didn't even know that. You actually put things in tokens. Well, actually I could take those tokens over and free up your job." So, there's this interesting thing that happens with design systems and designers where in the process of designing the thing, it actually builds more empathy for the whole team. 
 
I think that's part of the role and the responsibility of the designer in thinking about and creating design systems is: what is everybody else's job on this team to make products, and how do I design a system that makes it easier for them to do that? 
 
Then on top of that, there's all the stuff that designers are already good at. Use this purple, don't use this purple. Don't use these other colors, or use these type bases, don't use these. Use these like that. 
 
I think a good design system has those kinds of rules that ultimately should come from designers who are going, “let me think about what the best experience is gonna look like and let me make the right thing to do the easiest thing to do by making it hard for people to do the wrong thing.” 
 
If they shouldn't be using red, let's just not even have red in the design system at all. Let's limit that palette. I think one of the things for a designer to be thinking about is, what's that small palette that everybody else can use? What are the components? What are the colors? What are the typefaces? How do we create a system that scales, that's not too big and not too small, but just the right size for everyone to be able to do their jobs? 
 
TOOLING FOR TEAMS 
 
Dan Mall: One of the things that's really great is that because we're making tooling for each other, a design system is tooling for each other, we can actually innovate in the kind of tooling that we make for each other as part of the system that we use and deploy for our own organization. That's something that helps everyone on the team. The more we work closely together, the more we can actually come up with ideas like that. 
 
Josh Clark: I think an important theme there is that effectively there are a bunch of different interfaces through a design system. The most public one is the style guide or reference site. Here's the website that brings it all together and puts it in one place. 
 
But then there's the individual tool. It's, like, great, if I am a designer who's working in InVision Studio or in Sketch or in whatever tool I want, how does the design system through design tokens, perhaps using InVision Design System Manager or other token systems, essentially make it so that the design system just arrives in the tool that I use or in the coding environment that I use, so that the Sass variables automatically pick up the design system? 
 
Again the right thing to do is the easy thing to do. It's part of my workflow. I don't have to go someplace separate. I don't have to go out and download a PDF that is two years old and perhaps no longer in sync, because the latest is in my tool set using design tokens distributed through, for example, InVision Design System Manager. 
 
Dan Mall: One of the things that we often do when we're working together, Brad, as designer and developer, is that you're often like, "I'm gonna set up a placeholder for you, but I don't really need to care about what this Hex code actually is." That's something that me as a designer, it's important to me and it's also something that I should be able to tweak to my heart's content. 
 
So, the thing that I shouldn’t be doing with you is sitting over your shoulder, hovering art director, "hey, can we change that Hex color" or “I'll send you a bunch of red lines.” It's just a pain in the butt for me to make and a pain in the butt for you to receive and implement. Instead, if you can set up some placeholders and then I can go and tweak, say tokens for example, in my own way, now we can work in parallel and it's something that I'm helping you in your job, you're helping me in my job and that's another example of that collaboration. 
 
EYES ON THE PRIZE 
 
Brad Frost: I think it's really important to understand that everyone's eyes should be on the prize. What is that prize? The prize is a suite of living, breathing components that could then be deployed to other software applications to build other products. We need to make sure that this design system, the actual living breathing button component and the card component and data table and header and footer, and all of that, could actually come together and actually assemble real living breathing product screens, product UIs that are able to serve real product needs. A design system can't just exist as a static UI kit hanging out in Sketch. It's not to say that that's never valuable, but at the same time, you can't build products out of that. 
 
So, one of the things that we do very often in our workflow is make sure that we're focusing the effort on building working software. I want more eyes on my code because you, as a UX designer and product designer, and you as a visual designer, have way better perspective than me as the person actually building out these components and widgets. So, I need to make sure that UX best practices and visual best practices make their way into the actual living breathing component because that is the thing that those product teams are going to grab and plug into their respective code bases. 
 
A NEW PROCESS 
 
Josh Clark: As an interaction designer and a product designer, my work has changed a lot in that it used to be I would, for every screen, every page, or every view of an application, I would build a really detailed wireframe with lots of annotations that was itself its own product that then I would hand over to a designer, who builds a comp, who then details that, often with similar or different annotations, and then hands it over to the developer. 
 
A design system helps to short circuit a lot of that stuff. Now, I don't do wireframes anymore. I just do text. It's a simple text list. It starts with, what is the job of this page? This page has to do four different things for the business and maybe three different things for the customer. These are the jobs this is gonna do. I've got priorities around that and then it's march down the page and say, here's a section that needs to do this. Oh yeah, we've got a component that does this. 
 
So that actually by the end of it, I've just got a simple text list that I can discuss with both of you. This isn't even a handoff. It's like, I'm thinking that we can start with, well, obviously we'll have a header and we'll have a hero element. Then we'll have a set of cards that are specific to do this job. Then this sign-up thing because we need to do this job. 
 
Then it's really a discussion, I don't need to do all this stuff because it's already documented in the design system. We have a common set of vocabulary and it seems like we can just march down and do this thing, in order to accomplish these goals, and what do you guys think? What's new that we need to build in addition to that existing set? How does that change your work? 
 
Dan Mall: It changes it completely because one of the things that we find all the time, and this is both scary and exciting, is that oftentimes I don't even need to be part of the mix. 
 
THE DESIGNER'S NEW ROLE 
 
You can work right with the developer, the interaction designer and the developer working directly to say, “I can build that and scaffold that out with the design system components that we've already got in the can." 
 
You don't even need the designer for that because those components are already designed. They've got CSS. They've got JavaScript. They've got the interaction there. In one sense, that's really scary. Well, you just skipped me completely. 
 
Josh Clark: You're out of a job. 
 
Dan Mall: I'm out of a job. But wait, what I can do now is apply for a new job and that new job is all the stuff that I wanted to do that I never get time to do. Let me make a motion comp for how that component should animate better. Let me make some custom illustrations that will go on the top of this page to give it some character or some flavor. Let me art direct this a little bit more. Let me do a photo shoot so that we can go and plug in really great custom photos. All that stuff that I never got to do because I had to make every comp that you diagrammed and that you've got to build, I don't have to do that stuff anymore. 
 
So, my job is now focused on critiquing the final work. You guys put it together. You come up with the first draft. We'll look at it all together in the browser and I go, "Well, it'd be nice to have a little bit more space here, or it'd be nice to combine these two, or maybe swap out this component for this component." 
 
So, my job becomes an oversight job and that's what designers are good at and trained to do, is critique and revise and do that stuff. My job is also, what are the new problems to figure out. A new interaction that we haven't considered. A new type of component we might need. So my job is focused on the new. Isn't that exciting for designers? Isn't that what designers want to do all the time, is just do the new stuff? All the old stuff, you guys can take care of that. I actually got the better job. 
 
WHERE’S THE WORK?
 
Josh Clark: When we built the design system for Exxon Mobile, an engineer told us, “I was in a whiteboard session. We were figuring out what an application should do. During that session, I used the design system to create a working prototype of the thing.” How exciting is that, to go from idea to prototype in the same meeting that normally would be kicking off a three week process? 
 
Brad Frost: That's right. 
 
Josh Clark: But wait a second, we're talking about no more wireframes, no more comps. All of the production, or at least the production of the components that we've already created, is suddenly in the browser and working software. This changes our process a lot, but it also is like all of a sudden we have stuff happening, but now doesn't that mean that all of this is on your shoulders? 
 
Brad Frost: It's important to stress that a design system is not a panacea that we're just going to plug in and just magically like, "oh, wow, everything is just perfect now and no one has to do any thinking anymore." 
 
It's just getting that first draft into the browser allows us to understand what we all respectively have to do in order to bring this design home. The cool thing is, is that the byproduct of all of that thinking can then get fed back into the system. So every time you use this system is an opportunity to bolster and enhance and improve and evolve the system, as well.
 
Josh Clark: It can sound like, well, wait a second, designers aren't designing anymore. It's all just developers doing cut-and-paste from this. It's like, well, this sounds like a whole bunch of cookie cutter websites. Where is the work anymore? 
 
It's really, no, you get a foundation for free, but then you have lots of opportunity to extend, improve, and customize individual components to make it tuned perfectly for the job that needs to be done. The risk is that you can look at this kit of parts and think, "I am only allowed to use this kit of parts," which can sometimes mean square peg, round hole. I'm using the wrong thing because it's the thing that I've got available. 
 
Really there's a thing of, and it takes time to get used to, I'm gonna use these pieces to design my webpage, my application, what have you. I'm gonna use these pieces, but I also understand that I have freedom to create new ones. 
 
Then I think there is a little bit more of a traditional role, where it's like I am doing some whiteboard sketching and wireframing with the designer or with the developer to create something new.

Josh Clark, Dan Mall, and Brad Frost explain how to move from a single-product pilot to a living design system that supports every team, product, and platform.

You’ve proven your design system as a single-product pilot. Now it’s time to put it to work as a living, evolving source of truth that supports your organization’s many teams, products, and platforms.
 
In this episode, Brad Frost, Dan Mall, and Josh Clark share what they’ve learned from helping design teams all over the world make the critical shift from pilot to scale.
 
Get techniques for curating your design system as it grows, and learn what goes in, what doesn’t, and why. Hear how to make sure your design system enforces common usability across different products that each have their own unique look and feel. Finally, learn how design tokens keep code in sync as design standards change and help your team focus less on coordination and more on building experiences your users love.

Episode 5 - Proven strategies for scaling your design system

Episode 5 - Proven strategies for scaling your design system
 
Josh Clark: Like a lot of companies, we started with a single brand on a single platform and a single product. And that was already enough work to sort of try to figure out how that goes.
 
Over time, as we've seen this approach be adopted by larger and larger companies with more and more platforms or products or brands, sometimes all of those dimensions at once, you're seeing a design system used in all kinds of different ways and places. And that adds enormous complexity to the planning of this, as well as to the use of it.
 
Josh Clark: So Brad, a question that I hear a lot is: does every component in every project need to be in the design system in the first place? How do you decide what goes into the design system or does everything go in?
 
SPECIAL SNOWFLAKES 
 
Brad Frost: Yeah, sometimes there are special use cases that are product-specific. Maybe that's the self-contained mortgage calculator widget or something like that that only makes sense to one product. It's fine to go ahead and build that as a one-off component, and each product might have one or two or maybe even a handful of special use-case components that only live with that product.
 
But the trick is to be able to audit that stuff and manage that stuff so that things don't get out of control because very quickly it can be, "oh, well our product also needs this" or "oh, we just need to make this one little tweak to this form component" or "oh, we just need to do this" and the next thing you know, you're back to square one where each individual product is its own snowflake.
 
And I think maybe the distinction is, if you find yourself tweaking existing components, so it's like "oh, I just want these form labels to be bold rather than normal font weight" or "I just need to increase the padding of these table rows just a little bit more," I think that those are situations that we want to avoid, right? We want to reduce the slow creep away from our visual standards, right?
 
And if a change should be made, if there's a rationale for why the team is trying to make that change, then they should coordinate with the design system to make sure that "hey, we actually need these things to be a bit more prominent or a bit more chunky and here's the rationale for them" and collectively together you can come up with a variation of a component that then serves that use case really, really well. So, that's a way of doing that with the grain of the system rather than detracting from the system.
 
But then there are other use cases that, whether it's that mortgage calculator or that really complex bit that only makes sense for one product, sure, there's going to be times where the team that's working on that product can go ahead and put their head down and build that component as a one-off.
 
But one thing that I've been advocating is for teams to build those one-off components and place them into the same place in their product code bases. So maybe you have a folder called "one-offs,” or something like that, across all of your different products. And what this does is standardizes all of those unique special snowflake components.
 
So, then the design system team can come around and audit "oh, how many one-off components do you have" and, like, "oh, maybe this looks like a good candidate to extract into the system" or "oh, this one product is using it and this other team is asking for it, so maybe we can elevate that out into the system." So, you're able to manage these one-offs in a way that still works with the grain of the design system process.
 
INTRODUCING VARIATIONS 
 
Brad Frost: The workflow that we've tended to do is through the lens of real projects. We plug in the components as-is, as it currently lives in the design system, and see how it holds up.
 
If it needs some massaging, or we find that it's lacking some behavior, some style, then that might be an opportunity to, not necessarily tweak the core component, but to create a stylistic variation of it.
 
So let's say we create a data table pattern and we plug in all this data inside of it through the lens of one of our projects. And it's like, wow, this looks like a lot of data. This is really hard to parse, and it would actually be really great if we had some sort of zebra-stripe patterns, so every alternating row in this data table has la light-gray background, for instance. The current design system doesn't support that yet, so what can we do?
 
Well, let's create a variation of that pattern so we can add a class onto our data table, a pattern that says “dash-dash-striped” or something like that. Now we have this extra option if we need it. So it adds another tool to the toolkit or adds a new feature of an existing component that therefore makes it more flexible and robust and can travel to more places.
 
ENABLING CHANGE 
 
Brad Frost: If something isn't working, then you shouldn't have to square-peg-round-hole it and force this component to do a job that it was never supposed to do. Rather think: how can this system include something else that helps solve this problem in a better way? And what you're able to do is codify your contribution process and the process for changing a component or adding a component and to bake that process into your style guide before the system even exists, before it even hits an MVP state or a 1.0 state.
 
You're able to say "okay, what does it look like if we need a new component? Who does that work? What if something similar already exists?"
 
So, that means that even the first users of the design system are able to, if they get stuck or if they're finding things not doing exactly what they need them to do, they know the path forward for making modifications or improvements or additions to the system.
 
DESIGNING ACROSS BRANDS 
 
Josh Clark: Often you'll see something where it's, like, well, great. We have several brands that we need to address underneath our umbrella. We've seen that, for example, in publishing companies that have different media titles.
 
So, there could be a high-end fashion magazine, for example, and over here some sort of political magazine. Very different brand or feel. And you might look at that, particularly from the inside if you're attached to one of those brands, as being, like, there is no way this same design system could serve both those.
 
Yet when you go to their function of what they do underneath the hood, they are both reading experiences, media experiences that have similar models of navigation. So you can create models that serve those functional uses and then create brand themes on top of those to address those individual brands.
 
A design system can serve multiple brands very well in the same way they can serve multiple products, even if they have a different look and feel.
 
Dan Mall: When I think about different brands that exist in a design system, they should look like a family. Some of them can be siblings, some of them can be cousins, but they should be recognizable as part of the same family.
 
So one of the ways that designers can think about how to do that well, is to think about, well, what are the commonalities? What are the things that should exist across different products that we make, and also what are the things that should be different?
 
That's a great way to think about themes. Every product in your design system could be a theme or be its own theme or adopt from a theme or inherit parts of a theme.
 
So, a lot of times we'll see an organization that has the need to make marketing products, right? Things that look really beautiful, really gorgeous and polished and spaced out and open and airy. But then at the same time, might have very dense apps that process a lot of data and things that are internal to a team or internal to a particular customer or on the enterprise side.
 
That doesn't mean that both of those things can't exist in the same design system, it just means maybe you need two different themes. Maybe you need a dense theme or maybe you need a marketing theme. And you can name the themes whatever you want. Some teams have a blue theme and a white theme, that's fine too.
 
So they can be conceptual themes, they can be visual themes. I think part of a designer's job is to go, alright, what are the things that should be common across those?
 
We all have the same eye color for example, and what are the things that could be different? Some of us have beards and some of us don't. So that's one way to think about, “what are the commonalities across all of the different themes and the products that could inherit from those themes?”
 
DESIGNING ACROSS PLATFORMS 
 
Josh Clark: I think a trickier thing to handle, frankly, is how to build a design system that works across platforms, and here I mean a design system that will work for the web, but also for iOS, and also for Android.
 
There are a few different layers that you have to think of there. As the umbrella above all of this, you have the brand and the visual language of the brand. But then you also have this platform language where things work a little bit differently on iOS versus Android versus the web. And you have to respect those native conventions.
 
Brad Frost: So, how you go about doing that? There's a bunch of different ways. What we've found is, it's helpful to create a technology-specific flavor of the design system. Let's say the React flavor of the design system, and then individual applications that are using React to build the front end of their applications can then consume the React flavor of the design system as a project dependency.
 
This allows teams to grab that code and start building, using the design system's components, without having to manually copy and paste things over. So there is still some connection between the system and the products.
 
Josh Clark: So when you're thinking about a design system that goes across all these, first you have to create a consistent visual language and really nurture that, really work with the marketing and brand-focus to make sure that that reflects that, and then marry that to the individual platforms.
 
A design language can be expressed in many ways, but at its core are these simple brand attributes. Those can be expressed as design tokens.
 
DESIGN TOKENS 
 
Brad Frost: Design tokens are implementation-agnostic design properties. That might sound a little esoteric, but that's what they are.
 
So any developer will know what a variable is, right? You say Color Brand Red. So if you're Target, you have Color Brand Red is Target Red. Or you might have a specific border radius value that you use for all of your digital products. Or you might have a specific font face you use for all of your products.
 
All of these design properties are what help build a brand. You can sort of refer to them as subatomic properties, right? These are the properties that ultimately make up your user interface.
 
So InVision Design System Manager is a tool for managing design tokens and integrating them into your team's workflow and tools. It's really exciting because it allows designers to work in the tools that they're comfortable with, tools like InVision Studio or Sketch, and define the brand's color palette, neutral color palette, font styles, and things like that, and beam those up to the Cloud.
 
So that means that if the Brand Green changes, the designer can make that change, sync that up to the Cloud, and then as a developer, all I have to do is pull that change down, which becomes a part of my normal dev build process, and I will receive that updated green.
 
This is really really powerful. This gets designers closer to working in the actual finished software product, but it also gives developers the power to control those variables and to thoughtfully integrate them into their code base.
 
Design tokens provide a single source of truth for these crucial design properties that designers and developers can change in one canonical place and then have those changes propagate out anywhere those design tokens are utilized.
 
Josh Clark: All these things are ways that basically want to say that the job of the design system is to reach out, curate, and pull together and collect all of the different guidelines and conventions that are used across every discipline, across every channel, across every brand, and have it in one place so it's really easy to find and reach for, and hopefully to put even into the path of my workflow so it's not some reference off to the side.

Josh Clark, Dan Mall, and Brad Frost share operational models for long-term design system success. Learn how to build a cross-disciplinary team dedicated to design system management.

The best design systems are never done. As living digital products, they need to adapt alongside the people and products they represent.
 
In this episode, Brad Frost, Dan Mall, and Josh Clark lay out the path to long-term design system success. Learn best practices from innovators like Salesforce, IBM, and Etsy and organizational models from industry experts like Jina Anne and Nathan Curtis.
 
Hear how these influential teams and design leaders approach tooling and governing principles, and get proven techniques for keeping your design system healthy while it evolves.

Episode 6 - Maintaining and Evolving Your Design System

Episode 6 - Maintaining and Evolving Your Design System
 
Josh Clark: It's important for a design system, and really any product, to have a set of guiding principles that will govern the decisions that the team is gonna make. Why is this product the way that it is? Why are we gonna make the decisions that we're gonna make? A big way that we do that is by creating design principles for the project. Design principles are things that emerge from a combination of the business goals, the user promises that we make—what do we need to do for users, what do we need to do for the business? You kinda marry those into principles that say something about what the product is or does. 
 
DESIGN SYSTEMS: MASTERING DESIGN AT SCALE
 
Josh Clark: The importance of design principles is to actually help people make a decision when there are two viable paths. A design principle like “clean and simple” is probably not gonna be very useful, because no one wants messy and complicated as their by-word. Instead, we wanna have some principles that help to make decisions when you're at a fork in the road, where a reasonable person could go in one direction or another. So, design principles become these things that are rallying cries in a sense, reminders of what is in our path and help us to make decisions when there are competing directions that we might go in.
 
GOVERNANCE
 
Brad Frost: We put all of this work into this thoughtful component driven system and there's all this great thinking baked into this thing, and nobody uses it or it becomes outdated. The whole thing, all of that effort, just gets thrown in the trash can. Because, as soon as all of that knowledge locked up in that style guide website ceases to reflect the reality of how your products actually get things done, it ceases to be useful. 
 
We've encountered many organizations that have a graveyard of design systems littered throughout their history, sometimes going back almost a decade. Oh yeah, here's this first pattern library effort and here's where we tried it again and here's where we tried it again. So, governing a system is probably the most critical piece to get right.
 
Josh Clark: When we talk about governing a system and what is design system governance, really what we're talking about is - how do we make sure that it keeps up with the needs of product and likewise, as the design system improves, how do we roll those changes into product? I guess then, let's get down to brass tacks. How do you, after you've built a system with a few pilot projects, start to build additional projects with it and roll those changes back into the design system and vice versa?
 
Dan Mall: I think maybe one of the obvious things that needs to be said is that if pilot projects are what got you to a design system, maybe pilot projects will keep that design system running. I think that, again, the design system serves products and it's supposed to be a product that helps you make products. So, keep making products. But, don't keep making products in isolation. Keep making products with an eye toward - how does this affect our design system? Does it change it? Does it edit it? Does it modify it? Do we need to remove things from it that we don't need to support? Do we need to add things to it that we now do need to support? 
 
One thing that's a really actionable step is keep making products, but maybe build into your process one or two checkpoints, maybe in the middle of your project, to go - are we using all the things we need to use from the design system? And then, at the end of that process, going okay, what can we actually take out of this product, harvest back into the design system either by adding it or by changing something that's already there?
 
Josh Clark: Who's doing that work of auditing products and harvesting them for design system improvements or additions?
 
Dan Mall: There's a couple of models for that, and there's lots of good writing on this. Gina-Anne has written some really great stuff. Nathan Curtis has written some really great stuff about this. 
 
I'll start with the first one and then maybe you guys can fill out. Maybe the most obvious one is your design system might not get a lot of love when it's first at your company. Maybe you've gotten buy-in from everybody but then everybody's forgotten about it while you're building it. Typically what happens is there's one person and it's just that person's baby. That could be a product director or it could just be one fledgling designer or developer that's just really passionate about this stuff. And, that's cool. That's great. At least somebody's passionate about it. 
 
What we find is very rarely is that person actually able to sustain a design system, one person having oversight of the design system, because if all things go well, if you've done all these things, they will go well, you very quickly get inundated with lots of emails. People going - how do I use this or how do I maintain it or how do I update it? So, one person is a good start, but it's not a sustainable model for one person to have oversight of the design system. What else? What are some other ways to do it?
 
Brad Frost: I think that another team model that can work well at an organization is the “centralized” team model. You have a dedicated product team that is responsible for making, grooming, maintaining, and evolving the system. That kind of team structure has the “systems” view. All of those people are thinking about the entirety of their product ecosystem at the organization. 
 
The risk with that model though is that it can lose that “on the ground” perspective, that individual “product need” perspective. 
 
There's another team model, which is the “federated” team model. This is where you don't have a centralized team doing all of that production work but rather representatives that work on different products scattered across the whole organization. You might have a front-end developer working on this product and a designer working on this other product, and all of those people are representatives that are maintaining the system. 
 
The risk with that though is that product roadmaps always take priority. So, those people's attention are split between serving real product needs. As a result, the actual system, in that bird's eye perspective, is lost and the whole thing just gets swept away. 
 
Another model, and Gina talks about this, this is the model that they put in place at Salesforce whenever she was working on the Lightning design system. It's called the “cyclical” model, or the Salesforce model, which is basically a combination of a centralized team and federated members. There's close pairing that happens between those teams. You have a centralized team that's doing a lot of work, but then there's also federated members that are able to feed that “in the weeds” perspective to the design system.
 
Dan Mall: It is a diverse model, where there's representation from all around the organization. You’ve got some bird's eye view people, you’ve got some “on the ground” view of people that are making products with the design system, both makers and users. 
 
I think it's worthwhile to populate that with other people from the organization. Maybe you have people that are executives on that team and you have people that are makers doing the work as well, so you get different views of the organization too. I don't know that we've particularly seen this model, but I think it scales well too, where potentially you could even have some people who don't even work in your organization as part of an advisory board for that.
 
Brad Frost: That's exactly what the team at Etsy did. They established a design system committee that met regularly. I think it was once a month, or continues to meet, hopefully, once a month, where they have representatives from a bunch of different areas that get together. There's a committee leader, but then they also bring in different owners from different products, so you have different products represented as stakeholders in the system.
 
And then they have different platform representatives, people working on their web properties, their iOS properties, their Android properties, their email properties, all with a seat at the table. 
 
But then also, they brought in, I think this was especially clever, bringing in subject matter experts that might be working on specific products, but if you have an accessibility guru and a performance guru and a responsive design guru, each scattered across the organization, they come in as an expert and lend themselves to this committee. 
 
What you end up with is this really nice cross-section of stakeholders and experts all dedicated to growing and maintaining the system and making sure that it continues to serve all the different products and platforms successfully.
 
CULTURE
 
Josh Clark: I think one of the changes too, as we think about governance, is that there is a cultural shift of - how do we encourage people to think about we're creating together this common body of design, philosophy, and standards and interactions that we can all commonly use from which individual applications will spring.
 
Dan Mall: But, we have have seen organizations that go - that's opposite of our culture. It's not that they're opposed to it, but they're just, like, we couldn't flip a switch and then all of a sudden we've got this open-source model and culture here. So, I think it's important to say that there are steps to get to that too. We've seen all different permutations of that, where some organizations go - yeah, we can do that because we have something like that already existing here and so that folds in naturally. 
 
We've also seen - let's just first set up an email address so that people can email us if they have questions about this. That's a good first step too. We've seen groups set up Yammer Communities or intranet groups or private Facebook groups or Slack channels dedicated to the design system as a way of going - we can't really go full open-source yet because of the politics of our organization, which are very real, but we can do some semblance of that. 
 
I think that's okay, because that's a way to build up to that point, where we're starting to create that culture. You don't create culture overnight. Maybe in a year we'll get to that point, and in the meantime, we'll have open contributions via email or a forum or something like that. So, it's not all or nothing. It's definitely stages to be able to get there.
 
Josh Clark: I think one of the things that we want from a design system as we make these is for people to be enthusiastic about it. To be like, yes, I wanna use this. I recognize myself and the way that I want to do design and development in this system. The biggest way that you can get people to feel invested is to let them invest in it and to signal we are open to improvements on this.
 
Again, humility is such an important part of creating a design system. This is not something of us telling you the best way to do something. It is we are here to support you. What do you need to do your job the way that you want to do it?
 
Brad Frost: That's right. And, I think that there are, as Dan said, a number of different communication channels. Having a Slack channel that's dedicated to it and the team that is invested in making and maintaining the system, that hangs out there and is eager to answer any questions is good customer support. 
 
But also, regular state of the union meetings. Updates on the roadmap whenever you do a release. We've seen regular email campaigns, where every month the team says here's what's new to the design system and here's the MVP person that just really killed it on this product. Look at this really cool contribution that they made, or look at how they used the design system in a novel way. All of that helps foster this sense of shared ownership and contribution and encourages this culture.
 
DESIGNING FOR WHAT’S NEXT
 
Josh Clark: The amazing thing is, once you have a design system in place, you have a common set of components that everyone understands. Designers, developers, UX designers. And, a common set of names. 
 
What that means is that when we're all working together, I can just call it by name. We need a carousel here. We need a slideshow here. We need a card list there. Whatever names we've come up with, we can just refer to them. 
 
I think an interesting thing is, is that we're actually now talking about creating a shorthand for visual design systems, where I can write it down and we've got the names there, but it's like - what if we could actually speak this out loud? Or, what if we could take our wireframe and take a picture of it and know those symbols and actually even the machines could start to translate it? We're starting to see that happen with companies like Airbnb experimenting with taking wireframe drawings and using machine learning to map those to design components that you can actually put into a page. 
 
I think that that shows the importance of being fluent in multiple platforms when you're designing for design systems, but also multiple inputs. I think it's important to remember that we're designing not just for the screen now, but we design for keyboard-only experiences or voice-only experiences.
 
At the same time, there's also a lot of excitement about emerging channels and emerging interactions, about speech and about augmented reality and all these different new ways that we're able to talk to the machines. A design system can capture those conventions too, as companies start to build those out. 
 
For a speech interface, you may have a bot or an interface that has a certain personality, and that's something that should be recorded with common phrases. For example, how you do confirmations, and different language around that. You could even have some things like Alexa has, which are called speechicons. “Badabing,” believe it or not, Alexa knows how to say. 
 
You can build in these flourishes as a library. In the same way that we have icons that we have in a system, you can have things like speechicons as a collection. All this is to say that for every different channel that you use, there are likely to be guidelines and conventions that you want your designers and developers to use, and as much as possible, get that close to the code. So, here is actually the code snippet that you use for that speechicon in your speech interface, for example. 
 
A design system consists of more than just a UI kit and a pattern library and a code library. It's also all of the different ways that you communicate and interact with customers. 
 
So, it can include things like a writing style guide or voice and tone. You think about voice and tone, that's also especially important, as we have this emerging future of speech assistance and bots. What is the tone of your bot? How does it talk? Should it have a big personality or should it be a neutral assistant?
 
All these things are things that as an industry we're starting to figure out, but your company needs a point of view, and the design system should have that point of view too.

Sign up, free

Sign in

InVisionApp, Inc.

Freehand

Prototype

See all customer stories

100% of the Fortune 100 collaborate with InVision.

Company

Blog

Insights

Films

Events

Resources

By using InVision brand assets you agree to follow our guidelines packaged with the media kit. For further information about use of the InVision brand assets, please contact support@invisionapp.com.

Build your design system like the pros

Would you like to speak with InVision about how to unite your team’s workflow using DSM Enterprise?

Course outline

Episode 1 - The heartache of design at scale

Episode 2 - Selling the value of your design system

Episode 3 - Starting strong: applying atomic design and choosing a pilot

Episode 4 - New roles and processes for a thriving design system

Episode 5 - Proven strategies for scaling your design system

Episode 6 - Maintaining and Evolving Your Design System

Transformative collaboration for all the work you do
Learn more about Freehand

Build your design system like the pros

Would you like to speak with InVision about how to unite your team’s workflow using DSM Enterprise?

Course outline

Episode 1 - The heartache of design at scale

Episode 2 - Selling the value of your design system

Episode 3 - Starting strong: applying atomic design and choosing a pilot

Episode 4 - New roles and processes for a thriving design system

Episode 5 - Proven strategies for scaling your design system

Episode 6 - Maintaining and Evolving Your Design System

Transformative collaboration for all the work you doLearn more about Freehand

Transformative collaboration for all the work you do
Learn more about Freehand