Enter design system pros Brad Frost and Dan Mall, long-time collaborators known for their expertise in bridging the gap between designers and developers.

In this episode of the Design Better Podcast, Aarron and Eli talk with Dan and Brad about reducing friction between these two very different disciplines. They explore a few misconceptions around agile methodology, the risks of the creative technologist role, and the latest in design systems thinking. This is a conversation you don’t want to miss.

Bios

Brad Frost is a web designer, speaker, writer, and consultant located in beautiful Pittsburgh, PA. He is the author of the book Atomic Design, which introduces a methodology to create and maintain effective design systems. In addition to co-hosting the Style Guides Podcast, he has also helped create several tools and resources for web designers, including Pattern Lab, Styleguides.io, Style Guide Guide, This Is Responsive, Death to Bullshit, and more.

Dan Mall is the founder and director of SuperFriendly, a design collaborative that brings exquisite creative direction and design to the world’s most important and interesting organizations. He’s also the co-founder and CEO of SuperBooked, a networking service that helps you find work with a little help from your friends. You can learn more about Dan on his website and follow him @danmall.

Brad Frost and Dan Mall: Rethinking designer-developer collaboration

The following is a complete transcript of this episode of the Design Better podcast. Enjoy the episode!

[Introduction]

Dan Mall: The front part of the process where only designers are traditionally involved, well, let’s get developers in that part. And then the end part, where traditionally only developers are involved, well, let’s get designers in that part. Right? And that way, everyone has representation all throughout the process.

Narrator: This is The Design Better Podcast, where we share lessons and insights from today’s foremost design leaders. We hope the conversations and stories you hear help you transform your design practice and build remarkable products. In our third season, we’re exploring the connected workflow. How designers work more effectively and efficiently with their engineering and product counterparts. We’ll talk about how building key partnerships throughout an organization can help you ship better products faster. This podcast is hosted by Aarron Walter and Eli Woolery and is brought to you by InVision, the digital product design platform powering the world’s best experiences.

Aarron Walter: Design systems are a hot topic in the design world. But if you’re trying to implement one in your organization, you won’t get far unless your design and dev teams are aligned. In this episode, we chat with Brad Frost and Dan Mall about some of the best ways to get these teams to work together more effectively. Dan Mall is a design leader, the founder and director of the agency SuperFriendly, and the co-founder and CEO of SuperBooked. Brad Frost is also a design leader, as well as a web developer, and author of seminal design systems book, Atomic Design. Dan and Brad have worked on many projects together and share their thoughts on how agile affects the design-dev relationship, what the creative technologist role brings to the team, and how design systems can be a middle ground for designers and developers. They also give us a sneak peek of the masterclass they filmed on design systems for ambition. So, grab your developer partners and sit down for a great episode with Brad Frost and Dan Mall. Thanks for listening.

Hey there. Aarron Walter, co-host of the Design Better Podcast right here. Want to give you a little tip: Did you know that the Design Better Podcast can be listened to directly on your Amazon Echo or Dot? Try simply saying, “Alexa, play the Design Better Podcast on TuneIn.” And voila, you will be listening to our latest episode. It’s magic. Thanks for listening to the show. Now, let’s get started. Brad Frost and Dan Mall. Thank you so much for being on the Design Better Podcast today.

DM: Our pleasure. Thanks for having us.

Brad Frost: Yeah, thank you.

AW: So, we’re recording this post on Thanksgiving, and I think everybody still has a little bit of a turkey hangover. But we’re interested to talk to the two of you for a couple of reasons. You guys work together quite frequently, you occupy different roles. Dan is a well known designer with years of experience working on some pretty incredible stuff, including StarWars.com, which I will forever be impressed by.

DMl: That’s my claim to fame.

AW: And Brad Frost is perhaps one of the best known design systems experts in the world. Speaks all over the world about design systems, and has done a number of workshops with us on design systems, and is a front end developer. And so, we’ve got an interesting combination, design and development. These two perspectives. And that’s something we see with a lot of teams, that there can be friction between design and development. But to the extent that design and development can align and work together effectively, products can be pretty amazing when those two come together. So Dan, where do you see the pitfalls of design interacting with the development process?

DM: I think one of the biggest and most common areas where design sort of has a pitfall is that lots of designers tend to want to own everything. It’s this very possessive version of designing. And what that does is, it kind of creates everyone else as subservient, right? It’s like, “Well developers are just going to build what I designed, what my vision is, and copywriters are just going to fill in the design of what I’m doing. And I have everything in my head.” And it tends to affect the culture of the way that the team works. And so, a lot of times when I’m working with designers, a lot of my role is as a consultant.

I work with a lot of in-house design teams and working with them, a lot of that first conversation about design is, “What are the things that belong to other people? And also what are the things that you can help other people with?” The first line of collaboration is, “What are the things that you should own and need to own, and are the good things for you to own? And what are some things that you really can rely on somebody else for, that they would do a better job or their environments are more native to the process than yours are?” And that tends to be the first difficult conversation. But if that goes well, all signs point to yes for good collaborations.

AW: Brad, from your perspective as a developer, where do you see the pitfalls of collaboration where developers might kind of lose that collaborative spirit?

