The Developer Experience in Design Systems
This week feels like a special episode, as we pull into dock with Brad Frost. I'm pretty confident that this is someone who needs little introduction, but for those of you who don't know who Brad is, his book Atomic Design popularized the concept of design systems in modern design, he started the front-end design system environment Pattern Lab, which paved the way for a lot of others including Storybook, and has spoken at pretty much every conference in the world (or so it seems). I was lucky enough to sit down with Brad and talk about the developer experience in design systems — what processes and tooling helps him, where he sees common problems and what the future of design systems and designops is looking like from his perspective. Let's set sail!
- Brad on Twitter
- Pattern Lab
- Atomic Design
- Outkast, Stankonia
- The Element, Sir Ken Robinson
Luke: A good place to start with is how did you get into design systems, what was the journey there?
Brad: So I worked as a mobile web developer at a New York City-based agency called RGA and we were working on stuff for Nike and MasterCard and Tiffany & Company. But they were m.sites. And at the time the iPad was just coming out and I was actually helping make ipad.nike.com and I was helping create an experience that was meant to go to the desktop website, to this new iPad website and to not one but two mobile sites. There was iPhone.nike.com and then there was also just an m. for everybody else, so that’s four different environments. But the experience was, how do we actually deliver this single experience to these four different environments. So we created an experience that was flexible, that was fluid and it just happened to get, not quite I framed in, it was like native to all of these different environments, but it was indeed a responsive experience. But this was before Ethan had written his article about responsive design. So it was on like the tail end of that, that Ethan wrote this thing and we're like, Yeah that's what we're doing, it’s a little different because we were shoehorning it into these different buckets, but same deal. So responsive design came out, the iPad came out, iPhone started to get traction and I just happened to be positioned in this place where that was explicitly my job was creating these mobile web experiences for these new and emerging devices, just totally dumb luck, right time, right place, I guess. We started to explore this whole responsive web design concept and meeting the needs of all of these different devices and stuff like that, started getting into well, okay we could create these flexible experiences. The hard part isn’t creating a flexible page, It's pieces of the page, right? It's like, ah, navigation is hard, right? How do you do a horizontal navigation on large screens, but then what does that do on smaller screens. And that's what led me down the road, I created a project called This Is Responsive, which was a collection of different patterns for different types of UI and how these things flow and adapt across the screen resolutions and so it's like, here's six different patterns for dealing with data tables, here's six different patterns for dealing with navigation. And it was cool because the community started inventing these patterns and things started to emerge, we kind of throw them on the pile and so we had this nice pattern library of here's all these different ways you can handle this stuff. So that was like the first thing of it's not about oh, let's make the homepage responsive, it's like, well, what goes on the homepage and what components in here need special responsive attention. So that was the first let's break this down into its more component pieces because some things just naturally scale on their own like images and stuff like that. So that was my first voyage in there and then as time went on at the time Bootstrap came out and it was this, here's components, you can build pages and I'm like, yes, like that's nice, but it seemed like two course of a story. And so, what ended up happening around this time, I left my agency job and set out on my own and I'd been thinking about these things and that core story of it's like sure, we have components that we could construct pages with them, but it's lacking this nuance and that's kind of where atomic design came from as well as a tool called Pattern Lab, which is a little bit like precursor to storybook, it's still around as a project but like, this is early 2013, I guess, was whenever we created atomic design through the lens of a couple of my first freelance projects. We redesigned tech crunch, the technology blog, and then a US-based entertainment publication called Entertainment Weekly.
Luke: Just small projects to get started on,
Brad: Yeah! I love that. That was it and big shout out to Josh Clark, who I’m still working with all these years later, he was the one that was like, Hey, I have these projects, would you be interested in doing that? And that actually gave me the opportunity to step out into the great unknown and self-employment without the scariness of it. I stepped out into a project, but it's also through that lens that I was able to work with Josh Clark and Dan Moll. And as I had this idea for atomic design and splitting out components into a more granular and hierarchical fashion, I was working with them to help galvanize these ideas and really put them into practice. But the funny thing was the gig wasn't deliver us a design system, the clients didn't care about that at all. And in fact, we were like, here's your new site, and they're like, great, that's what we needed and we're like, oh, and by the way, here's this super thoughtful pattern library that everything is like super spelled out and very standalone and robust and versatile and all this stuff. And they're like, that's nice, trashcan. So it took a while, it took a number of years before that started to even be a thing that people started to ask for. So at the time it was please help us make our first responsive websites and that was the gig and it only evolved into this more, Oh, Hey, we're actually looking for a sturdy component library. Design systems wasn't even a name until I feel like 2016, 2017, that people were really actively and openly sort of like talking about we need a design system.
Luke: Yeah. I remember the same thing. It's like, I used to create little pattern libraries for little websites that I was creating for my clients when I was freelance. And it was always one of those things where they only cared about it when you were like, well, this is going to shave off a week of my dev time. And that's the part where they go, oh, great. And it's like, do you want me to package this up in a way you can use it in the future? No don't worry about that. That's fine.
Brad: Don't worry about it, I like the sound of that, but Yeah. don't bother, we don't know what to do with this thing.
Luke: Yeah. They're like, we're probably going to redesign it in six months anyway, so it's fine. As one of the grandfathers of design systems now, I mean, does that make you feel old?
Brad: I am old. I'm fine with that.
Luke: I mean, you've worked on so many design systems, especially really big ones and I know that you've obviously built loads from the ground up, but you've worked on quite a few where it's like, you've come in and they've been established and it's sort of to overhaul them or sort of fix them, fix the problems that are involved. And I suppose on this podcast especially, we've been talking to lots of designers. Well, apart from Jerome, you're the first dev to come on the podcast. And so I suppose I just wanted to know what has been over all of those design systems the valuable thing that you've learnt when it comes to building or maintaining a design system from that dev perspective. What are the things that like you wish that you could just, when a developer is about to go in on their first design system to just take them aside and be like, okay, this is going to save you so much time.
Luke: Yeah. Cause I've been in many teams where this has been the case, right. It's always the, when I've got time later or when we're bigger and we've got our shit together and it's like, actually, if you're not treating everything as a reusable component from day one, you're just creating tech debt you're creating future tech debt.
Brad: Yep. There's a Creedence Clearwater revival song called Sunday Never Comes and it's one of my oft-quoted song lyrics because it happens all the time with every team we work with. It's just like, we'll address this later, like, we would like to do it this way now, but we can't for reasons X, Y, or Z, but I'm sorry to say, someday never comes.
Luke: Yeah. And I suppose so in terms of from a practical point of view as well, I'm curious, I'm sure everybody else is, in terms of your tooling and workflow, I'm really interested in what has made your life easier over the years. What is part of your sort of standard repertoire these days? Obviously, atomic design is the basis of everything
Luke: Yeah. I mean, if you're treating that environment as your full sandbox, it just makes, it makes everything like QA easier. And as you said, I'm guessing also means that you don't end up with that massive chasm between what is in production and what exists in your Storybook.
Brad: What's awesome is that you're able to, as a UI developer, you're able to be like, whenever you get into wiring this thing up in the environment, one, you're able to handoff, not just a static fig, but content anymore or whatever. And then like the application developers have to deduce what's going on and recreate that. What you have is an intermediary stage in between a comp and the sort of production code that is a code representation of the comp, but exists outside of the application code base with the biz. Yeah, with the business logic or the APIs and the databases and all that good stuff, what you're able to do is have this extra layer of, is this actually a UI bug or is this like an issue, like whenever we fire it up or wire it up to this thing and that's what's causing the performance bottleneck or like the assessability issue or whatever, by having this prototype kind of call them interactive comps sometimes, which is just like, here's this thing, it's generally the production, like this is the view layer of your application, the honest to goodness production view layer, right? It's just doesn't have the data in there. And what you're able to do is have this extra layer of comparison of less like, oh, if things are slow, is it slow in the Storybook? Or is it just in the application code base? So, it unlocks new levels of QA and new levels of comparison to see what's going on and why and I really liked that.
Luke: I'm curious though, it feels like suggesting this as a way to do things would come up against the age-old, oh, but we don't have time for that. I mean, it obviously will save time in the long run, but I mean, if you were going to estimate how much extra time would you say it actually takes to do this as a step between, just documenting or just building your components and individual patterns in Storybook, through to, having it all in the production code. I mean, how much extra does it actually take?
Luke: Yeah, it's I mean, one, can you write, org design for front-end teams please?
Brad: Yeah. Maybe.
Luke: I think that that's definitely needed, that's the thing is when you say it, it just makes so much sense and I feel like it would have saved all of my product teams so much time in the past as well. Where have you been all my life Brad? So, okay. So you've got how your tooling and workflows work really well and this sort of sandbox environment that you work in, what are you missing? Like what are you waiting for? Is there anything that you're thinking about in the future where you're like, I just wish somebody would build, or, I wish I had more time to build this because it would speed up my workflow so much and make everything so much easier.
Luke: It's production-ready code, right?
Brad: Yeah. And any developer will tell you, yeah right, yeah right buddy. But there are opportunities to create the right handshakes in between the design and code worlds, design tokens is like a great example of that, where it's like, these values I could care less what the hex values are, but like the definitions of those things that I'm pulling into my code, I care very much about. So it's like design tokens have proven to be an area that we've been really finding a lot of success of like having our design teams kind of own, like we co-create the design token definitions, that naming conventions, developers tend to be a little bit more, tend to be better at systematic naming and conventions and things like that, whereas designers are like layer 25, copy 42.
Luke: Well, it's either that or calling the colors like, off eggshell, aubergine or something.
Brad: Sure. Sorry designers, not trying to crap on you but it is important, like designers and developers ought to be naming things the same, they need to be calling things the same and when you do that, that actually creates this opportunity as the tooling and stuff gets better, to actually have these things flow into one another. So it's like coming back to just like communication, collaboration, if we have a button and we have a prop on that button that says variant equals primary or variant equal secondary or variant equals tertiary in the design world, there ought to be the exact same component with those exact same names and in the Figma world it's variant and there's a dropdown that says primary, secondary or tertiary. That's a crude example of right now that is a manual effort, I am looking forward to the day when this matures enough, where it's like at the very least these names can be stitched together, even if the actual execution or whatever still needs to happen in parallel tracks. I remain sceptical of anything that's like automatically, you know, outputting to one or the other, even like backfilling things into design tools, there's a huge opportunity there, there's whole startups built around this there's loads and loads of different tools that are meant to bridge this gap. And I think that there's a good way to do it and then there's the way that I see it right now, which is almost, none of it is particularly good. It's a way of keeping designers and developers away from each other and that just shouldn't be the case.
Luke: That is the good thing, that it is, there is an attempt to standardize this and there is actually an official attempt to standardize this. I mean with the rate that standardization goes, we may be waiting a while, but I think they've got first draft, so that's good. But yeah, I think it's exactly what you were saying where it's like, I think everybody who's trying to implement this at the moment it’s at such a basic level that it's like, the idea is great, but there's so much process and workflow that you have to think of and consider to actually stitch it into the way that you’ll work in a way that's effective, but I can't wait for the day. And I think one of the things that's missing there is just it's, what you were talking about it's the communication piece in the middle. It's like having a system that can sync out both ways and is managed centrally is probably going to be an amazing concept, but the governance and the workflows that are involved to actually make that work in a way that's going to work in any organization, nobody's nailed that yet.
Brad: At the end of the day, the design tooling, the development tooling, all of that stuff is a commodity and will increasingly be so. It is the people, it is the people part of this as like overwhelming and you hear it. I get asked these questions a lot, actually, a fair amount where it's like, oh, what are the tools, like how do I keep my Figma library in sync with like my code base? Or like it’s often framed in this way, how do I get the developers to just listen to me, essentially, you read between the lines, it comes in the form of give me the tool that solves my people problem, and it just doesn't exist, that's the wrong mentality, software can help for sure, but it's not a panacea, it's not a solve for actually getting these teams closer together. And that's why I'm so passionate about coming back to the concept of front of the front-end developers. So the UI developer where I'm like, these are people that need to be a peer in the design process. These are designers, these are developers who happen to operate in the design team. And probably that's one of my biggest and in all of the design system consulting I do is, you need somebody and it doesn't have to be the entire development organization or engineering organization, you just need somebody that can play ball and collaborate with the designers and translate a design vision into code and bring the code capabilities, bring the realities, the limitations and opportunities of what you can do in the browser to the design process. And so the more that those people are co-located, so you have like a visual designer and a front of the front end developer actually like working together, then you're able to package that workup and ship it as a component library and ship that with confidence. And so the developers who are used to, please give me requirements and I will generate code, they could still do their thing and there's still a utility for those people and, God bless them, but it's like, not everyone can be that kind of developer. You need to have somebody that's able to go, oh, let me try that out or like, oh, let me push back on this idea that you're doing in Figma or whatever, because there’s weird source order things going on or like this isn't feasible or, oh, by the way, did you know that CSS grid could do this? What about that? Or what about this sort of like background, like blend mode or something like that. You need to have that representative from the code side that can actually make the design stronger. And when it's this sort of unidirectional, that's why I absolutely bristle every single time I hear the words, developer handoff, it's just like, no, and I've worked with loads and loads of really talented designers in my career, and I'm not like trying to disrespect them, but it's like, there is a perspective that is necessary in order to really paint a holistic picture of how feasible the design ought to be, sure that visual design matters, the brand matters, the UX matters, but then there's also this, how this actually plays out in the medium which you're launching a product, that also matters as a sanity check, but also again, as this opportunity where it's like the design can become stronger when you have someone or representative from the code world operating and as a design peer.
Luke: It's the same way that an architect and an engineer would work together, right? They understand the medium that they're working with and the constraints that they're working with. And quite often, the way that you can actually optimize how you build it and give advice of, oh, if you change this and actually it will work better this way, it's just standard. So with all of the companies you worked with, what have been the most common failings or misunderstandings of how developers work with design systems when you go into a new company and you consult with the new company and what are, I suppose, what are the ones that you just like, if you can get this in your mind now, this would make all of my future work much easier.
Brad: I think we've hinted around this, I think a little bit. There's a few things. One is, Design systems is a very unfortunate name. It's got design in the title and so very often it's like whenever we duck our heads into a lot of organizations, it's like the design team takes the lead and the organization understands this as a thing that the designers are doing. And then the engineers will then receive that, I guess, versus what we were just talking about, which is like, no, no, no, no, maybe even more so, the engineering organization needs to be fully on board with this, it's like a design system is absolutely part of the engineering landscape. So, that's one and again, the name doesn't lend itself to being like, this is a thing that developers need to own and tend to and care about and whatever. So that tends to be a common thing where it's like, there's, and again, it gets into like, what we've done in certain places is like, oh, the engineering organization really isn't set up very well for this kind of front of the front end role. And so what ends up happening is that the design end of the organization tends to, or can, we've done this a number of times where it's like, yep, it looks like you're hiring a few developers as part of your team and then that becomes the way to solve that. So, the engineering side, not fully understanding or embracing what a design system is one thing that tends to be a common issue. We see another common issue that we see is components being built in isolation, and coming back to this point of it's just like, oh, well, How much extra time does this cost. And like so many places, there's just like, if we could only just like, stop our work and like go off to the side and build this reusable set of components and then come back and pick back up on that. And again, that's a lovely thought, like good luck making that happen, it's like, Hey business, you know how we have all these things that we're trying to get done? We want to stop on all of that. So, this is again why all these years later, I find atomic design to be such a powerful and important concept because what you're actually doing is you're going, Hey, you know that mission-critical project we need to get done by Q1 like that checkout redesign or whatever, and re-platforming or whatever, we're going to do that and we're going to build a design system out of that, right. And then we're going to, you know that next thing that needs to happen by next Christmas, we're going to do that and we're going to build all of those pages and we're going to sort of build and bolster the design system through that work. So that was one of the biggest things that we see is like a lot of efforts to be like, we have a design system and here's a link to our Storybook and it's got like five or six components and they're kind of like cherry-picking things out from their product work and stuff. And it's like, no, no, no, no, this needs to be literally one in the same, the way you do your product dev work is how you do your design system work. These are not two separate tracks. This is like, the design system is how you do your development work, Period. And that's often where we tend to come in as sort of consultants is, it's like you have this, but we need to like hitch this thing to your very fast-moving wagon, that the business actually like cares about that your users actually can it's like the design system must be in service of shipping real product and if it's not doing that, it's a failure, it's a cost center. Like in whenever design systems become perceived as these cost centers, this is just a time sink, this is a resource sink, this is an energy sink it's dead it's not actually doing the job. And the businesses are right to kill those efforts or be super skeptical about them when it's seen as this, I know we have to do this thing over here, but like, we need to like do this other stuff to make our own lives easier, that's not a good place to be. So that's probably one of the biggest things. And then the other thing is, well, there's a number of other things, lack of a governance model is, is I think another one, which is basically people perceive the design system as this set in stone kind of thing, where it's just like the button is like this and even if I'm downstream from that button and the comp I'm looking at doesn't have the button in code doesn't look the way that I need it to look in the codebase, the reaction is well, time to either cut the cord or just hack the crap out of this thing and make it hammer hard enough to fit this square peg into a round hole, right. And so, one of the biggest things that we tend to do is really help formalize and establish that feedback loop between what the products need and what the system provides. And the sooner you could create that healthy feedback loop and this is sort of one of those things where, again, as a consultant, I love this role because it's just like, it's okay for things to be incomplete. It's okay for there to be changes. It's okay for you to run into the wall of, we need this thing and this thing doesn't exist. That's natural, that's part of the process. We can address that, we can fill that hole, we could create that new component, that new variation we could create that new concept, we can solve the problems we just need to have that feedback loop. So especially in the early days of the system, when there aren't that many solutions in place, there's a deal of trust needs to be this feedback loop established in order to get this thing off the ground. And then once it hits like a critical mass of maturity, then it gets into this, oh, this thing has most of what I need I might run into a few holes or a few blind spots here and there, but by and large we have what we need. That's what you want to get to. But in the early days when it's not quite ready for prime time yet that's whenever a lot of developers will just be like, without that governance process in place it's, I don't see this, so, therefore I guess I'm going to go reach for a material designer, uh, I guess I'm good to go just like roll my own, or I guess I can just go into butcher this thing and extended in like a weird way that doesn't work with the system. So it's like that's a developer thing that tends to happen, but it's also a designer thing too.
Luke: It's yeah. I mean, it's, it is something that always alarms me the lack of governance and contribution models with design systems. And it's like an effective one, ones that aren't just like, oh, well, they can just come to us and tell us what they need.
Brad: That's just it, it's like so many teams I work with and talk to, they just wish that it just happens. And it's like, no, no, no, this actually requires some work too, and again, it's so much of this, It's less about the tooling or like, we have a GitHub repo, I don't understand why people aren't adding issues to it. It's like, it's not the tools. It's not like the tools or the mechanics of it, it is literally the people and the relationships and the relationship building and the trust and all of that stuff. So it's like, that's the hard work with all of this is to basically be like design systems teams are a service organization, in service of the product teams that the design system is serving. So it really becomes this, it's a very humble job because your job is not to go, this is how it is. It needs to be, what do you need, how are things going? Are there anything that we could be doing better? Have you run into any weird spots? Can we like have a session? It's doing that proactive and very kind of like humble service-oriented. We are here to make your lives better.
Luke: Wait, Brad, are you suggesting doing, like actually talking to your users as a concept?
Brad: Weird, weird wild stuff. Yeah.
Luke: Okay, I could sit on here for hours and chat to you about this stuff, but I think it's about time that we ship you off to your desert island, okay Brad? So you get to take a piece of music, a piece of literature and a luxury item. So I suppose let's start with the music, cause it's obviously the easiest, what music you're going to take with you?
Brad: It's very, very hard, actually. Is it one piece of music? Is it like one album?
Luke: If you can pick one album.
Brad: I'll say Outkast Stankonia as an album I could listen to for probably years and years and years and have without it sort of going stale.
Luke: You also get to take a piece of literature. So what would you take to read on the island?
Brad: Probably the element by Sir Ken Robinson.
Luke: Okay. Is that, a Sci-Fi? No, no, no!
Brad: No, I don't read fiction. The element is a book about, I don't want to say its meaning of life stuff, but it's meaning of life stuff. Sure. it's about like finding where the element as he sort of describes it as like, were your aptitudes meets what you're passionate about. And that's like where people are truly in their element in life is where it's like, oh, you excel at this thing, you're passionate about it. And one of those things can be true without the other being present. So some people are really good at certain things, but aren’t particularly passionate about them, other people are passionate about things, but, never had the skill or know-how, so anyway, so that that's a book that's really resonated with me over the years. And I feel like if I'm stuck on an island and thinking about self-improvement and not going crazy, I would enjoy that one.
Luke: Sounds perfect. And of course, you get one luxury item as well, just to make your days a little easier. So what would the luxury item be?
Brad: Either a drum kit or my bass guitar or both.
Luke: I actually think that you could get a rig where you could drum
Brad: There we go. My one man band.
Luke: Perfect, That sounds amazing.
Brad: But it is something that, I play music every day and to not be able to do that would be absolute torture. So, that would definitely be top of the list.