On Theme: Design Systems in Depth

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

• Elyse Holladay • Season 1 • Episode 16

Share episode

📲 Text the show your thoughts!

Y’all, I’ll be honest. Some days, I’m scared and nervous and uncomfortable with AI’s emergence, and implications, too. But I am also curiously optimistic, and more importantly — I don’t want to use any platform I have to spread even more fear and discontent and drama. So today you’re getting a dose of two things that I love: infrastructure and optimism.

Drawing from his experience leading design systems at three very large orgs, Sam Anderson from Intuit shares how framing design systems as infrastructure can help them be recognized as essential to business success. He shares his vision for the importance of patterns as the next frontier of systems work, particularly in a rapidly changing tech landscape accelerated by AI, and we talk about what leadership conversations look like. Plus, Sam drops a spicy take that he believes AI won’t destroy design system jobs but make us even more valuable.

Links & References


💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Sam Anderson:

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, and 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 backend 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.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the show, I'm excited to have Sam Anderson. 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. He specializes in interaction design and information architecture, and holds a Master of Human Factors from Bentley University. 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.

Sam Anderson:

Thanks for having me. This is gonna be, this is gonna be fun.

Elyse:

Yeah, I think so. I am so excited to have more guests who are in leadership. 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, we're gonna really dive into design systems as infrastructure. 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. 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?

Sam Anderson:

Yeah, I've always been curious about the realization of design, or how design manifests itself in code. 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.

Elyse:

This site is best viewed in 800 by 600 in Internet Explorer.

Sam Anderson:

Exactly. We're all scarred by internet Explorer Six. Still. Truly. But that's what really got me curious about if I could scale beautiful things, through large organizations, how would I do that? And it led me to want to establish our first coded design system for WebEx. 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. 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. 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, really big job. From there I'm thinking like, what's my next design system problem to solve? And that's when Intuit came along. 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. So we're talking about Credit Karma and MailChimp in those acquisitions, and historically having TurboTax and QuickBooks, all billion dollar brands on their own. 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. 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. And we had this sort of big Gen AI moment, that really has turned everything on its ear since then. 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.

Elyse:

Yeah. And we'll definitely talk more about AI in later parts of this episode. 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? 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? 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. And in that journey, we've gone from design systems being style guides and sticker sheets and again, like design and engineering tools, to design as a product. There were 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 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. 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?

Sam Anderson:

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, and we were all going through this AI transformation moment where there was a lot of fear, uncertainty, and doubt in the air. 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. I felt like these new tools, these new capabilities that AI would bring, could accelerate design in general and could accelerate design systems. 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. I work within the platform organization, and so Intuit is transforming itself to be a platform company, rather than a product company, right? 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. 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. Our design system is looked at as part of the infrastructure of the company. And so as I kept thinking about it in the framework of, particularly Nathan Curtis, who made very famous the idea that we should treat design systems as a product— and we should, our product should have releases, we should care about it, we should care about the customer experience with the design system. So very much still aligned to that concept. 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. I think that as we continue to articulate design systems as part of the critical infrastructure of the company, they will continue to have mindshare or continue to have the right resourcing within tech.

Elyse:

Yeah. 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. And I fully agree about design systems as product in the sense that, yeah, we need customer support and service. 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. 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. 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: 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?

Sam Anderson:

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— 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. 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. 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, 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. So we put a lot of energy and a lot of effort and a lot of care into infrastructure. 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. 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. And we're measuring everything these days, right? We're measuring time until first customer interaction. And you know, if your load times are over two seconds or over five seconds or over 10 seconds, right, like, customers will, 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. 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. We have a component for X, Y, Z, we're just gonna throw in another package, we're just gonna throw in another import statement, but then you get package bloat, 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.

Elyse:

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. 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. There's all these elements that a design system really can touch. This is a, a Jina-ism that I got from Jina Ann that, design systems are just how we build UI now. 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. And to me, that is so compelling. It's so much more compelling to the organization than, the design system helps it look nice. 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. 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. There's a really scary moment right in there where it's very easy for the organization, for leadership to go, like, I, why are we paying for this? I'm not seeing the value. If you keep going, if you can get out of the dip, there's a moment where it starts to pay off. 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. Like, you really don't hear about teams like defunding their database teams.

Sam Anderson:

Yeah, one, one idea here, like the transition between design system as a product, to design system as infrastructure, design system as a product taught us to care about our customers. They taught us to care about adoption. It taught us to listen to our customers and respond to their needs. 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. 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, they care about providing things that the customer wants. But 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 and turned on, funded, defunded, in fashion and out of fashion.

