Design System Podcast image with podcast title, green map and small compass icon

Josh Clark, Founder of Big Medium: Scaling Digital Strategy Within Complex Organizations

Josh Clark and Chris Strahl dive into an in-depth discussion about navigating the digital landscape amidst economic unpredictability. They discuss the intricacies of building and maintaining design systems in large organizations, addressing the challenges of scaling, and emphasizing the strategic value of digital investments. Josh, an advocate for design systems as capital expenditure, shares his expertise on how these systems contribute to product development, impact revenue, and enhance customer retention, all while ensuring a balance between innovation and automation.

Transcript:

Chris Strahl [00:00:00]:

Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us at the Dspod. We'd love to hear from you.

Chris Strahl [00:00:21]:

Hey, everyone, welcome to the design Systems podcast. I'm your host, Chris Straw. All today I'm here with Josh Clark. Josh is the founder of Big Medium. He works with his better half, Brad Frost. They work on really big problems in design. Josh, so excited to have you on here. Long overdue.

Chris Strahl [00:00:38]:

Welcome to the podcast.

Josh Clark [00:00:39]:

Oh, Chris, thanks. It's great to be here.

Chris Strahl [00:00:41]:

So when we talk about big problems in design, maybe kick us off by understanding what does that mean for you at?

Josh Clark [00:00:48]:

Well, you know, we tend to work pretty exclusively with big, complex organizations, and so we sort of think of it generally as a category of big design. How do you get a whole ton of people working on a whole set of problems across platforms, products, brands, to actually go in a single, consistent direction? And of course, that's the nut of what design systems are about, is giving people a shared set of resources so that they can have a library of solved problems and not have to rehash already solved problems and create solutions over and over again. But I think it's also bigger than just design systems. It's sort of all of the process and philosophy and kind of vision or mission that teams have so that teams can actually work with each other across disciplines and across products and all of that stuff. And so a lot of the things that we do, we build a lot. We build products, we build design systems, but we also do a lot of process and organization design and helping companies be their best selves. I think one of the things, especially with big companies, they have the opportunities to work at economies of scale, but so often their scale just magnifies the dysfunction of the company. And I think helping companies work through that to be their best selves instead of their worst selves is a lot of what we do in terms of digital process.

Chris Strahl [00:02:16]:

It's really exciting. And I think that this leads us to a fun topic that we don't talk a lot about, and that is about digital strategy and specifically digital strategy at scale. So when you think about your customers and our customers, we serve a similar market. We work with big leading enterprise companies. You work with big leading enterprise companies. And I think it's interesting to talk about the trends in this right now, especially as it represents today's digital strategy and how that's changed from maybe twelve or 24 months ago. So when you think about what the environment looks like right now, the things that are obvious that are on the surface is that people are pulling back a little bit from big investments in design and product. And I think that there's a whole lot of reasons for this that are a little bit beneath the surface.

Chris Strahl [00:03:07]:

But I think overall we can all agree that this industry has faced a lot of contraction and that contracting scope and size of product teams is something that's left a lot of people worried and concerned for the future. I think that I have a little bit of a hopeful message in this, but I kind of wanted to dissect with you. When you think about the digital strategy of today and that pullback, where do you think that comes from?

Josh Clark [00:03:35]:

Yeah, I mean, I think there are a lot of reasons, and one is you see in the tech industry that the last year has had a lot of layoffs, a lot of contraction after years, decades of expansion. So there's sort of just what's happening in the tech industry, too. But I think in general, you look at just mainstream companies all over the place. This is just an unsettled time where there's just not a lot of great visibility for what's next. We've got a couple of wars going in the US. We're heading into what is likely to be a really weird election year with all kinds of uncertainty and reactions to, I mean, the economy is behaving really unpredictably. Like all the metrics are pointing in conflicting directions. And the thing doesn't seem to follow the rules that it followed pre pandemic, in the context of high inflation, high interest rates, which make it really hard for big companies to borrow money.

Josh Clark [00:04:30]:

So yeah, the logical response for leadership is be like, let's wait a tick, let's slow things down and see how things pan out. And that's sort of the message that I'm seeing is let's batten down the hatches where all this thing's going under so much. It's like, let's wait and see how this pans out because there's all kinds of confusing signals right now. So I think it just makes sense that there's a sense of conservatism. And I think that one of the things that digital organizations can be doing here, design, development, product. All those folks is thinking about what does it mean for us to operate in lean times, and how do we think about what is really valuable, not only to customers, but to the company, and how do we tell that story? How do we tell our story in a way that's really going to make sure that the important stuff gets done and that we can continue to do new and useful things with technology?

Chris Strahl [00:05:24]:

Yeah, I think the other part of this is it feels like whiplash to a lot of people because this is coming on the heels of what was ostensibly a big area of growth for a lot of companies for a while. You look at organizations, big companies, digital presence before pandemic, and it's one 10th the size of it is today. And that proliferation of experiences, apps, the surface area of our digital ecosystems just exploded for three years. It was like, what can I take that never happened online before and bring it online? What can I do to do even things like what we're doing right now, right. We're podcasting on a podcast platform from across the country from one another. And that was really hard to do. And you used things like Skype, and now there's actually, like, real platforms for it. So in that proliferation, design budgets were huge.

Chris Strahl [00:06:14]:

Product budgets were huge. People were spending a lot of money to try to build these ecosystems as quickly as they could. And now we're in the space where we're looking back at that time now more or less post pandemic and saying the metrics need to change. It's not just about how much can you build, how quickly. It's a lot more about the value of what you're building and whether or not that's actually moving a revenue or a cost needle in a particular direction.

Josh Clark [00:06:40]:

I think that's a great observation. I'll say sort of in the hurry to build a lot of digital stuff to replace kind of lost physical contact during the pandemic, there was just like a lot of people did things in kind of a messy fast because it had to be fast way. So there's a lot of sort of like, investment that was made that has not worked as well as had hoped. And I think one thing that I'll add to that is also there's obviously for decades now been this slow process of kind of what I would call traditional companies recognizing that digital is important and bringing it in. And we certainly saw with the companies that we worked with others, like big, super successful, but industrial or financial companies that didn't necessarily need to have cutting edge technology as being part of their core competency suddenly say, oh, we need to bring this in house. And so did that in a hurry, scaled quickly, and realized that kind of the other internal processes that they follow for scale manufacturing or whatever don't directly work for digital. And so there's sort of this thing of like, oh, wait a second. Not only are we learning the technique of design and development, but we're also trying to figure out how do we handle this process at scale, because it's not working the same way that our physical goods work or our other services work.

Josh Clark [00:08:03]:

And I would say also that a lot of the models that they tried to follow and bring in were sort of agency models, which are, frankly, not tuned for internal models. The incentives for agencies are often totally at ods from what the client company wants to do. And sort of trying to bring that in house actually creates problems and bad process and poor incentives.

Chris Strahl [00:08:27]:

Absolutely. I think it's interesting you say that as somebody that ostensibly runs an agency, the idea of how you take these problems that exist at a scale that organizations had never felt before. So my ecosystem has exploded. It's ten times the size it used to be. I have all these investments in design and engineering as a company that probably that's not your core competency. I mean, all of these organizations were investing really heavily in these digital experiences. Those digital experiences, from a consumer standpoint, have to feel like an iPhone app, not like the things that you're used to building. And all of that kind of coalesces around this idea of how do I solve this? And to me, it really came down to two fundamental pieces.

Chris Strahl [00:09:13]:

It came down to this idea of how do we solve this problem of people working together at scale, and how do we solve this problem of the proliferation of tooling and process across an organization. And when I talk about the former, I think about this as, like, when you have five products, you can kind of hire, like, one program manager, and that person could kind of hold in their head or in a Jira board all the things they need to think about that harmonize those product experiences. But when that's 500 products, that's impossible. That's dozens of project managers or program managers. That's a department. That's an entire set of resources that are dedicated to solving a problem at scale. That then creates its own problem of scale within that team or department. And then likewise, the tools that we reach for and the processes that we reach for kind of building on your point about people adopted an agency model internally is because that was the process they knew.

Chris Strahl [00:10:08]:

Likewise, the tools that we've all known and grown up with even vs. Code, GitHub, et cetera. But even things like Figma, it starts to break down. When you reach a certain scale where if you don't have a system that helps you control and engender trust in the way that things are changing, it all starts to break down. And this is the most exciting thing to talk about because we're now at this point where everybody's broke everything, right? So how do we fix it?

Josh Clark [00:10:34]:

One is just an observation that I think that sort of like the people and process and the tooling, it's really important. And that I think a lot of people try to put tools in place where good people and communication can happen. So I think there's this one thing of, like, at scale, you got to have tools, you got to have automation to help amplify the power of humans. But we have to be careful not to replace kind of communication and just shared vision, which I think is so easily siloed in large organizations. So I think one of the things is finding ways to have actual human connection and shared vision among teams and disciplines is a huge part of this. I think one other thing, too, as we think about tools, is design. Systems are tools, right? They're sort of like, when done at its best, this really elegant symphony of tools brought together to help the entire organization make beautiful digital music. One of the things that we see, though, especially in large organizations, is that pockets of the organization have this great idea of having a design system, and the people are making a difference where they can in their local valley, but they're optimizing locally.

Josh Clark [00:11:39]:

And then what we see in some places when companies come to us know. Josh, Brad, we've got six design systems now. We have six enterprise sized design systems, and now they conflict with each other. We aren't sure what to use, what's the best practice. And now we have consistency in terms of trying to solve these problems of efficiency and consistency. We now have created a new meta level of that by building and maintaining multiple design systems. So I think people want to solve these problems, and we see really good attempts at it within the sphere that they have. But what it suggests is that this is no longer a team issue, but a leadership issue, and that we need companies who say, you know what, we are serious about our digital process.

Josh Clark [00:12:24]:

We have made this investment. It has gotten messy because we've moved quickly and we haven't had the discipline or experience to do it. We now need to have a concerted effort to make this happen, and I think doing that in the context of lean budgets means that that sort of persuasion and explanation to sort of get the attention of leadership around this stuff is more important than ever. And I think that often the designers and developers who are leading design systems aren't necessarily well equipped in the language of finance and in the language of value to actually make that case.

Chris Strahl [00:13:09]:

I think that the big thing that gets me excited about this, right, is you talk to designers, engineers, product people that are working with these design systems every single day, and oftentimes they talk about how can I just get to the next incremental level of improvement, whatever that looks like, right? Like a better UI kit or a better implementation of MUI or any number of other things that could exist inside of my design system ecosystem. But the absent thing is the justification for what is the meaning behind that inside of leadership. And I completely agree with you, and I talked about this a little bit at clarity for the panel discussion. There is that the biggest barrier to design systems adoption across our entire industry is getting the people that are making the strategic decisions to recognize the value and the strategic importance of these systems. And without that, this industry starts to get real small, real quick, and it kind of has this failure to launch.

Josh Clark [00:14:04]:

Right.

Chris Strahl [00:14:04]:

I think that we're at this inflection point where there's no longer a blank check in design and engineering to invest in stuff like this. So how do we take the investments that we've made in systems and show how meaningful and valuable they are? And I think that you're uniquely positioned to understand how you think about a design system. Practice is an ongoing set of improvements that are strategically relevant to a big company.

Josh Clark [00:14:30]:

I think one of the things is that the most dangerous label that a design system and its team can get is that it is kind of an operational tool, that it's the kind of thing of like, oh, you're making a thing that will help designers work a little faster or developers have their jobs be a little more convenient. That is a problem in a few different ways, is that it sounds temporary. It sounds like it's kind of like, I don't know, we're kind of improving some ergonomics for designers and developers, which is nice for them, but not critical. Once you sort of start to understand a design system as critical front end infrastructure in the same way that you might think of as your payment processing infrastructure that you think of as your GitHub subscription and account, then it's like, oh, wait a second, this is actually a critical part of our products that we're doing. But it's also more than just an asset. It's like, one of the things that I've been thinking about a lot lately is high performing teams have design systems, but having a design system doesn't make you a high performing team. There's this whole thing of like, it is a critical part of the process that you need to make to follow great, well considered product, which is, let's capture our best work in one place. Let's capture and curate our best practices and our standards so that not only do people know what to do and they can take this stuff forward and it's convenient and easy to grab a solution, but it's also tested and proven solutions that we're moving forward.

