On Theme: Design Systems in Depth

Stop waiting for permission! and other ways to show design systems value, with Brian Alfaro — #05

• Elyse Holladay • Season 1 • Episode 5

Share episode

📲 Text the show your thoughts!

If the way we're building design systems has a fatal flaw, it's "waiting for enough investment to get it right." In this episode, Brian teaches us to not wait for permission and how your product teams' success is your success. Brian reminds us how important it is to remember that we're all on the same team, building the same product—and why internal politics and storytelling matters way more than components. Plus, why design systems are like toilets (not a Dad joke, I promise) and why Brian and I think "measuring the system is hard" is a beautiful thing.

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!

Links & References


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Brian:

I totally get the desire to code or design, in your corner, this most perfect idea of what we think is the perfect system. That's usually not the thing to do, right? Like, we're waiting to bring that value to the rest of the team. That is a recipe for a disaster. If I'm baking a cake, but you're only hungry for a cupcake, I'm like, well, too bad, you got to eat this whole cake, is like what you're asking some people to do.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today's guest on the show is Brian Alfaro. He's a design leader with over 15 years of experience, currently at Yahoo, driving the evolution of their design system, and previously spent five years at the Washington Post on their system. He is focused on empowering teams to work together seamlessly which is something I also care a ton about, and turning collective efforts into impactful tools and frameworks. He also says he is a proud member of the 3 D club: dad, designer, and developer. I got to know Brian because we were on a panel with into design systems together, in 2024, and I really loved his focus on iteration, not waiting for the perfect setup to show value iteratively, and that is what we're going to talk about today. Brian, thank you so much for coming on the show.

Brian:

Yeah, thanks for having me. So glad back in a room with you, where we get to talk about systems, and just all the stuff that affects us on a day to day.

Elyse:

I know, I'm super excited. So, tell us a little bit about the projects that you worked on at the Washington Post that were really cool or you worked on at Yahoo. Give us a sense of like some of the things that you've focused on in your design systems career.

Brian:

Yeah. At the Washington post, I spent a lot of the time really, standing up their first design system. They didn't really have something prior. There were pieces of design systems, people working in different corners, and my job was to really bring them together and build a system collectively. It was a huge success internally. When you think about news, you might think like, how much system really goes into that? But usually we balance stakeholders, like you have designers and engineers and maybe product, but there was another person in this room, which was the editorial room, right? They had a perspective that we had to balance of like, at what point does the system stop and editorial takes the lead. So it was a really great space to be in so much collaboration. And I really appreciate what we built there. Similarly now at Yahoo I've only been here about a month, a little bit more. And it's been great. I am again attacking a similar challenge, where people are working in their own corners and we're trying to figure out a way to bring alignment of such a really awesome legacy company, that has since kind of been on the movement, if you've been keeping track of Yahoo, they've been doing a lot of cool things. So it's just a space where, okay, well, let's bring that to working together across these different verticals that are happening across Yahoo. So that that's, I'm taking part in that, helping shaping it. And I'm very excited for the work to come in the next year.

Elyse:

That's really cool, because I think in both of those cases, there's so much you can do. It is also so hard to do those things when you are at a company that is either very big, has a legacy code base, or has a lot of legacy process. And I'm saying legacy, not in a like, it sucks kind of way just in like it's old, right? It's been around maybe it's very entrenched. I think this is the most interesting place to do design work because it's very easy to build something entirely new, and I think this is a trap that design systems fall into all of the time. They're like, we're going to build these new components. We're going to build this new Figma system. We're just going to like go off in this corner and make this shiny thing. Then we wonder why we're having conversations about, why doesn't anybody want to adopt this and, you know, adoption metrics and the business doesn't understand the value of this project. But when you are working in an organization that is already moving, they've already got a code base, they've already got Figma, they've already got design and engineering process, and you're asked to come in and really think about, how do we modernize this process? Or how do we bring these disparate things together? First of all, that's a major challenge. But second of all, it gives you a lot of opportunity to show actual change and actual value, as you go. You can't go off in the corner and just be like, look what we made.

Brian:

Yeah, I think it's a fine line. Working in these spaces, particularly at the Post and here at Yahoo, like you mentioned, they're both older, they've been around since the internet kind of started, right? And they have their own story, evolution, so like how they, how they arrived to where they are today. When you think about ownership, org change directions, uh, so much has changed. And I think where I can draw a through line between the two is that there's institutional knowledge that has arrived them to the level of success that they're at. So for someone to come in and be like, clean slate, this is what we're doing. It's definitely not going to work or you're going to receive a lot of friction. So I think what I really love about it, and what I find most people sometimes don't really love about systems, is the politics part. It's the part of working with people and bringing about alignment in such a way that, that you're getting them to an answer that they didn't know was one. And I feel like that is something that is, not just one person can do it, you know, I'm working with a team of folks, we're trying to arrive in a space that feels like a healthy compromise of both the new and the old. How do we get there? And so you're right, if, if I was a designer or engineer and I was just like developing component library or designing, you know, it's a very good chance that people are gonna be like, this doesn't fit what I need. So when it comes to these bigger spaces, I find that before you even pick up your mouse and try to draw a pixel or even open up your ID E you know, like you have to think about the people first and really start thinking about the process of just conversing. Talking about it and getting to a space where we all feel like we're on this ride together. It's a longer thing to do, for sure. It doesn't happen as fast as some people want it, but I always find that the outcome is way better than if we were to just take that kind of ruling governance, like you have to do this now because C suite says so. It just doesn't feel that way and people feel happier about the system.

Elyse:

I love that you said the politics part, because I think everybody gets really like, oh, I came here to make the perfect system. I came here to make components. And it's like, yeah, but the job of design systems and design system teams is sales and storytelling and politics and bringing these things together. And, I've been talking a lot about systems as organizational behavior change, right? Like we are changing how we build UI. We're changing that design process. We're changing how things get shipped. So I love that you're straight up acknowledging, like, that's so important, and it's also a thing that you like. We need more people in the design system space who are like, that's what I'm here for. So what do some of those conversations look like where we're trying to get everybody on the same page, like design, engineering, editorial. What are those conversations feeling like?

Brian:

Yeah, I think first is recognizing that we're all charting to the same goal. I think a lot of times when you are working within these orgs that are fairly large, you have a degree of separation from your colleagues. I'm working on the homepage. I'm working on the article page. I'm working on the user settings page. Sometimes they're so far removed because the nature of the work is like, is just too difficult for you to meet with other people or let alone know what they're doing. So you build this kind of echo chamber of like, my stuff that I'm doing is driving revenue, and it's super important, it can't change, blah blah blah. And you start building your own kind of narrative of like, we're charting towards this goal. The conversations that I typically have, it's like, just, just really open, talking to people about like what they're trying to do for their specific space. And then showing them, like driving them to say, hey, you know, so and so is also doing this. And having that aha moment of we're working on the same product. And at these larger spaces, sometimes it happens that you find yourself shipping the org chart, as opposed to shipping cohesive product. And that just happens, especially when we're more separated. I love remote jobs. Don't take it away from me. But like, you know, when we're talking about separations, truly, not just remotely, but you know, we're not in the same rooms, so we really have to come back to square one and say, we are building together. What you do over there does affect me. In terms of the user, they don't see Yahoo as different, they don't see The Post as different. They don't see Facebook as different. Any of these things that are huge, right?

Elyse:

Yeah, they're not seeing the org chart except for in the ways that like, how come it doesn't work the same over here, and that's just a frustration.

Brian:

Like how it shows up, right? How it shows up in the org chart will be in the UI. The select looks different. It's clearly because someone didn't talk to someone, but the user doesn't know that. They just think it's a mistake. So the first thing for me, it's like understanding that we're all on the same ship. We're trying to go to a similar direction. And if they are truly pulling in bipolar directions, then that's something that we need to have a conversation about. And that's beyond system teams. That's at a business level. And those conversations, we help influence, at least allow them to happen. So without that, you cannot really start to even begin to start thinking about a design system, because someone has to be invested, not in a system, but we're all invested that we're building the same product. Like that's first and foremost. And then after that, I think the conversations start trickling down to identifying patterns, a normal system kind of usage analysis or audit. Because we, we've realized, oh, you know what? We're all building a similar component. We're all using a similar color. Like it just happens like, oh, since we already agree, we're building the same product, why not just do these things? But that first conversation is super important.

