On Theme: Design Systems in Depth

The Four Quadrants of Design System Impact, with Ben Callahan — #14

• Elyse Holladay • Season 1 • Episode 14

Share episode

📲 Text the show your thoughts!

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

Ben Callahan joins Elyse for a fun conversation on creating impact with design systems. Ben shares insights from his consulting experience, discussing common pitfalls like organizations expecting a design system without adequately supporting their teams. They break down the "Four Quadrants of Design System Impact" framework, which breaks down tactical versus strategic work, helping teams avoid pitfalls like endless component creation. Plus, hear Ben’s predictions for the future of design systems


Links & References


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

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

Ben Callahan:

It's easy to actually look at the theoretical potential a system can give an organization, right? All the conversations you've had, efficiencies and accessibilities and consistency and all that, right? That's actually very easy, selling pitch to make. The reality though, is that you are going to every single team that is working on product inside of an organization, you're asking them to change how they work. If you go look at a product designer role, do you ask that person to go sell the concept of the entire, like underpinnings of how they're doing the work, to the rest of the organization? No, you don't ask that of them, right? They have a boss. They have a whole hierarchy of leadership that is in charge of having those hard conversations, and figuring out how the budget's gonna be split, and opting to prioritize this kind of work. This is what I mean when I say, organizations don't know how to support these teams.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today's guest is Ben Callahan. Ben is the founder of agency Sparkbox, and host of The Question, which is a weekly collaborative learning experiment for design system nerds, and one of my favorite things in the design system space right now. He's a design system researcher, coach, and consultant, whose personal motto is, stay in learning mode. Ben, super happy to have you on the show,'cause I'm really into our topic, I know this has been my personal soapbox, to talk about impact, and to talk about how the design system space needs to evolve. Thanks for coming on the show with me.

Ben Callahan:

My pleasure. Thanks so much for the invite.

Elyse:

Oh, of course. I couldn't leave you out. I know a lot of people who know me, know you, and are involved in The Question, but for those listeners who are not, tell us a little bit about what The Question is, and how that even got started.

Ben Callahan:

Yeah, absolutely, so I remember thinking, I had a question about systems that I just wanted to try and figure out, this is like a normal day, one of my clients is struggling with something, I'm like, oh, I wonder how other people are doing this? So I went out to Google and I'm sitting there typing in my search and looking for, looking for other systems and digging through their doc sites, trying to find answers. It just hit me one day, like, how cool would it be if I had this giant megaphone and I could just ask the question, you know, to a bunch of design system practitioners. And I, I thought, how would you do that? And would other people find value in that? And so that's evolved into what is now The Question. We started with about 50 people, and now we send a question out every Monday to almost 750 folks, who are all design system practitioners, who are just passionate about systems thinking, and the space, and then they get basically 48 hours to answer. The question comes out on Monday, if you answer by Wednesday, you get an invite to the deep dive on Thursday. And so every week is like a little mini research project. We ask two or three questions. I have a co-host– you've been my co-host Elyse, and it was a wonderful conversation— and we come up with that question together. And then it's always design system related and it's just, really a chance for everybody to broaden their perspectives on a really specific topic in the systems space. So it's a lot of fun.

Elyse:

It is a lot of fun. And if you haven't come to one, I highly recommend getting on the email list and coming to one, because— I'm a team of one, I know that's not true for everybody, there's just lots of people with design system teams— but even so, a design system team is a relatively small group inside a larger org, always. And the things that you're doing, you can be very much in a bubble, or very much isolated. And it's so easy to look at what other people are doing, and see their Medium posts or their celebratory LinkedIn post, and you just see like the shiny highlight reel version. And you don't have anybody else to go to, to say, how are you doing this? Like how did you approach this problem? Surely I am not the first team to have ever struggled with X. But who do I ask? So it's really neat to be able to engage with other design system practitioners in that way.

Ben Callahan:

Yeah, I think that's really true. It is a lonely job. And beyond even just the isolation, inside of an organization, that these teams sometimes feel, I also think that companies don't quite know how to take care of these teams yet. It's like they have these expanding responsibilities— we may talk about this a little bit. We've had sessions on The Question where we talk about, is it our job as systems practitioners, to train these other people who are consumers of the assets we give— do we have to train them on how to use the tools? Right? Like, is that our job or should that be their job? And that's one tiny example. There's hundreds of those. You know, the responsibilities bleed in, into other parts of the org in a lot of ways. So I think having a community like that where folks do have that shared understanding of what it's like, has been, it's been really helpful for me. I've learned so much and I've met so many amazing folks.

Elyse:

Yeah. Let's put a pin in this sort of like scope and ownership question. I wanna come back to that. But before that, what are you seeing around companies being able or not able to support their design system teams and practitioners? Because you work for Sparkbox, y'all are consultants, you're going and you're getting to see lots and lots of different design systems on lots of different companies. Which is a very different experience than being in-house in a team. So I'm curious, what is your consultant view? You know, being able to come into all these different organizations and see how things are set up. What are you seeing in terms of how teams are being set up in 2025? What are you seeing in terms of how companies are supporting their teams or not supporting their teams?

Ben Callahan:

Yeah, this is like a really interesting area. I, one of my customers said something to me this week that has stuck in my head all week. We were having a conversation about what's working and what's not working with their system. And they said to me, after some deep thought, they said, I think we want to have a design system, but we don't want to have a design system team.

Elyse:

Ooh.

Ben Callahan:

And I was like, wait, really? Like, let me think about that. I know, right? Well, I think that sentiment is something that I feel in a lot of these situations where it's like, everybody it's easy to actually look at the sort of theoretical potential a system can give an organization, right? Like, if we just stop using all these colors, we could consolidate. If we just did, the button, the, all the conversations you've had, efficiencies and accessibilities and consistency and all that, right? That's an very, actually, very easy, selling pitch to make. The reality though, is that you are going to every single team that is working on product inside of an organization, you're asking them to change how they work. And so when you get into it, the muck of this work, it is literally just, it's waist deep mud of like people's baggage that you have to move through. And I think organizations get excited about those benefits. And you get into the work and you realize, wow, there's a lot of opinions, there's a lot of ideas, there's a lot of momentum around certain tech stacks, and reasons that nobody really understands the why we've chosen to do the things we're doing the way we are doing them. And so all of that change is just really hard.

Elyse:

And just simply the, the inertia of change. I've been saying that design system work is organizational behavior change and that is muddy and sticky and messy and hard, even in an organization that actually wants all of that change.

Ben Callahan:

Yeah.

Elyse:

And not all of them do.

Ben Callahan:

Yeah, you're so right, and that's what, where my head is too. Like, I'm reading these books on like, how to create change in organizations. This is Kotter's book on Leading Change, some people would call it the Penguin book. It's like a pretty well-known book on organizational change. I'm fascinated with that part of the work. And I think that we have spent the last 10 years as an industry really codifying the tactical implementation stuff. And that stuff, you know, we're getting good at that. I think there's still lots of interesting areas for work to be done there, but I think you could easily look at that and say, yeah, there's three or four different approaches that teams take with this work. And let's pick one and then let's, and then let's get to the hard work, which is like actually getting the org to want to use it.

Elyse:

