Episode 29: Understanding the value of UX research

Transcript

Jackie Hey everybody, its Jackie D'Elia. With rethink that FM and I am here with Monique Dubbelman and Cathi Bosco, and we are talking today about why clients would want to pay for UX research. So understanding the why of UX research, and why would somebody want to pay for it and what they're going to get out of it? Anyone wants to jump in and start.

Monique Who's going to start?

[birds chirping]

Cathi I love this topic. I'll start us off briefly. Yeah, briefly, it's a question that I get a lot. So when we're making presentations, and people like, how other designers in teams, like, how do you get clients to pay for it? Like, it's, so sometimes we have to, like sneak our research in. And that's really sad, because the impact and value it can bring to a project and help teams avoid feature bloat, and really make sure we're building the right thing? Are we building the right thing, we can save so much money and energy by helping teams to make evidence based decisions on what users really need? And what their environments really look like?

Jackie That's the brief.

Monique Yeah, I can add that with a very tangible example. Currently, I'm making screen recordings in hotjar, for a workshop with one of my clients. And you can exactly see what they do. And where they struggle, what and where, but not why. And, and, obviously, this is kind of research as well, right? Doing studies of video recordings. And you miss the information about why they struggle. So yeah, you can't just do that alone, or just have a bunch of recordings and then know everything about your clients. It's always a sequence of different kinds of research and information that gives you the whole picture about where you need to look to either build or improve your product.

Cathi Yeah, you have to really expose yourself to users were in a scenario, even if you're working remotely during COVID times or you work on a remote team, you need to be able to ask them questions, like you need to be able to observe them accomplishing a task. And you can do that through shared Zoom recordings. You know, it's getting them to talk about what's going through their mind as they're accomplishing a task, the observational factor, weighs hugely. It won't show up in a screen recording of where they're clicking when they're, you know, putting money in the swear jar, because you wouldn't notice that right. So that kind of exposure, in a very lean way can make a huge impact, even like sitting down with five or six people who are trying to use your software to accomplish a task and observing them through that experience is enough. So it's not like you have to invest necessarily, depending on the project, of course, and the scale of the project, but you don't have to invest a ton of money to really improve your product through some basic field research that's, you know, observable exposure to your software.

Jackie I was going to bring up this point about so when you're working with a client and the the topic comes up about, you know, allocating some time for user research. And a lot of times in design projects. I know we've recently experienced that where clients were surprised by some of the things that were actually needed based on the user research versus what they thought was needed and what they were willing to pay for and put time for in a design. And they learned later that, okay, this is really not what our users need, they need more of this, or they need more of that. And they were able to redirect their efforts to actually better align their goals with their user's needs. And I think that's where, for us, we've noticed that's where the benefit comes from.

Monique Yeah, agreed. Like, it's not always the question of allocating budgets, but allocating budget to the thing you really need to focus on. Because from your own bias, you know your products or your organization so well. And even for us as designers like we look at it with our expert view, still with fresh eyes, which is helpful, but we're not the end users. And you can focus on the totally wrong things and spend lots of money on that. To find out that your users are not interested in that new feature you want to build. So that would be a waste.

Cathi That's true. And when you do a user, I say user research study. But if, if you are not familiar with that term, or the way I'm using that term, it's usability testing, while you're observing people using your software, so let's just call it usability testing, for casual conversation here, we can have another podcast about how to write a great user research study. That's all about usability testing. But the thing about usability testing, that's also very beneficial is it helps you pull out a backlog and prioritize. So typically, what we will do as a team is, well, we'll take all of the information we get from a usability, study and construct user journeys, and show where things are going well, things are going poorly. And then from that we can build a backlog and prioritize it for our clients. And they can run with it. Some of its easy fixes, like add a clear button so that people can clear their search, you know, that's an easy win. Some of them are more complicated, like, we really need an onboarding flow wizard, perhaps for our clients, for them to, for customers to use to really discover and use a complicated tool, perhaps. So does that make sense? Am I rambling?

Jackie No, it does, it makes sense. Another aspect too, I think is, are you doing surveys, because like, I know, a long time ago in a previous life, so I had a software business. And it was clear to me that sometimes I was focusing on what feedback I was getting from specific customers, right. And they may not have been the broad use case of all of my customers that were using the product. And so sometimes surveys and to be able to gain insight about how everybody who's willing to participate in your, in your survey, sees and views, the specifics of your product can be really, you know, can open your eyes to not just hearing the loudest voices, but also making sure that you cover a good cross section of everybody who's using your product.

