Episode highlights

• 00:07:32 – Key traits of legacy systems
• 00:09:56 – Balancing Big Picture and Deep Research
• 00:17:21 – Aligning business and research goals
• 00:21:50 – The importance of edge cases
• 00:24:36 – Managing power users vs. novices
• 00:28:08 – Connect with Bansi on LinkedIn

About our guest Bansi

Bansi Mehta is a seasoned UX design leader with over   15 years of experience, having worked at Aims Digital, 3D PLM, and Cybage. In 2011, she founded Koru Technologies (rebranded as Koru UX Design LLP in 2017), aiming to bring consumer-grade UX to B2B and enterprise applications. What began as a vision to improve workplace UX has since evolved into a leading design agency specializing in B2B products and healthcare software solutions for North America. Bansi has led successful projects for clients such as eClinicalWorks, Redwood Software, and EasyHealth, using user-centered design to drive business success. Her mission is to craft meaningful user experiences that address complex business needs while improving daily user interactions.

When you're working on legacy systems, it's essential to have a clear understanding of how everything fits together before you start making any changes.

Podcast transcript

[00:00:00] Tina Ličková: 

Welcome to UX Research Geeks, where we geek out with researchers from all around the world on topics they are passionate about. I’m your host Tina Ličková, a researcher and a strategist, and this podcast is brought to you by UXtweak, an all-in-one UX research tool.

This is UXR Geeks. And you’re listening to the episode with Bansi. Bansi is the founder and CEO of Koru UX Design LLP from India, a studio that has been on the deep end of enterprise UX for over a decade with specialty in healthcare. Together we were talking about the intersection of legacy systems and B2B. About its users, about their neglect of changes or about the edge cases or niche groups in such a system.

We were also addressing the need for adjustments while working on such a system coming from real business or user needs. It’s a very nice showcase on how. Bansi loves complex problems and complex system to tackle on, and it’s really giving some hints on how to work with stakeholders as well to research with users for such systems.

Tune in.

Hi, what is really important to know about you?

[00:01:36] Bansi Mehta: My name is Bansi Mehta and I’m the founder and CEO of Koru UX Design LLP. We are. A UX design studio that is specialized on enterprise UX and further specialized into healthcare. So health tech products. That’s what we have been doing for 13 years and that’s what really excites me a lot.

So I think what you should know about me as a person is that I. For some bizarre reason, really love complexity and really love making sense out of chaos, make making sense out of when things are all entangled and, and hard to make sense out of. So I think I thrive in that situation.

[00:02:14] Tina Ličková: I. Great. Yeah, I can feel it.

Yeah, probably the same here. Could you maybe describe your company a little bit? So also listeners know how your business runs, where it does it run with with clients when you’re also specializing on healthcare. That is super interesting.

[00:02:31] Bansi Mehta: Yes, of course, post pandemic. We are now like a hundred percent remote team, and so we have designers all over, but we are primarily based in India and headquartered in India.

We have office in California as well. All of our clients are primarily in the North America, and so US healthcare is the area or is the industry that we specialize in. And within that. Some of our clients are eClinical works with, which is one of the leading EHR companies in the USA, and we have been working with them for 12 years now.

So right from that end of the spectrum, lot of health tech startup companies where they will be specialized on a very focused use case or a niche area, be it in the insurance space like claim processing or. On the patient side of things like patient engagement, but more sophisticated orchestration kind of things.

And then some of our clients are also non-healthcare, but hardcore enterprise products, B2B, legacy products that really need fresh set of eyes in terms of what could be the ux and then where do we even start

[00:03:38] Tina Ličková: healthcare in us with all the reforms and reforms taken back. I can imagine that that is answering your need for complexity, I would guess.

[00:03:48] Bansi Mehta: Yes. Yes. More absolutely that, and I think probably that’s why we’ve gone drawn to healthcare. It’s just amazing flavor casting that how in US healthcare, all players, their interest are packed against each other. So it’s, so when you try to build an ecosystem that kind of works together, that’s, that’s the first hurdle that you really see.

Start from, and then you work backwards. So a lot of constraints on in general in terms of ecosystem and the how the data is shared and right from there to how many players are there and how everyone’s interests are really stacked against each other.

[00:04:24] Tina Ličková: When you were mentioning healthcare, you were also mentioning B2B, and when we were talking, you came up with a few topics, what to talk about of course, from this complex experiences that you had.

And we agreed on talking out legacy systems in B2B empowerment. Yes, yes. Which is like not a level, I would say. How do you define a legacy system, especially coming from your experiences in healthcare?