Elyse:

I think you said something so important just now which is that, design system team can and should influence these conversations around, are teams in different parts of the org going in a really different direction? Are they in conflict with each other? Are they working in really different ways? But so often design system teams, end up feeling like they have to own that, and then get really, really frustrated and really, really burnt out. Or they're telling their organization, we're going to own this, we're going to fix this by virtue of the tool that we're going to ship, e. g. the system itself, the components, you know, which like you, you cannot. And I've been saying the outcome or the value of the design system is not in the delivered thing, right? It's not the component. Because I cannot ship enough components to make two teams that don't want to talk to each other and are shipping in conflict designs, like the system can't actually help that. This is a trap that so many systems teams have fallen into where they're trying to own that, where they're telling the org they're going to own it. How are you talking to your organizations more broadly about, hey, like this is beyond what a design system team can, uh, control. Let's call it control.

Brian:

Yeah, actually that was a conversation I recently had here at Yahoo. And it was just essentially that, having a great design system that looks good, that feels cohesive, you could still have a shit product. You know? It doesn't mean that your product is going to be great. I mean there's some really nice design systems—

Elyse:

It's so true.

Brian:

—out there, and the products are not great at all, right? I've seen folks who have no design system and the product is selling like hotcakes, it's super good. So what is the role of design system in that space? And I think we do ourselves a disservice by saying, yes, we can resolve this if we just unify our buttons we're going to do so well. There's a level of investment from like an efficiency standpoint that we could sell. There's, there's a story to tell about the reasoning for cohesiveness when we think about the user journey and how it is holistically a part of a good product. But it isn't the factor that makes a good product. Good products still comes from product ideas, business challenges that you're trying to take on, and understanding your user. Systems play a part of that by reflecting the stuff that is being informed by those specific products. One thing that I've been finding myself saying is like, the system isn't, it's not a system first and then product second. Products drive the solutions that we deliver. If they're not driving it, then the solutions we're pushing out is just to no one, right? Like it's just our opinion. And developers and engineers are notoriously bad at predicting what everyone needs, like we know what we want, but like when I decide, like I, I made the perfect React button, I never have to add another prop. And then I find myself adding another prop, you know, just for like myself or even just for designers. We're not good at predicting. So like, I don't think we should pretend to say that we can sell this big dream. And maybe people do it for just to get the investment, but you might shoot yourself in the foot later.

Elyse:

Yeah, yeah. Let's talk about that. Let's talk about getting that investment, because obviously that has been a hot topic. Teams getting laid off, teams getting defunded. But at the same time, more and more and more companies are starting to be like, oh, we need a design system. You cannot, to the point you were just making, deliver anything that is going to be perfect the first try. You cannot deliver tools and components that are going to make two different parts of the organization that are in conflict suddenly move together. That is people, that is process, that is much, much bigger than anything that we can deliver especially as a small team. And so then of course our leadership is like, well, what is this thing doing? It's not helping do the thing that you promised me it was going to do. So when you think about investment, getting investment for the design system, and most importantly showing value so you can get continued investment, to continue to make improvements, how are you thinking about that? And how are you talking about that in your org?

Brian:

Yeah, I mean, I acknowledge it, I understand that it's hard. I totally get it when people are frustrated that they want this outcome, but aren't given, you know, the space to do so, or feel like they don't have the investment to do so. So I can totally acknowledge that. And I'm coming from that perspective too. I'm not just coming from like big budget people who just have deep pockets that we have time to sit on our hands to figure out these things. So like maybe you don't have a dedicated design system team, but you have expertise around trying to identify alignment and improve the relationship between developers and designers. And I think that's where the crux of this value is like bringing in the behavioral change around the way we talk about work, the way we approach work. Yes, consistency and all these other things are important, but what's more important, is that the designer and the developer have a sense of a shared language when they're talking about the work. It reduces the back and forth, all these other things, which is the efficiency part. But what it also does is it creates a very specific cultural change to that organization. Like when I left The Post and arrived here at Yahoo, the elements of a system are very much the same. Like that's not new to me. What is new is the culture. The culture that is here, the culture of how they talk about work, how they think about work, how we're sharing that across different verticals within a specific organization. So when I think about telling the narrative to folks, is that we're talking about behavior, cultural change around how we're talking about work. There's pain points that we can identify. When we say, oh, you know, I've designed this button 600 times already, like, why can't we just have one button? There's a story to tell behind that. It's not because you want this elaborate system. It's because you want to reduce that pain point, right? It's the story that you're telling to say, hey, it's a cultural change. I think it would be more important now to talk about how we can do things better with less, but also do things better with the people that we have today. Would be a very interesting thing for them to, to talk about as well.