Yeah. What would you say to, or what do you say,'cause I imagine you encounter teams and people on design system teams who feel this way: I wanna work on the system, I wanna work on the tactical stuff. I wanna build the thing. I'm really excited about components and, you know, setting up the perfect system and like the perfect token architecture and just getting it right, like, I don't wanna be selling, I don't wanna have to come up with metrics to talk to my leadership. I don't wanna do all of this. What do you say to them?

Ben Callahan:

Yes. Elyse, you said, let's put a pin in the scope conversation, and then you asked me this question, which is basically like reopening that, right? Because I mean, if you go look at a product designer role, do you ask that person to go sell the concept of the entire, like underpinnings of how they're doing the work, to the rest of the organization? No, you don't ask that of them, right? They have a boss. They have a whole hierarchy of leadership that is in charge of having those hard conversations, and figuring out how the budget's gonna be split, and like opting to prioritize this kind of work. This is what I mean when I say, organizations don't know how to support these teams, right? Like it's a team that just gets stuck underneath Design or Product or UX or Engineering, and they just are like, okay, fix all of the inconsistencies and do that for all the products. And it's like—

Elyse:

No problem.

Ben Callahan:

Hold on a second, you know? So, yeah, I mean, I think everybody's, some people love that stuff and some people don't. And some people are good at it and hate it, and I think it's just, this is where balancing your team with folks who— somebody has to do that, right? So if nobody's gonna do that work, then it's, I might even just say it's not even worth doing a full on design system if you don't have somebody who's gonna tackle that problem with you.

Elyse:

Yeah. I totally agree. I've been thinking a lot and in, in previous episodes I've talked about this idea of what is a design system in, you know, this Year of Our Lord 2025. It's like, this is how we build UI now. We're solving really different problems than we were solving a decade ago with design systems. So I know we're like, okay, we're not gonna talk about the scope question, now we're gonna talk about the scope question. It feels in some ways, like we've come full circle, where now the thing that we're trying to do is, okay, how do you organize engineers and designers to actually ship something. The tools have just changed all underneath us, but are we still solving the exact same problem that we were solving, like this whole time?

Ben Callahan:

Well, like what you're getting at there is, again, I was on a call today with another design system person from Dublin, and he was telling me like, our system is great. Our system is amazing. But we just can't get designers and developers to work well together. And I was like, oh my gosh. That's like the problem. That's the problem before systems ever existed, before responsive was a thing, before web standards a thing, that's the problem. It's like the age old problem.

Elyse:

Do you think this is why we're having all of the broken promises of design systems conversations? Do you think that's where that's coming from?

Ben Callahan:

I I mean, maybe, you know, I think it's like, this is a problem that's never gonna go away as long as we separate these people, and that's, just like, we do. We separate them. They're organizationally separate. And I remember when we first started Sparkbox, I said, I don't want that problem to exist in our culture. And so— this was maybe not the best solution— but everybody on my team was called developer. Because at the end of the day, we all shipped products. And so we had designers, we had UXers, we had researchers, we had front enders, we had back enders, and they were all just developer. And I think that didn't work for us long term, there's lots of other reasons career-wise why that's not a good idea, right? Yeah. Titles and all that stuff. But, but the underlying, feeling behind that is like, I don't want you, I don't wanna just pigeonhole you into one thing. I want you to think about the whole spectrum of what needs done and recognize every decision you make impacts all these other people. And we can't just do that work in isolation. That's just not how it works. So yeah, it's a lot, a lot of problems to solve there still. And I wish we would focus on those a little bit more.

Elyse:

Yeah. Well, turns out those things are hard.

Ben Callahan:

They are.

Elyse:

But well, yeah, but when you work with clients, who engage you and Sparkbox to come in and work on their design system with them, what are you seeing in the ways that they set up their design system teams and support their design system practitioners? Because I think the complaint, the last couple of years in design systems has been, exactly this. It's like, well, we set up the tools, but nobody wants to adopt it. Or we set up the tools and, we still can't have, we still have good design and engineering collaboration. Or we promise the org, efficiency and cost savings and this, that and the other thing. And then, you know, our execs are like, you didn't deliver on that, and laying off the teams. What are you seeing inside, inside organizations right now?

Ben Callahan:

Yeah, all the things you just said are definitely very real in all the organizations that I interact with. And not even just the ones that we work with at Sparkbox, but I just do, I'm a curious guy, so I just do a lot of conversations with folks, not that I'm working with in any capacity, I just kinda reach out to people and I'm like, Hey, can we talk? I want to hear what you're doing. And so I have had hundreds of those conversations and everybody is struggling with all the things you just said. I think, one, one area that especially is hard is the— and this is like a thing that's been in the space for a while as a problem— but this idea of a full stack developer. And especially in this moment, no developers want to be pigeonholed into one part of the stack. And so everybody wants full stack on their resume, so they want that on their title. And in practice in most of the organizations that I have had conversations or done coaching or worked, that means they're a backend developer. And they don't wanna write HTML and CSS. And so that leaves this gap, you know, and in situations where that's the case in engineering, and the system itself is owned on the design side, that leaves this really big hole of front of the front end work that engineering doesn't have the ability to do well, and the design team would love to do it, but if they do, engineering won't accept it,'cause it's code that they didn't write. And it's just like, nobody acknowledges the importance of this layer of work. And that is actually the role that sits between design and development. These are the folks building the thing the users touch. And they're the ones that actually have the ability to speak the language of both of those groups. And I think removing them from the org in the way that we've done over the last couple years is really detrimental. It's taking us back, in terms of designer, developer collaboration.

Elyse:

Well, I'm here for the return of professional CSS person as a job.

Ben Callahan:

Yeah.

Elyse:

That was how I started my career. And I had seven or eight years of like, yes. that is what I do. I do the front of the front end. And, you know, it was a real burnout moment for me. I left tech around this time that React was really being adopted really heavily in organizations. Because I was looking at the future of my career going, I don't wanna move into the engineering career ladder, where I have to effectively become a backend engineer if I want to do enough work to get promoted.

Ben Callahan:

Yeah.

Elyse:

To a level where I feel like I can be effective at the things that I wanna be effective at, and nobody's gonna hire me to write CSS anymore. And the role that I have now makes me hopeful that is changing, and again, the kind of like coming full circle, I think we are maybe in some places starting to recognize that. And so anyway, I am totally here for that. I think there's a real depth of front of the front end work, that like turning design and experience into the real product that a lot of, whether you call'em full stack or backend or even like React, which in some, depending on what perspective you're coming from, all of React is the front end, like

Ben Callahan:

Yeah.

Elyse:

whatever you wanna call it. Most engineers that I have worked with, eh, 90% of them just don't wanna do that work. Not even

Ben Callahan:

Right.

Elyse:

Not interested.

Ben Callahan:

Yeah, I think that's true. And some organizations even see the system as a solution to that problem, right? They think, oh, we can just, you don't wanna write the code—

Elyse:

Replace our frontend engineers with a design system.

Ben Callahan:

That's right. Yeah. That's part of what I think has happened, you know. And that's a, I mean, that's not, that's not really the healthy perspective, I think. But that role is definitely a role that's needed on the system team. I think there's other, other things that are interesting or, you know, just kinda like, where is the system? Where does it live in the org? I think that makes such a huge impact on how it gets prioritized. I think, having organizations where they share the cost of the system work creates some really interesting, there's just so much nuance in all of this stuff.

Elyse:

It

Ben Callahan:

depends! Yeah. Yeah. It's so true. It's so true. Yeah.

Elyse:

It really, really is. So speaking of able to actually make impact with the system, right? We had an episode of The Question, where we got to talk about impact, what that actually means, how does a design system show impact in an organization?'cause this is, I would say the most pressing question in design system land right now, especially, post 2023 layoffs. There were lots of reasons for those layoffs, but there's no way to avoid the fact that design system teams were really, really heavily impacted. And I think in a lot of cases, if your organization is getting together and going, we just don't think that this is the most important thing to keep, when we have to cut cost, like, uh, we can complain about the layoffs and capitalism and, you know, greedy investors and all of that all day long. And the fact of the matter is that last year, last two years, somebody sitting in a room going, I don't think this team is the most important thing to keep. And my personal 2 cents on that, is that we have not been able to show, or I'm going to air quote the word,"prove" what the design system is actually doing for an organization. So like we've been saying, oh, I mean everybody just say it with me: efficiency, visual, consistency, like we all know the spiel. But how do we actually, again, air quotes,"prove" that? And how do we actually bring design systems back into a place where it's aligned with what the business is actually in need of and really, really valuing. Because, you were talking a minute ago about, can we replace front of the front end developers with a design system? Like, the answer is no! The answer is no. Somebody's still gotta build that UI.

Ben Callahan:

Yeah.

Elyse:

And so it's no wonder that— we are making these promises, we're talking about design systems in these like incredibly overblown terms, and then that's not the reality. So what is the reality of creating impact with the design system? So we had this episode of The Question where we got to talk about this. Give us a little recap of that and your thoughts on, how does an organization see value from design systems now?

Ben Callahan:

Yeah, I think, the questions that we asked in that session were really interesting. We asked a sort of a quantitative question. Basically, do you think that your design system team in this moment is doing the right work, the work they should be doing? And so we got some answers from that. And most folks, I think it was, maybe 60% something like that said that they did feel that was true. Then we said, what should the number one top priority for your design system be right now, and are you working on that? And so we got a bunch of really interesting answers there. And then we asked this one, which I loved, which is, what is your system team working on that you believe is not valuable? And then why are you working on it?

Elyse:

That was the interesting one for sure.

Ben Callahan:

Yeah, the raw data from this episode was really fun. The answer that really stood out to me that I think exemplified a lot of what I heard folks talking about in this episode was, they said, we have this focus of adding more and more components to the system. Like that's, that is the measure that we have of being successful as a system team. And this respondent said our current component coverage is really actually good. It covers almost all of our use cases, and we're at a point where if we add new components, it just has diminishing returns. And that idea just really got me thinking, Elyse, I started drawing all these pictures. I think I even came to that session with one idea of an image. But that evolved into lots of different diagrams that I was trying to use to show like, it's this idea of like 100% the system needs to do everything is just like such a myth. And in fact, it should be doing much less than that, you know? And so I think that is like this feeling, is like that sort of myth being busted in some ways. That's what I remember most from that episode.

Elyse:

Yeah, I remember that too. I remember some of the other answers to that last question being like, my CPO's pet project is what we're working on and we shouldn't be working on. I think there was a lot of, we're building components because this is the thing that our team gets judged on, but that's not actually the thing that the organization wants. And it was interesting to see the details of how that was coming out because it was different— I mean, again, it depends!— It was different for, all the specific cases were slightly different. But I was actually really intrigued, I, when I, when we put together those questions, I thought people were gonna answer to the first one, like, no, we're not working on the right things.

Ben Callahan:

Yeah.

Elyse:

And sometimes, I still kind of wonder if that's true because everybody was like, we're working on all these components, and I'm like, hmm, is that actually the thing

Ben Callahan:

that's right.

Elyse:

the most important thing for you to be working on?

Ben Callahan:

Yeah.

Elyse:

But it was interesting to see that in those latter questions around what do you think the valuable thing that you're not working on is, there was a lot of answers that were like, training, and like helping the product teams, and like the redesign and the, like, it was like all this other stuff, Yeah. to throw back to our earlier chat a few minutes ago. It was like all the parts that you actually have way less control over, and are much, much harder, are full influence work, and because that's how the design system gets used ultimately.

Ben Callahan:

Yeah. And a few years ago, Elyse, I did a bunch of work around like trying to understand how systems mature. What are the steps that every system goes through? And as a part of that work, one of the things I started to pick up on or see as a pattern in the organizations that were the most successful was, they split the work into three categories. I wrote them as three E's. So evolution was one, right, where it's like, yeah, we're building stuff. We're adding components. We're adding assets, we're writing documentation. All of that stuff that we have to do. We have to evolve the system. But the other two buckets were education and engagement. And education meaning like, Hey, it's not enough to give you this really fancy set of components to use. You also have to know how to use them well. And so we need to figure out how to, how to level you up in that area. And then also engagement was more like, Hey, uh, we don't know what to build, like we want to work with you to understand what would be valuable to you. And so I'm at the point now where I actually think those three things are critical. And it's probably about a third each, right? And I think most teams spend, you know, 98% of their time evolving the system and they, and then they leave a 1% for each of the other two. And I would love to see 33% on all of those. And it probably is not quite that, it's probably, seasons, we do more of one or than the other. But I feel like that would help us, to, to the engagement piece especially to just really dig in with these teams and understand what's, what's actually happening in their worlds. Make the system something they can't do their jobs without, right? That gets rid of adoption as a concern.

Elyse:

Yeah, yeah, yeah. I've been thinking a lot about what that actually looks like in real life. Because it's much easier to have some kind of metric or number around, number of components we made, number of components that teams are using, this adoption number, like either per team or like component coverage or percentage of teams code that's actually coming from the system or not. And like, that's all great, but how do you know that your system is actually changing the way that your designers and developers work? That's hard to put a number on.

Ben Callahan:

That's hard. Yeah, it's hard, and I think most organizations right now that I work with are doing that through things like sentiment. They're just asking, Hey, did we change the way you do your work? Yes or no? Is it better? You know, I mean, it's like so elementary, right?

Elyse:

Well, well we can laugh and we can say that it's really simple, but I think we have tried to make it really complicated. Maybe it in some ways, maybe it is that simple. I would say that one of the things that I'm most proud of over the first year of my tenure at Color was, in the first half of 2024, I worked with a couple of our engineers and we talked a lot about like CSS Grid and I was kinda like showing them some of the new ways that I would like to lay things out and you know, how we do that. And at the end of the year, I guess this was like November, December 2024, I saw that same developer— first of all, I saw them shipping their own CSS grid stuff, and then I saw them in somebody else's PR that I was not tagged in explaining how to use CSS grid, and how to set up like layouts a little bit better than we had been, in the way that I was proposing. Okay, fine, it's just like one anecdote, it's just one or two engineers. But that's behavior change, right? Like they stopped doing it one way and they can look at a mockup and now they're doing the mockup a different way. And I was not even in that loop.

Ben Callahan:

Mm. I love that.

Elyse:

And I don't know how to turn that into a number.

Ben Callahan:

Yeah.

Elyse:

Maybe I don't need to turn it into a number, but I'm just like, that's the kind of thing that I wanna see when I'm thinking about, what is the design system, that we're building our UI, how is that actually impacting the people who are using it?

Ben Callahan:

Yeah, and I, it's interesting because I think people have been for the last year or two saying, adoption's not the metric, we shouldn't be talking about adoption. Adoption doesn't matter, like all this stuff. And I just keep hearing that and I'm like, I understand the point they're trying to make, but it, could we not say that if the system—

Elyse:

doesn't matter.

Ben Callahan:

—if the system embodies like the best practices of our organization in terms of design and development, then adopting those practices is actually a, it's what you just described, right? What you described is an adoption metric. People are working following the patterns that the system has established.

Elyse:

Mm-hmm.

Ben Callahan:

That's like, that is actually really valuable and really important and I'm tired of people saying adoption doesn't matter. I just wanna say that.

Elyse:

Yeah. Well, you're not wrong. And I, here, here's what doesn't matter. A random number that you can game and just say— okay, we have a small org, we are in a monorepo, by some definitions of adoption, we have a hundred percent adoption.

Ben Callahan:

Yeah, everybody's, yeah.

Elyse:

Great. Everybody's using it. It's in the monorepo.,

Ben Callahan:

Yeah.

Elyse:

You can make that mean just about

Ben Callahan:

anything, and

Elyse:

I do agree with people being like that, that is a, not, it can be a nonsense metric.

Ben Callahan:

Yes, it absolutely can be.

Elyse:

Yeah. As actual usage.

Ben Callahan:

Yeah. Or as, I mean, I think th this is part of the problem, is that we've defined adoption to be so narrow. And I would say, Hey, if you're reading the doc site, that's a form of adoption. If you are, maybe you're not using my components, but you pulled in a couple tokens, okay, that's a form of adoption, you know? And so I'm all about, let's broaden that definition and then let's think about how do we measure the health of an adoption, or that kind of thing, where it's it's, it can be a gradual scale. And that could even provide a roadmap for teams to be like, oh, I can see a nice step-by-step progression for me to move through the health of adoption towards a healthier approach, you know? There's a lot of benefits to that way of thinking, I think, so.

Elyse:

So going back to our episode of the question, I think one of the coolest things that came out of that was, you took what we discussed, the answers to the questions and actually made a diagram. And I know trying to describe a diagram on an audio format is kind of silly, but I wanna talk about this because, I think it's, you've done such an excellent job of taking the quadrants of different kinds of impact and how design systems can actually create impact. So will you tell us about these quadrants— and listeners, this will be in your email when this episode drops, so go check that out if you wanna see the picture of what Ben is about to tell us about.

Ben Callahan:

Yeah. So I, I am, if, if you know me well, you know, I love a good diagram. My team, I think I drive my team crazy. But all my presentations, all my writings, I always am trying to find a way to visualize the thing. That's just how my head works. And it helps me to process the thing. So in this case it's like an XY quadrant diagram. And on the Y axis, we have this idea of at the very top, Strategic Impact, so making an impact in your organization through cultural shift, like more strategic work. And then on the bottom of that Y axis, we have tactical. I have it labeled as Impact Through Assets. Where it's okay, we're going to give you tokens and we're gonna give you components and stuff that you can just pull in and use. And my theory is that you have to have an approach that works at both of those extreme ends, right? It's not enough to just give tactical stuff, and it's not enough to just do cultural work. And um, so that's the idea. Top is strategic, bottom is tactical. Now on the X axis we have, on the far left, Common Interaction Patterns. So these are like things that every product in your organization needs. So what's our classic example, Elyse, you know:

Elyse:

Forms, inputs, buttons.

Ben Callahan:

That's it, right? All that stuff, right?

Elyse:

Modals.

Ben Callahan:

The button, right? Yeah. Don't say modals! The stuff that, if you went out and looked at every interface that your company offers, what's in the Venn diagram, right? So that's the common stuff. And then out on the far right side is like the extreme unique stuff, that only one product in one flow has, some very, very specific thing. And so with this set of quadrants, we have this sort of bottom left situation, where it's like common interaction patterns and like a tactical approach to solving those. And that is, I think, that's like a really efficient way to think about creating more cohesion in the products. That's why I have this quadrant labeled Efficient Cohesion. And that's where the design system is offering just the right amount of kind of fundamental low level assets for teams. This is like the Lego brick analogy, right? It's just the pieces and—

Elyse:

This is where I feel like code component libraries live.

Ben Callahan:

Yes, totally. Absolutely. In that top right, I have this labeled Future Proof and Far Reaching. And this I think is where the organization, like this is like a very mature organization. So this is where we're thinking strategically and we've impacted culture. So that teams doing really specific, unique things that aren't in anything else in the product landscape, they're still making choices that align with the system, right? And that's, that doesn't happen through assets. I can't possibly give you enough components to solve every single problem that's unique to you. So what that means is they're, they're compelled to make really good decisions, right? The whole organization has the same values, is really what we're saying in that quadrant. That's what I think is needed and this, this is how we approach the work. You know, we do this really strategic work with executives and leadership, and we do this very tactical work alongside, individual contributors building stuff. I think the bottom right is where, this, this episode really helped me to see this bottom right quadrant. This is where, what we were just describing I think fits in there nicely, Elyse, feeling like I just, the metric for me is add more components. And so I've got all the stuff that most people need, so I just keep going. I just keep adding more and more specific product specific components. And that's, I just have that quadrant labeled, Add More Components, you know, and it's literally just a constant expansion of the system. And that—

Elyse:

Especially stuff that doesn't get used, or, you know, for a test or just a thing that's dead. Like I was actually just writing, starting to draft a doc on how we can get the app bar, like the navigation bar out of our design system. Because it's starting to get, like, there was the original one and then it got edited, and then it got layered, and now there's this override in one of our products and now we have a totally different product that's not even using it. And it's this doesn't even belong in here! And you have in this quadrant, Encroaching on Product Responsibilities. And I think this is one of the most dangerous places for design systems. Design systems who just wanna like, add more components and help product teams. It's like, I'm gonna help this product team by building it for them and putting it in the system. Look, it's in the system. Look how much of code coverage the system is providing. We're building two really different products right now, a consumer facing one and an internal one. They have very different needs, very different users, different design principles. The app bar, the navigation bar for both of those things does not need to live in our shared system.

Ben Callahan:

Right. Yeah. And in fact, that situation you're describing, Elyse, where there's like very different products being supported by a single system, that actually means the size of that system is gonna scope way back, because there's not as much overlap in the needs, you know? And so that's where the work, the tactical work that bottom left quadrant here, the common, the efficient cohesion space, that's a small amount of stuff. But the real work for that is in the top right.'cause I gotta get these two very different teams to think about the way that the system would implement this. That's what I really need them to do, yeah. So.

Elyse:

If, if add more components is our— this is giving like the Eisenhower matrix, right? Like important, you know, urgent—

Ben Callahan:

Yeah.

Elyse:

So if add more components is our negative, tactical, product focused, what's our like strategic failure zone?

Ben Callahan:

Yeah, that's where I have Inefficient Cohesion, right? And I actually think that this is how a lot of organizations that have really good products work, when they don't have a design system. So if you look at— I don't even know of a good company— but I just think that this, this statement has to be true. Before we ever had design systems, some companies had still figured out how to create a suite of products that looked great, felt like one unified family of products, right? So it's not that you can't do that without a system, it's just that's a very cultural strategic approach. We've really, we've bought in on our values and our principles and we preach those and everybody gets it and they can all repeat it back and they use it daily.