BF: A lot of times developers aren’t collaborative. Not by choice, it’s sort of thrust upon them by way of how the process goes there in a waterfall process. And even though you might call yourself agile, there’s still the last in line. And very often they’re thought of as implementers, as Dan was just saying. You get handed what design produces and just crank it out. And if there’s any issues with it, just shut up and do your job. So, I do think that that’s sometimes, I don’t want to say out of their control, but that’s how the process is designed. It sort of leads development to sort of get the short end of the stick.

But I’ll also say that developers, it’s definitely a two-way street where I think developers need to fight a lot harder to work their way up stream and get themselves embedded into those conversations earlier to influence how things are designed, and what can be designed, and what’s technically difficult to create, versus other things. And because developers tend to have a better understanding around the capabilities and the limitations of the medium, if they’re able to work their way earlier in the process, they’re able to sort of make a smoother process for everyone, including themselves. But very often that doesn’t happen.

So, like one pitfall I definitely see is developers sitting on their hands sort of accepting, just sort of blindly accepting their role as the code monkey that’s going to crank out whatever specs the designer’s throw at them. And I think that that’s a big problem that needs addressing.

AW: So, Brad, you just touched on agile and I’m curious to get both of your takes on, how does agile affect the designer-developer relationship in either positive or negative ways?

BF: I’ll let the certified scrum master, Dan, take this question.

DM: Thanks Brad. I guess I might be one of the only designers on the planet that is also a certified scrum master. That “agile” is a tricky word and when a lot of people talk … because first thing is that it’s loaded, right? A lot of times when one person says agile, it’s not what other people say is agile. So, that’s one part of it. The other part of it is when a lot of people say agile, it’s shorthand for, well our development process is agile. But our design process is waterfall until it gets to development. And that’s a thing that is worth working on I think. And I think one reason that leads to that is that developers and engineers are sort of used to working on things in small chunks.

I think it’s built into the process of good development like methodologies, like encapsulation, and modularity, and things like they’re native to good development practices. And I think designers don’t really have good language or good foundations in that. And so, oftentimes when we’re working with designers, like one of the first things to learn is, “Well, how do I even break up my work into smaller chunks?” Like I don’t even know how to do that. A lot of designers, the typical pace of their work is, we’ll envision the whole thing, map out the whole thing. Do comps of full pages but not even full pages, all of the states, all of the screens, all of it, so we get a sense of the whole thing. And so what that leads designers to do is just kind of hold up for a while. Like I’m going to go away for a week and do this whole thing and then I’ll show it to everyone. And that’s problematic in an agile process.

I think what we try to encourage, when Brad and I worked together and when we work with our clients, we try to encourage them to go just share smaller things. It’s okay if it’s rough. Because when you go away for a week, the expectation that what you bring back is going to be good is very, very high. But if you show something after 10 minutes of work, “Hey, I just worked on a thing, here it is.” If it’s 10 minutes, there is no expectation that that thing would be good, right? It’s just 10 minutes worth. If we can encourage designers to work on smaller pieces, don’t even work out the whole screen. Just work at the top of it. Just do the header, all right? And then show the header to everybody else.

And it’s okay to ask everybody to imagine. Well, we’ll get to that piece later. We’ll get to the bottom of the page later on. And so, when it comes to agile, I think the first step is designers figuring out how to work smaller, rather than how to work holistically and broadly. And if designers can work smaller now, they can work at the same pace and the same cadence as the developer counterparts and that puts some kind of an even playing field.

AW: Does that break the design process to a certain degree though, Dan, that designers want to have a sense of vision of where’s this thing going? I mean, the process you’re describing is not unlike what Amazon does. That very discreet experiments, they’re designing small pieces and you never really see a massive redesign of Amazon. You see small evolutions moving forward.

DM: Yeah.

AW: And this is often the criticism that designers have of agile was that. It’s incremental over innovation, and designers want to over index on innovation. So, just curious, pushing back on that, does that break the design process in any way?

DM: It totally does. It absolutely breaks it, and my stance is that it deserves to be broken. Or maybe it was already broken. So, perhaps it breaks it further and I think that breaking is worthwhile. Because I think, and for a good reason. I think what designers have to deal with sometimes is, “Well, I have the vision of how this thing needs to look.” I think that’s a fair assessment, and the developer has vision as to how it might be implemented. And I’m stereotyping a bit, but generally I think the designers and developers can fall into those two comps. But what tends to happen is, “Okay. Well, I’ll work it out in Comps, or Photoshop, or Sketch, whatever my tool of choice.

But then I have to hand the whole thing over to a developer or an engineer, and I just have to like peer through the window at how it’s going. And, an engineer who may or may not be fluent in the language of design, and what’s the intricacies of design and UI design, they get to implement that and I can’t touch it at all. So, I think part of it is a tooling problem where it’s like, “Well, I can’t write code so I’m not involved in seeing the design through.” So, what I have to do is I have to front-load all of that “vision” into what I’m handing off. And I think that’s the part that deserves to be broken.

I think that part of what fixed that is tooling, right? If designers can have better tooling to affect the software itself, not just a picture of the software. And those are things like design tokens can do that. Learning a little bit of code, or designers writing a little bit of CSS, those can help you as a designer, to not have to handle all the reins over to a developer and go, “Well, I guess I just got to trust the fact that they’re going to implement it the way that I envisioned it.”

