Episode 14: UX Research Craft & Methodologies with Naroth Murali, UX Researcher at DBS
54:59 Share

Hi everyone, I'm Dalen, founder and design educator at Curious Core. Welcome to our Working in UX Design podcast series where we interview a UX design leader in the industry on their experience in this emerging field. We've had UX professionals from Grab, AirAsia, Google and more join us previously and we're bringing you more exciting interviews this year.

Stay tuned for this week's interview with our special guest who is working in UX design. Happy New Year, everyone. And it's great to welcome all of you to our first session of working in UX design once again.

And we have a very special guest this evening. Thank you for joining us. For those who are in our live audience and for those of us who are listening to the podcast and you're new here, thank you for joining us. I am Dalen. I'm the founder of Curious Core and we help mid-career professionals to transition to the field of user experience design as well as product management. And we've been...

working out of Singapore and helping mid-career professionals, helping corporations to improve their design practices as well from a training and coaching perspective. So tonight I have a guest with me. Nirav is someone I've known for several years and I'd like to briefly introduce him. Nirav Murali is a mixed method UX researcher with over six years of experience in the design research domain.

and he has majored in industrial design and he's presently a part of the UX research team at DBS Bank which is a regional bank based in Singapore but it has branches all over Southeast Asia and he collects, analyzes and interprets customer data for the consumer banking business and UX team

And he's also an avid golfer, a food and wine enthusiast, and a science fiction lover. Curiosity is at the core of what he does. Nice wordplay over there. And he's adept at creating delightful user experience that challenges the status quo, backed by uncompromising research. So research first. Research is what we're going to talk about. I hope I didn't miss anything, Nirav. No, it's spot on, man. Awesome. Well...

Welcome to the show and welcome to the program. And let us start off by maybe having you share a little bit, like what does a UX researcher actually do? Okay, so like a day in the life of Naroth, the UX researcher. Well, firstly, maybe I'll just preface my job title a little. So I'm a UX researcher, but I do mixed methods research in DBS Bank.

And what that means is that we employ both qualitative as well as quantitative methods to arrive at recommendations for our business and design partners. And essentially I work in the consumer banking group in DBS, so a lot of my work actually affects products that you and I use on the daily, right? Like iBanking, mobile banking, Payla, things like that. Yeah, that's pretty much the domain.

And the work that I do essentially is about understanding people. So research, I think at its core is really about just being curious about understanding what people do, how they behave and trying to understand how our products can support that behavior or those needs that people have.

Yeah, that's really great and thanks for sharing. What does a typical week look like for you? Especially now it's COVID, right? Imagine you're not working at the office. So what does a typical week look like for a remote UX researcher? It looks a little bit like post-its on the wall.

Yeah, because I don't have an office space to really synthesize a lot of my ideas or insights. But essentially, it depends on what phase of the design process we're in. So it could be that we are right at the beginning of the design process where we're trying to understand the problem. We're trying to really discover and define what we should really dig into. And a lot of that is actually planning. So I spend quite a lot of time with...

stakeholders actually listening to them trying to understand what the problem is and then trying to pitch a research method or a plan to them. So I might spend like maybe three days actually coming out with a whole brief based on a workshop and some material and we will just pitch it to them and then I'll spend my time actually planning on executing the research. So that would be probably like the planning stage where you know a lot of it is pretty much determined by the brief or the problem.

And then when it comes to executing research, it might be like two or three days of going through maybe three to five people per day of interviewing people. So like how we are in a Zoom call right now would essentially be the setup, right? So I'll be spending an hour introducing myself, throwing some warm-up questions to the person and then trying to dig deep into either how they're behaving or any attitudes or beliefs that they have during the session.

Yeah, it's really wonderful that you mentioned about attitudes and behaviors. That forms a lot of the work that we do in UX research as well. What do you think are some of the better methods of finding out about attitudes and what are some of the better research methods of finding out about user behaviors? I'm happy that you brought that up because there's a clear distinction between attitudinal and behavioral data. So essentially, attitudinal data is about what people think

what they feel, what they say. So these things are not behavioral data, which is actually what they do. So for you to capture behavioral data, you need to observe people doing things. And essentially, there's quite a famous quote, like a lot of people say that what people say is not often what they do. And that rings really true when you conduct certain tests like usability tests or even concept testing, where you actually get the person to

interact with prototypes. You get to see a lot of the behaviors and a lot of assumptions are always broken at that point of time. So what you think that they might do or what they say they might do is quite often the case not true, you know? And that's why collecting behavioral data is really important to us. Yeah, that's great. And going back to the question, which is research methods, what's the best way to collect attitudinal data? What's the best way to collect behavioral data?

Yeah, so attitudinal data, you can do it with qualitative interviews, right? You could do it moderated, like me being a moderator and you being an interviewee. You could do it unmoderated, meaning that I could send a survey and collect basically impressions of what people think