Elyse:

And you're deciding that if you want to update the, say, button across 80 or 800 pages, somebody is going in and doing that work. And

Ben Callahan:

when we

Elyse:

talk about efficiency, this was something that Brad Frost said in in our episode that we recorded, and he was like, back in the day when we talked about efficiency, we were saying, that is a sad use of your time as a human being to spend three weeks updating the hex color of every button on every page across like 800 pages, and none of it's reusable. So like in the old, in Ye Olde Days, right? Like, that's what we were talking about when we were talking about efficiency. And efficiency means something different now. But I love that you made it so clear that there are ways to have cohesive, beautiful, visually consistent designs, that have nothing to do with the assets provided by a design system. That is in the way that we work, the way that we build ui, the way that you do design-eng handoff, the shape of your team.

Ben Callahan:

Mm-hmm.

Elyse:

And, and as you say, the values. Like we value this visual consistency so much that we are going to figure out a way to do it, regardless of where that comes from.

Ben Callahan:

Yeah.

Elyse:

And it doesn't come from the React component.

Ben Callahan:

Yeah.

Elyse:

The React component is just a method, a modality by which we share that information.

Ben Callahan:

That's right. I love that, I love that. And here's my question to you about this. Do you think the right way to go about this, is to start in the bottom left and just build the really common stuff? Or do you think the right way to go about this is to start in the top right? And assume that over time, if we're doing the top right well the bottom left will emerge.

Elyse:

And what is this? The Spicy Takes Design System podcast?

Ben Callahan:

Come on.

Elyse:

Yes. No I absolutely think that. Um, I, there was a period of time where, we were saying things like, if you're using a prebuilt component library, you don't have a design system. And don't think that's true. It might have maybe been true for a second when we were thinking about design systems as like this thing that we were building, but you know, when you were talking about efficient cohesion, right? This like interaction patterns, very tactical. For most companies— we're gonna get, somebody is like pissed off right now, they're just like waiting— like for most companies, most, not a hundred percent, maybe you are a special snowflake. Most of the time, the fundamental core components, the foundations, the things that are in every product, right, your button, your input, whatever, they're just not different!

Ben Callahan:

Yeah.

Elyse:

They're just not that different. You can get them pre-built. If you're Coca-Cola, like if you are that big and that global, if you're doing multi-platform, Android, iOS, web and you have multiple frameworks, like maybe you need to build a whole bunch of custom stuff, web components, do it all yourself, like there's a, there are reasons that you don't want to use a prebuilt component library. But I see so many teams be like, we're gonna start a design system. We're gonna build buttons and inputs, and that you're building it yourself. You're doing the like actual React functionality yourself. You're doing the UI styling yourself. And you're gonna spend six to 12 months on that, for something that you could literally npm install.

Ben Callahan:

Yeah.

Elyse:

And that to me is just such a waste of time. It's a waste of impact. Why am I gonna say, hey, product team, we're gonna, we're gonna, we're gonna provide this stuff to you— in six months. And they're like, I can literally install this right now, and we can like, theme the button. And so I think a lot of teams start there, right? They're like, we're gonna build these components, and then they have all this stuff, and then they're trying to get the people to use the stuff. And that's when you're, they're, you're trying to move into the strategic quadrant. And Dan Mall's talking about this, lots of people are talking about this now, like how do you start with the product focused patterns? How do you start with what are teams actually working on and how do we, like what are teams actually working on that's relevant to our product, that's like special or different? Because that's what helps your product teams ship faster and ship more cohesively. What I don't know about yet, is how do you start, like literally— okay, we're gonna go into an organization that has no Figma components, no code library, like maybe, super scattered, or there's like multiple code bases or multiple sets of libraries, things built in a whole bunch of different ways. How do you go into an organization like that, at a strategic level, and start to impact the tactical stuff from strategic down? I don't really know what that looks like entirely yet, but I think this is the problem. This is the conflict that we see. We hear about this in The Question. I feel like half of your episodes of The Question, somebody is talking about something like this, where they're like, my organization said they wanted a design system, but they just don't value, we're not putting our money where our mouth is. They say they want visual consistency, but they don't actually take the time to do it. They say they want this, but we don't actually go back and, clean it up. And so like I, I'm not sure what that looks like yet. So to answer your question, yes, but how do you do it?

Ben Callahan:

I know it's hard. I mean, when we start with a new customer, we always do a pretty robust cultural analysis. And that's because I've learned over the years, of 15 years now of running a studio, that you can't go in with the same approach to every kind of culture. And so I think there's a lot of wisdom in the idea of just Hey, like I need to just understand what the environment, what the context is, you know? The more I've thought about this diagram though, I think the right place to start is actually in the very center.

Elyse:

Hmm?

Ben Callahan:

And to slowly work your way out, up and right, and down and left. And I need to write about this. I haven't written about this.

Elyse:

I'm picturing a new diagram with circles.

Ben Callahan:

Yes. Right. There you go, like expanding. But I think you, you have to do a little bit of both, is what I think I'm saying. And and again, like that's gonna look a little bit different depending on the culture. But I think that's what you need, is a little bit of that strategic work and a little bit of that tactical. And the way I, the way that I think that, that actually might look is: every ticket that you write for your ICs to do, it's not— a ticket doesn't mean I'm gonna go write code or push pixels around. It means I'm gonna do that, but I'm also gonna do some education and I'm gonna do some engagement. So the ticket is, I gotta go figure out what this should be, and then I gotta design it or build it, then I gotta go train people how to use it. And now all of a sudden we're wrapping all of this up into one activity, and that's like starting right in the center. So that's how I think I'm evolving my thinking in this.

Elyse:

Yeah, and I'm curious to see if, in 2025, in the next couple of years, if the way that we hire for these teams is a little bit different. I think there kind of traditionally has been, I'm an IC designer or engineer, and I am annoyed at the, the inefficient things that we're not doing right? Like, I'm annoyed that our design is so inconsistent, and so I'm gonna start this sort of like, grassroots movement in my organization to try to do that. And when you're at, when you're at an IC level where what you are incentivized by organizationally is shipping designs or code, by, by which I mean your performance review is like, you did the design, you shipped the code, you did the ticket. That is the way that you know how to impact your organization. And so it makes sense for you to start with fundamental assets, because that is what you know how to make, it's what you get rewarded for, and it feels very tangible. It's a really, really hard mental shift to go to, I actually didn't deliver anything, and I made a really big impact on my organization. And there's been a really big backlash against, the, the consultant, the strategist, the, especially in the sort of like post layoffs, post pandemic, it's like, we're not gonna hire somebody who's just gonna make documents and talk about stuff. Like that's not a valuable use of our money and our time. I would love to talk more, and hear from listeners, if you're thinking about this, like, how do you act in your organization in a strategic way, while still not just being like jabbering about stuff and not actually making anything happen. Like that kind of strategic values work is really hard. And it's hard to prove or show and I'm curious to see if organizations are gonna start hiring different kinds of people on design system teams, who are actually at I'm gonna say quote unquote higher like career hierarchy levels, whose job is actually much more defined by the strategic work rather than the tactical IC work.

Ben Callahan:

It's interesting, Elyse, I'm just thinking of this as you explained that, I'm just now realizing, like I talk about it the same way. Like I think what, what are companies gonna hire for their system team? What's that role gonna look like? But I'm thinking now about the actual reality of the scenarios that I've been in, very rarely are they actually going out and hiring a design system team. Most of the time they're looking around the organization, and they're saying, you could do this, you're a product designer. Come over here and be a system designer. You, you're a product owner. You come over here and own the system as a product. You're an engineer on this product, come, you know, that's what we're doing. I would say 80 to 90% of the people on the teams that I coach, are people who weren't design systems people, but they got pulled in for some reason to do this. Either they wanted it or they just got identified. And so now I'm thinking like, oh my gosh, you know, we're, we're not even like hiring for these people. We're just like looking for somebody who has a portion of the skillset and putting them there, you know? And that's like a very different thing.

Elyse:

Yeah. And do we need people working on our design systems who are very familiar with our product, both from a design and a code perspective? Yeah, absolutely. To all the points we've been making, there's a lot of education and engagement and like organizational behavior change, right? And I, very much believe that these are skills that are learnable, these are skills that are really important for design system teams, but they're not necessarily skills that people on design system teams have or are trained or supported in.

Ben Callahan:

Right.

Elyse:

Importantly, probably not actually rewarded in their career ladder.

Ben Callahan:

Yeah.

Elyse:

Tanya Reilly has this really great blog post, so she calls Being Glue. She talks about this idea of glue work. And glue work is the stuff that like, makes it go. It's, hey there's a pitfall over there. Hey, I'm gonna, share outcomes, or I'm gonna share like, not, not like take notes in meetings, but like communication and describing what's happening and herding cats and like getting people all together. And what she talks about in the blog post is, if you're trying to move up the IC ladder, that work is not only not rewarded, it is often explicitly devalued. It's like you have to actually do the shipping and delivery IC work. But I think 90% of design systems work is glue work. The components are easy.

Ben Callahan:

Oh my gosh. Yeah. I never thought about it quite like that. Yeah, the fact that the incentives aren't in place for that kind of thing, it's just not valued. It's funny is like organizations all say they value that, but when you look at the reality of promotion and escalation, you know, moving up your career ladder, it's just, it's not really there. You said something a minute ago, Elyse, that I want to push back on. You said, we need people on our design systems teams who really understand the product. And okay, here's, here's my pushback on this. I understand what you're saying with that, but also, I've worked with teams where, there's like a designer who came from a product to work on the system team and their bias for that product is so strong, it makes it hard for them to think a level up, to like, look across all the product needs. And so one of the things that we do when we come in and partner with these teams is, if we have that scenario, which we often do, is we'll take that person and have them go research the needs in other products instead of having them give the information they already have in their head about their old product. And that sort of forces them to see the bigger picture. It's like training the systems muscles in their brains a little bit. So I don't know if I would say you have to do that,'cause I think part of the job is going out, like very few people know enough about all of the products to be able to answer the questions that a system needs you to answer. So there's a ton of research to do. You're, I think the impetus behind that question is like, well if we have people who know some of the products, they have a little bit less research to do. But I'm also saying maybe there's a bias there.

Elyse:

Totally. And I think a lot of us have worked on a system that was really heavily focused on one of the products that a company has built to the detriment of all of the others. But I do think there's a sweet spot where, yeah, you have to flex that system muscle, and if you're coming out of only being focused on one product and one user, you may not have a very strong system muscle. Hundred percent agree with that. I think there's a real sweet spot of components that are not in those fundamentals, right? Not buttons, not inputs, things that are actually like more relevant to maybe multiple products, maybe all of your products, that you have to understand, what it is your business is shipping. And I think this is where we get into the like, uh, component library is not a real design system because if you just take an externally built, built for everybody, can use it for anything, prebuilt component library. It's, there are gonna be places where you're gonna have to change it'cause it doesn't actually work for your product.

Ben Callahan:

Yeah.

Elyse:

I think yes, and there's a balance there. Because if you just hired, I'm gonna, I don't even know if people are out there like this, but like a just a design system person who's not, who's only thinking about like, how can I perfectly set up like the perfect and ideal token, scenario and the perfect and ideal types of banners or chips or like whatever, and then you try to put that in a product like, there's friction because your product needs a different thing.

Ben Callahan:

Yeah. Yeah, that's really fair. And really what we're getting at here, I think where we're landing is, that there's a really healthy tension between the system designer concerns and the product designer concerns. And we could do that with any discipline, not just design, right, engineering or product or QA or whatever. So that tension is what we got, that's what we're after. And we gotta have people fighting for those perspectives to you know, move the decisions into the right direction.

Elyse:

Yeah, absolutely. So if you were gonna set up a design system team, and I know this is like a broad question because I'm not gonna say for a 10,000 person company or a 100 person company, so like, you know, just a little hand wavy here.

Ben Callahan:

Yeah.

Elyse:

Gonna set up a design system team, what kinds of roles and skills would you really focus on? And like, where would you have them start?

Ben Callahan:

Hmm. This,

Elyse:

I know it's so hard because there's so many constraints, but I just.

Ben Callahan:

I love it.

Elyse:

We've been thinking about like, do you start a strategy? Do you start a tactics? Do you have product focus? Do you have system focus?

Ben Callahan:

Yeah.

Elyse:

What's the, what do we think the future of that is gonna kinda look like?

Ben Callahan:

Yeah. Something that I've learned is that the shape of design system teams changes as the system matures. There's a lot of tactical work that's needed early on, I think, as you're, if you decide that the right thing for your organization is there's a set of components we need and we just don't have those, right? There's a bunch of work to do that. It's not that those folks go away, it's just that the volume of customer support work like, it almost matches the amount of tactical work as soon as you release. And so there's this whole set of skills around like supporting the product we're releasing that most systems teams don't actually have anybody on their team who's dedicated to that. It's usually like a, well, you do it today, you man the Slack channel now, or you handle the email today, or whatever it is, you know? And so that's like not a, I think that's a miss on the part of systems teams, and I think we're gonna learn if we haven't already, that there's a really critical role of like actually owning support for the system. I also think in those early days, especially, I'm a big fan of just a really, like a refactoring approach. Before you release anything, just pick something that's meaty, that's like a problem, like you were describing this a moment ago, and I think, Dan's talked about this idea of picking like a big component to start with. I love that approach, of saying I'm gonna pick something and I'm just gonna take this thing and I'm gonna refactor it down into bits and pieces, and now I'm gonna go the other way. I'm gonna build something new with those bits and pieces, and now I'm gonna look at these two big meaty components and I'm gonna refactor those down again. And it's gonna be a slightly different set of foundations. And now I can build up to something else. And this little exercise of like deconstruct, construct, deconstruct, construct, it's a lot of work and it's a lot of rework. But what you end up with is a set of foundations that are actually true to what your products need.

Elyse:

Right.

Ben Callahan:

As opposed to just saying, oh, let's put every color in the thing, whether we're gonna need any of these or not. Let's put every font size in, let's put every, I mean, good grief, the number of tokens that people are putting in their systems right now is blowing my mind. And so I think this refactoring approach, especially in those early days is really helpful. So that's maybe where I would start. And of course the principles, the cultural analysis, like all of that stuff is like, that's like where I live, that's the stuff I really love. So I think understanding how to do that refactoring in the context of the culture of that org is the way to do it.

