DU019 – User Needs

Transcript

Episode – DU019 – User Needs.
Hosts: Chris Mears and Carla Lindarte.

00:16 Chris: Hello and welcome to Design Untangled with me, Chris Mears and Carla Lindarte. How’s it going?

00:23 Carla: Hi there. Good. How are you?

00:25 Chris: Yeah. All right. I’ve been feeling a bit rough the last week. Combination of Hay fever and colds and over illnesses, which is pretty rubbish for the middle of summer. But feeling bit better now, luckily.

00:37 Carla: Oh, that is good. Oh, that was my phone. I dropped my phone. Sorry, I am always dropping my phone. Do you remember when we used to work together? I was always dropping my phone.

00:47 Chris: Yeah, I vaguely remember that. But it’s a Pixel now, right? So you’ve probably improved it.

00:52 Carla: Yeah, of course. Yeah. I’ve got a brand new Pixel. Yeah, now been fine. Actually, I was a little bit ill as well, but yeah, all good. Enjoying the weather. It’s amazing, isn’t it?

01:03 Chris: Yeah. 10 days straight of actual proper summer weather. And then I am going to Italy on holiday after that, so I am going to be getting lots of Vitamin D.

01:13  Carla: You’re always in holiday.

01:14  Chris: Yeah, I know. It’s just how our roll, high-flying lifestyle.

01:19 Carla: That’s good. Well that is a big need, isn’t it? The need of having holiday.

01:25 Chris: Wow, that is a smooth segue.

01:29 Carla: So what are we talking about today?

01:32 Chris: Oh, we talking about user needs, which really probably should have been the first episode we ever did to be honest.

01:39 Carla: I know, I know. Well we kind of thought that everyone knew what a user need was.

01:44 Chris: No, sadly not. So for those who don’t know, which I will be surprised if it’s many of the people listening that stare anyway, so a user need is kind of a written statement of something that a user of your product or service needs to have fulfilled in order for them to have a good experience. So it’s really kind of the underlying foundation of everything you are doing as a UX designer. You’re trying to meet those needs with your designs and solutions.

02:18 Carla: Exactly. And there could be even levels of them as well. Like maybe the fundamental ones that kind of drive the reason, even the proposition of a particular product or service. So Uber, an example is in need of like having, easy access to transport, wherever you go, something like that. But the more fundamental ones that at the back of each product then you have more like feature level needs as well.

02:48 Yeah. Chris: So another word for those is tacit needs. So if we carry on with the rubrics on poor, the tacit need is something that someone wouldn’t necessarily say to you is something they need from that service, but it kind of has to be there as a hygiene factor almost. So if you are getting a new burger, one tacit need might be that, you need to feel safe while you are using that service. So that is not necessarily something we’d specifically say that that is a need, that your service or product would need to meet in order for them to have a good experience.

03:21 Carla: I never had about that definition. I mean, I understand what it is, but not that tacit need definition. That’s quite interesting.

03:30 Chris: Yeah. gov.uk GDS, language. I am not sure if they coined it, but it’s certainly something that is spoken about a lot within government over here.

03:41 Chris: Yeah, I can imagine. And what other type of needs do we have? So the fundamental ones and they’re more like fit to related ones. Right.

03:50 Chris: And Yeah. And then you’ve got created needs, which are the more specific ones I guess. And they would come out of any solution that you designed for someone. So if you design and you, let’s say add to basket page, then you would have needs, which essentially you’ve created because you’ve created that design and they might be needs around being able to delete things from that basket or edit them. So there are needs that wouldn’t otherwise exist if that person was not using your service.

04:24 Carla: Yeah, I guess the majority of the time as UX designers in a kind of product or service design delivery project, we tend to keep focusing a lot on the creative needs, that sometimes actually lose the division of the fundamental needs or whatever you call them. So that is a big risk because sometimes, as you design like different flows and different journeys within a product, then you’ve realize actually you have to do this and that and then you do that by doing lots of user testing and usability testing as well. You shouldn’t like keep forgetting about the main purpose of why you doing that particular product or service.

05:10 Chris: Yeah, exactly. Nobody is coming to your site or product, whatever it is to use your ads to basket page. They’re going there to throw some other sort of need or goal. And that is just a step along the way. You’ve added a few needs that need to happen because that design is there. But as Carla says, it’s important to keep the bigger picture and understand those epic level or most user needs. What’s the fundamental thing that person is trying to accomplish? What do they need to feel successful and what do they need to feel that they’ve had a good experience as well?