about certain questions, that's also attitudinal because essentially you're assuming that whatever they say in terms of their answers to the questions that you're posing in the survey will reflect their beliefs or their attitudes. And then you collect the data, you sieve it, and then you start to triangulate it.

Whereas behavioral data, you almost always have to do something that's live. So it's almost always moderated. Or if it's unmoderated, there are some really cool nifty tools online like Maze, where you can essentially upload a whole flow and you could actually see how they click through and

Where are they clicking? Where are they misclicking? What are the paths they're taking to success? How you define success is basically if I'm saying a person needs to go from A to B and they need to go through like maybe three steps, you could actually see where they're clicking in order to get there. So that's behavioral data, very powerful to collect. And thanks for sharing. Did you mean maze.design? Yes, maze.design. It's a really cool tool. A testing tool.

I hear Grab uses that tool as well and we actually happen to teach our students that too and they have the opportunity to use it. Glad to hear about that. Let's kind of contextualize it in an example. Is that a piece of work or an example you can share where you have collected attitudinal and behavioral data? Yeah, all the time. Like I was doing a survey recently on the well segment and essentially we needed to understand what kind of

what kind of tools they use and on some level what kind of actions and attitudes they have towards the brokerages that they're using so from there we can kind of get a sense of okay what are they feeling is good about the platform they're using what is not so great if it's not so great what is it specifically so they have like open text fields for them to actually type in certain comments which we will then see through and then look at it more closely so yeah that was an example of

a project where I collected ethical data. Tell us a little bit about the wealth segment in Singapore or share what you can. Is there anything interesting that you think, an insight that you discovered that might be useful about the wealth segment say in Singapore? Okay so in DBS we pretty much define the wealth segment as people having assets under management above 350,000 Singdollars.

But the interesting thing I felt was that even though you expect their behaviours to be vastly different from the average retail customer like you and I, they actually behave very similarly in terms of how they use the brokerages. And that brings me to the point that sometimes you need to kind of leave your biases at the door when you're forming conclusions or trying to understand certain groups or segments of people.

and that's where the power of research comes in because I remember working with my product managers and we went in with a lot of assumptions that there are very savvy users who are always going to be wealth customers so because they have a lot of money they tend to trade a lot more frequently or they would tend to use the most fancy tools to execute their trades or like data and information basically

And it turns out that it wasn't the case. We realised that they were very much like retail investors and the key dimension you would say to define these investors was actually not their AUM. So that's a really cool, interesting finding on our part to understand that hey, what we first thought was AUM being the largest driver for this behaviour was actually not the case. It was something else, it was a different behaviour.

Yeah, thanks for sharing about that. I would have expected they have a very different behavior. I wonder if it's different if they have a $1 million assets under management. Yeah, so it scales, right? So you have like precious preferred client and you've like private banking. So private banking, you might have a person who's sitting on like $2.5 million in assets. But the bank has a lot of different ways in which we service our clients, right?

So they might not, depending on the persona, the profiles of these clients, they might not actually even be really trading a lot. They might have a relationship manager who's managing all their funds. So they might delegate a person to actually handle that vast amount of money that they're sitting on. So then you need to kind of think about, okay, if these guys are actually not managing their own funds and they're not trading as frequently as we think they are, then what is a good digital experience for them?

It would look very different from what a retail customer who's maybe trading very heavily would feel like. Yeah, I mean there are people who are day traders and there are people who just leave their money there and that's about it. That's really interesting and thanks for sharing. Great that you're collecting data and you're working with data.

I think there's also this question about qualitative and quantitative data other than attitudinal and behavioral data. So would you say you're more proficient in either one or would you say you're equally trained in both? I would say I'm equally trained in both but I'm more proficient in qualitative methods. Quantitative methods are actually a whole different beast than ballgame because it actually requires that you set up a lot of time. Okay, how I describe it is

With qual, you gather the data relatively quickly, but you spend a bit more time synthesizing the data, meaning that when you are drawing conclusions about the patterns that you see in different people, you might spend a bit more time there, like post-its, right? Whereas with quantitative data, a lot of your work is actually done more upfront. You're front-loading the data.

the whole process so you really think hard about like okay i have a hypothesis what am i trying to collect what are the variables that i'm actually putting to a survey how am i actually going to start to triangulate those variables even before you send out the survey right so it requires a lot of foresight a lot of experience to think like okay that far ahead i'm going to collect a b c d e f g

and then I'm actually going to cross-tabulate or cross-reference those data points. I'm going to cut this data by these segments. So it's actually a lot of upfront work on the quant side versus a qualitative study.

