Alex Wilson and Jon Reidy at T. Rowe Price
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 @theDSPod. We'd love to hear from you.
Chris Strahl: Hey everyone. Welcome to the Design Systems podcast. I'm your host, Chris Strahl. Today I'm here with Alex Wilson and Jon Reidy. Alex is the engineering lead for the design system at t Rowe Price, and John is the director for the design system at T Rowe Price. And I believe this thing is called Beacon. Is that right?
Alex Wilson: That's right.
Chris Strahl: Awesome. Well, welcome to the program. Y'all. Excited to have you here.
Jon Reidy: Thanks for having us.
Chris Strahl: So I'd love to just do a little bit of background. You all have an interesting system that we're going to talk about a lot of the mechanics of today, but also get into some of the philosophy behind design systems. And so I think this starts off with understanding some of the things that you've held close to you through the process of the creation of your system.
Jon Reidy: I mean, me, I came in a little bit later. So I came in about a year and a half ago when the system was already stood up, already had a lot of community behind it. The name itself was chosen by the community. I think a lot of things really impressed me very much community led. I know Alex could talk about how it started outside of a funded design system, and it grew into that. Our business is called T Rowe Price, but people often call it T Rowe Nice. And I think coming into a business where the community is just really warm and welcoming, and I think the levels of adoption we're seeing is really big for us straight off the bat and it's, it's really exciting. It really helps us. But something we'd love to talk more about.
Alex Wilson: And so when Beacon officially started, or even before Beacon, it was called a project called Inter Source. And Inter Source was just exactly that. It was sourced development, not even bringing in design at that point to build a UI kit. That UI kit we knew that we needed across the board because we were inconsistently building these UI kits and the developers and even engineering management above that, they recognized that issue. And so we started getting together thinking about what we actually wanted out of a design system, which brought in this large amount of adoption and also kind of unified and community-driven ownership of such a system. So that way when it came time to actually talk about, well, we actually need to include design as a part of this. So it goes beyond UI kit into a design system. We already had the technical buy-in and designers saw the same need on the design side.
It wasn't a hard sell across the board. Then we actually had to get management on board. We ended up testing out this UI kit and some of the design assets that the designers were creating and showing how that could be used across different teams. Once we had that, we started putting in patterns. And when we started getting to the pattern level, you asked question of what did you want in your control? It was that level of standards, just making sure that once we knew that we had the system that we wanted to create, what standards did we want to put in place to make sure that system was successful? I think brings us into where we are now.
Chris Strahl: So tell me about that inclusion of designers that also happened where you went from something that was largely represented as an engineering project to something that was innately much more cross discipline.
Alex Wilson: So after we had begun development on that UI kit, we reached out to our design partners and said, Hey, do you have something similar? We'd love to partner on this. And they started doing a ton of research into all of the components that we had across all of our domains to try to get a better understanding of what needed to be designed, what needed to be built, what needed to be brought into the system, what needs we had. But at that point, they didn't have the designs to hand off to us. So it was a little bit split for a period of time until we actually came together as one beacon design system. At the point that we came together, that was when the design system actually started, but it started with a conversation and they had budget to do the research and come up with these initial designs and we were able to pull it together after that.
Chris Strahl: Interesting. So your idea of moving to patterns, what was the goal for all of this fundamentally? Was this about an efficiency side of things? Was this about more consistency across teams? Was it any number of these things? What was really the driving force behind this?
Alex Wilson: Well, early on it was efficiency and consistency, but we've seen a lot more benefits than that. And John, I think maybe from your lens, would you want to share on that?
Jon Reidy: Yeah, I'd say, I mean I kind came in a little bit later, but I know all of that hard work around the strategic buy-in was done. I know a lot of the focus to tell that kind of simple message around efficiency I think is a really big win. That's the one that will land in order to find the funding in to get the kind of agreements to go in place. And I think efficiency is always a big winner, efficiency, consistency, and then obviously you start talking about quality and the consistency around the experience, et cetera. But I think it really, really was that. I mean, I remember seeing lots of amazing kind of decks around moving from 50 buttons to one button and having those kinds of conversations really resonated with leadership. I heard that said over and over and again, and I think these simple messages, they just land a lot more clearly, I think.
Chris Strahl: So there's a lot of that that's relatively typical in the way that design systems get started. And then I think atypical part of this is the way that you have thought about this long term is a lot more focused on the value stream that you can continually provide this company. And that value takes a lot of different forms, obviously the first word of which is that efficiency, consistency side of things. But there's lots of other things that you've built into that. And I'm curious, what do you do to measure that and how does the organization think about that value relative to the creation of products across your ecosystem?
Jon Reidy: Yeah, I mean, like I mentioned, I know efficiency and consistency is always the topics that are rolled out when it comes to design system, and I think that opens the door that gets the funding and it keeps the funding in place. But I think it's just the level of quality you can bring as a focus design system team, because you're going to the nth degree on every component. You don't have the same kind of delivery deadlines. You can focus on much more enterprise level solutions. You have a lot more data. You can do a lot more testing, you can do a lot more collaboration when you're doing something from a design system point of view. You can do it with a much larger greater level of insight, meaning that the quality, the accessibility, the other aspects of it can be in just much more improved than your average design project team that have got three months to get a project out the door.
Chris Strahl: And how do you show that? Do you show that through a set of metrics or measurements? What does that showcasing of that value look like? And I assume that that probably takes a couple of different forms. I assume there's probably some that are qualitative, some that are quantitative, but I'm really curious how you continually prove that value.
Jon Reidy: I guess you've got the quality of the, almost as we would say associates or colleague quality, the kind of internal quality of our design tools, of our code, of our framework, our process, and just making sure that our community enjoy using the assets that we create. And then you've got the results that you get from the client. So that's kind of improved client testing, that's the qualitative and quantitative AB testing, and we're constantly measuring improvements that we're making and we're at the stage and our design system. We're still really in the teenage years of our design system where we're in many regards having the first version of everything kind of rolling out, but we're already in the second version in a lot of our major components. We're moving into that like our primary navigation, our master at the top, we've just moved into our second major version of that. So we've taken a lot of our learnings and findings for the last six months of the previous version, and we are improving on that. So we found that as a really, really important milestone. Moving from that first version into that second version shows how you can really assess and optimize what you've created.
Chris Strahl: So when you think about that assessment and that proof of that value, is that because you benchmarked a bunch of things and gathered a bunch of data upfront and are now presenting new data that shows a delta in that change? Or is that something that's a lot more organic where people have a feeling that you're living that value of T Rowe Nice.
Jon Reidy: I would say, for instance, if we consider the masthead as one of our first major, one of our largest components for everyone, and moving into our second version, we were able to look at all of the stats over the last six months over the usage in quite a few different areas. And we were able to then benchmark, well, we haven't got that yet because we haven't gone live with the second version, but we'll be able to benchmark all of those results against the new version, which I think will tell us a lot. And I think it's just important to consider it as iterative. We're going to release this version, but we built it in a flexible way that allow us to make changes and constantly iterate and improve each one of our products as we see them as kind of our masted is one of our major products. We're going to just keep working on the masted work stream and improving it as we go. And I think that's from a cultural point of view, I think that's important because it means that it takes away a lot of the kind of perfectionism stuff that really holds back delivery of these things. I think it lets you move a lot faster.
Alex Wilson: And on top of that, I think John's mentioned really something really interesting there is that we think about, of course, our end users, the people that will be visiting our sites and interacting with these components. But at the same time, we need to think about our internal users, and those are people like our developers, our AB testers, our authors, our designers, our application product designers, all across the board making sure that our experiences that we're building are really solid for them as well. The APIs that are built for our components, is that the right API for that component? We do a ton of research before we dive into each component. And then after that, once we think that we have the right architecture, we send it off, let people view it, and then we also ask for feedback. So even after we deploy that thing, then we ask people to create issues within our GitLab, create any issue. It could be a feature request, it could be a bug they're seeing. It could be an API inconsistency. We want to make sure that it's the best experience possible. And the only way that we can do that is getting feedback from our developer users. So there are different aspects to this in trying to understand what works best over time. And those are the two different angles. One's focusing on the end user, other is focusing on our internal users.
Chris Strahl: Gotcha. How do you unify that? Because
Alex Wilson: That seems
Chris Strahl: Like a pretty complex system to build. You talked earlier a little bit about one team has react, another team has Angular. I imagine there's one team that has one mandate, another team that has a different mandate. There's one team that really caress about accessibility and has done a great job, and there's another team that has been kind of like an afterthought. And so in that harmonization, how do you build that and how do you get buy-in for that? Because that means that there's a lot of change from a lot of people.
Jon Reidy: I would say, I mean, one thing that really impressed me apart from how nice everyone is at Tiro nice, was just how clear the mandate was coming down from leadership, which is something you don't get in a lot of places. We were joking earlier and I think in previous call where our CEO knows the name of our design system, that clear mandate all the way down of there's one system, everybody's going to use it. Obviously we're the guys that are going to work with the teams to make sure that it's right for them. But that mandate was really clear. This is your system, everyone's going to use it. And I think from an accessibility point of view, same thing happened really over the last 12 months. We've had a huge journey from an accessibility point of view, but the mandate was always clear that things need to become accessible. We need to move into that direction, and there's absolutely no discussion around it, which is really nice because I think that gray area that's created sometimes with multiple systems and different leaderships and having different priorities, et cetera, I think that can be really hard to deal with and you spend a lot of time dealing with it. And I think we're a, I don't know, medium sized kind of corporate. We've got about 7,000 people worldwide, but it's always been clear. I think the mandate and it's really been helpful to us.
Alex Wilson: And on the topic of different frameworks and technologies, I mean, we of course want to consolidate and making sure that we're not using everything and we have a little bit of focus here, but we're going to see things transition in and out over time, different frameworks, different technologies, different libraries. And so we have teams using Angular, we have teams using React, and we've got legacy systems that we need to support in order to support those things. We've chosen to really drive forward our system using web standards, like a web standards first approach where we first look at what specs are available. We don't look at third party libraries first, and we only look for third party libraries when we know that we have a large need that would make sense for us to use someone else's code for. And by doing that, we know that we can support our angular developers, our React developers, our developers that have been working in JSPs, trying to update a legacy system. We still want that consistency, but we may not have the technical unification to make that happen with a single framework. And I think that's probably something that a lot of companies face, even if it's not multiple frameworks, maybe you've transitioned off of one onto another over time and you're working now with two. In those cases, you still need to support both. And so that's just another layer to this that needs to be considered.
Jon Reidy: And I think it's worth mentioning Alex, that I think it was probably around this time last year that we were talking about the transition to web components, and I think it was a really brave move to make. Obviously I was quite new into the business, but you having to have that conversation where you're just standing up, you're just releasing your first set of components, and then you're realizing or with any kind of thing in the design system, it's such a heavy innovation space, you've got to be really brave to make a big call early on. And that was really, it was nothing to do with me, but that call I think was really huge because it meant that we're in the right position now. And I think if we hadn't made that call, if we were still delivering out to multiple technologies, then we'd be really suffering now. So I think that's probably really hard for people when starting any design system, people don't expect you to keep changing and iterating as you're standing up. It's really an innovation space. So bringing the stakeholders along with all of the change is hard. We've done our best, and I think we're still here so people seem happy with what we're doing, but it's a hard thing to communicate as fast as you are changing as well
Chris Strahl: See this broad organizational change that all has to happen. You also have a bunch of technology change that's happening and it's like change, change kind of all over the place. And I think that consistent is the commitment of t Rowe, the business and your leadership to making sure that this change is something that the company prioritized. And I think that's a really powerful thing when you talk about your CEO knowing the name of the design system, that's awesome. I would say that not very many big enterprise companies have that. And I think that that represents something that is really different where you mentioned reverse buy-in, right? You have a bunch of different leadership folks that really want this and want to see the benefits of it and believe in the strategic value of this as something that you all are doing as a company. And that's then translated to a lot more buy-in as a whole for a bunch of fairly risky technology choices.
Alex Wilson: So John mentioned it briefly earlier. We actually did build for a period of time for Angular React as well as a content management system, Adobe Experience Manager. We were about six months into formal Beacon coming out of Intersource when we made that call to start looking at web components. But at that point, we actually brought it up to different groups around the organization, said, what do you think about this decision we brought up to engineering managers? What do you think about this decision? And make sure that we had the buy-in at that level. Because once we then rolled it out and made the announcement, we had all of the leads that were working with their teams bought into the solution and understood the fact that yes, this is not a React component working in your React app, this is going to be a web component and that'll be okay, but it is the right decision for the design system. And while not every design system is using web components today, I do see it as a technology that will expedite design systems greatly in the future. And so I think that we're coming in early on this, but I think it was the right call and I think that our management would agree with that at this point.
Chris Strahl: Talk to me then about tooling, because your tools changed over at the same time also where you had one set of tooling and then as a rather self-serving question, you all now use knapsack. Talk to me about that decision to go from a set of tools that you were working with fairly effectively, but then to consolidate under a single platform.
Alex Wilson: I can start with the storybook conversation. We were using Storybook for a long while. We still use storybook at the firm as a whole, and I think it's an extremely useful tool, but what we found were just gaps in the ability to have the editing capability, the design capability to bring that in, have it all in one platform. And John did a lot of research in that space as well as a number of other people on our team. So John, is there something you want to chime in on there?
Jon Reidy: Yeah, I mean coming into T Row, first of all, I was really impressed with the use of Figma because it was used by everybody and it was synonymous at that point with design and development, et cetera, which is brilliant. But one of the issues is that we had all of our documentation and Figma as well, and straightaway I was like, that's not working. It's hard to keep your documentation and Figma, it's hard, especially for non-designers to use Figma. You put our big Figma board in front of a PO and they open it up on their Lenovo and it basically shuts the machine data to go and grab lunch, I think to come back before all loads. But that in itself is just inaccessible to large areas. So it's really the documentation thing. So I've had previous experience of building my own design system platforms and there's pros and cons. I think one of the issues is that you basically need a platform team to go alongside it. So not only do you have a design system team, you now have a platform team. And it's just something that we didn't need that stress. We're a design system team trying to roll out a design system. We don't need that in our lives. Basically. I think that this is about leaving the platform to the experts and allowing us to focus on what we enjoy most and what we get the most value out of. I think
Alex Wilson: I a hundred percent agree, and one of the thing on that is that if we were to continue down the route that we were on when we were using storybook as our primary source, we would have to manage all of that documentation as code and have no other ability for the designers to get in there. So they'd be essentially handing everything off to us and then we'd have to manage it, which would add on to our workload, which is not necessary.
Chris Strahl: I think this speaks to sort of a deeper question of when especially enterprise teams are looking at a design systems capability. You have a couple of different roads you can go down. There's the idea of I'm going to build this myself. There's a bunch of talented engineers, a bunch of people that really understand how user experience works. It's totally conceivable that an organization could build everything that they need more or less to stand up a design system. It's a lot of work. It's like you said, John, a platform team, a bunch of investment in that. A different kind of investment you can make is building a couple of different tools and figuring out how to glue them together. And then the third side of it is you can look at an all-in-one SaaS vendor situation, which is what napsa is all about. And look at that as like, all right, here's my platform. It's taken care of for me over here. Now my focus is on the content that's in the system. And in that sort of spectrum in you all kind came down on that platform side largely because what I heard was you said that the important part was to have the Headspace and the focus to be able to do the work on the system. Would you feel like that's a fair representation of that decision process for you? And were there any moments where you were like, maybe we should build this.
Alex Wilson: We got to weigh all the options. I mean, we always weigh the options, but if you think about what we need to do as a design system team that is not a part of it is managing the code behind the documentation system. That could be something else. And that doesn't impact
Chris Strahl: Our ability to deliver on the design system. So it's something that could be easily split apart and managed separately. So I think that's part of where that decision comes from. And then you can say, well then do we want a separate team to build and manage that thing longer term? What's the maintenance cost of all that? And that's taken into account. And then there's of course everything that you need to work with on the design side and making sure that there's easy ways to edit and update content and that everything can go in the same place and there's no bugs. It's just a lot that we would have to handle on our own. So I think that is an accurate representation.
Jon Reidy: Yeah, I can totally see why teams come into it. We're a design system team. We're building all the components to build the best website in the world. Why wouldn't we just build our own website and have everything on there and we build it with the design system with great exemplar of what we can do, et cetera. But that's great in theory, but I think it's a whole other full-time job I think running the platform.
Chris Strahl: So the really interesting part about all of this to me is you guys don't just think about this system as a set of tools. You think about this as actually a strategic almost line of business for the company where you represent strategic value to the organization and how you build product. And the way you do that is through your product, which is the content in that design system, but ultimately it's way beyond that because there's a change management effort, there's a unification of standards, there's all these things that you haven't even really had a Trojan horse them. They've been sort of like these overt ways of saying this is why this internal capability really matters to t Rowe. It's not just the result of a bunch of components and patterns and stuff like that. It's all the things that are around that as well.
Jon Reidy: Yeah, it's the cultural aspect of getting people to work together that have never worked together before. Different areas that come together to discuss their issues, come together with solutions. I think often the best way to look at a design system team is a conduit sometimes from a conduit of all of an amalgamation of your skills within your business, whether that's development skills, design skills, et cetera. Because as soon as we start thinking that we know best, we start putting ourselves on a pedestal and separating ourselves from the community, which is exactly where we don't want to be. Really focusing on the process to collaborate is such a large scale, I think has been a big one for us. It means that we build together, and then when things are done, then we have the buy-in and they get adopted quickly. Teams are not afraid to tell us overtly when we've done something wrong and give us direct feedback and not just talk about our guys about the water cooler. It's direct to us, and that's what we want to hear. We want to be part of those conversations, and I think they're being part of their lives, part of their projects, really understanding what they need, what their needs are on a daily basis. It means that we are in that fight with them. It brings us closer to the clients and it creates a good culture we want to be part of.
Alex Wilson: Yeah, we try to provide transparency into what we're building. We've recently launched our inventory so that way everyone can see where we are with the different features for each of our components across our different asset deliveries. And then also we do massive showcases. So we bring people in from around the community. We have community speakers that say like, oh, we used Beacon, the design system for X, Y, Z. This is how it looks, this is how it performed. And they talk about that with the rest of the community to kind of showcase how their usage has impacted their business line. And then we also talk about things like the new assets that we're going to be introducing, like the different ways of working that we have in place. I know that tailwind is a hot topic. Should we introduce utility classes, those types of things. Should those utility classes be driven by design tokens, the things that we're planning for and want feedback on, that's our place to showcase that as well as our existing work. And that brings us really close to the community where we're not hiding anything. This is all out there. Let's work on it together.
Chris Strahl: It's fascinating when you talk about this, it almost sounds like you started your own little business inside of T Rowe where you have the investment that's happening from your leadership and your executives. You have a bunch of users that you're constantly getting feedback from, and then you're publishing things like a roadmap that help them see where this is all headed, and that's all iterating towards product market fit and some grand expansion of this. Would that be a fair characterization?
Jon Reidy: Yeah. I mean, we boil it down to a three step process. Really. Step one is understanding the needs of our community. Step two is coverage of those needs, and step three is the adoption of that coverage. So just really trying to boil that down. Our needs keep changing. We'll keep evolving. The coefficient is the more that we all create for the community, the more that the needs are going to grow because they're going to evolve and they're going to be standing on the shoulders of the work that other teams have done, et cetera. That's just going to exponentially speed up innovation. But it's understanding those needs is key. It's basically understanding our clients, our customers, what do they need, and coverage is creating products that fulfill the needs of the customers. And then number three, it's just making sure we sell those products so there's no point.
We don't have a business anymore. I remember one of my colleagues was saying, it's like if you are running a phone business, you've got your r and d you want create your new handsets, but then you've got to sell those handsets. So if you create all of these different products and no one's buying them, you don't just keep doing RD and keep creating products. Everyone's got to go out and become salespeople that week because that's how the balance works. Otherwise, next year leadership are going to turn around and say, thanks a lot. We're going to go in another direction. Every design system team, you've got to be aware that you're in a really amazing space to be able to be given this space to create a system and innovate like this. You've really got to earn it on a daily basis, I think. And I think being close to the metrics like this and really being close to the coalface keeps us aware of exactly where we are and exactly how much value we're delivering.
Chris Strahl: I love that idea of you have to earn it and by earning it, I think that you've again worked on this culture that really lives that, but when you have new people, tell me about how you bring them into the fold. If you're somebody that's just starting off in design or engineering and you look at Beacon and you look at this thing, I imagine that can be pretty daunting, especially if you've never worked in that sort of environment before. So how do you get people on board with that?
Alex Wilson: Yeah. Well, first you definitely have to have a lot of documentation, but documentation only goes so far, right? So whenever we have a new team or new individual that wants to onboard, we definitely work heavily with that team during an integration period, and then we try to get them set up running. But then at certain point, they may have needs that go beyond what we concurrently support with our design system. And during those periods, we want for them to experiment, to explore, to come up with new ideas, especially when we're talking about the design side and coming up with new components that we could put on the page. Now, not every component that is built is a part of that, is something that we'll want to use long-term, but there could definitely be some great ideas that we could take into the design system long-term.
In order to do that, we introduced the incubator pattern where designers have a place where they can submit ideas, submit specs, so that way the internal core team can review. On the technical side, we have an incubator repo where we're going to allow people to contribute components that are signed off from the design incubator into the development incubator, and then other teams can use those components. Over time. We'll get learnings about how these components work, how they're working on our live site, how they work with the end user, is that leading to more transactions, something like that. And then from there, we could look to pull that into our system, maybe beef up the standards a little bit, make sure that's aligned with our component API. But at least at that point, we're not blocking teams, and that's critical because if the second that we're blocking teams, beacon becomes the problem and we don't want to be the problem here. We want to be the solution.
Chris Strahl: That's awesome. So this incubator is this place where you can basically have room for experiments
Alex Wilson: In a safe way that you're still getting reviews, they're lighter reviews. We want to make sure the purpose for the component is being presented, but beyond that, we do want to encourage this type of experimentation.
Jon Reidy: I think it's the message it brings to the community as well from a cultural point of view, that our system is there to be challenged, it's there to be improved, it's there to be contributed to by everyone in our community. So every team member has the chance to contribute and change what we're doing and change the direction of what we're doing by this. One of the fears that I had starting out and things that we discussed was if you get into a mature situation with a design system, I think there's going to be some of the community that feel that their job now is not to create their job, is to assemble the design system. They might feel discouraged to create new innovations. They may want to stop feeling like they have to sit back, they have to wait for something. You do get certain product owners, they're looking at their tough roadmaps and their budgets for the year, and they're saying, do you know what?
We'll just wait. We're going to wait for the design system to get round to us, and then we're going to be able to create something. By having a clear supported pathway, it means that teams don't have to slow down. They can work with us, they can work with our design system, but if they have to go live, they have to go live in three months time and they have to create these new things. You'll do it with our blessing and our support, and we'll do everything you can because that is a core workflow for us to support that.
Chris Strahl: I love that. I think that there's a lot of challenges in trying to figure out how to support the snowflakes, those variations that don't quite fit within the system, and we personally have taken a pretty deep philosophy of the system should be the way you want to work, and the moment that it isn't, you should be able to break out of that system very easily and do whatever it is you need to do to get your job done. Now, ultimately, hopefully that's tracked, and that's something that has that, again, sort of safe area for experimentation, so you can understand if there is really a shortcoming here that you need to address as a part of the core system itself, or if it really is just something that's a truly unique moment in time sort of thing. But that ability to create that area for experimentation, for play, for trying stuff out, that's like you said, I think as much of a cultural icon as it is a real true technical bridge to different solutions,
Jon Reidy: You don't quite know what Snowflake is until after the fact. Really, you dunno. We had conversations like, oh, we only want the good things in this incubator. Okay, is this incubator worthy, et cetera. But you've kind of got to think of it from the other angle as well, from a kind of governance point of view as well, because the incubator isn't just a collection of really nice innovations that can be shared. It's also a great tool for quality control as well, because it's a pathway to bring all new things through, and you go through those gateways, you get that support that you need. There's different team members in different corners of the world really, that need extra levels of support. So it's a process that allows that to come through in a formalized way. I just feel so wrong that work would be done and just thrown away and done somewhere and just thrown away and not shared, because who knows what ideas and innovations could come out of that work through better transparency management.
Chris Strahl: Well, John, Alex, thank you so much for being on the show, sharing your thoughts, your time. I really appreciate your perspective and thanks for some of those great sound bites. That was amazing chat, so look forward to having you back again sometime. Thank you so much.
Jon Reidy: Yeah, it's been a real pleasure, Chris. It's great to actually speak to you because we've been listening to you for so long.
Chris Strahl: Awesome. Well, I'm glad you were able to come on the show, everyone. This has been an episode of the Design Systems Podcast. Again, I'm your host, Chris Strahl. Have a great day, everyone. That's all for today. 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 @theDSPod. 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 Knpsack.cloud. Have a great day.