Elyse:

You know, you're making me think about how design system value, efficiency, consistency, fewer visual bugs, design eng handoff, collaboration, like all of these things have become shorthand, and we just don't really even dive into what that means anymore. I think that's partly because those things are very, very challenging. Like, okay, what does efficiency actually mean? What does consistency actually mean? And so I love that you're talking about a shared language, not just for designers and developers, but I think for the organization too, to kind of understand, what do we even mean when we say we want visual consistency? What is the outcome of that, that somebody can point to and say, we've made improvements in visual consistency.

Brian:

Yeah, I think, what becomes an issue is a lot of the things that we work on are artifacts, right? The outcome of something is usually an artifact of an idea. If you think about tokens, for example, we have a built a mechanism to tokenize a decision, and that is color. But when you think about that decision, it's more than just color we tokenized there, right? We've tokenized the decision from branding, the perspective of marketing, and we've built like our attempt to deliver that to the UI. The same is true for inputs or our buttons. If they are truly driven by the product, then they are a way for us to encode our learnings in such a way that it's shared, for example, if we tested a button, like AB test a button, the right shape, the right color, whatever, and then build that into the button itself. And that's shared throughout all of the org. We don't talk about these these pieces, because we get caught up, like you said, in like, things look the same things feel the same, but it's not just like an aesthetic thing. It's really, how do we codify, componentize, tokenize decisions that are a lot of times abstract. Like, how does the brand show up? I think tone when it comes to like content design, and inclusive design, how they show in the system is a really great example of how we could codify the brand's or the product's opinion on those things, within a system. Because there is no other mechanism. Like you could write a long guide or something that people can read, and then they have to like reference but if you truly want to reach this level of accessibility, we want to make sure that our tone is in this approach, like they need to be in a mechanism that is not requiring someone to sift through a bunch of documents. So systems allow the product to do that. Without it, you end up with segmented journeys, like, for the users it's very segmented in terms of like, we don't come in a unified approach. And I think like that piece, it tends to be overlooked when we think about the value of our system.

Elyse:

Yeah, and unfortunately, I think we just have to acknowledge that we don't have, and I don't think we will ever really have, I don't know, maybe marketing folks listening, call me, but we don't really have a way to calculate the impact of brand feeling, right? You know, we can say, oh, you know, they changed their logo. They lost some brand equity, but that is such a nebulous concept. We have no way to measure the lost trust when you go between different pages and things work and function differently. So, for example, at Color, one of the things that we did in the fall of 2024 was a bunch of visual design changes, specifically trying to make the product feel more warm. That was the brief. We're doing cancer screening. We're trying to get you to participate in your screening, to engage with this idea of your cancer risk and learning your cancer risk. You don't want that software to feel the same as your financial stock software or like car rental software. We needed to bring a lot more humanity and warmth to the product, but how do you measure that? How do you say the change in some metric is specifically because of this nebulous concept of warmth? And so, you know, we, we, we come up with all these, like, oh, you do an A B test, you get this, you get that. But those things are so human and so nebulous that I think, I don't know. I don't know where I'm going with that. It's just, that's very, very challenging when it comes to trying to do that through systems, we have to talk about it from a storytelling lens more than we can say, yes, like we have shipped this brand decision as like a final thing that we can calculate.

Brian:

Well, you touch on something that's very like the crux of a design system. It's like, it's both an art and a science. There's a science part of this, and then there's an artistic part of this, where we're really talking about these abstract ideas and how they show up into our product. As human we can feel them, we can see them, we can acknowledge them. But there are a multitude of factors that make up that experience. Like, I could encounter the same brand and not be in the headspace that I really want to feel welcomed and it won't feel welcoming, right? Like that's an X factor that's outside of the product and brand. But when it comes to what we can control, it's like you said, the storytelling and the narrative of how we come collectively as a product beyond just systems. It's just that systems are a mechanism for us to show up in a unified approach. Without systems we find ourselves back to our own ability to just do with what we have. And so, like, if marketing really wants to get into product, they're meeting with folks, they're reviewing designs, that probably is not what they want to do, right? So meeting with a systems team and codifying, componentizing, tokenizing, all these other things, we can then deliver that. That's what I love about systems is that it truly isn't measurable. And it, you know, it keeps you up at night as someone who works on it.

Elyse:

Yes.

Brian:

How does this show up? Or did I think about this? I think that's like it's kind of a nice space to be in because it's, it's unresolved. And you're forever going to not have it resolved, but you're slowly chipping away at it. Like, you know, from a directional standpoint, we're all going somewhere.

Elyse:

I'm laughing because only, I think, a true generalist systems person could say that, and genuinely mean it. Because I'm sure that there are people listening who are like, wait, the fact that it's unresolved and will never be resolved is a good thing!? Like you, Brian, you are out of your mind.

Brian:

Yeah I, would say so.

Elyse:

Yeah, I agree with you, I think that there's a beauty in that, because you get to iterate and you get to grow and you get to change and like, there is no end state. There's no perfect, complete moment. And I love that.

Brian:

Yeah, that's it's really like, it's poetic in some way, it's not a thing you could tie a bow on and say it's done.

Elyse:

Yeah, let's talk about that because, we touched on this earlier, this idea of like, okay, I'm going to get investment for my system, I'm going to go off in the corner, I'm going to create this thing, and then I'm going to deliver it to the organization. But, you know, it's not done. It evolves, it changes. There's culture changes, designers and engineers come and go, your team changes you know, more things are changing all of the time than are actually staying consistent. I think this is why we've gotten so focused on really foundational components, things that we think of as unchanging. Buttons, icons, text styles, drop downs, menus, whatever, because we're like, oh, I can control these, these are unchanging. But that makes our view of what design systems is, so narrow that we lose, I think, the opportunity to use all the uncertainty and all of the change to actually iterate and evolve. So one of the things that you talked about in the Into Design Systems panel that we were on that I really loved and want to dive into is making change you know, showing that value all of the time, rather than asking for, this big investment or permission to go change the thing, actually just starting to show that. Show that things are moving, use the system to start evolving the product and the culture. Can you talk about like, what does that even mean? And give us some examples of times that you've actually been able to do that.

Brian:

Really when I think about this, and I'll use myself as an example. I'm a designer first, and then I also love the code, right? But when I think about what really gets my endorphins going, like so hyped, is when I own a project all the way through. I can code it the way I want. I can design it the way I want. I could shape it the way I want. So I totally get the desire to code or design, in your corner, this most perfect idea of what we think is the perfect system. That's usually not the thing to do, right? Like, we're waiting to bring that value to the rest of the team. That is usually a recipe for a disaster. If I'm baking a cake, but you're only hungry for a cupcake, I'm like, well, too bad, you got to eat this whole cake, is like what you're asking some people to do. If you want to bring cohesiveness today, you could just take all the buttons, they may not look like the buttons you want. Take all the buttons, figure out what the sizes are, and just use what's there. You've already brought cohesiveness. It may not be what you want. It may not look the way you want, but guess what? You've actually arrived to a solution of where people are using the same button. And because we're talking about systems from a cultural standpoint, now people are along for the ride, right? Hey,I worked on that button. Cool. Like, I'm glad to see it's contributed to the system. Do that for every component, every color, yada, yada, yada. When we wait the conversation doesn't happen. People are not along for the ride. They don't know how you arrived to that solution. Then all of a sudden there's a brand change that you didn't know about, or some strategic change that requires the product to pivot. Well, guess what? All your work is complete waste, right? Because systems take longer to deliver it's better to just deliver upfront and don't wait. Because you'll, again, like, you'll just find yourself in a spot where you're either redoing and you'll feel so frustrated. And it'll take you down a notch. We get so entrenched to the work that we feel like they're taking us down a notch, and saying like, no, this sucks, I don't like this button. I don't like this API. I don't like this design. And it's like, well, we're not talking about you. You just missed the assignment. Like you, you didn't do it right.