Elyse:

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, like you, you can't just be like, oh, we're not gonna do that for a while.

Sam Anderson:

No. And it doesn't mean infinite resources forever either, 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. But there's a core idea that there will need to be people here to run this thing. 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, 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.

Elyse:

Absolutely. I wanna talk a little bit more about— 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. It is changing how design systems get built and how design systems get used. It's changing how software engineering is being done. It's changing how design is being done. 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? What do you see as the future of how that supports an organization on the internal side?

Sam Anderson:

Yeah. I think about the way AI is going to transform design really in two ways. I think it transforms the way we use design systems, the way that designers design product. I think that tools are gonna evolve and new capabilities are going to be there for designers to much more rapidly ideate, explore, and produce the types of artifacts that we've produced in the past. It doesn't mean design becomes any less critical, right? 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. This does not change for design. I think design will, that will continue to be a superpower. 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, finding the right solution, exploring multiple solutions. And we're all limited by the scope of knowledge that we have. 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. So 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? 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. But I think AI, in particular about agents and how agents are emerging now, can I 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. That's one possibility. I think we'll just see AI transforming the way we make design systems. I had the good fortune to work with Nate Baldwin for a little while here at Intuit, and Nate helped really extend my thinking. 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 make the task of doing that thing very visual to you as well. 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 to shape your thinking, a design systems practitioner, versus the sort of old ways of doing things.

Elyse:

Yeah, I'll be sure to link those in the show notes. And, you know, I know there's a lot of fear around AI but I'm excited for a lot of these tools. 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 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, 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? is a way of expanding and augmenting our human brains and what we can think about and what we can actually do. And then also the idea that we can use these tools for the, either the tedious, but also the mathematical, or like the computer stuff, right? 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. They're good at the syntax, they're good at, well, they may not be necessarily good at math.

Sam Anderson:

Yeah.

Elyse:

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. 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. 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. 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. 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. And I love the idea of freeing us up as humans to think about that 20% of polish, right? 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? So I'm really excited about that. What's something that you're really excited about?

Sam Anderson:

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. 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. 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? It blew our minds. But very quickly, like everybody else figures out how to do that as well. And so technology commoditizes and, and eats itself over time. But what will never be a commodity is a brand that you've built. So translating that brand through your design system is still a critical step, particularly in the AI future. Because in an 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. Your brand is all you have. 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. 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.

Elyse:

The system limits our creativity, I think around the same time. Yeah.

Sam Anderson:

So 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. 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. And as these AI tools come into designer's 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. 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, a critical, the job of design systems is still very critical in a world where AI is helping us do everything.

Elyse:

Yeah, I completely agree. 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. 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. And as those pieces get even more commoditized— and I mean that in a good way, right? 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. 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? 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. 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, 10 plus years, right? Like, we didn't have the tools to deliver true personalization. But in my episode with Jina Ann, she talks about this, like, how do you deliver a UI that is better for a left-handed user, like on the fly? 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? 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? 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. Again, that's just one example, but we haven't had the space to think about that because we are still making inputs. We are still making pixel perfect mockups of things that already exist and then have to get translated into code. 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?

Sam Anderson:

I focused a lot on like how I think designers work will change, or how AI will change what we do. 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. 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. 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? 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. And so there's gonna 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. I think that's a great thing for us to be focused on as a design community in the coming future.

Elyse:

So, this is a tough question because I'm gonna ask you to speculate about a future, and I feel like AI predictions, total, toss up.

Sam Anderson:

At your own peril. Yes. You make, yes. Yeah. Anything AI is bad at today, it might be good at tomorrow, right. So, yes.

Elyse:

We definitely don't know, we're totally speculating here, 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?

Sam Anderson:

So we focus a little too much on components, right? and tokens have been a, a very important thing as well. But I think the untapped value of systems is in the patterns. And so that's something we're leaning into heavily right now in Intuit, particularly as we think about AI in the future. We believe that the design system should contain relevant and well-tested interaction patterns, that AI based experiences will use throughout the products. 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. 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. 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? 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. That's, I think, a key value that design systems will bring to future product development.

Elyse:

I have so many questions about how that's gonna work because, I agree, I think patterns are the next, 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. 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. 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 and I think that is great, but patterns completely defy that kind of concept of, of what you can deliver. Because it's multiple things, 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? 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 I think there's still a lot to figure out there.