05:49 Carla: Exactly. I mean, it’s always good to kind of step back and every spring door,, every time you delivering a new feature on a new journey, just go back to the why, you are doing it so you don’t lose the vision of the product.

06:07 Chris: And I think we really can’t understate the importance of these needs. If you don’t understand what your user needs are for your different audiences, then you are really not going to be able to design anything effective for them. You’re just going to be shooting in the dark and trying to guess about what you think they need. And that is going to cause you a lot more headache than it’s worth really. So it might be worth speaking about now how you figure out what those needs are if you don’t know already.

06:36 Carla: Yeah, I mean, the best way to uncover them of course, is, through research, I mean, testing and evaluating what you are doing, doing lots of, especially at the beginning, like discovering what these product or service is going to be. Just going more into the generative research and understanding what are those fundamental needs. And then keeping track of all of that as you go through the design of the product or service and testing what you are doing all the time. I know is really hard from experience, to sell the value of research when you are in a delivery project, it’s always really hard. You always going to have pm saying, no, that is not, we don’t have time to test. And even if we had time to test, we don’t have time to make changes. Which is one of the most painful things I’ve heard in the product development project. So I know it’s hard, but then you have to keep pushing. You represent the user, but you cannot be the user. So the more research you do, even if it’s in a lean way, as we talked about before, you know how to do research in a lean way. That Christina’s episode talked about, so just do it, just do some researches. The only way you can actually uncover them.

07:59 Chris: Yeah. If you are going to fight for any thing on the project, then it should probably be discovering user needs. I think, obviously you want to test your products and stuff, but if you don’t even understand why you are building your product and what users want to get out of it, you are going to fail basically, regardless of whether they can find your okay button or not.

08:21 Carla: So that is your job. Basically, your job is not to do the wireframes. As you know, people think. Your job is to make sure that user needs are always considered when you are making design decisions

08:35 Chris: In government as well. If you are not designing for user needs that you understand, then your product or service doesn’t actually ever go live because it is deemed almost, well it is deemed a waste of money for the taxpayer to be fitting that bill because you don’t understand at the core why or who you are designing this service for. So it really is a very important thing to get your head around and you might have to be a bit creative about how you uncover those needs, but definitely make it your sort of number one priority if there are any needs that have been discovered already.

09:13 Carla: It’s also a bit, I mean I found that especially at the beginning when I was more like junior and inexperienced to separate, well, needs from want. So sometimes people say, is this what the customer wanted this or the customer said they would like these a button to behave like this. You have to be careful with that because consumers don’t miss or customers or users don’t necessarily know what they need. They might just talk about what they want. So you have to use a lot of observation and be clever in the way you ask the questions. Try to, I ask the same questions in different ways. If you are showing them a prototype and asking them to perform a particular task, just make sure that, you know, you are not focusing on what they’re saying as much as what they’re doing, because you can get in the trap of the customer. You know, this guy really wanted this to be here but that is a want that is not a need.

10:24 Chris: Yeah. That’s why it’s always good to start those usability sessions with general discussion as well. So you can explore a bit around what the person is potentially trying to do in your space. Learn a bit about how they think, what their, I guess mental models are for different things as well. We probably should do an episode on research and analysis actually because there is, not magic but there is a hazy sort of process where you get from these research observations down to the point where you agree as a team or a research and UX design team, what the user needs you have uncovered actually are.

11:06 Carla: That’s true. That’s a very good one actually, because it’s not an easy thing to do. And I think the more you do it, the more you learn how to do it. But yeah, that’ll be good. Because the ones like getting people to talk to you, it’s quite distracting sometimes. You have to really know where to focus. I actually in, before Sapient, my previous job we started experimenting even more and more, especially for a mobile banking app, we were designing to do more remote and moderated testing. The reason for that is that we uses wood to be able to interact with the prototype remotely. And without being too, moderated by us, which, you kind of allow to really observe what they actually do and how they react to, certain points in the journey. Sometimes people in the lab get nervous or they just think you want to hear that what they have done is amazing or whatever. So, sometimes depending on the project, and depending on the type of fidelity, actually doing remote testing is actually a very good thing to focus on needs and kind of like tried to filter out the ones.

12:27 Chris: Are there any, or have you encountered any alternative approaches to user needs? So are there any things you can use in their stead?

12:38 Carla: You mean in terms of framework?

12:39 Chris: Yeah, I guess

12:42 Carla: I guess, the thing is that there are many, well there are a couple of ways that you could [inaudible 00:12:47] represent user needs. As you said initially at the beginning of the podcast, it could be an articulation of the sentence or an ethic or user story. They also could be embedded into a persona or you know, an archetype. So then you kind of see the differences between these type of people and the other. And most recently a lot of people talk about, the jobs to be done framework, which is a kind of goes beyond persona. And I guess we should do, oh, we haven’t a lot of ideas about episodes.