[00:04:53] Bansi Mehta: So I have encountered multiple legacy systems, and when I’m looking at one, it’s at least 10 year olds, if not one.

For me, the record is 30-year-old. Oh wow. Okay. Yeah. And for some of our longstanding clients, I’ve also done like double cycle in the sense where we started, we were already doing one legacy overhaul, let’s say, from visual basic to then moving to cloud. And now 10 years down the road, we are actually looking at another round or 12 years down the road, we are actually looking at, oh, with AI now what?

How do we solve the same problems?

[00:05:27] Tina Ličková: And I don’t wanna pick on definitions, but one I, I love how straightforward you are with like, oh, it’s 10 or even more years. I’m working on the legacy system in meteorology, which is 25 years old, so I get what you are talking about. Back then, things were completely different.

But on the other side, how would you say, what is a legacy system when it comes to what qualities it has? Or is there some emotional bound from the users?

[00:05:55] Bansi Mehta: Oh yes, absolutely there are, there are multiple characteristic that would define the legacy system for me, and that would, and these are the common traits.

Invariably, when you look at the legacy system, you will see that it’s a mishmash of features because you can already see that. When a software is built or a product is built over the period of years, incrementally, it doesn’t look cohesive. You can see that different parts of the product live in different era.

And not only that, sometimes different parts of the product. You can also see that, oh, this part was done by or done for this customer, or this was done by this department, or this is done by the newer. New like forward thinking product team versus this is something that has been there and nobody has touched it in the longest time.

So that, that’s one part that you see another, the moment you think you, you talk about where is the documentation and you wouldn’t find any. So like invariably the case for legacy. And then if you have to understand the product, again, invariably you’ll find someone in the organization who would say that.

Oh, I have been working on this for 10 years, or 12 years or 20 years, and I know, or this person knows for this thing, you want to talk to this person and that that person or just a few handful of people hold all the knowledge about the product. So that’s, as far as your documentation go, is invariably another trade.

And third thing is that. If you bring up the topic of change, there will be multiple people who will say that, but you can’t touch that, or You cannot change this because of this reason. These are some common trait that you see right off the bat.

[00:07:32] Tina Ličková: I will maybe go back to this point of you can touch this and how to prioritize, what to touch, not to touch later on.

Mm-hmm. Remind me of that. But maybe let’s dive into the user side because what I really loved when we talk is how you various, in a simple way, but typologize the users from easy to very hard to nuances. Could you maybe mm-hmm. A little bit on that one.

[00:07:57] Bansi Mehta: Of course I see this especially as trades off, not specifically or not necessarily legacy product, but definitely when you say enterprise or B2B products, you are invariably talking about one screen or one workflow that is touched or used by multiple persona.

And those multiple persona could actually belong to multiple departments within the organization. But it actually goes beyond in the sense I’ve also seen where. That based on the customer base, that that’s using the product. Like there might be enterprise customers that would have their users and teams segmented and divided in different roles and how they use it versus a mid-size or a smaller clients or customers and how they would use the product where.

One particular task or workflow is done by different users or common users versus where on in a larger enterprise scale customer, you would see that it is much more organized. You would clearly say that, oh, there is an admin or a super admin, and then there are. Dedicated developers in their IT department, and this is how the request for a new change comes through a ticket versus in a smaller few organization.

You say that this workflow is very different, where it could actually happen via email, and there are not very defined roles, so you also want to keep that in mind because if you start from one end. It’s very easy to have skewed persona or persona that are right for this customer segment, but doesn’t work with this customer segment.

And then of course, on top of that, you always have the layers with, especially again, with legacy product, you always have the layer of power. Users who have been using it for years have built muscle memory around it. And then those who have. Just entered in the system and trying to make sense out of it.

And then the in-between, so you’ll hear very different version of how, what are their challenges, if there are challenges, um, depending on who you talk to.

[00:09:56] Tina Ličková: Interesting. And I am wondering, because you were mentioning this, okay, what to touch upon and what not or what doesn’t even need your energy because there will be such a backlash.

So first of all, when you uncover the issues. On daily use cases, how do you go about that in comparison or versus things that people are in very much psychological or pro professional neglect of not touching or touching it.

[00:10:28] Bansi Mehta: In this kind of a situation, there are, I’ve seen that there are two types. If you have been working with that product and teams for quite some time, you still have a sense of what is what, who to go to for what kind of a thing.

But I think it’s a different beast all together when you actually start the project by saying that, oh, we are going to do the discovery, or this is the brief that we, our IT ultimate goal is the UX or UI overhaul or new features. And for that we are going to do the discovery. That, that’s the part that I actually compare with this parable.

