Episode 132: Moving From Bricklayer to Architect

A conversation with Nick Hahn. Design Systems Strategist, Design Leadership Coach Formerly at IBM, InVision, Meta

This article was originally published on?voltagecontrol.com

“Design systems are the tool that enable us to step out of being individual makers, crafters on particular interfaces. And it elevates our craft to a point where we’re able to spend more time focusing on our users, bringing in our stakeholders, collaborating more and less time just kind of grinding through production. That might be scary to some people, but I genuinely think it’ll be a better job in the teams that are already doing it. I’m seeing that as well. It helps us just be a more valuable set of contributors in any organization.” — Nick Hahn

In this episode of Control the Room, I had the pleasure of speaking with Nick about his experience working in Design Systems and adopting tech while keeping the people in mind. He begins with reflections on collaboration. Later, Nick explores cultures of innovation and the importance of ‘first draft thinking’. We also discuss feedback loops, governance, and starting small when implementing change. Listen in for example of the value of design system.

Show Highlights

[1:50] How Nick Got His Start

[6:00] Asking How You’re Going To Collaborate

[15:00] Adopting First Draft Think In Design Systems

[28:00] Using AI In Design Systems

[37:00] The Value Of Design Systems

Links | Resources

Nick Hahn on?LinkedIn

Nick’s Personal?Website

About the Guest

Nick Hahn is the founder of Creative Liberation, a coaching and design consultancy. He has spent 20 years riding the rise of the Design industry through agencies and inhouse at IBM, InVision, and Meta. Nick now specializes in the human side of Design Systems — governance, contribution, and adoption models, all while guiding the deep cultural changes needed to ensure long term success of those systems. You can find him on LinkedIn and at Nickhahn.com

About Voltage Control

Voltage Control is a change agency that helps enterprises sustain innovation and teams work better together with custom-designed meetings and workshops, both in-person and virtual. Our master facilitators offer trusted guidance and custom coaching to companies who want to transform ineffective meetings, reignite stalled projects, and cut through assumptions. Based in Austin, Voltage Control designs and leads public and private workshops that range from small meetings to large conference-style gatherings.

Subscribe to Podcast

Engage Control The Room

Voltage Control?on the Web

Contact?Voltage Control

Full Transcript

Douglas: Welcome to the Control The Room podcast. A series devoted to the exploration of meeting culture and uncovering cures to the common meeting. Some meetings have tight control and others are loose. To control the room means achieving outcomes while striking a balance between imposing and removing structure, asserting and distributing power, leaning in and leaning out, all in the service of having a truly magical meeting. Thanks for listening. If you’d like to join us live for a session sometime, you can join our weekly Control The Room Facilitation Lab. It’s a free event to meet fellow facilitators and explore new techniques so you can apply the things you learn in the podcast in real time with other facilitators. Sign up today at voltagecontrol.com/facilitation-lab.

If you’d like to learn more about my book Magical Meetings, you can download the Magical Meetings Quick Start Guide, a free PDF reference with some of the most important pieces of advice from the book. Download a copy today at magicalmeetings.com. Today, I’m with Nick Hahn, the Founder of Creative Liberation, a coaching and design consultancy where he specializes in the human side of design systems, governance, contribution, and adoption models, all while guiding the deep cultural changes needed to ensure long-term success of all those systems. Welcome to the show, Nick.

Nick: Hey. Thanks, Douglas. Nice to be here.

Douglas: Great to have you. And as usual, let’s begin by hearing a little bit about how you got your start in design systems.

Nick: Yeah, it actually goes way back in the day of selling computers at Gateway Country. If you remember the cow box where I’ve figured out that I love connecting people and technology and kind of understanding the human side of things, and knowing the geeky side of what’s out there and what tech is there and how to make great experiences. So ended up in the agency world, had my own design consultancy, and then went off and joined IBM where I was a design principal there leading a bunch of design system projects. And then went to Envision and then Facebook/Meta, and now I’m back out on my own. So kind of did a full circle.

Douglas: Wow, and what a ride like giant computer sales to your own professional services, to Big Blue, to then kind of smaller startup by those comparisons, and then back to one of the big fangs.