Elyse:

Yeah, that's, that's, yeah, I think you're right. I think that's missing in a lot of teams, you know, you start with the assets, you start with the tactical stuff, and without understanding what it is that your organization is actually valuing,'cause it's so easy to say, we want visual consistency and we want efficiency, and we want this and we want that. But when you actually look at the way that your organization is working and what they are valuing, if you're not aligned with that, you are, you're just fighting an uphill battle the whole time. I've heard people say this in The Question in particular, like, well, my organization says they want visual consistency, but they don't actually, they don't actually care because they're not actually putting any effort toward it. Therefore they're like, they're lying and they don't care and design systems are gonna entirely fail. And I'm just like, well, they care about something. And how can you use the design system, I think it's Taylor Cashdan who said, it's like the design system can be like a Trojan horse to get this stuff done. Right now at Color, we are in speed mode. Does that mean that I'm doing less foundational refactoring and maintenance work? Yes. Does it mean that the design system is not able to provide impact to my teams? Absolutely not. Just it's the way that you go about it is really different. And so, to your point a minute ago about doing that refactoring, that kind of like building and unbuilding kinda like understanding the fundamentals for your organization, whether that's tactical or strategic—

Ben Callahan:

Mm-hmm.

Elyse:

—really matters because, if you're trying to get the, your product team to do something that is misaligned with their incentives, it's just not going to happen.

Ben Callahan:

Is it a slippery slope though, to say,'cause I've said this myself, so I'm not calling you out here or Taylor, but I'm just saying, it's actually really easy to look at the potential benefits of a design system. And I could go to any executive and I could just, without talking about systems, I could be like, what do you care about? What are you trying to get done right now? And they could tell me, and I could say, I could tell them how a system would help them with that, right? Like, it's pretty malleable. There's a lot of facets, there's a lot of benefits to it. But that gets us into, that's the beginning of the problem you started this whole conversation with, which is, we've made all these promises about what systems can do, but are they actually doing them? And so, I love what you're saying. I've coached people to do it myself. I've done it myself Elyse! But you're making me think here, like what's the right perspective? I don't know.

Elyse:

That's a, yeah, that's a tough one. I, I feel like, in my gut, I feel like there's a difference between. Hey, exec, what do you care about? Well, we care about, speed and efficiency and visual consistency. And we want our product to be perfect and great, and we wanna, you know, ship faster and blah, blah, blah, and you're like, yes, great. We're gonna build a design system. Gimme six months done, like, solved.

Ben Callahan:

Yeah.

Elyse:

right? Like that. And I, I know nobody's actually having that meeting and saying that, but I do think that's the aura of design systems. That was a very millennial use of aura. I don't mean it in like the cool Gen Z way. I just mean that was like, I'm old, um, you know, we were talking about systems, I think you hit the nail on the head earlier, as a way to replace front of the front end people, for a while. That's not what I intended with that statement. I'm thinking more about, we started building our internal tool. There was some discussion of whether or not it needed to use the design system. Totally valid, right? Like different design principles, different user, no real need for it to look the same. In a lot of cases it can't look the same. Different type stacks. Super data heavy, lots of data grid

Ben Callahan:

tables. Mm-hmm.

Elyse:

But we also have a really incredibly tight turnaround deadline. And I'm like, well, why would we reinvent all of these things that we already have? Or, hey, design system team can help you think about patterns like navigation and patterns like dialogues and those can be the same in a lot of cases, right? Like we actually can use the system that we have to get us the thing that we want from an organizational perspective. Maybe that's more tactical, right? Like maybe we're more in like the center of that circle than we are in the sort of like values. And I think the, like over promising is often in the very high level values. Like we're just gonna have design consistency all over the place. We're just going to, not need front of the front end people. Like, it'll just be there because the system will provide it. So I think that's the difference in my mind. How does that

Ben Callahan:

land? I think that's fair. Yeah, I think that's fair. And I think maybe what I hear you saying, if I was gonna try to summarize it would be like, instead of going to one executive and saying, what do you care about? And that one says efficiency. And you're like, okay, it'll make you fast. And then go into another one and they say, uh, cohesion. And they say, okay, it'll make everything consistent. Because I think that's how we get there, right? The one person's not gonna say, I want everything and I want it tomorrow, right? I mean, they might, but they're just being stupid if they're doing that. But each of them care about different things, you know, and that's the, that's that healthy tension. Like a set of executives are supposed to care, somebody's supposed to be pushing us to be more efficient. Somebody's supposed to be pushing us to be better quality. And there's tension between those, and we gotta find the right balance for us. And so if the system goes to all those people individually and gets those things and makes promises, then we're in that problem space. But if we can get them together and we can have them say, let's put our priorities in order, right? What is the most important thing to us? Now we can look at that list and we can say, okay, let's start with efficiency. If that's where we are right now, and that's maybe a little bit more digestible, more accomplishable for a system team.

Elyse:

And I, I would argue that most executives, there are definitely I. dysfunctional organizations out there, but there are, I would say most of the time, most executives understand that you can't have everything all at once.

Ben Callahan:

Yeah.

Elyse:

There's trade-offs. What do you wanna start with? Is it speed that matters? Is it design, visual cleanup time because we've got, you know, a rebrand coming in, or we did an acquisition, is it technical cohesion—

Ben Callahan:

Mm-hmm.

Elyse:

—like what is it? There's a whole list of things. Dave Rupert, a while back, put out an article where he was talking about the, like the on fire reasons that you do design systems work. And I actually really love that because he's really just saying, here's a nice long list of reasons that your organization is like, oh man, this is on fire. Those are the things to latch onto. That's how you like, I mean, again, a design system is just a tool for doing those things, for saying, oh, we're gonna try to mash two products into one after this acquisition and we need it to look and function the same. Like design systems isn't magic. It's a tool by which you do that. And there's a whole bunch of ways that you could do that, including hard coding every button with hex colors if you really wanted to.

Ben Callahan:

That's right. That's right. Yes. I think I agree.

Elyse:

Well let's not go back to that. That's a, that was a rough, a rough era of building for the web.

Ben Callahan:

Yes, it was, I, I don't know. I think it's like, there are, there's a huge benefit to latching the system to some other need, right? You get the benefit of that funding, of that momentum. But, making the system a dependency for the success of other things can sometimes also be really hard, and especially when we get to—

Elyse:

Great callout.

Ben Callahan:

If it's like a product that's dependent on the system— we talked about this with shearing layers and all of the articles about that going back years— that the system has to move at a slightly different speed. We can get into some real problems if we have that dependency.

Elyse:

Mm-hmm. There are many traps and many pitfalls. But you know that, I think that's true in all parts of the product and engineering and design lifecycle, right? I think a lot of the problems that a design system struggles with are, some of them are unique to systems, because of the kind of interesting, is it a product, is it a platform? Is it an infrastructure? Like this kind of like interesting space that we sit. And I think a lot of these problems are the same problems that we face in design and engineering and in building products in general. And some of those things are just hard. Like how do you measure efficiency? How do you not get stuck in a ridiculous like maintenance tech debt rabbit hole where you're like, oh, we're just gonna rebuild the whole thing and then you're just trying to get to feature parity for six years. Like, how do

Ben Callahan:

Yeah.

Elyse:

Like, these things are just hard. It's people and people are hard.

