But "design systems as infrastructure" is boring, with Sam Anderson — #16

WEBVTT
1
00:00:00.160 --> 00:00:11.520
I think the untapped value of systems is in the patterns. Look at your platform peers, look at your platform teams. What problems are they trying to solve through centralized capabilities in the company?
2
00:00:11.580 --> 00:00:18.100
And th- those are where your patterns work should go. They may or may not think they're supposed to be producing UI.
3
00:00:18.180 --> 00:00:35.060
[laughs] They may think that their work is just back-end infrastructure or APIs, but there's a conversation to be had to say, "Hey, what if we delivered some kind of UI also as part of this platform initiative that we have to, say, take a request from a user and send it to an LLM and sanitize it on the way back out?"
4
00:00:35.140 --> 00:00:45.660
This is On Theme: Design Systems In Depth, and I'm Elise Holiday. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact.
5
00:00:45.720 --> 00:00:53.600
Design systems is due for a major reinvention moment, and I wanna share what's working from design system practitioners out there forging the way.
6
00:00:54.620 --> 00:01:06.780
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.
7
00:01:07.580 --> 00:01:13.350
Into Design Systems is back with their annual virtual conference May 28 through 30, 2025.
8
00:01:14.000 --> 00:01:24.400
Visit intodesignsystems.com/ontheme to get your ticket to three days of practical hands-on sessions showing the what, why, and how of design systems.
9
00:01:25.240 --> 00:01:31.240
This year, the conference is focused on developer handoff, accessibility, multi-brand theming, and governance.
10
00:01:31.880 --> 00:01:39.360
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.
11
00:01:39.780 --> 00:01:53.340
Get your ticket at intodesignsystems.com/ontheme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the show, I am excited to have Sam Anderson.
12
00:01:53.480 --> 00:02:05.800
He is the director of the Intuit Design System, leading design into its AI-accelerated future and enhancing customer and designer experiences. He previously led design systems at USAA and Cisco Webex.
13
00:02:06.340 --> 00:02:12.520
He specializes in interaction design and information architecture and holds a Master of Human Factors from Bentley University.
14
00:02:13.100 --> 00:02:22.280
Based in San Antonio, he loves live theater and concerts and cheering on his kids in gymnastics. Sam, thank you so much for coming on the podcast. Thanks for having me. This is gonna be, this is gonna be fun.
15
00:02:23.220 --> 00:02:35.480
Yeah, I think so. I'm so excited to have more guests who are in leadership, and we can talk a little bit about some things that maybe some design system practitioners don't often get to see, like today's topic.
16
00:02:35.560 --> 00:02:38.329
We're gonna really dive into design systems as infrastructure.
17
00:02:38.860 --> 00:02:51.100
You recently published a blog post about this, and I am all aboard the design system as infrastructure train, so I'm really excited to share that and hear from a leadership perspective why that is a valuable way to talk about systems.
18
00:02:51.760 --> 00:03:00.160
But backing up for a second, you've been in the industry a long time. You've been in design systems a long time. What was your path to this work? Yeah.
19
00:03:00.200 --> 00:03:06.820
I've always been curious about the realization of design or how design manifests itself in code.
20
00:03:06.900 --> 00:03:21.240
I got my start in the industry in the early days when we were all trying to figure out how to make the web beautiful, so the early days of CSS and carving up little images to make things in tables and- This site is best viewed in 800 by 600 in Internet Explorer.
21
00:03:21.700 --> 00:03:32.940
Exactly. [laughs] We're all scarred by Internet Explorer 6 still. Really. But that's what really got me curious about if I could scale beautiful things through large organizations, how would I do that?
22
00:03:33.540 --> 00:03:37.820
And it led me to want to establish our first coded design system for Webex.
23
00:03:37.920 --> 00:03:56.360
I had been at Cisco a long time and had tried to design interfaces with very few design resources against many engineers for a long time, and had an opportunity within Webex to really bring a design system into being, like a zero to one effort, and move beyond just the brand book or the style guide into a fully encoded design system.
24
00:03:56.640 --> 00:04:03.160
So that was my first rodeo. And then from Cisco, I went to USAA, which had a really mature, great design system, a great chief design office.
25
00:04:03.780 --> 00:04:15.180
And my role was to take that 1.0 design system and transform it into a 2.0 design system, essentially to re-architect it for both web and mobile. So that was a really big re-architecture, a really big job.
26
00:04:15.700 --> 00:04:23.000
From there, I'm thinking, like, "What's my next design system problem to solve?" And that's when Intuit came along.
27
00:04:23.180 --> 00:04:33.700
At Intuit, the problem was very interesting, where they have these very distinct brands that all stand on their own and all have their own brand equity, and yet they were bringing these brands together under the Intuit umbrella.
28
00:04:34.140 --> 00:04:42.640
So we're talking about Credit Karma and Mailchimp in those acquisitions, and historically having TurboTax and, and QuickBooks, all billion-dollar brands on their own.
29
00:04:42.680 --> 00:04:59.380
And I'm thinking, "Okay, how do you take these billion-dollar brands and create a design system that lets them express themselves and lets these brands stand on their own, but also creates some cohesion between the brands that represents Intuit and represents the umbrella brand that we're trying to contribute that brand equity to?"
30
00:04:59.820 --> 00:05:07.840
And so that seemed like a really interesting design systems challenge to step into. And as I did that, about a year later, ChatGPT came out.
31
00:05:08.360 --> 00:05:13.460
Then we had this sort of big gen AI moment that really has turned everything on its ear since then.
32
00:05:13.580 --> 00:05:22.960
And so we've been adapting and evolving, still solving that really important design systems challenge, but now doing it within this AI transformation that we're currently in. Yeah.
33
00:05:23.060 --> 00:05:26.680
We'll definitely talk more about AI in later parts of this episode.
34
00:05:26.870 --> 00:05:42.240
That history, your experience in design systems, has taken you from how do we even share designs and components, which was a problem in the early days, to, oh, how do we do cross-platform, right?
35
00:05:42.320 --> 00:05:52.420
Like, how do we build for iOS and Android? How do we build for these very different frameworks and languages, all the way to how do we build for multi-brand?
36
00:05:52.880 --> 00:06:07.120
And that is such a journey of design systems, the industry, from just solving our own technical problems, solving our own design problems, to bringing this to a very critical part of the business.
37
00:06:07.240 --> 00:06:18.016
And in thatjourney, we've gone from design systems being style guides and sticker sheets, and again, like design and engineering tools to design as a product.
38
00:06:18.556 --> 00:06:30.896
There are many, many years where we were speaking about design systems as a product to now this design systems as infrastructure. And I really wanna dive into this concept of design systems as infrastructure because
39
00:06:32.116 --> 00:06:41.716
this is relatively new, but I feel like it took off in the design system space so quickly. Like, people immediately grasped onto this concept.
40
00:06:41.776 --> 00:06:53.716
I think it immediately worked in some way that design systems as products didn't really work. So when did you first hear or start talking about this idea of design systems as infrastructure?
41
00:06:55.176 --> 00:07:02.956
Yeah, this emerged as a thought for me as I was sitting with many different design leaders in different contexts, so different leadership conferences and things.
42
00:07:02.976 --> 00:07:07.346
And we were all going through this AI transformation moment where there was a lot of fear, uncertainty, and doubt in the air.
43
00:07:07.816 --> 00:07:17.036
You know, tech layoffs had started, and people were wondering what the future was going to look like. And I felt differently than a lot of people were articulating at the time.
44
00:07:17.656 --> 00:07:26.036
I felt like these new tools, these new capabilities that AI would bring could accelerate design in general and could accelerate design systems.
45
00:07:26.816 --> 00:07:36.615
And so I was coming back to why I felt differently, like what is driving me to think differently about this? And I thought about how we've been building our team here at Intuit.
46
00:07:37.276 --> 00:07:44.756
I work within the platform organization, and so Intuit is transforming itself to be a platform company rather than a product company, right?
47
00:07:44.876 --> 00:07:53.956
Of course, our products are very important, but they all need to share capabilities that are fundamental, like data exchange between products. And so those are all built at the platform level.
48
00:07:53.976 --> 00:08:00.196
And that, that's infrastructure. So my peers in the organization are people who run the infrastructure that run our products, that run the company.
49
00:08:00.616 --> 00:08:03.816
Our design system is looked at as part of the infrastructure of the company.
50
00:08:04.556 --> 00:08:16.076
And so as I kept m- thinking about it in the framework of, particularly Nathan Curtis, who made very famous the idea that we should treat design systems a- as a product, and we should. Our product should have releases.
51
00:08:16.176 --> 00:08:21.376
We should care about it. We should care about the customer experience with the design system. So very much still aligned to that concept.
52
00:08:21.496 --> 00:08:33.136
I think they should be thought about in a company context as infrastructure, as essential building blocks of how we deliver product here, how we create product here. So I, I feel optimistic about that.
53
00:08:33.276 --> 00:08:44.256
I, I think that as we continue to articulate design systems as part of the critical infrastructure of the company, they will continue to have mind share or continue to have the right resourcing within tech. Yeah.
54
00:08:44.396 --> 00:08:54.196
I feel like the biggest challenge to design systems are infrastructure that I have heard that I think is very legitimate is infrastructure is boring.
55
00:08:54.226 --> 00:08:59.696
And I fully agree about design systems as product in the sense that, yeah, we need customer support and service.
56
00:08:59.776 --> 00:09:25.496
There's a internal customer-facing element to design systems that maybe database migrations don't necessarily need to have, or some of your other engineering-focused infrastructure can be managed by a team in a way that a design system is much more an interface between parts of your company, and especially when you have multiple brands and you're a very large company, even between brands, like between arms or verticals in your company.
57
00:09:26.616 --> 00:09:38.916
But it's true, infrastructure is kind of boring. It's not very shiny and interesting. We don't really think about infrastructure in the same bucket as branding and logos and marketing.
58
00:09:39.036 --> 00:09:51.316
We talk about design systems as a way to ship the brand, but that's not how we think about infrastructure. So how do you... Well, I guess two questions.
59
00:09:52.076 --> 00:09:58.676
How do you get design systems in the platform conversations in that part of the org, and how do you talk about it to leadership in a way that's compelling?
60
00:09:59.816 --> 00:10:08.796
First, I'll say that as designers, we might think about infrastructure as boring. We might think about databases and servers and networking as boring. But we're very empathetic people as designers.
61
00:10:08.976 --> 00:10:19.776
If you spend time and listen to the people who are driving your infrastructure, who are caring for your infrastructure, who are building out the infrastructure to scale, I think you'll find a lot of empathy with them.
62
00:10:20.116 --> 00:10:27.976
They're very excited about their work. It's important work, and we take a lot of pride at Intuit in the uptime that we, we have for, particularly for tax.
63
00:10:28.036 --> 00:10:33.996
If you think about the number of people that need to file their taxes and that all put it off until the very last couple of days.
64
00:10:34.016 --> 00:10:49.196
[laughs] We have extensive infrastructure needs to make sure that everybody who signs in at 11:00 PM at night on April 14th or April 15th, they get a great experience, and they get a performant experience, and they get an experience that they, that they'll rave about afterwards and say, "Yeah, TurboTax was there for me."
65
00:10:49.716 --> 00:10:53.336
So we put a lot of energy and a lot of effort and a lot of care into infrastructure.
66
00:10:53.356 --> 00:11:00.176
So maybe as designers, we need to take a step back, first of all, and say, "Maybe this isn't as boring as we thought it was in the past. Maybe it's actually mission critical."
67
00:11:00.576 --> 00:11:16.476
And so then we take that, that label, like this is mission critical, and paste it onto your design system and say, not only is the networking and the storage and the compute mission critical, but the actual frame of the browser is mission critical.
68
00:11:16.956 --> 00:11:21.256
And we're measuring everything these days, right? We're measuring time until first customer interaction.
69
00:11:21.756 --> 00:11:27.446
And you know, if your load times are over two seconds or over five seconds or over 10 seconds, right, like customers will...
70
00:11:27.656 --> 00:11:34.616
Your NPS scores are going to drop, and people are gonna move to more performant tools and more performant platforms. That's just table stakes and expectations.
71
00:11:34.676 --> 00:11:50.896
As a design system organization, we have a unique ability to drive that thinking, to be in the room, to be at the table for those discussions, particularly as you think about the performance impact of people who, or developers who develop their own components or add their own components to the mix.
72
00:11:51.096 --> 00:11:57.616
We have a component for XYZ. We're just gonna throw in another package. We're just gonna throw in another import statement, but then you get package bloat.
73
00:11:57.666 --> 00:12:29.708
And so design systems teams have a right to be at the table in those discussions, and we have the responsibility not only to make a beautiful design system that translates the brand into product, but we actually have to care all the way deeply into the frame of the browser how the product is rendered, how it performs, and how customers respond to that performance.I love that framing because design systems now are not just the visuals, but it's also like the example you just gave of an engineer adding some other NPM package or just building something that's a little bit different.
74
00:12:29.768 --> 00:12:49.978
It's not just efficiency for developers that they don't have to go build a new component, it's also that not going to build a new component, not using another package, not doing something in a different way really does help the whole product perform better from a UX perspective, from a code perspective, from a rendering in the browser perspective.
75
00:12:50.508 --> 00:13:00.678
There's all these elements that a design system really can touch. This is a, a Jina-ism that I got from Jina Anne, that design systems are just how we build UI now.
76
00:13:00.688 --> 00:13:17.728
And so when we think about the UI code that we are offering to our internal engineers, that's also infrastructure. We are offering them tools to build this product in a way that meets our company's goals.
77
00:13:18.388 --> 00:13:29.348
And to me, that is so compelling. It's so much more compelling to the organization than the design system helps it look nice.
78
00:13:29.388 --> 00:13:44.848
If we think about shipping our UI in a way that maintains the brand, and is performant, and is fast both for the user and for the internal designer and developer, that's a critical capability that helps us get all of us to our goals.
79
00:13:45.028 --> 00:13:57.328
This, I think, makes it a lot harder also for an organization to just say, "We don't need that design system anymore," or, "That's not delivering the value that we thought we were going to get."
80
00:13:57.868 --> 00:14:05.988
There's a really scary moment right in there where it's very easy for the organization, for leadership to go like, "Uh, why are we paying for this? I'm not seeing the value."
81
00:14:06.048 --> 00:14:10.868
If you keep going, if you can get out of the dip, there's a moment where it starts to pay off.
82
00:14:11.628 --> 00:14:22.768
And when we think about design systems as infrastructure, I think that's much easier because we recognize that infrastructure has to be long-lasting, that the value of a system has to happen over time.
83
00:14:22.788 --> 00:14:35.248
Like, you really don't hear about teams, like, defunding their database teams. Yeah. One, one idea here, like the transition between design system as a product to design system as infrastructure.
84
00:14:36.208 --> 00:14:45.008
Design system as a product taught us to care about our customers. They taught us to care about adoption. It taught us to, to listen to our customers and respond to their needs.
85
00:14:45.388 --> 00:14:52.888
So it taught us how to build design systems and how to ensure that they become mission-critical to the company, having a real customer focus.
86
00:14:53.828 --> 00:15:03.248
Pivoting to design systems as infrastructure, my dirty little secret here is that infrastructure is also a product, and people who build infrastructure look at it as a product. They care about their customer.
87
00:15:03.298 --> 00:15:05.808
They care about providing things that the customer wants.
88
00:15:06.418 --> 00:15:19.847
But the, the difference is we look at infrastructure as something that must be sustained over time, something that's mission-critical to the company, something that transitions from thing to thing and doesn't just get turned off then turned on, funded, defunded, in fashion and out of fashion.
89
00:15:20.448 --> 00:15:31.008
Mm. Yes. I love saying in or out of fashion at the organization because you can't have your AWS or Kubernetes or your scaling server concerns or your database migrations.
90
00:15:31.048 --> 00:15:38.648
Like, you, you can't just be like, "Oh, we're not gonna do that for a while." No. And it doesn't mean infinite resources forever either.
91
00:15:39.008 --> 00:15:48.108
Like, just like any other team, infrastructure teams, they scale up with needs, they scale down with needs. Sometimes they contract out or bring in consultants to help them scale.
92
00:15:48.228 --> 00:15:53.148
But there's a core idea that there will need to be people here to run this thing.
93
00:15:53.308 --> 00:16:01.088
There will need to be people here to ensure that not only the contracts are signed with AWS or Google or whoever cloud providers you're using, right?
94
00:16:01.568 --> 00:16:14.108
But there's also gonna be, need to be people here who help the company adopt and use and continue to get the benefit of that infrastructure. Absolutely. I wanna talk a little bit more about...
95
00:16:14.168 --> 00:16:22.558
Yes, I wanna talk a little bit more about AI. I don't want this to be like a design systems AI podcast, but I feel like we can't ignore it right now. It is changing things.
96
00:16:22.608 --> 00:16:31.328
It is changing how design systems get built and how design systems get used. It's changing how s- software engineering is being done. It's changing how design is being done.
97
00:16:32.248 --> 00:16:45.028
So how are you thinking about those two sides of that coin, not just about AI, but design systems in general in the future as critical infrastructure? How are they getting built internally?
98
00:16:45.848 --> 00:16:57.028
What do you see as the future of how that supports an organization on the internal side? Yeah. I think about the way AI is going to transform design really in two ways.
99
00:16:57.188 --> 00:17:03.268
I think it transforms the way we use design systems, the way that designers design product.
100
00:17:03.868 --> 00:17:16.228
I think that tools are gonna evolve and new capabilities are gonna be there for designers to much more rapidly ideate, explore, and produce the types of artifacts that we produced in the past.
101
00:17:16.908 --> 00:17:19.278
It doesn't mean design becomes any less critical, right?
102
00:17:19.308 --> 00:17:30.328
The designer's job is still to envision a future state of the product that doesn't yet exist, to socialize those ideas, and to gather consensus around a future state of the product that is not there yet.
103
00:17:31.028 --> 00:17:34.428
This does not change for design. I think design will, that will continue to be a superpower.
104
00:17:34.858 --> 00:17:49.588
So I think the way we'll see AI accelerate the designer workflow is we'll see more focus on solving the right problem, exploring the problem more, ex- finding the right solution, exploring multiple solutions, and we're all limited by the scope of knowledge that we have.
105
00:17:50.108 --> 00:17:57.878
AI could be a very helpful thought partner to help us explore beyond the scope of what we currently know or what's currently in our brain or what we can imagine. Mm-hmm.
106
00:17:58.268 --> 00:18:08.258
Well, I think it'll be a very useful partner for design. I think specific design systems, AI will transform how we build systems. There's a lot of tedious work that happens in design systems, right?
107
00:18:08.348 --> 00:18:17.508
If you think about one change that needs to scale across hundreds of components with dozens of states of those components, we've developed tools that help us do that faster.
108
00:18:18.208 --> 00:18:33.668
But I think AI, in particular about agents and how agents are emerging now-Can I ch- create an agent, train an agent, give an agent enough context to go do a bunch of things to my system that I think need to be done, and have those happen in a much more rapid way?
109
00:18:34.218 --> 00:18:38.788
That's one possibility. I think we'll just see AI transforming the way we make design systems.
110
00:18:39.148 --> 00:18:45.308
I had the good fortune to work with Nate Baldwin for a little while here at Intuit, and Nate helped really extend my thinking.
111
00:18:45.408 --> 00:19:06.448
If you haven't seen his tools like Leonardo for color or Proportio for spacing, Proportio he developed while he was here, and they're just great tools that help you understand the mathematics behind color, the mathematics behind spacing, and that can create usable artifacts very easily but makes the task of doing that thing very visual to you as well.
112
00:19:06.648 --> 00:19:21.038
Huge kudos to Nate on those, and I, I think we'll see more of that type of tooling automation that helps to shape your design systems, helps shape your thinking a design systems practitioner versus the sort of old ways of doing things.
113
00:19:22.088 --> 00:19:28.628
Yeah. I'll be sure to link those in the show notes. And I know there's a lot of fear around AI, but I'm excited for a lot of these tools.
114
00:19:28.768 --> 00:19:37.728
There's two things that you said that I really wanna call out, and one is this idea that we're limited by our own knowledge. We can only do as much
115
00:19:39.468 --> 00:19:53.748
n- new design or new thinking as we have expansive mental space to come up with those ideas. And I'm thinking about even a really simple use case like I didn't know that component existed or did that.
116
00:19:53.868 --> 00:20:06.268
I didn't know it had that variation or that option. And being able to use an LLM tool to just say, "Hey, what's out there? What's available? What are the potential options for this? Can it work like that?"
117
00:20:06.368 --> 00:20:14.028
is a way of expanding and augmenting our human brains and what we can think about and what we can actually do.
118
00:20:14.068 --> 00:20:23.088
And then also the idea that we can use these tools for the, the either the tedious but also the mathematical or, like, the computer stuff, right?
119
00:20:23.128 --> 00:20:33.827
Like, the LLMs right now, I don't know where we're gonna be in 10 years, and I'm not gonna try to be here making predictions that don't age well, but right now the LLMs are really good at the computer stuff.
120
00:20:33.848 --> 00:20:38.918
They're good at the syntax. They're good at... Well, they may not be necessarily good at math. Yeah.
121
00:20:38.948 --> 00:20:47.868
But they're good at, like, looking at all of your components and their code and saying, "Here's how they work," or, "Here's how this color math works," and explaining that and surfacing it.
122
00:20:48.788 --> 00:21:02.208
And one of the things that I'm optimistic about is, again, augmenting how we can use our craft and use the human side of our skill alongside that.
123
00:21:02.868 --> 00:21:15.768
Color, obviously when you talk about color, accessibility comes up, and we have very different human eyes in very different human bodies, and we see things differently. We emotionally relate color differently.
124
00:21:16.108 --> 00:21:32.308
And so when we look at something like a color scale, there's not just science that goes into it of all these colors across the spectrum have the exact same HSL values or whatever, but then also, like, oh, that yellow looks like baby poop, and maybe that's not a good color for our UI.
125
00:21:32.348 --> 00:21:42.928
Or, oh, what is the feeling of this? Or how do we tweak this in a way that works for people with all different kinds of vision? And there's a science there, but there's also an art there.
126
00:21:43.028 --> 00:21:52.448
And I love the idea of freeing us up as humans to think about that 20% of polish, right?
127
00:21:52.568 --> 00:22:04.368
That 20% of making it really work for our brand, for our sensation, our experience, for accessibility in a way that, like, instead we've just been spending all of this time, like, doing the math ourselves, right?
128
00:22:04.408 --> 00:22:07.998
So I'm really excited about that. What's something that you're really excited about?
129
00:22:08.228 --> 00:22:15.508
I, I think that our job is still going to be to translate the brand into product or into marketing or whatever your system is really thinking about doing.
130
00:22:15.968 --> 00:22:30.298
And as you think about, like, code getting commoditized or even, like, experience design getting commoditized, and what I mean by commoditized is that more companies have the same abilities to create the same experiences.
131
00:22:30.608 --> 00:22:37.988
We've seen that great leveling up, like when Google Maps very first came out and suddenly you can move the map around, you can zoom in and zoom out of it. That was stuff we'd never seen before in MapQuest, right?
132
00:22:38.028 --> 00:22:43.388
It blew our minds. Uh, but very quickly, like, everybody else figures out how to do that as well.
133
00:22:43.428 --> 00:22:50.988
And so technology commoditizes and, and eats itself over time, but what will never be a commodity is a brand that you've built.
134
00:22:51.288 --> 00:23:06.088
So translating that brand through your design system is still a critical step, particularly in the AI future because in the AI future where agents are writing code, code is being created and tested on the fly, not necessarily always handcrafted, your brand is what you have.
135
00:23:06.188 --> 00:23:14.948
Your brand is all you have. Mm. Your brand is your biggest asset. It's how you instill trust with your customers and how your customers will continue to rely on you or want to rely on you.
136
00:23:14.958 --> 00:23:24.128
And so I believe just like we saw with Material Design where when it went big and broad and a lot of companies started using Material for their design system, everything started looking the same.
137
00:23:24.268 --> 00:23:27.748
The system limits our creativity I think- Yeah... around the same time. Yeah.
138
00:23:27.788 --> 00:23:37.568
But there's still important work to be done, you know, company to company to craft what do our products look like, and I think that will be, that will emanate from, that will come from the design system.
139
00:23:38.058 --> 00:23:45.188
The design system will continue to translate the brand for the customer because the fastest way to deliver anything to a customer is going to be with the design system.
140
00:23:45.528 --> 00:23:55.108
And as these AI tools come into designers' hands, the language that's going to be used under the covers is the design system. We are defining the language for the company. We're defining that design language.
141
00:23:55.148 --> 00:24:05.668
We're defining the language for the LLM or the model to use to create experiences that we can look at and say, "Yes, that's a great experience. Let's ship that to our customer." And so this is still a critical...
142
00:24:05.968 --> 00:24:13.808
The job of design systems is still very critical in a world where AI is helping us do everything. Yeah. I completely agree.
143
00:24:13.968 --> 00:24:21.188
I think there's so much room to think beyond the way that we do our jobs now and the things that we deliver now.
144
00:24:21.228 --> 00:24:29.248
On this podcast, I have been saying a lot with Dan Mall, like the foundations, these primitives, like that's not really the real value of the design system.
145
00:24:29.268 --> 00:24:33.408
And as those pieces get even more commoditized, and I mean that in a good way, right?
146
00:24:33.468 --> 00:24:42.030
Like, how many ways are there to build an input?There's just, there's only so many, and we don't need to be doing that fully crafted by hand anymore.
147
00:24:42.060 --> 00:24:51.560
We have so many examples of really great inputs that do just about anything that you could ever need them to do that we can use, so what does that free us up to do?
148
00:24:52.660 --> 00:25:07.230
I love your, like, MapQuest versus Google Maps examples of a new, a new interaction or a new experience that actually really leveled up the whole industry in thinking about how we can interact with our devices and the internet in a new way.
149
00:25:07.330 --> 00:25:24.970
And I think there's a lot of room for that in the coming years when we can stop thinking about building the dang input and instead start thinking about how do we deliver on this promise of personalization that we've been talking about for, I don't know, five, s- 10 plus years, right?
150
00:25:24.980 --> 00:25:36.720
Like, we didn't have the tools to deliver true personalization, but in my episode with Gina Ann, she talks about this. Like, how do you deliver a UI that is better for a left-handed user? Mm. Like, on the fly.
151
00:25:36.780 --> 00:25:48.620
How do you actually change your UI to make more sense to somebody who is colorblind or somebody who has a physical disability? But even something like being left-handed, do the buttons always need to be on the right?
152
00:25:49.040 --> 00:25:59.320
Can they be different? And that's just scratching the surface of all the things that we can do as designers who are thinking about what does it mean to deliver a really good experience to our users?
153
00:25:59.380 --> 00:26:11.200
What does it mean to make UIs that really work for our product, whether that's new interactions or new technical tools that can do things like change the UI on the fly based on user settings.
154
00:26:11.650 --> 00:26:19.640
Again, that's just one example, but we haven't had the space to think about that because we are still making inputs.
155
00:26:19.740 --> 00:26:25.500
We are still making pixel perfect mock-ups of things that already exist and then have to get translated into code.
156
00:26:25.640 --> 00:26:38.620
What if we expanded our horizons of what work we have to do and, and where we get to play in the UI and UX space? I've focused a lot on, like, how I think designers' work will change or how AI will change what we do.
157
00:26:38.980 --> 00:26:48.910
Make no mistake, I believe also AI will change the products we're building for customers. And so the interaction designs, the interaction models of the past may not be the interaction models of the future.
158
00:26:49.120 --> 00:26:57.820
And as you think about, like, with ChatGPT or the various different sort of chat-based interfaces that have come out, they're just chat-based interfaces. We've had chat-based interfaces for a long time.
159
00:26:57.860 --> 00:27:09.160
That's not the revolutionary new interaction model. But agents represent a potentially revolutionary new interaction model. Like, how does a real person know what an agent is doing on their behalf?
160
00:27:09.400 --> 00:27:20.860
How do they inspect their work? How do they start an agent and stop an agent? How do we sort of verify and, and trust throughout the journey of AI doing something that it's doing it accurately on our behalf?
161
00:27:21.600 --> 00:27:28.640
And so there's going to be new emerging interaction models. There are gonna be new emerging interface design, and I'm here for that. I think that's gonna be exciting.
162
00:27:28.770 --> 00:27:40.540
I think that's a great thing for us to be focused on as a design community in the coming future. So this is a tough question because I'm gonna ask you to speculate about our future, and I feel like AI predictions-
163
00:27:41.480 --> 00:27:50.620
Yeah... total toss-up. Your own peril, yes, you mentioned. Yes. [laughs] Everything AI is bad at today might be good at tomorrow, right? So yes. We definitely don't know. We're totally speculating here.
164
00:27:50.780 --> 00:28:03.120
But thinking about design systems as infrastructure and some of these potential new ways that we might work or things that we might build, how do you see design systems supporting those things in the future?
165
00:28:04.060 --> 00:28:12.940
So we focus a little too much on components, right? And tokens have been a very important thing as well, but I think the untapped value of systems is in the patterns.
166
00:28:13.620 --> 00:28:18.880
And so that's something we're leaning into heavily right now w- in Intuit, particularly as we think about AI in the future.
167
00:28:19.520 --> 00:28:29.789
We believe that the design system should contain relevant and well-tested interaction patterns that AI-based experiences will use throughout the products.
168
00:28:30.509 --> 00:28:38.760
So we don't need a redesign from one product to the other how a user would verify something that AI read and transcribed for them.
169
00:28:38.820 --> 00:28:47.280
There could be just one sort of pattern or component that does that, that was well tested and we know that customers love, and that's also a platform capability.
170
00:28:47.400 --> 00:28:54.579
So our products can reach down to the platform, ask the platform to process that for us. We send it back to the interface, to the customer, right?
171
00:28:54.720 --> 00:29:03.390
The customer just saw this really performant, magical experience, and maybe they use multiples of our product, and so maybe they get used to seeing the same experience or having that same experience in multiple places.
172
00:29:04.160 --> 00:29:13.820
That's, I think, a key value that design systems will bring to future product development. I have so many questions about how that's gonna work because I agree, I think patterns are the next...
173
00:29:13.860 --> 00:29:21.660
one of the next frontiers for design systems. But from a technical perspective, from a code perspective, it's actually quite challenging to deliver patterns.
174
00:29:21.690 --> 00:29:30.040
And I think one of the reasons that we coalesced around components is because it's very easy to deliver, like, a very small atomic chunk of something.
175
00:29:30.480 --> 00:29:40.420
React in particular made it quite easy to do that in an abstracted way, where we didn't have to know anything about the product itself. We can just say, "Here's the props. It's totally isolated."
176
00:29:40.540 --> 00:29:51.210
And I think that that is great, but patterns completely defy that kind of concept of, of what you can deliver because it's multiple things.
177
00:29:51.360 --> 00:30:04.400
You maybe need to be also talking to your database or to some API, or, like, you just, you can't deliver it as a completely isolated thing. And so I'm really intrigued to explore, like, how does that actually work?
178
00:30:04.440 --> 00:30:18.190
How do we deliver patterns in a way that actually makes sense for our internal users, our designers, and our engineers to use it in a way that's not just like copying stuff around and then it being edited, and then it's not the same pattern anymore, and then...
179
00:30:18.280 --> 00:30:28.290
I think there's still a lot to figure out there. Yeah. The tip I would give people, particularly if you work at a large-ish company that has many teams solving many problems all at once, is look at your platform peers.
180
00:30:28.360 --> 00:30:35.280
Look at your platform teams. What problems are they trying to solve in the infrastructure of the company or through centralized capabilities in the company?
181
00:30:35.920 --> 00:30:47.984
And th- those are where your patterns work should go.They may or may not think they're supposed to be producing UI. They may think that their work is just back-end infrastructure or APIs or some other interaction model.
182
00:30:48.344 --> 00:30:53.724
But there's a conversation there to be had to say, "Hey, what if we delivered the pattern?" Right?
183
00:30:53.804 --> 00:31:08.324
What if we delivered some kind of UI also as part of this platform initiative or this central infrastructure initiative that we have to, say, take a request from a user and send it to an LLM and, and sanitize it on the way back out, or make sure it's compliant, audited on the way out, right?
184
00:31:08.564 --> 00:31:16.564
There are many subsystems like this that have to emerge, that need to emerge in a company. At Intuit, we do a lot of document reading, right? People upload their tax documents.
185
00:31:16.604 --> 00:31:23.264
We have to read to understand the document, and we have to put it into their tax forms for them. And so we have centralized capabilities that do that work. But guess what?
186
00:31:23.304 --> 00:31:29.344
It's great for tax for people, for individuals, for individual customers. It's also great for business owners, right?
187
00:31:29.764 --> 00:31:34.964
Businesses also have a lot of even more bespoke forms, like things that they create for their own customers.
188
00:31:35.004 --> 00:31:41.164
And so the same capability that reads and understands our tax forms can read and understand business forms that they're creating on the fly.
189
00:31:41.604 --> 00:31:50.874
So that's just one example of, like, centralized capabilities within the company you could look at and say, "Where are our opportunities to declare patterns and to nurture patterns within the company?"
190
00:31:50.904 --> 00:32:02.674
And maybe it's within those engineering teams. Just more engineering friends to go make across the company. [laughs] That is, like, one of my personal soapboxes, though, is that design is currently...
191
00:32:02.724 --> 00:32:09.764
We are working in a medium that is not the actual medium, right? Like, when we are making a Figma mock-up, or back in the day it was, like, Photoshop, we're making a picture.
192
00:32:10.344 --> 00:32:21.984
And Figma has done so much for design of UI, but I am all always, always, always on the soapbox of our designers need to get closer to the medium.
193
00:32:22.024 --> 00:32:27.364
They need to understand what is actually getting built and how it actually works on the code side, because the code is the medium.
194
00:32:27.904 --> 00:32:47.563
I think we're gonna see more tools that allow designers to interface with the code in a visual way, which is fantastic, and I think we're gonna see, I hope, more understanding from the design side of the engineering needs and how it works on the engineering side, just like you were talking about, right?
195
00:32:47.623 --> 00:32:59.124
Like that pattern of reading a document and, and spitting it back out. There's a visual component, but there's also a user experience and flow component, but there's also a fairly technical component.
196
00:32:59.704 --> 00:33:09.004
And I think you're a better designer when you understand that technical component and what it actually does and how it actually works and how to work with that. So I'm excited to...
197
00:33:09.144 --> 00:33:16.424
I'm excited for anything that brings us closer together. I think the days of saying bridge the gap are over, and we need to just- Yeah.
198
00:33:16.744 --> 00:33:29.164
Yeah, going back to the existential threats to design, honestly, I think the only existential threat is for design to stay stuck in the current visualization tools that we have. I love Figma. I loved Sketch before.
199
00:33:29.324 --> 00:33:34.864
I loved Photoshop before that, and Illustrator, and Fireworks, right? But one thing that's constant is our tool set will change.
200
00:33:35.244 --> 00:33:46.864
And yes, it will change yet again in the emerging capabilities that AI will bring into the world. And how do you not get leapfrogged, right? Keep moving forward with how do you visualize the future customer experience?
201
00:33:47.284 --> 00:33:50.244
Today in Figma, because it's a very low-cost way of doing it.
202
00:33:50.284 --> 00:34:00.103
It's a low-cost way to prototype something together quickly, mock up some visuals, mock up some wire frames, show it to your product manager, show it to the engineers, get some reactions, keep iterating.
203
00:34:00.144 --> 00:34:06.284
There may be faster ways to iterate in the future that are closer to code. They're closer to even production code. We don't know.
204
00:34:06.344 --> 00:34:13.844
That will emerge, that new sort of product development life cycle or that iteration capability will emerge, and we need to be ready for it.
205
00:34:13.984 --> 00:34:24.904
That brings me back to some concerns that I think are floating around the design system space right now around this idea of design system as infrastructure, or that I think design systems as infrastructure can maybe help with.
206
00:34:24.944 --> 00:34:34.504
And that is this idea again of like, well, the design system is failed. The design system isn't doing what we want, therefore we're going to stop working on it. We're gonna defund it.
207
00:34:34.524 --> 00:34:41.684
We don't need this design system team anymore. We talked a little bit earlier about why it's harder to do that when you think about design system as infrastructure.
208
00:34:42.624 --> 00:34:56.244
But how can we be talking about the continued need for the system and the continued way the system can evolve to our leaders? A lot of the people I think listening to this podcast are maybe senior staff plus ICs.
209
00:34:56.504 --> 00:35:09.824
We don't often get to be in these director plus conversations or C-level conversations. And I know that there's a lot of worry that, you know, in, in the past couple of years we've built these design systems.
210
00:35:09.844 --> 00:35:17.464
The design system teams have been, like, massively staffed up, and then there's been like, "Oh, we don't need this anymore. Oh, we're gonna stop working on it." We don't really get to see the full value of the system.
211
00:35:18.124 --> 00:35:28.724
When I talked to Noelle Lansford on the podcast, she was actually talking about her hiring experience and having hiring conversations with teams, I think in 2023, that were like, "Yeah, we actually just wanna get rid of our design system."
212
00:35:28.964 --> 00:35:39.684
And I see that shifting, but I see also the potential for a lot of the AI-enabled changes to, to have that same...
213
00:35:39.724 --> 00:35:49.084
Like, we're gonna meet that same speed bump again in the future, where it's like, oh, the design system didn't keep up with this change, or, oh, now we can have the AI do it [laughs] or whatever.
214
00:35:49.484 --> 00:35:55.124
And I don't personally think that's true, but I do think that we might see that.
215
00:35:55.164 --> 00:36:07.984
So I'm curious from your perspective, how would you encourage design system practitioners to think about continuing to evolve the value of design system as critical infrastructure as our tools and ways of working with it change?
216
00:36:09.464 --> 00:36:16.264
This is just as much for leaders as it is for anybody who works on the system. We all need to be worried about education.
217
00:36:16.324 --> 00:36:25.824
We all need to be worried about understanding the point of view of the people surrounding us and helping them understand how the design system helps to solve the problems that they're most worried about.
218
00:36:26.414 --> 00:36:30.414
This is a very hyper-contextual thing for every organization in every company.
219
00:36:31.044 --> 00:36:52.924
So I mentioned before, I've worked in design systems at three different organizations, three completely different sizes, completely different business challenges, three completely different engineering setups, product setups, maturity levels.And so your strategy, whether you're a leader or an individual contributor working on a system, your strategy needs to be specific to the organization that you're delivering within.
220
00:36:53.334 --> 00:37:03.984
So there is no copy and paste playbook that you can just go into every company, and that's why every design system is different. It serves the company differently, in different needs, in a different scale of maturity.
221
00:37:04.684 --> 00:37:12.464
So I would say take a step back. Who are your investors? So who are the people that are responsible for funding your team, funding your efforts?
222
00:37:13.154 --> 00:37:21.364
So those are the investors you need to make sure you have a specific message for. Who are your customers, and are you delivering for them? When they give you the feedback, is that feedback responded to, right?
223
00:37:21.464 --> 00:37:29.204
Just like we talked about with design system being a product. Who are your customers? And then who are your, your team, right? The people who are going to deliver the system with you.
224
00:37:29.704 --> 00:37:32.924
As a leader, you need to make sure that you have the right team to be able to deliver it.
225
00:37:33.124 --> 00:37:43.244
And as things change, as design systems change, you need to evolve the skill sets and the abilities of the team to, to match the need that's needed at the time.
226
00:37:44.844 --> 00:38:06.934
I think one of the subtexts of design system as infrastructure versus design system as product is if we can get the organization to think about it as infrastructure, then, then they'll just know that it's very valuable, and we will never be defunded or, or have layoffs, or, like, there will just be support for it in a way that there wasn't when we were trying to
227
00:38:07.944 --> 00:38:15.314
be a product. But I don't think that's really true. You mentioned earlier infrastructure teams scale up and down to meet the needs of the business.
228
00:38:16.504 --> 00:38:27.444
What are your conversations like in, in director plus meetings about infrastructure and about maintaining that infrastructure and positioning the design system organizationally?
229
00:38:28.084 --> 00:38:37.864
One of the things I've learned, particularly here at Intuit, we're very focused on our customers, and we're very focused on getting the value of whatever we're doing into our customers' hands.
230
00:38:38.184 --> 00:38:39.624
And so we're very outcomes-focused.
231
00:38:39.804 --> 00:38:51.404
Although process is very important, and the process, the design processes we've established at Intuit that are fairly mature help us to achieve the outcomes we want, at the end of the day, the outcome still is the objective.
232
00:38:52.064 --> 00:39:05.224
And so knowing what your fellow directors and the VPs and SVPs are looking for in terms of a customer outcome and aligning your system to those customer outcomes is the critical path.
233
00:39:05.904 --> 00:39:21.824
And if you can put the design system in the critical path or if you can articulate why the design system is a part of the critical path of delivering the most valuable thing your customers need tomorrow or this year or this quarter or whatever timeframe you're thinking of as a company, then the magic happens, right?
234
00:39:21.924 --> 00:39:30.324
The resources come. The idea of, "Oh, yes, this is critical infrastructure. This is how we're going to deliver XYZ experience to our customer," is understood.
235
00:39:30.784 --> 00:39:35.244
Design systems always had a little bit of a tailwind in that we were close to the components team.
236
00:39:35.824 --> 00:39:43.424
And in, in organizations where engineering drives the boat a little bit, they always understand the need for UI components.
237
00:39:43.713 --> 00:39:49.584
And so design systems have always had a little bit of a head start to say, "Oh yeah, that's important," because we know the engineering importance of it.
238
00:39:50.204 --> 00:40:07.204
Similarly, if you live in a product context, if your design system is important for achieving that next scale of revenue, maybe we need to go international, so we need to be able to have components that are internationalized or localized to have every country we intend to go to, and that's gonna unlock N number of dollars in revenue for the company.
239
00:40:08.524 --> 00:40:19.344
I'd say align your design system efforts to the overall company goals so that you can help the company achieve their objectives. Yeah. I think in a lot of cases, a little bit easier said than done.
240
00:40:19.484 --> 00:40:50.464
Maybe for folks out there who don't have a design director or an engineering director or somebody who is in those conversations already, in the room already, who already agrees with that or already understands the position of the design system or what it could be, what advice would you give an IC design system practitioner, maybe somebody who's already on a design system team but is worried about the position of their design system in their organization, and they're not getting to be in the room with VPs and execs who are talking about those company goals.
241
00:40:50.833 --> 00:41:02.564
What advice would you give them about how to have that conversation with their manager or bring that to their leadership? One of the things that ICs can really focus on is
242
00:41:03.464 --> 00:41:07.244
design systems adoption to those company priorities.
243
00:41:07.724 --> 00:41:20.304
Sometimes we have the instinct to roll our eyes when people struggle to adopt the design system, or when you have a customer request that feels like it goes against the design system grain, but it's for this, like, hot, new, important initiative for the company.
244
00:41:20.324 --> 00:41:23.964
As design systems practitioners, I would say, like, step into that conversation.
245
00:41:24.004 --> 00:41:35.404
Like, align yourself, join yourself to that important project, to that important initiative to the company, and see how you can take whatever experimentation or learning that they're doing, drive it back into the design system.
246
00:41:35.784 --> 00:41:39.544
If it's good insight, it will improve your design system overall as well.
247
00:41:39.844 --> 00:41:49.064
And so you can't look at every challenge that's coming to you from the product design teams and roll our eyes and wring our hands and say, "Oh, if people just understood the design system and used it, our jobs would be so much easier."
248
00:41:49.354 --> 00:41:58.744
Like, our job is to continue to go out and help people use the system, but also facilitate the insights that they're getting from the products back into the design system and improve it.
249
00:41:59.184 --> 00:42:10.544
So that, that's one more team-level thing you can do. Sometimes you can't change the broader organization, right? You live in engineering, you live in product, you live in some corner of a business unit somewhere.
250
00:42:11.424 --> 00:42:18.504
I'm not sure there's any magic wand you can wave or any letter you can write or any, anything you can do special to, to make those big changes.
251
00:42:18.544 --> 00:42:28.664
But I think you can get close to the critical initiatives for your company, for your business unit, for your product leader, and show how the design system provides value there. Yeah. Completely agree.
252
00:42:28.794 --> 00:42:38.524
And I, I love that you said that at the end, that sometimes the organization is just gonna go in a direction that you don't agree with, and that sucks sometimes.
253
00:42:38.624 --> 00:42:52.364
You get a new executive, and they don't like it, and they wanna do something different, and sometimes that's just bigger than we can influence from an individual IC levelBut it's also I think such a good reminder that
254
00:42:53.584 --> 00:43:02.464
aligning yourself with the goals of the organization is the value of the design system. Things are always changing. Our product is always changing.
255
00:43:02.644 --> 00:43:10.144
If we're not changing, we are not going to have a successful product, we are not gonna have a successful business. We have to always be changing and adapting.
256
00:43:10.474 --> 00:43:16.984
And I think there's a, a really delicious tension though with design systems where we have to be the backstop, right?
257
00:43:17.144 --> 00:43:26.704
We have to have the stuff that is, like, tried, tested, and true, and we have to be supporting these new directions that our business and our product really have to move into.
258
00:43:27.224 --> 00:43:39.904
And no matter what your organization looks like or where you're positioned in the organization, it doesn't mean you shouldn't or can't talk about your efforts and perform your efforts in the way that you want to.
259
00:43:39.924 --> 00:43:45.444
Don't hold yourself back based on the organization in terms of the way you feel like you need to show up and you need to do your design systems work.
260
00:43:46.124 --> 00:43:57.024
I think if you are true to what the organization needs, you're true to what you want to deliver as a designer, then the org structure will figure itself out over time. We can hope.
261
00:43:57.104 --> 00:44:06.424
So as always, I ask every guest who comes on the podcast to give us a spicy take on design systems. This is my favorite part of the show. We get so many really good answers.
262
00:44:06.464 --> 00:44:19.064
So Sam, what is your spicy take on design systems? I don't understand why everyone is afraid that AI will destroy design jobs, and more specifically, why it will destroy the design systems jobs.
263
00:44:19.584 --> 00:44:28.764
Yes, this is certainly having a near-term impact on many companies' hiring practices, so I'm not trying to be unsympathetic to people who are struggling in the current hiring environment or situation.
264
00:44:29.344 --> 00:44:42.084
But I, as I look beyond the sort of fear, uncertainty, and doubt of right now, and we look at, and we look at code that might be commoditized and the activity of coding being commoditized, then you are left with your brand again.
265
00:44:42.204 --> 00:44:48.924
You're left with, how do we translate our brand and our brand values to be things that the customer care about?
266
00:44:49.024 --> 00:45:00.644
And, and so the way you convey your brand is through your bespoke design language, and we will always need careful, thoughtful design practitioners to take that language and codify it into systems.
267
00:45:01.234 --> 00:45:13.844
So I see a world where design specialists in particular, if you think about all those specialties of topography and visual design, interaction design, information architecture, they're actually more valued and they're more important in the future world where we're defining the language for AI to use.
268
00:45:14.504 --> 00:45:27.304
I know that there is a lot of fear right now, and a lot of uncertainty, and for good reason. When we go through a big sea change in the industry, it can be very scary. What would you say to somebody...
269
00:45:27.644 --> 00:45:37.384
Because you've been in the industry a long time. What would you say to somebody who's feeling a lot of that fear right now about where their skills can fit into the world of the future?
270
00:45:37.964 --> 00:45:45.684
These technological shifts come along all the time. I'm old enough to remember life before the internet, right? And then the internet came along and changed everything.
271
00:45:46.224 --> 00:45:54.303
And then mobile came along and changed everything again. And then cloud came along and changed everything again. And now AI is coming along and changing everything again.
272
00:45:54.384 --> 00:46:07.464
And so through all those shifts that have, have all happened through my, what I feel like is still a pretty short career, we have made it to the other side of all those shifts and have been stronger, better, faster, more capable at the end of it.
273
00:46:07.524 --> 00:46:18.464
And so I have no reason to doubt that we will have that again, that as we get through this period of uncertainty where we're trying to figure out what the future looks like, at the other side of it, like, the future will, will take care of itself.
274
00:46:18.504 --> 00:46:23.004
It will remake itself in a new way with these new capabilities. Let me say it this way.
275
00:46:23.544 --> 00:46:37.224
I am an eternal optimist, and I believe that the future will still be good and bright, and we just have to get through the uncertainty phase of not knowing exactly what that future looks like, but be confident and optimistic that it will be a future that's worth living in.
276
00:46:37.244 --> 00:46:47.184
Mm-hmm. Yeah. I love some optimism right now. It's sometimes hard to come by, and I think it's much needed. Things are going to change, and humans, we don't like change. We don't like uncertainty.
277
00:46:47.264 --> 00:46:58.164
That can be very hard for us, but I think so much more opportunity opens up when we can say, "Okay, what do we do with this? How do we go about making this work for us?"
278
00:46:58.224 --> 00:47:11.804
And I think that there's so much room for human ingenuity and human creativity and human expression using the tools that we have. That is always how humans have used tools, and I think that will continue to be the case.
279
00:47:11.944 --> 00:47:21.904
So thank you for your optimism, for going over all of that stuff about design systems infrastructure with us, for sharing your thoughts on leadership conversations and, and the future with us, and thanks for being on the show.
280
00:47:23.204 --> 00:47:34.104
My pleasure. 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.
281
00:47:34.564 --> 00:47:35.664
See you next episode.