That sounds about right. I mean, if you don't prepare and you struggle with actually filtering out a lot of the noise and rubbish and junk data as well. And I think that was an interesting question being posed by one of the audience members. How do you actually work with product managers, right? Do you do research or do product managers do research? Yeah, who does what? Okay, that's very interesting because the PMs that I work with,

they would initiate a research request. That's actually how in DBS the model works, right? So we actually have a funnel where we collect all the requests from different departments, different verticals, different products. And then from there, we actually kind of like spread it out to the different researchers to tackle based on their bandwidth.

But that's kind of like the newer model that we've just adopted. Previously, how it worked was that we were working a bit more embedded. So what that means is that, let's say I would be attached to the wealth team and then the product manager and I will actually work very closely. Essentially, it's like I'm a consultant for the team in terms of everything research, right? The same way they have a design resource, a designer or a content designer who would be attached to the project. And then...

at any point of time they would actually tell us like "oh okay we are actually at this stage where we need to maybe run some evaluative research" and here's the thing I'm not sure whether this is more of like a DBS specific problem but yeah I'm gonna go on a bit of rant here I think a lot of product managers tend to focus very much on research being a checkbox right I just want to take this element of like I have spoken to the customer about this and it's good

But in essence or in reality, we need to be understanding the customer needs way before we even try to design screens or try to even think about the feature or think about constructing whatever it is that we're trying to build.

So that's where I feel we as an organization can do better, can improve. And that is actually a lot of, the onus is actually a lot on us to go out and educate and try to preach, for lack of a better word, the research discipline. Yeah, that's a great point. And I was just wondering in terms of talking about the role between product and design and research,

How do you then work with designers? There are quite a number of us over here who are UX designers. How does a researcher work with a designer? What would you wish your designer do or tell you in order to work with you better? Okay, I mean, I empathize because I was a designer. I'm design trained. So at some point in time, my career actually made a pivot to research. And the way I'll describe it is almost like a pivot from left brain to right brain. I started to look at the world very...

through a lens which was a lot more rigorous and a lot more detail oriented so it's almost like you know conversion thinking versus like divergent thinking that you would normally ascribe to designers but to answer your question i think what i would

like designers to do is actually to be free to express themselves. Like leave the evaluation to me, let me be the one to take the lead in terms of giving you the material to answer customers, like basically what is the customer needs, what is the problem statement, those things I can supply you, but I want you to be creative and go a bit crazy with the ideation and then we can think of how to dial it down later on. In DBS we work with the DLS system, Design Language System,

So sometimes even though there's a really great operations tool, right? So that you can standardize the look and feel across a lot of different products. Sometimes it's a bit of a leash where you feel constrained by, you know, I need to use this component, I need to use this pattern. And oftentimes it becomes like a bit of a dilemma. I've seen in designers in trying to really understand what fits the design brief best because it's just there, right? Drag and drop.

But why not think about it really from scratch? Yeah. Well, thanks for mentioning that. And designers, I think feel free to see it as a partnership and sounds like feel free to express your ideas and be as creative as you should be. We got some really interesting questions about privacy as well. And firstly, I think privacy from the research side, right? For the research, someone

here in the audience was asking do we need to have some kind of ethical clearance or some kind of clearance form signed since the subject is a human being yeah so typically we'll have like ndas non-disclosure agreements prior to any qualitative interview so that you know we disclose that this information is only recorded for research purposes only it's not going to be disseminated anywhere else so it's always a good practice i would say for any researcher to always start off with that

So you protect essentially the customer data. That's a good point. And if during data collection, the researcher discovers something problematic, right? Have you ever actually encountered a situation where you have maybe an ethical dilemma about whether to share this information?

Because I think that's what I'm understanding from this context. Is there a mechanism to report this within the UX community? That's verbatim what I'm quoting from the person. Okay, I mean, I'm not too sure whether I'm getting the context well. When you say an ethical dilemma, do you mean that it's something that the customer is bringing up? Or is it like the material...

with which we are actually interacting. Yeah, I think it's based on what you collected. Okay. Yeah, I mean, we always have a compliance department with which we can feel questions around these things. If not, the most direct would always be to our managers or the principal researcher, trying to understand whether there are some breaches in ethics. But generally, I've not come across situations like that. Yeah, and I think that's a really good sign. We spoke a little bit about...

privacy as well you know especially in banking privacy is important security is also important for example in Singapore we're having seen an increase in the rise of scams phone scams and people are actually being very sophisticated in terms of like scamming the older workers did you had any thoughts on that on how the situation should have been better managed or even like better designed yeah

Okay, so this was actually something I was literally talking about to my friend in the afternoon. At some point in time in 2020, I did a project around digital confidence. And this was basically around the topic. Basically, there are some marginalized groups of people in the world who might not perceive digital interfaces the way you and I do.