I don’t know if you’ve heard of it, but then when there are blindfolded men. Trying to make sense out of an elephant. Somebody will touch the tail and they would think it’s a snake and another would touch the leg and thing that it’s a trunk. So everyone is trying to make sense out of what is this product, especially from the research team or the design team.

And they’re new to the whole system. And I feel in that. I have come across this situation and in that situation I would say that the number one priority is to get sense of that big picture as fast and as early in the process as efficiently as possible, because then you can decide that which part you want to dive deeper into.

Because as broad and as vast, the legacy products and enterprise products are, they’re also deep and you can’t cover both breadth and depth all at once. And nobody has the patience really to do. Three months, six month upfront discovery. So you also want to see that, oh yes, you are understanding it, and we are getting somewhere with that.

So I usually, uh, recommend that deploy as many combination of different methodology that you might have to, but your number one goal is to really get a sense of that big picture and that my go-to approach is really to say that. Start from growth qualitative and quantitative. So you are not blindsided by the small set of users that you might be interacting with, or just the story that you might be hearing from one department in the team or one user who has been working with this product for years.

Because you keep hearing very different version and it’ll be very hard to come to the consensus to say that this is the problem or this is where we want to dig deeper. So balancing, combining both and then see then say that. This is where the maximum volume or this is where the maximum footfall, so let’s dive deeper into this, make some headway, and then go after the other and the other.

But I, I, I’ve always seen that with legacy product and enterprise applications, you can, you have to go deep, you have to go to the very depth of last field that is that there, or the last use case or the edge case that is to be covered.

[00:13:10] Tina Ličková: When I’m listening to, I’m like, yeah, I love the idea of, okay, let’s do the big picture and then decide what to go deep into in that approach, however, I encounter a little bit like underestimating how deep each problem could be.

I see it also happening in finance, in especially in internal systems or also in science. Whereas, oh, you just do it somehow. And I, for example, had this conversation on LinkedIn or I jumped into a conversation on LinkedIn where a friend of mine who is in UX for years was very critical to some meteorological maps, but those are also standard for the whole world.

And he was, he made a good point that, okay, this is for the end user so you don’t have to follow the standards. But also making the change in the minds of meteorologists, like for the end user, it could be something different, is a very big change. And I know, like I was humbled by the work with the meteorologist and their legacy system, how many details and how these details run deep.

[00:14:18] Bansi Mehta: Yes, absolutely. Yes. And Tina, that, that’s why when, uh, whenever I take up the project or an engagement that is. That starts with an upfront discovery for a legacy system. One thing that I really want spend enough time on is the alignment on what is the goal, because it might sound that this is the most intuitive thing to do or common sense thing to do, but you’ll be amazed that how.

How fast the narrative changes as you discover and as you present or start sharing information with the stakeholders, given that there are so many stakeholders, if you have not logged in that, why are we doing this research? For example, with one of our clients, the research focus was. When we started the research focus was that our business runs on those legacy products, and we don’t want to disrupt that.

But at the same times, we want to prepare ourselves for the future because we see that new customers and new generation find it very hard to use this product. But at the same times, if we actually, if we. Change something that would upset the existing customers. That is like a problem today that affects our operations and the business and the revenue today.

So how do we balance these two? And this is what we want to do. We want to go after capturing new customers and new market and want to prepare ourselves for a few years down the road. Now that it’s very important to have that alignment because it’s very easy to say that if the researchers research talks about.

These are the problems. Who do you talk to? If you talk to the existing customers, they will tell you problems in the existing product. But if the brief is to build something that is for tomorrow, there might be too big a gap, and that would actually involve probably creating a parallel product. The greenfield strategy, as they often call in digital transformation, how do you even go from here to there?

And then you need the backing because it’s not going to be an easy path to go from here to there. There will be time before you actually have something tangible that you show in terms of the new product and how that would lead to revenue and people could have change of mind as we go through this. A transition.

So I make sure that everyone is in alignment, that the CS is in alignment, that how are they going to generate revenue with this approach, is their approach. And what is the business priority? Because if the business priority is that, oh, we are losing customers and hence retaining customers is important, then we want to really make sure that we are understanding what is the current customer’s pain point and how can we ease that.

But if the narrative or the business strategy is that we want to build a product for tomorrow, but also want to protect the revenues of today, that’s a very different brief to work with, right? This is very important one to establish and then to keep on reminding everyone. And it’s not funny how many times you’ll have to bring it up and sometimes you’ll have to again do the realignment during the process as we are doing the research or uncovering things.

