On Theme: Design Systems in Depth

Building a multi-brand joint venture design system for BetMGM, with ToniAnn Drenckhahn — #06

• Elyse Holladay • Season 1 • Episode 6

Share episode

📲 Text the show your thoughts!

ToniAnn joins the show to share her experience building a multi-brand design system for BetMGM and Entain's joint venture. This episode is our first project deep dive and it's full of legacy codebases, lessons learned, and big wins. ToniAnn talks to us about dealing with ambiguity, owning your decisions, and keeping leadership on board as you ship a system that changes the way your business works—and your partners businesses, too.

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


ToniAnn Drenckhahn:

There's also this leaning on the vision that we try to do with our leadership teams. We know next year where we want to make progress, but in five years, where are we going to be? What does that five year vision look like with the design system? What does it look like without the design system? And we're able to actually use that strategy of, that's where our other teams are going in the future. You know, they're trying to be more collaborative and work together more. Okay, well, if that's true, here's how the design system is going to enable that, because you're all using the same components. We already are confident that your dev teams can deliver this stuff.

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 is ToniAnn Drenckhahn, Senior Manager of Design Systems at BetMGM. ToniAnn studied Visual Media, Photography, and Graphic Design at Rochester Institute of Technology, so naturally she went into UI design and didn't pick up a camera for years after graduating. She accepted her first design job on the digital experience team at GEICO, and since then, she's been involved in design systems for about seven years, at Capital One, where she worked on their single product platform design system and then a global design system for multiple products. Then she moved into the zero to one space, made a design system at Dave, a FinTech startup, to support the product as the company went through their IPO, and then went to the design infrastructure team at DoorDash working on supporting Prism. And now she is at BetMGM leading her own band of design system nerds. Thanks so much for coming on the show.

ToniAnn Drenckhahn:

Thank you so much for having me. I am super excited to be here.

Elyse:

I am too. And I'm really excited to have you share what BetMGM is doing because you've been working on an initiative to stand up the first real design system for BetMGM. So tell us what is the initiative? What have you been doing? What's the setup?

ToniAnn Drenckhahn:

Yeah, so, BetMGM's an interesting organization to work on design systems with, because it's a joint venture between a company called Entain, which is a UK based sports betting company, and MGM Resorts. And so BetMGM has their own product and their own design teams. And we've been working hard on trying to figure out how we navigate this space, and how we really compete in the area of sports betting and iGaming. But our technology actually all comes from Entain. And so logistically speaking, that's, that's really hard. You know, we, we sit far away from our development teams. We share a platform with many other brands that are not really connected to our business, but that do impact how we ship products. And we haven't had a structured front end that provides components and tokens and theming the way that really robust design systems actually do have. So we've been starting with the Entain teams to change all of that. Because it's very hard to ship products when you have sort of an entangled front end that's really not enabling our teams to ship fast, or to even ship like autonomously. Things take a lot longer than they should sometimes. But a lot of what we're trying to do now is figure out how can we just deliver a front end that feels really modular, feels really reusable, and also enables more of our teams to do the things that we have on our backlogs, and we've been itching to do for a while.

Elyse:

So you were brought in to turn that into a systematized way of shipping front end and design, right? It's not just like build a design system. It's like, we have a front end and a brand that we want to ship, but we're using this other company's technology. And whatever code we ship has to work with that. But we also want to have autonomy over it. But presumably you're also trying to provide a system set up that works for Entain as well and for the other brands.

ToniAnn Drenckhahn:

Yeah. And that's been a really tough part because when we started all of this work, um, you know, I have a lot of experience in design systems, that's why BetMGM hired me. But to deliver a design system, I mean, we know you cannot untangle anything. You can't just do it for one brand and hope that it works for everybody. It has to be solutions that you know are scalable and that you've validated are scalable at this multi brand multi organization level. And so there's been a lot of hardships, I think, in trying to navigate that space. Working for BetMGM, but getting my Entain partners to trust our team, that we also are delivering solutions that will scale for them. And that will ultimately elevate their products as well.

Elyse:

How big of a team do you have? How big is Entain? How big is BetMGM? What size company and design system team are we talking about?

ToniAnn Drenckhahn:

Org wide? BetMGM probably is, is like the, 2000 and under. I know you always like select your company size, BetMGM is not very large. It's, it's kind of interesting because BetMGM has a internally like a, a very startupy type feel where we are not afraid to fail. But we have this backing of a really strong brand like MGM. Entain is a huge company. And they've also over the years acquired many of the brands that they own. So they have people in places where like, we have partners we didn't even know existed. And we were learning throughout this process oh my gosh, this is actually so much larger than we even thought it was at first. Design systems wise, we're actually operating on a pretty small team, which has been helpful, honestly, to move fast and get the alignment and the learnings that we need throughout the team. So my team has three designers on it right now, and I think we have plans to scale next year as well. And then the Entain Design Ops team has. It's been changing over time, but right now we work with three core designers on their team. And their leadership teams as well.

Elyse:

I'm just imagining the legacy code base of multiple acquisitions and it's probably very exciting.

ToniAnn Drenckhahn:

are like the most scary thing, but also kind of the most fun. Cause you're like, I don't know how to solve this problem. I tell my teams all the time, like these problems can feel really frustrating if you are in this headspace of like, Oh, I just wish I had cool, really innovative technology to play with. But if you can solve the problems of a legacy code base, where people are so afraid to touch certain things because nobody at the company knows how it was built. You can solve any problem from there.

Elyse:

Yeah. And I feel like getting into a legacy code base is a real skill. It's a much bigger challenge than building something from scratch, it's very easy to build something new, but getting into, you know, a 10 plus year old code base that has, three acquisitions in it and trying to turn that into like, for listening. You know, some new modern ways of doing things without breaking anything. That's a real, like, that is a major effort. And it takes a lot of skill. I think until I get in there and be like, oh, okay, here's what's going on. Here's all the nooks and crannies. Here's all the bits that literally nobody at this company even knows about anymore. And I'm going to get in there and try to figure out how to make this thing

ToniAnn Drenckhahn:

Yeah. It's

Elyse:

stay afloat.

ToniAnn Drenckhahn:

You really have to get creative with some of the solutions and our teams are trying to work around every corner that we can to go like, okay, how can we pull one lever without knocking down the entire house of cards? And how can we figure this out? Being on the flip side of it and having worked at a startup in the past, creating a design system from scratch, that was a lot of fun, and I learned a ton from that, but the problems you face are, it's a whole different game we're playing here. And so many companies need it too. There are so many companies, especially that I've worked at, I've worked at a lot of large companies that have legacy code bases, they need it the most. And I think they need people who are really passionate about solving these problems. So I'm kind of happy to be in that space now.

Elyse:

Yeah. It's, I think, a myth to go into a company and be like, we're going to start this thing from scratch and it's going to be perfect and easy and ideal, and we're going to use all these new technologies. That's just not, if you ever get to do that, you're extraordinarily lucky.

ToniAnn Drenckhahn:

Yeah.

Elyse:

Okay. So tell us a little bit about how you got started. You get brought in and you're like, all right, we need to, I'm guessing that it wasn't, we need to build a design system. I'm guessing the problem statement at the beginning was a little bit more abstract, like we need to ship our own brand. Or we need to be able to change things on our own. What was the initial problem statement and how did it turn into a design system as a solution to this problem statement?

ToniAnn Drenckhahn:

I think the problem statement has been rumbling for a number of years now with BetMGM. When we started off leveraging Entain's platform to deliver our experiences, there were definitely hardships as we tried to overhaul the product. You have a new product and design team, they come in and they're like, we want to do this and this really cool thing. We want light mode, we want dark mode and we can design it and we can dream it. But then you face so many blockers with shipping it. And so over time, those things have definitely started to be documented and bubbling up to the surface. Throughout the past, couple of years that I've been at BetMGM, we've actually transitioned to a squad working model, which goes to show you how much legacy you were at. There were still large parts of the company that were shipping in a very old waterfall model when I first joined. And so when we have all these squads now trying to ship and scope smaller elements of the product, there's even more issues we're facing. Like, okay, well, this squad wants to ship this feature, they can't because there's six other teams with dependencies that are responsible for it. Or if we do it in one place, it's going to change places that we didn't intend, because things are coupled together on a way that's really not helpful. So I think the problem definition has always been how do we ship faster? And for a while, the solution was, well, we need more resources and we need BetMGM specific resources. So there was a lot of partnership with Entain to make that happen. But after a certain point, you get the resources and you're like, that didn't work. Like, there's still something

Elyse:

You can't just add more cooks to the kitchen and expect to get more out of it.

ToniAnn Drenckhahn:

Not much you can do from that place. That was our huge problem on the product and design side. On the tech side, there's also looking at how do we increase speed and performance? How do we make this more manageable to have all of these teams put in requests to actually want to change things? How do all these brands come to one team or multiple teams to actually get changes in? And the proof of concept for the design system actually started on the tech side. So we had, our partners built a POC, which showed how we could manage theming easily through Figma variables and outputting that through Storybook and maintaining that single source of truth connection. It was a really cool concept. But it was really focused on the technicalities of delivering theming behind the scenes, and this idea of providing brands more autonomy over their front end styling. And so when we started we were like, all right, we've got the dev side, proved out this model could work from a technical standpoint. Now they staff design to it. To be honest, I don't know that anyone understood exactly what we were about to get into. As is the case with a lot of design system work. Taylor Cashdan who joins us a lot on The Question has that image of the iceberg, and we've been passing this around internally for a while. We're on the top. You've got, yeah, we're going to build components. We're going to build tokens, but there's so much more underneath it, that I think many people didn't expect. And so we started designing components and churning things out really way too fast, ahead of dev teams, even like nothing was aligned, nothing was really thought through.

Elyse:

YOLO some components.

ToniAnn Drenckhahn:

Yeah. I mean, leadership wants to see something, and how we're going to make this progress. And so you figure like, okay, well, we've got to put together a proof of concept. But a proof of concept does not make a robust design system.

Elyse:

No, no, tell me, tell me a little more about that dev proof of concept. You said they were working on theming. Because when I hear a proof of concept to go from some Figma variables to some code variables and see that in Storybook with the words proof of concept, I'm imagining a bunch of tooling that is not the same thing as going into all of our actual front end code and tokenizing it and getting those things into real production. Is that where it started?

ToniAnn Drenckhahn:

Yeah. Pretty much. I mean, so it's a vision, right? It's a vision of like, oh, this would be really cool if we had this. Not really a plan at that point yet on how we're going to deliver theming at scale because it's one thing to theme your components, but it's another thing to have your entire application be themed. That is a multi year journey for us. We had to do a lot of work to explain too, because there's a lot of misunderstandings or misconceptions about, oh, we're working on the design system, so when will we get light mode and dark mode? And I was like, wait a minute.

Elyse:

Whoa.

ToniAnn Drenckhahn:

There's a few things in between there that we're going to have to do. I think that was the toughest part of the POC. Like it generates what we need from terms of buy in, to keep going on this route of design systems. We had a lot of support from leadership at a high level of, what this thing was going to give us, and what it was going to do. I think you reach a point with legacy applications where you're like, we can't do anymore. And if we can't do anymore, what are we going to do as a product? So we had that from the POC, but it remained to be seen how this was going to be managed. And then what happens in the meantime, we're dealing with this interim state right now where we're shipping the design system and building it and now it's partially in the product. We're like slowly, slowly getting there, but in the meantime, you still have code coming from like eight different areas. So how do you tell people where it's coming from?

Elyse:

Yeah, it makes sense that leadership is interested, right? You're describing a massive legacy code base where it's actually impeding your team's ability to deliver improvements on the product. But you were saying we went way too fast. We went straight into building components. How did that actually get started? What did you build? What kind of components did you start designing? And then when did you realize we can't just make these off in a corner.

ToniAnn Drenckhahn:

So I mean, differentiation was a huge conversation when we first started this. And when we say differentiation, we mean like brand differentiation. A lot of what Entain feels managing all these brands is like, everyone wants something different, and so how do we do this at scale? And in a way that's not going to assume the most tech debt, right? And so when we did this proof of concept, we actually took our sports header navigation. Our sports is typically the most complex part of the app that we have. We were like, let's try this out. The navigation is actually different across Entain brands, so we share like one product platform, but it shows up in different ways. Good example, we always use pills to navigate, one of the Entain brands has tabs So they wanted to see like, how can we create a design system that will support switching a theme and going, boom, you have different product areas. So a lot of it was standing up the components at first that were in that header proof of concept so that we could show a tangible product output. But part of it was also that, one, these components didn't cover every use case. So we ran really fast for the POC. There was a misunderstanding at first that the components we put in the POC were done. And we're like, no, that was like—

