Mohit SantRam: I think we should have done shots before this. You know, like, that might have helped or something like that. So...

Clinton Bonner: (Laughing) You guys didn't? 

Mohit: No.

Kevin McGrath: (Laughing) No.

(CATALYST INTRO MUSIC)

Clinton: Welcome to Catalyst, the Launch by NTT Data podcast. Catalyst is an ongoing discussion for digital leaders dissatisfied with the status quo and yet optimistic about what's possible through smart technology and great people. In today's episode, we're diving deep into a topic that often flies under the radar, but has major implications for the success of digital products. We are talking design debt. To help us unpack this critical issue, we're joined by two experts in the field: Kevin McGrath and Mohit SantRam. Kevin is a Design Director here at Launch, and is a seasoned professional with extensive experience in product design and user experience. Mohit brings a wealth of knowledge from his years in design strategy and implementation, and is an Associate Creative Director here at Launch. Design debt, much like its better known cousin, technical debt, can silently accumulate over time, leading to significant challenges and a ton of inefficiencies. When businesses cut corners on design, whether due to financial pressures or the need for quick fixes, the long-term consequences can be really severe. Today, we'll explore what design debt is, how it manifests, its impact on organizations, and most importantly, how to address and mitigate it. Kevin and Mo, welcome to the podcast. We're pumped to have you in the studio for the first time. How are we doing? Kevin, how are you doing, man?

Kevin: Doing great, thanks. Thanks for having us today, Clinton.

Clinton: Of course. Thank you so much. Mohit. I see the beautiful Launch hoodie in your background there, man. Good job with that. How are you doing today?

Mohit: Awesome. Thanks for having us here. Clinton.

Clinton: I want to say thank you guys. You guys brought this to me. We use Slack internally. We talk a lot about collaboration and communications on this podcast. It's just so crucial, right? So, for me to understand, like, what are topics people need to hear about? And what are some... We said earlier, like, under the radar things that maybe just aren't being brought up as much as they really need to be? Everybody talks about technical debt. Everybody gets that. But this topic of design debt really intrigued me. So, Mohit, let's start here. If you had to define design debt, what does it mean for you? And, you know, how big of a thing are we talking here, man?

Mohit: That's a great question, Clinton. I think it's a very big thing. Specifically, I think that design debt means the culmination or the grouping of decisions that were made to circumvent specific areas of user experience, research and design work. These decisions usually were likely made for a variety of reasons. Specifically, quick-shifting business decisions. Design, development and product shortcuts. Time, budget, and team constraints. Optimizing short-term gains versus long term goals. Scaling teams and missing specific opportunities.

Clinton: Quite encompassing, is what it boils down to. Lots of ways that it can either creep in or show up. So Kevin, what would you add to that, or how would you define it? Are there different words you might use?

Kevin: 100% agree. I think something that jumps out to me is really important is the debt part of that. Because just like technical debt and just like real debt, it compounds over time if not addressed, right? So, every fix you want to make or new feature you want to develop, it just gets harder and harder and more and more expensive as you have these additional layers of inefficiency. And if it gets really bad, things can get so slow and so expensive that it completely kills your momentum and potentially kills your product. So it can be really serious if it's not addressed. 

Clinton: Alright. So, Kevin, I'm going to follow up there. Is it similar to, you know, like we said in the opening, a cousin to technical debt? Or is this really more a form of technical debt, from your perspective?

Kevin: They overlap in a lot of ways. So, for example, if you're properly fixing your front-end tech debt, that kind of goes hand in hand with building a design system framework. And a lot of the modern tools that we use to do that are a spot where developers and designers are working together. So we think of design debt and we call it out specifically because technical debt doesn't encompass everything that design debt considers. But there's a lot of overlap there, and they stem from a lot of the same core issues, the same core business decisions about being fast and cheap instead of having a strong foundation and taking the time to do things right.

Clinton: Glad we got to expand that, or define it a little bit deeper for the audience. So, appreciate that. You're mentioning design debt and how it accumulates from skipping some essential steps. And you mentioned, like, research or validation, and you led out with that. Can you give some examples of some common shortcuts you've seen companies take that do lead to this accumulation of design debt? So we got some types. You know, research and validation. But maybe examples, and things you've actually felt on the ground, where you're in a conversation and someone's like, okay, whatever it is, we're not going to do this thing. And, you know, your spidey sense goes off, your alarm bells start going off. So, Mohit, why don't you start? 