Josh Clark [00:16:07]:

That's a whole other topic of sort of like, curating patterns rather than inventing them, which I think is a really important distinction.

Chris Strahl [00:16:14]:

There's the axiom there of having a great design system. Great teams have great design systems.

Josh Clark [00:16:20]:

Right?

Chris Strahl [00:16:21]:

That simple fact, I think, is absolutely true in this industry. If you're a world leading company, you probably have a design system, and it's probably pretty good and pretty mature if you're trying to figure out how to become a world leading company. Like, a design system is a great step, but that doesn't mean that you're just, like, grabbing material off the shelf and implementing inside of your products. That means that there's a thorough, reasoned process that's gone on inside of your organization that has understood that they're making an investment in an infrastructure. And I think that how companies make that investment is a really interesting area to explore, especially in today's environment. When we think about, like, all right, the danger is operational spend, right? Like, this is some temporary thing that we're using to boost morale or spirits. Right. It's the design equivalent of a shot in the arm.

Chris Strahl [00:17:13]:

But the reality is, it's much different than that. And when you think about how companies invest in infrastructure, I'm curious, your take on where this spend comes from and how strategic budget holders, the people with the pockets, think about this spend.

Josh Clark [00:17:28]:

Yeah. There's this really important accounting distinction between capital expenditure and operating expenditure. There's shorthand for it. Capex and Opex. And it's important because it affects how stuff goes down on the budget. So capital expenditures is in the classic sense. It's like, oh, we're building a new building. We're buying this new machinery.

Josh Clark [00:17:50]:

We're making stuff. And in software, it's, we're making new products. We're actually putting something new into the world. Operating expenses are about maintenance, are about keeping things running, are about hiring the person who is going to run the machine, about the person who's going to keep the machine fixed when it's breaking. And those things are immediate expenses. Okay, great, fine. But it's all money, right? It turns out that it's important, because when you buy that new machine or you launch that new software, the total value of that becomes an asset on your balance sheet, and you're able to amortize the expenses. So I spent, whatever, a million dollars for this machine or for this piece of software.

Josh Clark [00:18:35]:

I can now say I have a million dollar asset, but I can put my expenses out over the next five years in accounting. Speak, say this has a valuable life of five years. So I'm so sorry to all of your listeners to be talking about accounting, but it's important for making the case, because what one thing is this year, in a lean year, I've suddenly got a million dollar asset with $200,000 of expenses. So I've got $800,000 on my balance sheet now versus, oh, I've just spent a million dollars this year. That's how it looks on paper. It's like, I have $800,000 more on my balance sheet this year. Because this is a capital expense and not an operating expense. And that's real.

Josh Clark [00:19:20]:

It's real in the sense that it matters, and it's important to the people who make these decisions. It's not real in the sense that either way, you spent a million dollars and you've got this thing. But the way that you claim it as an expense is super important. And what that means is that people who are making design systems have to put themselves in a thing of, like, this is more than an operating expense. This is more than maintenance. This is actually materially and immediately contributing to new product. This is a capital expenditure. We are making new things and constantly putting things into it, which means we need to show that the design system is actually moving our roadmap projects forward.

Josh Clark [00:20:00]:

Right now, it's not sort of some abstract thing that's off to the side. It is directly involved in contributing to these products. And so I think that that's like, one thing in lean times, is demonstrate and make the case that this is a capital expense, not an operating expense.

Chris Strahl [00:20:17]:

It's interesting, right? Because the idea of how is this infrastructure, and without diving deeply into the CFO conversation about SaaS software and various.

Josh Clark [00:20:27]:

Other things complicated, how does actual process fit into all this? Yeah, right.

Chris Strahl [00:20:31]:

Yeah. The idea of where this spend comes from, the core thing to hone in on is what is the strategic value of the content and capability that goes into it.

Josh Clark [00:20:43]:

Right?

Chris Strahl [00:20:43]:

You mentioned GitHub, right? So your git provider, whether it's GitHub, GitLab, BitBucket, whatever, right? The reason why that's a capital expenditure is because the thing that you put into it has value. And that I think is very similar with the design system.

Josh Clark [00:20:57]:

Right?

Chris Strahl [00:20:57]:

It's not like I built this really amazing CMS that houses my documentation, or it's not like I built out this really great way of managing my components. It's the actual components themselves and the actual docs themselves that has the value, not the wrapper around it. And I think that that's really important to think about when you're talking about how you advocate for your design systems project is it's the application of those things into your products. And this is where a design systems product really breaks down for me is there are fundamentally different measures of success for products than there are for infrastructure and capital expenditure. And so when you think about where this lands, you can basically say, hey, that single component that I created that is now reusable across my entire ecosystem, that's a strategic asset that has some sort of measurable value. And it's not the thing that it took me to get to build that component. It's that that component exists somewhere in an ecosystem that is a shippable thing. And that to me is like, where all of this power that we're not really good at talking about lives inside of design systems and systems thinking for products.

Josh Clark [00:22:06]:

Yeah, no, that's great. I think it's really easy to fall into what frankly, is a trap when you care about design systems, when you care about this type of work, to think that it is almost the end in itself and it is just demonstrably not the only thing that really matters about the work that we do. And certainly what the businesses care about is like, what actually gets built and presented to customers and what happens next. And so everything that we need to do has to be thinking about how can we best support the best kind of product delivery. And at that level, kind of what leadership cares is really only about three things. How are we making money, how are we saving money, and how are we attracting new customers, and maybe how are we preventing customers from leaving as sort of part a subset there? And it's like, that's the story to tell. And I think design systems have a great story to tell there. That actually investing in design systems as a capital project also means that you're going to do better on all those things.

Josh Clark [00:23:09]:

I mean, if the design system is working well and it's more than just having the assets, it's having good process and really using that system in a really productive and healthy way, which is easier said than done. But if you've got that, you're going to get those products to market faster. It's like, great, we're making more money now. We're saving money because we're able to do more with less. And that's a mantra that we're going to be hearing a lot over the next year. And that a lot of people, unfortunately, have already been hearing at companies is we have to do more with less, but we're saving money as well. And it's like we're getting to market faster so we can make money sooner and we're spending less money, less resources, less time to get there. And when done well, a design system, as I mentioned earlier, is this library of solved problems.

Josh Clark [00:23:57]:

It's like all of our best work captured in a place for reuse, so that the experience is going to be better. It means that we're not building everything for the first time. It's been fixed and vetted and fussed over through multiple iterations. It works and it's proven. And I think that that's also another trap. That's easy for design system folks to turn into, especially for new systems, is we're going to build the new way that we do stuff. And it's not a good place for design systems to do innovation and create experiments and new exploration, except for at the very edges, in the smallest ways. That's for product to do.

Josh Clark [00:24:34]:

It's like the product team should go out there, try crazy new stuff where it makes sense, prove it out, and if it's proven, bring it into the system so we can do more of that. But it's like only prove those sort of proven things into the system. That's really important. It's a curator role of best practices and making sure that we keep doing the things we do best even more in the future.

Chris Strahl [00:24:57]:

I love the way you talk about it. I think that I agree so wholeheartedly about this idea of how we should be presenting these systems as a value driver across better, faster and cheaper simultaneously. And that's a kind of cliche adage of like better, faster, cheaper. But the reality is there's a support business case to be made for all three of those things. To leadership that really does care about this stuff. And is ultimately the one that holds budget for it. And when you think about that better, faster, cheaper story, if you're inside of an organization and you're trying to sell this up the chain, picking one of those to really focus on, but then talking about the other two is a really great way of starting to get buy in for stuff like this. And it's kind of like aligning it to what your organization cares about at that moment, right? If it's better to get new customers, if it's faster to get to market quicker, if it's cheaper to save on costs, I think that what's been interesting is to see that cheaper side of the conversation start to get pretty loud lately.

Chris Strahl [00:26:00]:

But then, moreover, once you actually have this thing in place, how do you represent that value as something that is about repeatability and about automation and not necessarily about innovation value? Because I definitely see this, and this is an interesting thing that we can explore for a minute here, is like we're talking about changing the way we work, and we talk about changing the way we work. We say like, hey, there's this system that has this automation. It has this intrinsic value. It's this asset. And the reason why this asset works is that better, faster, cheaper story for all the products in our ecosystem. But then there's also this innovation side of it, too, that we still need, right? We still need new things. And having that domain of product be where that innovation happens, I think that becomes a much more natural division in the way we think about the design and code paradigm than it is about like, we need design system designers and design system engineers and UX engineers and all these different titlings that are somewhat nonsensical. The reality is that there's a place for innovation and a place for the automation and systems work.

Chris Strahl [00:27:06]:

And that, to me, feels like where those job duties start to tease each other apart a little bit.

Josh Clark [00:27:13]:

I love that. I see this all the time, is this conflation with the role of the design system as being kind of a production shop for product. And when you conflate that, when you sort of say, oh, this is just sort of like part of the product work, they're going to build components for us and it's going to be awesome, that's part of the story. But when you start to say it's like, oh, no, they should be sort of like working at the same speed. They just work with a different mission. Because one is an infrastructure layer and one is a product layer, and it's those things that sort of, it can look like a design system is failing when you have the expectation that it's going to be working at the same speed of product, of churning out sort of brand new kind of components, new innovations all the time. And really what it's supposed to be doing is almost working behind product. So that product is kind of the first draft of history, and the design system team captures that and encodes the stuff that works into best practices.

Josh Clark [00:28:11]:

But a lot of this, too, is, I'm sort of talking about this. One of the things that we work most closely with companies for, because they've often failed to do it on their own, is to actually realize the benefits of this stuff because they've created a pile of components, they've created the assets, and that's becoming more and more clear how to do that. Well, there's like the technical, tactical part of it, there's a lot of expertise around that. But actually getting it to sort of work at that, sort of like the pace that you create that infrastructure layer and those components, how do you negotiate that with a much faster product roadmap pace? How do you make that work together? How do you set the right expectations and how do you get adoption? How do you actually get that contribution model so that product teams are able to contribute their incomplete first draft versions of those components to the design system where they can be completed? All that stuff is so hard, and if you get it wrong, feels frustrating, and it seems like the gears start grinding, and so it's really easy. So this is essentially what I was talking about, about high performing teams having design systems. But design systems not necessarily making you a high performing team, is you have to become a high performing team to get all of the benefits that you're going to get out of a system. And I think that that's part of it is recognizing we can build it, but it takes time and care and leadership to make the thing actually work at its best. You're always going to get some benefit from it at some level, but you're not going to get the exponential benefits that you can get from design systems without having the right process in place.

Chris Strahl [00:29:54]:

Yeah, absolutely. I mean, there's benefit in a well structured figma file. There's benefit in well organized code. But being able to actually call that a system that lots of people that weren't the ones that built the thing ultimately end up consuming it and using it, that's a lot harder. And I think that that's like the value that you're talking about unlocking. I also think there's a lot of interesting ideas about how new forms of automation can fit in here and new possibilities that these systems enable. My co founder, Evan, is very fond of know design systems are the boring part. Like standing up.

Chris Strahl [00:30:24]:

The system is really hard and really important. But once that system is in place and the people know how to use it, there's so much possibility of unlocks that go well beyond just design systems. We're human beings, right? We have this penchant for standing on the shoulders of giants.

Josh Clark [00:30:41]:

Right?

Chris Strahl [00:30:41]:

Like building from a foundation. The importance of a design system, in my mind, is the ability to create that foundation that you can then do a lot of really interesting things.

Josh Clark [00:30:50]:

From.

Chris Strahl [00:30:51]:

Where is it that you see some of these really interesting new possibilities coming from?

Josh Clark [00:30:57]:

Yeah, Chris, I'm so sorry, but now we have to open the AI chapter of our conversation.

Chris Strahl [00:31:03]:

It's inevitable.

Josh Clark [00:31:06]:

We have to talk about AI. And maybe, I mean, I think it's clear that sort of the big next exciting generation of this stuff is how does AI and machine learning help us with this? And if you come back to sort of what the basics of design system are at its most fundamental level, it's kind of creating a shared vocabulary around what we call components, around how components are used, around design and development, so that everybody sort of knows either instinctively or from a really easy reference to the system, what the right thing to do is, so that they can move quickly and solve new problems instead of old ones. I think one of the exciting things is that the robots are learning all the weird ways that we communicate, not just in language, but in visuals and in writing and speech, and just sort of like all the stuff that used to be totally impenetrable to the machines, if it wasn't in ASCII text, and if we've been sort of like spending the last decade or so with design systems, trying to help teach humans that vocabulary. And now the machines are coming right up behind us, and they can share in that, too. And as we've seen with some of the richness of kind of some of this text based AI and generative AI lately, the machines can have really kind of subtle insights and be able to really put things together really quickly from familiar patterns or great mimics. And so I think one of the great opportunities that we've been exploring a lot with our own internal AI system, which we call Dr. Frank, our developer, Kevin Coyle, has put together Dr. Frank, which we teach it all kinds of things and ask it to do all kinds of stuff, not least build components, write tests, assemble pages, and I would say that some of the lower order stuff, building components and assembling tests in our style and using our conventions is great.

Josh Clark [00:33:01]:

And I think know assembling some pages is not a bad first pass. But I think one of the exciting things too, that Kevin has been really great at exploring has been how do you use it to sort of bridge the gap among disciplines to explain what the system is for. For any of us who have played with Chat GPT and sort of used the explain it to me like I was five example is super useful. But also explain it to me like I'm a product owner, explain it to me like I'm a developer who just joined, is that we've had really interesting, lovely explanations of components or aspects of the system that the machines are able to digest and deliver to us much better than a single static version of documentation, which I think is really exciting. It's like, oh, how can we help the machines help us to understand better, not just generate and write things, but to interpret and share, which I think is really an exciting element of this. As we think about how do we collaborate and have a shared vision better that it's like actually, oh, the machines may actually be able to be really good at some of that interstitial stuff.

Chris Strahl [00:34:14]:

What's funny is you're talking about storytelling, right? That's what that fundamentally is, right? The fact that we have an AI and a robot that now can tell us a story from a point of view that we can actually understand, that's where that power in that interstitial space is. Is that a creation of common understanding that we end up blocked on as humans for whatever reason. Either we're too close to our own discipline, or we can't frame it in a way that somebody else is going to understand, but that bridging the gap and understanding is about the machines being able to tell the right stories. And I think that's such a powerful concept in this. And it's less about how do I generate a bit of react code from a visual design, and a lot more about how do I understand why the system is important and how the system derives meaning for any particular person that could get value or use out of it. I love that vision. I think that that's something that I'm going to start talking about a lot, is this idea of the robots are there not necessarily to do the work, but to help us be better at understanding why the work is important?

Josh Clark [00:35:16]:

I think that's really well said. I think one of the things about machine learning about AI is that the opportunity here is to let people do what they do best, discover new problems, discover new stuff, make connections and communicate and care about one another, and let the machines do what they do best. What the humans do best and machines do best are rarely the same thing, almost never. So I think if we can kind of think about where can we put the robots into the places that we struggle at repetitive, high scale, detailed work so that we can focus on the stuff that we do best, that's really exciting to me. So I think one of the things, too here is also, as we think about what those complementary activities are, one is these things is sort of interpretation and sharing. There's certainly kind of some of the grunt work stuff that tends to be error prone for humans, that the robots can do great and effortlessly and with no problem. I think that there's also this opportunity where the robots can not just help to explain stuff to us, but also to kind of coach us or to review the work that we do. So I think a lot of the emphasis right now is on, oh, look at what the robots can make.

Josh Clark [00:36:37]:

But I think what they can also do is to take a look and evaluate and compare our work to other things and call out where, according to that benchmark, this could be improved or changed or things that are missing. It's like my daughter had graduated from college this year and in her last year of taking some computer science classes, in the year that Chat GPT came out, it wasn't hey, Chat GPT, write this function for me. It was, hey, Chat GPT, why is my function breaking? And it was like, oh, try this, this and this. And it was like this sort of thing of like, oh, here's something that's now looking out for me and helping me and not replacing my work, but actually making it better so that I can figure out what the problem is. And it's helping me kind of craft the solution in the most efficient way.

