On Theme: Design Systems in Depth

I’m a design system consumer now: lessons from the other side, with Beau Ulrey — #07

• Elyse Holladay • Season 1 • Episode 7

Share episode

📲 Text the show your thoughts!

I invited Beau to the podcast because of his great Medium articles on design systems... but he's not working on a system team right now! Beau shares his experiences on both sides of the—fence? aisle?—and the lessons he's taken away. We chat about the tradeoffs of building for speed vs stability, bringing new designs for AI products into the system, onboarding, cross-team empathy, and why we're always complaining about the other side. Plus, find out what Beau wanted to be when he grew up.

💖 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. 


Beau:

It's becoming more and more apparent, the designers that really understand how the business works and what the business values are, like they're usually able to illustrate that in their portfolios, or they're able to talk about what was going on within the business and why did they make the decisions they made? Now that I'm back in products, it's clear that those skills are huge when it comes to being a really impactful designer.

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 podcast is Beau Ulrey. Beau leads a small, but mighty design crew within Oracle Health, creating AI based tools for nurses and physicians. Previously, he led the shield design system at U. S. Bank, and he focuses on using empathy and good design to help people reach their goals. He writes about design systems and product design practices on Medium, which is where I first heard about Beau and his design system work. When away from the screen, Beau can be found hiking in the Pacific Northwest, splashing in the Pacific with his kiddos, and toting his camera along the way. And I'm excited to have Beau on the podcast because I reached out to invite him to the show because of some of his Medium articles, and his really great writing on design systems, but it turns out you're not actually working on a design system team anymore. Is that right?

Beau:

Yeah. Is that, is that going to be awkward? Can I, can I stay? Are you going to kick me out?

Elyse:

What are you even doing on this podcast?

Beau:

Well, you invited me, so No, I'm not working on design systems directly right now. I spent a good two years at U.S. Bank working on design systems, partnering with a lot of awesome people there, doing my best to lend a hand to the team. But yeah, now I'm at Oracle and I'm working, like you mentioned, on some AI based tools for nurses and physicians. It's been very interesting to spend a couple years in design systems, and then shift back to being on a product team using a design system, and having some kind of x ray glasses to see like, oh, how's the system set up? And why would it be that way, not this way? And how can it be better? It's been really fun jumping back into being a consumer. And honestly, I've really enjoyed it.

Elyse:

And that is exactly what we want to dive into today. You know, I think often design systems people, we like to say, oh, we're systems thinkers. We do different stuff, our brains work in different ways and we kind of set ourselves apart. And in a lot of ways, I think that's true, and the work is very different, when you're building something for many, many teams that has to work across many products. The concerns at a system level can be very different. But I think that attitude can also instill this othering, or otherness, around product teams and their needs. So I'm excited to hear about your journey around being a design system practitioner, and then being a design system consumer and what you have learned and what you can share with us from going both ways. So let's, let's actually back up a little bit. I want to talk about some of the systems work that you have done. So you worked at U.S. Bank on their system, you worked at IBM and used Carbon.

Beau:

Yeah. Yep.

Elyse:

So I just want to hear about the size and the scale of those systems, and what were the kinds of projects you were working on when you were on design system teams?

Beau:

Yeah, something that has stood out to me throughout my career is just, if someone is a continuous learner, they can kind of shift from being on a product team to being on a systems team. They can pick up things as they go along the way. So when I first joined IBM that was my first big full time, you know, large organization design job. And I was part of a small team that was working on HR applications, and we didn't have a design system. The Carbon Design System wasn't a big robust tool yet, because this was about about 10 years ago. So we started looking at the products that we owned, and the brand that we had present in our products. It was a little disjointed. We wanted to look at things like color palette, how could that be better? And as we started to propose things, we realized like, oh, we can do that in our new products, but our old products are hard coded and we'd have to go through and change all these hex codes, and this is going to take way more time than we thought. And it just kind of showed like oh, we should probably be doing this a little bit differently. We started basically trying to get to a place where we were more consistent, especially with the visual design details. At the time, each designer was creating for their deliverable. They were creating in Photoshop and making web designs and then also creating a PDF to break down the specifications. And the last five pages would always be like, here's our button, here's the size, here's the background color, here's the states, and that would get put, like, into every single person's PDF, and there's multiple versions, they're all, like, in our Dropbox or whatever, and it was just really difficult to make sure, like, are we being consistent? I don't know. So our first approach was just, let's make a pattern library, where we have one place where the stuff gets documented and we'll kind of go from there. So it started just as a single place to find the details, making reusable things for designers. And then we started working with a front end developer and making components. And then we realized, the Carbon Design System was you know, rising to power, and more and more teams were adopting it. We were set up a lot better to take the Carbon Design System and start to use it just because we had already started thinking about like, how could this be more reusable? But U.S. Bank was different, when I joined there, the Shield Design System existed. I joined a product team called the Money Movement Team, and we were using the design system, trying to create new components and contribute. And it was a natural progression, like, the more we were trying to contribute, the more we learned about it, and then I was able to join the system team and bring a unique perspective, because I had been using it. I had frustrations using it. There were things that were working well. And I could bring all that experience and baggage and angst and bring it to the team. And it just helped me be a better advocate for consumers of the system, being one myself just a little bit ago.

Elyse:

So it sounds like you've made that jump of consumer or product designer, system designer, back and forth a couple of times.

Beau:

Yeah, yep. And at first it was like a side project at IBM. At U. S. Bank it was a partial side project to contribute, and then it became my full time role. So it's also been interesting being part of where it's more of an experiment, and then at U.S. Bank where it's like, no, we're building a team, we're investing in this and it's a huge purpose for the organization.

Elyse:

You said something earlier that I love and want to call back to, which was, we were thinking about the system of design, even at a product design stage, right? And I think it's just so important to remember that this whole concept of design systems comes from the product design itself, from the needs of making a consistent design, making a beautiful design, making a design that makes sense all across the board. It's just another indicator that we are not actually as separate as we think we are, like the design system team versus the product teams, and there's so much overlap. When you were working on a design system officially, what kind of lessons did you learn from being on a system team that you're taking back into your product design work?

Beau:

There's, there's a lot of things that I've picked up. I think the two years at U.S. Bank working on systems, they were a big growth season for me, working alongside people who had focused on systems for a lot longer. Also just working more closely with developers, with other designers, focused in on the component itself and how could it be structured, how could it be more efficient. One thing that it taught me is just that quality emphasis on components takes a lot of time, so it's been really difficult to come out of that environment and jump into a product environment where I see something that could be a component, but the purpose is not to create components, it's to create product experience. And move a little bit more quickly to be competitive. So it's definitely been a reframing, like what has the value and warrants the time to make reusable? And what could be done at much simpler depth and deliver the same value to the user? So some of those important things to figure out when you're creating a component for 400 designers is not as important when you're working for a smaller audience. Especially thinking through how much complexity, especially in a Figma component, like how much complexity is actually valuable and how much could be simplified

Elyse:

Yeah. When we were prepping notes for this one of the things that you mentioned was this idea that the designs are only an illustration of intent, right? What do we need to get across to guide developers to do their work or, you know, to iterate on it. What you have to do for a component that's going to be used by hundreds of designers or engineers is a little bit different than when you're trying to get across what is the feature supposed to do? Or how do I hand this off so I can collaborate? How have you seen that manifest in your work now that you're back into, into product? Where do you make those tradeoffs?

Beau:

Well, I think some it comes down to looking at what I am working on and trying to think through, like, is this set in stone, ready to be systematized? Or does it still have like a high probability of change? So if I'm working on something and I could see like, oh, I can make this a component, cause I'm going to duplicate it in my design file, like 15 times. That could be helpful, but I'm not going to go through and make it a full component until we get to some level of like, the concrete has dried and we know it's going to hold, and now we can actually make a component out of it. So I think some of it's just looking at how much change do you anticipate? You can't always predict it, but looking at what's ahead and, who you need to go get feedback from, or have you done testing, or have you iterated? You know, making sure that time spent standardizing is at the right time, is is really key. At least being on this side of the, not the fence. We're not fenced apart. Being on this side of the aisle, I guess.

Elyse:

Yeah, I think it's just it's just the focus of the work. You know, I've been having a lot of these podcast episode conversations, and one of the things that keeps coming up is this idea that we're not on air quotes both sides. It's not a fight. I think for a while there was this attitude of like, we're the design police, we're gonna like, make these standards and you have to adhere to them. And it made a lot of tension, between product—mmhmm— teams consuming the system versus the teams who are building the system. And a lot of that's on design system practitioners, and the promises that we were trying to make, and the way that we were trying to go about doing things. And there's a lot of reasons for that, but one of the conversations that keeps coming up on this show is this idea, like we're trying to all go to the same place. We are trying to build the same product. We are trying to make this product good. We are working within this business together and we're trying to help each other get there. But it has been kind of contentious in the past.

Beau:

Yeah. One of the little lessons learned I think from being at U. S. Bank is, it's really important to understand both directions. Like you as the team consuming the system, if you're facing frustrations because your contributions are not being taken in and published, or you're being told, like, you can't use a toggle for that or like whatever it is, trying to understand why. And likewise on the design system team, if, you know, no one's adopting your system, or they keep breaking your components, like try to figure out why. So a lot of the gaps are just in understanding like what constraints is the system team under that they cannot help, and how could me on the product team potentially help with that? Then on the system side, like what, what frustrations are people having with this and is there something we could do? Could we change our strategy? Trying to think through like, what are the problems on both sides? And what what could we do about it? I think the worst case scenarios I've seen is like, people kind of dig their heels in, and they're unwilling to to explore new approaches. Or you know, the answer is no, but there's not really a path other than that, you just need to expand the thinking a bit.

Elyse:

Where do you think that digging your heels in attitude comes from? And I mean on, you know, both system teams and consuming teams. I've talked a lot about this as like an incentives problem. But having experienced both, you know, maybe complaining about the design system when you're on the consuming team, or complaining about consuming teams when you're on the system team, where do you think that that consternation between these two groups comes from in real day to day experience?

Beau:

Yeah, I mean, I have, full disclosure, I've complained about the design system team. And yeah, I know people complained about my team when I was on the design system team. It's okay. I think it does come down to a lack of understanding where the other team is coming from. And it is a mismatch of priorities that sometimes doesn't get clearly communicated. So your system team, they're trying to standardize things. They're trying to make consistency happen. A lot of times the product teams are trying to move quick, get things out. They want to be able to just like look at that customer, what's their experience, make it better, next feature, or enhance that feature. And, and honestly, that's not a bad thing. It's just when, the teams don't understand each other, it feels like you're pulling in different directions versus working together. So that was a light bulb moment for me at U.S. Bank when I started reading about pace layers and the concept of like, yeah, you don't move at the same speed. That's okay. Like, that's intentional. You don't want to standardize things so quickly that they're actually not standardized at all once you look under the hood. It takes time. You have to do it slowly, methodically. But how do you also let teams move quickly, or how do you let them tinker with the brand and try to change things? I don't think we figured out all the problems at U.S. Bank, but I felt like just communicating that and illustrating that, was a big step forward, and releasing some of that tension and seeing like, okay we do move kind of differently, and let's make sure leadership knows that. Let's make sure product teams know that. Let's figure out a way to operate together.

Elyse:

While you were talking, I was like, oh, this sounds like pace layers. Um, you know, I think this concept is really, really caught on, but I love that Brad and Josh really put a name to that because, I saw so many teams, and maybe you did too, be like, we're going to take all the new things that product teams want and build it for them and put it into the system. And then the design system team is the gatekeeper of product feature delivery.

Beau:

Yeah I think what I saw was this concept of like design system review that needed to happen before things could get published. That, that might have caused like a a reaction if if people are listening to this. But it isn't a way of working that's really sustainable. Even if it's a large design system team, we don't have enough people to make the system, maintain it, support it, and also review everything everybody's doing. So there have to be ways that we're establishing trust, we're setting up other people to know the system better, and we can hopefully, ideally, like, we're helping build systems thinking skills in the culture, without going out and forcing it on people in a abrasive kind of way.

Elyse:

I mean, I just take a second and think about the absolutely massive undertaking that it is for a design system team to review 100 percent of product work and product design. To really give a good review of a design, you have to really understand the use case and the user and the current state of the requirements and like— Forget design systems! You can't have one team do that for very many other teams! That's not, that was never supposed to be the point of any of this. And I think the, the pendulum is swinging against that now. I mean, it's just, it's just wild to me to think that like one team would want, even want to take on the burden of reviewing every single team's designs. That sounds really hard.

Beau:

Yeah. Not personally, not why I went into design. Or even remotely what I imagined doing as a grownup. So yeah, not, not my goal in life, but.

Elyse:

What did you imagine doing as a grownup? What did you want to be when you were a kid?

Beau:

Um, I wanted to be a zoologist. That was a big one. Like just work at the zoo. Take care of animals.

Elyse:

I feel like every millennial was like marine biologist.

Beau:

Yeah kind of like that but— more land-based I think personally.

Elyse:

And we ended up in design systems instead.

Beau:

Yeah. There you go.

Elyse:

Just herding cats. It's basically the same thing. Um, so now, now that you have moved into a new role where you're fully on a product team, I want to hear about what it's like being a design system consumer. So obviously you started a new role, so you have a new company to onboard to, a new product to onboard to, and it sounds like a new design system to onboard to. What was that like, onboarding with all of this information, you know, knowing like you have your systems brain kind of turned on still too.

Beau:

it's been, it has been interesting. I mean, so Oracle has Redwood Design System. You can check it out. It's public. Being on a design system team, being really ingrained in, like, what decisions are made and why, and, and understanding that aspect at U. S. Bank, and then coming to Oracle and seeing what has been done the same? What has been done a little bit differently? One thing that really stood out to me is, Redwood has a lot more emphasis on templates, and like larger reusable things that address their broadest interaction patterns. It really made it clear like the focus is on creating products and getting them out in users hands and getting feedback quickly from real users. Whether that's like, oh we're going to ship things in beta and run test groups, or AB test, or we're going to just get live code faster and, do moderated testing, like whatever that looks like, it's a lot more about like getting things created.

Elyse:

What are those, What are those templates like, like, what's the actual like deliverable is this, you know, like a example to look at? Is it Figma? Is it code? Is it like a code recipe? What, what is the actual like deliverable of a template that you would use?

Beau:

Yeah. It's pretty much all the above. So like full blown page templates for some key flows that you can kind of just like, add your content, fine tune it, and you have, like, an idea illustrated at the very least in Figma that you can start to get reactions on. But yeah, there's also code with it, so you can get to coded prototypes faster. It seems, at least from my perspective, geared towards moving quickly, being competitive, also being able to get feedback, and run really solid product process quicker.

Elyse:

When you started, you said you were seeing what's different, exploring that, seeing the templates. What was onboarding like?

Beau:

It was, so it was my first time onboarding fully remote. I worked remote in the past at all my jobs, but it was my first time onboarding remote, meeting everybody remote, dealing with my mountain of onboarding training, home alone with my cup of coffee. So I gotta say the flow overall, and getting into it was really well designed. Looked at onboarding at U.S. Bank, onboarding to the visual design practice, which I was involved with for a little bit, and onboarding to the design system. I can try to think through like, what do you need, as a designer. But I had already been at U.S. Bank for like three years, four years. So there's a lot of just knowledge that you pick up over the years that you don't think like, oh, people would need that told to them. What we created probably had a lot of gaps in it. So it's been interesting jumping into Oracle and seeing like the things that exist to help me learn about the system and jump in and start using it. Like, oh, I wish I would have thought of doing something like that in my past role. You can't really put yourself in the shoes of someone onboarding to your system. You really have to if possible find someone who just onboarded. And dig in, ask some questions, figure out how it's going, check out their work, see how they're using the components.

Elyse:

It is so hard to remember all the things that we didn't know when we started at a new company. And I feel like the design system really gets short shrift in onboarding.—Mmhmm— and I have, I have never. I've never really worked with a design system team that was able to spend really significant time thinking about new hire onboarding. I'm just thinking about how impactful that must be to join a new company and actually be able to go through something that talks about the system as part of the process of designing and building UI, which is really, really kind of amazing. What kind of things did they talk about around the system in onboarding, like what kind of things did you learn?