Mohit: Sure. I think, like, making assumptions that we don't necessarily need to go through specific areas of user research, or we don't need to talk with users and to understand fully what the problems that they might be having. Specifically, understanding the pain points and the areas of friction that they're experiencing on a daily basis. Also, along the lines of, like, testing. And making sure that the products that we're building actually work, and that they answer the pain points and the problems that these users are experiencing. Validating all of the concerns and testing all of these things can add to a lot of short-term gains. So, for example, if a company wanted to skip over these things because they felt they didn't need to do these things, or they didn't have the time or the budget or the personnel to carry out all of these tasks, they may decide to skip some of these tasks so that they could save some amount of money.

Clinton: Kevin, I think I'll toss it to you. Mohit’s saying save money, but is that maybe just an illusion and a perception of savings? And is this a bit of a monkey's paw situation here, man?

Kevin: I think so, yeah. You know, pretty often, I understand the pressure that businesses are under to continue to deliver new features and new products. But if you opt for quick wins and MVP's and you never take the time to circle back to planning for this future vision and planning scalability, yeah, okay, you're saving money on this one feature, but every new feature you release is going to be more and more expensive. And you end up with a sort of death by a thousand cuts situation.

Clinton: In that particular example, you release a feature, you get your... Your instant gratification, right? Like, hit of dopamine because you got it out to market faster. Like, congrats, check the box, you hit your date. And then you're suffering down the line. What are some of the things that come out down the line that you've experienced, Kevin, and seen, when that shortcut is taken by an organization early on?

Kevin: Maybe this is me, in particular, the ones I've worked on, but I tend to work on sort of cross-platform customer experiences, where maybe they have two different portals, they're building two different technologies, and because they do one really quickly, they don't take the time to go back and update the other one to match, and you end up with a disjointed user experience. Or you have a design system that's not being implemented correctly across both of these things. So, users have a hard time coming back and understanding how to use that feature in the second product, because it's totally different from how they used it in the first.

Clinton: Got it. I understand that part. So, Kevin, any other shortcuts that come to mind for you?

Kevin: Yeah, I mean, quick fixes isn't always just when it comes to releasing a product. Sometimes it's about your organization, also. So I think not hiring the right people is a common shortcut we'll see. Orgs that want to save money on design will understaff the team, or they'll hire lots of junior designers because, you know, they're less expensive. But those junior designers maybe don't know how to manage design debt, or they don't know how to build executive level support for the investment it takes to do things right. So it's both, like, in your day-to-day process of building a product, but also in your team organization, and the tools and the process you use to collaborate as an org.

Clinton: So, that really brings me into another question I had for you guys around... You're talking about hiring and making sure that you have the right people there, or at least you're accessing and working, bringing in the right partners. If you're not in the, you know, the arena to hire. That makes me think about design leadership and maybe the lack thereof. So, Mo, if you're going into a client environment, what are some of the symptoms or senses you get, if there just simply is a lack of design leadership? How do you know it when you see it?

Mohit: There's another great question there, Clinton. I do think that there's... A lot of times there are a lot of signs that you'll see. So, for example, for an organization that may take shortcuts, there may not be advocate for fighting for the user, or there might not be a person who might not recognize that there is a long-term loss by assuming or taking on design debt. For someone to be able to recognize and to say, this is great, we're optimizing certain features, or making sure that we are releasing code or products in a given time frame. Or it might be, as you pointed out earlier, might be choosing to use more junior designers or developers or product folks to be able to build out a product. That might indicate to me that someone is making a... Taking a shortcut, and not necessarily accepting that there are better choices to be made, or that should be made, to make sure that a product is released correctly and satisfies the business goals that were the whole reason for building the product in the first place.

Clinton: Kevin, bouncing it back over to you, how about those telltale signs? You know, is there a couple of things you see? Or, you know, you start to get under the hood with a client, and what are some of the things you start to hear from them where you're like, oh, boy. They may not realize it, but they are suffering from this design debt, but they probably just don't know any better. 