Chris Strahl [00:37:23]:

Well, and it can also hold a context that is at least somewhat unique to you.

Josh Clark [00:37:28]:

Right.

Chris Strahl [00:37:28]:

It's funny, during the course of this conversation, I typed into copilot, why do I like Taylor Swift? So that we can at least make sure we're covering both the relevant.

Josh Clark [00:37:38]:

Thank you.

Chris Strahl [00:37:40]:

And I mean, it's still going. It's definitely telling me a lot of the reasons why I personally would like Taylor Swift.

Josh Clark [00:37:45]:

That's awesome.

Chris Strahl [00:37:45]:

The number one thing for me was Easter eggs and surprises in her songwriting lyrics, which is pretty on brand for me.

Josh Clark [00:37:52]:

I think that's the thing, is the machines will run in whatever direction we point them in. And I think it's like, what incentive do we want to give? You know, this kind of comes back to agencies, too. I know I sort of had made sort of this remark about how kind of agency models don't work within large companies. And you mentioned, it's like, oh, you're a guy who runs an agency. And it's true. I think one of the things that we've been trying to do as we think about agencies, what it means to be an agency to help folks like this with things like this and to add value there is that what we really don't want to do is make our clients dependent on us. Our whole reason for being is we want to make our skills, their skills, so that they can go and internalize this stuff and move forward. And that is not a typical agency role.

Josh Clark [00:38:39]:

Most agencies are trying to get long term contracts. They want to create the dependency and put as many heads in the door as possible. And so right now, as we think about this digital strategy in lean times and thinking about doing more with less, I think one of the things that I would be thinking of as a leader is where are my agencies taking me? It's like, where are the robots taking us? But also where are my agents leading me? Because it's like their incentives are not strictly aligned with what I want. And so as we think about kind of coming back to this idea of what is value in tough times, one of them is making sure that anything new that you're building is likely to hit. Or maybe you've got a big swing that you're going to take a risk, but you don't want to have a ton of those. And you also want to sort of have this reliable set of functions. So design systems are good at that, right. It's like we've figured out what works.

Josh Clark [00:39:33]:

We've put it into the system. We can sort of repeat that activity. But you sort of want to limit brand new, big swings, uncertain things in a bit. You want to be really careful and intentional about that. Agencies generally understand themselves as hiring to do something novel that it's sort of like, oh, I'm here to build something new, things that often tend to break or challenge systems. Actually, a lot of times, agencies rarely care about the design systems that companies have. And I don't want to paint too broad a brush, but tend to break existing systems in the effort to make something new. And I think one of the things that we think a lot about is how do you capitalize on the value that you've already created.

Josh Clark [00:40:14]:

And again, that's sort of what design systems are about. It's like, yeah, let's encode that. Let's figure out how to do more with less. Let's figure out how to fix our process so that we're getting to market faster, doing more with less, improving stuff for our customers. I think that that's stuff that is like, oh, that investment comes back to you really quickly again, especially if you can capitalize on it. But I think part of this is, yeah, it's, where are we headed? What are the incentives that we want to do, and who are we working with? Whether they're robots, employees, or partners, how are we making sure that their incentives are aligned with what we care about? Which right now is, I think, a little bit of a skin, flinty, cheap, skate tight with the budget, look at things. And I think it behooves all of us as designers and developers to really be careful and thoughtful about the degree that our actions support those realities and the case that we make for it.

Chris Strahl [00:41:12]:

Josh, that was awesome. I really appreciate you being on today. Thank you so much for the time. It was a really wonderful conversation, and let's chat again soon.

Josh Clark [00:41:20]:

Yeah, let's do it. Chris, that was fun. Thanks.

Chris Strahl [00:41:23]:

This has been the design systems podcast. I'm your host, Chris Strahl, signing off. Have a great day, everyone. That's all for today.

Chris Strahl [00:41:29]:

This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter at @theDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.

Get started

See how Knapsack helps you reach your design system goals.

Get started

See how Knapsack makes design system management easy.