Chris: 13:23 I hope someone’s writing these down.

13:25 Carla: I am not. Maybe, we should do it after this. And, the jobs to be done frame work actually. I find that sometimes more useful depending on the stage of the project you are at, as well as the type of stakeholders to focus on jobs to be done rather than personas. But basically there are, the fundamental jocks that people, that interact with that particular product and service need to achieve. So again, they are very similar to user needs. So trying to untangle this vocabulary is just the same thing. It’s just that the way you articulate that in the way you frame it is different. So you can articulate it and frame it in a sentence or statement or even some design principles as well could represent user needs, easily. But you could also embed these needs into a persona, which kind of gives it a bit more context in personality and it creates more empathy with your audience when they actually looking at them because they see people, but also can be represented in a jobs to be done framework that has the kind of the macro job sitting down or the, you know, then the smaller ones, I kind of go at the back of that.

So yeah, so there are very different ways that you can articulate them, to make sure your stakeholders or the people in your team understand what you are trying to do.

14:52 Chris: Yeah. I think on a practical level, something else that is quite important is actually having a feel of what priority the needs are. So there are going to be some needs that if you don’t meet them it’s kind of game over for the user. But then there are very often quite a wide variety of other needs, which can be quite hard to figure out what’s more important than what the, generally the stuff that people care about more than other stuff. And you need to balance that with how much effort you might spend designing for those needs over another one. And one way to prioritize that is literally just kind of how often you observed it and your research. So if you’ve been out doing discovery research with 24 people and you saw instances of that need in nine or something, you can say that is at the least and median kind of priority need.

15:52 Chris: And having that in your minds can help you make decisions with the product team where you are getting pushback from the business and stuff. And it helps you get a sense of where you can compromise, where you need to push back. And if they want to do something for some tech constraint reason, but it’s only going to affect some of your lower priority needs, maybe you can make that concession. So having that order in your minds but ideally written down somewhere, and it definitely gives you something good on your day to day, practical level of pushing for your designs.