So we actually kind of take it for granted that we are very fluent in using user interfaces, but groups of people like migrant workers or even the elderly, they tend to be a bit left behind because essentially they're not really comfortable with using these interfaces. So that's why they're a bit more susceptible and vulnerable to scammers, right? Who better to prey on than a person who has very little idea of how...

a certain service works or even how phishing links work If we were to be in a similar situation there might be something subconscious that clicks for us like "Hey, this doesn't look right" or "This link doesn't make sense" The timing of the SMS or this prompt is kind of suspect But to these other guys it doesn't factor at all in their thought process So there's actually quite a salient point that I brought up in the research that

security protocols and their understanding of it is actually quite poor and it's something that we need to try to mitigate this risk by either doing some education or really like dialing down the design such that it's simple enough like think of it as like common denominator kind of design where the complexity doesn't really warrant too much of reading into. And you make a really good point there like educating them or even helping

tone down the importance of the design, right? Because I remember I was once walking on the street and an old lady came and asked me, hey, you know, like, is there anything with this SMS I should be paying attention to? It was a government notification that the government has actually sent a letter to a house on something simple. And she thought like it was a life and death matter from the government. And she was really anxious about it. And she asked me questions about it. And I had to assure her, like, it's nothing important. You just check your letterbox.

So like the use of SMS, right? Usually if we receive an SMS from, let's say an official channel, it's usually something very important. Now that these people who are not so educated and not so aware or not so cyber savvy, they're being notified by SMS. So like they think it's something really important that they need to take action immediately. They need to,

to listen and they need to actually comply with the instructions. So yeah, any thoughts on how as if we're designing financial services, if we're designing for public or for the elderly or for people who are less cyber savvy, do you think that's anything we should keep a lookout for as UX designers? Yeah, I would say the first cut is always accessibility, right? And this is something that can be often overlooked when we design things.

So in DBS, we actually have a dedicated designer who's right now looking at accessibility specific designs and making sure that we have clear guidelines on how we

basically design interfaces that will meet these standards of accessibility. But if you are in a smaller outfit, maybe you don't have the luxury of a single person resource to do these things, I would encourage you to actually go online and check out what those guidelines are, because they're not really that difficult to follow. They'll be simple things like font size,

contrast, those are the two that actually stand out. Maybe some sort of settings that would enable people to toggle on and off these things, either natively or they can actually follow the OS settings. So that was something actually interesting that we didn't do, right? In DBS, if you look at our mobile ranking, it doesn't follow your OS accessibility functions. So that is something we need to definitely fix.

Of course, no product is ever perfect and no product is ever done. And it's always a process of continuous improvement. I'm a DBS customer myself. I've seen DBS make a lot of improvements over the years. So I think kudos to you and your team for helping implement them.

And somebody in the chat asked, does the DBS team usually involve frontliners like branch staff, relationship managers during the research and design stage since they probably know the customers quite well? Yes, definitely. So we think of them as almost proxies to the customer. They are so close to the end user that a lot of times they are like our eyes on the ground. So for certain projects, we actually tend to look at them as key stakeholders and we'll kind of

bring them into the fold when we're doing research and design. So they would actually inform us on like, okay, this is something that I see that's persistent in the customers that I deal with on a day-to-day basis. And yeah, this intervention works or this problem is not relevant, et cetera, et cetera. So we can use them as kind of like a first cut to filter what are the most salient problems. And then we'll go deeper and dig using the research methods to triangulate whether these things are actually true or not.

That's a good point. And talking about getting research and after the phase of doing the first cut and getting people to join your research studies, after the recent scams, people should be quite wary of links such as Google links and Bitly and all these funny links. Do you face difficulty in recruiting users? How are you guys recruiting research participants in this case?

Okay, so I'm a bit spoiled because I actually have a recruitment resource on hand. So I don't need to necessarily go through any other channels to get my hands on participants. And also because we live in Singapore and I'm doing research in Singapore and DBS is like the largest bank in Singapore, we have no shortage of customers. But that being said, it's also important to think about having a...

a pool, right, basically of customers that you can tap on. But to build something like that actually takes a lot of time and work. You need to think about incentive structures. You need to think about how you're able to kind of cycle them because you are not going to always use the same participants over and over again because it introduces bias into the studies. So there are a lot of factors to think about in that respect. Yeah. Yeah, that's a really good point. And I think we have some questions about

how you work with product managers as well. And one involves about the roles and responsibilities of creating a persona and customer journey. Do you do that together with a product manager or do you do it only with your UX design partner? Who does what? Or rather what's practice, right? I'm sure it's quite unique in

every different organization, but at least in DBS, which the UX practice is quite mature, who handles personas and customer journey? Me.