[00:17:21] Tina Ličková: I’m happy that you’re addressing it because I, I had a, the first question that popped out in my mind was like, how do you actually make sure that good goals are defined, but the, and constant alignment? I really liked the idea that it’s not just aligning in the beginning. I know we did some with some clients, but those were not project, which were running for years, but maybe for months that they were even signing papers.

This is what we agree on these features, and this is the goal. But yeah, if you’re working on a long-term thing, then you have to keep aligning. And the second point is I really like. That you are bringing a lot of product management perspective into it. Okay. Realigning, looking at the needs of the users, looking at the business needs, and with that re, re-aligning again, because it might make sense.

The follow up question because you were also bringing it, that research itself re informed you about, oh, okay, we have to do another realignment. Do you have any examples? Or maybe it doesn’t, you don’t have to enclose any data or especially not from healthcare, but maybe some high level example, like when does it happen and how do you navigate then the change?

[00:18:37] Bansi Mehta: It happens all the time. I think it, it happens with the research of this scale. It’s bound to happen because you start with what you know, but then the moment you uncover more there is, you won’t know what you don’t know from the start. And you only know it when you uncover the uncover this much. But that many people find it very hard to process.

Very hard to see that, oh, but we had given this much time for discovery. How come you are coming up with now that we need to uncover more? And I wouldn’t say that I was. I had this clarity from the get go, but with experiences I have learned. What I would recommend as a strategy is that you one, that elephant analogy that you start with big picture thing.

I always make sure that we are not really jumping or working at multiple levels because the moment when resources for work, that if you change the lens in terms of if you change the degree of where you are looking at the data from which perspective and which scale. It completely changes the meaning, right?

So to have that idea that, oh, we are starting from 10,000 view and now we are not, right now, we are not go talking about the details, and then you say that, oh, this part you want to go deeper into, and now we need another round of discovery. One, having that alignment from the get go to say that, oh, this is a preliminary or primary discovery that we are starting with.

Just to get the understanding only of the land. And then from there we will do, we will have some idea in terms of how these are the areas of opportunities or pain point, but we will do deeper discovery, which is more pointed, discovery, focused discovery on those specific areas before we get into the ideation cycle.

So that way we are not stacking all the research in one go. And at the same times we are not saying that, oh, we are not going to. Touch on research. Again, it keeps that conversation open, but it does require the alignment in terms of both prioritization as well as the fact that, or just the affirmation to say that no, we are going to do deeper discovery.

We know high level area that these are the areas of opportunity, but we don’t know all the details, but we. Won’t be equipped to really design to that last bit of edge case or the field, uh, data point till we have done that deeper discovery. So having that agreement from the get go, it just makes sure that it’s not a one-time job and that it’ll, you’ll not uncover everything in one go.

[00:21:02] Tina Ličková: And you were multiple times mentioning edge cases. And this is really interesting because what I encountered is that the edge cases, especially in legacy system. Might be on one side, etch cases, but on the other side, super important to cover. So it’s not an unusual thing of, oh, this is an etch case and we maybe do it in some time, but this is an edge case.

If it’s not there, the pain of not be not being existence in the new thing. However, it doesn’t matter if it’s an optimized thing or a greenfield thing is going to be really large. And you were mentioning this 80 to 20 principle, which kind of fascinates me. Could you maybe tell me more about that?

[00:21:50] Bansi Mehta: Yes, so I’ve seen that for enterprise applications 80/20 rule is not always the one that works because you can’t just say that, oh, if it works for 80% of the customers, 80% of the time, this priority is create, because for many customers, that 20% or even that 0.5% of the use case.

That it might be running their business. And the implications are serious. You don’t want someone, so for example, one of the transportation management, a product that we are working on, they process billions of dollars of invoices through that system. So not just playing around with one seed that has, that does the calculation for just one customer.

That if, if the order is routing via Alaska, apply this exception. If we don’t take care of that, that it’ll actually impact those invoices to be processed and that will have further implication in terms of deliveries happen or not, and that that could, it could actually impact their day-to-day business and hurt the bottom line.

So every edge case and every logic, no matter how absurd it may sound, sometimes when we look at, we wear our designers hat and look at the product, we may feel that. This is absurd. Who needs so much data? And this field is never used. I looked at multiple items or case cases, or in one case, we were actually looking at the number of incident tickets, and we just went through tickets, and tickets after tickets, and we were like, 60, 70% of these fields are never filled.