Nick: Right. It was quite the scale difference, but it’s interesting to see the patterns that come out in the human side of things, regardless of if it’s a five-person company or a 500,000 person company, they’re still the same kind of idiosyncrasies that people do, and the politics and how things get made is very similar.

Douglas: It certainly plays out very similarly and it’s still baffling to me how often companies will focus on the technology, the process, and the logistics or the timeline, and really just ignore all those people issues.

Nick: Yeah. My time at Envision, I was leading up the team that consulted with all of our customers that were buying design system manager, so trying to implement design systems. These were vast majority of the companies we worked with were international enterprise level. And so, time and time again, we got to hear them say, “Oh we started building our documentation site. We started putting together the componentry.” And I would ask them, “Okay, who’s involved? Who’s going to end up using it?” And they’re like, “Oh, these two dozen teams.” And I would ask, “How many of those teams have you talked to yet?” And they’re like, “Oh, maybe a couple, two or three, but we’re already building it. It’d be great when we build it, they’re going to start using it.” And that’s the immediate first red flag of a probably going to be a failed design system.

Douglas: Absolutely. I mean, just like anything, lots of product companies have adopted design thinking as a way of building better products for customers, but it seems like employees and systems and processes for employees just somehow they don’t bridged those practices over.

Nick: Yeah, it’s fascinating talking to fairly senior level designers and design teams that are quite mature. And when I asked them, “Well, what about adoption? What about governance?” They fall into the same trap of the engineering teams that they used to work with when kind of rolling out design thinking and going, how about we do discovery first? And so, posing that question to those teams is often a light bulb moment of just being asked, have you done the discovery work? Have you done the staging work before you start building? And it’s just a human nature thing to want to, well, I’ve got this stuff, I can start tinkering with it and I can start putting it together into a cohesive thing. And it feels like progress.

Douglas: Yes, we’re all drawn to the quick wins and the easy progress. And to your point, for design teams, it’s probably easier from the grass because they’re already doing it for products. It’s like, oh, let’s just apply it here. I think when it comes to other teams where there’s change with inside an organization, sometimes harder for them to realize what they’re missing because they haven’t experienced it before.

Nick: And my experience at IBM, I was managing the cloud platform design team, and we got to work really closely with our engineering and product teams, and it was far more engineers than designers. They were trying to standardize the look and feel of all the cloud apps across, across IBM and getting each individual team to do that was a monumental task. I mean, just changing the header bar, it was getting 50 different teams to update their code. And so, the need for some sort of cohesive system was clear, and most companies that had that light bulb go off that we have to standardize these components and make it so that every team can use it without updating everywhere. So there’s a lot of complexities with shifting the mindset from being a team that builds individual pieces on my product to teams that build products or pieces for the greater system.

Douglas: I was talking to an insurance company recently and they had this big initiative going, and they said to me, “The good news is that we’re collaborating. The bad news is that we’re collaborating.” Which is kind of made me chuckle, but then I stepped back and I thought, well, there are better ways to collaborate that are going to will scale. There are ways to design these things so that we can move quickly. But the thing that I think people miss is that you do have to take a moment and step back and do that upfront work to then lay that foundation to think about how are we going to collaborate in a way that’s not just gridlock.

Nick: Yeah. One of the jokes I have in the design system world is the US government, when it first was founded, didn’t start building roads and build a bank and an army and then come together and make a constitution. They got the 13 states together and said, “How are we going to collaborate, and what’s the governance of how we’re going to function?” And then they started doing the rest of that stuff. And so, just taking that kind of approach to how to get dozens or hundreds of teams together to collaborate has been much more effective, I’ve seen.

Douglas: And also, it’s thinking about your comment earlier about people’s propensity to bill things. I don’t think that’s necessarily a bad thing. It’s not a bad habit to go and tinker and build things. I think when you combine that behavior with the behavior of that, we often fall in love with the things that we make. And so, when we’re holding those two deer and near. Because if your brain needs groups together and you’re tinkering, you’re showing stuff off and learning and using those as ways to get input from people, then it just kind of shifts the mindset of let’s not hope that this solves everything and just be in love with it.