That's me. That would be the researcher. Okay, only you? Or do you put in your PM or do you put in your UX designer as well? So ideally, you want it to be collaborative and we do it all the time. So I think we are always moving towards like a more flat hierarchy of collaboration. I see this as a trend that will continue for a long time. Essentially, our roles are going to get a bit more ambiguous. Ambiguous is the wrong word. Maybe a bit more multidisciplinary. So persona studies and building relationships

customer journey maps should be something that is done within a whole team structure. So I might be handling the best practices in terms of how to execute the research to get the data to synthesize such an artifact, but the activity...

essentially should be handled and done by everyone. So in DBS, we try to really involve stakeholders like our product managers and designers in coming to the interviews, taking notes, then sitting in debrief sessions with myself to actually really think about like, okay, does this pattern make sense? Like, what do you hear from this customer? Within the three of us, is it true that this is what he or she said, right?

Again, you're mitigating risk, number one. And number two, you're actually getting a lot of buy-in from your product manager to essentially empathize with your end user, right? Because if they are distanced from the end user, then how do you expect a product manager to carry out his or her vision for the product that they're building?

Yeah, that's really fair. I think it's a good segue to the next question, which is how do you get people to adopt your research insights? I remember sometimes when I did research as a product manager and I show it and it's nice, people think it's a nice presentation and then they forget about it, right? So how do you increase the chance of your research insights being adopted and actioned on? Okay, so deliverables firstly, let me take a step back, would be something like a research report.

So we will detail the structure, the study design, as well as what data we collected, and then the insights, findings, etc. And one of the most important things which I feel I learned a lot having been through like three years, close to four years in DBS is really the recommendations part. You need to be crystal clear about how you communicate what the next steps are.

And those things are something that you can kind of hold the team accountable to because essentially you spend money doing research, you spend time, resources doing the research, and now there's some recommendations that come out of it. We all need to agree that these are steps that we need to do in order to churn out a successful product or a design. And yeah, I would say that is really the crux of the whole research piece, right? Can you write a solid recommendation that everyone is going to buy into?

And then there's also another part about research impact, like metrics, like ROI, things like that. And it could be as simple as acquiring a new customer segment. It doesn't need to be super complex. When we think metrics, we always think like, okay, satisfaction, ease of use, success rate. In DBS, we have five-star ratings.

you know at the end of every session you get to click these five stars and say like okay my session today was like a four or five and those are things we collect over time and it feeds into the the narrative that customer data and satisfaction is important but yeah i'll say coming back to the recommendation part definitely that's something that needs to be really rock solid

Okay, and that's a really good advice right having crystal clear recommendation Actionable insights those are really important, but let's say you've done the research, right? It's it's it's great, but there's so many things going on and people start to forget about it What's the best way to remind someone about it again?

Or what's the best way to kind of like get people to pay attention to the research? Yeah. So my practice right now, what I've tried to do, and maybe this is to all the researchers out there who might be listening to this podcast.

So we work on Figma, so it's a cloud software, very nice because designers are designing their screens on the cloud in files and the great thing is I can insert my research right next to their files. So it's almost like in plain sight, you're literally looking at the research findings, the problem statements, everything that's customer related, you can actually look at it side by side to your design

And then you can design with that in mind. And it's a perfect marriage, right? If you think about it. Instead of having the files sit like outside of each other, what's out of sight, out of mind, right? They say it's right in front of you, man. Like use it.

Yeah, that's a great idea. I mean, of course, I think you curated and you selectively put the most important things for your designer and design partners to actually work on and action on. So and this is a great point about working in a remote era and setting. Someone asked earlier, like maybe when you're doing an affinity map, it might take several hours.

and you do it remotely over the Miro board or a cloud service, I'm curious to know what are the things or what are the practices that have changed

since COVID, what did you have to adapt or what did you have to evolve in order for you to do remote research effectively and still deliver on the results? Yeah, so I would say again, it was really about collaborating on the cloud a lot more closely because in a physical setting, I could actually have as much time as I needed in a separate room with my designers and product managers piecing together and synthesizing these affinity maps.

but I don't have the luxury of doing that right now. It means that we need to set up time, specific time for us to actually synthesize this information remotely, which is a pain, but it's something you get used to. And it kind of like speeds up the process as well, in the sense that everyone's focused, you know, we know this is a task at hand, this is an agenda for the meeting, so we don't come there and like, you know, not try to get that done. I would say I'm thankful for the advances in cloud technology because it really, really helps speed up the process a lot.

Because essentially there's no other way to do it, right? I mean like your hands are tied in this, I mean our hands are tied in this respect. Exactly, especially during lockdown, right? You can't actually go out. Yeah. So I have a lot of questions coming in that are very related to quantitative data and how quantitative plays a role to complement qualitative, right? So do you mind sharing a little bit more about how quantitative research complements your qualitative research, especially when you're doing mixed methods?