Sam Anderson:

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, 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, and 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 backend infrastructure, or APIs, or some other interaction model. But there's a conversation there to be had to say, hey, what if we delivered the pattern, right, 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, audit it on the way out, right? 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. We have to read and understand the document. We have to put it into their tax forms for them. And so we have centralized capabilities that do that work. But guess what? It's great for tax, for people, for individuals, for individual customers. It's also great for business owners, right? Businesses also have a lot of, even more bespoke forms, like things that they create for their own customers. And the same capability that reads and understands our tax forms, can read and understand business forms that they're creating on the fly. So that's just one example of like centralized capabilities within the company you can look at and say, where are our opportunities to declare patterns and to nurture patterns within the company? And maybe it's within those engineering teams. Just more engineering friends to go make across the company.

Elyse:

That is like one of my personal soapbox though, is that design is currently, we are working in a medium that is not the actual medium, right? Like when we are making a Figma mockup or, back in the day it was like Photoshop, we're making a picture. 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. They need to understand what is actually getting built, and how it actually works on the code side, because the code is the medium. 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? Like that pattern of reading a document and, and spinning 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. 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, 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...

Sam Anderson:

Yeah. 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. I loved Photoshop before that, and Illustrator and Fireworks, right? But one thing is constant is, our tool set will change. 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? Today, in Figma because it's a very low cost way of doing it. 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. 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, that will emerge, that new sort of product development lifecycle, or that iteration, capability will emerge. And we need to be ready for it.

Elyse:

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. 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. 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, 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, 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, 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. 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. And I see that shifting, but I see also the potential for a lot of the AI enabled changes to, to have that same, 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 or whatever. And I don't personally think that's true, but I do think that we might see that. 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?

Sam Anderson:

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. 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. This is a very hyper contextual thing for every organization in every company. 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 a, an individual contributor working on a system, your strategy needs to be specific to the organization that you're delivering within. 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. 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? 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? 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. As a leader, you need to make sure that you have the right team to be able to deliver it. 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.

Elyse:

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 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. What are your conversations like, in, in director plus meetings about infrastructure and about maintaining that infrastructure and positioning the design system organizationally?

Sam Anderson:

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 customer's hands. And so we're very outcomes focused. 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. 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. 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? The resources come. The idea of, oh yes, this is critical infrastructure, this is how we're going to deliver x, y, z experience to our customer, is understood. Design systems always had a little bit of a tailwind in that we were close to the components team. And in, in organizations where engineering drives the boat a little bit, they always understand the need for UI components. And so design systems have always had a little bit of a headstart to say, oh, yeah, that's important because we know the engineering importance of it. 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 every country we intend to go to, and that's gonna unlock N number of dollars in revenue for the company. I'd say align your design system efforts to the overall company goals, so that you can help the company achieve their objectives.

Elyse:

Yeah, I think in a lot of cases, a little bit easier said than done, and 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. What advice would you give them about how to have that conversation with their manager or bring that to their leadership?

Sam Anderson:

One of the things that ICs can really focus on is design systems adoption to those company priorities. 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. As design systems practitioners, I would say like step into that conversation, 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. If it's good insight, it will improve your design system overall as well. 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. 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. 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. I, 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. 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.

Elyse:

Yeah, completely agree. 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. 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 level. But it's also, I think, such a good reminder that aligning yourself with the goals of the organization is the value of the design system. Things are always changing. Our product is always changing. 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. And I think there's a, a really delicious tension though with design systems where we have to be the backstop, right? 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.

Sam Anderson:

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

Elyse:

We can hope. 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. So, Sam, what is your spicy take on design systems?

Sam Anderson:

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. 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. But I, as I look beyond the sort of fear, uncertainty, and doubt of right now, and we look at, we look at code that might be commoditized and the activity of coding being commoditized, then you are left with your brand, again. You're left with, how do we translate our brand and our brand values to be things that the customer care about. 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. So I see a world where design specialists in particular, you think about all those specialties of typography and visual design, interaction design, information architecture, they're actually more valued and they're more important in the future world where we are defining the language for AI to use.

Elyse:

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, 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?

Sam Anderson:

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. 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. And so through all those shifts that 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. 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. It will remake itself in a new way with these new capabilities. Lemme say it this way. 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.

Elyse:

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, 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? 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. 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.

Sam Anderson:

My pleasure.

Elyse:

Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!