Nick: Absolutely. It’s really important to feel like you’ve got the freedom to tinker. The blocker that people end up encountering is they go, okay, now the design systems team, we are the centralized team that will own the design system. They’re tinkering, but then they tell the other teams that will end up consuming the system, “Hey, we’re building this thing. We’re very excited for you to use it someday.” The gap there though is that those teams that are going to use it should also be co-collaborators and contributors from the beginning because it should be happening with them, not to them. And that’s where facilitation and design thinking and all of these collaborative techniques that you and I love so dearly come into play.

Douglas: Yeah, absolutely. And how can we invite them into the tinkering?

Nick: Yes.

Douglas: What are some ways that you’ve seen that work? Well, I think your experience at IBM is especially telling there, and it’s like how to see that find its way through more of the organization, not just the small pocket that we’re occupying.

Nick: So IBM’s a great case study, and then we actually replicated it. I got a chance to do the same thing with the team over at Boeing. But for instance, at IBM, we had 22 distributed design teams all on the cloud platform that contributed to it all over the world, and we kicked things off with a design jam. So instead of us going as a design team, centralized design team, we know what components we’re going to build and we’re going to start building them. We did a three-day collaborative design exercise where we had all the different people from all over the world come together. We structured the facilitation of it, we kind of organized what we might work on. But then individuals got to select what area they were specifically, what component they wanted to work on, and they self formed in the small teams.

Those small teams then owned that component or set of components over those three days. And we have multiple rounds of diverge and design and come back and present and get feedback, and that was the seat of it. And not only did that help give us an immense amount of stuff to start with, it also made it so that the other teams had ownership into the design system from the beginning.

Douglas: So sounds like there were a lot of people involved. I got the impression there was a lot, but give me a little bit more color on the types of folks that you brought in.

Nick: Yeah, so I’d say it was 80% product designers. The other 20% was front end engineers and product managers. There was just less of them because most of the work for that initiative was heads down, design time. And so, when you’d have a front end engineer on one of the teams, they’d be more there for reviewing and kind of giving feedback instantly. But 22 design teams, I forget exactly how many, I think we ended up, we didn’t take every person from those teams. I think the actual design jam had about 50 participants from those 22 teams.

Douglas: Oh, wow. I mean, that’s a sizable workshop.

Nick: Yeah, it was cool…

Douglas: Sizable gathering for that matter.

Nick: Yeah, gathering. It was cool because it was a traditional kind of design thinking workshops or more post-it notes and get away from the computer. This was almost more like a design-a-thon or hack-a-thon. It was structured in a way where there was enough heads downtime, they could produce content and then come back and get it critiqued.

Douglas: I’m actually a big fan of those types of workshops and events because it focuses on the generation of prototypes and things that can then be tested, and if we’re all doing it together, there’s kind of this dedication to the outcome that we’re all putting in the moment.

Nick: One of the biggest design thinking tactics that we used at the end of this that I had failed a lot with when I first started my facilitation journey was the clear next steps. We did all this work and we have all this energy and everyone’s kumbaya, but what happens the next week and month and two months later? We had a dedicated half day to just assigning work and people delegating themselves to take on parts of the project because it really was the start of a huge 18-month-long project. And so getting them going and saying, “I’m going to be the person that runs this part of it,” was a massive step and I’ve seen a lot of teams skip that or just quickly brush over, but dedicated time to that is a huge value.

Douglas: I’m a huge fan of commitments. We always think about when we’re closing either the day or the series of days, how do we ensure that people are making commitments to themselves and to each other so that we really land the plane? Because if there’s not some prioritization and some ownership coming out of it, oftentimes people will reflect back and go, “Hey, that was fun, but was there any business value here?”

Nick: Yep. A 100%. And I’ve failed at that several times, and so I’ve definitely ingrained into me that you got to have that dedicated time to commit to things.

Douglas: Absolutely. And so, one of the things that we spoke about briefly in the pre-show chat was how often organizations are shocked at the sheer number of people and different types of people that get exposed to this work when you start really opening up design systems and what’s required to really have them take root. And so, you mentioned designers, engineers, product managers, but I assume there’s probably other folks that are impacted that ultimately need to be brought in when you’re talking about adoption and governance and stuff. Do you want to elaborate on that a little bit?