Elyse:

You didn't understand the assignment.

Brian:

Yeah, you like you completely whoosh over your head like you didn't get it. You need it to be talking to us and being with us, to deliver what we need as a product, not what you think we need.

Elyse:

Yeah. Oh man. I learned that lesson the hard way about five years into my design system career and once you learn it, like once you get smacked upside the head with that, you're, like, oh, oh, I'm never going to do that again. Because it is such a waste. It makes you feel like you're not good at your job. Everything that you built is like now not going to get used. And you're just like, what, what was I doing? I think I spent a period of time being like, I know that I'm right. And if I could just get these designers and engineers to understand my genius thing that I built, then they would finally come around. And it's like, wow, ego, control yourself. Every team is different. Every organization is different. And it's so absurd that we think that because we have the mandate to do consistency, that we suddenly know better than all these product teams who are so much closer to the user and to the thing that we're actually making as a business. Like, we don't know better than them. We are trying to be a steward of all the decisions that they've made. And I think that's a really different way to think about the work that we do that, you know, five, seven years ago, I wasn't hearing people talk about it like that. We are the owners only of codifying the intelligence and the decisions of the product teams and of the things that they're building.

Brian:

Yeah, no, that's, I love that because when you find yourself as a system designer working with your developer or whoever, and you guys are talking about like, what this API is going to be, and you take a while to agree, and then you go and expect like everyone else not to have that same level of discussion you internally had, is a little bit delusional, right? Like we think that like it, we already struggle to align with each other sometimes. So finding that outside core team is going to be so much harder.

Elyse:

Yeah, absolutely. And I, one of the things I was thinking about when you were talking a few minutes ago was all the different ways that a system team can start to show change and value. In this very broad sense of like, you have shipped something literally to the product or you have changed the way that somebody on the team is using something. And there's just so many ways to do that, right? You can be shipping something in Figma. You can be changing the way the designers are doing something. You can be changing some kind of process with design. You can be changing something about the design eng handoff. You can be shipping some code. But I think this can be very very challenging for systems teams to describe or feel good about, right? I did a bunch of work at Color in 2024 that was really moving stuff around under the hood and like nobody noticed. And sometimes I'm like, was this valuable? And, you know, some days I'm like, no, because nobody even noticed and other days I was like, yeah, I just made it so much easier for anybody to come in here and do anything. How do you talk about incremental wins and the value of that incremental work, especially at a big organization where the, the size of the incremental thing you did might be so small relative to the surface area of all of your teams and all of your products. How are you talking about that?

Brian:

Yeah, that is a difficult thing to address. That happened a lot to me and our team at the Post. We did something, but did anybody notice? We're like, I don't know, does it matter? And to my supervisor, I actually shared this anecdote around, you know, I see design systems as a toilet, like, you don't really

Elyse:

I can't wait to know where this is going.

Brian:

Yeah, it's like a bad analogy, but I thought it was funny. Like, it's a toilet. You exist in your house, you use it when you need it, and it just kind of there, right? It's effective. But when it's not working, right, when it's not working, then you notice, and when it's gone, then you really notice, right? So I see systems similarly. We are effective in what we do. And a lot of times that doesn't mean it's like this big grand show, but you may have well made a silent change that would avoid us a cost down the road. Maybe you did a React[upgrade] from 17 to 18 to now 19, right? You coordinated that. Nobody saw some visual UI change. There's some infrastructure things you might have addressed, some technical debt, whatever it may be. People may not have ever noticed, and I think that's okay. But what is important, is that people value that you are there, right? And so I'm going back to that toilet is like, yeah, they may not have noticed, but they'll notice when you're not doing that. So I think understanding that throughline to your performance review or your C suite, whatever, I think you need to talk about it from that level of perspective. That, this silent change, had we not done this, this is what would have happened. Being at Yahoo, there's so much work, there's so much awesome work that's happening across all over. We had this end of the year wrap up and I had a chance to see all the work that's happening, and it's insane the amount of quality of work that's coming out of here. And then I think about well, how will our impact drive these solutions in ways that, we could show up as effective, and there's ways to measure that. But I think if you tie yourself to strictly metrics, you're going to lose that battle. But if you do start changing the narrative that like, it's about holistically how we approach work. So the success with The Post, when we delivered a component, people use our component, they deliver all these different features. Did we get, you know, the kudos every single time? No, Did I expect to get those kudos every single time? No. But what was important that I identified as a system designer, I identified where those components were used, so I can relay that to my supervisor. Like that's on me. I don't expect other folks to do that. So when I say, hey, we shipped this accordion, and it was just in time for this feature and it got launched, so their success is my success. Second is the holistic piece. If we think about work holistically, it's more than just designers or engineers or product, it has to be like, we're all collectively building on this thing. And so when we think about performance, we can't just drill down to the metrics. We have to drill down to the stories of success and how design systems are weaved into that. Cause take any success from your product of a, like a whole user journey, how successful or how unsuccessful will that initiative have been, had systems not been around?