Talking more conversations I think helped lead to that. So, I think it’s worth breaking. I think it’s certainly what I’m talking about does break the design process, but I think it’s already broken. And so, what I’m advocating for is, well, let’s give the designer back the part that they should own, right? Which is the design details. And let the developer, an engineer own the stuff that they really should own as opposed to, “Well, I’ll just do as much as I can up front and then cross my fingers that it’ll be implemented well.”

BF: Yeah. I think to build on that, I think that Dan’s touching at … I think one of my biggest beefs with agile is the misconception that agile automatically equals collaboration, which in our experience just isn’t the case. And I think what we’re advocating for is true, honest-to-goodness collaboration and communication across disciplines. So, to sort of break the design process even further, it’s like, “Yeah, let’s get some men engineers in there.” Let’s get those people who historically have not been part of the design process, certainly not viewed that way, to get them, front-load them into the whole design process so you’re actually designing this stuff together rather than, like Dan said, one specific discipline, taking the weight of the world on their own shoulders and sort of almost selfishly, sort of executing their vision that everyone else just needs to follow.

DM: I think to build on what Brad said, it’s such an important point, which is that we’re so separate in the way that we do work, right? Designers design and developers sit around, and then developers develop and then designers sit around. I think what Brad is saying is it’s so important, which is let’s put everyone everywhere, right? The front part, “front part” of the process where only designers are traditionally involved, well, let’s get developers in that part. And then the end part where traditionally only developers are involved, well, let’s get designers in that part. Right? And that way everyone has representation all throughout the process.

It’s not, “Well, this is my part and that’s your part.” And then the two shall never meet. It’s let’s put everybody everywhere. And that leads to, sometimes, a lot of confusion, and that’s the breaking part. That’s the part where we go, “Oh, we’re not used to doing this anymore.” But when the Web first started, that’s how we all worked anyway until we siloed so much. And so, I think what Brad is bringing up is an important point that let’s put everybody on every part of the process. And that’s just not designers and developers. It’s product people, it’s writers, it’s QA, it’s all the people in all parts of the process. And that’s what it really looks like for a team to be collaborative.

BF: Yeah. I’m glad you brought up QA too because I think that they’re the ones that really see the downsides of a lot of that broken process. So, by sort of involving them early in the process, they ended up being some of the best designers on the team because they see what happens with all the edge cases that you don’t account for it. It’s like, “Hey, it looks like the name is Tim Smith. Well, what happens when the person’s name is not Tim Smith?” And fits nicely on one line. It’s like having people whose mind just sort of naturally works that way is crucial in the beginning parts of a process. But then also, to sort of come back to the end of the process where it’s historically developers beating their heads against the desk, and fixing bugs, and scrambling with everyone breathing down their necks to get the project done.

What we need to do is we need to get those visual designers, and those UX designers, people that are historically in the front of the process. Get them in there and get them active and looking at all the work that’s been done. And as Dan was alluding to actually give them some real responsibilities with the actual software so that their vision, or how that was spelled out, again historically and big giant wire frame sort of documentations, or big giant comps, or whatever to actually make sure that those visions, those design visions on how the thing should be architected, what it should look like actually makes its way into the finished product.

And that needs to happen in order for good work to take place. It can’t just sort of happen in these abstractions and then yeah, you just lob it over at developers and trust that they’re going to do it justice. Like you need to see it through in a very sort of hands on way. And that requires a bit of humility on everybody’s part, I think. I think it requires everyone sort of coming to the table. Developers being willing to communicate, collaborate, and sort of have a little bit of flexibility will say, “Rather than give me the specs, just give me the red lines, give me the … whatever the things are and I’ll just sort of implement it.” To sort of be able to sort of accept a little bit of a gray area, of a little bit of a fuzzy sort of, “Well, we have a good idea of what that should be, but let’s bring it home together.”

On the designer side, they need to be willing to sort of come to the table and come into the world of the actual code environment in order to not necessarily do that work, but to be able to sort of accept the fact that it’s like, “Okay, I’m going to sort of partner with these people who know this medium inside and out, and maybe I can learn some things about new layout techniques like CSS grid or something like that.” Right? Things that I didn’t necessarily know existed and new possibilities or limitations that I wasn’t aware of. So, it’s like that humility on all fronts combined with including all those disciplines throughout the entire process, is what leads to good work.

AW: So, this is newer role of a creative technologist that’s cropping up in more teams? Is this something that could kind of bridge some of the gaps we’re talking about here or are there other ways that that role could influence a designer-developer relationship?

DM: I have kind of a love hate relationship with the creative technologist. I think it’s really well intentioned and I think that all these new roles are cropping up to help bridge that gap. Like you mentioned [inaudible] the creative technologist is one. If somebody who kind of sits in both camps, right? Somebody who’s a little bit designer but also a little bit programmer, or engineer, or coder. Design Ops is another one of those, right? It’s kind of like tend to bridge the gap between sort of product and business and design.

And I think that what I’m realizing through that is, we do have these big gaps, right? We are separate in our silos and I think that the intention of that is the thing that solves it. And creative technology is one solution, right? But it’s more the principle of what a creative technologist is, that I think is the solution. Which is, “Let’s close those gaps, right?” Let’s build bridges across them if that’s one way.

