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:01)
Hello, system thinkers. My name is Ben Callahan and I am so excited to welcome my dear friend, Vitaly Friedman here. Vitaly, thank you so much for joining me for episode 71 and for sticking around for an extra half an hour here to just recap the things that we've learned. Thank you so much.
Vitaly Friedman (00:17)
Thank you so much for having me, Ben. It's a pleasure. think I was actually quite surprised by some of the things that we learned in that session. So, wow, that's a great community you have here. So let's go.
Ben Callahan (00:27)
Yeah, it's an amazing group of folks. ⁓ I feel very fortunate to be surrounded by so many people who are so generous with their knowledge. know, people share so openly in the conversations, which makes it a lot of fun. ⁓ If you've never joined The Question before, the way it works is on Monday we send a question. On Wednesday, I send an invitation to anybody who's answered to join us for the deep dive that we just hosted on Thursday. Those usually happen at noon Eastern on Thursday. And then.
I ask my co-host to stick around for an extra few minutes just to talk about the things that we observed during the deep dive. And so Vitaly and I here will just kind of walk through what we covered. ⁓ In our early conversations prior to the deep dive, we were talking about some of the work that Vitaly's been doing. And so ⁓ it sounds to me, Vitaly, like you've been working on some very complex pieces of software and...
Vitaly Friedman (01:18)
mean, things are complex until you understand how they work internally and how all the relationships in between are functioning and all of that. But I would say that there is a of a combination of complex domain, a lot of people involved and just relatively complex systems, often also with a wonderful sparkle of a beautiful legacy somewhere in the middle. So that's always fun.
Ben Callahan (01:41)
Yes, and we'll definitely get into some conversation around legacy because that was a big topic during the deep dive. ⁓ We landed on a context that sort of referred back to some old agile thinking from early 2000s from Alastair Coburn, who wrote this book called Agile Software Development, which is a very, very well known piece of writing. If you're in the software world and you have gray beard like I do. ⁓
Vitaly Friedman (01:47)
Exactly.
Ben Callahan (02:08)
And so from this, we looked at his Coburn scale, which is this way of sort of like comparing the criticality of a piece of software with the size of the engineering team and using that matrix to ⁓ impact the way you approach the software. And so in that scale, he gives us the criticality side of the scale, which is on the y-axis. And that covers ⁓
a series of four different options. You can see this if you take a peek wherever you're listening, take a look, you'll find the link to the FigJam. Take a peek and you can see the matrix. He covers that scale of criticality starting at loss of comfort, increasing to loss of discretionary money, then to loss of essential money and then to loss of life. And so he kind of layers that scale across these four dimensions and then compares that with the size of engineers working at the team size of engineers working on the product and
has some different groupings, five different groupings for the team size. And so we asked that same question of our folks here on the question. We asked them to assess their most critical piece of software's ⁓ criticality on that same scale. And then we asked them to ⁓ describe the size of the team. So pick one of those categories of engineering team sizes that work on that critical product. And then we gave them two questions that were a little bit more open text.
The first was, how do you ensure that your design system adequately supports the criticality and scale of the product? And last question, the fourth was, is someone in your organization doing workflow analysis with the users of this product? And if so, describe that approach. We sent this question out to 1,069 design system practitioners. We got 61 responses this week.
And as always, wherever you're listening, you can get the link to the raw data where you can do your own evaluation of this data. ⁓ Vitaly, the first question kind of blew me away. It was overwhelmingly people identified that the sort of criticality of their software was loss of essential money. And I just didn't know. I've never actually asked this question of anybody before. And so I was very curious to see this. But what were you expecting when we asked this?
Vitaly Friedman (04:23)
Well, this is actually quite surprising for me to find out because usually when it comes to like in my world, right, this is often the lack of or the loss of reputation or the loss of trust or anything similar that comes up. And I think to a lot of people who were answering this question, this is ultimately the proxy towards.
Ben Callahan (04:33)
Mmm.
Vitaly Friedman (04:43)
Kind of whatever is that can go wrong and what I mean by that is that very often you will end up of course eventually with a loss of money on the in the end side of things but what can contribute to this could be many many many different things. So it could be just a product probably implemented not clearly defined not clearly designed ⁓ something that is causing more confusion than help or anything similar maybe just poor discoverability as well. So you pour a lot of money and resources and efforts into something maybe AI something
And then as a result of that, you basically don't see a retention. You don't see that feature being used. Now that's a loss of money, right? If it's, you know, it's one thing if it's discretionary or essential money, but those projects can be quite expensive. And I mean, that's probably a bit of a stretch on my end here, but I would say that the loss of essential money is probably the ultimate negative outcome. But there is a lot of stuff that is happening in kind of before that, that eventually will drive.
to the loss of potential money. And so for example, if you're working in I don't know, a fintech application, right, what we desperately want to avoid is to communicate any poor or inaccurate insights or data. Now that would be a deal breaker. And so if you have, let's say a design system that is basically communicating some ins or not communicating, but that's, I would say presenting in some ways used to present insights to people, but those insights then are presented in...
in a sort of chart type that is very difficult to read or can be confusing or maybe even lies to people, then when people make decisions on that, well, then definitely will lose some money, hopefully not essential, but that could also be a part of it. Right. So I think it's kind of the ultimate, the ultimate ⁓ outcome of it, but not necessarily the immediate one.
Ben Callahan (06:29)
Yeah, it's a really good observation. And I think a lot of folks were feeling this as we asked this question of them right there sitting in that moment trying to figure out, what's my most critical product that the system supports here and how would I rank it in this way? And we got lots of interesting ⁓ input in the other, which was also we always give spokes and out if they can't choose one of our options. You mentioned loss of reputation, loss of trust.
But we also saw folks mention things like loss of transparency, right? Loss of essential data to make informed decisions, loss of future compatibility, and even somebody who works in the government space saying all of these are relevant for our products. So ⁓ really interesting to see. And I think it made me wonder if we were to either invite Alastair to join us to reimagine this scale, or if we took our own ⁓ approach at trying to gauge
Vitaly Friedman (07:20)
Yep.
Ben Callahan (07:25)
today's criticality of software, we might come up with a slightly different model, you know?
Vitaly Friedman (07:28)
Yeah.
I think also when it comes to digital products today, I think we are getting to the point where
We kind of know how to design things and we kind of know how to build things. We can also allow systems to do that for us if we wanted to. But I think frankly that all of those things will probably stay relevant for years to come. Because I mean, if you look into something like hyper personalization that is happening, or if you look at the personalization of the UI for every single user, customization of the UI for every single user. Well, if we do all of
that how do we know what is actually happening how do we know what the user experience is like
Ben Callahan (08:13)
That's such a good point.
Vitaly Friedman (08:14)
Do
we even know? I mean, everybody has their own experience and some of it will be good, some of it will be bad. And so what we will find out, I think, basically stories from loud voices and loud voices are usually not the ones where everything is just fine, but where something goes wrong. And so we probably will be hearing about loss of money, loss of, I hope not, loss of discretionary money and all of that. And so these are just expressions, I guess, of some...
Challenges that we are going to deal with especially when we can design and build anything relatively quickly relatively easily but then we need to be very deliberate in about what we're designing and I think the design system will make and will be even more crucial part of that journey because somewhere all those decisions that have to be made or that have been made must be documented and I guess this would be the place I mean totally going off topic here, but a friend of mine ⁓ told me just what
Ben Callahan (08:50)
Mm-hmm.
Vitaly Friedman (09:11)
literally one a week ago, one phrase that really stuck with me. He said, well, we need to think about decisions being made today as infrastructure. And I said, what do mean by that? Well, in the world where we maybe are using AI in order to generate things or make decisions or, I don't know, draw insights from data, if you have, let's say, knowledge base in a company,
that knowledge base must be up to date. And so that means that decisions that are being made across organization must end up becoming a part of a markdown file somewhere. They must be written down. They must be added in similar to pull requests and all. Just in that meeting, we decided this, right? And in that meeting, we decided this. And so with that, you have basically a growing markdown file or skills, whatever you want to call it, that basically defines what has happened. And with it, along with it, also priorities.
Right? Because this is always evolving because organization is moving always, sometimes slower, sometimes faster. Right? And so decisions, ⁓ the cornerstone of everything. Right. And if anything, like if those decisions do not get their way of find a way to markdown files or design system or whatever we want to call it, then somebody on the other side end of it will never learn a bit about it. And then you have potentially really poor consequences of that.
for company, for organization, for people, for teams, for individuals. So there is a lot to unpack here, I think.
Ben Callahan (10:41)
Yeah.
There really is. And I love the sort of, we didn't cover this in the deep dive, but this idea of generative UI or ephemeral UI or phrases that I've heard that like, we need to be building products that create UI for specific use cases for specific users in the moment. you know, I don't think that we had the tooling to even do that in the past. And people see,
AI tools as a way to do that, I think. And so this sort of ultimately customizable experience, what I heard you saying, Vitaliy, is like, how do we even validate that? Right? Like if we don't know what this system will build as a potential UI in a specific moment for a specific user's needs, how do we validate that? And the answer has to be, we encode all the potential outputs in rules and in these markdown files or whatever.
Vitaly Friedman (11:24)
Nope.
Ben Callahan (11:40)
structure format we need, but in guidelines in barriers, don't go beyond these kinds of experiences, things like this. so, yeah, the system is right now the likely place for those things to live. And that puts a lot of responsibility on a system team.
Vitaly Friedman (11:57)
Yeah, I think it's also probably the question. mean, we're going off track here right away. But I think, I think it's for me, this is also a point where we, ⁓ I mean, it's a really kind of philosophical question for me, because I think like a lot of parts that we were doing in the past, right, we first automated them. And now we also AI find them with automation, right. And so it goes through everything. So it goes through design, it goes through the code, writing code, it goes through create, it goes through
Ben Callahan (12:02)
That's okay.
Yeah
Vitaly Friedman (12:25)
shipping goes through deployment like all of that stuff if all of the and then of course UI then as well and if all of this is fully automated or AI fives Which of course different things right then we end up in a situation where a single person who is coming to the website or using a digital product Will have their own customized experience that is adapted for them and their needs I mean we obviously see this in infinite scroll feeds on LinkedIn and so on support anyway, right, but the point for me is
So if we wanted to verify that, you how are we doing? How good is that experience? Now, you can of course look at metrics like retention and engagement and all of that, but it's not applicable to every environment. In enterprise environment where people just need to complete the tasks, right? And maybe there are agents completing those tasks for them. So the work is done, but then you need to look for accuracy, right? Not just completion rates, but like factual accuracy, things like that.
Ben Callahan (13:19)
Yeah.
Vitaly Friedman (13:21)
And so you might have, of course, other AI agents doing that to track the work of the other agents and then creating more agents to monitor other agents. But then I'm just really, maybe I'm overcomplicating things. So maybe if we're looking, let's say, at airplanes, it's not like a human is involved in monitoring every single piece of an airplane. It's all automated, right? But then I am wondering, like critically,
where and what is the role of a human in all of this? We can't just let it all go and hope for the best, right? There must be something in between.
Ben Callahan (13:52)
I know. And you could take it further.
Right. Like it's possible that the users that we're optimizing these UIs for are actually AIs too, right? Like an individual may just be like, I don't want to browse that website. I'm going to just have Claude whatever go do it for me, you know? So, Yeah. Yeah.
Vitaly Friedman (14:02)
Could, sure, sure.
Yeah, but then, you know, Claude doesn't need UI and Claude needs just a good API to connect to. That's all it needs, right? So,
I mean, I just lost a little bit at this point because I really don't know. And I think that this all creates this notion of poor visibility into the system because there is just so much happening at any given second. And you can of course rely on other tools that are making sense of all the data that's streaming at you. But then if it's again, ⁓ AI, you just hope for the best. So...
Ben Callahan (14:26)
Yes.
Vitaly Friedman (14:39)
Yeah, so that if anything that kind of increases the criticality of the system and that affects all those things that we are covering in the scale here too.
Ben Callahan (14:48)
Yeah, yeah. It's funny in the AI space, there's a phrase to describe this, which is called flying blind. And it's used to sort of refer to these moments where we actually don't understand the inner workings of how some algorithm or some AI model is coming to the answers it's coming to. But we see and perceive that it's doing so well. And so we continue to build layers on top of that.
Vitaly Friedman (14:55)
Mm-hmm.
Ben Callahan (15:14)
And what that means is like the more layers you build on top of a system that you just don't understand, the more unstable that becomes, right? That's flying blind. And I think it's especially easy for us to kind of fall into that these days because it is very difficult to understand why these systems are working, you know, so.
Vitaly Friedman (15:33)
But Ben, flying blind is nice, right? You just sit down and get a cup of coffee, hopefully a good coffee, and then you just give it a task and then it does it and then you look at it and you think it's fine and then you move on, right? But it has some consequences. Yeah, yeah.
Ben Callahan (15:47)
Yes, it's nice until it's not. Yeah, yeah.
My goodness, we could we could do this forever, Vitaly Thank you for just diving in with me. This is great. That second question was on the scale of teams, and we just got a very sort of even distribution here. Nothing surprising there. We did take a minute just to map those out sort of on the original kind of Coburn scale. I just used the number of dots to refer to the number of individuals who's
self-assessment of their criticality on the y-axis and team size on the x-axis sort of position them in one of these boxes. So you can definitely see the number of loss of essential money as like the one that sort of stands out that row. But you can also see that we had folks kind of across the entire spectrum, which is kind of cool to see that the diversity of scenarios within which ⁓ our community is operating. So that's ⁓ Where to go next? I actually kind of...
We had a few folks who asked this question in the answer. The last question was around workflow analysis, and they were like, hey, what do you mean by that? Because I think we know what these words mean, but that could mean something different to many different people. Can you give us just like a short version of what you meant by this phrase, workflow analysis?
Vitaly Friedman (17:01)
Yeah.
So typically there are two types of analysis that we do when we're dealing in complex environments. I mean, there are plenty more, but these are the ones that are very important to me because I'm using them frequently. That would be a task analysis and workflow analysis. And so with task analysis, we try to understand what is it that people are doing when they try to complete a task. ⁓ you know, literally what goes into this to make sure that they are successful in that. Successful in many different ways, speed, accuracy.
⁓ resilience, whatever, anything of that kind. And that usually is a particular part of a journey. Like if you think about again, financial market, have maybe a fintech application, somebody has a portfolio of stocks and so they need to bring this portfolio of stocks into the system. So that would be something like an import portfolio. So that would be a task that they're performing. We need them to excel at that. So we need to understand what is required to do that.
But then on the other hand, you also end up in situations where people are basically going through a series of different tasks and series of workflows, well, parts of the workflow that are required for success. And so that typically is when people are dealing with a lot of people, other people, systems, products, when there a lot of collaboration, interaction, when that's not just a task, this is literally a workflow from start till the end.
that could also include processes, systems, legacy and third parties and so on and so forth. So we need to understand what are people doing full stop, right? Literally across different tools, different systems, different products and ultimately, you know, if they want to, let's say, invest money, right? That's a journey. So that's a workflow that they're going to go through. They're going to look into things like candle charts, they're going to look into the...
stock screening tools, they're going to look into recommendations and expert reviews and news and we kind of need to understand how it all works. So it's not really a task. It's not a kind of a close ended. It's more like a journey and eventually they're making a decision or not. Right. And so that's also nonlinear very often. So we kind of need to understand what is going on there across different domains, be it tooling, be it the frequency of use of particular features in a particular product.
Ben Callahan (18:59)
Mm-hmm.
Vitaly Friedman (19:20)
how the data flows, how the interaction with other people or other systems works, right, and all of that. And so this is sort of the workflow analysis. So task analysis is for individual tasks, workflow analysis for slightly larger things that involve also a lot of people in other systems.
Ben Callahan (19:37)
Yeah. Tell me the like, what was the hypothesis that you had that sort of led you to want to ask about this in the context of criticality?
Vitaly Friedman (19:47)
Yeah, so in my world, it's very important to get this right. I'll put it this way. I really need to understand what people are doing, right? And what systems they're using. Like is it one screen? Is it 14 screens that they're using for work? When do they use it? Do they use it here or there? Do they use it with other people? What other systems are installed on the platform that they're using? What is on the tabs in the browser and all of that? That kind of gives me some context about what is it that people are
where people leave basically to do that job that they need to do, right? Because they will be spending probably five to eight hours doing this in one way or another. And so this is very important. And me spending a bit of time in, I would say, products and systems that, I mean, don't necessarily have high criticality, I would say, but they have a lot of implications of when things go wrong. Right? So that can have again, like damage in reputation, damage in trust, damage in...
Usage drop-offs, of course, and other things as well. So getting this right, I think is a cornerstone of making sure that people are successful in the end. I mean, it's probably not necessary for, let's say, designing ⁓ a landing page or so, right? You basically have a particular task that people need to complete, which is, you know, buying a book. And of course, you have a wonderful book coming up, I heard, right? But in general,
Ben Callahan (21:14)
Excellent, excellent transition.
Vitaly Friedman (21:16)
I'm trying my best here, Ben, trying
my best. But then this is really important, I think, to get anywhere close to the point where you understand the domain, the tasks involved, you know, I guess also the workflow involved. So that's why I brought it up.
Ben Callahan (21:31)
Yeah.
Yeah. So maybe to summarize what I hear you saying is there was a hypothesis that as the criticality of the products a system supports increases, we would hope that there's more of this kind of thinking task analysis workflow analysis happening in the org to validate that the system is serving those products. Well, yeah. Yeah. So that's something that I was looking for. I assumed that's kind of what you were thinking. And I did spend some time looking for that.
Vitaly Friedman (21:53)
Exactly.
Ben Callahan (22:01)
trend in the data, and I actually did not find it. And of course, our sample size is low and I always... I'm always careful for us to never think that this data is statistically significant. We've got a very biased group of folks, albeit very smart, but they're systems thinkers. They're very focused in their world. And so we're not really sampling a broad set of folks and that kind of thing. But...
Vitaly Friedman (22:05)
Yep. That's a very sad moment of my career, everyone.
Ben Callahan (22:30)
What I did see, ⁓ and again, sort of take this with a grain of salt, but was that we saw that depending on team size, the workflow analysis did change, right? And so for smaller teams, there were blockers to having the time and space to do that kind of thinking, right? They're too busy. They're not operating at scale yet. There's not enough time, right? It's not a priority. For the mid-size teams, it was usually a little bit more structural kind of bureaucracy.
⁓ No dedicated UX research function. ⁓ Sometimes it was political, know, optics, politics, that sort of thing. ⁓ And then for the largest teams, so teams that had massive engineering organizations, this stuff is actually happening, but it's kind of removed from our audience, the system practitioners, right? It's in a separate function. It's kind of siloed and set aside. And sometimes they have some visibility there, but a lot of times they don't, you know, they're trusting that those teams are doing their jobs well. So.
⁓ It was interesting, Hattie described this scenario where, she works at a large org, she has safety teams that are giving her inputs as a system practitioner that she needs to honor, right? Like the safety concerns of their product, which is a large physical tractor that they make and lots of other heavy machinery. And so her system team has to take all that safety stuff into consideration, but it's not her responsibility as the systems practitioner.
to validate that the product teams are implementing those things well, right? She owns the responsibility of the system, but product teams consuming that system are sort of held responsible for implementing the safety measures accurately in product. And so it's an interesting, it's like the separation. We talk about this a lot in systems that we are, you know, removed from the end users in a certain amount, in a lot of ways. And so we have to have a really close partnership with our product teams to make sure they're...
Vitaly Friedman (24:14)
Mm. Mm.
Ben Callahan (24:25)
have getting the things they need from us to be able to meet those demands. know, interesting. So, yeah, lots to think about here. ⁓ We had a fat. Yeah, we had a really fascinating conversation. ⁓ Guy kind of said, hey, I want to hear from some of the folks who answered in their question and self-assessed that their product is ⁓ life critical. Right. Yeah.
Vitaly Friedman (24:29)
Yeah. Yeah.
It will keep him busy for a while I think,
Critical.
Ben Callahan (24:54)
loss of life on the critical scale. And so we had a bunch of interesting conversations here. ⁓ this just like opened up the conversation. Taylor jumped in from Mayo Clinic about how, you know, like he definitely sees that this impacts the way he thinks. He's asking a lot more questions. He's talking to a lot of folks. He's got, you know, whole security teams and safety teams to consult with. And so it does impact the work to a certain extent. But it also I also heard him saying that
in some ways it does, in some ways it doesn't. Like, how did you interpret that comment or that part of the deep dive, Vitaly?
Vitaly Friedman (25:32)
Yeah, I think it very often feels like, you know, well, we building a design system and so we basically are defining the rules and the interaction patterns and the voice and tone and the principles and the usual things, right? And so, yeah, we do it for one system, do it for one product, we do it for another product. is, you know, the criticality of the product is not really defined by that. But at the same time, like when you start thinking about it and you look into what you are building here,
Ben Callahan (25:55)
Mm-hmm.
Vitaly Friedman (26:02)
there are always these external influences that actually shape your work as well. And it was interesting for me to hear him coming in and saying, well, there are different layers, right? Literally all these different layers that we're dealing with, obviously there is going to be like a security or privacy team, legal team, and all of those things that kind of need to be...
Ben Callahan (26:12)
Yeah.
Vitaly Friedman (26:23)
defining the guidelines and then those guidelines need to kind of find their way to sprinkle all over the work that is being done. So when you then bring those all those components, all this flow, all those things together, right, then they must follow along. And it's like, you know, there is this famous saying that, well, if you have one elephant, if you split the elephant, you don't get two elephants. That's not how it works, right? So you can't just say, well, we're going to make this whole thing like
Ben Callahan (26:46)
Hmm.
Vitaly Friedman (26:53)
a very important rule or very important ⁓ guideline and then that guideline is defined and then we're going to sprinkle it across all those different components or so. Well, you still need to governance around it as well, right? And so I think you kind of end up with the design system being sandwiched between the work done by the product team and also the work that is expected to be done or the quality assessment or the quality
Ben Callahan (27:16)
Mm-hmm.
Vitaly Friedman (27:20)
guidelines that are coming from the top and so you are just in the middle, right? And eventually you have to connect the dots as well because in a good well-operating systems all those things are somehow connected, right? Then you have relationships established as well. So whether you want it or not eventually it just finds a way, it's just not very clear at times how does it find its way in the design system, right? one thing that I kind of brought up
Ben Callahan (27:42)
Yeah, it's such a good point.
Vitaly Friedman (27:46)
is that when you think about, let's say, dashboards and you're designing a system that includes charts, right, and different chart types, well, you can just pull together a couple of charts in a dashboard and then you have that, but then if you are not careful and you're communicating a particular data with a wrong chart type, so people don't understand it well or they misread it or they misinterpret it, then it might have negative consequences, right?
especially if you are in an environment which is all about the money or health or anything similar. So the question is how do we then adjust our design system to accommodate for that? Now that requires for more kind of accuracy and consideration. I guess that this is what Taylor was also speaking about.
Ben Callahan (28:32)
Yeah. And especially today, the speed with which our systems operate, like making a choice in the moment in some interface and a browser can result in money being gone from your account in a matter of seconds. And so that speed almost makes the criticality even more important in some sense. ⁓ In the chat, ⁓ the Zoom chat during the deep dive, there were a couple examples that folks dropped around this idea of like, hey,
There are scenarios out there where people have made very ⁓ poor decisions because of the interfaces that a product has given them and that's resulted in loss of life or many examples of loss of essential money. So I think ⁓ there is a requirement here for us to really think about this stuff. ⁓ I think the last area that I'd love to...
just kind of quickly hit on would be, and it's one that you brought up, which is this idea of legacy software. Can you give us just the context here? Like why did you bring this into the conversation?
Vitaly Friedman (29:35)
Yeah, because I think like a lot of times the troubles come in not necessarily from things that are new and shiny and work as expected, but things that are almost like black boxes where you just don't know what's happening in there. And that's always a risk factor. The reason why I brought it up because I feel like it was maybe Kele think, who was speaking specifically about things like, well, there are a lot of things that we need to consider as well. So they're going beyond the usual stuff that are untouchables almost, right? So you can never like go in and just say,
Ben Callahan (29:47)
Yeah.
Yeah.
Vitaly Friedman (30:05)
I'm going to change the legacy system. This is extremely dangerous because you're breaking the ways of working, you're breaking the habits, you're political capital. So for some people the legacy product that they were building and maybe releasing, I don't know, 10 years ago, it's almost a part of their identity. You cannot just remove it, but this is like you're really removing the part of their identity, so they get also very defensive as a result of that. And so you end up in a situation where you always have to consider
that magical legacy thing as a big potential risk. And I think that when we're speaking about kind of the levels of severity or the criticality, we're thinking about things that can go wrong, thinking about risk mitigation or risk management. And we are trying to make sure that we install some sort of systems in place or...
I don't know, a working place that reduces the chance of those things happening. But this becomes almost impossible with legacy, because you have something that a lot of flows will go through, be data flows, user flows or anything between. that's it. just, know, stuff will just go through it. And so you might be craving the most polished design system ever. But because you have a lot of flows that are going through a very fragile, old, semi-broken
⁓ legacy, usually with a very different flow, with a very different UI, with a very different everything, accessibility, performance and so on, you have a critical point of failure and we can design the most remarkable products in the world, which will break at the point where they shouldn't break or where they will confuse people where they shouldn't. And that for me personally brings up this really challenging part because you kind of have
Ben Callahan (31:39)
Yeah.
Mm-hmm.
Vitaly Friedman (32:00)
Everything done fairly well, but then if you have one point one critical point that a lot of people are going through that breaks. Well, that's a criticality right there
Ben Callahan (32:09)
Yeah. Yeah. We have such little control over the legacy software. I'm actually a fan of legacy stuff, right? Like the fact that a piece of software lives long enough to be called legacy means it has served purpose as well, right? Like generally that stuff doesn't stick around if it doesn't work. So it's valuable in that sense, but it also does create this almost like it's like the lowest common denominator for failure in a lot of scenarios like this.
Vitaly Friedman (32:21)
Yeah, that's true.
Yep.
Ben Callahan (32:39)
It sounds like we need to do another conversation around legacy software because there's a lot to unpack.
Vitaly Friedman (32:42)
Justin, I think also,
yeah, also just one more point on that. And I think was actually quite interesting is that we're now we're talking about legacy, right? And of course we can automate a lot of things and we can use AI as well to migrate from legacy software and legacy UI, would say in the new design system view and all. But one thing that's important there is of course that when you are moving or transferring or changing legacy in some way, you're also affecting existing ways of working. You never migrate just
Ben Callahan (33:10)
Yeah.
Vitaly Friedman (33:12)
product, a legacy product, also migrate flows, ways of thinking, procedures, protocols, and everything in between. And that's extremely risky. I mean, we are operating at the heart of the business at this point. And so this requires an extra caution in all. And I think any product that contains legacy in some way, despite every single effort of incredible designers working on it, ⁓
Ben Callahan (33:15)
Right.
Goodness, yeah.
Vitaly Friedman (33:40)
is a potential really, really huge risk and security risk and threat. And with that also, criticality.
Ben Callahan (33:50)
Yeah, yeah, it's a really good point. There's just so much change that has to come if you're going to move like foundational pieces of software like this. And it's something that we have to do, right? Like all the time, this is a part of the work, you know, and in any enterprise, right? Yeah.
Vitaly Friedman (34:06)
Yeah, well luckily
Ben we have wonderful people like you who are obsessed and possessed by ⁓ legacy systems and is willing to spend days and nights working through them and improving them so we'll be fine.
Ben Callahan (34:15)
Yeah.
That's right.
That's right. Yeah, hopefully. Yeah, Vitaly. It's always so much fun to talk to you, my friend. Thank you for sharing so much of your experience with the community in this way. I've got a little bio of yours in the FigJam file where you can get in the comments or in the show notes for this conversation. Vitaly, give us just like a one minute rundown. What are all the things that are happening in your space? I know you've got so much going on.
Vitaly Friedman (34:25)
My pleasure.
Ben Callahan (34:46)
You
Vitaly Friedman (34:46)
Well,
I don't even know where to start. I think most of my life is actually working with teams trying to improve whatever it is that they have. would say processes, systems, sometimes also legacy as well. So that's sort of like the world in which I'm living. I also have, well, obviously I also have wonderful Smashing conferences happening. have Smashing workshops happening, Smashing books happening as well with one wonderful book by Ben coming in soon. Right. And... ⁓
Ben Callahan (35:10)
There it is.
Vitaly Friedman (35:12)
Also working on a few video courses, just recently released one on design patterns for AI. But then there is also a more strategic one about how to measure UX and design impact and also in general interface design patterns. I've been obsessed with design patterns. I think maybe a bit too much of my life. And so all of this has a house, a really friendly home now. Video course is also growing because I find always something to record a video on.
Ben Callahan (35:18)
Mm-hmm.
A long time, yes.
Vitaly Friedman (35:40)
like with four or five sessions added in there every year. I don't know, I think that I'm really looking desperately for any design patterns or anything that requires attention. I've been obsessing, just to give you an example, I've been obsessing over language selectors for something like five months. And this was back in 2022. And now it's 2026 at this at the moment when we're recording this. I think I'm running out of patterns.
Except legacy, legacy I should really touch more closely. I will seek your advice, Ben, on that.
Ben Callahan (36:14)
There you go. Well, you could you could find some really fun ones. Yeah,
all right. Well, let's collaborate. That sounds great. There's so many ways to get connected to the great work that Vitaly is doing. Please check out these events And of course, I know that he and I both really value the community. So get connected to us on LinkedIn, Blue Sky, wherever you're doing your sort of social network stuff these days.
⁓ All of my information is in here as well. I really truly it's like my favorite part of the week when someone reaches out and they're just like, they just want to talk shop, you know, so please don't hesitate to do that. There's tons of other resources in here. Redwoods is open. Would love to if you like this kind of collaborative learning. That's what we do all day, every day in Redwoods. It's amazing. Incredible folks in that community. It's true. I don't I don't see much ⁓ so many good resources from the Redwoods community that have been published in the last couple of weeks. So check out these articles.
Vitaly Friedman (36:58)
Yeah, Ben never sleeps. Never.
Ben Callahan (37:08)
⁓ It's awesome to have this community of folks to rely on Vitaly again. Thanks again. I really do appreciate you friend.
Vitaly Friedman (37:16)
Thank you so much Ben, it's a pleasure to be here and be a part of this wonderful community. Thanks for putting it up.
Ben Callahan (37:20)
Cheers.
Ben Callahan (37:22)
Thank you so much for joining us on Episode 071 of The Question. This format doesn't work unless folks like you are willing to share some of your experience and then show up here in learning mode. 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 on your design system program, I'd be honored to support you in that way.
There's much more information about my individual and team coaching programs over on the website. Thanks for being here and remember, stay in learning mode.