Elyse:

Yeah, I love that. How would you talk to an IC or somebody on your team who feels like they're really struggling to describe the value of their work to the organization. That could be a performance review, but it could also be, like I need to go talk to my team or, my design director, or our C level, or whatever, so that I can pitch updating some foundational code, or we need to rebuild the app bar, or we need to do a design pass and think about type hierarchy. What kind of advice would you give somebody who's struggling to talk about that in a storytelling way? Because we often think it's very self evident. We're like, see, all of this type hierarchy is so crap, therefore, we definitely need to fix it. But that's not always a particularly compelling sell, to even an organization that might be particularly design minded. How, how would you tell somebody to, to talk about that work and to make it a more compelling story?

Brian:

Yeah, I think there's, there's a couple of facets to that. The first is we have to talk about our designers a bit differently. Like every designer doesn't fit into a cookie mold. And so when we think about system designers, they don't quite fit exactly what I would consider, like maybe a standard product designer on a specific team, on a specific niche. And I think that's first important to understand from like a leadership level, if I'm going to advocate for my specific IC, that they don't fit into a certain shape. So when we think about like system designer, they might be really good with information architecture, or practices around accessibility and inclusivity. But maybe they're not doing so much of like research feature level kind of stuff, or driving business initiatives that are direct impact. These are the spectrums we need to measure our designers and developers too, for that matter, in a way that truly reflects the work that they're doing. Zooming out from that, if an IC is gonna go talk to someone around here's what I worked on, then I would encourage them to focus more on where they drove change. And change is a larger bucket to reach into, as opposed to like, what was the KPI, what was the business revenue that you gained? How much subscriptions did you increase? That's really hard to talk about. But when you drive change, change can be fabricated into a story. And the change could yield outcome, whether it's hopefully you're sharing something positive, but, you know, some instances, it's something that you learned, right? So when we talk about, like, all these type scales look really bad, and the ramp is just all over the place. We normalized that. Here's what we did. We worked with these teams. And because of that, we've streamlined decision making around type pairing and blah, blah, blah, right? You can drive this level of conversation through the bucket of change. With this, in conjunction of how we're measuring designers and engineers to the respect of their work, now, all of a sudden, when I go to bat for them for a promotion, I'm talking about it in this lens that they're being measured on the change that they're impacting. So if we don't change the lens at their end, and we put everybody in the same bucket, that's super impossible, and that's not fair to people. People have expertise in certain things, better skill sets, and we should cater to a more broader cookie mold, so to speak, for each type of person and designer and engineer.

Elyse:

I love that so much. I want to just touch on this idea of don't wait for permission again at the end because, you know, we think I have to get team buy in, I have to get investment, I have to get a designer and an engineer and a PM and get it into the sprint and we have to get everybody to agree and like have consensus and all of this. But I think that there's so much that everybody can do where you can actually influence and create change in very, very small ways. And we like, we don't do it. We don't just go for it, because we have to make this big rigmarole around getting investment or whatever, and so I know you've been talking about, don't wait for permission. Bring us home. Tell us what do you mean by don't wait for permission? And how do you do that in an organization where you do need to respect timelines and other people's work, and you can't just like be YOLOing shit to prod, right? Like, how do you, how do you balance that? What does don't wait for permission actually look like?