Another way is to expand our role so that our silos are less separate. If designers could code a little bit, or coders could design a little bit, or designers write a little bit copy. How can we expand our roles and make them more broad so that the gaps in between them disappear? Creative technologists, the hate part of that, the dangerous part of creative technology is it says, “Oh, you’re the person who becomes responsible for the overlap and I don’t have to do it as a designer or as a developer.” I think that’s the part that’s potentially dangerous is to say, “Well, that’s not my job.” I think anything that leads us to say, “That’s not my job, I don’t have to do that.” I think that part is tough to deal with because it gives people the permission to not engage. To go, “I’ll just put my hand. I’ve done my thing, I’m going to go on vacation.” Let the creative technologist handle that, let the developer handle that, let the QA person handle that.

And I think that collaboration is the opposite where we go, “Oh, I can do that. I don’t write copy. I’m not a copywriter, but I’ll try it.” I think the opposite of that is the scrappiness, the willingness to do something that’s not necessarily part of your job, but hey, you need to get it done. You have to finish the project.

BF: Yeah. I think just to sort of build on that, I’ll sort of poke at that a little bit just because I think a lot of it’s personality based. What we found some people really are willing to experiment and sort of go outside their comfort zones and, “Yeah, sure. I’ll write a little copier.” Oh yeah. This isn’t part of my actual job, but I’m happy to sort of take part in those conversations. But then in our experience, I think we’ve also seen people who do sort of fit squarely in one camp. And they’re an engineer who they’re like, “Don’t ask me to crack open sketch or something like that.” It’s like, “I am an engineer, or whatever.”

And I sort of draw this distinction between, or I called brick people and mortar people. And sort of brick people are people with very clear boundaries to what they do. Right? The back end developer is only touching the back end. You’re not expecting them to necessarily get in the weeds and sort of play around with front end code or be a part of the design process so much. Maybe more as a consultant than anything else. And that’s fine. And you sort of need those people, those sort of people with very clear sort of responsibilities and stuff like that.

And you could technically build a wall with bricks and only bricks, but unfortunately it’s not going to be a stable wall. So, I think that where rules like creative technologists but also to Dan’s point, I think people who are a little more malleable, or a little more sort of flexible, are sort of fuzzy in there specific sort of skill sets, those people are what I call mortar people that sort of help ooze in between all of the different sort of brick people that allows a sturdier process to happen.

So, to Dan’s point, I think we need to close those gaps. Absolutely. And how that gets done is going to vary from team to team, and personality to personality. And I think that that’s the spirit of a good project manager or an attribute of a good project manager, a product owner, like someone sort of molding this team. It’s incredibly important to not just see them as, “Oh, these are just lines on a Gantt chart or on a spreadsheet.” And it’s like, “Oh, we need three developers, we need two designers, we need this team member.” And so on. But rather to say, “Okay. These people very much are go getters and are willing to sort of sit down and sort of have conversation and stuff like that.” These people are a little more in the weeds, put your headphones on, like, “Don’t bother me,” but they produce good work that way.

So, it’s about sort of designing the team that really sort of helps facilitate good work and recognizing that, “Yeah, not everyone is going to necessarily work in this very hyper collaborative cross disciplinary way.” Some people just aren’t … their minds don’t work that way. And that’s fine. And I think that that’s important, but you can’t have everyone on the team operate that way.

AW: So, what we hear is, “We’re talking about breaking down the design process, thinking in smaller chunks,” which developers are already been doing for a long time. About broadening skill sets, making those fuzzy. So, there’s more of … It’s an easier coming together of these two different worlds. And in this notion, it seems like the idea of a handoff which has been talked about a lot for the past few decades. I know back when I was in the agency world in the ’90s and that handoff was part of what we did, but it was also where projects exploded. Can you talk about handoff and why? I suspect, I know that you have strong opinions on this. But, can you talk about the potential downfalls of handoffs?

DM: So, my tendency is to push hand off one way or the other. And so, one way could be just eliminate handoff, right? Everybody doing everything. And that’s a bit of a utopia, admittedly. It’s like if you have a team where everyone can do a little bit of everything, you’re probably rocking and rolling. And so, that may not be realistic for all teams. And so for other teams, the other side of the spectrum … And Brad and I have sort of been playing around with like, “How do we talk about this and how do we do this? How do we show this?”

And one metaphor that we’ve come up with is certainly not a solid one, is the metaphor of hot potato. All right? Hot Potato is a handoff from one person to the other, but it frequently goes back and forth. Right? It’s like you for a little bit, and then me for a little bit, then you for a little bit, then me for a little bit. I found that that is a useful process for a lot of teams, is not the handoff goes one direction and it never goes back. But it’s like, here’s a little bit of design, goes to develop or build that thing out, back to design though, right? That’s the part where it breaks a little bit. Right? The part where we’re not used to, back to design.

Let’s look at that and see how it’s going. If it doesn’t work, all right, maybe we’ll modify it, or maybe we’ll ship it, maybe we’ll build on top of it, or maybe we’ll do something else to it. But, so, this idea of kind of going back and forth between design and development, design and development, and that applies for all of the disciplines too. You could get copy in there, you get UX in there, you can get QA in there, your backend in there. So, all of them sort of like hot potatoing between each other.

That tends to see representation from everyone. Right? That way it’s not just really heavy design and then no design. Right? And then really heavy development, and then no development. It’s like that seems so lopsided and it seems like that’s hard to manage. And so, doing a little bit at a time seems to be really manageable for a lot of teams. And so when I think about handoff, I think about, that might be a more sustainable way for a lot of teams. To think about handoff as sort of hand it off, but then hand it back, and then hand it back again.

