S02E06: Brad Frost
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!
Show Notes
Transcript
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.
Brad: Yeah, there’s so many, there’s so many, there are so many benefits from a dev perspective. I’m finding that I’m almost a little bit of an outlier in this perspective, but I basically treat everything as a reusable component from day one. There’s other perspectives out there that they’re basically, once you arrive at the third use case then, ah, that becomes a pattern there. That’s not how it works. What ends up happening is by the time the third team needs a thing you’ve already hacked the crap out of everything. And you have a big mess that you now have to clean up. So it’s like my overwhelming perspective and just operating model is, everything is a reusable component, take whatever you’re working on as a front-end developer. And if you’re having to write markup, if you’re having to write styles, if you’re having to write presentational javascript, how do you write that once and have that be maximally reused forever and ever amen. It’s that, how do you strip it of its context of its content? How do you make this the most generic versatile component you can make it. And it’s not extra work, it’s not extra dev work to make that happen, it’s a mental shift more than anything else. Rather than calling it homepage carousel, you call it carousel rather than calling it FAQ accordion, you call it accordion. These sound like dumb ideas, but like holy smokes, you would be very, very surprised, as we go into all these different things, all these different places and look at these different code bases and libraries and things like that. There’s a lot of stuff that should be reusable, agnostic components, are instead these one-off kind of things. And then there ends up being a bunch of rework or reconciliation amongst all of these things, or like looking over shoulders and then recreating and it’s like to touch those things, especially once they’re powering real products, becomes a big, scary mess. So, that’s why it’s my overwhelming, we’ll say, advice to developers is how do you boil any of your front-end work down into the cleanest, purest, most reusable, most extensible, most agnostic components possible. And by doing that just right out of the gate, you’re going to save yourself a lot of time, a lot of energy, a lot of agony and not have to go this whole refactoring change management, blah, blah, blah.
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
Brad: but that’s not really like a tool and people get at me about this where they’re just like, well, like how do you structure your code base with atomic design? And I’m like, I don’t it’s more a way of thinking about it and it continues to be really good. So, I’d say that a hundred percent on all of my projects since 2013, what I call a front-end workshop environment is the bedrock of a design system, development environment, I guess. And what these front-end workshop environments are, Storybook is certainly the predominant one now and that team has done some amazing work to get it to where it is today and it’s really, really exciting to see all that go. As I mentioned earlier, I created one called pattern lab, which turned it into a big community. Other developers helped develop that software, that one’s more conducive for things like Twig and less modern JavaScript frameworks. And then storybook is more conducive for React, view, angular, web components and things like that. As more things have been going in that direction, Storybook has become the de facto leader in this front-end workshop environment. But what these front-end workshop environments do is give you the ability to build UI code in isolation. And that was why I created pattern lab all those years ago, was this I don’t want to have to spin up a WordPress instance in order to make my buttons orange. Like, I don’t need a database to do that, I don’t need this stuff, I don’t need the data, I just need a sample of that. And that’s the spirit of these things is like to be able to build UI code in isolation, these front-end workshop environments give you this canvas with which to paint. But not only that it, of course, coming out the other end of it, you have documentation around these things, right? So it’s like they do a lot of heavy lifting and I think what I find in my design system work as I go in and consult with all these organizations, is that dev teams treat Storybook as just the documentation part of it. Whereas what we tend to do and what we’ve been doing since 2013 has been using these front end workshop environments, not just to document, here’s what our buttons look like, here’s what our accordions look like and things like that, but to really play out the whole spectrum of atomic design, like here’s this low-level button and here’s how that button gets included in this card and here’s how that card gets included in this card grid and here’s how that card grid gets included on the category landing page and then here’s what that category landing page looks like with women’s shoes in there or men’s shoes or children’s shoes, or here’s what it looks like when it’s on sale and here’s what it looks like whenever this thing is, out of stock or whatever. So what we’re able to do is not just design and build these UI components in isolation, we don’t do that, we build the components through the lens of real project pages right? So that’s what we do. And like 90% maybe even a hundred percent of the Storybooks and other things that I see, like other teams doing, just have like the components. And I’m not saying that that’s like not valuable, but it’s like, how do you know that all of these components come together to form a cohesive whole? And oftentimes you don’t, or there’s like a big chasm where it’s like, oh, well we like assemble them all in the product environment and that’s where we really played these things out. That creates too big of a feedback loop. Between like the low-level UI components and the pages, so what we have is an opportunity to shorten that feedback loop and to co-locate not just the components, but also pages that are built using those components. And then what you’re able to do is ship the component library, publish that as a package or whatever, with a greater deal of confidence. So like fewer things come back into the component library world as like a bug ticket or something because you’re like, oh no, we already took care of what it looks like for a new customer with an empty state or something like that. It’s like, you’re able to like play all those things out in a very sort of light prototype B kind of way.
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?
Brad: Negative extra, negative extra. This is a time-saver, not a time adder. And that’s with all things design systems, right? Like, oh, this is going to take us so much extra work and it really isn’t, mentioning earlier, it’s like by way of just thinking about things differently, you’re not expanding your timelines or your sprints or whatever, like in order to accommodate a lot of this stuff. So much of this is just thinking about things differently. But to come back to your question is, does this take extra time? And the answer is, you have to build the front-end UI in order to build the whole product you need to build the parts of that product, right. So what you’re doing is you’re just kind of shifting the point of production out of the application environment, which is clunky, you just find yourself tripping up over again like tokens and APIs and all of that stuff. And what you’re able to do is oftentimes parallel-track these things. So it’s like, this has been one of my big soapbox things, has been actually creating a real line and distinction between developers who specialize in UI code, HTML, CSS, and presentational JavaScript. Presentational JavaScript meaning you click on the accordion and it opens, you click on the accordion again and it closes. That’s a different kind of javascript than writing up some middleware, like doing all this stuff of Firebase and whatever. Not that, they’re both important, they’re both equally important for making a product go. So what we end up having is we have, and again kind of coming back to, and like leaning on this, like, does this take longer? It’s like, what we’re doing is we’re kind of creating the right swim lanes for people to do their best work. And so it’s like you have a UI developer that’s able to work primarily in Storybook to build the UI code that will power this product and then you have the application developer who is then freed up to do more of this back at the front end work as I call it, there’s like front of the front end work and back of the front of work. So what we tend to see, is people like me, whenever I’m involved in building these design systems with my clients is me and my team like building that front end code in Storybook. The application developers are writing all their business logic, doing all their stuff, wiring up the sort of routes, doing all that business. And then we meet in the middle. And meeting in the middle is, we publish a library of reusable components that then gets pulled into their development environment, into the app environment. And their, yes, is a, let me copy and paste, literally, these templates that were created, but we’re going to rip out the part where it says, page header, title equals men’s shoes, that’s hardcoded in there. And instead, we’re going to rip out men’s shoes and swap that in with whatever the call is to whatever service, that information that text string is coming from. So it’s really, there’s no difference in the dev time required to do this, you’re just adding a little bit more nuance about where that work happens. So no change whatsoever, but like, by splitting it out you end up with a more elegant workflow that in essence saves time because it prevents front of the front-end developers from having to get tripped up and just even standing up their environments. It’s like whenever we have to work in a client’s dev environment, for very lousy reasons, honestly, it’s like we’ve literally taken weeks to just get the environment stood up and it’s like, that’s just time wasted. Meanwhile, if we were able to work in this more nimble front-end workshop environment, we would have had two more weeks of work done. So there is a time saving that comes with this split. It’s just a matter of just thinking about where certain work should happen.
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.
Brad: Hmm, that’s a really good question. I think that there’s a few things, and none of it is brand new concepts, I think is just like a matter of having certain things be a bit more mature. The big one that we’ve been building design systems with our clients and web components in recent years. And even in the three or four years we’ve been building in web components, there’s been a lot of improvements and a lot of maturity happened in that world. So I’m very bullish on those and for the uninitiated web components are like building reasonable components in a native web way, this is like part of the web, this is not React, Angular and Vue.js, these are all wonderful, wonderful, JavaScript frameworks, they are also proprietary, they’re like, not part of the formal web landscape and web components are especially conducive for these very low level dumb reusable kind of building blocks, just like dumb little blocks of HTML, CSS, and Javascript that need to travel and look a certain way and function a certain way, they’re contained and so the web component world is getting better. And so I’d say that that’s like, one of the things that I am excited about and feel like we kinda like hit up against some edges, I think a fair amount of how you work with these things and stuff like that. But also there’s this opportunity because, it’s not that, web components are going to necessarily replace all of these proprietary frameworks. Each of these things like the react world and the angular world and the view world all still very much have a real good place in the ecosystem, especially when it comes to making things work properly, like state management, the routing, the like all of that sort of stuff. It’s not an either or, I see them as very, there’s a good handshake and we actually have a few client projects right now, what we’re doing is we’re basically we are creating this sort of web component-based library that then gets ingested into a react library or an angular library, or some other framework to make it work. It’s like web components are really good because they could go anywhere because they’re just part of the web. You can like launch it onto a WordPress site or whatever, in addition to into a react library, and then have that go and it’s pretty awesome. And that gets to the heart of what we’re trying to accomplish with design systems is this consistent look and feel, this consistent experience from a user perspective because your users don’t give a crap, if this part of the experience is powered by react, but the checkout flow is in angular and like this other part is a Drupal site or whatever users don’t care. They just want consistent-looking buttons. We finally have a way to make those consistent buttons that can go anywhere. So I’m excited about that, I think that there’s going to be a lot of opportunities coming up. I think that there would be some like really, but again, it’s like still a little bit kind of clunky, a little bit sort of making this all work and get orchestrated together, so there’s that. And then on the other end of spectrum, so that’s like squarely in the dev world. It’s like we build web components and then there were like propagating those web components out to other frameworks and environments, that’s exciting. That’s an area I’m really bullish on and I’m looking forward to, on the other end, you have the whole split between the design world and the development world. And that is its own beast and you have tools like Zeroheight that are like doing a lot of good to bridge those worlds together. You have a lot of other tools that, at least on the box or what they proclaim to do, are to try to bring these worlds together, but in my experience, and if you’ll allow me, so much of this software and a lot of the tooling around bringing design and development together, or at least that’s what they proclaim, it’s actually doing anything but. We are such big proponents of the best tools of all which is just communication and collaboration. And, what we now have is hundreds of millions of dollars of VC software basically erecting a wall in between the worlds of design and development. And so I think that there’s a big opportunity, and it’s not that software is inherently evil, of course, there’s all sorts of opportunities there, but yeah, a lot of people are profiting from, oh, the designers are going to stay over here and then we’ll have our like developer handoff button that does our thing and then the developers will come in and it’s just like this, or they could just like talk together they could just like jump on a Zoom call and like work through these things. So there’s, I think, a lot of opportunities to create a more respectful and more equitable kind of workflows where designers and developers are actually working together, but also, getting to this thing that we’ve been after since the dream Weaver days and Adobe muse and all of this stuff, which is what is that split between, can designers publish things that ultimately go into code, and how do we make this a more automatic process and how do we get our Figma library to just flow into code or vice versa. And I think that those are really fun and exciting and good things to explore. I remain sceptical, as any developer is, any design solution that says, oh, we push this button and it generates the code.
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.
Luke: Brilliant.