Kevin: There are things, I think, that you don't have to be a designer to always see. So things like complaints from users. If your support team and your sales team keep coming back and saying, we're hearing the same UX complaints over and over from users, and we're having low customer satisfaction scores, low feature adoption metrics, we've got these brand degradation issues going on, that's a sign right there. High maintenance costs. So when a client talks about how it takes them a ton of time to just release something new, or they tried to build something and it cost them a fortune and it was incredibly slow, that's because they don't have a strong foundation in place. But I think, honestly, the biggest thing that jumps out to me, and the thing I would ask any leader who's not in the design space to think about and look for is team frustration. I think the human factor is where you really start to see this, where you have designers and developers who are frustrated over the complexity of their day-to-day work. And in more extreme situations, team turnover. Difficulty hiring and retaining the kind of people who are able to solve these challenges for you.

Mohit: I'd like to add in, too, that there are some other signs too. So, for example, inconsistent experiences. To what Kevin was saying, thinking about the increased time that it takes to design, develop and ship product features. When a code base is out of sync, or a design system isn't fully being utilized in the correct manner, you'll find that there might be many shortcuts, and those might crop up from visual inconsistencies that I mentioned before. And thinking about the satisfaction that the people on the team that are building those products, if their satisfaction starts to go down, or the complexity of the content or the work that they're doing takes a markedly bad turn, that's definitely a sign that there is not enough attention being given to this design debt that's being built up over time.

Clinton: Yeah. What's really interesting about what you guys both said to me is that... I would hope, for the audience's sake, that when they're, if they're, feel like they might be suffering from this, or even they might start, even sense it, that it could be there, it's like, hey, there's actually a pretty wide array of people that you can go talk to. And Kevin, when you mentioned turnover, it's like, well, you can go look at, maybe go talk with HR. Like, literally get into the HR data, like, hey, are we seeing turnover inside this part of the organization? Why? Like, what's what's going on with those exit interviews? Like, okay, they're frustrated. Why are they frustrated? And I would say all the way over to, if there's a chief experience officer or a chief digital officer. And talk to the people that are trying to work and figure out those, because they care deeply. Like, their job is to examine, unearth, and really care for every single digital transaction or digital experience that could possibly be out there. And of course, that's a pretty tall tale. There could be thousands upon thousands. But that is their charter. And I think talking with that team and uncovering their frustrations, and I think that might actually bubble up, Kevin, with the pace you were talking about. They're probably getting inundated by the business constantly. Then they feel that maybe they can't deliver it as quick as they want to, or feel like they should be able to, and they could go talk to the business. That might be another great telltale sign. Yeah, we have a two-year roadmap. And nothing seems to really get done. And when it does get done, it's not exactly knocking socks off, right? So, if you want to get to the bottom of it, there's probably multiple people you can go have conversations with, which I think is fascinating. It's pretty cool.

Kevin: Yeah, 100%. They might have slightly different ways of articulating it, but I think if you talk to all of them, you'll be able to see the commonality there. Yeah.

Clinton: So, Mo, let's say they did this research, and they discovered that, yeah, it is design debt that is the culprit. Like, I'm sure you guys have been in situations where you've had to present that news. So, if there's not a design leader within the organization that you're working with, how do you represent that? And how do you make, you know, let's say a CEO or a CIO or a digital officer, give a damn? So they take the information and then act on it?

Mohit: Great question. I do think that it's really identifying the root of the problem. And I think it's having a frank and open conversation with the leadership over at the client, per se, that might have been ignoring some of the telltale signs. I think as digital storytellers and product developers and creators, it is our job to make sure that we are conveying what that story is to all participants. So, if a design advocate on our side sees that there is something that's being missed, it's important for us to be able to recognize what those things are, package up an actual story, show actual data. So, for example, as Kevin was alluding to earlier, the amount of time that it may take to deliver or to ship a specific product feature or an actual product itself... If that time starts to lengthen, because, let's say, the design system is out of sync, or the developers are frustrated by the code base being very complex, it is important for us to be able to take all of that information and to be able to articulate that by showing exactly how much time something has taken to be released or developed or designed. And then to come back and say, well, under the ideal situations, or in other instances, this is how much time a feature should take, in ideal situations. And then start to build a story or a pathway as to, how we can bridge from where we are to where we should be. Paying down design debt is a very arduous task, but it's an important one that companies will have to take on at certain points. It's up to us, I think, as designers, as advocates, as developers, as leaders, to come back to those leaders on our client side and say, these are the symptoms, these are the actual problems, this is the area which we can help you address. And these are the specific steps that we can take to get back on track.