Ben Callahan:

it's true. Yeah, it comes back to that for sure.

Elyse:

So one last question to wrap us up. Tell me a little bit about some of your predictions for the future of the design system space. Again, as a consultant you get to see lots and lots of different systems. You have a different perspective than somebody who's in-house. We have talked a lot about the problems today and some of the things that we think maybe should happen, or maybe some like better ways to do things. So, let's just, I just wanna hear like where do you think the design system niche is going? What do you think the future should look like?

Ben Callahan:

Yeah.

Elyse:

What do you hope the future should look like?

Ben Callahan:

Well, okay, now we're getting different, that's, that's a little more optimistic. I, unfortunately, I do think that system teams are gonna continue to stay very small. I mean, you, of course you have, you have your big ones and I think those organizations, IBM and Adobe, and folks like that who have larger teams and are all in on building, like very robust implementations, those teams probably will continue that work. But I think for the, medium to small business out there it's a, it's gonna be a couple people tops, you know? It's funny, Nathan has had such an impact with all of his articles, and, he wrote the piece around team structures. And then recently wrote a piece saying, I shouldn't have recommended this idea of going toward a fully distributed model. I think a lot of folks had felt that tension, you know, around like, hey, we're trying to move towards contribution, we want to have a federated team. And I do think we've, organizations have felt the stress of trying to do that. Every once in a while I talk to a team and they think, oh, we're just gonna build it and then we're gonna go federated, and I'm like, that ain't gonna work. You know, like I've talked to maybe one company that's had that work. Um, so.

Elyse:

Pretty rare. I think it's just a misaligned incentives problem.

Ben Callahan:

Yeah, it's hard. So I think we're gonna see more centralization of the teams. And honestly, as efficiency becomes something that every organization wants more and more of, I think contributions in general are just, it's just hard to do them in an efficient way. They're not fast. And it slows you down to do that. I'm sorry, I'm a little bit of a negative answer here, but I do see it's still constricting, is how it feels. And luckily, I also think the scope of systems is constricting. So, I think that's actually a really good thing. The scope of the tactical work is constricting. And I think that, this is probably a pendulum that, that will swing for us in systems world for a long time, but I think, the hard thing would be if the teams are shrinking and the expected scope is growing. So if we can get folks to understand that, it's like, hey, it's okay if the team has to get a little smaller, but let's seriously think about what needs to be in the system. I mean, we can't talk about this stuff without AI, right? And I'm, I actually, my major in college was computer science, and I had to choose a specialization, I studied artificial intelligence for a few semesters in college. This was way before any of this hype had happened, you know? But I'm interested in this space, especially in the systems world, for a lot of reasons. I think everybody kind of jumped right on, like content, like writing your documentation, which I think is not actually a great use case.'cause I've actually tried doing that a little bit just to see like what's it gonna give me and like—

Elyse:

A button is an action that a user can click to do a thing.

Ben Callahan:

I mean, it's like, it's awful. It's awful. But I do, I do see value in, over time, organizations adopting the system as the sort of training for AI models. So that what we can do is get away from having to write all these, write the logic out for every individual to consume and understand when do I choose which token, right? It's like, okay we can automate a lot of that. Tell me what it is that you need and I can show, I can point you in the right direction. A lot of the larger systems are doing really cool programmatic stuff with their systems now, where it's like a little algorithm that makes a decision and gives you a value, and so that sort of programmatic approach or functional approach to systems I'm really excited about. I think there's so much that can be done there.

Elyse:

I'd love to hear more about that. I think those are great predictions. I feel like we could talk for another hour about all of those things. I personally think that in maybe in the immediate future, yes, like maybe there's still some, some constriction, some retraction, but I actually think that the future, even for small teams is really, really bright. I think that you can get very focused on your own problems when you have a big team, right? If you have a design system team of 10 or 20, you can spend so much time like, navel-gazing over, like all of these like teeny tiny little things. So when you are small, when you're one to five, you have to really, really focus on like, what is this actually doing? What is this for? What did I just spend my quarter doing?

Ben Callahan:

That's such a good point.

Elyse:

It makes your priorities much more clear.

Ben Callahan:

Yeah.

Elyse:

When you look back and you're like, we didn't, nobody used any of this, and so I actually think that there's a lot that a small team can do that maybe a big team can't do.

Ben Callahan:

Hmm.Yeah or they're more, they're like more motivated to do it or something, you know?

Elyse:

Yeah, I dunno if I'd use the word motivated. I think you just, maybe you can be a little more nimble or a little scrappier, or you just don't have the space to— like, when you are two people, you don't have to have a scrum process and retros and like your whole team, like yada yada, yada.

Ben Callahan:

It's true.

Elyse:

When you're twenty people, you absolutely have to have that stuff to work well together.

Ben Callahan:

Yeah.

Elyse:

So, I mean, it is just different. I'm not saying one's necessarily better than the other. But I do think we saw these big design teams like get so focused on building the design system. When you are a small team, you really have to spend more time on your other two E's, right? Like your education and your engagement. And so I would say my other prediction, and I disagree with you on this, I think scope is gonna get bigger and teams are gonna get smaller. And I, I wanna see it work. Because I think when you are smaller, you can have more relationships, you can go directly into teams in a way that has like way less overhead. And obviously if you're two people, you're not gonna be able to support 10,000 engineers. Like there, there's some scaling effect here. But how do we actually help our engineers and our designers work differently? And when you're a big team, you're like governance, documentation, office hours, checklists, like all this stuff that you have to do. And we don't see, you're talking about contribution, we don't see people taking us up on it. They don't come to office hours. They're not doing the contribution. When you're a small group and you're like, hey team, like what are y'all working on? Oh, you're stuck. Oh, you need help. Like we can come to your meeting, we can pair with you. My prediction is we're gonna see changes in the way that teams engage between product and design system teams because they are small.

Ben Callahan:

Yeah, I could see that.

Elyse:

Ben, thank you so much for hanging out with me. This was really fun, as always. So many good aha moments and like, oh, new things to think about, which I love. I ask everybody who comes on the podcast, this question, is my favorite question, tell us your spicy take on design system. No notes, drop a spicy take right here at the end for us.

Ben Callahan:

I will tell you, I don't think your design system is gonna make your products more consistent. And that's because you can build really terrible things with any design system, no matter how restrictive it is, right? So if you want consistency, that comes from culture and that comes from the cohesion, that strategic work at the top of that diagram we were talking about today. So I think that's a misnomer for folks for sure.

Elyse:

I love it. Did you see from Config in 2024 Cam Worboys from Wise in his talk? He actually did a little demo of that, he like intentionally made like a really terrible UX out of system components. It was actually really funny. It was quite appalling. You can definitely, I mean, it's just buttons and inputs and

Ben Callahan:

Right.

Elyse:

and accordions and modals and you can just make some absolute nonsense.

Ben Callahan:

Yeah. And if you know what you're doing, you can make some really bad stuff, you know?

Elyse:

You know what you're doing.

Ben Callahan:

Yeah. You can get in there and— It

Elyse:

takes skill, folks.

Ben Callahan:

To hack the heck outta it.

Elyse:

Oh, amazing. Thank you so much for coming on. I really appreciate it. It was a really good time.

Ben Callahan:

Yeah. Elyse, I love it. Thanks so much for having me.

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!