Nick: Yeah, so design system is really the instantiation of a brand into digital products. And so, you’ve got to consider what’s the brand layer, what’s what things are owned by brand? Is it colors and typefaces and all the other stuff that we think of in brand guidelines. So immediately working with your brand team is a huge thing you should be doing from the beginning. If there isn’t a brand team and maybe this hired a consultancy, you have to accept the fact that you’re going to be doing some branding work. You’re going to define some tokens in the design system. There may not be a tertiary color you might need to do that, you may not have a disabled color. That kind of stuff you need to design and create during the process.

There’s communicating with legal, with compliance, with globalization teams. I mean, there’s so much that goes into it that go beyond what the standard like, I’m going to make a card component. Well, all the things you need to make that a live component that can be used in UIs all over the world is a lot of work and typically is done in part of the production process. But the cool thing with design systems is you can centralize a lot of that like accessibility. You can do a lot of that accessibility work in the design system versus at the end of every production cycle of every product you’re making.

Douglas: So that upfront consideration is going to require some coordination with other teams.

Nick: Yeah, it’s huge. There’s also some interesting things around content and content strategy. Just being able to, content design is such a big deal now. There’s so many content designers, it’s really great to see that that trade sort of mature over the last few years. And now, you’re seeing heads of content design, and so, maybe your content designers aren’t staffed to your actual software product, but getting them involved from the beginning. What’s interesting is content designers are actually a lot more comfortable with governance. I’ve been talking to a lot of them lately, and product designers tend to go, “Ooh, governance, I don’t know. I don’t necessarily want you all to be telling me what to do.” But content designers are like, “Oh give me the structure so that I can work within that structure.” And so, there’s a bit of a marriage there of blending those two kind of cultures where governance isn’t a bad thing, it’s something that gives me bounds to work within just like any design, and I know the bounds I can play within to do my creativity.

Douglas: That’s super fascinating. I mean, do you have any thoughts on how that came about, why they would be more resistant or whereas the other group embraces the governance more or the structure more?

Nick: I think it has a bit to do with the way we typically would go through a design school or art school. It’s like my design. I’m doing my project and I’m presenting my thing, and then I get into the enterprise world or the product design world, and now everything I’m making has to fit into everything else, and I have to take into opinions from a lot of other people. So there’s already a little bit of educating early career designers to be really comfortable with presenting unfinished work and getting that feedback early. So breaking that bit of a cultural norm of, I’m just going to work on this until it’s done. And I shouldn’t have to listen to other people tell me what should go into it is just a kind of baggage that we have in the design world.

Douglas: I think that shows up in a lot of places too, because I’ve worked with folks that are really apprehensive about sharing the ugly baby, and some of that is because of the way they’ve been treated in other organizations.

Nick: Absolutely.

Douglas: If people got shut down because something wasn’t perfect out of the gate, then they’re going to be very apprehensive to start sharing again.

Nick: Yeah. Providing feedback and giving good critique is, you have to be emotionally sensitive or and have emotional intelligence enough to know how to deliver that. And also just have a general culture of feedback is a gift, but if it’s Why does that look like that? That’s stupid kind of feedback, then people are going to be much more ins isolated or insular on what they share.

Douglas: So I wanted to also touch on something that was really fascinating to me and was this idea that once people start to use design systems or start to even explore them, it can be an awareness moment around the maturity of their organization or a light bulb goes off that, oh wait, there’s some issues here that we haven’t seen yet, and so we’re really curious. I mean, it sounds like it’s very common, so I’d be curious to hear a couple story or two about how that’s shown up and what does that look like when they’re coming to that realization?

Nick: I was working with a bank, a pretty legacy bank, and at the time, this is in roughly 2020, they had just stopped using PDFs to email designs around to get feedback. So it’s the way we handle digital design 10 plus years before that. So it was kind of a shock just for them to go like, oh, we can just upload stuff and share it digitally? Yes. So the idea of doing a design system where you have to have designs which are both in sync, the things that are in design and in code, and knowing how design and developers have to overlap and not just do a handoff in a waterfall style.