Clinton: So then, Kevin, how difficult can that be for... I don't want to say the average designer, because that's just painting with a terribly broad brush. However, that's not usually what they do there in their day-to-day. And it's not what they were educated on, and it's not the things that they go to conferences for, right? But that is a business problem. They've got to get, like, change management accomplished from their perspective. And Mo, as you said, framing it in a business problem. That there's data, that things are taking too long, and it's costing us money and revenue and profit and services, et cetera, et cetera. How difficult can that be for most designers to actually make that argument and make it stick?

Kevin: It can definitely be a tough one for designers who are new, who are junior, or just sort of new to the technology space. Because you're right, you don't go to school, design school to learn that kind of a thing. You go to design school to learn how to build these great products and experiences. And I think part of the catch-22 challenge is that, also, designers don't want to have to communicate this. I know that sounds a little weird, but, like, you want to be building stuff, and all the time that you have to spend getting buy-in from leadership and convincing people that this is important is time you're not getting to spend building a fantastic product. So it's kind of challenging on two fronts there. It's both.

Clinton: Yeah.

Kevin: The communication takes time to learn how to do that, and also it can often feel like a distraction. Like, it's important, obviously, but it's time taken away from building a fantastic experience.

Clinton: Right. And it leans back into the point you made earlier about the importance of design leadership. Hopefully they're at, someone at the C-suite level, but if they're not really tied in so that the voice is there and the pulse is always there, so folks understand how things are going in the world of making sure things are really smooth, that you can operate, and that design is not a bottleneck. Because, you know, design is always meant to be... It's the highly collaborative, we can go fast, we can get the clickable prototypes, we can show you the future and we can do that pretty darn quickly. That's why design leadership and having that voice could be super important. And if you don't have it at your organization, well then at least when you're working with your providers and your partners, making sure they do. And making sure that they can be that advocate. Because without it, I would imagine things like this will probably just keep piling up and not get addressed, is my, you know, my intuition on that one. So, Mo, I'll toss you this too. We've identified design debt. We have buy-in. We made the case. People are like, get it. You're right. We gotta go tackle this. What are some of the tactical things they should be doing... After the decision's been made. Yeah, we do need to tackle this. How do you start to compile that... There's so much you could go do first. What are you focused on?

Mohit: I think it's important to first recognize what the problem is. And specifically, what are the symptoms? Or why do these design, why does design debt get accrued in the first place? Understanding what that process might be from a decision making process, or, are there the right people? Do we have enough staff? Do we have the right people at the right levels that have the ability to make those decisions? And then to be able to say, okay, from that standpoint, what are the most important areas where we can have the most amount of impact? If it is going back and looking at a design system that's out of date, will updating a design system to make it easier for developers to find the information that they need, so that they're not dependent upon bottlenecks or decisions from other folks, whether it's product or design or business, to be able to execute certain areas of code? If that's an area where we can help them optimize, then we will certainly help prioritize the areas that are important first. It's also, I think, important to help them understand the choices that they're making and the ramifications. So, choosing a short-term win over a long-term loss, I think will create collateral damage. And it's important for us to say, this is the result. So, in the future, to help educate them, when this comes up, when there is a decision that might need to be made and we might circumvent certain aspects of design or thinking, whether strategic or product or engineering thinking, it's going to be important to understand that this is what might happen. So, helping them recognize what the symptoms of the problems are, what the effects of those problems might be, but then also how to avoid those in the first place, is something that we can help them do.

Clinton: Yeah, that makes a ton of sense. For sure, Mo. And then... Another thing that I certainly have experienced in my, whatever, 13 or 14 years... I've been in technology. Now I'm a marketer. I talk about technology. I don't code. However, I end up talking with lots of different leadership, different folks that certainly are in technology and can get under the hood. One of the biggest things that I see that works over and over and over again, and whether this is design debt or some other topic, is getting wins on the board early and gaining momentum to kind of show early value that your hypothesis, it has some green shoots and then maybe even some early wins. So Kevin, are there some low-cost kind of quick wins that orgs can look at if they're starting to look at reduction of design debt? Is there a few that you'd line up and say, yeah, do these first if the intention is, show quick value, gain momentum?