And so it’s seeing everybody, not just one time, but multiple times. I think the price of that is it sometimes, especially when you start to do that process and you’re used to something else, it’s less efficient. And I think that we live in such a high efficiency culture of product design, that a lot of teams that’s antithetical to the way that they do business. And I think that’s maybe one of the hurdles to get over in that. Okay. If you’re going to do multiple handoffs, if you’re going to do this hot potato thing, that you might lose a little bit of efficiency upfront, but you’ll get it back in quality later on.

I think that that’s what we’ve seen with a lot of the teams that we’ve worked with is it’s a little clumsy at first, right? As is anything that you try for the first time, but then you start to build more fluency, and you start to build more quality that way because you have more eyes on the whole thing and more opinions on the whole thing eventually. And that generally leads to higher quality.

BF: Yeah. I think one thing that’s crucial to underscore and how we tend to think, and this is coming back to agile. So, one of the core tenets, and I’m stealing from Dan here, but it’s working software over documentation. And I think that historically, handoffs involved just a ton of paper, digital paper of course via the pdfs and all sorts of things that ultimately get thrown in the trash can.

And I think that one of our big pushes when we work with different teams is to really prioritize the finished process. And that all the artifacts should lead to a stronger sort of final product. And to do that as soon as possible, what’s the minimum viable artifact that gets the result that you need? Right? If it’s, “Oh, we updated our primary navigation, we added these two links and we sort of changed the labeling on that.” Cool.

That’s like three words. Just say those. And then we can plug them into code immediately. I don’t need an updated wireframe deck for that. Or I don’t need a new clickable prototype of that thing. Just tell me the words and we can plug it in. And the same goes for comps and stuff as well. If we’re talking about the homepage hero area or something, just spot comp that thing. We don’t necessarily need the whole Shebang in order to have a conversation about this one part.

So, it’s like what’s the minimum amount of sort of artifact that we could create that gets the ideas across so that the team that’s actually building the thing for real can get that built faster. And again, how can the other team members or support that? Right. And very often, this is sort of a wild thing that Dan and I have discovered in almost six years we were eating together is that it’s just now. The amount of artifacts or would be artifacts are solved in just by way of a quick zoom call or a quick Skype slack chat where we just say, “Hey, where are we going to do about this? Here’s a screenshot to this.” And he’s like, “I don’t know. Maybe move this over here over here. Here’s another screenshot of that in action.” And he’s like, “Yeah, yeah, that works. Cool jobs done.” The formality of it.

And I think that this is a thing that a ton of teams get tripped up on is that, we try to sort of formalize our process into this sort of Henry Ford, “Here’s how we produce this stuff.” And that you become a slave to that, right? People short circuit when you try to break that process because it’s like, “Wait, we’ve created this. Yes, it’s rigid, but it works and it’s proven.” It’s a lot harder to sort of get people to bite off on and it’s like, “Hey, this process is going to be a bit more rough and tumble. There’s going to be a lot of fuzzy edges, and gray area, and stuff like that.” But you have to trust that by sort of prioritizing the working software that the finished product more than the process of going through the motions of a lot of these other artifacts, you’re going to end up with a stronger finished product.

EW: Nothing takes the wind out of a designer’s sales like shipping a product that looks nothing like the original design. But let’s face it. Lots of design details get lost in translation when transitioning from comp to code. If only there were a more efficient way to eliminate those mistakes, while empowering developers to build faster. Actually there is a tool to do just that. It’s called Inspect and it’s part of InVision. With inspect, when designers share final comps with developers, they’ll see all the specs of the design including spacing, type styles, colors, and more. No more shipping-frankenstein versions of your product. Get it right the first time with Inspect. You can try it for free at invisionapp.com/designbetterinspect. Thanks for listening. Now let’s get back to the show.

AW: So, maybe talk to us a little bit about how design systems can be a middle ground for designers and developers.

BF: Design systems very much are sort of a weaponized, sort of this combination of a bunch of different perspectives, all sort of put into this actionable sort of thing, right? Here’s the set of components that should embody development best practices, front end best practices, accessibility best practices, brand best practices, UX best practices, and QA best practices. All of this stuff, right? You are able to sort of … Done correctly, you end up with a set of reusable components that sort of contain all of these perspectives, and then those puzzle pieces get taken and plugged into real applications to build new software that then embody all of those best practices. So, like it’s great because you get this watering hole where designers come together to share the best of their knowledge with the developers who are sharing the best of their knowledge, and it all sort of meets in the middle.

And then again, crucially it becomes… weaponized is too harsh a word. But, it’s like it becomes this thing that once you sort of go through that process and create this system, that you’re able to ensure that all future work that is using the design system is able to sort of benefit from all of that great thinking. So, this is great because historically used to be, if you have seven product silos in an organization, you’ve got seven teams doing really smart work. There’s a bunch of smart brains sort of within those silos and they would solve these problems in very novel smart ways, but that’s great. But that only benefits their silo by sort of elevating that out of individual silos into this sort of thing that’s meant to be sort of used across different products. You’re able to sort of elevate all of those smart brains out of their silos and into this centralized place. This is what we call a central repository of institutional knowledge.