Monique I think that works if you have a large user base, and setting up a good survey is really hard to do, and not have leading questions, right? What would you do if we wouldn't exist anymore? Would you feel sad? Well, yes or no? I mean, what do you want to hear as a company? We're laughing at this. But I mean, it's just really, really hard. And I know my partner is a researcher. And he's been that for 30 years, and even within his field where they do use it or not user research, but they do research. And they make up a lot of surveys. They do qualitative research as well. Actually, the first step they always do is interviews, like and and a user research study sort of is an interview, right? But the difference is, is that you're not just asking questions, not leading questions, but open questions to let people talk. But you also have them perform some tasks. And I think there is maybe a difference in qualitative research, where you just have an interview with someone, and a user research study, actually, someone does something that you record and take into account. Am I right, Cathi, is that?

Cathi Well, that's Yeah, interviews can be a standalone thing for sure. And usually, when when we conduct research studies, it'll be a combination of some interview questions, because we want to understand their motivation, and how they're behaving. And you know, what their needs are through some questions. But then we also need that evidence of exposure and observational of how they're accomplishing tasks. And doing these early on. In the beginning, again, you get that backlog, to pull out. It's great to collaborate with engineering teams on the backlog. But you also get a fundamental understanding of what the critical user journeys are through your product. And who those people are in terms of what scenarios they're in personas user what those user groups are, I like to think of them more as user groups. What are the critical user journeys so when we did that with the Unsplash plugin, we were able to identify that the most critical user journey experience in the dashboard was people wanted to add an image after they were done writing their post primarily in the flow of writing it. And so we need to do provide direct access to those unsplash images right from there, and then not necessarily they're not going in and just opening their media library ahead of writing an article and that's kind of a surprise to I didn't expect that because, you know, I'm visual. So I'm like picking out the pictures first. But that's not the average critical user journey.

Jackie And that's the work you did with XWP. Right, Cathi?

Cathi Yeah, yeah, that was when we developed the plugin for unsplash. Right, I did XWP. So critical user journeys are really important to have from the beginning as well. So that we're building the right thing, that with the highest priority and impact, it's all about impact, and avoiding feature bloat. And for stakeholders and businesses, they can free up resources that are not wasted. So they're not wasting resources on engineering and development, where they could put a few resources towards maybe marketing that as a new, you know, next step. So there's lots of impact for product teams as well as stakeholders.

Jackie In so let's just just roll with an example. Like if you're, if this is just gonna be basic, but you know, you have a client, they want to redo their website, right? So they come to us or they come to somebody and say, we need, we want to redo our website. And of course, you're going to ask why. Right? So that's like the first question so you can understand what the motivation is for wanting to do it. But at that point, if the client is not really familiar with user research, and how that can benefit, the "I need a new website design", or "I need a new app design", or "we need to do an improvement to our app". How do you want to approach that so that you can really demonstrate the value before you start doing any design work

Cathi They have to unlock what you users really want? And that's the question right? Go ahead, Monique. I didn't mean to overtalk you.

Monique Well, though, there's, I think there's two approaches. I mean, you have to unlock what users want. But you also have to unlock the business goals first, because they need to align it's when you say user research studies, and I think usability definitely has a centered focus on the users, right, as the name says it all. But it doesn't make any sense if that goes against all the values, goals and ideas that the business stands for. So I think ideally, starting with a client interview, and making their goals very specific, what do you want to achieve with this redesign what you want to achieve this new feature? And I prefer to making this as tangible as possible, because then there's no way of having a misconception about the outcome, right? And also making it measurable, like, people want more users, or they want more revenue. And that could be like more users with same amount of revenue or more revenue from, you know, a group of existing users. And then still, how much is more, is that $1 per user? Or is that 100? And in which amount of time and I've noticed that clients find this really hard to do, because they always think that you're going to pin them on it, like you said, $100 her and we've got 200 art, we didn't make it, did you do enough effort for your marketing, you know, stuff like that. So they find it really hard to to make things tangible. And I always try to, you know, make them at ease, like, you know, no one's gonna die if you're not gonna reach it. You know, maybe adjust your goals. Maybe they weren't realistic, right? So you have to work on the on the realistic part of the goal. But yes, smart goals. It's an acronym for specific, measurable. I always forget the A...achievable, realistic and time bound, right. So within a specific amount of time, so that and and then you get alignment with what does the business one and what does the user want? And it will be good to see where do you align and where you have gaps. So you can bring that closer together? I think that's maybe in the end, what you want.

Cathi Yeah, and I think you bring up a really good point is before we would even do a usability testing or a research study for a client, we would hold this, we bring up interviews again, and we would do a stakeholder interview first to understand what the business goals and what they think the users needs and environments are like so they're not always right.