Kevin: Yeah, it's a good question. It's a tough one. Because I think it depends on the level of the design debt. If the level of design debt is on the lower side, then yes, absolutely. You can introduce a design system, if you haven't been working one. You can overhaul the one that you're using, or try to tie it more to a front-end framework for efficiency there. You can add a design ops function to your team. If you don't have someone who's sort of responsible for that, you can hire a new role or make that a managerial role, that will go a long way. You can also... Maybe it's a little bit opposite of a quick win, but you can sort of make the decision to slow down a feature release and give the time, the team some more bandwidth to build a scalable solution, right? If you do, like, a sprint cadence. Say, like, alright. The fourth sprint, we're going to focus on scaling and turning what we've been building before into a more robust foundation. You can uplevel design leadership. Really easy to take a design leader who's doing well right now and just give them more strategic visibility, more voice at a leadership level. So I think if the design debt's not too bad... Yeah, there's a bunch of stuff you can do. But if the problem has festered, right? If the design debt has really accumulated, there's really no way around the fact that it's high-cost and significant time to fix things. And that's a tough spot to be in because you have to fix it. The longer you wait, the more expensive the fix is going to be. And you have to maybe push back a little bit against the idea of getting quick wins and momentum, because you don't want to start building new things or doing new things that are just going to make the debt worse. If it's really bad, you gotta sit down and have a real conversation about, how do we go back to square one and do a little bit of a reset on this stuff? Because we've let it go for too long.

Clinton: That's a great answer, man. I love the fact that... It comes with the weight, that you have to have some judgment about the situation at hand and be honest about that. There's not some black and white line that goes, okay, that one extra thing and it's severe versus more mild, so therefore go for the quick wins. But I think it's a really intelligent thing to call out that there is some line there to understand that whether or not, which bucket do you fall in? Even though there's a gradient, of course. And where quick wins for one of them can get you momentum, can be successful, can be something that is positive. And then Mo, I saw you nodding along there when Kevin was answering. But in the other case, when it's really severe, you actually might be doing yourself a disservice if you just go for the quick wins. Is there anything that you could add to that, or examples that you've had to fight, in a positive way, with a client about, hey, we've got to delay some gratification to do it the right way?

Mohit: Another great question here. We have a current client that we're working with who, again, limited budget. They want to release a lot of work really, really quickly. They've got a limited set of users that are using this product internally, that is being used to broadcast a lot of information externally. And it's important for those folks to be able to input information into the system easily. But what we found is that sometimes, when we are keeping a frenetic pace of trying to release a lot of code, or to release a lot of features that may not have gone through enough vetting or thinking from a systems design standpoint, we tend to lose, because what happens is that, well, we're going to build this for a couple of users, let's just get this code out. And what we find is that the overall time that it takes for us to release that code, and release that specific feature, takes so much more time. Because we go really far, we've released a bunch of designs, and then we uncover a problem. And this specific problem, we could have uncovered in a much earlier phase had we gone through the process of going through research and making sure that we were talking to users and thinking about pain points and doing all of the work that we initially should be doing. And what we find is that later, that collateral damage that we mentioned before, that starts to crop up. For us to be able to say, let's take a quick win of thinking about specific developers as an example, that might be more engaged by making sure that they are feeling as if they're being listened to, or the recommendations that product and UX and engineering might be providing to to a client are being heard. That is a really good quick win. I think that might have a longer-term effect of being able to help undo the damages from design debt that have been incurred.

Clinton: In terms of, okay, so, in that case, I'm thinking maybe you've got someone who's got a charter, right? They have a roadmap. And their job is probably measured by how many, possibly, how many features they get out. You know, and then of course, they can measure uptake and all that stuff down the road. So they're in product and they're really aligned to making sure all the JIRA tickets get done, and that this frickin' product gets out with the features we promised, and if not, their butt could be on the line. If that's the person making the call, ultimately, because they own the product, let's say, what do you need to say to them so that they come to your side?

Kevin: Yeah, it's a challenge. And part of that's sort of the unique nature of the work that we do. As you know, we're not designers who are embedded in a product organization. We're hired as experts to come in and support clients who are going through these challenges. So, it's sort of like, first you have to make sure that the direct client that we're working with understands it. Then you have to figure out how bad it is. Then, you have to help them be the change agent within their own organization to communicate it back and get that mindset shift about, okay, we can't be just judging based on the success of, like, how many features do we ship? We need to change how we judge based on, maybe, how many people adopt those features. Right? That's, I think, to me, a more significant measure of how useful a product is, how many of the users are actually engaging with it, rather than how many did you shove out the door. And I think that's sometimes the most rewarding part of, when we get to dig into projects that are really deep in this, is we can really be somebody's partner in helping them fix this real problem. Because something Mo and I have talked about before is that, when orgs have become accustomed to doing things the wrong way, to skipping research, to saying, enh, it's good enough, that becomes a cultural thing that is really tough to undo, and it can be very disruptive to shake an org out of that. But, you know what? They need disrupting. That's the way it works.