Elyse:

No, no, no.

ToniAnn Drenckhahn:

It's proof of concept. This is not delivery. And then there was another conversation around, we need to be really clear, when we say differentiation, there's visual differentiation and functional differentiation. Visual differentiation is what we were handling through the design system. If we're going to talk about functional differentiation, Product A wants to use these components, Product B wants to use a different set of components, we need to be really clear through this proof of concept, that the design system does not do that. You have to handle that on a product level. We had gone so fast to build all these components and try to set them up in a way that would showcase this. But ultimately it really wasn't the conversation we should have been having. We should have been having a conversation around well, design system standardizes Let's say that first. There's going to be a certain level of like a button is a button is a button. We can change radius and color via tokens. And we can build an unlimited number of buttons, which we did, we built a ton of buttons at first. But the way those buttons get put in the product, if one product wants to have a primary that's filled and a secondary that's outlined, but another one wants to have both filled, that's going to have to be handled at some level. So there was this partnership that's now needed between the design system and the product engineers to showcase like, if you want to have different products, we have to have that conversation and it's not a design system solve.

Elyse:

There's two things that you said that really stood out to me. And one is just the limitations of theming, right? You can have different styles, different colors, different border radiuses and whatnot, but if you're going to say, conceptually, the buttons or the cards or whatever, are entirely different, at some point you start to build components to do everything and they have like 1000 options and that becomes not helpful. Or you build button a button B button C, and button D, and as a team, you just have to know which one your team uses, which is not helping with the consistency problem in any way. And the other thing you said that I thought was really interesting was this idea of how do you ship a component like a header that sometimes has tabs and sometimes has pills? Like, that's a real challenge.

ToniAnn Drenckhahn:

Well, I think that's where we're still learning and figuring this out. So we've managed to be able to scope our V1 of design system to really basic components, like, let's get the basics right. Once we get the basics right, then we can talk about shipping complex header components with all this crazy differentiation. What is it that we're building for V1, which is atoms, basically, and then what is the rest of the design system ecosystem actually look like? When we talk about building a header that swaps components out, maybe that's not a component we're building. Maybe we're just building a template that can be reused. We have other levers to be able to pull within our organization to illustrate a front end that can be modular and have one central source that outputs different elements for the brand. The thing that we really butted up against at the start of all of this was just this idea that like, oh, you could just ship it as a component and that's fine. And I'm trying to illustrate that if we're going to assume the same tech debt in the design system, like just because we have a design system, it's not going to solve our problems. And then there's a misunderstanding around how much unification does the design system really provide? Because when you talk about implementing design tokens, like true semantic design tokens, in places that never designed semantically or cohesively in the first place, things are going to change in the product. And we were trying to disrupt our products as little as possible with this design system. Things can't stay the same because you had places where, a good example is like, we have a CTA 01 variable that exists in our code today. It's just a primary color, and it's just used every— it's not[just] used for CTAs, it's used for everywhere the primary color should exist. And so when we're trying to unify the idea of designing with semantic tokens in mind, you get this, you get a different UI, really a better UI, a cleaner UI, but that wasn't really expected at first. These are the types of things that come with design system work, the amount of unification and standardization across the board. You do remove some flexibility, but for good reason, right? For consistency, for the user experience and cohesion for your brand look and feel, but also because the tech debt is so real. If you want to enable everyone to do something slightly different, for arbitrary reasons that may be like, don't can't point to business value.

Elyse:

Yeah, yeah, and there's, there's no way to implement these major changes regardless of whether or not you're doing them in a design system, without making some edits or like having things move around a little bit. And I think it becomes a particular problem with, trying to make those changes through a design system because, there's this conception of design systems as a consistency effort. That does not mean that the immediate effect of any change is more consistency. Especially in design systems, other teams start to get a little bit like, you're taking away my control. You're now in my product, taking away my ownership of this. Is that something that you ran into when you were making these changes?

Yeah, we run into this, and I think a lot of it too is

ToniAnn Drenckhahn:

that feeling of you're losing control over your product, it's much harder in large organizations where you can't engage with everybody. It's not physically possible. If you want to get work done, like we have to figure out how to scope our team small enough to get the right stakeholders in the room and then just go, we're going, we have alignment at the highest level. Like if we're changing the UI for the sake of these reasons, and if it's for the right reason, it's okay. But having leadership buy-in is different than the person who sits, you know, seven countries down from you who might feel like, why did our product just change? And it's hard to engage the right people. What we have found though is that it's just about communication. Most of the teams that we've interacted with, who come to us and were like, why did you do this? Why don't we have control? This is not what we asked for. They come around to understanding what the goals are, and are on board once they feel like their voice is heard. Accessibility was a huge one. Like there are certain colors that were just straight up not accessible. That does mean some of the core colors that these brands use have to be tweaked a little bit. And if they weren't informed, that's going to feel like a violation of their product, something that they feel like they own. So we do face like, people feel they have a loss of control, but we always try to focus on, we're giving you a lot more autonomy because, we can point to, especially on the BetMGM side, we can point to times where squads have spent like four sprints doing little cleanups in areas so that our our front end looks and operates better. When they could have spent that time delivering valuable features to our customers and increasing the customer experience. When you put it that way, teams are okay with it.

Elyse:

Always the people stuff. Right? We're like, oh, we're going to build components. We're going to build tokens. But at the end of the day, we're helping our organizations change the way that they ship software, and that is a people effort at its core. It can feel like a challenge to product teams to have that ownership of their UI feel like it's being taken away. And so I think you're spot on to be like, okay, we're actually trying to make it easier for you to ship your UI. And the question is, did you? Or are you just saying that because, you know, design systems. So on that note, when did you really start to get in sync with engineering? And how did you start to see those things become real, like outside of the POC? Where did that momentum of collaborating really closely with engineering get started?

ToniAnn Drenckhahn:

Yeah, I think we were lucky because it started early on, but it wasn't as effective as it could be until maybe a few months after that. So we were lucky enough in January of this year, the design system development team actually attended an onboarding in Vienna where they learned how to build Angular components. We have a lot of teams who have never built a component before, don't really know how these things are supposed to be built, the idea of modularity, it's like teaching a designer, how do you design modularly? That's a whole new skillset in places where somebody might just be only feature focused. We actually advocated for our team on the design side to attend this onboarding. They were like, I don't really see any value, it's a dev thing. We're like, it's not. For us to understand more of how engineering is going to be building components, it helps us set up the components in the right way and design them in the right way, or in a way that we can at least have better conversations. We sat in on their onboarding. It was definitely very dev heavy, we were like, in the back trying to keep up, like, trying to open, VS Code and really get to all these things. Um, it was a great time and it was wonderful to meet so many of our partners. One of the biggest things was the face to face barrier is so real. I always love this story, when we got to Vienna, you know, you have some beers with people, you get to know people a little bit better. One of the things that came out is how much we all hate when people message us and say hi, then just wait for an answer.

Elyse:

Worst Slack etiquette.

ToniAnn Drenckhahn:

It really is. But like on the U S side, I was always like, well, they're from other places in the world, like maybe they're just more polite than we are, like I'm from New York, we'd be really rude and not think twice about it sometimes. So we all felt like, oh, we should, we should say hi. And when we found this out, like, oh my God, we had no idea. Now everyone's say like, don't say hi, just please get to the point. And it's stuff like that that really started to foster the actual connection point with engineering so that people felt less worried about talking to each other and setting up meetings and taking up time on each other's calendars. We have so many meetings with this design system work that I think it was very sensitive. When we first started building components, it was a rough start. We weren't really aligned with development. We started to have better relationships, but there still wasn't an acknowledgement on both sides of design and development around just how important it is to be in lockstep. And so even when we designed components, because we had baggage from the POC, we had to go like, all right, we're actually throwing that out. We're not throwing it out, but we are throwing it out. We had to reset and start to explain why it's important to align on component requirements with our engineering partners and the intention of the components. There are some components that are like, we don't know if it should be one or two components or should we break this down more atomically or is this too big? Those types of conversations took us a while to get to. And even when we were having those conversations, there wasn't always enough engagement to know, like, oh, it's really important that we make this decision up front. So we went through a lot of rounds where we'd design a component, have some sort of alignment with our dev teams, but then we would get to building, and then we would need to redo the component. So all of that is learning. It feels inefficient when you're going through it and it feels like, we, we knew we should be aligning, like, how did we not get there? But it's also that I think people have to go through that type of learning to get to where we're at now. We spent more time in Vienna in September, and we actually had a design development workshop where we had a retro. We talked about our ways of working. We talked about how we hand off components and how we hand off communication for when tokens change and things like that, how we use dev mode, where we should communicate things. And then we also broke down components together and said, if we were going to build this component, how do we talk about the best way to set it up? We use a lot of slot strategies for our current components because they need to be so flexible at this level. And so understanding from the dev side how they're actually implementing that we were able to spend time going deep. Now we have these awesome conversations where we can talk about components. There's a lot of engagement on our calls around the constraints for what we're doing, how to scope components so that we can deliver a V1 and get to the more complex versions later. It required a ton of consistently picking at each other and going like, I think we should be aligning here and we need to reset, but it also required us to go through areas of, not failure, but missing connection points and being okay with that and going, we're learning as long as it's getting better, like, you look at the trend, not the day to day.

Elyse:

What was one of the first very successful components that you shipped all the way into the product? Like design, building the component, delivering that, getting it implemented into. the real shipped live product.

ToniAnn Drenckhahn:

That's a really good question. I'll start with this one. The easiest one has been probably our segmented controller component. There's been no issues with that one. We stood it up, it's relatively simple. We have a couple different variations to support our icons and—

Elyse:

What is a this. segmented controller? I love components that like, what is that?

ToniAnn Drenckhahn:

So it's like, we'll call them button groups, but it's basically like a tab, but it looks more like a set of buttons that you're going through. You can select one at a time. We use them in different areas of our product, if you're on a live game and there's some media that you can watch, you can either watch it live, you can watch like a, an illustrative version of the game. We use it in those places. Or if you're navigating to place a bet for a specific team and you want to find a specific player, you can filter out the teams by using the segmented controller. And that one's been like, that was easy one that was like really no bumps in the road. One of the ones that I think was a huge win for us was pills. We had a product summit where all our product team gets together and we share out the progress that each of the groups have made and Design Systems was lucky enough to be on that stage. And one of the stories we told was about our pills and how hard it was for us. It took us so, so long to change the design of the pills. Because they were all coming from different areas, no one really knew who was styling these components, and now we have these pills centralized. We were like, look, you can change it now. We wanted it white before and now it's gold. Like, look at the success of this. So there's only four or so components that are live in the app as we roll out more and more but we have like 30 plus built already. It's been amazing to see from that standpoint, but there are some that are like, we just did not know how complex it was going to be, like,

Elyse:

Well, especially when you take the product complexity into account, right? It's easy to build a pill that changes colors. It's really hard to build one that's going to go into all these different places and different use cases. Even for something that seems straightforward upfront, when you start thinking about the real use cases for your product. And that's something that it sounds like y'all are doing very thoughtfully.

ToniAnn Drenckhahn:

We, we did face that. I mean, early on when we were designing components, because. there's so much legacy stuff in the app and then there's so many different, like, if you have an account that's this status versus that status. So there's a lot of areas we just did not know existed. And so we tried our best to audit the app. You start with the audit and you look at everything and then you scope it down. But we kept missing stuff. There's stuff that would come out of the woodworks, like random account screens. We were like, where did this come from? Who's using this? Or you have a brand that's got this random page that we never knew existed either. And a lot of it, we just try to keep focusing on that 80%. I know adoption's a big topic, to get a hundred percent adoption, but for us, it's like, let's move forward. That's the goal here. It's a pretty basic goal, but I think it's a really good one that we always lean back on. Because if there's an edge case in the product where the component is not going to fit, we face these times where the component would fit if the rest of the page was designed a different way. Very doable, but a larger conversation to have. You can't just redesign an entire page because one component needs to be there. So we skipped that component. It's not a big deal. We will come back to it. There is so much more work to be done. But we also work really closely with the product teams who actually integrate the components because we found the same thing from the technical side. Tabs took us a pretty long time to get off the ground because there was a lot of complexity behind it that we didn't know we were going to hit. And so now we work really closely where we actually have a test integration where one of the engineers from the product side will actually take the component that we built, do a whole investigation and try to integrate the component, and come back to us with their findings like, hey, I found all these areas in the product where the design doesn't match. Are we okay with that? Or do we need to add more variations? Or like it didn't work the way we thought it was going to work at all. Our core team that we're working with on the design system development side doesn't ever really work on products. They've owned a set of centralized CSS in the past. But they've never been so close to the product to understand how it works. So that partnership has been really important to make sure we're accounting for everything up front.