Beau:

Yeah, it was a lot about why the system exists, how do you use it, unpacking the concept of templates, looking at things like brand and color palette. Similar to U.S. Bank, we kept it really high level and I still think that's a good approach because, you know, I was new to Oracle and trying to learn like 1500 things. I don't really want a tour of like how to use your Figma component right now, but I'm probably going to want one in like two weeks. So it was good to have that high level view, know where do I go when I have questions, where do I go to find documentation? Where are your components? I think that was all good. I think the piece that could be better is beyond that initial onboarding, how is the design system helping people get up and running a little bit more hands-on? How are they teaching design leads

or creating self service

Beau:

documentation or videos, like what what's that kind of like next stage where, we don't want to welcome someone and say like here's our whole native system and our responsive web system, and here's where the code is, and here's how we do release cycles, here's what tokens are, like you don't want to do that. Once they get in, and it's like, okay, I'm working on native apps, I'm going to start with iOS. What is our log in screen like, what's our authentication flow? That's where you can start to see like tactically what do people need, and how do we help them through that? So that's still

a missing piece,

Beau:

but I think that second wave of onboarding is a really crucial one.

Elyse:

Yeah, uh, just pin that any listeners who are on systems team, something to focus on something for me to focus on So you have joined a AI team. Is that right?

Beau:

Yeah. Yep.

Elyse:

I'm really curious to hear about that because design systems are like just stepping into, the AI tools space. I've heard from a number of people over the last six to 12 months that they're like, we're building a design systems really focused on, you know, our chat related components or, you know, how our system can handle the experience that we're trying to make with AI. I'm curious, you know, for, for you and for your team, what are some of the ways that the design system is helping you do that? And what are some of the places that you're kind of in uncharted territory? You're having to come up with entirely new design concepts that the design system just hasn't covered yet.

Beau:

Yeah, no, it's a really good question. I think it goes back to that notion of the system team moving at a different pace than product teams. So as we're working on AI tools and we're trying to push the envelope. And especially in this product space, we want to take in what is everyone doing, and how do we bring that to the health space. So we're definitely trying to move fast, and I think one thing that a system can do really nicely is just set up that foundation. Like we don't have to go work on color palette, we don't have to go work on typography standards. And we want like the presence of anytime AI is helping you, to have um you know a certain look and feel. How do we accomplish that? But really I think, like the the system helps set up the foundation itself so you can create those things in a way that you can apply a lot more broadly, than if there was no system. So I think that's a really a big way that systems are helping us move a little bit quicker. We don't have to spend time on components or spend time on maintenance. We can focus on like what the technology can do and what users actually need and how can we bring it together? And a lot of visual design, front end design, front end development, can be you know, a lot faster, or really handled primarily by the system.

Elyse:

We're, we're working on some health related AI stuff also. And one of the things that we've been thinking about is, how do you make it clear, you know, where there's AI support or where there's generated response, things like that. How are y'all thinking about moving that kind of design guideline back into the system, so that other teams can be benefiting from that thinking too? What does that process look like? And or have you gotten to do that yet at all?

Beau:

I haven't personally but, yeah that's the plan once we establish things, that's definitely part of the process, like, when do we want to dig into that with the design system team? I don't know today, but I'm curious to know, like, what is their criteria? And they've also got a view across more of the organization than I have so far. So it'll be interesting to see, what, what type of reach does a template need to have to be in the system? Versus on the product team. So I'm interested to see like, yeah, what does that look like here? And what's the criteria for that kind of a contribution?

Elyse:

I'm really interested in and I think starting to see more of these multi layered systems, I'm hearing a lot of people call them recipes, like the ways that we're going to start adding and separating layers of a system and layers of components. Because I think it's weird to say like, hey, this element of this product, oh, it's not really a component. It doesn't really belong as part of the system. It's like, well, no, it totally does. Maybe it doesn't go in some of like the core things alongside like buttons and inputs, but it's still really valuable. So I'm really curious to see if that becomes a little bit more of a standard thing in design systems. I think a lot of teams are already doing that and have been doing that, and, I think maybe just the way that we talk about design systems hasn't like fully caught up.