Yeah, let's start with that. I would say that's the most powerful way of trying to get research is by adopting mixed methods. And what it just means simply is like having both qual and quant done in succession. So for example, you might do a discovery research piece where I'm trying to uncover the problem, trying to understand the profiles, trying to create personas and customer journey maps.

And in doing so, I come up with basically my hypothesis, right? Like this is all inductive reasoning. So I'm looking at multiple observations and then I'm coming to a conclusion based on those patterns that I've observed in qualitative interviews that this is the truth now, right? But if you just stop at that level,

It's not wrong to then design based on that, but what would give you more confidence at that point of time if you did have the time and resources to execute another research project? I would say you do a quant study to then get a larger sample size and to see whether what you found out in those qual studies are those things representative in the broader population, are those things that you found out popping up in different segments, right?

you can actually get a lot of solid actionable data through a quant follow-up study to a qual and that's what I love doing so like I think every time I get the opportunity if I do I always try to propose like a qual-quant like combo like two punch nice that you brought up the boxing analogy yeah so I really think that is the

That is the most optimal way of doing things. But of course, sometimes you don't have the time, you might be crunched, timelines are really tight, and you need to go on just your core findings, which is fine. Because if you are truly adopting a more iterative approach to the way you're designing, then that doesn't really matter because you're going to cycle through the four Ds again, and eventually land back in the discover phase where you...

then do more discovery core work to triangulate the previous findings. Yeah. Did you say the four Ds or the four Ps? And do you mind clarifying what they are? Oh, right. Four Ds is basically discover, define, design, deliver. Those are the four Ds we roll with in DBS. In DBS. Yeah, DBS. The D in the DBS. Awesome. All right. And then when we look at sort of like that process where you...

bring in the quantitative data. Has that been an opportunity or been a study whereby they're saying different things, right? Your qual data and your quant data are saying different things. What did you do in that situation? Yeah, so it's great when that happens because then it gives you a lot more insight and in a way, again, coming back to this

mitigating risk thing, right? If I'm a company and I'm spending millions of dollars building this product, wouldn't I have wanted to know that my quant studies actually said something different from my qual studies? In a weird way, I've actually saved the company a lot of money, right? Like by not going down this route based on the first set of findings. But it has happened. The way we deal with that is by trying to understand why it happened. So if we understand why that happened and we have another hypothesis for it,

then we can either design around it using those assumptions or we can do another qual study just to back up that research. But essentially you want to do it within the context of maybe a usability test somewhere down the line so that you maybe don't need to do like a qual, qual, qual and then a UTA.

Yeah, that's a really good point. I mean, now that you've been shaped by some of the results, there might be some confirmation bias and audience member actually asked a question. Now, how do you stay neutral all the time as a researcher? Stay neutral? Yeah, good question. I mean, in qual studies, there are certain best practices like don't ask compound questions, don't ask questions which are basically multiple questions in one question.

I don't have a really good example, my brain is freezing but essentially you don't group multiple questions into one question, it's a compound question and then you have things like no leading questions so you remove bias by not asking leading questions like how difficult was it to find this particular button you wouldn't ask that, you ask them how's your experience of finding that button so we can't prime or we can't prompt participants and that's what introduces bias if I get the question correctly

Yeah, it's really great. And I think these are related to the way you communicate, right? And these are also best practices that we teach our students as well. And I was just wondering,

What about for yourself? How do you cross-check yourself to stay neutral? And I think it's hard, right? Because sometimes when you look at the quant data from the first report, you're like, oh, what's happening? Like then you're swayed to a certain decision or certain direction. Yeah. Yeah. I mean, the way I see it, if there is contradictory results from both studies, you need to infer why that happened. And the inference is very powerful because you as a researcher, you're kind of imbued with this idea

special card where essentially your insight is an inference. You're inferring something based on what you observe or cross-checking it with some other data. So you are given that kind of freedom to infer and then the inference becomes a hypothesis which you then use to either further validate, invalidate, or you run with it and create a design around it.

So there's no real perfect solution to when that happens, but it does give you an opportunity there to infer why that happened. And that is often very powerful because that would really give you like the aha moment, right? Like,

how come what we observed or what we found out in the first test is suddenly contradictory in the second. I have some great examples but I can't really share them right now because it's... Yeah, that's okay. We know there's confidentiality involved. But it's really nice that you bring that up because sounds like there's a lot of critical thinking involved. And this is something I'm really curious as an educator, right?

How do you help a fellow colleague or how do you help a fellow team member be a more critical thinker? And it sounds like you ask a lot of why in your work to also remain objective and neutral. But yeah, just curious, like what would you prescribe to improve critical thinking in your teammates? Wow, that is a hell of a question, man. Because that's something that I've also struggled with in big groups and, uh,