Monique Um, but sometimes they are right, but

Cathi Sometimes they are, Yeah, and then they're right about a lot but yeah, not always everything!

Monique But it's also good to to get some validation, right. It's not always about proving wrong or about it's it's also good to get confirmation from what you were thinking from the users. So you know, you're in the right track.

Cathi And any previous research that they've already done that will help, you know, narrow what we need to focus on as well. I think for stakeholders, they, they're the impact for them can be a variety of things, one of the things they might want to do is like outperform the competition. So we might do some competitive analysis and research in there for them as well, depending on what their goals are, right? They might want to, you know, lighten the load on support. And so sometimes we'll do interviews with support teams as well in advance just to find out what those reoccurring questions are or right. I think I feel Jackie nodding in the background. Yeah.

Jackie I am! We did just that with a client and one of the major goal was reduced the support time, right, reduces support costs, and talking to those that have the data they've collected, right? So they have data that shows what's the most common questions, what's the most issues people have? Where do they have them, when they first start these advanced users, beginners, and you start to look at all of that data, and you start to collate it and put it together, they can get it, they can see some patterns. And that can help you when you are designing, say, a onboarding wizard, right. So that can make a big difference for you and save quite a bit of time. And then you can also take the data that they've got, and then actually go out and do some interviews with actual users and compare that and see if they they do align, right. So or maybe there's some things that are frustrations, or This has resulted in a lot of turnover, where they don't actually have the data because somebody just dropped off. And I think that can be really helpful.

Cathi Helping clients have less churn, and that we can really make a good impact there often. And then among teams on the inside, you know, one source of truth for all. So once we've done some journey mapping and, and provided the evidence based on real exposure, it creates a single source of truth for everyone, including stakeholders, and, and it just, it's like a chord, like you play a chord on the piano, and everything is just like, in harmony. And there's no guessing.

Monique Where you going to make a sound there?

Cathi I was, but I'm tone deaf, so I thought better of it. Yeah, I was thinking of it. I had my fingers in the chord position to play the air piano, but it just didn't, it didn't come out of my mouth. So yeah, so we're obviously very passionate about research and making it affordable and making it a priority. So that if it pays for itself.

Monique You know, because all the things you mentioned, like we could do a stakeholder interview is, I think, a no brainer, we should always do that. Benson, the UX toolkit is so big, that it's really hard to say upfront what you want to do, because it really depends on what you want to achieve, right. And it's not one size fits all. So like I said, when it's a really large scale project, you might pull out a lot of tools to get a bigger picture. But when it's a really small scale company or a small product with, you know, only a small focus, then maybe one or two tools would be enough and would give enough insights already, and that would definitely have the budget align with the size of the project, because, you know, it's the same with building websites. And if I did, it course once with what are they called again, it's not good. I can't remember the name again. It's Australian company that is doing some some coaching stuff for WordPress people, and the guy Troy Dean people may know him in the WordPress space. But he had this comparison about a client who wanted to start up a social media website for fysiotherapists, I think, and it had to be like Facebook, and his budget was $500. Right? So and then you don't really have a realistic goal, because the money that Facebook spends on like, one button to put that in the right position, like how much research goes into that, that would exceed $500 with you know, a measurable amount of money. So I thought those things are good examples. And that's the same with the research part, right? We you don't want to put up the whole toolbox for i don't know i don't want to diminish small projects, you know, but I just want to say that it's ridiculous to do a really big research study and spend a lot of money on something that's small scale. Well and nice for our wallets, but you know.

Cathi Well and and focused, do focused, even if it's a big project, you can break it in and work in an agile way and focus in

Monique Yeah. Because otherwise a major overhaul you wouldn't know what really brought improvement, right? If you do a lot of improvements on a lot of parts, then what was the thing that actually helped improve that experience? So you want to be sure about that.

Jackie No matter what size the project, right, you're still going to have basically three components to it. So you're going to have that understanding part, right? Which is your research, the Why get get all of that information. And then you can have that creative part where you take that information, and then you design something. And then finally, you're going to build it right. So there's that, you know, the, the creative, the build, and then understanding the why at the beginning, and that kind of sums up the whole project. So it doesn't matter what size the project is, you still kind of need those three pieces, even if they're very, very small pieces to make the whole pie.

Monique Mm hmm. Yeah, in university, I used to work with a PDAC cycle or a PAC cycle? Yeah. And because she said you build it in the end, but then it's Plan, Do, Act, Check. And it's sort of you get a lot of these circles, circular models, so you plan for it. So first, it would be like getting the information. You do the research, you act, right, you build it, and then you check because you have to validate if all the things you've been doing, actually did do improvements as users as for the client, as far us so I'd say it's it's an iteration that you keep working on? It's, I mean, working in the tech world in digital environments, it's it's never done, right.