Why do we even need them? Why don’t we just prioritize based on what is what? Which are the fields which are filled the most, and then get rid of the ones which are never used, right? But again, you are only looking at limited set of data. How do you broaden the lens? We, so we actually did this exercise where we asked the engineers to say that, can you run an SQL query and give us one year worth of data?

And they actually came back with. 400,000 tickets for all those 70 fees, which we did the analysis and then they were like, can we see that these, this fee, these bills are not used? And then they were like, but what about the backward compatibility? Who said that? We have to support only one year worth of data?

We have to support the, if somebody has used something in last. Two years or three years, we need to take care of that as well. We don’t archive our data for three years. Then you, so where do you stop and how do you balance this and how deep you go in this, right? So you really need to consider all of these aspects, and it can’t be just based on a few interviews that are conducted or even when you are playing around with the data yourself or product yourself.

Just going through the, those numbers yourself.

[00:24:36] Tina Ličková: I, I, I just feel like the meme, like preach the same thing where I am. Even when I’m working with banks or in the customer research, which is like closer to market research, I am still like, we did this interviews and I love it and we understand maybe now more the psychology.

But where is your data where we can actually look on how it’s actually used? I don’t know, your account or the features that you build in the apps, like we need to connect it and we need to have this complex picture. And it won’t be easy. There won’t be any easy answers and I, I really love that you are show showcasing how much balance you need in different points, touch points in those projects.

Yeah. Yes. Maybe one of my last questions because this is always, and for people who work in enterprise or B2B or on legacy systems, always the case, how to bring balance between power users, the common users, and the novice users. Tell me your wisdom.

[00:25:42] Bansi Mehta: I would say talk to each set. The most basic thing that you could do is to make sure that, one, you identify that how deep this product goes in terms of how old your customers are, and how old the users of those customers could be, and determine that.

Who are those powered users? And then make sure that we talk to. At least a handful of users or individuals from each group. And that happens only if we are conscious. Because if you look at the legacy system or the enterprise application, the numbers can go up very fast. Like the moment you say that, oh, this particular application is used by five different departments, and within those five different departments you can, you could easily have seven to eight different unit.

Persona. And in that, if you say that, oh, I’m going to talk to the power user and novice user, the number can go up very fast. But at the same times, not talking with, with all set of individuals can give you a really skewed picture. And my experience in one of the projects I’ve had, the user who used all the power that he had in his capacity in terms of all the connections that he had internally to escalate and say that.

But we fill this form using tab, and this field comes on the third tab. How come they’ve changed it? Now I’m, I’ve messed up all the data entry and this is not, okay. I’m not going to pass this in UT. So if you have not really thought about that and preferred that narrative or told those stakeholders before.

Beforehand that this could happen, that there will, that could be a backlash when we do this or that we have taken care of this part, it, they will be caught by a surprise and some users, they, in, especially in legacy environment, they do hold power to stop releases from happening.

[00:27:34] Tina Ličková: Very good point. Also, yeah, there is the power users, they have power.

They actually have power to influence things and influence other people. They can be very helpful when they want a change. They could be super counterproductive if they don’t wanna have the change.

[00:27:51] Bansi Mehta: Absolutely. Yeah. Yes, yes. So you want to vary the cost in terms of not talking to them or not even getting the buy one would be really to listening to them, but two would be you also want to make sure that you have that buy-in, that they are on board.

[00:28:08] Tina Ličková: Great. Thank you very much for your wisdom. Is there any plays or any website, social media account that people can follow you and look or onto what you do and what you publish, where you publish your thoughts?

[00:28:21] Bansi Mehta: I frequently pub share my thoughts on LinkedIn and yeah, that’s whatever I feel that is worth sharing.

I make sure that I share. Most of my followers are product people as well as designers, so I often share my experiences there.

[00:28:36] Tina Ličková: Thank you. Looking forward to what you will share in LinkedIn.

[00:28:41] Bansi Mehta: All right, great. That was very nice talking to you, Dina, and have this conversation. Thank you so much for having me.

[00:28:52] Tina Ličková: 

Thank you for listening to UXR Geeks. If you enjoyed this episode, please follow our podcast and share it with your friends or colleagues. Your support is really what keeps us going.

If you have any tips on fantastic speakers from across the globe, feedback, or any questions, we’d love to hear from you too. Reach out to geekspodcast@uxtweak.com.

Special thanks goes to our podcast producer, Jana Filušová, our social media specialist Daria Krasovskaya and our audio specialist Melisa Danišová. And to all of you. Thank you for tuning in.

💡 This podcast was brought to you by UXtweak, an all-in-one UX research tool.