Mohit: And I think also, to add to that, I think sometimes, you know, like, the habits that are ingrained by those types of decision making processes are hard to shake. And it takes a little bit of work for us to be able to recognize and to help them recognize why they're doing certain things, or why they have these types of thinking baked into their corporate culture. As Kevin is talking about being change agents, it's important for us to be able to show them, these are the shortcomings. And this is why. But yet there is a rosier path, there is a more productive path, following more ideals.

Clinton: The fascinating part for me is that so many of the conversations on this podcast, on the Catalyst podcast, they end up boiling up or boiling down to tough leadership conversations and change management. It's just... Over and over. And I think it's because, or at least I think one of the things that the commonality is, we're always discussing about doing this inside the enterprise. And the enterprise is big and gnarly. And there's lots of people and there's levels and there's personalities and there's politics, there's all these things. And it's kind of cool that a discussion that starts with this problem of this design debt is at least partly solved by being an honest challenger, great communications and helping - you said it, Kevin - like, maybe taking the anti-hero and then making them the hero of the story. Or, they're the ones that are detractor and you gotta, like, hug the hater, get them to see it your way. And then they've gotta be the vocal advocate, because they're the one in the room with the team. That they go out for beers with, maybe, or at least see virtually and hang out and do trivia with. You know, like, that's a real thing to get around. That's very... It's... For me, it's very cool to hear that too, because you just don't talk about design that way very often, because folks are so... I don't wanna say folks, humans. We're so visual. So, we love the shiny stuff. We love the fast, clickable prototypes. But underneath that is a lot of hard work to get organizations ready to accept the truth, and then get better. Which I think is really fascinating. So, let's weave in the omnipresent, and potentially omnipotent, topic of AI. Right? So, AI is everywhere and for good reason. What about AI? Mo, I'll start with you. Are companies looking at the combination of AI plus humans to specifically address design debt? Are there paths there where that could be successful and used in that way?

Mohit: Absolutely. I think that a lot of companies are probably looking at the promise of AI to help automate certain specific tasks. As UX practitioners and designers, it's important for us to always fight for users and to help represent their needs. But when we think about, sometimes, the time that it takes to do certain aspects of our work, it can be time-intensive. It can be cost-expensive as well. So I think a lot of companies might look at some of these AI tools, and we may, as well, to be able to help speed up some of the lower-level tasks, or to be able to think about, what are things that we can do and automate, that are necessary? That may not have gotten the light shone upon them, or it may have gotten cut in the past. But if we could use AI to help use that technology to do that type of work, and that allows us as practitioners to really think about, and spending more time on strategic standpoints, or thinking about the areas that actually needs more specific focus, I think that will provide, or could provide, real cost benefits, as well as experience benefits, for companies building digital products.

Clinton: So, Kevin, on the AI topic, anything you would add to what Mo said?

Kevin: Mo and I are both members of the design team's AI Guild, so we actually get to chat about this pretty often, which is fun. I have some concerns about AI's impact on design debt. I suspect a lot of businesses are going to see, on YouTube or TikTok, some design tool where they say, oh gosh, I can put in a prompt and it's going to design a screen for me and that means I don't need this robust design framework. But that is not a scalable solution, right? So I do worry a little bit that the short-sighted approaches to AI will make design debt significantly worse for businesses that don't already have a mature design approach, and don't really understand the danger from doing that. Something we get to talk about in the Guild sometimes is that historically, new technology doesn't always give people time back, but rather raises the expectations of what they can achieve in the time they're given. So, AI tools that accelerate designers' ability to do the little tactical things... If organizations think, okay, that means you've got time to just do more stuff instead of an opportunity to step back and think about, how do you have a scalable solution, then it's not going to solve anything. So I think really, it's the organizational practices are going to be the thing that determines design debt. And AI is kind of just one of the many tools that designers are going to use for it.

