Subscribe
Share
Share
Embed
The Question is a collaborative learning podcast about Design Systems. Smart people like you sign up, answer a few niche questions about design systems for each episode, and then we all get together to unpack the data we've gathered. Each week, I'll invite a new co-host to help facilitate the conversation. After the deep dive, the co-host and I record a recap of what we learned. That means, for each episode, you can listen to the recap and the full deep dive!
If you're a design system practitioner, subscribe today (https://bencallahan.com/the-question) to receive an invitation to each episode. This only works if the community joins in!
Stay in learning mode ❤️
Ben Callahan (00:02)
Hello, system thinkers. Welcome to the recap for episode 074. I am joined by my friend Kaelig here. Kaelig, thank you so much for spending an entire hour with us on the deep dive, taking a quick break and jumping right back in with me on the recap
Kaelig (00:17)
Thank you for having me. I mean, the questions that we had and the way people just brought their own experience and expertise was just awesome. So yeah, that was exciting.
Ben Callahan (00:28)
Yeah.
Good conversation as always. ⁓ We, you and I spoke before last week about what we would cover here and we knew we wanted it to be kind of AI related. You've been spending some cycles doing some really cool stuff with AI and in our conversation before this episode aired, I had asked you sort of what was going on in your world and you were giving me some stories and one of the things you told me was about this.
I think you said back in 2016, so a decade ago, that you were working at Salesforce and you were at a symposium and it was a bunch of other larger system teams there all kind of sharing what was going on and what was working and what wasn't. And to close that day, somebody posed the question to the attendees, if you had a magic wand, what's the one thing you'd change about your design system? And so,
Your answer back then was about tracking and sort of visibility into systems and the idea that we landed on that as a question a decade later. I'm just I just want to pause and let you respond to that. Like how does that make you feel?
Kaelig (01:36)
Yeah, well first kudos to Tim Shiner who was ⁓ moderating that symposium and organized it. He was the design system manager for Salesforce and brought in amazing people together. And then that inspired me to do more of that as I moved to, for example, Shopify, just liked to do show and tells between teams. And every time we would learn so much about other ways of doing design systems. yeah, my answer to his question was,
How do we get to know how our components are being used? And not just components, but components are a big part of that. Tokens would be one of those as well. And not just by design system teams, but also by the end users so that we know which are the hot zones of our design system, which ones need a lot of love, which ⁓ ones would need to have very fast SLAs. So if there's a problem in...
an input form, sorry, a form field. How big of a priority is it versus a drop down somewhere or a edge case of your design system and how to prioritize your response times and your team's roadmaps based on all of these things? Because without visibility, it's very hard to prioritize and strategize. So that was my question at the time. And to this day, I don't think it's been fully solved.
Ben Callahan (03:03)
Yeah, it is. It really is. If you are watching and you have the ability to build a tool that will look across all of the different disciplines involved in product work, from UX and prototyping and research through engineering delivery to actual prod, and you can tell us how and where and why assets of our system are being used, that would be ⁓ a game changer.
Kaelig (03:03)
And it's a business opportunity for people watching this. If you could build this, that'd be great.
Ben Callahan (03:31)
people would pay money for that one. ⁓ answer the call.
Kaelig (03:37)
Make it happen, just manifest it, just ask AI to do it.
Ben Callahan (03:39)
That's right.
Yes, do it. ⁓ So we settled on four questions, Kaelig The first one was, how would you describe your current level of visibility into how your design system assets are actually being used across disciplines, including their use by AI? And we gave folks a handful of choices. One, we have robust automated tracking and analytics. We have some small manual processes or partial tooling. We rely mostly on informal channels like Slack or office hours.
We have very little visibility. It's largely a black box and we gave them an option for other or NA. The second question was as agents and automation tools produce more content, design and code at scale, what are your biggest design system concerns? And we let them select all that applied and the options were the system being used incorrectly or out of context, new patterns emerging that we can't see, inconsistency accumulating faster than we can detect,
losing the feedback loops that inform system evolution and of course, NA or other. The third question, how has your feeling about the right balance between design system enforcement and enablement shifted as AI enters the picture? And they had to choose one from it's shifted significantly toward more enforcement, shifted slightly toward more enforcement, stayed about the same, shifted slightly toward more enablement or shifted significantly toward more enablement.
And the final question was, if you could instantly implement one thing today to improve visibility into how your system is actually being used without becoming the design police, what would it be and why? Lots ⁓ of data unpack. This was sent out to over a thousand folks who are all design system practitioners. We got 78 responses. And as always, wherever you're watching or listening, you can click this link to get the raw data and do your own analysis.
If you do, please let me know what you learned. ⁓ Kaelig, you said at the beginning of the deep dive that you're working on an article and that these questions are hopefully helping you sort of gather some context or knowledge about that might inform your writing. Can you say anything else about that piece or?
Kaelig (05:53)
Yeah,
yeah, I I love crowdsourcing my writing and understanding what people are thinking about. ⁓ And for that particular piece, it's a ton of research from all the design systems thinkers out there. ⁓ I've noticed some people veered more towards ⁓ enablement, some more towards enforcement, and also it depends at what layer. And so trying to see what thought
Ben Callahan (06:18)
Yeah.
Kaelig (06:22)
leaders are thinking and how that could inform the future of design system. But also I have my hot takes and my thoughts. Even though it always depends. There's so many variables and things at play that ⁓ could inform the future. I want to take a really deep dive on all of these things and then try to do a summary of where things seem to be going and then my own.
my own take at the end. So it's like a dissertation in a way.
Ben Callahan (06:52)
Yeah.
Love it. That's ⁓ it's so cool that you shared that because I started the question because I wanted this this to happen. Somebody in the space is curious about a thing wants to dig deep once a little bit more rigor around their writing and thinking than maybe what is normal in in the you know.
course of the internet these days. And ⁓ if we had a system in place where we could ask a question over the course of a single week, get a ton of data back, discuss it, analyze it, synthesize it.
Wouldn't that be cool? And so that was like the, that was the nugget of the idea. And so you have sort of like, without me, like prompting that in you, you've seen that as as a, a valid use case for this. So it's really fun for me as sort of the founder of this podcast or this show to see somebody using it in that way. So thanks for doing that. I can't wait to read it. ⁓ And ⁓ obviously, you know, dig into the data and let us know what you find. We'll make sure we promote that piece.
Kaelig (07:57)
Yeah, thanks. And it's going to be another long read because there's so much context out there and I want to do it justice. There's a lot of nuance in some of these blog posts that people have been so generous to share. And I don't want to be doing an X post just for the clicks and the cloud. And it's for my own curiosity as well. Like I really wanted to know, what do people rethink? And also, where do they contradict each other?
Ben Callahan (08:02)
Yeah.
Hmm. Yeah.
Yeah.
Kaelig (08:26)
⁓ is the interesting part here.
Ben Callahan (08:26)
Mm hmm.
Yeah, well, let's get into it. Kaelig Okay, like so the first question was about folks kind of self identifying their own level of visibility into their system and how it's used. What were you expecting to see here?
Kaelig (08:44)
Yeah, it's a... I haven't seen too many teams have very robust automated tracking and analytics, and I think it takes a level of maturity and investment that might not be worth it for most folks. ⁓ So I'm glad that at least people have some processes and partial tooling. That's really good. ⁓ And in any way, you definitely still need to rely on other informal channels.
Ben Callahan (09:05)
Yeah.
Kaelig (09:14)
I think design systems are for people like Jina likes to say, and a lot of this is relationship building. You can't leave everything to robots. There's things that robots only can do to give you signals on how things are being used. But also if you completely ⁓ robotize your outreach, you're losing so much of the value of design systems.
Ben Callahan (09:38)
Yeah,
that's a good point. During the deep dive, we can't remember who it was, but somebody sort of made that point, is, oh, Tony was saying like, gosh, there's all these problems if we just would sit down and take the time to talk to each other. You know, like we a lot of this stuff gets resolved. So this is definitely human work for sure. I think I was surprised to see that so few folks identified this. I mean, I
I think our audience on the question obviously is largely biased, right? These are folks who are in the space, very active and engaged in systems work. And I know the companies that a lot of our community members are working for, I know the scale at which they are operating. And I thought, I guess I thought maybe we would see that some of those organizations feel that they have better tracking and analytics in place than maybe. ⁓
than maybe I've seen in many other places, but you're right. And it's interesting too, to think too that like, just because you have the, maybe if you do have automated tracking and analytics, that doesn't mean you're forgoing, you know, some manual processes as well, or some informal channels as well. So these do probably stack, you know. ⁓
And so I think that's good way to think about it is like, OK, what can we learn at each of these types of layers? an informal conversation is one way to learn, but looking at actual stuff in production is another way to learn. And you're going to learn different things from those approaches. So cool to see that the community is doing lots of those.
Let's see, the second question, this one, it wasn't a ton to pull from. When I read the data here, it read to me as if we're just concerned about everything. And so I don't know, did you interpret that differently?
Kaelig (11:30)
Yeah, it seems like everything's a concern. Which is good, mean. Yeah, and maybe it means the question we asked.
Ben Callahan (11:34)
Yeah.
Yeah.
Kaelig (11:42)
was
too general and it's hard to ask really good questions and without going without making the survey a 15-20 minutes kind of thing because there's so much nuance we can't capture in three, four five questions.
Ben Callahan (11:48)
It is.
Yeah, that's true.
Yeah, I was thinking as we were talking about this one in the deep, I was thinking maybe a better question would have been like, what is if you have to pick one, what's your top concern? Right. Because that would have forced people to choose between like incorrect usage versus, you know, feedback loops, the loss of feedback loops. You know, when I looked at this list, I thought to myself,
Kaelig (12:21)
Mm-hmm.
Ben Callahan (12:24)
The feedback loop one is to me the most critical one. Like it doesn't matter. Some of these other things it's like if we at least have a process in place to gather and learn from our consumers, it helps resolve any of the other concerns, you know. So that's probably where I would have selected if I had to choose one.
Kaelig (12:44)
Yeah,
a stack-ranked type of answer would have been useful to not just pick one, but also be able to say this I care more about. ⁓ And I agree with you because it...
Ben Callahan (12:47)
Yeah, that's true.
Kaelig (12:59)
Yeah, this is what everything depends on. It's... How can you learn?
Ben Callahan (13:04)
Yeah. Yeah. And it came up again in the deep dive. I'm sure we'll touch on it here. ⁓ That third question was about the balance between enforcement and enablement. It's sort of a, almost like a frame of mind that system teams take. And it was really interesting. It was very balanced, you know. ⁓
a tiny bit more towards enablement, think is what the data showed, but it was almost negligible. And ⁓ I think what we heard in the other answers, there were quite a few, think it was, let's see, 14 % of folks answered other on this one. And when we dug into...
why they did so and we read sort of a little bit more nuance from their answers. I think a lot of them were saying, hey, don't make me choose between enforcement and enablement. And I think even ⁓ Alexander and Robin both during the deep dive called out this idea that like at different layers of my system, I need.
different things. And so I think I heard this idea and this aligns with a lot of what we know about, you know, pace layers and shearing layers from Stewart Brand and others in the the design system space to who have applied that that thinking right where like the lower something is in those layers, the more quality is so important and we have to be so much more careful. Right. Those are the foundational pieces. And so perhaps.
there's ⁓ something to connect to with like lower layers in your system, more foundational layers need some enforcement and we can move more towards enablement at the higher layers. Do you agree with that assessment?
Kaelig (14:35)
Yeah, I agree with it. I would say yes and the time component, as in if you look at the software development lifecycle where you start diverging a lot, you do a lot of prototyping, even the bad ideas are welcome. In fact, one way to have good ideas is to try a lot of bad ideas and to do that,
you need to free yourself from the system sometimes. In fact, if you introduce systems too early, you might forgo many really good ideas that the system wouldn't have supported, but you were limited in your choice from the get-go. So there is ⁓ a time to do more enforcement and a time to just let go and let people roam free.
Ben Callahan (15:20)
Yeah.
Yeah. And so there's like layers here, right? Because so we talked about the idea of like, ⁓ sort of like foundational versus more ⁓ like further out on the architecture. like fundamental layers moving up through things like components and then ultimately into patterns and workflows.
Kaelig (15:54)
Yeah, so that's vertical.
Ben Callahan (15:55)
that's vertical pass through. And then you're saying there's this sort of time consideration, like when is the right moment to introduce more ⁓ flexibility or enablement into the process and when do we need to have more rigor or enforcement? And so that's another one. And then the other thing that I heard you say, I think in the deep dive was that there are also certain tasks where we don't want to open it up to ⁓ variety, right? Something like accessibility is like we cannot compromise there. And so
that's an area where we need more enforcement. And that's not at any specific layer that exists across the layers, you and across the time. So there's a lot of dimensions here, right?
Kaelig (16:35)
Yeah, and I'm seeing accessibility often being ⁓ part or sitting under design systems. ⁓ And I don't know if that's the right spot for them to sit in because it's almost a bigger consideration, like security and legal conformance, those kind of things that can, like the design system is a tool to achieve that. ⁓
But we're talking about those layers. I wonder if accessibility sits at the same layer as security and it needs to enforced when you are getting close to production, whether you're using design system or not.
Ben Callahan (17:09)
Mm-hmm.
Yeah, that's true. And that's a really good point because I would say that the healthiest design systems do not have everything your product needs to make every interaction. And so if you embed accessibility enforcement in the system, you're not touching all the surfaces that your end users will touch. ⁓
And you can broaden, obviously accessibility was a thing before we even had digital products, right? Like so the physical spaces that we operate in. So you could expand that out to be a much larger role inside of an organ. I think that's very smart. And then in that world, we're a much smaller slice of a very large concern.
And you said something there, Kayleigh, that reminded me of a question. We didn't actually get a lot of energy toward in the deep dive. But so let's go here and start. And I just want to hear your sort of response to this. This question we saw in the data, a couple of folks calling out this idea that they're feeling like.
As AI has really taken the center stage in their organization, the design system team has become the place where the org is relying on these people to define how we will use AI in a sort of product builder kind of way. And so that's in us. That's like a very different.
world than maybe we all kind of came to the role expecting when we did. This got me thinking, should we be rethinking our team structures, our skills, our careers? What is your thought on this idea?
Kaelig (18:53)
Yeah, I mean, the best design system practitioners I know are great educators. And this is essentially taking that to the next level. How do we educate the designers of tomorrow, which a lot of them are going to be agents, to do good design, to build good product. And so to understand what is the job, it's no longer pushing pixels. It's less and less creating components and maintaining them.
It's more and more teaching the robots how to fish. And so I think it's going to go more and more towards that. So if you're somebody who struggles with communicating ideas, work on that. This is going to be such a great unlock for you because all of a sudden you can manage, you can break down problems in a way that agents can act on them, on solving them. ⁓ And you can scale that.
know how. Like if you have great talent in code or in design and you want to scale yourself, this is a great time to do that. So I think that's going to veer towards that more and more.
Ben Callahan (20:01)
Yeah.
Yeah, it's definitely got me thinking, you know, in the sort of coaching and consulting work, this is like one of the hottest topics people want to talk about is like, what do I need to do? How do I reshape my team, my systems team to be able to respond to this expectation from the organization? So ⁓ it's tricky because the same orgs that are like really pushing for AI enablement are oftentimes the ones that have a hard time.
getting the legal approval to do it in some way in the inside the org, know, actually giving the tools to the people. So that that definitely slows things down. But ⁓ OK, so I want to read this one. I loved this one answer. I need to look up who said this and send them a thank you card because I thought this was just so beautifully written. So this is in response to question four, which was us saying, hey, if you could kind of wave your magic wand, what would you change about?
your ability to get some visibility into your system. And this person said, the most useful thing would be lightweight embedded signal collection at the point of consumption.
system consumption like asset use rather than at the point of review. If contributors and consumers could flag uncertainty or deviation in context without it feeling like a compliance checkpoint, you'd surface real usage patterns before they compound into systemic drift. The goal is making visibility a byproduct of a normal workflow rather than a separate audit process that no one has time for. So I just want to like
Let you respond to that. Does that sit well with you, Kaelig? Is that how you would like to work?
Kaelig (21:46)
Yeah, it depends on, again, on the time in which this is introduced. But as we're getting closer to production, weaving those informational hints throughout the process makes it part of just that's how you work. It doesn't come in the way of you building great product. It just makes you better at it. I love that. And everything that's kind of just in time.
Ben Callahan (21:51)
Yeah.
Kaelig (22:14)
This is what you need to know right now is the way to go. That's what developer tooling is doing more and more. ⁓ so in terms of bringing that amazing part of the developer experience to designers, it's just, yes.
Ben Callahan (22:31)
Yeah, and you talked about how that is kind of a part of the developer workflow, and it's maybe not made its way into the designer workflow yet. ⁓ And we did see, we had Pegah Amadi come and do it. She's over in Redwoods, and she came and did a little demo of Magnolia, which is a tool she's been working on that's sort of like.
solves this, you know, in some interesting ways. And so she's got some really good writings. If you're ⁓ listening or watching, check out the Fig Jam link. There's a sticky note in there with some links to some of her articles more recently. ⁓ let's see. We referenced Donnie's show with Brad several times, and I haven't watched this one yet, so I need to get on there and do my homework.
Brad, think in this conversation mentioned something that you're also thinking about in this article you're working on called the Fog of War. I'm an old StarCraft player too, so we need to get a little SC2 game going, but ⁓ it's fun to hear somebody else talk about that. And you mentioned this idea of like, you know, like we...
You are comparing systems to this idea that we don't actually get to see all of that right the lack of visibility that we're talking about in this episode creates a sort of fog of war for us as practitioners. Can you just share a little bit more about that and how that sits with you in your workflows.
Kaelig (23:47)
Yeah, and the reason why I think about this is because it's easy to build the wrong thing if you don't have certain types of information, but you can't know everything at the same time because your attention in those games is the most important resource, really. There's obviously when you're getting your workers to mine minerals and to mine gas and whatnot, this is important. But the real attention ⁓ at high level, least professional level, is attention.
And the amount of multitasking these pro players can do, it's just absolutely crazy. But for your team, as a design system team, it's the same. There's so much multitasking. Design system teams are the ones that are typically the most bombarded of the entire company by questions because everybody's going to be using your stuff and wondering, how do I do this? How do I do that? Those are signals. Those are great. But as you're...
under attack by a swarm of and rushed by the Zerglings, ⁓ the people trying to use your stuff. You also need to have some proactive visibility and send little scouts across the company to understand what are people actually trying to build before they've even built it. And that's what in StarCraft, for example, you would send a scout unit
Ben Callahan (24:48)
Pyres are. Yeah. Yeah.
Kaelig (25:11)
that would go and see what the opponent is just about to build, enough that you have time to respond. you would think in terms of, so in other companies, it might be in terms of sprints or quarters, et cetera. In Starcraft, it's a matter of, okay, now I know I have 30 seconds to respond to this move that they're gonna make. And it's like a chess, but a little bit faster. ⁓ And with even one would...
Ben Callahan (25:36)
Yeah.
Kaelig (25:40)
argue potentially more complexity because it's a game of incomplete knowledge. so how do you apply that thinking and compose with that fog of war? Know that it's But sense, try to get the right signals at the right time so that you have time to respond to those changes in the landscape ⁓ instead of focusing on something that you thought was true. And the classic one in StarCraft is
you're building anti-air units and your opponent is switching completely the tech tree and building things that are going to be on the ground, super strong units, and you're like chilling with your anti-air and the entire army swarms you and you're like, oopsies, GG, good game. And it's the same for design systems. Like if you're focusing on building and date picker and everybody was like, this other team was really needed a data table, a data grid.
Ben Callahan (26:17)
Yeah.
Kaelig (26:37)
You spent weeks and so many cycles building something that they didn't need. ⁓ And how do you get those signals? How do I get those signals? Lots of relationship building, attending meetings at larger companies, small companies. Do people have roadmaps anymore?
Ben Callahan (26:45)
How do you?
Yeah, not often, at
least not that anybody can see.
Kaelig (27:03)
It changes week to week, so it's becoming even harder. ⁓ So attending roadmap sessions, trying to see what are they building right now that I can tell they're going to need some support from the design system at some point. ⁓ And if you have enough of those, can see you can start to, ⁓ or at least that's the way I do it, is I start drawing lines between those dots. And if there's some commonality,
then I bring that back to the team. And my role as a design team leader has been mostly to do a lot of de-risking, ⁓ proactive building for things that we know are definitely coming. And also that means dropping some things and say no to things that you were like, a year ago that was true, but it no longer is because they're just buildings, like very different stuff from what we thought they would be a year ago. It's hard to let go sometimes as well.
Ben Callahan (27:59)
Yeah.
Yeah, yeah. You're describing a process that is almost, you know, exactly scouting, just being aware, going out and doing the work to be to be aware. It's it's tricky because these processes like this that are so ⁓ relationship driven are really hard to
Kaelig (28:23)
also way easier ways to scout for your entire company's Google Drive for new keywords, new things that might be interesting. And so you can set up routines that just go across your Slack, go across your Drive.
Ben Callahan (28:30)
Hmm.
Kaelig (28:42)
in the support channel, looking at repeating kind of sentiment analysis of people's feedback, how quickly certain things were resolved. You can get so much of that data now for almost free for the price of just a few tokens. ⁓ So I would encourage people to do those things. You're right, it's hard to scale because it keeps on evolving. The tooling around this is becoming easier and easier. So if you over invest into something today,
and it's commoditized tomorrow, maybe that's time you could have spent doing way more important things. ⁓ I try to do... How little can I invest in getting that signal that's just good enough that it helps me ⁓ gather data and make good decisions. But again, the danger is to try to get perfect data. And again, the fog of war. You're not going to get it. Things just keep on changing so fast.
Ben Callahan (29:26)
Yeah.
Yeah, right.
Yes,
they do, they do. ⁓
Let's see, let's pivot a little bit to, so I thought this was a really interesting correlation. I'm always, as we do these episodes, I'm always looking for ways to sort of like see new patterns in the way people respond based on how they answer other questions. And so I ran a little analysis with ⁓ the anonymized data using Claude. And I just asked it to map the answers to question four, which was the enforcement versus enablement against the answers to question one, which was the amount of visibility that folks have.
And there was actually a pretty clear pattern that emerged, which you can kind of see going from dark red in the bottom left to dark green in the top right. Those colors represent the way folks answered that enforcement versus enablement questions. So dark red meaning significant enforcement, ⁓ light reds slight enforcement, gray is the same and then out to significant enablement on the green side. And you can kind of see that pattern really emerge that as.
we move up these layers from little or no visibility into how the system's used to robust and automated tracking, things turn more green. And so that means that folks who have little visibility are asking for or desire more enforcement. And folks who have... ⁓
more visibility as opposed to the less visibility in the bottom are looking for more enablement, you know? And so this connects to some of the other things we've been talking about, but did you, I mean, I never would have thought of this before we answered, but how does this sit with you? How does this make you feel about the work?
Kaelig (31:22)
Yeah, I love that you did that. That's awesome. Such a good idea. ⁓ My hunch on this, and it's a trend that I've seen across most design systems I've worked with, ⁓ it's that at the very beginning, when you have no metrics, no ⁓ adoption even, your goal is to try to tame the chaos that has become your user interface or your product for years without a design system. ⁓
or disparate design systems. And so of course, your goal is to try to get it under control to get some sense of coherence and consistency. And then further, the further you get adopted, you have to think more about, oh, maybe we need to chill a bit on enforcement because everything is starting to look the same. We've become so successful that nothing stands out. It's just
Ben Callahan (32:11)
You
Kaelig (32:21)
all a ⁓ bland, everybody's reverting, like converging to the mean, which is just use the system. And that's, yeah, I love that you're zooming on that part of the FigJam because that's what we discovered at Shopify, but not every design system goes through that kind of success story where you have to ask yourself those questions of backtracking on consistency. So yeah, those two talks from CalPete who...
is the instigator of Polaris at Shopify and then Gisenya who took over ⁓ a few years later. And those are just awesome ways of understanding what's going on there.
Ben Callahan (33:00)
Yeah, just send. He had joined me for an episode a ⁓ few months back and we talked about this article, the plot beyond the plateau of sameness. Such a good piece. I reference this often at this point, and she's such a great systems thinker. I've not watched this from Kyle Pete. I'll have to check this out. So thanks for that. Thanks for that resource. ⁓
Kaelig (33:17)
So good, yeah.
Ben Callahan (33:20)
Yeah, it's interesting. I think we, this is where we got Tony and chiming in and saying, Hey, the less visibility you have, the easier it is to make assumptions about what people are doing and why. And so, you know, the idea of like conversation and discussion and just like literally getting in the room with somebody and like trying to like have some empathy for them. That's, think a posture that I look for and I see in the most successful design system teams is one of curiosity. It's not, if you've deviated, there's a problem and I want to go fix it. It's if you.
deviated what can I learn because you did you know what did we not give you or how did we not make it visible or discoverable you know and so ⁓ that that posture in my mind is maybe like probably the I would guess is the best indicator about whether a system team will build something that's actually successful in an organization so I love that these ⁓ two separate questions kind of came together to show that
What else do want to talk about, man? This was a really fun episode. I feel like we only scratched the surface. There's so much more to dig into here.
Kaelig (34:23)
Yeah, I feel quite depleted because that was just a lot to take in. ⁓ And that's awesome. That gives me so much to think about for the piece. And even as I'm thinking about the future of design systems and how it can help folks in this community to thrive in this new environment where I think it's going to be a pretty big pivot for a lot of people, especially on the design side. I think developers are going to have such a good time.
design engineers, I think it's gonna be the place to be. But if you've never coded in your life, or if this is kind of, starting to get into it, it's possible that you need to rethink quite a bit about your role. And so I'm trying to help, like how do we do that?
Ben Callahan (35:10)
Yeah.
It's definitely needed. A lot of folks are feeling a lot of pressure right now. I know this, you know, I'm hearing those conversations and ⁓ we talk about this all the time over in Redwoods. ⁓ just ⁓ want to say to you, Kaelig, I really do appreciate the generosity with which you share in the community. It's been instrumental in so many folks careers and ⁓ the success of so many systems programs. So thanks for all the work you're doing for the community. ⁓ I'm hoping that you will
be out in San Francisco in June when Redwoods is doing our next community hike. If you're interested in joining us at this hike, we are going to go to Muir Woods, which is the home of the coastal Redwoods. ⁓
John Muir wrote some amazing things about nature in all of the Sierra Nevada area and out into Muir Woods, the national monument there. We've got a couple of sponsors that have stepped up. Sparkbox is a design system studio. That's my company and my business partner agreed, hey, we want to support the community in this way. So we're stepping up to make that happen. And then Brad and TJ of South Left and Brad Frost Webb have stepped up with their new AI and design systems course to sponsor
and make this happen. there's very limited space for this. can only take a certain number of people on the bus over. And so if you're interested in joining us, if you're in SF or if you'll be at config this year in June, get on the list. There's a link there in the FigJam file. Kaelig, will you come join us? Yes.
Kaelig (36:40)
I will be there for sure and
⁓ I'm scared about the amount of nerd-manship that's gonna be on this bus.
Ben Callahan (36:49)
It's going to be awesome. We did this when we were at Converge over in Bristol last year in October. I did a little research and found there was a small stand of coastal redwoods just outside of Bristol. So we had Penpot and Zero Height sponsored and they got us a bus and they bought us lunch and we went and saw the trees and it was epic, man. So it's going to be fun. Yeah.
Kaelig (37:08)
it. Amazing.
Ben Callahan (37:11)
Kaelig, thank you, buddy. I really appreciate you. Looking forward to having your continued insights in the community, and maybe we'll have you back on at some point. Thank you. All right, cheers, bye.
Kaelig (37:19)
Thank you, Ben. You're awesome.
Ben Callahan (37:25)
Thank you so much for joining us on this episode of The Question. Remember, you can get access to the raw data, the collaborative FigJam, and all of the recordings for this episode and many more on my website, bencallahan.com
If you or your team could use an outside perspective in your design system efforts, I'd be honored to support you in that way. There's more information about my coaching and consulting offerings over on the site. And if you need a hand building a sustainable design system program, my studio Sparkbox is standing by ready to partner.
Sparkbox is an investment in your design system and your team. Reach out and let's see if there's a good fit. Thanks for being here and remember, stay in learning mode.