Beau:

Yeah. And some of it, I think like it does come down to the vernacular where you're at in your company. Cause we, we were working through that at U.S. Bank. And we have this notion of like, core components that were owned by the design system team, the Shield Design System. And then on top of that, we were setting up a commons, Shield Commons space, which would be owned by the community. So we still had this distinction of like, we have our design system, but then on top of that, we have our community. And we were calling them both Shield. Because the idea is like, all of this is reusable. All of this is what you, your teams, your developers, your designers, should be using, from like pretty much everything that you do. I like the term ecosystem to think about how it all comes together. Those core components, you know, those things are kind of like the foundation of everything, they shouldn't honestly be changing too much. But then on top of that like, how do you create space where there is a lot of change and reuse? And maybe a little bit of chaos is okay. So it needs to have that level of just flexibility.

Elyse:

Yeah. On that note, one thing that always comes up is this like, engagement of the system team with the consuming team. Like we have office hours, you can come ask us questions. And so, you know, a consuming team designer comes and they're like, Hi! I have a question that, you know, something basic that's totally in the docs and the system team is like, ugh you're wasting my time. Go read the docs. Or they come with a design and it's kind of complicated, and the design system team is like, I don't have time to review all of your work. And so I think a lot of times it's, you know, become kind of a point of contention, where I think a lot of consuming teams feel like the design system team is not really listening to them, or they don't want to take their contributions. Or they're not getting the kind of support that they need. From the design system team's perspective, a lot of times they're like, why didn't, read the manual? Like, why didn't you, you know, like, this is not my job. I assume you've been in design system office hours. You've been on the system side of that. But presumably you're getting to interact with the Oracle Design system team, and talk to them. What have you seen work or not work? Uh, What has your experience been?

Beau:

Yeah. I think it's funny, the documentation example, because I think I've also seen the opposite where like people read it too closely. And they're always like, oh, we found this error, like this, this is inconsistent between like this component and that one. And you're just like, ah, dang it. But it's not fair to assume that people don't read. I think people do read. They're very intelligent. They're very curious. Sometimes people don't have time to read like five pages about a component, when they're after one detail. So yeah, just kind of have grace with people if they have a question about a component. And here, they're talking to you, they want to know the right way to do something. It's a good thing to say like, Oh, let me take you and show you where you can find that. Because you might have like tabs in your documentation that didn't make sense to the person at first. Great, like show them around, give them a tour. But, yeah, it's never good to to get snappy with people for bringing questions. But I think one thing that works really well too, is just like having a place where you can ask questions at any point. So here at Oracle there's a Slack channel. That's pretty common. And I know there's sessions you can go to as well to connect with the team. You know, it can be dangerous for the design system team, cause you'll get potentially like a lot of questions. So you have to have some clear communication around what can we help you with, what can't we, when should you expect a response. You know we're not just sitting here on slack waiting to hang out with people and

Elyse:

It's my whole job. I just sit here and stare at the design system channel waiting.

Beau:

Why is no one messaging me? Ah, so lonely.

Elyse:

What a waste of a day. Nobody messaged me.

Beau:

Yeah, so it's just knowing, like, people have a lot going on and knowing that you have to set expectations. Some of it's just having grace with people and knowing like, oh, you're busy. Yeah, they're busy too. They don't want to read. Or they don't have time to read this today, they just need to get moving, so how can you help them? Again, we're all on the same team, so sometimes you have to hold hands a little bit to help people find the answers. But then hopefully in the future, maybe they can help the next person along. I've also seen that work well, especially for developer communities, like create a space to answer questions, but make it more of a place where like the community can answer questions too. So if it's like your package isn't loading, right. Someone else had that same problem. Here's how they fixed it. They'll tell you. Great. So finding ways, and maybe that goes back to incentives, if there's a way to give kudos when people help others outside of the team, any ways that you can help grow systems thinking and a sense of community will benefit both sides.

Elyse:

So, so true. So as we wrap up, I really, I really have to ask this question because I feel like it is again, such a hot topic for design system practitioners. Which is this idea of, how do I talk about the value of my work? How do I get a promotion? Is there a career path for me in design systems? It can be a lot more straightforward to do on a team, you're like, I was on team D and we were responsible for this feature and it converted this many people and it's sold this many dollars of revenue. Therefore, we hit our targets, we did a good job. We contributed this much to the business. And I mean, it's not always that straightforward on a product team either. But I feel like every design system person that I know, myself included, has had the struggle on design system teams where we're just like, how, how is this helping my organization? And you have this sense in your heart that you are, but it's very, very hard to calculate. What has your experience been talking about the impact of your design work as a feature team designer or as a design system designer?

Beau:

I've been in large organizations for really like my whole career. And the thing that's always been a struggle for me is like, yeah, we can say, we released this feature, and then we saw like 50 percent growth in this or that. But usually there's like six things that went into that, like, yes, your feature, but also there was a marketing campaign or a discount on the product or, you know, this or that to create that boost as well. And it's even more difficult for design systems because you could say like we enhanced this component, it got used so many times, this team was able to move that much faster. But there's like so many factors that play into that. And if you're trying to show like system impact based on customer metrics, that's even like times two. So for me, it's always been tough to figure out, how can I capture those metrics, but then also explain, like, why what I did or what our team did impacted that too. It's also hard to be in that team when you feel like you're on shaky ground. Or you feel like, if you were put to the test, you wouldn't necessarily have strong evidence to say like, yes, you invested this much and we showed this much value to the company. I think it's becoming more and more apparent, the designers that really understand how the business works and what the business values are, like they're usually able to illustrate that in their portfolios, or they're able to talk about what was going on within the business and why did they make the decisions they made? So more and more, as I've been involved with

hiring

Beau:

designers, or growing teams or looking to bring people into the team I'm on, it's been more about metrics versus, visual polish. Like, okay, the portfolio looks great, but I want to dig into the text. And read what they wrote. So it's more and more about can you communicate about the business? Can you communicate, like, what was your role? What did you do? How do you solve problems? What tools do you use when you face challenges? Now that I'm back in products, it's still clear that those skills are huge when it comes to being a really impactful designer.

Elyse:

Yeah, I think that's a great reminder of how to talk about what matters. Because for design system practitioners, we don't necessarily have a metric. Maybe we have a, you know, sentiment survey or something like that, but we don't really have a customer metric. So if we can talk about, what did the business need? How did I face this challenge with the team? How did we get this thing shipped? Like, how did we tell the story of the brand through the product, or make change, or make organizational change? You know, even if you can't tie that to, you know, a conversion or a dollar KPI, I think that that's a real skill in how you talk about your work, um, at the, at the systems level.

Beau:

Yeah,

Elyse:

Thank you so much for sharing your experience with us. I think it's probably common, maybe more common than we think, that people move between product design or engineering and design systems, but you often don't really hear people talking about that. So thank you so much for sharing all of these lessons with us.

Beau:

Awesome, yeah, thanks, Elyse, for having me. I really enjoyed chatting and nerding out, as always it's fun.

Elyse:

Yeah, always nerding out. So to wrap up, I always ask every guest on the show, the same question at the end. Give us a Beau spicy take on design systems. What's your spicy opinion right now about the systems industry?

Beau:

Okay, this, may or may not be spicy, it's hard to tell. I don't know if people have felt comfortable sharing this about themselves or not. But I don't think in, in six months or a year, I don't think we'll be thinking, talking, writing about tokens. I think they will become something that just kind of happens in the background. I think the team at U.S. Bank did a lot of brilliant work on tokens, so if, if any of those folks are listening, like I'm not discrediting you, I promise. But I think people are not, not great at managing large taxonomies like that. I think computers are really good at that. So the more we see this common approach applied in organizations of all sizes with all types of needs when it comes to branding and theming and things like that, I think it's just something that is begging to just be automated and done for you. So that, that's something I think will, will maybe be spicy for people soon.

Elyse:

Probably. There's somebody who just spent like three months on their token architecture who's like crying Um, But, ah, you know what? I'm with you. I think that we've really over indexed on stuff like tokens. I'm very curious about the idea of doing that in a generative way. So if y'all go build that, please report back. Uh, we definitely want to hear more. 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!