Realizing that they have to work in a different way was definitely a shock, and that’s where you can tailor how much change you want to take on by that design system. Sometimes design systems are okay just to be a small little micro project in your collaborating with five design just design teams to get them to kind of function in the same way, but that’s like the first step in the evolution. Eventually you need those design system componentry to be in code, and so, you got to work with the developers to make that happen. So gauging what maturity level an organization is at will change how big or grand that the vision for that design system is right now.

Douglas: And have you found success in starting small and kind of growing it?

Nick: Yeah. There’s a couple approaches. If you can find, and actually I was working with a client who their larger development organization was fairly hostile. They didn’t have a good working relationship with them. The stakeholder I was working with was in the design organization, but they had a couple of front-end developers that were interested in being involved with it. So they just invited them to be part of the process as a side project, and those developers were happy to join. And what they did is instead of building 30 components or 50 components and building a big site in design and maybe even coding a few of those.

They decided, “Hey, we’re going to start with one small product that’s live and we’re going to convert a couple of those components into design system components.” So starting with two to three components in the library total, and then just making sure that those components show up in a product is really, I would say, more of a design system than having a library of 50 components that people just look at. If it’s going straight from design all the way to code and people are contributing to it, that’s a system.

Douglas: Yeah. It comes back to your point around adoption. If it’s not making the code, it hasn’t really been adopted.

Nick: Two interesting words in here. There’s adoption, which I typically use to mean as, is it culturally adopted? Are people actively contributing to the system that, are they starting their designs and development work F by going to the system to pull from it? That’s adoption to me, and then there’s implementation of the coded components into product. And those are two distinct things. You can have a hundred percent adoption, everyone contributing to it, and it not showing up in end product. It’s not implemented yet into end product.

Douglas: Yeah. You’re thinking in the terms of buy-in that people are into it and contributing.

Nick: Correct.

Douglas: I guess, when we’re thinking about helping with adoption with relation to a change in the organization, people can be bought into it, but if the follow through isn’t there where we got the business value, we haven’t nurtured that.

Nick: Correct.

Douglas: That adoption’s not rich enough because at some point, there’s a broken link in the chain.

Nick: Yes. It’s interesting if you can measure adoption almost down to the individual practitioner level. If I’m a designer and I sit down and I have to work on a new design, do I go and Slack my coworker and say, Hey, can you send me that Figma file that we used last year so I can start from that? Or do I sit down and open up the design system, look at the guidance and start pulling the stuff from that and using the tools that are in the system and then going how, oh, great, there’s a card component. It does 90% of what I need to do, but it’s missing something, so how do I give that feedback into the system? If you can start in that place of, I’m literally starting with the system and then working from that versus, let me just comp something up real quick, which is when these systems get really splintered and stop being a system.

Douglas: It’s really interesting because that word system gets thrown around a lot and not everyone has taken the time to look at systems theory or think about what the word system means, and what you’re describing is if it’s not a living, breathing thing. It’s not a system if they’re not inputs and outputs and feedback loops and whatnot, it’s not really a system. And so, I love the fact you were pointing out a feedback loop right there, which is a critical element of any system and how if we don’t have the ability to notice something is not serving us and then point that out and have it addressed then it’s not really a system.

Nick: I mean, I’ve said the word governance a few times, and when I talk to folks about design systems, they oftentimes need a bit more detail about what governance means. In this case, it’s literally that it’s, “Hey, I’m a designer on product A, I’m using that component, it doesn’t serve my needs. How do I get my voice heard back into the system and make sure that that’s validated and I get output from it at some point?” It’s like it’s contributing to a law. I give feedback to my government and hopefully that feedback turns into something that makes a positive change, and there’s plenty of broken governance systems, so always attributing it to a local government or something is not necessarily the best example. But just having agreements in place so that you know how to operate in that exchange is really important.

Douglas: What’s some simple examples for those wanting to get started that kind of provide enough structure, but to have some governance there?

Nick: I always like to do some sort of workshop. I love the idea of kicking off with finding those initial stakeholders, getting some degree of support, even if it’s an unsanctioned project from the higher ups, you can use your side time to gather some folks together. And get people together to define what is the real problems that we’re trying to solve with what we think a design system is. Design system as a term is like UX had been for 10 or 15 years, just this broad umbrella term. So I see people trying to do a design system and they’re calling 10 different things a design system.