DM: One of the things I learned early in my career from one of my first creative directors, Jason Santa Maria, he always used to say to me, “It’s easier to revise than it is to create.” Right? Creating a design from scratch is incredibly difficult. It’s just like there’s a lot of mental energy that you expend on that. There’s a lot of figuring stuff out that you’re trying to do, and we’ve gotten so used to that process. We as an industry that we tend to want to replicate that over and over again. And a design system takes a lot of that work away. It shouldn’t take all of that work away, especially if you’re building and making something new, or concepting something new. But the stuff that you’re making over and over again, let the design system take advantage of that, of your design system there.

When Brad and I work a lot with clients where we help them make design systems for their in house teams, and one of the things where you really see the benefit of that is you don’t need to comp anything, right? We’ll sit at a whiteboard and we’ll draw a bunch of boxes and we’ll go, “Okay. This and that we need … Okay, we need an area to cycle through a bunch of products, we need an area where we can put some copy, we need an area where we can have kind of a navigational thing.” And then we’ll consult the design system and go, “What do we have in here that does that job?” Okay. For this one we’ll just use this carousel thing, and for this one let’s use a body copy component, and for this one we’ll use this other thing.

And we’ve just made an interface that we can build directly in the software without a comp, without anything. Just oversight really from a designer and then, and a couple of includes from a developer. I think that’s incredibly powerful. I think there’s a lot of stuff that’s wrapped up in that too, is now comes questions like, “Well, if I didn’t comp anything as a designer, well, what do I do? Am I redundant now? Is my job useless?”

And so those are the things that have to be solved at the same time. It’s sort of all the stuff around the crafts. And I think that’s a lot of reasons why designers … And I speak as one, so I feel this myself, why designers tend to need to justify their jobs and developers too. Well, if I’m not comping, what am I doing? And if I don’t have a good answer, well then the answer is I need to comp more. So, anything that takes comping away from me, it’s probably a bad thing for my job. And so I think if we can address those kinds of problems at the same time by going … Well, one of the last projects that Brad and I worked on where we had a design system and we were building these interfaces really quickly, it freed me up to say, make diagrams for the client who didn’t understand how a particular process was going to work. Right?

So, okay, I can make an infrastructure diagram with those same design skills. I don’t need to make comps for my developer because they don’t need them. We have a good design system in place. And so now it frees me up to use my design skills elsewhere to help somebody understand something new, to help our team figure out a process, maybe to create something new that we normally wouldn’t have had time to do. So, I think that design systems are helping us to be an accelerant to product design. But I think we also have to solve the problem at the same time, “Okay, well what do we do with that free time now? Now that we have this efficiency, where do we spend it?”

AW: And of course designers are contributing more value by focusing less on what color, what shape is this button more about? How do we drive business value? How do we satisfy customer needs and so forth, which is much more meaningful work.

DM: And so much more valuable to humans.

EW: Sure.

DM: This is … That’s real design. If design is relegated to what typeface did we pick and what color combinations do we use, I mean, the machines will take over your job. Promise. That has never been the value of design. The value of design is we get to look at things and go, “There’s probably a better version of that somewhere. What is it? Where is it? How do we find it?” Designers have always been good at that. We’ll continue to be good at that, but we have to accept that that’s our job. That’s the job, not the job of like, “Oh man, look how pleasing this harmonic palate is.” I mean, that’s … the computers are good at that.

AW: Let’s talk a little bit about language because that’s something that the two of you have touched on already. And Brad in your example where you talked about how easy it is after six years that Dan understands where you’re coming from, you understand where he’s coming from. So, there’s rapport that’s built, which is infinitely valuable in a team to make a team more efficient, produce better work and so forth. And so you can basically solve problems faster together. And that boils down to language, a common language that’s developed.

And we’ve heard from people like Stanley Wood, who’s director of UX at Spotify. He had some trouble coming into Spotify, which is a very engineering driven culture to … Trouble communicating, objectives and here’s the design perspective, here’s what we’re trying to achieve. He would say things like, “Hey, this work is not high quality.” And the developers would say, “I don’t understand what that means.” Because it’s a different perspective. Right?

So, he had to shift his language and talk about things like UX crashes. This is the UX crash. People try to log in and they get confused. They don’t know how to reset their password. This is one of my pet peeves, is the error messages. It’s either your username or password is wrong. Something is wrong in this combination, try again. And so you try like 16 permutations. But if you would’ve just told me it was my user id that was wrong, then I probably would have gotten it in a quarter of the tries. So, I’m curious if in your experience, how you’ve bridged the language as you’ve built this rapport over the years, or how you’ve seen that in the various companies that you’ve worked with?

DM: So one thing that I really appreciate about working with Brad is that he has come up with a really wonderful methodology for how to build products, right? Brad has sort of like collected his ideas into a philosophy called atomic design. A methodology called atomic design that has … here are some specific things that I use in my practice. One of the things that I’ve seen Brad do all the time when we work with our clients is not to take those for granted or not to say, “Here’s what we’re going to call stuff, and here’s what we’re going to say, and you have to use it this way.” It’s building them together. It’s being collaborative, even about the language just to say, “Hey, what do we want to call this? Do you want to call this an organism, or a component, or a pattern, or a this, or a that?”