I really think that critical thinking comes from leaving... Firstly, you need to leave your ego at the door because you need to first and foremost admit that you don't know everything. And as a researcher, that's my humble advice. Admitting that you don't know everything is actually great because it means that you can go out there, search for the truth, and try to validate it.

Secondly, when it comes to critically thinking, yes, definitely the why's. Really helpful. Asking five why's, for example. We have a little exercise around that. I'm sure you're familiar with.

And yeah, just drilling down to what the problem is or the pain point is sometimes also very helpful in developing critical thinking skills because it then just means that you can focus on that one thing. Okay, what is the problem? What is the problem? What is the problem? Why is it happening? And then you drill down to like essentially the simplest form of what that means. And I mean, there's no magic pill to

Yeah, it sounds like it's a practice. It's almost like it's like a muscle you have to keep like training and exercising and all that. And I recall being a team leader and manager as well. And the way I did it is to get my team to regularly do reflections, whether it's reflecting on the work they do or writing a journal or keeping a journal. And that practice of reflection seemed to have

that awareness and with the strength and the awareness, it also helps them think about things at a deeper level instead of just skirting or instead of jumping to solutions, which I think is

Especially for those of us who just started UX design or for those of us who are not familiar with the process, that seems to be the habit and the tendency. If I may add one more point, thinking of what success looks like is also really powerful in thinking critically. So if you were to take two steps back and try to envision, "Okay, what does success look like to me?" and write that down, that can also be a way to encourage you thinking critically down the line about what you need to do to get there. I think that's something that's helped me too.

Yeah, that's also very important in building great products that people love and use. And let's talk a little bit about research ops or research operations. And I think DBS is quite a big UX design team, probably one of the biggest in Singapore. Do you do research ops? And if so, if not, what is the practice of research ops within DBS? So research ops, I think broadly refers to

how you support fellow researchers, right? The same way DesignOps is about just how do you support designers in the best way possible? How do you increase efficiency? How do you make sure that their workflows are tidy, neat, and to the point? And the way we do it, I think I've been involved in certain ResearchOps initiatives within the team. We used to do a lot of like

creating templates because that's something that is a big pain point for researchers either coming in new researchers or guys who have been around for a while

Essentially, it's kind of like the DLS of the research world, right? Like templates to do reports on, to conduct research activities. Let's say you're conducting a workshop. Do you have a certain template that is very easy for you to pull and then modify for your purposes and context? I think that's quite important. Workflow is another. Basically, the core workflow. What's the first step? What's the second step? What's the third step? For a guy...

who's new to research coming into our organization, we want to make sure that this serves some sort of quality assurance, meaning that if let's say he or she came from a different organization where their processes were a bit different, when they come here into our organizations, they can kind of level up

or level down whichever way you look at it to the way we are conducting so it's like consistent consistent yeah systematic so that's like workflow related another one which is really interesting is data structure how do you collect data how do you analyze and synthesize the data is there a certain structure to that

So collecting data can be haphazard if you're not experienced. You go in there, your discussion guide is just like, oh, you know, you're collecting all sorts of berberthym, but what is the raw data that you're actually collecting? What is the finding? How do you actually arrive at a finding from the raw data? How do you synthesize the insight? So you can actually see that if you were to put columns very clearly materialized in front of your eyes, right? Like I went from A to B to C to D, and this is my recommendation, which is like E or F.

And that's something I feel has really boasted the capabilities of our team. Sounds like there is a fair amount of documentation involved. And it sounds like the documentation, of course, you will synthesize your best practice into templates as I'm hearing it. What about data? How do you store research that you have done? Do you have a repository or a library where people can search?

and they get the insights that they need yeah what's going on yeah so we used to have like a basic folder structure like most research teams would have based on like time so like 2020 2021 2022 and then like folder names and projects and stuff quite standard right laza fair but recently we actually moved to a insights bank where we're actually uploading the insights and tagging them to the reports so that essentially across the organization you're able to

democratize those findings. I think a lot of our struggles previously were that we were keeping all the research too close to the chest in a weird way. It was all within the team, the research team's domain, but it wasn't something that was freely accessible or easily accessible to everyone from different departments. So that's something we're trying to change.

Yeah, that's really great that you moved towards democratizing your data and sharing it with the rest of the organizations. I think that's also what a mature data analysis kind of practice looks like, where these things are circulated. How are people reacting to it? Are people using it? Do you see any change? Yeah, it's still quite new. I'd say that you'll need some time to gain traction.

But as I see it right now, definitely exciting. I think there's a change in that mindset that, hey, we do get access to this and we can freely peruse these research documents, which is great for everyone. Yeah, that's really wonderful. Wanted to just end off with a few couple of questions about career and being a UX researcher. What does DBS look out for, UX researchers, or what do you think qualifies to be a good UX researcher?