So get together with your stakeholders, get together with the people that might end up using it and ask them what they think this thing should be and start building it together. Get some sort of consortium together, definitely the best place to start. Then you might say, “Hey, I’ve got a bunch of Figma libraries or a bunch of sketch libraries,” and then we can throw those together into a pool and start mixing matching. Great, but that should be after you get the folks together and run some sort of facilitated activity.

Douglas: It’s a theme that I’m hearing. It’s not just a library of things that people are throwing to that gets varying levels of usage, really a cultural thing.

Nick: Correct. Here’s a quick story. One of the designers that I used to manage, a phenomenal designer had been doing it for years, UI design for years and years. She said to me once she understood what a design system was and how it’s going to impact her job, she was like, “Okay, so the design system’s going to have all the design done in it, so what is my job?” And her question was rooted in my value. She didn’t say these words, but this is what it meant. My value as a designer has always been represented and how many wire frames and prototypes I build, how many on knockout? You’re saying to me, I don’t have to make as many, aren’t many wire frames or prototypes anymore. I can just sort of cobble together stuff from the system and I’m like, “Yes, that’s the point. Now, you can go from being a brick layer to an architect,” and that’s the thing you always been asking. You want to be at the table, you only where the decisions are happening, you will now have time to be at the table versus just pumping out wire frames.

Douglas: It’s really interesting to point that out because when you describe it from the point of a brick layer versus an architect, that’s some clarity in that, right? But people don’t always see it from that vantage point because if they were trained to be that brick layer, that’s kind of what they valued about themselves. There’s some identity, there’s some sense of self there and there’s some pride in craft. I’m really good at moving these pixels and not really realizing that the 10% of the time that they spent really creating the best flow possible or just some of the nuances of the things they just have done innately because that’s the way they flow them out or respond to user input or whatever. So pointing out that there’s the real value, even though you spend 80% of your time moving the pixels, the real value is the thing you’ve been spending 20% on. What if you could spend a hundred percent of your time doing that?

Nick: And honestly, the irony is that even that person and many people I’ve interacted with in that same situation, they will on the side also complain that they’re in meetings all day and they don’t have enough time to do the designs. And if they just had more time to do the design, it’s like it’s this catch-22 of if the time spent doing the pixel pushing is reduced dramatically, you then have the headspace and the actual physical hours in the day to go talk to stakeholders, go do interviews, listen to the research, collect the data so that you can best represent the user in the company.

Douglas: Also, if it’s less laborious, you don’t feel so attached to throwing it away. If you can more quickly cobble together to use your word a prototype and get feedback on it and it’s not the right thing, just do it again. It wasn’t that much effort to do it.

Nick: Yeah, you’re not spending all that time moving. I mean, 10 or 15, 20 years ago, we spent so much time designing buttons like pixel perfect. What’s your corner radius now? Almost nobody designs buttons. A few people, we used to spend a lot of time designing typefaces. If you’re spending your time as a UI designer designing typeface, you’re not spending the right, not spending your time where it should be going. You can do that on the side. That can be a thing, but that’s not the role of a UI designer. Same with visual designers.

I mean, when I joined IBM, we, our teams were staffed. Each team had a visual designer. We found out real quick that once you have a design system or even a decent UI library, visual designers don’t have that much work to do. You’re not type, you’re laying things out anymore in the same way you used to. So that trade kind of changed in what they do, and now the visual designers might be on the brand team or on the design system team helping define it at a top level down, but they’re not on each individual product team.

Douglas: It’s also making me think about how this phenomenon we’re discussing shows up in other places as well because let’s look at the rise of AI and ChatGPT and all these other tools that create generative inputs. That’s cutting a lot of the busy work, a lot of the equivalent to the pixel pushing out, right?

Nick: Yes.

Douglas: And it’s really frightening to a lot of people, but I think the thing that everyone has to keep in mind is that, Hey, let’s embrace that. What does that free up the time to do? What new opportunities can we move faster and not have to sit here and do that piece anymore? It’s like that’s really super fascinating. And so, I guess, to bring it fully circle, are you seeing any new AI tools that are emerging impacting design systems?