16:28 Carla: Yeah, I also think you need to balance them as well with the business needs, which is always a challenge that we have. Sometimes the business needs, kind of want to override the user need, just like, really destroyed it or make the experience really bad. So I mean `it is very important. You find the balance between those two is also very important. Then when you are looking at business needs, you actually see how, that particular business need, should or shouldn’t be fundamental for the product. Yeah. You’re designing and I remember once I was in a retail project and the kind of the supply chain people and the fulfilment people were really against the idea of users to select. It was a wine case basically at they select the wines that they wanted to be in the case because now that would have increased the price of delivery as well as the price of packaging quite highly. However, from the use of research, people really wanted to be able to pick their cases and the wines for the wine cases because you know, they are paying for six. So at least they have the option to, have more variety. He came back several, several times from user testing that, we needed to change the way people bought the wine cases, but I mean it was quite a hard decision for the business to say, how can we make this process cheaper and easier for the business? And at the end they actually managed to do it and they basically decided not to have as much profitability out of that product. Just to kind of give the users what they wanted. But sometimes, businesses can’t really do that, and you have to really realize and find better ways to deliver that user needs, that you have to really consider the business.

18:47 Chris: Yeah, it’s tricky, right? Because if you are UX fundamentalists, then you would refuse to do anything that was contrary to your research stuff. But in the real world, I find that type of UXer doesn’t really last very long. So they may, it depends on the culture of the organization, but there are very few organizations which will change their entire business model because of research. Unfortunately, that would be the dream scenario, but that is not the reality of the world out there. So it’s your job to absolutely push for those user needs through influencing business stakeholders, stuff like that. And as I mentioned before, having an idea of the priority of those needs helps you understand where you can make those compromises and where you do have to push back. Because if you are saying no to everything that is coming back at you, when you present your designs, you are going to become very unpopular very quickly. So a lot of the job really is about helping people understand why this stuff is important, but also being flexible in terms of where you can meet them in the middle, without compromising the user experience.

20:09 Carla: Yeah, definitely. I mean there are fundamental things as you said, that change the business model and then you have to be careful on your recommendations. Sometimes it’s just pure pushback from stakeholders. So things that you could do is gets, the whole team for example, to come and participate in testing or research. Broadcast your session or record the videos and get them to actually come with you. I used to get ba sometimes to come with me, help, take notes, et cetera. The reason it was not because we didn’t have enough people in that project, but just say they also create that empathy with the users. They understand and they absolutely send from people, real people utilizing the products. Well, how they feel about certain things. So that is also useful for you to help you and the tools to help you balance out business versus user needs.

21:02 Carla: I also think that you should, consider that needs could change even if it’s the same product, needs could change. I mean the order or business could change depending on the channel or that device that you are actually using. As you’ve seen, things like Gmail for example, would have a calendar, for example, sorry, not Gmail, like Google calendar would have very, very few features and on the mobile app, versus the desktop app. And it is because, there is a different context. So even though they’re the same users and the same product user needs could be very different, depending on the context of the use.

21:49 Chris: Yeah. And it’s important that you keep validating those needs as you go through the project because something that appeared very strongly during your discovery phase after you’ve done, eight more rounds of testing over the course of a few months. It might be that maybe you misjudged it and you never see that needs come up again. So it’s important you don’t disregard the fact that these things can change. You might have made the wrong call on how important they are. And as you interact with more users, do more research., Your understanding of the problem space and what those needs might be will only improve but don’t rigidly stick to what you first thought was the case. You’ll uncover new needs, you’ll discover some needs are no longer relevant. For example, you might build a feature, the main, some other need somewhere else is no longer applicable. So they’re very much a live document almost that needs to keep getting validated. Things get removed, things get added, things get changed. Just keep on top of them as you go for your design process.

22:58 Carla: Yeah, I agree. And also sometimes don’t get overly obsessed or researchy. And I know this is going to contradict what I said before, but there are things that are best practice. There are things that are already exist that had been proven methods and proven ways of doing things. So don’t go too crazy about, discovering how e-commerce works because e-commerce works in certain way and people expect similar features and similar experiences across, e-commerce overall. I mean, you could obviously provide a better or worse experience depending on how you design it, but at the end of the day, people are just buying online. So what I am trying to say with this is that, if you are trying to convince stakeholders, or your clients on research focus on the important stuff, focus on whatever is going to really make a difference in the product your designing and not like, I’ve seen and I have experienced, projects where you go away and come back and say, actually when people buy online and add things, the basket, they will like to delete them. Well that is been proven and that is the case. So just we just focus on something that you really don’t know, and use your mistakes and obviously best practices to cover the known things, if that makes sense.

24:22 Chris: Yeah. And in that example, that is some of the tacit needs stuff. So I think it’s still useful to have those listed somewhere. But as you say, you don’t need to go out and do all the leg work to figure out, people want multiple payment choices at checkout. That’s not a good use of anyone’s time. Have it in your mind when you are doing it together. But what you really want to understand is the deeper goals that people are trying to do in your problem space. So yeah, there are definitely stuff you can leverage out there already, which you can use. But you do need to understand what specific to the design problem you are trying to solve.

25:02 Carla: Well I think that is it for me in terms of needs. Do you have the need to talk about something else Chris?

25:10 Chris: Well maybe before we go we should actually describe how one might be format because it ties into user stories and stuff like that. So then, let us say what format they usually take. So it’s normally as an insert user type here, I want to be able to, or sorry, I need to be able to almost punking myself right at the end of the podcast. So I need to be able to do whatever it is so that I can, and then whatever the outcome that they’re looking to achieve is, and that is a very similar, if not identical format to how you create user stories, which are the basis for development tasks ultimately in Agile. So there are a nice mapping there and it shows how you can take those needs through to actual production of design and code all the way to the end. All right. That’s 26 minutes.

Microsoft Word – DU019_-_User_Needs (1).docx

26:07 Carla: We always do twenty-six minutes. That’s amazing, isn’t it? Maybe I should buy the lottery with the 26 number?.

26:13 Chris: Or just six 26s.

26:14 Carla: Yeah. Six twenty-sixes.

26:16 Chris: Yeah, I have a feeling you might lose that one.

26:19 Carla: You never know. I am very lucky.

26:22 seconds

26:27 Well, not judging by the fact that you dropped your phone within about 12 at the start of this podcast.

26:29 Carla: Well, I am lucky because it didn’t break.

26:32: Chris: That’s solid Google workmanship for you, isn’t it?

26:35 Carla: Oh yeah. All right. Well, it was a pleasure talking to you about user needs. I’ve never thought we were going to 26 minutes ago.

26:44 Chris: No, I had no idea, but it is 27 now. And probably a bit longer once I play the intro and outro, so I might just edit out two minutes of your conversation just to make it fit.

26:55 Carla: Okay, good. Just edit me out and then we will be fine.

26:59 Chris: Yup. Alright. Until next time, see ya.