Elyse:

Yeah, that's so important. How did you get that process with the test product integration stood up internally? What were those conversations like, how are you getting team resources from product team engineers to do that? Are you spreading that around across multiple product teams? I am very curious how you got that as a formal part of the process.

ToniAnn Drenckhahn:

Yeah, so we've been very fortunate in terms of the staffing of the design system resources since we started. It's fortunate, but also unfortunate. Because what happened at the beginning of our design system was, the teams that were building the components and designing them were stood up and set on that path at the same exact time as the teams that are supposed to be consuming them and integrating them were. Logistically, that's very difficult. How do you integrate something that doesn't exist yet? And you're just kind of like waiting. Pretty much every product area had a couple engineers that were dedicated towards design system integration. And we started with our sports products, again, it being the most complex. We're like, if we get that right, everything else should be easy. I don't know if I would have done that in hindsight, like that's, it was a, to start with the most complex one, I get the idea, you know, like you tackle that big thing first. But in practice it's, it's very difficult for teams that are dealing with as much new concepts as we're dealing with. So we would work with the teams, develop that component really quickly. Again, design and develop it almost too quickly. And then they would try to pick it up integrate it, have hardships, kick it back over, there was a lot of ping ponging back and forth between teams. In a way that wasn't positive. I think that can be seen as collaboration at times. In the start, it felt really frustrating to everybody involved because it felt like there were obvious things that should have done more due diligence on. if you're missing variants that anyone can log into the product and see then okay,

Elyse:

No, why are you giving me this half baked thing to build? you're not taking this seriously. So I don't have to either.

ToniAnn Drenckhahn:

Exactly. And so there was, I think there was friction with our teams when we first started with that. But as we got better at component building, and learned our way through it, the teams were able to pick up more complete components. They felt better about what they were being given to start to use over time. And so we were, we basically have a Scrum of Scrums set up. So that is the main connection point for all the moving parts. We had multiple teams, multiple developers, multiple releases, designers everywhere, product managers everywhere. Like it was kind of wild. You know, we had teams who were trying to pick up components that we knew weren't ready. And we were like,

Elyse:

Oh, no.

ToniAnn Drenckhahn:

No. We just need to know what you're doing each sprint so we can let you know if that's a good idea. Or like, we already know you're set up for failure. And then sprint demos. So each sprint, the teams would come to us, even if it wasn't super complete, they would go like, here's the result. Like I tried to use this thing and either like, I'm having trouble and I need help, or, it's obviously not done and we need to fix some things or we need to add some things. So a lot of it just requires, constant communication. And like actually actively listening and respecting like, okay, I hear you, you're blocked. Let's try to figure out how to unblock this and not just going, well, that's the nature of starting too early or like, we're learning. That is an answer, sure, and it's—

Elyse:

That's not a satisfying answer.

ToniAnn Drenckhahn:

No, and it's not really, it doesn't really show that you're respecting your partners and being like, I know you just spent a lot of time doing this, and we hear you. So after we faced all of those problems, we stood up component validation where all the components we had already designed and were either shipped or in the middle of being shipped. We partnered with designers from each of the product areas, had them give us key screens for where these components exist in their product. We sat in Figma and put all the components in the product, got mockups for everything we were affecting change on, so we could see the befores and afters and make sure that we were doing that due diligence up front. It's a roundabout way of getting it done, but stuff like that showed our product teams that we were really trying to hear their concerns. And we were really trying to fix this issue. And now we do it better up front. We obviously got out of that hole, but it also took a number of months. We set up this component validation effort and week after week we had teams still going like, yeah, but it's not working. And we're like, well, it's, it's going to take a minute. Like hang in there with us. We'll figure out how to get this done. But communication again, it's the crux of everything that goes right or wrong.

Elyse:

Yeah, it definitely is. and I feel like for you, you were a manager and now you're a senior manager. I imagine that a lot of that communication and process really falls on you. What were the kind of skills, behaviors, or strategies that really felt effective for you, trying to get a design system effort off the ground in a senior leadership role?

ToniAnn Drenckhahn:

One of them is being present, I mean, a huge one is being present. We have a lot of teams, especially in this remote environment. I have a standing desk and I, I walk. So everyone knows me as like the girl who's always bopping around on calls, but I am on camera all the time. I am showing up to those 6:30, 7am meetings with our partners across the world. I am making sure that I have something to show and engage with. That was half the battle is like making sure that people can see you putting in the effort. And then being really scrappy about the strategy of communication itself. There are channels we stood up that didn't really work. There are things that we tried to implement in terms of processes for UAT and integration that didn't work. So each time we had a meeting where I knew I had my stakeholders on the call, I would present something that's like, okay, here's a new process that we're going to follow, or here's a definition of the process we've been talking about, but I don't know that everyone's seen visually and can align on. So Scrum of Scrums and being present in those meetings and really owning those meetings was a big, big thing, to be able to showcase what the design team was intending to do and then ultimately what we actually did every sprint. We also have risk register meetings where we're flagging those things. It's a lot of like being proactive and going, this is a risk, I'm calling this out. I mean, we were using variables, so we were hitting the Figma 40 modes issue. We knew we were going to hit it for a while. That was on the risk register. So when it came up, teams kind of had an idea of what issues we were hitting and what we were doing, cause I've been talking about it for a couple months before that. For me, it's just like put everything on my calendar. Like I'll self opt out of things that I think I can't make an impact on, or meetings that I don't think are going to be a good use of my time. But getting in front of all the people so that I can look across the board and see like, okay, I'm consistently seeing that in every meeting I've been in, there's a UAT problem. There's an integration problem. There is a component validation problem. Now we can take that, stand up a single process, communicate that out in a single way and then start to iterate moving forward. Um, I also came from, like, Capital One deck culture. I work with somebody who was, who was at Capital One, as well, and we talk about this all the time. There was such big deck, everything was a deck, make a deck for it, like. Big deck energy. Oh yeah. Yeah, big deck energy. And so we had this culture of like, just put together a little presentation. Could be small, five slides, whatever, to show, like, okay, here's where I'm seeing a problem, and here's the strategy I'm recommending that we move forward with. So everyone's in alignment and then I can feel confident going on a call and being like, this is what we're doing. Like, I'm just going to say it with confidence and then make sure people are able to follow up on, what I'm asking them to do at the end of the day.