Yeah, I mean, we spoke about critical thinking, right? I would love to see that in a portfolio. Like a person who is rigorous and methodical in the way they thought about what they were doing, how they collected data, what were they looking for, what's the problem they're trying to solve, and the outcomes.

That is just one part of it. I think curiosity is another, being passionate about your craft. You don't need to be really well-versed in every single methodology that is out there, but at least show or demonstrate your competency in the ones that you have already attempted. And I think that's really powerful. Communication, definitely extremely important. I think that's my biggest takeaway as a researcher as well. Being able to communicate articulately and precisely

is such an underrated and overlooked skill that everyone should have, let alone a researcher. I think everyone in an organisation should have that skill.

I agree because everyone can benefit from better communication skills and especially for a large organization like yours where you're working with multiple stakeholders and people that's even more critical. Yeah and building upon that point on communication like there's this whole idea of storytelling that's really important in research as well.

Because oftentimes, you don't want to go there like a robot, like this is what I found out and this is what you should do. You really should be thinking about piecing together the story that will make maximum impact to your agenda or the objectives of what you found out. And that takes practice for sure. You need to incorporate some storytelling techniques. I'm sure you can find them out on Google. Just Google like storytelling UX. I'm sure you'll find a lot of material.

But essentially, it's about how you structure the narrative around what you're pitching to your stakeholders, which is extremely important. And then of course, there's the craft side, right? So your rigor in executing the research, collecting, analyzing, interpreting the data.

Yeah, this is really great. I think we have a lot of the audience thanking you for your sharing and your candor today as well. And thank you everyone for the questions. Just wondering, you know, you've been an industrial designer yourself. Years ago, you were trying to transition into the field of UX design. Do you have any advice or do you have any words of encouragement for people who are also trying to get into the industry and transition maybe from another design discipline?

Yeah, I would say take a stab at doing some research-related work. It could be as simple as interviewing people around you, your friends or family members, sending out a survey to your Instagram followers. Think of data more holistically. I think we tend to think of data as this really sophisticated, god-like thing that only very

professional people have access to. It's not the case. Like, data can be anything. Your Instagram poll could be data. Emails that you send out could be data. Five-minute interviews that you do on the street could be data. So think about it more holistically and then think about what are you driving towards? Like, what's the problem you're trying to solve? What's our hypothesis? You know, do a bit of digging into that and then go through the steps of, like, coming up with the insight, the findings, and showing how that could possibly, um,

fit into the design or the objective of your research if you're trying to transit from design like I was a lot of it was really about crafting a narrative and you know try my level best to explain what the hell I was doing in my other projects because I think what probably got me the job was like the fact that

I had some sort of level of rigor in the way I approached the research. And I was very detailed about what I did. So I would document like, okay, this is what I did. This is a method I used. These are the people who I interviewed. These are the profiles. This is what I was trying to search. And then like the findings, don't sugarcoat them. Like say them as they are, because that would actually speak a lot more volumes on or truths around like whether you were

you're being true to the craft. There's no point trying to sugarcoat or say something that isn't true because sometimes the greatest research comes from things that you were really totally unaware of or essentially caught you off guard or by surprise and you did more digging around that. Those are the kind of stories that we love to hear.

That's a really good point. And in your opinion, as a final question from the audience, how many percent, let's say you're doing a UX project or UX design sprint, how many percent of that should be allocated to research and synthesizing data?

You're talking about a research sprint or a design sprint? Yeah, like overall when you're practicing the entire UX process, like how much time should be allocated to research and synthesis? Okay, so I would say like if we were to take the 4Ds again as an example, your discover and define stages are typically where you want to front load the research with.

And I'd say you spend like a half, 25-30% of the entire time doing that research. And then the rest of it is really like feeding that research into the design, letting the designers go diversion, come up with a lot of different solutions. Then you converge again using research to drive that decision making, and then you can roll it out to market. So I'll say like 30-40%, maybe I'm biased because I'm a researcher.

we'll never really know but yeah that's my ballpark figure yeah thanks for that and the last question I have is what are you looking forward to in 2022 for work for example I think right now I'm looking forward to doing more horizontal work I think a lot of my work has been

embedded like how I described it in the start of the interview very deep very siloed but right now I like to do work that actually spans across the organization takes a little bit more time but the impact is a lot more pronounced that way so I'm looking forward to that kind of like discovery research excellent and with that I thank you for your time Nirav any other final last words or anything else you want to share no no thank you so much Dylan it was a pleasure

I hope you enjoyed this episode. If you did, please let me know what you think. Get in touch with me over email at mail at curiouscore.com. I would love to hear from you. Do also check out our previous interviews and other free resources at curiouscore.com. And until next time, I'll see you on the next episode. Take care and keep leaning into change.