It doesn’t matter what we call it, right? It just matters that we’re shared on it. And if we all agree that it’s called this, great. Then when I say that word, you all know what I mean. And so we tend to start a lot of projects that way is to go, “No one here needs to be precious about the language. Let’s just all agree.” If we can build consensus around the language that it doesn’t matter. Like, we’re going to call this a gobbledygook. But now we know that if, when somebody says that word that we all know what that means.

And so, I think that’s one of the things, it’s like we can build language together as a collaborative exercise. We’ve done lots of projects where we’ll write a glossary of terms to start the project. This is what this means, this thing goes over here. When we enter things into CMS, we call it this, it’s a blob, not a … whatever. Whatever we call those things. And now that we’re shared, now we can use those as tools. And I think that that extends to not only terminology about, well, what is this a component or a pattern? But all sorts of things.

We’ve done projects where we will build a glossary of values. What values do we want to have when we work on this thing together? Do we want speed as a value or do we want intention as a value? Because at some point those two are intentional with each other. So, I think that extends more than just terminology. I think that calling things, and project values, and principles, we’ll often say, “Well these are principles that we want to have either for the system or for our work together.” And I think those are the things that kind of drives the process. And kind of what I’m getting at here is I think consensus is the most important thing, or one of the most important things about language is it really, the language itself doesn’t matter the fact that we’re shared on it, it makes all the difference.

BF: Yeah. And I think that that’s why it’s so important in our process how we kick off any design system initiative. But at any project really, but increasingly it’s big design system initiatives is to talk to people and talk to a whole bunch of people, of a bunch of different disciplines, and a bunch of different levels, junior developers, senior developers, junior designers, senior designers, all the way up to the CEO sometimes. And to get at sort of how work gets done there currently, what they’re frustrated with, what they’re happy with, what they would like to see out of there, how they work with other disciplines and stuff like that. And all of those conversations help shape all of those values and principles and all of that stuff that Dan was just referring to.

And we started to take that research, those conversations and started to extract themes. And whenever we kick off a project we’ll do a priority exercise to basically say, “Okay, we’ve heard this sort of dozen or so themes.” The design system should touch on all of these things. But which of these themes are most important for the outcomes of this of this initiative? Of this project?

And so, it is really great to sort of get all the stakeholders in a room together, and collectively come to a broad consensus about, “Oh, here’s what we’re trying to do.” And that’s the sort of first step to really getting those values, and principles, and sort of that shared direction sort of baked into their culture. So, it’s like that first step towards a shared language. And I love that. I love seeing a bunch of different viewpoints and perspectives, each with their own sort of personal ambitions, and sort of pet projects and bugaboos, and whatever. And sort of get together and put those things aside and sort of recognize like, “Oh, okay. Now that we are able to see the whole elephant, it totally makes sense for this, this, and this to be the main sort of outcomes for this.”

And that sort of gives everyone a solid foundation to stand on right there. This vocabulary to stand on. And what’s cool is that from that kickoff initiative and once we sort of bake that into our project plan, here’s how we’re going to go about this. That becomes something that we refer back to throughout the entire process, right? Whenever we establish on our principles and how we’re going to work together, and like what this project needs to do and accomplish. When the going gets tough, or whenever there’s competing priorities, or whenever somebody is sort of, again not letting their personal pet thing go, we’re able to refer back to it like, “Oh, remember when we all came together and collectively decided that these were the main things that we need to take care of here.” And so it just becomes this really great reference to keep coming back to that keeps the train on the tracks and helps everyone sort of come back to the greater good, if you will.

Talking about specific language, I think Brad brought up a good phrase there and there’s a couple of phrases that we tend to go back to a lot. One of those phrases is, “Remember when we decided that …” And it’s reminding everyone of, “Remember when we had consensus about this thing, right? Remember when we decided that color was going to be the driving force of this?” Or, “Remember when we decided that more revenue was the highest goal here. Remember when we decided that efficiency was the thing that we were going to prioritize.”

And we refer back to that at every point in the process, whether we’re referring to you’re walking through a design direction, or walking through a build or a prototype, and somebody says, “Oh, I don’t like this thing here. Well, remember when we decided that this is where this thing came from?” And it’s okay, have we changed our minds about that? And it’s okay if we have, but it means that we probably built this thing on the wrong foundation.So, we’re often trying to lay the foundation for a good work and then build upon those foundations of good work.

Another phrase that we tend to use a lot in the collaboration process of actually making a product is kind of like this, right? Like I’ll have a website as a reference, “Oh let’s make it kind of like this one.” I don’t have to make a copy of that. I just need to send you a link or a pull out an APP on my phone. Oh, kind of like this kind of like they do it. And sometimes that’s enough to get people building, or thinking along the same lines. And so the common theme of all of this is, how can we be more together? Like how can we draw people together, draw the team more together than enforced how separate we all are about this. And so we tend to gravitate toward language that does that. That kind of brings everyone together. “Remember when we decided kind of like this.” Those are phrases that we tend to go back to often.

AW: So, you both recently filmed a masterclass for InVision on design systems along with Josh Clark. You all look great on camera by the way. So-

BF: Thank you. They’re wizards. It takes a lot to make me look decent.

AW: Could you give us just a high level overview of what viewers will learn in that series?

BF: Yeah, absolutely. We started to go through soup to nuts sort of the process of creating a design system and a lot of the pitfalls we’ve seen in our own work. And we’ve sort of been studying many of other design system initiatives that have been out there over the last few years. But yeah, certainly the entire spectrum of the arc of a design system initiative we cover and talk about what leads to good outcomes. So, again, we are just sort of talking about the research involved in that, sort of talking to people and kicking off in initiative.