Jackie That's right. Yeah. Yeah, measuring a B testing. So it's that same pie, it just rotates around? Mm hmm.

Monique Yes, yeah. This is where the subtitles would say heavy nodding.

Cathi I think to circle back to, you know, why it's important to include research is that it's important for both the development process in the building and the entrepreneurial part of the work. But it's also important for the business goals. And you know, the stakeholders have slightly different needs, but they're consistent needs. And when when this is done well, they can sleep good at night, they can impress their colleagues, everything works well, they can unlock budget for other opportunities, like internal resources of any kind. So yeah, I guess that's my final thought is like, impress your colleagues, and everyone will thank you for the job you're doing if you do good research! [Laughter]

Jackie So if you're a stakeholder, you just you know, and you have a budget, you just want to make sure that you're you know, allocating enough time for the understanding and the why of the project before you start doing any design. And I can speak personally for me, you know, I, early on in my work, I probably jumped way too fast into the design part thinking, Well, I know what they need, I know what to do. And this is, you know, this is what we should, this is what we should use. And I didn't spend enough time doing actual research on not only from the stakeholders, but also from the users and who was it for, right, it's really hard to build anything if you don't know who it's for.

Cathi Yeah, and I think this a good thing you touched on, because I think that's still a big issue with with larger agencies as well, like clients are really demanding, and they just want to see something. So the visual design is something that's really appealing to people. But recently, a project I've been freelancing on like the visual design was pulled forward before the UX research. And then new insights were unlocked in UX research, and a lot of things have to be revisited because it wasn't workable with the visual design that was already there. Right. So there was a lot of extra time going into engineering a lot of extra time again into showing new iterations of the visual design to the client who said No, we've seen this we want that. That's not working because research shows you know, so it's it costs a lot of extra communication and and engineering time to get aligned with the client again. So I think it's still a big mistake. If companies feel forced by clients to pull that upfront visual design and I mean, it's hard to understand the research and selling something that's not so touchable, right? You want to, you want to see something, smell it. I mean, you can't smell design. But you know what I mean?

Cathi What does design smell like, though?

Jackie I mean, like your agencies where the focus has been on design and per product, visual design of the visual design, a lot of the time and attention has gone with that. Most of the client exposure right time with the client is all been on the visual aspects of everything. And I think it's up to agencies to educate their clients about the value of it, and to really be able to demonstrate that there is value in it, and that it will save time and resources for the remainder of the project.

Monique And frustrations.

Jackie Yes!

Cathi Yeah. I think UI (user interface) gets shipped, it gets shipped with the code. So it's just kind of out of sight, out of mind sometimes. So one of the things I think our team and other design teams that do it well do well, is creating those visual journey maps. So the research becomes a deliverable that people can refer to in one source of truth that helps people not make the mistake of thinking design is just UI.

Jackie You're right. I mean, in our Miro boards, it's very visual. You know, there's lots of information there that has a visual element to it, that is a deliverable that you can hand off to somebody, and they can see Oh, wow, this is the journey that a user has taken, or this is, this is the research of that we've gathered that shows these specific user groups need this.

Cathi And I've had good experiences, walking through customer journey maps with marketing teams so that they can pull out the value proposition they need to communicate to potential customers, as opposed to just marketing jargon. Right?

Jackie Absolutely. Final words? We've got two minutes!

Monique Well I've got three! Oh, now I feel pressure. No. Brain freeze, sorry.

Jackie Well, I think it's just being able to demonstrate the value of it, and to really recognize that it's a central part of the work that you're going to do for a client and taking that time to educate them. And if you get pushback, you know, be prepared, be prepared with some evidence based facts that you've got that can demonstrate the value in this and push that back. And I think once clients see that, and they realize the benefit that they're going to get from it. And it's, and it's measurable. That's really important.

Cathi Yeah, and I'll add to that, that some of these user journey maps that we make, we can't necessarily put on our website because they're confidential, and they show some of the mistakes or errors or challenges within a software program, but we can share them with clients privately so you can see what we're delivering you can see deliverables, and I would encourage people to contact us if they'd like to see what those look like. We will gladly show them but we can't always make them public.

Monique A nice sort of visual illustration to that you get an impression on the kind of deliverable without too much detail,right?

Cathi Without too much detail. Yeah, permission from clients as always given first right?

Jackie Yes. Okay, well, then I guess that's gonna wrap up this episode. Thank you both for joining me and our discussion about this topic, and we will see you in the next episode.

Team UX All The Things Bye!