Brian:

Assuming you have a core team, waiting for permission is probably the worst thing you can do. So what I mean by that is like really, you should already be doing the work of building off the back of the work that existed. So one example at the Post, when I arrived there, it wasn't like there was nothing built, right? There was a lot of stuff already built. By the nature of the work, we're already thinking about these things. They had their CSS framework. They had this like pseudo at that time, Invision library, it was like DSM, RIP Invision, uh, so like they had something there, but it wasn't really what we would consider a fully baked system. They weren't thinking about how it truly bubbled up to this grand system, but they're already doing the work. And because they did that, it made the work that I needed to do, so much easier. It makes it so much easier to build off what exists. And so when I think about, don't wait for permission, building off what exists allows you to operate and move with minimal need for alignment. You know, you actually can just pull the buttons from everybody and say like y'all designed it, is how it is, I'm just reflecting what's there. And I'm not saying it's the best API, the best design or whatever, what I am saying is that, there is a decision that was made and it was done in such a way that somebody decided to make it more efficient, even if it was just for themselves. There's this, there's an essence of a system, an unspoken system that exists in every product, and that unspoken system needs to be brought to the light before we make any pivotal changes. So building on that allows you to curtail the, I need to sell this dream. And it's like just do the work. Everyone's already doing it. Just build off what they're doing. The other piece that I would say is like, if you're not a core team, and you're really someone who's just on an agency level or like, you're embedded in a feature or vertical, and you're trying to find yourself building a system. I think take the button. Don't redesign it 600 times. Make a decision. No one wants you to design a button 600 times. I promise you that, like, they're not paying you to do that. And then when you actually need a change, go revisit that decision and understand why. So you're like almost building a system for yourself and testing for yourself as the user. And slowly roll that out to a colleague, and bring in people as it scales, because that's part of the work, right? Start building your system, even if it's just for you. Eventually someone else will come in and say, hey, this person is building a system, why don't we just, you already codified and componentized these things, like let's go ahead and find alignment. And it makes that a lot easier to bring those things together.

Elyse:

Amazing. You didn't touch on this, but I just want to add, that helps with the nobody cares burnout. Like the, the value of the system is not that you made a new button, that now you're going to try to get people to adopt, and then they don't want to adopt it because that's just like, they didn't get any input and they don't understand, and now there's tech debt. But instead just like putting a shared language, a shared layer, around the things that are already happening. And then people are like, oh yeah, this is a thing, like now we're moving all together in a way that didn't really have an emotion around it before. I think that can be such a beautiful thing personally, as a design system practitioner, because ah, I made change that moved people.

Brian:

Yeah, making change that move people feels really good.

Elyse:

Yeah,

Brian:

Even when you frame it that way

Elyse:

it really does. Yeah.

Brian:

You moved me.

Elyse:

Well, you moved us. This is an amazing episode, Brian. Thank you so much for hanging out. As always, I have one last question for everybody who comes on the show. Give us a Brian spicy take on design systems. No notes, just like, what is something that you feel like you feel really differently than everybody else? Drop it in. What's your spicy take?

Brian:

Yeah, I would say that I don't think design systems should be called design systems. That's my hot take on it. Maybe some people agree.

Elyse:

It's not about design.

Brian:

It's not about design at all. It's a part of it, but it's not about design at all. When we think about systems, they play such a crucial role that is beyond design. Yes, you'd need to be a system designer, you have to be a system thinker. There's so much to it that it's not just design, right? Like we're built from so many different pieces of the org that shaped the work, and the solutions that we're delivering to everyone. I don't have a better name. But I will say that that's not what it should be. Because how many times have I talked to people? It's like designers designed it and they're supposed to manage this. And like the designers have to own everything. Or engineers feel out of place. Or product feels what's my space in this? I just don't think leading with that feels of odd, but it's the name we have today. I don't think I'm going to make a movement today.

Elyse:

When you, when you change your mind and you come up with a new name for us, I think a lot of us are on board because you're right. It is so much bigger than just design. Thank you so much for taking the time, coming on the show, I really appreciate it. It was really good to have you.

Brian:

It was a lot of fun and looking forward to all the episodes listening beyond just mine.

Elyse:

Oh, me too. Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!