Clinton: Again, I love the nuance, and a little bit of the yin and yang that we've got in the... It can be that accelerant and it can collapse some time frames, and then the... The bit of a warning of, okay, but be careful what the expectations are and how you then go use that time, and not just to go maybe bang out the next thing, versus, maybe some deeper work that could happen to, you know, change how you do some of the work, too. So some great thoughts there. One last question, I'll start with you, Kevin. So, looking ahead, what other trends or emerging tech do you see playing either a significant role or a burgeoning role in helping orgs understand and then go at their design debt?

Kevin: Mo already called out a lot of cool opportunities on the horizon around accelerating design systems and documentation and research. Two things that kind of jump out to me is that, design system frameworks are becoming more and more accessible. React, Tailwind, Angular, those are all things that have better and better support for design systems approach. Token systems are finally getting official support in tools like Figma, despite having been a thing designers have talked about for a decade. So, a lot of these systems are becoming more accessible. And I think, kind of, as design system approaches and scalable design becomes the standard in this sort of core digital product space, those best practices have a cool way of starting to work their way into other digital product areas. So, like, last year, we had a client who wanted to move more into the immersive and real-time 3D space, but they were worried about managing design debt in this totally new technology. One that doesn't go hand in hand with Figma. So we built a first of its kind design system tool to help automate that process, so they can not be worried about having this explosion of design debt just from trying to adopt a new technology.

Clinton: And I know that project. I wish I could name who it was. But I know what it was, and I've seen the internal case study, and it's like, oh, that is such a cool, such a cool use case. And again, the creativity and the invention of, okay, this is a new business problem. But you queued it up really cool, Kevin, that the client understood, we're venturing into this new collaborative environment. And if we're not careful, if we just start guns blazing, if you will, go out and start creating things without a semblance of what this new system needs to do, we're going to end up in a situation where we can't scale, we can't replicate, we're just chunked down, and you're going to have to have people with exquisite domain knowledge of that specific tool to do anything, and then nobody could use it, which was the exact opposite purpose of making it collaborative and more shareable in the first place.

Kevin: Yeah,

Clinton: So really, really cool, really cool vignette there. Mohit, anything else you'd add to, you know, future forecasting, if you will, of this particular area and tackling design debt?

Mohit: I'm just a huge fan. I just, I think we all love Figma, pretty much, but I think it's great to be able to see the democratization, I think, of access to a lot of the tools, and the pathways that we choose to be able to think about design. So, it's great, as an example, when I'm working with specific developers that are getting into Figma, as an example, as you know, Kevin's alluding to, many tools, just one of many. But when you see developers being able to embrace the technologies that we're using, and to be able to collaborate with them more openly, more quickly and more easily, so that the information or the dissemination of information goes from one person's brain to another person's brain pretty quickly, is really, really amazing. So, I just love the collaborative-ness of all the tools that we're using, and the fact that we can be spread out throughout the globe, if not all over the country, and to be able to make decisions very quickly, as opposed to thinking about things as they were earlier in our careers, that might have taken a large amount of time to have come to a specific decision. Now, I think that we can use tools to help us recognize that there is significant problems with design debt, and now we can help use some of those tools to help tackle those problems faster and sooner.

Clinton: I love this conversation. 12 out of ten, would recommend. Kevin and Mohit, thank you so much for joining us today and sharing your invaluable insights on design debt, your perspectives on how design debt, how it accumulates, the critical importance of addressing it, and the practical steps to mitigate it have shed a lot of light on this overlooked issue. As we've seen and learned today, ignoring it could lead to inconsistent user experiences, a ton of wasted resources and frustration, and even jeopardize the long-term success of the team and the business. But by recognizing it, having those tough conversations early, investing in the right practices and the right teams, and leveraging net new technologies and experimenting, you could turn the tide, and do it really, really well so that you could scale and have good flow and have happy people and great, great products out in the market as quick as they possibly can, and can get out there. So guys, thank you so much for being on the pod today. And for our listeners, we hope you found today's discussion as enlightening and inspiring as we did. Design debt might seem like an abstract concept, but its effects are clearly, very, very real and far reaching. And thanks again, guys. As always, thank you and please pass on these episodes to your friends, to your colleagues. We think they would enjoy them as well. Because in this studio we believe in shipping software over slideware, that fast will follow smooth, and aiming to create digital experiences that move millions is a very worthy pursuit. Join us next time as the pursuit continues on Catalyst, the Launch by NTT Data podcast.

(CATALYST OUTRO MUSIC)