Language shapes the way we think and structure the world we build. On this episode of The Design Systems Podcast, Chris Strahl sits down with Ben Callahan, co-founder of Sparkbox, to explore the critical role of language and communication in team dynamics, problem-solving, and system structures. Ben shares insights on how linguistic choices shape product creation and drive organization-wide cohesion. He argues that while common ground is essential, design systems should balance order with controlled "quenched disorder" to foster innovation, using flexible, layered structures that adapt to unique team needs and create scalable, culturally embedded solutions. Listen to the full episode to gain a deeper understanding of the intricate relationship between language, design systems, and organizational culture, as well as practical insights on fostering system adoption and cross-team collaboration.
Guest
Ben Callahan is a developer, designer, and founder of Sparkbox, known for his engaging presentations, workshops, and his interactive series The Question. With a passion for sharing knowledge, Ben uses his journey to inspire others, bridging the gap between technical insights and the human challenges within design and development.
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, thedspotd We'd love to hear from you.
Hey everyone. Welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Ben Callahan. Ben is the co-founder of Sparkbox and the person that creates such wonderful and amazing content for this community. It's been a long time coming. I'm really glad to have you on.
Ben Callahan [00:00:37]:
So excited, Chris. Thanks for having me.
Chris Strahl [00:00:39]:
So before the show, we were kind of discussing topics and we got off on all sorts of tangents about Dungeons and Dragons and coffee and, you know, like you do when you're trying to plan a podcast show. And a big part of this that struck me while I was going and refilling my cup of coffee was the number of systems that are all around us. We talked a lot about systems for tabletop role playing games and systems for how you make a really great cup of espresso. And, you know, we talked about language and the creation of language and how those things are important. Kick us off here. Which direction do you want to go with this? Because I love that you and I are of a similar mind that like, we see the systems that are all around us.
Ben Callahan [00:01:18]:
Yeah, I think I'm wired as a very curious person, you know, and so I was telling you a little bit about how you mentioned a book, I think, and I was telling you a little bit about how I read, which is that I don't have the attention span necessarily to read one book, start to finish. So a lot of times what I do is I just, I keep a stack of books here just to the left of me on my desk. And I'll have to send you a photo of this stack, but it's a little unwieldy. But I've got books on architecture, like really old books on architecture. I've got the philosophy of History, I've got the structure of Scientific Revolutions. I've got some classic, like Christopher Alexander stuff, timeless way. I've got systems theory, I've got strategy books. I have some fiction stuff.
I have biology. I have, you know, I'm reading this one on Complexity. And so what I end up doing is I read a little bit of a few of these books each day, and that sort of forces me to find connections between ideas that maybe were never intended to be connected. I think about that as, like, the work that we have to do. Right? That's like flexing the muscles of a system. The important stuff is the space between things to make it really practical. Having a great button doesn't do very much for you unless it's connected to an interface in a way that is meaningful.
Chris Strahl [00:02:30]:
When you talk about those spaces between, expand on that for me a little bit. I think I know what you mean, but I want to hear in your own words, like when you say the value of a system is in the spaces between, what specifically do you mean by that?
Ben Callahan [00:02:44]:
Okay, so here's the analogy that I think helps. And this is not my analogy. This is an old sort of systems thinking analogy, which is that let's just say I go out and I do an evaluation of all the automobiles in the world, and I find the automobile that has the best engine, and I take that engine out. Let's say it's the Mercedes, whatever. I pull the engine out of that thing and I bring it into my house and I set it here. Then I go do the same evaluation of brake systems in vehicles, and I find, okay, Alfa Romeo has the best braking system. I bring it in, best tires, best everything. Exhaust, ignition, all of it.
Right now what I have is a room full of every single thing that I need, the absolute best of every single thing that I need to make a vehicle. But I actually can't get from here to where you live with that. Right? Because the parts are perfect in isolation, but they don't work well together. Right. And so in my mind, what that means to us is that compromise is necessary. So the job of a systems person is to fight for the cohesion of all of these things working together. The job of a product person is to fight for the quality of the independence, right? And that's like the fun balance that I think we get. And that's what I mean when I say the space between the systems. Person's job is to figure out how these things connect, how do they work together.
Chris Strahl [00:04:08]:
There's an interesting way of thinking about that, related specifically to design systems where, like, you can have an incredibly well-documented component, but without the ability to put that component into something that is actually composed into an experience that provides value, there's very little of interest in that. Much like design tokens, right? You can have Great color scales. But unless that color scale is actually presenting data in some interesting way in front of somebody that's like accessible, relevant, et cetera, that color scale is just something that's an academic exercise. It's essentially.
Ben Callahan [00:04:38]:
I totally agree with that. And that's why I think my kind of default approach to actually the tactical building of a system is much more about refactoring than it is about inventing things, you know, and so I like the exercise of constantly looking around, finding things that an organization is doing really well with their digital interfaces, and then refactoring that into a system so that you're exposing the goodness to other parts of the org.
Chris Strahl [00:05:08]:
That's awesome. It's funny to hear you talk about this, being ostensibly an agency guy, where a lot of your work is about the net new, like, how do you go and you actually create the thing, right? And I think that, like, look, our friend Richard Banfield always talks about this, right? How you hire an agency because they're like the creative, interesting people with tattoos that like, can come in and spark interest and excitement in your boring, you know, plain toast kind of company. But then ultimately, like, the reason why those people are hired oftentimes doesn't manifest in the work that gets done. And the reason why is because that boring plain toast company doesn't necessarily want to be covered in tattoos. They want to have that refactoring, that restructuring, that new way of thinking injected in. But they still want to be the same old organization they've always been. I think there's a lot of parallels here also with that idea of like, you know, how do you actually create the tools and the structures for systems like this to come into being? Do you go get a bunch of best of breed bespoke solutions and then write a bunch of stuff that glues all those things together? Or do you pick a platform and in that platform try to find something that maybe isn't perfect in some ways, but ultimately covers the gamut of what you're trying to achieve? I think that is fascinating to me that as again, an agency person, a lot of your focus is on, like, how do you create these robust things that fill the gaps in between, not just some new fancy, tattooed, covered idea.
Ben Callahan [00:06:31]:
It's funny because I think, like, the history of work for us at Sparkbox has always been as long as we've been doing this, it's always been that we're going into situations where an organization has worked with another agency or studio of some kind and not had a good experience and So a lot of times I feel a little bit like we're kind of like coming into triage. We're coming in to sort of like rescue or save a scenario as much or more often than we are coming in to do something new. And these days, at least, pretty much every organization has at least pockets of people who are thinking systematically already. So there is no new system.
What you said earlier, the new part here is the cultural work. And that's where you said, you know, the tattoo, whatever comes in. And we want the energy of that, but we don't necessarily have the gumption to make that kind of change. So when we come in, we come in starting with that cultural analysis, right? It's like, I want to understand what is the context within which we're going to try to do this work. And that starts the conversation about, like, are you actually ready for this kind of change?
Chris Strahl [00:07:37]:
Exactly, exactly. And I think about this as an interesting factor in the design systems space as well, because, you know, very often I get asked by investors that I'm pitching or people that aren't really as familiar with design systems, and they always say, like, what's the starting point? Are these just things that have never existed before? And I'm always like, no, no, no, no. Like, these exist everywhere. They're design systems in almost every single company that we talk to now. They're at a wide variety of maturity levels and a wide variety of implementations. But it's almost inevitable that there is something that is a starting point for this that exists in some pocket somewhere inside of that organization. Even the least mature folks at this point have at least some system that we're building from. And when you think about that, like, the role of design systems has shifted from one that circa 2016, not a lot of people had these.
And now, you know, 2024, eight years later, we're in a place where lots of people, almost everyone has these. So our role has gone from one of, like, let's go create something, like, really innovative to let's go rework our swing. Let's go rework our way of thinking about this system. And that almost always starts with a cultural idea of how we build. And I think that there is this big sea change happening across companies right now where this embracing of systems, this embracing of that way of thinking is starting to affect the actual structures of the organizations and the way they work to build product.
Ben Callahan [00:09:06]:
100%, I've definitely seen that. And that creates some real challenges, you know, especially for somebody like myself who's coming in from the outside. Often, you know, what they think they're hiring me to do is to build a system for them. But in reality, I know the real work. I spend a lot of my time in tools like figjam, because what I'm trying to do is show you kind of conceptually what we're building, but also the impact of this on the way your teams are structured or on the process that you use. And that goes in every direction, you know, so it means I spend a lot of my time just talking to people, just trying to understand sort of like, what are their expectations and how do we bring everybody into that, you know, into the conversation to make sure we're moving these things in the right direction. It's fun work, but it's also wildly interpersonal, and that comes with a lot of baggage and challenge.
Chris Strahl [00:09:59]:
Definitely. Yeah. I think about knapsack customers also, where in a lot of cases, there's this idea that they'll be able to pick up a tool and all the decisions will be baked into that for them. And a big part of our philosophy is we're intentionally pretty unopinionated in the way that our tool works, because we work for a wide variety of really big companies. And in that unopinionatedness, there's often this gap that exists, which is why we pull in partners to go do the work you're talking about is most of the time, this isn't a tooling problem. This isn't something that is going to be solved by just, like, implement a technology system. That technology system should support the very difficult work that you have to do to talk to a bunch of people about how they build, why they build, the process they use to build, and then adapt that to a system.
Ben Callahan [00:10:48]:
And we could take it even further. Right? Like, I think we kind of sometimes start with the assumption that in order to work more efficiently, in order to build more cohesive experiences, you have to have a design system. But that's totally not true. And it's so funny to say that on this podcast, but, I mean, genuinely, like before systems existed, right, There were companies that were doing great work, they were working efficiently, they were releasing wildly cohesive experiences, very good, innovative experiences that felt right for the brand. It's possible to do all of this without a system. It's just that when you do those things, well, systems emerge. And so I kind of think of it more as, like, I want to be on the journey of the organization moving towards the things they actually care about. So if your company cares about being more efficient, Getting to market faster.
If you care about better experiences for your end users, it's likely these kinds of tools, these kinds of patterns of systems thinking are going to emerge in the Org. Let's bring those together. That's actually the work.
Chris Strahl [00:11:50]:
It's interesting. My background is in product and so I spent a lot of time in product, first as an engineer, then later as a true product owner. And you always think about things like the Mythical man month, right? Where in a book like that, what they're talking about is they're talking about how to create pathways without systems. And I think, interesting, right, because like that book has aged remarkably well for going on 40 years old at this point. And when you think about it, the entire structure and point of that is, hey, everything is always chaotic, it's always a mess. How do you sort through that mess and ultimately end up with positive outcomes? And I used it for a very long time as a true blueprint for how you cut through the chaotic nature of how you build a product. And a big part of the reason why Evan and I started Knapsack is we took a look at the processes described in the modern way of building applications and basically said all these things are just inherently really painful and there's not necessarily a good reason why they have to be like, why do we have to build one to throw away? Why do we have to do all of this work to make sure that our upfront planning is both robust and flexible. All these patterns of antifragility that we have to build into every single thing we make.
Because we know that the moment that we actually get into the tech and we actually start working on the thing, there's going to be a million problems that emerge that we never thought of upfront. And all of the work that we'd put into like true product ownership and product management was about how we account for the inevitable problems that arise in this bespoke means of development. Now with systems, that bespokeness is giving way to a much more systems oriented view. The fundamental nature of how we build products is starting to be called into question where maybe we don't need to do all these things that were essentially insurance policies against the inevitable when we would start to build something.
Ben Callahan [00:13:49]:
Yeah, that's an interesting shift in thinking and I think what that leads to with a more systematic approach because you take some of the chaos out and what was the chaos giving us? It was giving us innovation, disruption, challenging the way we thought about things. And so this is one of the common frustrations, I think that Folks who love that chaos have with systems is that it's chilling out our ability to like actually solve problems in unique, innovative ways. And I'm interested in finding ways that we can start to incorporate some of that back in. You know, I do think the pendulum can swing too far right in the direction of absolute system control. And I've been really encouraged, you know, to hear other systems folks talk about the idea of like real flexibility and actually not seeing our role as the police in any way. And so I think there's interesting comparisons there.
Chris Strahl [00:14:50]:
So kind of tying all this together into a common thread, right? Like you and I are both believers that systems are changing the way that we work, the way that we build. And there's a lot of benefits to that. There's a lot of this that creates like clarity, that creates a sense of Zen and calm across the way that we think about building as long as organizations are able to adapt their culture to be able to embrace those things. But what we give up as a part of that is that little injection of entropy that sometimes makes interesting things happen. And I think that that's an interesting kind of like topic to riff off of for a second. Right. I was telling you before the show, anybody that's listened to this show for any length of time has heard me ramble on about playing Dungeons and Dragons with my friends. And so I play a lot of TTRPGs.
And when I think about tabletop gaming, I used to be the guy that cared all about the numbers. There's a website called RDR that lets you do a bunch of different dice rolls and graph them. And it's basically like this like statistical analysis tool for dice rolls that is very heavily used for people that are very into the crunch of TTRPGs. And so I know basically the stats for like the percentage chance of nearly anything happening for any character that I would build. And that used to be the thing that excited me. Right. Like that was the meta game for me is like being able to figure out how to optimize so deeply into the data driven nature of my characters that I would create. And as I've played for now going on 15 years, I've actually moved away from that and I've actually started to build characters that innately have flaws in them because it makes for more interesting stories.
I think there's maybe a parallel there between the systems that we're creating and the products that we're building.
Ben Callahan [00:16:30]:
Yes, there totally is. And just as an aside, I'm not much of a D and D guy. Both my kids love it. I have one, the older one, who is 100% how you used to be. Like, they want to optimize. They know all the stats. They're using those websites to try to plan out a perfect character. And I have one who cares so little about that and just wants it to be a really fun story.
And so I get to see both of these extremes play out every Friday night here in my dining room. But I've been reading this book on complexity, and there's this little story about ants in there, and it talks about ants as a system. You know, it's a nice example because ants in and of themselves are fairly simplistic, but when you put them into a colony, like with bees or even with humans, right. On a larger scale, like when you consider them all together working towards a common goal, it's wild what they can accomplish. And they talk about how ants have these pheromones they release when they go out searching for food. They kind of walk in these paths until they find something, and then they find something. They turn around, they go back, they follow the one they laid down, the pheromones they laid down, and they lay down a different scent so that other ants can then go out and find that. But there's always a few ants that just sort of, like, randomly wander, because if you put all your eggs in one basket, or if you put all of the ants going to the one food source, then all of a sudden it's gone and you're hungry.
And so there's always ants out also looking for new food. And that's like that little bit of, like, randomness, the little bit of entropy, the little bit of chaos. And in the systems world that we live in, design systems, I keep thinking about that edge of things as, like, by a system offering flexibility, you're enabling product teams to do that kind of experimentation, to do that kind of, like inject the chaos a little bit. Right. And what that means is you're going to give up a little bit of cohesion. I think that there's even words. Quenched disorder was the word that was used in this book. I love that phrase because it's this idea of saying, like, okay, we want some, and here's your guidelines.
But we're also not making things so rigid that you can't break the rules. I like that, you know, as a framing.
Chris Strahl [00:18:31]:
Yeah. That acceptance of the fact that there's going to be these oddball things that are part of it. And it's actually funny, like, when we talk about with our customers, about like what percentage coverage they should aim for of their design system and stuff like that, right? We always say like 80%. And I have problems with this metric.
Ben Callahan [00:18:46]:
Oh my gosh.
Chris Strahl [00:18:46]:
Yeah, up and down. But like the whole idea of like you want 100% of things to be built using the design system is actually like, probably not good for your organization.
Ben Callahan [00:18:55]:
No, totally not good.
Chris Strahl [00:18:56]:
So when we think about the practical application of this in the landscape of design systems, oftentimes talk about the centralization, the cohesion, the collaboration, all being in some sort of single source of truth as a big feather in the cap of the design system. Right? Like that is the goal or the end state. One of the things that has always troubled me about that is that there needs to be this sort of intentional fragmentation that you insert into these structures and these systems. Because fundamentally, if an organization is large enough and complex enough, there's enough diversity of need and diversity of experience across that organization that without that fragmentation, you end up underserving significant portions of a user base because their needs are just fundamentally different. And look, we work with a lot of banks. And so when I think about this, I tend to think about it in terms of banking, right? You have commercial, you have markets, you have retail. All these have different ideas of what a banking interface should be because they have fundamentally different ideas of how money moves in our society. And the idea of a design system being a single system that can serve all of those potential needs, that's a really hard problem and maybe so complex we shouldn't actually build that.
We should think about this idea of where do we actually intentionally induce fragmentation in that process. And a lot of that lands in this world of systems, of systems. And I'd love to hear your thoughts on exactly this problem because I think this is going to be the next big challenge we face in the land of design systems is as people get more mature, as people build more of these structured ways of working, how do we introduce the right kind of difference? That injection of entropy or that, what was it again?
Ben Callahan [00:20:43]:
The quenched.
Chris Strahl [00:20:45]:
Quench.
Ben Callahan [00:20:45]:
Quenched disorder.
Chris Strahl [00:20:46]:
Quenched disorder into our structures.
Ben Callahan [00:20:50]:
Yeah, this is so good. And I think you can look at it from two directions, right? One is kind of what you suggested, which is we build a system, a full on design system, like we think that solves some of the problems and then we allow you to kind of take that and extend it in some way for your own sort of domain of needs, right? And so maybe it's 50% of the problem solved at this Core level, and then another 30% solved in a specific domain. And then there's a bunch of other things that just.
Chris Strahl [00:21:16]:
The clone it, fork it idea.
Ben Callahan [00:21:18]:
Yeah, yeah, right. Then there's the idea of saying, what if we just let these teams consume or subscribe the system at different levels, right? Instead of saying you have to use components, what if we said, okay, you can just use tokens? Now we're like, we're giving you a slightly smaller, less composed solution, right? It helps us move towards solutions that are actually healthy for the things we want out of a system. So those are very different models, but they kind of are ways of serving the same problem in different ways. You know, I actually really like that idea of, like, letting folks kind of get into the system at lots of different levels because it really expands the idea of adoption. Like you said, we tend to say 80% is what we look for coverage. Like, what does that even mean? You know, like, I mean, I think of any use at all of a system as a form of adoption. You go read the doc site, you just adopted in some way, right? So, like, I love the idea of lowering the bar of what it means to use the system. It gets really hard to measure all of that, you know, because there's so many different ways that somebody can adopt.
But if you're talking about what percentage of code in production is generated by the system, then you get something you can measure. But then you're wondering, are these appropriate use cases for the system? The quality of the. So all kinds of things to think about.
Chris Strahl [00:22:43]:
I mean, again, back to the era of the mythical mammoth. Code is gold in so many people's minds. But at the same time, there's a lot of things that go into the creation of the right code that still really matter to that effort. And much like how we think about the difference between how managers. Managers and how makers make. Meeting time is productive time. Talking about accessibility is productive time. Reading and writing documentation is productive time.
And that ultimately is reflected in the quality of the result that gets implemented for a user. And I think there's like, a tendency to forget about that when you think about that adoption standpoint. If nobody ever uses a single line of code from a design system, but their organization had all of the right conversations about exactly how they should structure their components and their tokens and make their colors accessible and do all the really hard work, that's still a successful design system.
Ben Callahan [00:23:36]:
Totally is. And that's what I was trying to say at the beginning, where it's like, you actually don't have to have a system in order to create cohesive experiences and to do so efficiently. What you have to have is a culture that values the benefits we ascribe to systems. That's what you have to have. And so what you just described is a culture that values equitable experiences, accessible experiences, a culture that values creating a good experience for a customer that is familiar to them because they've used your other products.
Chris Strahl [00:24:05]:
So back to cakes and forks real quick. So like, when you think about like this layered model of a design system where people can adopt it at the level that they choose, the layer cake, if you will, versus the like clone it, fork it model where you can take something and if you're able to leverage it, you can then extend it however you want. There's a lot of pros and cons with each, right? Like in one case you have the upstream problem where you know if you're forking something and then that thing changes, how do you incorporate those new changes into what you're doing versus in like that layer cake model, depending on what layer of the cake that you're in, you're getting a different level of value from that system and you can ascribe a different richness to it. And so I would think that the layer cake model, as probably the more complex one, is more interesting to a lot of people on the surface because they're like, well, it sounds great to be able to like have a menu that I can choose from. If I just want tokens, I just get tokens. If I just want components, I just get components. If I just want docs, I just get docs. But there are a lot of shortcomings that we run into here.
And in large part in my mind, it's based on the pace of change of different things inside of a design system. If you have something that is a core brand decision, like your color palette, it's unlikely that that changes all that often. And that's something that's fairly static, fairly robust, not immutable, but definitely not rapidly changing, versus something that is like further down the value chain, like a complex feature pattern, right? Here's my four step signup flow that's likely to change really, really frequently. And in one model, when I think about it, the clone it, fork it model, if those things are fairly immutable, that seems like actually a more efficient way of getting things done. But if you're looking at it from the idea of like, here's something that changes and iterates really, really rapidly, does the layer cake model still support that?
Ben Callahan [00:26:04]:
Yeah, I think it's. Yes.
Chris Strahl [00:26:07]:
And this is why I'm stoked to hear. I really want to hear your opinion on this because I've been grappling with this all the time lately.
Ben Callahan [00:26:15]:
Yeah, yeah. A lot of our customers are grappling with this too, because systems work, I think, is easy at a small scale, but it adds value at big scale. When you start putting this into really big, very complicated organizations is when these problems surface. And I think you have to allow both of these things to happen. Like, the layer model provides like a really nice roadmap for adoption. Like start with the docs, you know, that's so lightweight. Just go read these things and try to build following the guidelines we've given you. You know, you're following the docs and you want to adhere to the color contrast ratios that we've established. We actually have some of those codified for you
Chris Strahl [00:26:54]:
Right.
Ben Callahan [00:26:54]:
Here's a set of tokens you can use. That layering sort of like helps our product owner out in the real world who has to like make space in a roadmap to do this work. It gives them like a very visible, tangible way to become an adopter of your system. Right. So I love it for that reason. But I think what happens in that world is they get so far and they realize we're getting benefit from this, but it's not going to do everything for us. And that's when we move into them saying, you know what, we need to create some of our own things. Right.
And the thing that worries me about that model is how do we expose the really cool things that all these independent product teams are doing to each other? Because that's what's missing in that world, right? Is the idea that like one product team is doing the same thing that three other product teams are doing because it wasn't in the system. So what we need there is just a way to expose, right? A way to sort of like cross pollinate these ideas. And that's where it's like a lot of systems teams I'm talking to now or working with have these sort of like playground areas, right? Where it's like product teams come in from all different lines of the work and they have one space to just play around with things and they can kind of see what other teams are doing with stuff and then they can say, oh, that's actually helpful. Let's collaborate on this. And now we have a couple people working on the same problem that we could at some point in the future evaluate and Maybe bring back in.
Chris Strahl [00:28:16]:
Yeah, I like that idea. I mean, I really agree with the sentiment, right, that the most untapped value in a design system is that if team A innovates something, team B and team C should be able to take advantage of that innovation. And that is absolutely not possible in a bespoke product development organization. It's really only possible with systems thinking. And the structure for how you share that innovation between team A, B and C is where the hard work is. And like, what form does that take? Right. If that's innovating a token set, maybe it's just plug and play. But if that's like a four step signup pattern, it's very likely that those things are different between those different experiences, even though there may be great ideas that should be shared across them.
And in that friction reduction of the adoption of those other features, that's where a lot of value lies. Right? Because now all of a sudden we're not designing three different signup experiences, we're taking the core of one and then adapting it slightly for other use cases. And that's so much more efficient and so much better and so much less friction than basically being like, we need to design this experience three times. And people talk about like the consistency as the value inside of a design system. And I don't actually really think, like, yes, that matters, but like, that's not as important as that ability to share that innovative thinking between all the products in your ecosystem. How do you think about that?
Ben Callahan [00:29:42]:
Yeah, I mean, I think that is it and I love this. So let's just take consistency as like a specific benefit of a system. Because when you ask about it, people throw out efficiency. And those are like the two big things.
Chris Strahl [00:29:55]:
People talk about maintainability, maybe you hear.
Ben Callahan [00:29:57]:
Maybe accessibility, of course, but it's like all of those things are like just good practices baked into things that you spread around. Right? But being more efficient and experiences for our customers that are more cohesive. And so one is external and one is internal, we can get to market faster. That's an internal benefit. And one is external. Our customers experience our interfaces the same. Both of those things you can think about in layers too. Like at an individual level, if I have a figma file that I share with a friend, even just with myself, like I've designed a dozen buttons.
Ben Callahan [00:30:33]:
Okay, I'm going to make my own little mini. Absolutely. Micro system of just. Okay, here's the buttons. I grab these when I need to make a new interface. That's a way to get the same kind of cohesion between me and all of of the work that I do. But, like, we got to go up a level to my team, right? So, like, how do we think about solving these problems? And now we need something more robust for all of us to think about solving the problem. And that's a great level of cohesion, a great level of consistency.
But you can go even deeper, which is more of like, that cultural level of cohesion. And this is where it's like when the system is rooted in the brand and everything comes from the values of the organization. Now all of a sudden, we're getting cohesion in a very different way, which is not just interfaces look and feel the same. It means that the tone that you get when you come to our website aligns with the tone you get when you call us, right? And so all of a sudden it's like, wow, we just went next level with impact and value and brand awareness and that emotional connection people have to an organization. And we can't be a part of that unless we go all the way deep down to that root. You know, you can do the same thing with efficiency.
Chris Strahl [00:31:43]:
I love this because it's like people ask me why purpose and principles for design system matter.
Ben Callahan [00:31:48]:
Oh, my gosh.
Chris Strahl [00:31:49]:
And there you have it, right? Without the idea of these sort of anchoring tenets of why you're doing the thing you're doing, it all becomes this quagmire of just people trying to make decisions in a centralized place. And it is like Conway's law plus plus, right, where it's like, it's not just about the organizational mirroring of the communication flows, it's about the culture mirroring of the organization.
Ben Callahan [00:32:15]:
And that all leads back to where we started around this idea of language. Because on the efficiency side of this equation, it's about sitting in a meeting with a bunch of other people who you have to work with on a specific feature. And you walk out of that thinking you understood what you were supposed to do, and you work for a week and you come back to the next meeting and you all missed each other. That kind of miss happens way more than we want to admit. Inside organizations, on product teams, maybe just.
Chris Strahl [00:32:45]:
As many times as a hit.
Ben Callahan [00:32:47]:
It probably does. And it creates so much frustration. I mean, you get angsty about that, right? You remember that that becomes baggage for you in the work, and it creates frustration, it creates tension. And all of that can be solved if we just have the right words to use to talk about the problems we're solving. And that's in My mind, the biggest benefit a system gives you is it gives you a way for your organization to talk about the actual problems you're solving. And the documentation is where that language lives.
Chris Strahl [00:33:18]:
This makes me think about, in my career, one of my good personal friends, as well as one of the most talented engineering minds I know, didn't go to school for computer science. They went to school for linguistics. They have a degree in language. And he always used to talk about the idea that when we're talking about creating code, we're talking about a different kind of expression in, obviously, a language, but it's all about mirroring the things that we think about in our mind. And so how language works, how English and humans communicate, is actually reflected in the code we use. The entomology of our words ultimately become our code, and the expression of that in digital space. And his ability to tie the conversation in a meeting to the code that would show up in an IDE and ultimately get committed to a repo and show up in front of users. That was always his superpower.
And I always thought that was a really interesting capability for an engineer, is not to just be able to say, hey, I'm a really good coder that can understand how functions and complex states and loops and stuff like that work, but actually being able to connect the reasoning and the intent to the code that they write. And that is so cool to think about that in terms of language and also to think about then design systems and the structures and systems we're putting in place as a collection of these different linguistic choices that ultimately lead to a system to create a product.
Ben Callahan [00:34:48]:
Yeah. And the thing that really pushed me towards this was another book that I'm reading is on. It's actually by a biologist. Her name is Robin Wall Kimmerer. And she wrote this book called Braiding Sweetgrass, which is, like. She's a citizen of the Potawatomi nation. So she has this sort of background, this sort of, like, historical upbringing around, like, storytelling is how we pass knowledge. And for her, she never learned Patawatami, the native tongue.
And so she decided at one point she wanted to learn it. She grew up speaking English, and so she went to this meeting where there were eight remaining people alive who spoke this language. And so they said, we have to start passing this on. So this group of people came to try and learn it. And she got really frustrated at this experience because Patawatami is a very different language than English. And I think the way she describes it is she says that English has, like, 30% of the words are verbs, but in patawatami it's like 70%. So everything is a verb. And she says that another difference is the way that we assign like gender to nouns. In English, they don't do. They assign something as either animate or inanimate, as opposed to masculine or feminine.
Chris Strahl [00:35:59]:
It's either alive or not.
Ben Callahan [00:36:01]:
Yes. Right. So it just like blew me away. She talks about it like you listen to a person speak with a different word than you listen to an airplane, because a person is alive and an airplane is not. So the verb of listening. So it's a very complex language. But here's the thing. When you grow up speaking a language like English, your worldview is shaped by the possibility the language gives you.
And so this is one of the things that's so different about sort of the Patawatami view of the world, right? We are equal with nature in their language. And in English, everything is a thing as opposed to like humans are the only thing that live. Right. And so it's just like a very different framing. And when I translate that to our work on systems, I think that's the power we have. Product teams are working with the language we give them to build product. That's huge.
Chris Strahl [00:36:59]:
I love that framing. And it's funny because I think about this in a similar but vastly different context, I guess. Do you ever read Snow Crash from Neal Stephenson?
Ben Callahan [00:37:09]:
No.
Chris Strahl [00:37:09]:
So it's a sci fi, like cyberpunk style book that was written like you know, 30 some odd years ago that basically predicted how social media works, which is, it's crazy. Like, I mean, most of this stuff is borderline pre Internet. And the way that it's described is almost prescient in a lot of ways. And it's one of my favorite books, and the reason why it's one of my favorite books is because it describes language as a virus. And so language is a virus. And its viral nature and how it infects the thoughts and memes of the way that our society works is really fascinating. Look, there are weird parts of that story, but at the core it's a book about how language and the way that we interpret language ultimately shapes our worldview. And I've oftentimes thought about like Snow Crash and that virality as the power of a design system.
Because all of a sudden if you codify something and you write it down and then a bunch of other people go look at that written, codified thing, their worldview is shaped by it. And as such you create your own, like new zeitgeist within an organization based on this ability to construct a system and whether that is a fundamental shift in the way we think about how we express ourselves vis a vis the language you talked about, or if it's just knowing that we're planting a seed in someone's mind that's ultimately going to change the way they work. I think both of those are really cool worldviews on what we're doing.
Ben Callahan [00:38:35]:
Yeah. And then I start to think about how does this translate to the job that systems folks have of selling systems internally? Because it's one thing to get somebody to adopt it, to read the docs, to take in the language, to start using that in meetings, to start using it in their problem solving. But when you have to go to an executive who's not gonna ever go read your docs. Right. How do you teach them the language? In my mind, like, that's the most successful organization is where every layer of the organization understands how to speak that language. And otherwise, what you have is execs making decisions without context, not even understanding the language of their teams. You know, I don't actually know the answer to that. That's something that I'm grappling with right now is like, how do I actually help my clients learn how to teach their leaders the language? So maybe you got some answers for me.
Chris Strahl [00:39:27]:
All of a sudden the interview has been reversed.
Ben Callahan [00:39:29]:
That's right.
Chris Strahl [00:39:30]:
No, I mean, it's a major challenge. Right. And a big part of the challenge there is organizational leaders speak a different language than the people that work for them. And it's interesting, right, Because I often rail about how our society assumes a career pathway for most people that says, like, you go do a thing and then you manage people that do the thing. And we do a really bad job of preparing people that did things to then go manage those things. Because it's a fundamentally different skill set. Like, being a manager is like being a designer or being an engineer. It's like a discipline.
And we do a really terrible job of preparing people for that pathway. And I also think that it's maybe not important that everybody walk that same pathway. But digression aside, when you think about what happens when all of a sudden you're managing people is your worldview and what you value changes. And it has to, because now all of a sudden you're not concerned about like, hey, how do I create this really interesting interface? Or how do I code through this really difficult problem? It's how do I get that to work at some level of organizational scale that creates some value that is not just my value, but my entire team's value. And that necessitates a very different viewpoint on why systems exist. And the way that I've found it works best is when you talk about that collective value and how that collective value ultimately influences an outcome. And when I talk about it in terms of that outcome, what I tend to focus on is how do you make all of the people that work for you, that you trust, that you care about, that you want to see be productive and successful? How do you make their burdens easier? How do you make their life better? How do you make them be stronger, better, more effective people at building the things, you know, you need to collectively do? Because at some level, every manager understands that they're just managing a group of people. And that group of people extends them beyond what they'd be able to do themselves.
And talking about a system enabling that extension to go further than they ever felt before, there is a power in that that I think is really interesting that is beyond just like roi. Right? Because you could talk about that all day long and like people at executive levels, they kind of get it. But the reality of it is you're saying, like, look, we're making people that work at your company happier, more effective, and able to do more than they would have been able to do without a system like this.
Ben Callahan [00:42:03]:
Yeah, that's like that unity thing. You know, I'm somebody who is fascinated with, like, organizational culture and things like this, and I actually get goosebumps. I get really excited when I find a way to sort of help teams come together. And I think of systems where doing that because it kind of requires multiple disciplines to do it well. And you can't really just go do the design part of it. You can't waterfall it. It doesn't work. And so I think it forces that sort of unity to happen. And it also becomes kind of like a rallying cry. We're building something for us. Right. Which there's power in that too, which I really like.
Chris Strahl [00:42:45]:
So, Ben, this has been awesome. It's been great to talk a little philosophy, a little linguistics, a little nonfiction and fiction with you. And so I want to just say I really appreciate you being on the show. If folks want to continue the conversation with you, where do they find you at?
Ben Callahan [00:43:00]:
Yeah, my website is just bencallahan.com. i'm very active on LinkedIn, so folks can always hit me there and DM me. I'm gracious with my acceptance of LinkedIn connection requests. So reach out there. I'm on Twitter or X, not quite as often as I used to be, but still kind of hanging out there occasionally.
Chris Strahl [00:43:16]:
Yeah. And you have a show also called the Question?
Ben Callahan [00:43:19]:
I do. It's not exactly a podcast. I'm trying to figure out what to call it. So it's very simple. I ask a question question of folks on Monday morning, they have two days to answer. If they answer by Wednesday at noon Eastern, they get an invite to a deep dive where we look at all the data we gathered. So that either happens on Thursday or Friday at noon Eastern. And so it's basically in the span of one week. We pick a topic, I get a co-host. I'll have to have you come join me, Chris. I'd love that.
Chris Strahl [00:43:44]:
Yeah.
Ben Callahan [00:43:45]:
We pick a topic, we come up with a question, we ask it of hundreds of design system practitioners, and then we gather a bunch of data and we dive into it. It's really fun. I think of it as like a collaborative learning experiment where we're all just kind of bringing our expertise and very different lived experiences to a problem. So it's really fun, very collaborative. And I learned something every week. So that's just on my website, bencallahan.com, you'll see a link to the question.
Chris Strahl [00:44:10]:
Awesome. Well, hey, thanks again, Ben. This has been the Design System Podcast. I'm your host, Chris Strahl. Have a great day, everyone. That's all for today.
This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter 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.