← Insights Unlocked
Insights Unlocked
Designing trustworthy AI with the Sense, Shape, Steer framework
00:40:35
Learn how Bansi Mehta’s Sense, Shape, Steer framework helps teams design trustworthy, human-centered AI experiences users adopt.
Loading summary
Transcript31 lines
- [00:02]
A
Welcome back to Insights Unlocked. In this episode I'm joined by Banzi Mehta, founder and CEO of Koru ux, to talk about what it really takes to design thoughtful human centered AI experiences. We explore her Sense Shape Steer framework, the challenges teams face when adopting AI and why trust usability and continuous iteration matter more than simply adding new AI features. Enjoy the show.
- [00:31]
B
Welcome to Insights Unlocked, an original podcast from User Testing where we bring you candid conversations and stories with the thinkers, doers and builders behind some of the most successful digital products and experiences in the world, from concept to execution.
- [00:50]
A
Welcome to the Insights Unlocked podcast. I'm Nathan Isaacs, Principal Content Marketing Manager at User Testing and today I'm joined by Banzi Mehta, Founder and CEO of Koru ux, an award winning design agency focused on complex enterprise and healthcare products. She's a leading voice in designing AI experiences and the creator of the Sense Shape Steer framework. Welcome to the show, Banci.
- [01:15]
C
Well, thank you so much for having me, Nathan. I'm, I'm stoked. I'm very answered to be here.
- [01:22]
A
I'm glad you're here and I love that we're having this conversation when we're like exactly 12 and a half hours apart in time zones. So it's your evening, my morning and to kick things off, to kick us off on this day, can you tell us about your journey into UX and what led you to found Coru UX and how that experience has shaped the Sense Shape Steer framework?
- [01:48]
C
Oh wow, that's so.
- [01:49]
A
Well, I'm in just a sentence or two. Can you tell us?
- [01:56]
C
Well, I started my journey when the only expression of any sort of prototype was actually to write the HTML code. And that's how in a browser you would have any sort of GUI and people used to, yes, call it gui. So it feels really, really old. That's when I started and it was. It has been fascinating to see that how from there the behavioral science kind of became front and center. When I started Coru, it was back in 2011. I always had a bent for enterprise products. So what I was always drawn towards was the complexity that enterprise products often come with where you are invariably dealing with minimum three Persona using the same product. Right? So it's between three to five different Persona, conflicting priorities and one screen that needs to deliver on so many goals and tasks. People always fighting for every pixel of space. So how do you balance declutter versus what do you prioritize all of those things? I would say that we actually now live in really exciting time because in last two years I have found myself on multiple occasions solving the same problem, but now in a completely different way with AI still. So in healthcare some of the problems were like really, they're really established problems, right. And people have been trying to solve it. It is like fragmentation is of course one of it, but also the documentation, the amount of information, all of that. And with AI it's a whole new opportunity. So I find that very, very exciting really working with startups, taking on incubants, really reimagining and approaching that problem in a completely different way as well as even enterprises that are actually thinking that oh, we have, what we have is working, but now with AI, how, what can we do? What are the opportunities?
- [03:53]
A
So yeah, well that's interesting and it's going to kind of get into the topic that we're going to be talking about today and it's a conversation I'm hearing a lot in our own organization here at User Testing, but also with a lot of our customers and, and they're just trying to get a sense of like in this world of AI, you know, how do we do the things that we're doing? And I'm just wondering, you know, before we dive into the framework, can you just tell me like what, what made you see, what were you seeing in teams out there in healthcare teams and startups and so forth that made you realize that we needed something like the sense shape steer framework.
- [04:35]
C
But I would say a frenzy. Nathan, if I'm honest in the sense in the teams, like there's tremendous pressure from all ends. I have been in conversations where for private equity companies, the shareholders and investors are really creating pressure that everybody else in our portfolio are doing AI. Why are you not doing? And that's sometimes the pressure, sometimes it's really Gartner's quadrant or staying in Gartner's quadrant that's driving. Sometimes it's really like a few enthusiastic people within the team, they would actually prototype something like code something, have a proof of concept and everyone gets, gets excited that oh wow, we can do something like this. Now let's figure out, it's more like we have a solution now but let's find a problem to it, right? Or we have found something that looks or sounds really cool, but how do we make non tech people really understand what it is? Right? So those are some of the conversations within the market that I really actually not once but I kept, I came across it again and again. And on the other hand, really for design teams and product teams, how do you Approach it, where do you start and what is the process and method to it? Right, because it felt like the old ways or the traditional ways of approaching product or solving problems that were kind of failing us in the sense we were, yes, creating stuff, but it felt like that it's still a very superficial layer that we are touching upon and not going deep enough. Because with AI, if you stop at, for example, if it's conversational AI and if you stop at just the interface, then all you have is a chatbot, but the whole experience happens within it, right? And hence you have to get deeper and that's just one kind of AI interaction. So how do you approach different kind of problems? Where, I mean, for example, I've seen that where teams would come one with the POC another time where enterprises would say that, oh, we have these workflows, we in fact we actually did just UX transformation. But what about AI now, right? And what are the AI opportunities? Where do you start from? Do you say that, oh, let's map out every opportunity and then design it? Or you say that no, these are the low hanging fruits and then you start with it. And then of course there are startups where AI is the product, right? Where that's the front and center of it and it's an idea and now you're conceptualizing it from ground up. All of these are very different problems to handle and approach, especially with AI in the mix. And I personally thought that if, if we are struggling, I'm sure that lot of people would also be wondering about it and how can we bring some method to this madness? And to be very honest, that was, that's where the whole framework come into picture from.
- [07:36]
A
All right, all right. Yeah, it can feel overwhelming. And you know, I spent a couple weekends ago, I, I was tasked with trying to map out, you know, of all the things I do in marketing, you know, how would I do that with an agenic AI? And it just feels overwhelming. It just feels like a tidal wave is coming over you. And, and so let's get started with the sense, you know, teams are often under this pressure that we're talking about the just add AI or AI agents or whatever it may be. What do you do actually in that moment to help them slow down and reframe that problem?
- [08:17]
C
Well, it might sound not very innovative at all, but oftentimes what I feel is missing from the whole conversation when people are talking about AI is who is going to use it and what problem it's going to solve. So the whole set, whole sense Part of the framework is actually about saying that let's come together, let's slow down and let's really make sure that we have answers to what's happening here. So it really starts with one on one end identifying the problem space, or if we already know what is the problem, then at least laying it out. Because that way when we are thinking of opportunities, we can see that where is the overlap, right? So if you really look at the sense part of it, if I have to summarize it or give it in a gist, what it is, is about one, yes, we understand what are the user, what are the user needs or the problems. And then on the other end we say that what are the AI opportunities? And then where we see that, see the intersection, that's the sweet spot, that's what we are really looking at. But oftentimes it can be two very different things. I have seen where people would have some sort of an idea in terms of what we can do with AI, but not have a very good sense or understanding of what exact problem for the business, for the users it's going to solve, right? Sometimes it's like, no, there is a real opportunity, but we don't have enough insights in terms of the user needs and the problem space for us to confidently say that, yes, this will actually solve a problem. So since part of the whole framework is about defining who are the users, what is the context, what is our understanding of where is the problem or the friction point and how are they doing things currently? Because that tells a lot about it, right? That what is their frustration level, what would be this leap or the learning curve would be when we introduce something new which might be AI powered, which might be completely different way of working around it. So understanding that is, I would say, ever so more important than before. And then on the other end, where we really say that, okay, what ideas that we have in terms of AI opportunities, what are the specific tasks that we feel that AI can help with? And that's where you want to kind of map the jtvds in the sense the jobs to be done for the user and then say that what part of it AI can help with and in what capacity, right? Are we saying that it will completely automate it? Are we saying it will be an assistive role? Are we saying that it will be more of a suggestive? Are we saying it will be more working in the background and doing some of the groundwork? So this is where that conversation happens. So that's one part of it and another part of it is which is a conversation that I feel that teams oftentimes don't have, but it's a very important conversation to have. Is now when we say AI, it's not just the model, right? We have ncp, we have AI that can access the agent, AI that can access certain tools within the ecosystem, that can have certain ground truth that it can be trained on. And it's important to say that within the boundaries, within the realms of things, what does it have access to? And I'll give you an example there. It's one thing to say that, oh, we have let's say 6,000 plus customers and they all use. They have been doing the voice dictation and the scribe for a long time in terms of documenting the patient charts, right? But is that data available to us as a product team for us to learn from? And the answer is no, because that's phi. That is the data that is with the practices. And that data is not available for either. Forget actually training training, but even doing AI evals against, right? In which case what access we have, how are we going to really create that ground truth or the data set that is essential for this? So this is where we actually pause and also talk about what data AI has access to versus not. Because then what solution we think of and how do we create the user experience to set the right expectation. All of that actually has direct, direct dependency and relationship with. So that's one of the things that happens in this sense. And then along with that we actually talk about one very important thing, which is the risk and guardrail in the sense that this is an early conversation to talk about that. Okay, let's say for a moment that this is the solution we build and this is the problem we are trying to solve. It's of course all hypothesis, but this is where it feels like logically the right fit. Now, what could go wrong if AI makes a mistake? Right? And that's where we again start thinking about that. Okay, what are the guard risks? If we thought that it will be an autonomous mistake or kind of an AI, or if we thought that the whole product will be AI native and using AI is the only way of accomplishing something. In that case, yes, it becomes quite critical that we think about that. If AI is not available for whatever reason or it can make a mistake, then what can really go wrong, right? And is it reversible? What is the impact of it? What kind of oversight are human in the loop needed here? And where should it differ to humans versus what part of the heavy Lifting that AI can do. And that would be actually okay or in fact even welcomed by the users. So that's. And then we kind of end it with discussing briefly, because then there is a separate section altogether to talk about it, but briefly, that what would success look like? So success metrics, not really defining the AI events and criteria, but at least high level, having some sense of that. If what we are thinking works well, then what success would look like? Because again, oftentimes AI ideas start with a lot of excitement and we are not always thinking that would it actually move the needle? Would it actually make a difference? So when we kind of define the success metric, then it tells us that is it worth pursuing, is it meaty enough to even go forward with it? Or we kind of pivot or kill it right there. That could also happen. So that's about. Yeah, that's the sense part where the team kind of walk out of that with a sense of what is the AI opportunity and what is the problem that we think it's going to solve. So I call it an AI opportunity statement.
- [15:16]
A
Sure, sure. And a lot of, I think a lot of people have thought about that, and maybe not in those terms, but they think about like, oh yeah, are we actually solving a problem with this AI? I think the other questions that you raising there is like, what are the tools that we actually have access to right now? Right. You know, it's one thing to say, oh yeah, I'm going to do this, but if I'm still using tools, you know, from two decades ago, especially in the healthcare space where they're using, you know, old antiquated software, they may not even be able to do any of this kind of stuff. The then I think about just like, and I think you bring this up as like, oh, I'm always ambitious, I always want to do this, this, this and this. I'm like, actually I only have two hours a week to do this new type of content. What can I actually do in that sort of space? So when you start in that sense phase, you're not just looking at the AI that you can do or the problems that you'll solve, but what are your, your laying out? Like, what tools do we have, what access do we have with? And, and this is true in healthcare, it's true with us at user testing, like, security is paramount, you know. Right. And they are, our IT and security team will not let me have access to all the stuff that I want to have access to and connect it and stuff like that for very good reasons.
- [16:49]
C
Right.
- [16:50]
A
So you have to figure that, all that out. So I, I really appreciate listening to you explain it that way. As we move into shape, you know, and this is where teams define how AI behaves. Can you walk us through an example of where a team had to rethink whether something should be automated versus human led?
- [17:10]
C
Automated versus human led. Yeah, of course, of course. In terms of just kind of walk
- [17:14]
A
us through the, the, the shape process in general.
- [17:20]
C
Right, right. So if I take an example in terms of, I mean starting with sense itself, it's at one point we were kind of exploring an opportunity to say that can AI help with the script writing and script writing for an automation workflow? And of course there's a very good use case for it. Right. In the sense to one the personalized developers, developers are at the forefront of actually adopting AI and using AI. So it was, it seemed like a great idea, but at the same time where we wanted to deploy deployed are the enterprises. And this was the time I, this was the time, I would say around a year or year and a half back and a lot of enterprises were still very skeptical and they were like, we don't want anything, anything to do with AI. So it's one thing where on paper it sounds, sounds like yes, this is a really good use case and this would work versus in practice, a completely different reaction altogether. Right, so absolutely. Similarly again for. So we work with a lot of enterprise clients which are not healthcare as well within logistics space. Again, one of the ideas was that because the legacy software, the traditional software throws actually a lot of notifications in terms of a shipment is delayed or this has happened and because of that there are downstream consequences. And yes, it's extremely painful in terms of piecing, I mean that information together and then build a picture. But at the same times where we said that oh, actually an agent is going to do the full triage and take an action, people were, the reaction was like, no, because how would you know that if something goes wrong and what will be the downstream consequence of it? Right, right. So that not that level of automation, then the other option was to actually say that oh, it can come up with recommendation or suggestion that a human can review and then say yes or no. But at the same time it sounds very logical. But if you think about it, if somebody has to actually get into the decision tree to understand that what led to this decision and if that is not managed very well, it actually creates more fatigue and more cognitive load than helping. Helping. Right. And in that if your accuracy level in terms of how many times the AI recommendation would be right. In terms of the triage, if that's not certain threshold, then people would be very quick to say that it's not worth it. So yeah, I mean, different factors really play a role in terms of you deciding one, the pursuing the whole idea itself and two, to say that, okay, how much of it you automate, how much transparency is actually good. Transparency. Right. Because yes, you want transparency, but you also don't want to bombard the user with so much information that it actually ends up being counterproductive.
- [20:33]
A
Yeah, that's a very, that's a fair point. Right. We want, it's, it's really about trust too. And as we're learning to trust all these systems, systems, I, I seem to recall, and I can't know if this is true or not, but like the technology on an airplane is so complex that you could just turn on the autopilot and it could land the plane on its own, but we're afraid to trust it to land the plane on its own. So we still have the pilots doing that job even though the plane could actually do it better than the pilots. And in a way it's the same sort of thing. Right. We're, we're, oh, I'm asking you to do all this stuff, but really I, I, I'm afraid a lot of, a lot of fear. What, what are the other things that we should be thinking about in the shape phase?
- [21:24]
C
In the shape phase, actually, once, once you have some sense of that, oh, this is the solution and this is the problem space. So this is where first and foremost, what, what is different from traditional UX here is that one AI often doesn't mean that there are screens. There might be screens involved, but there might not be. Right. So it always helps to take a step back and say that, yes, let's definitely think from user journey perspective, but let's stick to actually doing a storyboard which may or may not involve screens. And hence that completely changes the perspective that, oh it, you can actually build lot of things and solve a lot of problems without having one, an interface and two, where you are still keeping the lens in terms of who is the user. And that's where like that's one of the parts or exercise that we do in the shape part, where it's a four swim lane kind of a framework where at the top, yes, from storyboard perspective you have each frame, but then you're also thinking that what is the user action at? What is the goal? What are they trying to do Here, right? And then we say that so where does AI come into play if AI come into play and what are the decisions that we have to make from design perspective? So that keeps the whole story tight in the sense without having to bring in screens early on. However, from there then we get into kind of drafting the AI touchpoint map so that we know that at every point of time in the one that it doesn't become that AI feature as the front and center of the whole solution. Because without this kind of and rigorous exercise, it's very easy for it to become the front and center where we are only talking about that. Oh, this is where for the description field AI can give an auto suggestion or oh, this is how AI can actually summarize this particular page. Or this is how and because gen AI is so easy, AI can actually generate the patient snapshot, operation summary. And if you think about it, that's actually more things for the provider to read. That's more work for user and not less. Right? And not having that user's lens can very easily lead to a feature creep like this within the process. So this is where we kind of keep everyone grounded in the say that yes, let's talk about how AI is helping, but how AI is helping in the overall user journey. Doing what? And then from there where then we say that okay, now is the time where we actually design team thinks about wherever there is interaction involved. What are the AI patterns that they're going to use, what kind of AI it is? It's an ambient AI that's doing the quiet work in the background and then just surfacing. Is this agentic AI? If yes, then what are the triggers in the user journey? And with those triggers, what will happen? Right? What kind of task the agent can do for the user and what does it mean for the user? So that's where we start talking about the AI modality and the types. And then when we bring it all together, then the challenge for the whole team. And when I say whole team. So this exercise is best done when you we have some representation from engineering, design and product. I mean design can also do it by themselves by sourcing enough information. But if they do it together, that's the best way of going about it. Because in that then at one point and while when everyone feels little confident about that, oh, this is the end user experience that we are aiming for somebody from engineering and that line is actually blurring. It could be product manager, it could be the designers themselves can actually say that let's prototype. And when I Say prototype, not really prototype in figma, but prototype in terms of, for example, using an annotated workflow to say that if we are to actually orchestrate this, if we have to take like one thin slice of it, right? To say that how this experience would be. It's one thing to hypothetically say that, oh, you upload transcripts and AI is going to give the output like this. It's altogether a different thing where you say that, oh, you know what, if it's a best use case, let's feed this 10 different, even if it's synthetic, 10 different kind of transcripts and see that what will be the output. And from there then you can actually kind of stretch the output in the sense to say that what happens if there was a different kind of accent involved, right, where it could not capture the transcript perfectly? What happens where it didn't have context or it was a very short conversation, those kind of things. Where for example, we often do that when we say scribe. It seems like a very standard process nowadays, but it's still not as straightforward and easy because conversation is just one part of the signals that are being captured within. If you look at the whole patient record, there is so many different data points within a patient's record. And when you synthesize it all more, you synthesize harder. It is to say that how exactly the output is going to be, right? And in that you want to really test that, oh, if it was a sparse data situation, how it would be. If it's a lot of data situation, then how it would be. What if there were unstructured unreadable data like lab results that are not perfectly captured in PDF format, right? Then how it would be. And that's where you start seeing that where it would skew. And not only that, even hypothetically saying that this is the model that would work, but some models really work poorly versus others. And at the same time you still have to kind of justify the cost because good models are expensive, right? And they consume tokens very fast. So in that case, where do you want to draw a line in the sense that, oh, user experience wise, we will only allow this much input to the user in terms of the token consumption, right? Or we don't want to open up the context window to be so so long that it will either hallucinate or it will be very, very expensive. So that's the kind of conversation along with of course the ideation ideation that usually happens in the. When you are designing something that happens and that should happen as part of the, the shape, shape section.
- [28:10]
A
Oh my goodness. Each of these phases are so complex and, and, and necessarily so like I'm not making it, I'm just appreciating the thoughtfulness that went into all this as you explain it because there's so much that I would be missing if I was attempting to do this on my own. But that's why I work in marketing. You know, I'm wondering as we move into the next phase, you know, the steer phase, this is when we've launched our new AI products into our ecosystems. What, what surprises teams as they do this? What, what are they? What should they be mindful of? What should they be thinking about as they move into the steer phase?
- [28:56]
C
I would say this is a good time to actually one, of course you do want to from early on define that in terms of steer, steer, what are the agreed upon success criteria? Right. And then so you know what you are evaluating against and even it might actually feel very commonsensical, but it's not. I mean I can't tell you how often I find teams to not be on the same page in terms of this feature is designed. But we don't know or we don't have any idea in terms of what success looks like and how are we going to measure that success and then if it is not meeting certain threshold or criteria, then what are we going to do about it? Right, so the steer part is where, yes we now where the rubber hits the road and we want to think about not only one, of course the accuracy, if that's one of the criteria. Right. But also usefulness because again I have found so many AI experiments where initially in terms of the concept phase, everyone is so excited, things work fantastic. The moment now you start trying to rolling it out or even testing it out in staging, lot of things come together and one of that is where users feel that it's not worth it because users don't care about how much time and effort you put in it or how cool a tech it is and what a massive opportunity it is they care about. Does it work, not work, does it increase my work or it actually helps, do I trust it enough or I am always watching over my shoulder in terms of that, oh, when will it fail me? And hence we all, as we use different tools that are AI powered, we are always mindful and in fact I feel that people who are using it, they would agree to this that we are ever so vigilant in terms of what AI is saying, where it is taking what and as you continuously Use it what kind of degradation or really acceleration that it will actually give. And because all of us have something at stake here, right? A provider has their license on stake when they are using AI powered thing. Similarly, for example, if I'm using it has my reputation on stake. So similarly, if the trust threshold doesn't match or if users don't personally perceive it as useful, they'll be very quick to reject it. And this is the time where you want to not your guards let down, but actually be more vigilant and really see that how people are adapting, if they are not adapting, really go to the depth of it. Because really the statistics in terms of the accuracy that can only take you so far. I'll give you one example for within healthcare again, rcm, which is revenue cycle management, is one of the actually very ripe and potent area for AI because humans in terms of billers and coders spend lot of time just going through the transcripts and what happened in a call to interpret what are the services that were rendered and hence what can be built. And based on that the whole claim is is packaged and then processed for insurance, right? So it feels like the perfect place where AI can come and be an assistant to the coders. In terms of that. Oh, these are the services I can go through the transcript and I can already recommend and give yes or no. And the business seems to buy it in the sense, I mean this was a product and the business seems to buy it in the sense that yes, of course this will save time and we will use it. And what we saw in the pattern in terms of the observation is that users would not really users would still kind of override it. And when we look at it logically, it made no sense because those were kind of the claims where you would see that documentation is weak or evidence is not enough and it's likely to be rejected logically. But you know what those users, they were like you take our chances because we have seen in past that sometimes it gets approved and they would reverse it. And in that moment, if we have not designed for it in such a way and if you don't go deep enough to understand what is really at play, you can simply say that oh you know what, maybe it's transparency is a problem and we should actually probably AI should tell that why it recommended what it recommended. But what we really needed was to understand the human psyche, right? That why are they reversing some of these suggestions and for that now when you understand that, then you can solve for it the solution to that is to say that every time they reverse it, they have to select the reason and that becomes the machine learning loop. Where now the AI is also kind of matching with the human psychic to say that, oh, this is how you make decisions and make recommendation and only when it will recommend. What the coders would actually say yes to is when they are going to use it. If they end up find themselves mostly rejecting it or changing it, they are not going to use it. So this is the space where when you launch it, it's not done like traditional software when you've done enough testing and you launch it and then you know that for 99% of the times things will go and run fine. But with AI, this is where actually now it is the wild world and how things will work is you want to watch it very, very closely and then tweak the parameters based on what you learn. So that's the, that's. And that's why the name steer well
- [35:02]
A
and it kind of like leads right into like, like many things. It's a cycle, right. So you have to kind of like the steering phase leads right back into the shape phase. Not the shape phase, the sense phase. And then going on through that. How. How do teams do that? How or what should they be doing? To think about this as a continuous loop, to be always kind of mindful and like revisiting, oh, we are doing the right things that that sort of thing.
- [35:31]
C
I would say that one parameter to keep in mind is to just like how any product team. I think this is the rule of thumb for product team that once they, once we release a feature, we want to constantly watch and see that what is the usage? Is it actually making a difference? Is this particular feature was adapted by people or not adapted and then do something about it. Right. So similarly here that's the least that needs to happen in the sense to say that if it's not working, then really what are the lessons to be learned here? If something to be tweaked, then what is to be tweaked? And then you rightly said some of it will actually be an input to sense part of the thing and you might have to start over. Right. Some of it would be a small tweak where it's a user experience or the expectation setting that you need to do. Is it a cold start problem where, I mean, yes, enormous potential in terms of what that copilot can do, but you don't know what to start, where to start and what to do with it? Right. Is it a cold Start problem that it's you solve it in a different way. So only through by listening to signal, just like in the product. Otherwise you would know that what is to be changed and where. And then sometimes you have to just kill it because there is only so much prep you can do and do the testing within the closed constraint or in the laboratory setting. Sometimes things don't work in spite. Best of your intentions.
- [36:59]
A
The people are listening to this episode. Many of them may be just starting out on this idea, but many have already adopted some sort of AI product or designed some sort of AI product. They're kind of like everybody's in their. In their maturity cycle in different places. If you have to give some advice to a team listening right now and they can only, and they can only focus right now on one part of the framework. Where should they be thinking? What should they be doing?
- [37:32]
C
I would say that definitely, most definitely spend time on the sense part of it than anything else. Because shape is more instinctive. More or less that will happen in the sense you will think about the solution. In fact, if at all people will start from solution first. So with AI, people are always thinking of the possibilities. So it's very easy to be solution driven there than the problem driven. But sense kind of allows you to really one, think that what problem it solves and two, by saying that what are the constraints available and how do we actually manage those constraints? And the constraints can be managed beautifully through user experience. I mean, delightful user experience still means that if the expectation is set well and then you deliver more than that expectation, that's what the delight is. Right. So knowing that having that conversation really grounds teams and I would say that that's the part that they should spend more time on.
- [38:32]
A
Yeah, the Bonsi. I've appreciated our conversation today. Thank you so much for being on the show. How does someone learn more about you, your thought leadership and what you and the team are doing over at Coro UX?
- [38:47]
C
Well, I would say LinkedIn is the best place. I frequently post there. Reach out to me for anything. And I would actually love to have a conversation with people if they happen to try the sense shift here to see because I have personally seen our teams trying it in different capacity and every time we have applied it, we have learned more and we have from there evolved this. They work constantly and at the same time I have seen that just like how you said different product teams are in different maturity and then they would have different time constraints, pressure. And in that you might not be able to go from beginning to end. But having it in mind, it allows people to then adapt it based on. And that's why the framework. Right. Based on their situation. So I would love to have a conversation and become, I mean, take a peek into how people have implemented it. So yeah, LinkedIn. LinkedIn is the place.
- [39:45]
A
Excellent. Yeah, I'll share links to all that in the Show Notes. You have a great article on your website that kind of goes through the framework, so people can take a look at that as well. Again, thank you for being on show. I'll talk with you again soon.
- [40:02]
C
Thank you so much. Thanks for having me.
- [40:07]
B
Want to keep the conversation going? You can find the show notes@usertesting.com podcast if you haven't already. Don't forget to follow us on Apple Podcasts, Spotify, Overcast or Google Play, so you never miss an episode. And if you enjoyed today's show, please share it with a friend or leave us a rating and review on Apple Podcasts. And until next time, this is Insights Unlocked, an original podcast from User Testing.