 Hello, everyone, and welcome back to the state of the web. My guest is Brad Frost, web designer and author of Atomic Design. And today, we're talking about design systems. Let's get started. So Brad, thanks a lot for being here. Thanks for having me. I want to start off by asking you, has the metaphor of a web page exceeded its usefulness? Yeah. It certainly has. As web designers, we've been thinking about the web in terms of pages for a long time. It's been with us since the web's beginning. We scope things out in terms of pages. If things don't load in the browser, it says this web page hasn't loaded. And that's had a really big impact on how we structure our teams, how we scope our projects, and how things are actually executed from a web design and development standpoint. So for instance, I work with a lot of large organizations, and so they'll have a team that's responsible for the home page, and then they'll have a team that's responsible for the product page, and another team that's responsible for the checkout page. And all of those teams are doing things independent of one another because they're just focused on this notion of pages. And as it happens, all of those pages are actually made of the same stuff. If we were to break things down, you have buttons, you have form fields, you have blocks and cards and heroes and all these other things. And we end up with, whenever you have these different teams working on different pages and thinking about things in that way, you end up with one button looking similar, but different than the next team that's working on the next page and so on and so forth. And you repeat that a number of times and span that out over a number of years, and you end up with a giant mess on your hands. It's not to suggest that we should stop using the term. It's probably still useful for users who only see things as a flat page. But from a design and development perspective, it's kind of outdated. Yeah, yeah, that's right. Exactly. It still comes together as a cohesive whole. And I think that that's important, especially as people get into talking about design systems. A lot of people have a big misconception that, oh, design systems mean you just sort of isolate things at their component level and just design the button and just design the sort of headings and just design the card in isolation. But that's just not true. It's important to sort of realize that, yeah, things do, all of those components do come together and form a cohesive page at the end of the day. And that's what the user sees and interacts with. So it's important to, it's not an either or thing, but we just have to be more considered about how we make the parts of that page. As the web and technology as a whole progresses forward, how has that changed the way that web designers think about serving pages to users and the ways that the websites are accessed? Yeah, well, from like an access standpoint or from like a design and build process. The fact that a user could be, I mean, even these days accessing the web from their refrigerator, you never know the form factor or anything about the user's device. You can't make any assumptions. Yeah, yeah, that's right. And again, it's gotten really complicated. And that's why I think design systems have become as popular as they've been because the devices haven't slowed down, right? The device proliferation is still happening, right? The number of context and screen sizes and form factors and yeah, native web embedded devices, different screens, different sort of mouse and keyboard, touch inputs and voice and like all this other stuff. It's just the amount of things that users or that designers and developers have to consider as they're creating user interfaces and creating these experiences have just sort of accelerated and we can't keep up, right? We can't create bespoke pages for, here's our small screen view and here's our tablet view and here's our desktop view. It's, so we've had to sort of pull back out of necessity just because we're on the hook to deliver more features, more services to more users and more context using more devices in more ways than ever before. And it's like, unfortunately, our budgets haven't increased and our resources haven't increased with that same sort of exponential curve. So that's what's like sort of forced us to sort of step back and reconsider how this all gets done. Given that there are so many different viewport sizes and everything, does that mean that the flat Photoshop file is no longer very useful as a means of conveying the design? Yeah, yeah, and still to this day I'm working and Photoshop might be a little long in the tooth when it comes to web design but same thing happens in Sketch and Figma. Just last week I got from the client's designers, a mobile version of a comp and a tablet version of a comp and a desktop version of a comp. And a lot of that's just sort of wasted effort really because all three of those things in isolation are sort of one, they're already alive because it's a picture of a website, not an actual website but all those spaces in between is where things really fall down, right? You could sort of paint a picture, especially in a static design tool where there's art boards and you could just sort of move things around in free space. Like that's not how things work in the actual browser, right? There's things like source order considerations and all that, you can't just sort of go, on this side screen I just want to move this from here to here or this, I'm just going to swap this around. It's really important to sort of make sure you're considering the actual medium that this user interface is going to come alive in and do that much sooner in your process. I want to ask you about concept reviews before called design debt. What does that mean? And how do you avoid going design bankrupt? Design debt and design bankruptcy. I've never actually heard design bankruptcy before, I like that. I think a lot of places could declare design bankruptcy. I think just when it comes to design debt it's you have number of teams working on different things than just as we were saying, working on different pages or different products across a company and you sort of can take a cross section and sort of see a lot of discrepancies just in that but that's just one moment in time when you stretch out that process over time especially products that have been around for a long time the Googles of the world or eBay or whatever it becomes like a little sort of Benjamin button like experience as you click through pages you get further back in time in these older crustier user interfaces. How did I end up in 1999 all of a sudden? So I think that that sort of that sort of that visceral feeling of design debt where it's like you have all of this sort of old stuff that was created once upon a time and that whenever that was launched it was the new hotness and the new hotness becomes the old crusty experience pretty quickly these days. So I think that the more sort of deliberate and the more sort of systematized you could sort of control and wrangle all of those sort of user interfaces that are out there in the wild the better your chances are gonna be at sort of like reducing that sort of design debt. And that's again I think a big crux like the crux of design systems is to sort of help eliminate that debt to basically take those 1999 designs and say okay we're gonna update them with the new design language but we're gonna do it in a very sort of systematic way so that the next time we do a big redesign we have actual hooks in there that we could actually sort of lift up the quality of and you know sort of evolve that design language like flip the switch and roll that out to a bunch of places sort of simultaneously or in very short order instead of like oh we have to do this big monolith like redesign and we have to do that for each of our products again and again and again. So the developer experience must be a lot better when you can have like a single source of truth for your design but also the user experience as well. Could you describe like what it might be like for a user to be on a site that has designed it? Yeah I mean this happens all the time. I mean the e-commerce example is a great one just because I think that you know e-commerce sites you know super sexy homepage or the super splashy, super current right. It's like it's got the latest you know shop fall trends or shop Christmas like coming up or whatever that's like it's like very campaign driven so it's often like a very modern experience. You sort of like click into like that maybe a product detail page or a product category page that sort of feels modernish you know it's like sort of a little bit more meat and potatoes like e-commerce stuff. So it's like those templates sort of probably feel pretty good but then like you might get to the shopping cart or if you like actually log into your account it's like those things feel way different and then you get to the checkout flow and then you know that might be sort of way along in the tooth or it might be sort of built by you know an external vendor or something because they're processing credit cards and stuff like that so it might not actually be integrated with like the rest of the site at all. So what ends up happening for why that matters from a user experience standpoint it's not just about oh, things look different like cause who cares as long as that's effective then that consistency shouldn't ever be like the number one goal of any of this and I think that that's when we talk about design systems I think that's another misconception is that oh, we just want everything to look the same everywhere and that's just really not true because if your metrics are doing well and stuff and the buttons look different on the checkout page than on the product detail page then that's fine, right? No harm, no foul but the problem is is whenever you're a user and you encounter say a date picker or something and this is a favorite one of mine just because those are hard to build so oftentimes developers just sort of go and grab something you know the library they find on the internet somewhere and if you're say like an airline or a hotel chain and you have four different developers grabbing four different date pickers across the site now all of a sudden every time the user needs to pick a date they have to relearn that new library and that even if it's just fractions of a second or a second or two or where they're like oh wait, I'm used to booking from the homepage but this is a different convention that slows down that process, right? And that has a negative hit on certainly when you're talking about booking flights or hotels or something that's gonna cause a dip so that sort of consistency from a user experience standpoint, right? That ability of like, oh yeah I've encountered this pattern before and I know how this works so I could just sort of roll on and sort of fill things out a lot faster or interact with this thing faster like that's what we're after, right? So that consistency for consistency sake not so much but consistency from a sort of mapping to what users are used to already like yeah, that's where it's at. One of the people problems on a design and development team is not sharing the same vocabulary or calling the same components consistent names. So what are some of the problems of that and how can designers and developers get on the same wavelength? Yeah, so that's one of the biggest things that I encounter is and one exercise that I like to do with design development teams whenever I'm working on design systems with them is right out of the gate we conduct what I call an interface inventory. So we basically go across their entire sort of suite of products or whatever user interfaces could be served by their design system and sort of divvy things up. It's like okay, you go hunting for buttons I'm gonna go hunting for sort of input fields or whatever. And then we sort of do that as a group and then what we do is we get together and sort of present what we found to each other and that's where it's really fun because especially whenever you have designers in the room developers in the room, QA engineers business people in the room, right? Like the product owners like all these different disciplines and you actually sort of have to articulate what your UI is, right? So somebody will get up and it's like oh and here's this admin bar and then somebody goes admin bar we call that the utility bar, right? And then the developers are like oh we just mark that up as the gray bar, right? And so it's like okay, there we go, right? You got everything out on the table, right? These inconsistent names for the same thing. And of course that means you have to have again just like that sort of user experience you have to like slow down you have to have a meeting to figure out what you're gonna call this thing like and a lot can get lost in translation in between design team or different disciplines but also different teams in general, right? If team one is calling it a certain name and team two is calling it something else that's a big deal, right? So again, so bringing this all back to design systems what a design system can do is sort of centralize your sort of UI patterns call them names, right? Write guidelines around them so that everyone is like literally speaking the same language, right? They know what you mean when you say utility bar and you know how to use it and where it's useful but also crucially one of the other things that we found really valuable in creating design systems for clients is here's what this thing is here's where it's useful but also maybe here's some gotchas or here's where it might not be useful and maybe you wanna use this other thing instead. What are some of the trade-offs of investing in a bespoke design system versus taking something off the shelf like a bootstrap? Yeah, that's a big one. And I'd say it's tough because tools like Bootstrap and Material Design are already made. They're there, they're well tested, right? They're in use by giant companies like this company called, have you heard of Google before? It's like it's a pretty big one. It sounds familiar. Yeah, so a lot of these people, right? Who are using tools like Bootstrap and Material Design they're like, oh, this has been tested by these giant companies so I could just sort of grab this and go and I don't have to do all that work myself. And that might be true and there are sort of instances of that. I think one of the big things that is important to sort of recognize and consider whenever you're reaching for these tools is that it's like you don't own it and it might be attractive from sort of an efficiency sake at first but as time goes on, right? At the end of the day, your boss or your product owners or your clients or whoever they are, they're gonna say, oh, well we need to do this, this way or we need to add this feature and all of a sudden you have to learn and become sort of fluent in this other sort of system that you didn't write. So it can work and you can do things and extend things and customize things that works with the grain of these frameworks but oftentimes what I found is I work with clients that end up sort of working against the grain and they end up having to sort of undo a bunch of stuff and write a bunch of other custom stuff and then they end up in this sort of like weird messy middle ground where it's like, oh, this is our sort of hacky stuff that we've done to sort of make things our own. But then also crucially, I'll say that from more of like a front end architecture standpoint, I think that it's sort of like safe, you got good bones to build upon but like material design and bootstrap actually offer a sort of an aesthetic, right? They provide an aesthetic and that could be helpful because again, it's like, oh, here's some good looking buttons, here's some good looking form fields, here's some good looking components that I could use but if Nike, Adidas, Puma, if Reebok, whatever, they were all to use bootstrap for their redesigns, they would look frighteningly similar, right? And that's sort of not what they're going for. So there's like, there is this sort of branding aspect of it, right? This ownability that sort of gets lost whenever you're sort of all using the same thing. What are some of the challenges or unsolved problems of design? Of design? I mean, tons. I think sort of specifically to design systems, like a lot of, there's some things that are around, sort of tooling and sort of figuring out how to keep design tools and tools like Sketch and Figma and stuff in sync with what's in code. That's definitely one of the most, I feel like tangible sort of problems that there's a bunch of teams doing a lot of work to try to solve that and startups and stuff that are really exciting. And so a lot of them look promising. And I don't necessarily think that that's, far and away the biggest problem that's out there. I think so many of the problems with design systems have to do with the sort of people, have to do with communication and collaboration and sort of figuring out like, how do we get this stuff adopted into our products, right? How do we sort of communicate when things aren't working as planned? How do we sort of establish solid processes for releasing new versions of the design system and letting everyone know like, here's when you wanna use the design system or here's when it's sort of safe to sort of deviate from that system or build upon it or extend it and how do you roll that back into the system? So a lot of that sort of coordinating a bunch of different people who are all suddenly relying on this design system product, that stuff I feel is still very tough to crack because it involves people and the health of your design and development culture and like how well everyone sort of collaborates together and like, of course that's tricky, right? So you could like, I could say things like, here's how I would create a governance plan for a design system and here's how I would, get these teams to work and communicate more but it's an easier said than done. So how much of a design system success depends on the designers as opposed to the developers? What is their role in the success of it? I think, and this might be a little controversial, design systems is sort of an unfortunate name because design systems are like, oh, this is about design and it's really not. The design system is, as I define a design system is how the official story of how an organization designs and builds digital products. And there's a lot of ingredients to that story. And yes, like the design language, what the brand colors are and the rounded corners or not of the buttons and stuff like that. Sure, that matters, but that's actually like a pretty tiny slice of what a design system entails. And so when it comes to the success of a design system, so much hinges on that design system living in code. And living as a thing that engineers and developers can sort of pull down into their application and sort of, import a component and sort of see that design systems button or whatever show up on their screen. And then they're able to sort of pipe in whatever sort of attributes and click handlers and whatever to sort of make it, breathe life into it, make it real. But they sort of get that stuff for free. If all you have is like a sketch library or some like Zeppelin file or some like little sort of style guy thing where it's like, here's our colors and here's our whatever. There's so much that gets lost if all of the developers are doing is like copying and pasting some hex codes in their sort of crappy development environments. And it's just you end up with a bunch of spaghetti even if they're all using like the same color blue it's not like systematized, right? So what you want to get to is you want to say like, if we change our brand color blue and this actually just happened on a project of ours had a brand color blue and actually it wasn't passing the accessibility level that we wanted it. And so they actually had to sort of, tweak the color blue in order to make that sort of pass, sort of cut the accessibility mustard. With the design system, like you literally have variables file or these design tokens and you sort of tweak that value there and then that ripples out to the entire sort of design system, right? And then that gets packaged up in a new release of the design system in code. And then next time the developers pull that down and they'll sort of see those updates. So coming back to it's like, yeah like the design language part of it like the look and the feel of it, that matters. I'm not going to say it doesn't matter but it's almost just like, you'll like do your thing, make it look good. Like, you know, I trust you be systematic about it, right? Think about motifs that are going to sort of like, you know, translate well the different components but like so much hinges on like getting that stuff into a place where it's consumable by the actual sort of, you know, environments that users will be interacting with your products. And that's what we spend probably the overwhelming majority of our time and effort on is actually like building out those libraries with components, right? And HTML, CSS, JavaScript, you know bundling that stuff up and like sort of working with development teams to make sure that they have what they need in order to use the system successfully. So to what extent should a design system anticipate the chaos of user-generated content like errors and long names? What is the actual like breaking point of a design system? Yeah, well, I think that the breaking point of the design system has everything to do with how well you consider all of that stuff, right? So if it's user-generated content that you need to account for in your UIs then you have to, you know consider things like character limits and things like that. But, you know, there's many other flavors of that as well. You know, internationalization right to left languages or just, you know, German will wrap onto multiple lines and things like that. And this is where I think again sort of designing and building components in isolation is a bad idea because you could sort of, you sort of fall into the trap of saying like, oh, here's this like perfect scenario where, you know, everything's filled in and the card has this nice sort of, you know, image I found from Unsplash and it's like really nice looking and, you know, as it happens, the user's name is Sarah Smith and Sarah doesn't even have an H on it. So it just fits so nicely onto one line. And then of course the reality of our user interfaces is anything but that. And this sort of also comes back to like the trap of sort of relying on these sort of static design tools to sort of handle that up until very, very recently there weren't even conventions in place to sort of handle like dynamic data. So that's sort of how we handle that. This is where atomic design as a methodology I think really shines. So what atomic design does is basically helps people consider the whole, the pages, the actual product screens in various states and configurations as well as the sort of parts of that whole, right? So the underlying components that build up those screens. And at the page level of atomic design what we're able to do is articulate here's what our homepage looks like with this, you know, the fall campaign with the leaves and, you know, this tagline in it and this call to action button that takes people to this and whatever. But then you're also able to say, okay and then here's what this, that same page looks like in German or here's what that same page looks like with, you know, the Christmas campaign and oh, that sort of image that we're using that has a bunch of Christmas ornaments that actually is sort of, you know impacting the readability of the text that's sitting over that image or something like that, right? So you could start seeing where the UI starts falling down and then what you're able to do is sort of take that and learn from that and sort of go back to that hero component at a more atomic level and sort of say, okay, we're gonna maybe add a variation of the hero component that adds like a little gradient overlay so that the legibility of the text always sort of, you know, pops over the image a bit more. So how we sort of do things like in our own workflow with that, we sort of will create sort of, you know, try to represent the whole bell curve. So it's like, what does a card look like? What does sort of like a kitchen sink card look like with like the maximum character count that you might be able to sort of upload as a user or something or what happens if the user uploads the profile picture or what if they don't, right? And so all those various states and sort of, you know, mutations of a component sort of get that sort of commonly used case down, of course, as like a starting point but like you really do have to represent like here's the extreme and here's the empty and sort of everything in between as well. And the only real way to test if that actually works is by sort of plugging in real products and areas into your user interfaces. And by sort of having that, that sort of atomic design system wired up where like the pages informs and influences the underlying components, you're able to sort of make changes to those components which then, you know, inform and influence that the actual page design. So it's sort of like a virtuous cycle between like the design system and the pages and screens that that system builds. Finally, what resources would you recommend for people eager to learn more about design systems? Oh, there's a lot. I feel like I have a hard time keeping up with them anymore. There's a number of really great resources. One that I help maintain is a resource called styleguides.io which is a collection of, I think we're over like 250 examples of public design systems and styleguides that are out there in the wild as well as sort of talks and books and resources and tools around a design system. So that's just like an open source, resource repository that people contribute to and sort of submit poor requests to. There is design.systems which is maintained by Gina Ann who's done so much work for the design systems community. She has a clarity conference which is a conference dedicated to design systems. We have a podcast which is a little bit in hiatus but where we interview people that work at different organizations who have spun up their design systems and what they've learned and sort of struggled with as they've done it. Stu Robson has a really fantastic design systems newsletter that's part of the design.systems sort of universe there. And then there's also Slack group all about design systems as well. So I'd say that like that sort of has me covered for sure. And again, there's like a lot of activity there and new stuff's happening every day and people are learning from thing, from each other and plugging them in at their organizations and sharing what they've learned. And like that's really for me the most exciting part of all of this is just sort of, you know, here's some concepts here's some things that we found useful share those people take them learn from them validate or invalidate them and then sort of share what they've learned and then everyone benefits from it. So Your book is also available for free to read online, right? It is. People find that. Yeah, yeah. So you could read it at atomicdesign.bradfrost.com Great, Brad. This has been great. Thank you so much for coming. All right, thanks so much for having me. You can check out the links to everything we talked about in the description below. Thanks for watching. We'll see you next time.