Nick: Not yet, but from the new batch of stuff that’s come out, I’m really excited and kind of keeping an eye on it to see who applies this technology to design systems. I do think there’s an opportunity to use those systems, those AI models on if you have a robust design system and it says create a login through checkout user flow, it could probably do that and then create a new version of it, and then you could iteratively test it. There is a tool from Adobe, and I forget the name. It was a concept where you could sketch out on paper and it would visually look at that sketch and then create a coded UI based on the design system it’s tied to. So it was very rudimentary, but this idea that I could sketch maybe something on a whiteboard and then that pops out a coded prototype that I can have users use is that’s where you get into really cool tight cycles of iteration and learning that we’re really hamstrung from doing now because it takes so long to produce a single prototype.

Douglas: I’ve been watching Mid-Journey pretty closely.

Nick: Interesting.

Douglas: I’m really fascinated by that. There’s some interesting stuff that I think is possible and also, I don’t know, I think we’re going to see, especially with just so many new tools coming out, I think we’re going to start seeing some real opportunities to do generative stuff. Which is like what if you’ve got a challenge that you need solved and you have the system spit out like 50 designs and you look at the 50 of them and say, oh, that’s interesting, or maybe you combine three of them. I personally have been using ChatGBT to just get past writer’s block.

Previously, I would rely on a Thesaurus pretty heavily. I’d kind of think of a word that basically was saying what I was trying to say, and I would use the Thesaurus to look at a bunch of other words, and then I might take one of those words and put it in. It’s almost like a mind map of different association words. Now, with the tool, if I’m stuck or needing inspiration, I might just type something in and then I’ve got a couple paragraphs to just think about and then I’ll rarely just copy and paste. I’ll usually just read it and then go, okay, now I know what I want to go write. And I think that’s how we’ll see these tools impact designers as well, just from that pure inspiration and generativeness.

Nick: I love that, and I’ve had many times in design reviews where we’re looking at two versions of a potential UI and then collectively in the room it’s like, these are okay, but I wish we had more to look at. And then it’s like, okay, design team, go take, make two or three or four more. If we could just in that room, click a button and it spit out three more and be like, oh, interesting. That one’s in. It helps us use our cognitive towers to put together the intangible pieces while looking at the tangible pieces, so that’s fascinating. I would not be surprised to see a tool like that pop out pretty soon.

Douglas: And also, I think we’ll probably see more tools that move beyond heuristics. When you think about a heuristic eval, that’s kind of helping us think about is this design meet the criteria for good user experience and accessibility and things like that. I mean, it doesn’t seem that farfetched to imagine just being able to send your design into a thing that says, “Hey, the button’s too far away, bro.”

Nick: Yeah. It’s not legible with certain eye types. It’s not legible, or even like…

Douglas: Anyone over the age of 50 will not be able to read this.

Nick: Yes. Or that the padding you have in that UI will not work when you translate it to German. Here it is in German, and it can just show you, that’s powerful. That’s super cool.

Douglas: And I wonder too, even talking about the governance stuff, I could imagine situations where you could have governance tools that almost act as your arbiter or help facilitate some of that stuff.

Nick: I’ve not yet seen any tools that integrate governance rules, so you could determine as a team like these are the steps, something needs to go through, a component needs to go through to get validated and be part of the system. All of that stuff is just done by humans right now. It’s in a project document or something right now, so there’s a huge advance. We’re sort of like 2009 when the App Store came out. We’re real early tool days and there’s going to be a lot better stuff coming up, but you know it’s not going to change, and to bring it back to facilitation and design thinking kind of all this stuff. What’s not going to change is even with the best tools and the AI is getting the right people in the room to agree on a direction and hearing them out, having them be part of the process, and that needs to happen continuously.

It’s not, you ask, how do we get started? Well, I said, get everyone together. That needs to be a cultural pattern change. It can’t just be we got everyone together and work for six months. You’ve got to build in these milestones where everyone’s getting a chance to reflect and give feedback, and I think it’s real easy to go heads down and disappear for six months and build a system. Just a big reminder for everyone out there. Bring your stakeholders in, even though it’s scary, because there’s going to be those swoop and poopers. You’ve got to hear them now because if you don’t, they’re still going to come and do that later and it’ll be worse. But if you get them bought in from the beginning and keep them bought in, it makes everything go smoothly.