Elyse:

I love that. There's no substitute for good old fashioned communication and just showing up and talking to people. You need to be in front of them going, I hear you, I see you, I'm there, I'm in those meetings, I'm seeing the five different ways this QA problem is coming up or whatever. That's how things get done in organizations, especially big organizations. There's no way to, there's no way to abstract that work. We can abstract components. We can abstract processes, but we cannot outsource or abstract the straightforward, like, I see you, I'm paying attention to what's going on.

ToniAnn Drenckhahn:

Yeah, absolutely. One of my favorite quotes that always plays on my mind, especially in the times where I feel like I did a really good thing and no one's using it, or no one's aligning to what I want is when you're tired of saying it, they're just starting to hear it. So this has been true like every systems role I've ever had. You have to get to the point where you're like, I cannot say the word differentiation anymore, I can't, I cannot call this component anymore.

Elyse:

Haven't we figured this out by now?

ToniAnn Drenckhahn:

But at that point is when people start to go like, oh, okay. I see what you're saying. And they start to affect change. So I think a lot of it is also like, I tell my team this all the time, it's perseverance. And that sounds really cheesy, but it kind of is. And it's really just like, keep at it. If what you're doing, isn't working, keep your message consistent but change your approach. Maybe you're talking to the wrong person. Maybe you're in the wrong meeting. Maybe your visuals make no sense to people.

Elyse:

Or maybe they just haven't heard it for the 18th time, which is the time they need to hear it for it to really sink in. Because I think a lot of this stuff can be very conceptual, right? It's like, yeah, it's great, like consistency, efficiency, like we need to do that. We're going to have to use components. But what does that mean for me? Like I'm on a product team. I'm trying to ship things. I've got features.

ToniAnn Drenckhahn:

Like when you're talking to somebody, they have 1 million different things going on. It is rare that what you're saying is top of mind for them or feels relevant to them.

Elyse:

Well, especially when we're like, we're going to build all this stuff to make your life easier, and then it turns out the first thing you have to do is a bunch of refactoring, and redoing your mock ups, and getting your manager and your product manager to prioritize all this other stuff, that doesn't actually ship new features, that does not go on your performance review, that doesn't actually improve anything. And you're like, why? Why are you coming to me asking me to do all of this stuff? I don't see how this actually benefits me in any way. We really need to own that. Especially at the beginning, when you're trying to stand this kind of thing up. And so how do you come to them with empathy and be like, here is how this is actually going to serve you.

ToniAnn Drenckhahn:

Yeah.

Elyse:

I think we have to not just say it, but actually change the way that we manage our design system so that it actually does serve them.

ToniAnn Drenckhahn:

Absolutely. Yeah, I think you also have to build that trust. If people are like, in theory, the design system is supposed to be this great thing, but I'm just not seeing it. And they also don't trust you, and they don't think that you have their best interest at heart, they're going to throw it away so quickly. But if they are like, well, I don't know, but I trust this person and they're always there to help me out, and they're always trying to make a difference in my day to day. They're more willing to take that leap of faith with you. And I think sometimes design system work, especially at this scale, where you're coming from the negative and trying to enter into that positive, or even just the black, it requires a little bit of a leap of faith in people. Like, don't quit on us especially when we're starting to make that impact. We've seen that graph of productivity has got to dip before it gets better. And on the dip, sometimes leadership goes. Yeah. Okay. This isn't working. This is proof that it's not working, because I've watched this over time not work. And how do you make sure you illustrate the good things are coming? Like let's celebrate our wins.

Elyse:

Let's talk about the leadership communication thing, because the productivity dip is real. The iteration time is very real. Seeing the big value of design systems is a thing that happens over time, right? Like systems show their value more over time. And so at the beginning, you're going, we've got all these promises about what this is going to do for the actual product. And that all sounds great. We've seen the proof of concept. We're totally on board. The reality is that over, six months you're shipping pills and tabs and selectable controller. And I, and I don't mean to say it in a way that's like, I'm not minimizing that. It's just that you can very easily look at that and go, okay, now 1 percent of the product seems more different or like the same different. We've changed what's under the hood, but the end result of the product doesn't actually feel any different. So this is the very dangerous moment, I think, for new design systems in an organization, because we're telling leadership big promises. And the output, the actual value to the organization, it's hard to see. And so at what point is it like, actually, we're not even going to bother with getting to the the potential value of what could be because it's going to take too long and we could have just kept building product in the meantime with all of this money that we're spending on this team. How are you, especially now as senior manager, but through this whole process, how are you talking to leadership I'm not even asking about like investment and buy in. How are you actually communicating, here's what we're doing. Here's the risks. Here's what we actually delivered. And here's the actual outcome and value for your organization.

ToniAnn Drenckhahn:

Yeah, I mean, I think it's a couple of things. One of it is we're very clear about, building a design system does not mean the product is using the design system. One of the biggest things that we're advocating for next year is we need to continue to integrate this thing. We get nowhere if we don't have partnership with product to actually take what we built. The other thing is because we're in an organization that came from such a hard place to work on a front end perspective, and we aren't able to ship products really quickly. It's gently reminding why we started this in the first place. Um, I do a lot of, I love to lift. And one of the things people always say is, if you miss a day or you're just going to not lift for the rest of the year? Like what that's stupid. Like if you blow out one tire, you're going to slash all four of your tires? That's silly. So there's this idea that like, as an organization, we have to find a way to deliver products better and faster. If we look at what it's going to take to do that, it's fixing the front end of our product. It really is. And that can be done in multiple different ways.

Elyse:

But this is the way that we've picked.

ToniAnn Drenckhahn:

Yeah, that's the way that we've picked and we've invested pretty heavily in this. And I think it's reflecting a little bit on where we've been and trying to make those intangible, invisible things visible. To be honest, I think it's pretty impressive the amount of work that we've got done this year with the amount of baggage that we've had. It's really hard to be able to build a system in this type of environment where you have corners of the product you didn't know existed, stakeholders you didn't know existed, teams that don't design systemically, that don't design together even, and also different businesses. But we're able to go and say, okay, listen, there are all these components ready for use, ready for you to grab. We've validated a bunch of them with not only design, but also tech. So we're confident that this is going to work in the products. Now all we really need is for you to put it in the product. There's also this idea that we've come together on, not only relationships with design and development, but also between design teams in a way that is a part of a larger strategy with BetMGM. So what we're looking at wa s figuring out, instead of acting like our teams don't exist across the pond, like, you know, and Entain and BetMGM, recognizing like, okay, where are dependencies? And if we have dependencies on each other, working together up front is going to get us to an easier place, a faster shipping, experience. And we're able to actually use that strategy of, that's where our other teams are going in the future. You know, they're trying to be more collaborative and work together more. Okay, well, if that's true, here's how the design system is going to enable that, because you're all using the same components. We already are confident that your dev teams can deliver this stuff. I think there's also this leaning on the vision that we try to do with our leadership teams. We know next year where we want to make progress, but in five years, where are we going to be? What does that five year vision look like with the design system? What does it look like without the design system? If you can illustrate that point, and do it honestly, not in a way of like, how can we tell this story to make it sound really good? If you can look at that honest illustration and go, oh, yeah, it's much better if we invest in this, and we invest time and resources. But let's just talk about like, what is too much resources? Where do you think it's not valuable? There's probably a tipping point at which you go, well, we have to ship something. We're not going to put everything into the design system. And we're not going to scale this team to like the insane levels. And then there's also keeping our teams honest. So now that I manage this team, what I try to do is get them to scope things down. If we're not sure about all this extra elements of the component, but it's fluff and it's noise, deliver the core thing. Like just get that done. We can deliver a lot faster if we can scope properly.

Elyse:

Yeah. How do you know if you are shipping the right things to your teams? If the things that they're saying they're trying to do strategically in the product are aligned with what you're trying to do? How do you know when the extra parts of the component is fluff or the key deliverable? Especially when you're talking about a multi year vision, your business needs change. The things your product teams are building now may not be the same as what they're building in three quarters. It's so easy to go off in the corner and work on components because then you don't have to deal with any of this ambiguity that comes along with being really in lockstep with your actual organization. But that's how you're successful within an organization, is actually being nimble and responding to the changes that the organization is seeing, the needs that the product teams have, which change quarter over quarter, but still keeping this long term vision. I mean, there's just a lot of really big unknowns and a lot of ambiguity there. We talked about this a little bit at the beginning before we started recording, this idea of, dealing with ambiguity. You see this a lot in job descriptions, especially as you get into, Staff, Senior Staff, Manager roles. Your job literally becomes, being the person who has to be like, okay, there's more unknowns than knowns, and we still have to actually ship something. So what is this idea of dealing with ambiguity around what you can deliver and how it's valuable, how is that showing up for you? What does that mean to you? And, how have you been able to manage that?

ToniAnn Drenckhahn:

How Yeah. I mean, design systems are always ambiguous for all the reasons you just stated, but start to finish, we were dealing with so much ambiguity and a lot of it was like, how are teams going to work? We want to talk about building a design system to enable differentiation. Does that mean you expect this design system to power multiple product platforms? In terms of real differentiation you can actually support at the product level. Or like, are we talking about still trying to figure out how to support design teams that work in silos? Or are we going to rest of the org? Is it going to work together? That idea of our product teams actually collaborating across BetMGM and Entain wasn't necessarily clear when we first started. And that was a huge pain point for us. We were like, if we don't know how our product teams are going to be working, how are we supposed to make a design system? A lot of it was me trying to get into the right conversations and then just ask questions and then go, okay, I'm not getting a clear answer, but if I can take a step back and look at, this person said this in this meeting, and then I talked to this person, they said this, how can you sort of internalize that and interpret it in a way that makes you feel a little bit more confident? I was really worried that setting up a token architecture for design teams that were still going to be enabled to go off in their own corners and do separate things, this could go south really fast, if we didn't end up in the right direction. I mean, luckily we did, but even if we didn't. At least we can make a decision and go, okay, it sounds like our teams are going to have more success collaborating together. Like this is a joint venture business. It's a partnership. That's got to be true. Starting at the highest level, there's a contract on the table, so we know these people will exist in these rooms together for a certain period of time. And then when you look at it from that standpoint, okay, we're building a token architecture and we're relying on a lot of really great industry standards. So even if we were wrong, you're going to have to be okay with being wrong at some point. But we could back our decision and go, we asked for a clear answer, we didn't really get one. So we took cues from all of these types of conversations. We listened in really hard on like all hands conversations, our product summit, tried to understand how our leadership teams were talking about collaboration and then go, this is what we have to make a decision off of. So let's gather the best information, form a really solid hypothesis, and then go in from there. Um, so in times of ambiguity, I have this thing on my wall. It's like, make a proposal. So you just look, don't know what's going on, but here's what I think is going on. And then like trying to visualize the openness and the opportunity in the organization. Form a hypothesis. Put something together. And then, spot the momentum, and just do it and go, okay, test it out. And be really ready to pivot if you start to see different things. But it takes a lot of paying close attention. Because a lot of times when you ask for answers, you're not going to get them.

Elyse:

But I think you hit the nail on the head. It's okay, how do I define what it is that I actually do know? And what are the constraints or pivot points around what we don't know? Then being willing to be the one who puts their neck on the line to make a friggin decision and I think it's, we, we don't want to do that. Like it can be very scary to do that. And I think that's one of the things that you have to learn as a skill to move up in an organization, from an IC to a leadership role. You have to be willing to be like, I am going to put my name on this decision. And I might be wrong. And I've identified the risks. I've explained it and communicated it to the best of my ability. And if you're really, really wrong, you go down with that ship.

ToniAnn Drenckhahn:

Yeah. and I luckily have not like, I mean, give me some wood to knock on. I'm not have any like career ending, you know, types of things, but.

Elyse:

But I don't mean to be dramatic, but like, I think, we are so afraid that I'm going to get in trouble if I made this wrong decision, so we don't make any decision. So then nothing happens.

ToniAnn Drenckhahn:

But I always look at it from the standpoint of like, if I were to get in trouble for something that I made a decision on and I have to have a conversation with somebody, there's a difference between making a decision, being wrong, and being sloppy.

Elyse:

Yes,

ToniAnn Drenckhahn:

Being wrong because you just didn't think about it. Your focus wasn't there. You didn't do enough research, or you didn't look at the problem and try to solve it with enough rigor.

Elyse:

If you can go back and say, this is why I made this choice.

ToniAnn Drenckhahn:

Yeah,

Elyse:

This is what I knew at the time. These were the risks.

ToniAnn Drenckhahn:

We face this problem a lot where people are scared to put their name on things, so things don't move forward. And there's really no other answer than you can't operate like that. Especially leading teams. Your teams are not confident in you if you're like, I don't know, you just like, can't make a decision, and can't push forward for what the right thing is. But as long as you can justify, like we always have little internal arguments about all the little, the little component related things. We're constantly debating on calls, like really healthy debates, it's fantastic. But what it teaches us is also that there's no right way to do this. But there is a way to think so that you can back up your point of view. If you can back up your point of view, I can't be mad at you for that. I looked at it and was like, I, I did, I know I did the best with the information that I had. You have to be okay with that at the end of the day. Like, I don't think that there's any other way to handle it.

Elyse:

No, totally. All right. Couple last questions. Let's come back to present day. We've been talking about the things we've been shipping, starting with the POC, getting things in the product. What kind of outcomes are you seeing in the organization because of this work?

ToniAnn Drenckhahn:

So we are so excited. We are actually going through a visual identity exercise for our design system. We're naming it, we're branding it. Basically spent this whole entire year being very inward. We were focused on building the design system, not necessarily getting the entire organization to understand and use it, because we weren't there yet. Now we're at this place where we're going to be launching a V1, probably early January of next year. And that'll include some fun visual identity, some really cool sizzle reels and teasers, like getting people excited about this thing that we're building. The term design system also gets thrown around a lot in an organization. We want to make very clear what it is we're actually building. So we have, we'll have 30 components set up in Storybook, ready to go. All those components are aligned with our Figma builds. So we're prepared from a design and development standpoint. We have four components, maybe five components, actually live in the app by this time, as well. And we'll be working on trying to get all the teams to integrate and then figure out what our next year looks like. There's a number of components that we left off of our V1, because they weren't as important, but we still need to build. There will be things that people will want to tweak, I'm sure. And so we're just, trying to put a bow around what it is we're going to give the organization. Right now, we started to see some really great engagement from the summit that we presented at. So we're working with our A/B testing teams to try to figure out how we can start to stand up A/B testing with our design system. We want all of our decisions to be data driven. So we're excited about that. We start to see teams really understanding more about how to actually leverage components and how to affect change on them if they so need to. And we're also standing up documentation. So next year, a lot of what we need to be working on is patterns. And templates of those components, and more of the larger design system ecosystem that we're trying to stand up.

Elyse:

Yeah, I love that. I love that you're launching a V1, but already have things like, here's how we actually integrate into our teams, established. It's not just like, here, we built some components. And now, the grand reveal. And then trying to figure out like, okay, how do we actually get the teams to use this?

ToniAnn Drenckhahn:

Launch is like a soft word for us. Because it's not really a launch. And, yeah, the how we work part is the biggest thing that I'm waiting to see that tipping point still for it to change. We know it'll change, but it hasn't landed on everyone's desks yet. And that's also why there's still misconceptions about the design system across the org. There likely will be until it affects people. I don't know what you're talking about until I see it, until it really matters to me. I think next year more of our teams will start to see that, but they'll start to see it when it goes live in our product. That's why we're pushing so hard on this, because our designers are actually itching to use, they really want to use our theming right now. And we're like, you can for vision work, if it's helpful, like obviously use our tools. But if you're trying to deliver something to development, just know like what you're delivering is not what they have. It's not what they're working with. So you'll be in a misalignment of language if you start to use this thing too early. So we are really excited for the year to come, but there's gonna be more bumps in the road, I'm sure. More education, more saying the same thing over and over again. But it's kind of the nature of it.

Elyse:

Speaking of the year to come, let's time travel a little bit. It is January 2026. It's a year in the future. What do you imagine or hope the state of the design system is?

ToniAnn Drenckhahn:

Ooh, that's a really good question. So I really hope that the noise is removed honestly. That's my biggest wish for the design system and what we can enable. Right now we have this space that we're playing in where half of the code coming from here, half of the design is going from this file, there's a lot of mental energy people are spending right now, in this interim state of shipping this design system into the product, that I really want to be able to remove from them. We talk about a single source of truth, but that's not going to be realized until we get all of this noise out of the way. So that's where I'm really hoping is that we have a design system, it's running, we've got BAU, we're good with development. We can just ping back and forth on teams, get things done quickly. Now we're talking about, what is the little fun motion we're introducing? What are the really cool things we can start to do with the design system? I think the baseline is pretty cool if you look at it from you know, start to finish what we're delivering, but I know our teams really want to get to that point where we can start to focus more on some nuanced craft elements of the design system. So I really hope in a year that that's where we're at because we don't have this integration mess going on behind the scenes. Um, and we have dark mode. Of course.

Elyse:

I hope this for you as well. That's a really, really good vision. All right, last question is the question I'm gonna ask everybody on this show. Tell us a ToniAnn Spicy Take on design systems.

ToniAnn Drenckhahn:

I've been thinking about this all day. Honestly, it's that what's in a system doesn't matter. It really doesn't. I've worked on some really amazing design systems, some really technically cool design systems that are doing really unique things. I've worked on very basic design systems. And at the end of the day, none of them would be successful without figuring out how it works for everybody, without figuring out what your operations model is, and who you're talking to. And if the people who are consuming your system actually trust you at the end of the day. We can fix components. It's a lot harder to fix relationships that are broken once they've gone down that path. And I've been on teams that are dealing with that. That is a place where your system can easily fail, and honestly just leave consumers with a taste that they never want to come back to it. But if your component is broken, you can fix it. And you can go to them and show that tangibly to them, and they go, oh, that's better, I'll use it. But ultimately, what's in the system doesn't matter, but who you are as a systems team and how you show up to support your teams, that's really the most important part.

Elyse:

Yes, we love it. That's what it's all about.

ToniAnn Drenckhahn:

Yeah,

Elyse:

ToniAnn, thank you so much. This was a real pleasure. We had so many good things to talk about. I really appreciate you coming on the show and sharing what y'all are doing at BetMGM.

ToniAnn Drenckhahn:

Thank you.

Elyse:

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!