On this episode of the Design Systems Podcast, we're thrilled to have Beau Ulrey, the Design System Manager at U.S. Bank, join host Chris Strahl live at the Kiln space in Portland. Today’s episode deep dives into the intricate world where design meets development. Beau will share his fascinating journey from a design and photography background to becoming a pioneer in interaction design at IBM, and his current influential role at U.S. Bank. Beau and Chris discuss the vital role design systems play in building customer trust through consistency, and how U.S. Bank’s design system is tailored to meet diverse customer needs across various platforms. We’ll also unpack the complexities of design codes and the transformative impact of well-integrated design systems in the banking industry.
View the transcript of this episode.
Guest
Beau Ulrey leads and manages the Shield Design System team at U.S. Bank. He's passionate about using empathy and good design to help people reach their goals. Whether working as a designer, coach or manager, his goal is to uncover what people need to create better experiences and tools. He writes about design systems and product design practices on Medium (@beauulrey) and talks them as well from time to time.When away from the screen, Beau can be found hiking in the PNW, splashing in the Pacific with his kiddos and toting his camera along the way.
Transcript
Chris Strahl [00:00:00]:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.Cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at thedspod. We'd love to hear from you.
Chris Strahl [00:00:21]:
Hey, everyone. Welcome to the Design Systems podcast. I'm your host, Chris Strahl. Today I'm here with Beau Ulrey. Beau, welcome. He's the design system manager at US Bank.
Beau Ulrey [00:00:30]:
Thanks for having me, Chris. It's great to be here. I appreciate it.
Chris Strahl [00:00:33]:
So you all might hear that this episode sounds a little bit different. I actually found out through the design system podcast application process that Beau lives here in Portland, and so we decided to do this live in person at the Kiln space down in southeast Hawthorne. And so I think this is the first live-in-person that we've done since episode four or five.
Beau Ulrey [00:00:55]:
That's awesome. And it beats sitting at home in front of my computer. So it's great to be here in person.
Chris Strahl [00:01:01]:
And this also kind of, like, feeds into the way that we're trying to start to think about not return to office, but maybe like return to community, where we're trying to get a bunch of people to meet up at local events. We're running the design system leadership summits and major cities all over the country. Check knapsack.cloud/events. And then also we're going to start to do community events where we just get a bunch of people that are really interested in design systems together, have a slice of pizza, talk about what you're working on. But we're going to actually be doing one of these here in about two months.
Beau Ulrey [00:01:29]:
Awesome. Yeah.
And I'm really excited, obviously, to be here today and talk about a passion that we share and also, yeah. To connect more with the community, because that's really the best way to learn about how other industries, how other companies are doing design systems, how are their teams work, what are the problems we're all facing? That's the gold.
Chris Strahl [00:01:50]:
So, without further ado, talk to me a little bit about how you came to be in your role. I think it's an interesting journey. Maybe not the odyssey, but certainly an epic journey.
Beau Ulrey [00:02:02]:
Yeah.
No sirens here. No. I think for me, while I went to school for design and photography, graphic design, if we're going to go way back quickly, got a couple internships, was able to try a lot of different facets of design, was able to try interaction design, and really fell in love with that. Decided I wanted to do that versus like print or digital or advertising or anything else. So after that short stint in my life, got into interaction design at IBM. I was there for about five years, and it was basically like going back to school, but way more applicable. So I got to learn about design thinking and design systems and design research and just all these different aspects of how large enterprises do design. I learned a ton from that role and realized the thing that kind of drove me as a designer was helping people accomplish their goals.
Beau Ulrey [00:03:02]:
So within that role, I was working on products in the HR space. It was all about helping people find their jobs that could be their dream jobs. It was helping managers build their teams, helping recruiters connect the right people with the right roles, helping everyone get their job done faster so they can focus on other things.
Chris Strahl [00:03:23]:
How did that jump into design systems? Cause that was how long ago now.
Beau Ulrey [00:03:26]:
So that was four years ago, like.
Chris Strahl [00:03:29]:
Just before pandemic, you said, I wanna go do something else. What was the impetus for that change and what led you to where you're at?
Beau Ulrey [00:03:36]:
Yeah, basically the thing IBM does really well is it makes a space for new people in the design industry to grow a ton, take on leadership roles, gain skills, learn, and that was great, but then it didn't always offer a best path forward for people to move up in their career. So I started looking elsewhere. I found us bank, and I found an opportunity to take on more of a lead role, and I was able to bring a lot of what I had learned about design thinking and design systems with me and bring that into my team at us bank.
Chris Strahl [00:04:13]:
So you were hired specifically to manage an existing design system, build a new one. What did that look like?
Beau Ulrey [00:04:18]:
No.
Beau Ulrey [00:04:18]:
So I was hired to be a lead designer in the money movement space. So that was working on products. Anytime customers want to move money from one place to another, like transfers, check deposits, fun stuff like that, it could be very dry work. But also it's like the nuts and bolts people need from their bank to manage their finances and get their work done. So I did that for a couple years and then shifted to design systems after that and jumped into a role with the design systems team. Ended up moving also pretty quickly into a management role. So I had to kind of shift my mindset from focusing on the work customers were trying to get done, moving their money, accomplishing their tasks, to the work that my teammates are trying to get completed, helping them grow in their careers, helping them do really awesome work, helping create tools that product teams can use, really across the whole design team, whole engineering team.
Chris Strahl [00:05:18]:
So this is kind of a funny question, but when you think about banking, you don't immediately think design. That's maybe not the first word that springs to mind. And so when you think about this in the context of 100 plus year old organization that is largely about safety and financial wellbeing and security, what role does systems play in that ecosystem, and how does that support design value in a place like us bank?
Beau Ulrey [00:05:47]:
Yeah, I think one leadership at us bank does a lot of work shaping the values that we all want to embody. And that comes from, like, very top of the leadership chain all the way down to, you know, folks like the leaders that I work with more directly. Trust is core to everything I've ever heard since I walked through the door. We're always trying to build trust with our customers.
Chris Strahl [00:06:13]:
That's good, by the way.
Beau Ulrey [00:06:15]:
Yeah. Just want to throw that out there. Very trustworthy place over here. But I think the way that design systems play into this most directly is that we create consistency. And if you're a customer and you're moving from one experience to another, and it feels very different, whether you realize it or not, it gives you pause. It makes you feel like this isn't as quality as it should be. So design systems are a way to get to consistency, to reinforce trust, even if it's just at a visual level, but also if it's at, like, a functional level and a performance level and how this product's working. Design systems are a big part of that.
Chris Strahl [00:06:57]:
It's interesting when you talk about the idea that inconsistent experiences erode trust when you think about a high design concept. We want a design that engenders trust into our organization, and you think about the places where you can do that. That's an interesting topic. But there's also this idea of the places where that breaks down. And like you said, I think inconsistency creates this erosion of trust based on the idea that, oh, this experience is somehow disjointed and therefore not as well thought out, or it's maybe unsafe because there's obviously two systems or multiple systems I'm interacting with here instead of something that feels cohesive. And that is really kind of the focus area for you, is how do you get really into this idea of what breeds the right kind of experience?
Beau Ulrey [00:07:49]:
I think for this is something that's probably going to relate to almost all design system teams or people thinking about systems. It always has to connect directly with the community that's going to be using the system. We rely really heavily on the product teams out there picking up the system, using it, putting it in the hands of customers, because they're the ones that are doing direct research with customers. They're hearing the feedback. It's not always feedback about components, but if it is, we want to know about it. And if, for example, if there's a negative experience where a process fails or there's something on either side that's preventing the customer from getting their work done, what's the next step? Like, how do you communicate that? What does that look like? And that's something that we should do consistently as well. So even if things don't go well, you get a consistent experience in how that's handled.
Beau Ulrey [00:08:48]:
Gotcha.
Chris Strahl [00:08:49]:
So you think of yourselves as two parts, right? In service of these people that are actually building product. And then similarly, as, like, the guardians of trust and the ability to basically shield an end customer who's not necessarily your customer from a bad experience.
Beau Ulrey [00:09:10]:
Yes.
Beau Ulrey [00:09:11]:
And I don't know if I told you this yet, but our design system is called shield. It is the shield design system.
Chris Strahl [00:09:18]:
That's great. No, I did not know that, because.
Beau Ulrey [00:09:20]:
Partly to connect it with, like, our logo, our corporate logo is a shield.
Chris Strahl [00:09:26]:
It's very Captain America.
Beau Ulrey [00:09:27]:
Yeah, it is.
Beau Ulrey [00:09:28]:
We are very into superheroes and our internal communication channels, but we do. We try to create tools that help product teams do just that for their customers.
Beau Ulrey [00:09:41]:
That's awesome.
Chris Strahl [00:09:42]:
And so the greater purpose, if you will, which, by the way, I've started really to hone in on this, in a lot of the conversations I've been having, is like, what's the greater purpose for the design system? Right. A design system for design system sake is maybe not meaningless, but certainly less meaningful than if you're saying, like, how is this supporting some broader organizational goal?
Beau Ulrey [00:10:01]:
Yeah.
Chris Strahl [00:10:02]:
So when you think about the overall purpose and that overarching reason for existing in the design system, what would you like hone in on as the core for that?
Beau Ulrey [00:10:11]:
I still think the overall goal should be helping teams accomplish their goals. So one example of this would be we're partnered up pretty closely with our experimentation team, who partner with product teams. Their goal is to run small experiments so they can see if we make small changes. How does that impact the ability of customers to complete this task that they're trying to do? Like, that's not a novel practice, but because our system works the way it does. It's easier for them to set up multiple versions of a flow and see which one works better. So what we're tuning into is those broader objectives with other teams, and how can our system help them accomplish that goal?
Beau Ulrey [00:11:02]:
Gotcha.
Chris Strahl [00:11:02]:
So you sit there and you look at all these different folks inside of the organization that all have some intention behind the use of the design system. And you support that intention, in this case with speed of iteration. But in all their cases, you probably support it with accessibility or performance or some other thing that is not necessarily the core capability of that business unit or that stakeholder, but provides them a ton of value because it lets them go faster or do better than they would have otherwise.
Beau Ulrey [00:11:32]:
Yeah, and I think a lot of it comes down to adoption. Like, if we see a team not wanting to adopt the design system, usually there's a reason they're not just, you know, not wanting to or dragging their feet. There's always a reason why they're not prioritizing this over their other work. Like, maybe there's other features they have to get to to stay competitive. Maybe they're trying to fix defects that are kind of hidden from view, but they need to work through before they feel like they can migrate to the latest design system. It's always key to figure out, like, what is going on with that team, what are the main struggles they're facing, and then also what are their main goals, and how can our system help them achieve those goals? Like right now, one of the big things we're working through is updating to WCAG 2.2 standards across the board, and our system is well along the way to get there. So using the system can help you get to those accessibility goals a lot faster. It's not going to get you all the way there.
Beau Ulrey [00:12:37]:
There's still things outside of components that you have to address, but it will get you a good chunk of the way there. So we're trying to figure out what are those big objectives for teams and how does our system help, or how could it help, and that helps us know where to take our roadmap.
Chris Strahl [00:12:52]:
Yeah, and I think that a design system's goal to say that it's 100% is always hard. Right. You're not going to be able to cover every single use case because design systems are innately a bit of an abstraction, but at the same time providing that really powerful baseline where a product team can insert themselves, and in far less time than it would take for them to build something from scratch, they can have something that works ultimately for their end user.
Beau Ulrey [00:13:16]:
Yeah.
Beau Ulrey [00:13:17]:
And honestly, at least within the enterprises I've been a part of, I don't think the design system should ever cover 100%. If that's your goal as a design system team, you're going to get so much in your system that you just cannot manage at all unless you kind of eat up all the designers in your enterprise. I think there should always be some amount of what belongs in the design system versus what doesn't. So for our team, we talk about the shield design system, and then we have a commons library that's built on top of the design system that's owned by the community. So we have a button in our design system. You shouldn't have a button in commons, but you might have a button group, or you might have a form flow for applying for a new product.
Chris Strahl [00:14:03]:
So I love this concept, and I wish that more large organizations did it, where there's an informal system almost on top of a formal system, and that that informal nature of it creates almost this playground for experimentation and this place that people can feel free to mess around and break things. And oftentimes what we see in bigger enterprises is this semi rigid structure of, okay, you have a core design system and then some base level, fairly low complex component library, atomic design parlance, think atoms and some molecules, but then organisms and bigger, more complex amalgamations of components tend to be pushed out into these product design systems. And it's interesting, right, because it ends up being either a bunch of different components that are deeply integrated into that single product experience, or it ends up being a composition of those more primitive components into something that represents a recipe. And I think both instances have merit. But oftentimes those systems are too formal to feel like people really have, like some way of contributing to them, something that might be interesting or meaningful to someone else.
Beau Ulrey [00:15:21]:
Speaking of contribution, for a while we looked at our design system, our design system team, and we questioned, you know, we're very centralized right now. Only the design system team touches the design system. Should we open that up? Should we start to look at decentralizing, giving more direct path to contribution? And our answer was no. We're going to keep this team focused on this system, but we're going to create the space where contribution happens. Another aspect of this was the rate of change within that space is much higher because you might have entire flows or page templates or very complex organisms. And product teams are always learning, they're always doing research, they're always iterating. If they find out. Oh, we actually want to totally swap these two components within this molecule.
Beau Ulrey [00:16:19]:
If they have to come to our team, because that's in the design system and change it, that's going to really mess up their timelines.
Chris Strahl [00:16:26]:
Yeah, it's a bottleneck.
Beau Ulrey [00:16:27]:
Yeah. So we don't want to be a bottleneck. We want to give a path to contribution and give clear ownership to those things.
Chris Strahl [00:16:35]:
So I want to back up for just a second on that, because you actually had the conversation that I think a lot of people don't have, or at least happens very organically. And that is like, do we want to have some tight central control of a design system, or do we want to federate it? And there are definitely people that have highly successful federated models out there. I think more often than not, there's a little bit more centralized control. But it is interesting to actually have that chat, and I think this mirrors really well. I mean, I feel like we've talked about Conway's law on every podcast for the past dozen or so. Right. We're like, what is the organizational communication flow, and how does your design system align to the way your organization thinks about how information flows and the idea of a big financial institution? I immediately think that, like, centralization is probably the way the organization thinks about how information flows through it. But I love that you still gave people that need to have a contribution and need to remove bottlenecks from their process and outlet for that.
Chris Strahl [00:17:35]:
I think that's a really intelligent way of thinking about a very deep and fundamental question to your design system of what does your contribution model look like?
Beau Ulrey [00:17:44]:
Yeah, there is no one right answer. This model makes a ton of sense in our company because risk is such a big deal, accessibility is such a big deal. We need as much control over the core design system as possible. But then there's a little bit more freedom within commons. The other aspect of this is that we do connect between the two groups. So if we see something happening in commons that actually might make sense in the core design system, or it's being used by five different teams that have very different use cases, that might be a signal that it's something we should look at bringing in. But that decision and that prioritization is really owned by the design system team. So we're trying to find the right ways to build bridges between community contributions and design system roadmap, and we'll see.
Beau Ulrey [00:18:40]:
It might look totally different in two years from now, but I think it's a good next step to get that community grown.
Chris Strahl [00:18:47]:
What does the composition of those different teams look like you have a formal design systems team. And within commons, what does the makeup of contribution look like there?
Beau Ulrey [00:18:57]:
On a very broad scale, we have our team split up into business lines or segments. So we might have a corporate section and money movement and different segments. So we partition the common space in the same way. Typically what teams are contributing will get reused within their segment because it's something like a check deposit flow, or you're transferring money, and that might look the same whether it's internal or external or person to person or whatever. So right now it makes the most sense to keep those in the segments, and then they also own those, maintain them, perfect them over time.
Chris Strahl [00:19:42]:
So tell me about the places where your design system abuts other pieces of technology inside of the bank. And the reason why I asked this question is I've never had a banking experience that didn't feel like I was touching something else at some other point. Be that plaid or Zelle or ACH is different than accounts and deposits. You know, an entire services platform that is attached to it that is obviously something that is branded like the bank but is not owned by the bank. How does that ecosystem work with the design system?
Beau Ulrey [00:20:17]:
Right now we focus on three main tech stacks. So we have react, that's anything web. We have AEM, Adobe experience manager, that's our USbank.com site, and then we have native as well for our apps. So what we're working through right now are looking across the whole ecosystem, not just based on tech stack, but based on what type of user you are and what point in your customer journey you are, this system might have to look and function a little differently. Like if you're a potential customer and you're just checking out the products we have, and you're trying to learn more, or you came across a knowledge article, you're doing research about something, you're considering, that experience will be very light and bright. But if you decide, okay, I'm going to apply, I get approved, I'm managing my finances. Six months later, that's going to be a little bit more data rich. That's going to be a little tighter.
Beau Ulrey [00:21:16]:
You're focused more on getting a job done than just doing research or learning. So we're looking at the ecosystem overall and trying to figure out things like data density, brand expression, and how to fine tune it in the right ways for the right use cases.
Beau Ulrey [00:21:34]:
That's interesting.
Chris Strahl [00:21:35]:
So in terms of the idea about like, all right, we have multiple different types of technology we support. That's across essentially three different ecosystems. Where are places that the design system doesn't extend to, that you feel like maybe it could or should?
Beau Ulrey [00:21:52]:
Well, we always have a partnership going with marketing, so when we zoom out a little bit and just look at our brand overall, we kind of have our overall brand, and then it branches out into, like, what you'll see in print in a branch, if you go in, or what kind of mailers you might get in the mail. And that's kind of next to our digital brand expression, which is our apps and our websites and the ATM that you drive up to. So I think something that could be interesting in the future would be looking at cohesion between those two forms of expression. And we've done a lot of collaboration with marketing and we've influenced each other. I think it's been really healthy, but I think that's always something that could be taken further. Also, things like the ATM experience, not just different technology, but you. You're in a very different mindset and you're in a different context. You might be in your car or you might be standing on the street corner.
Beau Ulrey [00:22:56]:
It's very different from being on your phone at home or being on your desktop computer or something like that.
Chris Strahl [00:23:01]:
You think about new technology enabled experience, like contactless payments, or the ability to do things that are like, hey, I can do a transaction by tapping my phone to yours type thing. And all those like, have been largely the domain of separate app ecosystems. But more and more, you're watching financial institutions take forays into new tech that is not necessarily screen based.
Beau Ulrey [00:23:23]:
Yeah, I mean, we do have assistant experiences in our app and our sites to help do text based interaction that can be really helpful in a ton of different use cases. It can be a helpful piece of tech from an accessibility standpoint, too. In some ways, it's almost like assistive tech. So looking at those types of experiences, I think are another opportunity for our design system. I've yet to see a really well done system approach to a text base or a verbal navigation and interaction.
Chris Strahl [00:24:03]:
Looking at what's next for knapsack, what's next for a lot of our customers? Trying to think about interfaces associated with AI, interfaces associated with chatbots, invisible automation, all these are things that are really challenging because there's not a lot of. Really well done. Yeah, this is the thing. I think there's people working on it, but it's just not quite there yet. I think that the other thing that I wanted to chat about is there's a lot of accomplishment in what you've done to create a system that does create shield, create a contribution model with commons, do all this work to sort of organize a way of working around systems thinking. I imagine that didn't come without a few pitfalls along the way. I think that if there was anything you're comfortable talking about where it didn't work out exactly the way you were hoping, or there's something that other people that are on this journey should be aware of as they embark, or consider embarking that you wish you'd have known.
Beau Ulrey [00:25:00]:
There were definitely lessons learned. I think the way our system started, I don't think is unique. It started with a team that was working to. I don't know if curate is quite the right word, it feels a little reductionist, but they were going out and finding how are teams working on forms? Let's get that standardized, let's get that in one place. So their battle cry was kind of, let's get to a single source of truth for all these things, and let's create those nuts and bolts that teams need to get these products created. When I joined the design system team, we were in the middle of growing a lot. So it shifted from just one team to about five to seven teams. And we were working on different aspects of the design system, working on the next iteration of the design system.
Beau Ulrey [00:25:54]:
And one of the things we looked at was, okay, we've got this library, but it's not quite a system because there isn't a systematic approach across all of these pieces. So one thing that I learned was that was okay. Like the first version of that toolkit was exactly what it needed to be. Now, everything needs to be an amazing enterprise level, robust system. If you're just starting out, if you're a small team, or you're just a practitioner who's passionate about design systems, it's okay not to have an amazing system. It's okay just to make the things that people need to get their work done that much better. Might be kind of against the point of the podcast, but you might not need a system. It's more about understanding the needs of the teams you're trying to support.
Beau Ulrey [00:26:47]:
What are the tools that they actually need, and what can you realistically achieve?
Beau Ulrey [00:26:51]:
One of the things that is the.
Chris Strahl [00:26:52]:
Hardest thing to hear from a customer is I need to get to critical mass before I launch. There's these ideas that if it's just far enough along that it solves everybody's problems, that suddenly everyone is going to want to use it. The reality is it doesn't work. That way, your initial set of users is probably pretty small, and you should really focus on serving exactly their needs and learning as much as you can about that smaller group of users. Before you start to think about what does everybody in a company, especially a big enterprise company, really look for and need out of a design system? And that ability to repeatably deliver that value into an ever growing set of users is what the target should be. The target shouldn't be everything everywhere all at once, because that's oftentimes too much. And the ability to actually get it right gets smaller and smaller and smaller. The more people and the more things you include in that initial, like, here we go, let's go.
Beau Ulrey [00:27:51]:
Yeah.
Beau Ulrey [00:27:51]:
And it gets much, much harder to change decisions if you're like, another way to look at that would be if you're trying to create the whole system and then release it versus releasing value in small pieces over time, it's always like a tightrope walk, because it's hard to take a system and cut it apart and say like, oh, these are all logical releases. Sometimes you have to do things in big structures, but as much as possible, releasing in small ways, getting feedback really quickly. We have principles for our design system. One of them is listen and learn. And it's all about listening to the people who are using our system, or we want to use our system and trying to learn, like how is it going for them? How is it working or not working? What are their big priorities that we need to be thinking about so that if I could go back in time, I would push a little harder on how can we break these things down into smaller pieces? Whether it's releasing the whole system with a smaller population, or we're releasing smaller pieces of it, or we're not releasing, we're just like bringing people in and doing more focused testing and much more rigorous proving that it's usable and that people are getting the work done with it.
Chris Strahl [00:29:16]:
I like that idea of inviting people in, and I think this is also somewhat underutilized in our industry. Is this idea that the longer you can live in beta, probably the better off you are, because the stronger the thing will be when it ultimately ends up hitting a first release. But that beta can't be in isolation, because much like as a SaaS software company, we are not our consumer, we are not our customer. And so making sure that you invite your customers into that conversation, which would be other product owners and designers and engineers in the organization that aren't necessarily building the design system, but are consuming it, that creates an overall, much stronger product.
Beau Ulrey [00:29:54]:
Yeah, and that's one of the big benefits we're going after with commons, having that community space. We want a space where tinkering can happen, smashing can happen, and it's given the opportunity to be proven. And if it does get proven, then it's something we either want to encourage or consider bringing into the design system. So there's a few different ways to bring people in and have them be like active participants in the system. Last year for our team was all about releasing big majority pillars of our system. And this year is all about building up community, building up adoption, making that space where people can try things, break them. We can learn from all the happy accidents that happen along the way.
Chris Strahl [00:30:45]:
So I think that's a great place to leave it. Everybody loves Bob Ross, and now I'm just gonna be happy for the rest of the day.
Beau Ulrey [00:30:50]:
So go home and paint a little.
Chris Strahl [00:30:53]:
Exactly, exactly. Well, bo, thank you so much for being here. I really appreciate you sharing your time. And hey, sharing the same physical space. Hallelujah.
Beau Ulrey [00:31:01]:
Yes, we might have to do a selfie for sure.
Chris Strahl [00:31:05]:
We'll get it in the show notes. Awesome. Hey, thanks everybody. This has been the Design Systems Podcast. I'm your host, Chris Strahl.
Beau Ulrey [00:31:10]:
Have a great day.
Chris Strahl [00:31:12]:
That's all for today.
Chris Strahl [00:31:13]:
This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter. We'd love to hear from you with show ideas, recommendations, questions or comments. As always, this pod is brought to you by Knapsack. You can check us out at Knapsack.cloud. Have a great day.