And we go a little further in the weeds about sort of how to conduct those things but also sort of how to convince your bosses, your colleagues, and clients to sort of embark on this journey in the first place. But then getting into the weeds about, yeah, how do you actually do this? And how do you work collectively and collaboratively to make these things happen? And then crucially, how do you maintain this? How do you set this thing up for long-term success rather than it being a, “Yay, we made a thing,” and then it immediately just starts decaying and soon becomes obsolete. So, that’s the sort of general big picture of it.

And again, a lot of it, the perspective of it is that we’ve been super fortunate. Me, Josh and Dan had been super fortunate to work on these things over the last six years. And, we’ve seen a lot of success, we’ve seen a lot of failure, and we’ve ducked our heads into a bunch of different organizations, and we’ve had a lot of firsthand experience building these things together. So, I love that aspect of it is that it’s like, “Here’s how we not as sort of like just individuals who happen to be working together, but as this sort of tight knit team that’s been doing a lot of this work over the last five, six years. How we’ve come out the other end with some success stories.

DM: I think one of the things to emphasize in our work is that we’re consultants. All right. And so, our experience in working with design systems is broad, right? Not as deep as someone who maybe worked in house at any one of those places, but we’ve been able to touch, I would say over the last five or six years, maybe two dozen or so design systems at different scales, private and public companies, big designs and some small design systems. And so, part of the series that we did is really just to kind of expose some of the things that we’ve learned from our vantage point to say, looking across these design systems here there are some of the patterns that we see and what gets traction, and how to make them. What doesn’t get traction and how to make them, what we’ve seen in teams being successful, again, it kind of an aggregate.

And so, while we can’t really speak to a lot of the level of depth that may be somebody who is working in house at one of those places, or two of those places could do, we hope that there’s some wisdom in saying, “Here’s a couple of patterns that we’ve seen across a bunch of these things.” And so, that’s what we’re kind of hoping to impart from that series.

AW: I found it personally fascinating just to hear each one of you talk about your perspectives touching on a lot of different types of issues in building out design systems. So, I hope our listeners get a chance to check that out. As we draw to a close on our conversation, we like to ask our guests what they’re reading, what they’re inspired by, what’s informing their work today? Are there books, or blogs, or podcasts that currently have your attention?

BF: I’ll start because it’s just this morning I finished Future Ethics by Cennydd Bowles. It’s incredible. It’s absolutely incredible and I think that it’s mandatory reading for any designer, especially people that work on large scale projects at big companies. I’m thinking, Google, Facebook, Twitter, etc., etc. Just really talking about baking ethics into your day to day design work and just how imperative that is in this day and age. It’s incredibly … I don’t know. I’m floored by it. I don’t usually write reviews of books on my blog, but I was like, I need to do that because I’ve been just absolutely blown away by … He’s just incredibly articulate. For one, if you know Cennydd he is extremely smart and intimidatingly so I if I may add. But he just covers a lot of ground, gives a lot of great examples, and a lot of really good tactics about how to basically do the right thing in your job and how important that is for good outcomes. Not just for individual projects but also for all of civilization. Our Future.

DM: For me, I’ve been … I kind of hop back and forth between. I, like, read multiple books because I do them over audio mostly. So, the one I just finished was, It Doesn’t Have to Be Crazy at Work by Jason Fried, the CEO of Basecamp and it’s great. It’s not an instructional book like I thought it would be. It’s more of, here’s how we do things. And I appreciate the transparency of, these are some of the principles that they have, the way that they built that company in a very calm way. And are some of the drawbacks of that, right? And here’s some of the penalties that were willing to incur because we have a company like this. And so, that one’s been great.

I’m also reading To Sell is Human by Daniel Pink, where he sort of makes the case that all of us are sales people in that we have to convince other people of things more and more in our lives. So, we may not be selling a product or maybe not be trying to get money in return for what we’re doing, but we’re trying to get attention, or we’re trying to have someone respect us, or trying to just be heard out sometimes. And that is an act of selling. And so, more and more as I’m thinking about how I work with teams, and collaborators, and just people in general to convince them of things to be able to hear them out well. I’m more drawn to that. And then the last one I’m reading, I like to kind of mix it up with some kind of work stuff, and then somethings are not work stuff is Artemis, which is a fictional book by Andy Weir, who also wrote The Martian. And I’m doing the audio book and it’s narrated by Rosario Dawson, which is excellent and I’m having a fun time listening to that.

AW: Great recommendations. Dan Mall and Brad Frost. Thank you so much for spending time chatting with us on The Design Better Podcast.

DM: Yeah, thank you guys. Thanks for having us.

BF: Yes. Thanks for having us.

Narrator: That concludes this episode of The Design Better Podcast. Thanks so much for listening. If you’re hungry for more stories and lessons to continue to level up your design practice, visit invisionapp.com/designbetter. You’ll find eBooks, videos, and articles on design. The union team can use to learn more about design thinking, building world class operations, facilitating enterprise design sprints, and so much more. If you enjoyed this episode, please leave us a review on Apple Podcasts. And share this podcast with a friend or teammate interested in designing better today. Thanks so much for listening.