Douglas: And the storytelling. Bring them in and then keep them looped in. Figure out ways to really ensure that the progress that’s being made is amplified and told in a way that really resonates so that there’s a narrative there that people can really understand and feel a part of.

Nick: Yeah.

Douglas: I’m kind of curious how often you run into design ops when you’re thinking about design systems.

Nick: Commonly, some companies have design ops teams, some don’t. Some put their design systems teams in the design ops. Ops or operations in general is a fascinating topic. I’m a big believer that design systems should not be part of product teams, designers and engineers, they have mismatched KPIs and different goals. Design systems teams are much more about building that infrastructure and helping others move more quickly and be more efficient and make better stuff, so it’s really an operations thing. And so, it’s fun to see design program management or program management team or design ops teams own the design system. It’s not that common yet, and I think it’s just a matter of time until more teams move that way.

Douglas: When I first heard of the term and immediately resonated with me, and I could imagine so many ways to empower teams to work in that way, because whether it’s tooling that just makes it go faster, and especially if you combine it with design systems, we’ve already decided how these components work. Well, I don’t know. Let’s say that we have a tool that can inject customer data into a widget, and so, that way when we bring our design up, we can then use that Figma plugin or whatever it is to then switch in and out different length names. It’s like the classic like, oh, this look fine in the mock-up, but then when we put a 50 character last name in there, it looks horrible.

Nick: Totally broken. All those exceptions, it’d be great to test those exceptions for sure. I’m pretty sure in the next three years, we’re going to be weaning ourselves off using the term design systems. It is an inadequate name that captures too many things under it, and it has the word design in it, and it constantly causes friction because your engineers need to use it. Your product managers need to be involved with it. Your branding team needs to be involved with it. And so, calling a design system immediately makes it a difficult push through because people will go, “It’s not for me, that’s what the designers use.” It’s similar to design thinking, after using that term for a year, and at IBM, I just stopped using the word and we just say, “We’re get gathering people together for a reflection or a workshop” or whatever. And so, the naming of things is important, and I think we’re just using this as a placeholder. I think that the term itself will evolve heavily over the next few years.

Douglas: That does happen. I’ve seen it happen many times. You’ll go through evolutions and things will get rebranded, and it’s like, “Oh, isn’t this the same thing?” And then it just emerges kind of with the different flavor and a new name, and that’s an interesting point that people are going to make associations just with the word design and the name.

Nick: Yes. It happened with user experience UX. We for a long time were just broad spectrum UX designers and then realized, oh, there’s content designers and there’s visual designers, and there’s more product based or growth designers. There’s all these nuances and they have totally different roles even though we’re all designers, so UX has kind of gone away a little bit, and I think design systems will too, as a name.

Douglas: That reminds me in the early days, everyone was trying to hire a UX UI engineer.

Nick: Yeah, I know. They wanted you to…

Douglas: And I was like, “What’s that?”

Nick: Yes.

Douglas: So good. Well, we’re kind of coming up on the end of our time together, so I would love to give you an opportunity to leave our listeners with the final thought.

Nick: Yeah. Design systems are the tool that enable us to step out of being individual makers, crafters on particular interfaces. And it elevates our craft to a point where we’re able to spend more time focusing on our users, bringing in our stakeholders, collaborating more and less time just kind of grinding through production. That might be scary to some people, but I genuinely think it’ll be a better job in the teams that are already doing it. I’m seeing that as well. It helps us just be a more valuable set of contributors in any organization.

Douglas: I love that. It’s an opportunity to elevate your skills and your perspective, your mindset. Definitely check out Nick at nickhahn.com and Nick, it’s been a pleasure chatting today. We’ll chat again soon, I’m sure.

Nick: Yeah. Hey, man, this is so fun. Thanks for having me on.

Douglas: Thanks for joining me for another episode of Control The Room. Don’t forget to subscribe to receive updates when new episodes are released. If you want to know more, head over to our blog where I post weekly articles and resources about radical inclusion, team health and working better at voltagecontrol.com.