Chris chats with Christina Li (Melon Experience Design) about doing lean UX research that delivers results.
We also cover how to bring research back to your team, recruit participants and how to point microphones the right way.
Show notes
User research – The beginner’s guide
Transcript
The Design Untangled Podcast
Episode: DU005 – Lean UX Research
Host: Chris Mears
Guest: Christina Li, Director, Melon Experience Design
[00:17] Chris: I’m here with Christina Li from Melon Experience Design. Hello, first of all.
[00:24] Christina: Hello.
[00:24] Chris: I am not here with Carla today because she is over in Colombia, so we thought we’d do something a bit different, which is an interview. This will be the second interview with Christina today. The first one was ruined by my amateur recording skills. The mike was facing the wrong way, and we did it in London’s loudest café with the most aggressive barista I’ve ever seen.
[00:49] Christina: And not to mention the ambulance siren going on.
[00:52] Chris: Yeah, there were ambulances. It was crazy. So we’re going to do it in a nice quiet setting now, hopefully get a usable recording. So today we are talking about Lean Research and I’m going to give the floor to Christina to explain what Lean Research means.
[01:10] Christina: Right. So, I think there is two things to think about. Do we mean Lean Research in the context of an agile development? When you are sort of working towards that sprint, and you’re continuously doing something. But I think in the context of what we’re talking about today, we’re interested in how do you do research that is quick but meaningful in a very short period of time, so that you can produce something useful and then to pass it back on to the team. So that’s the kind of context I think about when we talk about Lean Research.
[01:43] Chris: Yup. I think so, and it’s probably worth exploring what the converse idea of that is. So in my head, that’s more the kind of discovery style, exploration type of research where you’re looking at the, or trying to uncover the big themes about what you’re trying to design, and understand how people are doing things currently, that sort of thing, and it’s much bigger picture stuff, I guess.
[02:09] Christina: Yeah, I would agree. Discovery style tends to be, like you say, more contextual or like home visits or you’re going into someone’s office where you’re starting from blank where you shouldn’t assume anything or have any presumptions on what’s happening. So you’re going to explore and to uncover what the current experiences are and what the pain points are. So you probably get a lot richer information that you need to spend longer time to unpack and analyze. Whereas Lean Research, it could be fit into sort of the context of usability testing, where you already have a product or service defined, such as a website or a mobile app, where do you sort of know what you want to get out of it, to where you have already set defined, research questions and outcomes that you want to look for. So in that way then, as-is pattern and how you conduct it would be very different.
[03:05] Chris: So how would the analysis for say, a discovery piece of research differ from kind of the more lean product-based research?
[03:15] Christina: Like I said, I think discovery, because you don’t know what you’re starting from, the analysis would be more themes that’s emerging, or identifying big problem areas that you can then break down into smaller problems to look at how you can solve it. Whereas, usability testing could be an outcome of that process. The next step of doing the research when you have already defined that problem space and you want to try out different ideas or concepts to see if it helps to solve the problems that you thought it was going to solve.
[03:50] Chris: Yeah, and I think the thing with the Lean Research with the sprint based research if you’re doing an agile, is you’ve got to be very sure about what you’re looking to find out. So that means if you’re a UX designer, it means you’ve got to be very clear about why you’re putting certain elements on the page, what you expect the kind of behavior to be by doing that. So now if I put this button over here, I expect the user to not notice something else, for example, because it’s distracting or whatever the behavior you’re trying to drive is. You need to be very clear about why you’re designing what you’re designing, so that the research team can then go out and validate that hypothesis or not.
[04:33] Christina: Yeah, exactly. So one way of doing it could be hypothesis, setting up hypothesis in your design, so based on your findings or based on some assumptions, for example, you’ve seen certain things happening in a round of research. So if I then do x, I should start seeing a different kind of behavior and I will know it’s been successful if I saw that behavior. So it can drive that Lean Research much quicker, because then you’re running a series of experiments, and you could learn that actually it’s not a “thing”. It’s not valid. Great. You can throw it away, or by doing that process, you learn that the “thing” you saw was actually a subset or multitude of other things, and then you can learn from that and develop more experiments based on what you’ve done and design according to that.
[05:23] Chris: Obviously it’s kind of time-boxed to this style of research. So how do you plan so that you’re going to be able to do the research in time and get the findings in time to go into the next cycle of design and testing?
[05:40] Christina: Yeah. So a research plan always helps, so what I tend to do is have a discussion with the team and look at what is ahead in the roadmap, and then maybe plan maybe two or three sprints ahead so roughly we know in maybe a month’s time, we’re looking at this kind of thing so we can start thinking about recruitments, who we should get and what sort of method of research are we really interested in. Sometimes usability testing might not be the most appropriate. It might be a little bit of a quick interview or testing paper prototypes, ideas. So really it depends on the nature of what you are testing. But the idea is we should be able to get ahead. So we have a bit of planning so we could start understanding the people that we want to speak to and the research questions around it.
[06:36] Chris: And so you are obviously generating a lot of research insight quite rapidly in this style of stuff? How do you, or do you even kind of document that? Is it just a case of it’s fed back to the team and that’s it, or is there value in capturing that in a more formal way?
[06:57] Christina: So I think it’s both. Yes, there is value to do that quick feedback to the teams so they can get on with identifying the next steps and what to do. But it’s also important to document especially the decisions you made, because a lot of time when you’re doing something really quick, you can’t do everything. You have to prioritize one over another and it’s important to document your findings and the decisions made at a time, because designs change but fundamental needs of people don’t really change that much over time. And if you were then to pick something up, maybe six months down the line, you don’t want to be doing that sort of research again, you can already have reference to it. It just saves time and money.
[07:36] Chris: Yeah. So something I’ve been trying in our team at the moment is to track our user needs in that sort of design-test-research cycle. So you track the need as it goes through, kind of where did that need come from, which is usually a sort of discovery thing or something you’ve heard in another session, you attach your design faults to it and what you’re proposing to test that need. That then goes through to the research analysis – did you meet the need or does it need more work, and then live data done, or it goes back around the cycle again to be iterated on or back in the backlog if it’s something you’re going to look at later.
[08:18] Christina: Yeah, that’s how we’re doing it as well, and sometimes we turn them into hypothesis as well. So like I said, we could then run experiments to try different design concepts and design elements. But regardless of how you do it, you’re still tracking the progress, whether you’re tracking the needs or tracking it as a hypothesis. And I think that’s important because everyone should be playing in a part in that process. It’s not just a researcher saying this is everything and go ahead and do something about it. It’s a team effort.
[08:49] Chris: And with that in mind, it can be a challenge sometimes to get the team fully involved in the research. Are there any tips you’ve got for sorting that out, getting people excited and intrigued about what you’re doing? I know very often, it’s a new concept to some people, so selling it is challenging.
[09:12] Christina: I don’t know how exciting research can really be.
[09:18] Chris: Have you been in one of our lab sessions yet?
[09:24] Christina: One tries. So like you say, if you’re in a lab then, in that setting you’re more likely to have an observation room where you can have observers, people in your team or other stakeholders who might be interested, or as an introduction to see what research is all about. If they even come along to maybe an hour or two, so they get a flavour of what it is and they can help you maybe do some observation, take notes and then take part in a debrief and analysis. That’s always helpful. But I understand if you’re doing maybe contextual research, you can’t bring your whole team with you to someone else’s home to do a home visit. That would be a bit too much. In that case then maybe considering how you can playback the finding, using videos, bring a bit of story back to life and using storytelling method, it always helps. So have a bit of a scenario, tell the story, and understand the context of why they’re using your service or products today.
[10:20] Chris: Yeah, and I think it’s about making people feel included in that process as well. So sometimes you get people in the project team who can see their part of it as very separate from the ends deliverable. So it’s quite important to get those kinds of people interested and involved as well, I think.
[10:39] Christina: Definitely, and sometimes a lot of the time, from my experience anyway, it’s the work we do. It is change. It is transformation. It is new to these people and they don’t know what it is, and they don’t know how it’s gonna impact them by the end of that process. So it’s about bringing them with you on that journey of change.
[11:04] Chris: So cheesy!!
[11:05] Christina: I was going to say, as cliché as it sounds, but it’s true because some people get scared that they’re going to lose their job by the end of this.
[11:14] Chris: Yup. That’s very true. There is always a big fear in organizations that are going through some sort of big transformation.
[11:21] Christina: And a lot of it why organizations are doing it is maybe to save costs, reduce staff, so there are some elements of change to it that are real and will impact on people’s lives.
[11:37] Chris: Yeah, absolutely. Just going back to the kind of discovery discussion. We both have done a lot of public sector work where that is a key part of it. I’ve also done projects in more sort of established private sector e-comm type settings where almost the discovery part just doesn’t get done because e-comm has been around a while. People believe they reasonably understand what people do in a shopping context, and it’s all just about optimizing, optimizing, optimizing. And I think it’s worth it, even if you’re doing this lean research stuff, occasionally taking a step back and just going why. It’s very easy to get into the granular level of design this one chunk of a thing every two weeks and then when you actually look at it as a whole experience or service, it doesn’t make any sense.
[12:32] Christina: Yeah, exactly. It is about understanding the context, and as you said , in public services, that is so important because you need to show empathy to the people who is going to come in and use the service. You can’t sort of pick and choose who you’re going to focus on as a government. That context is so important. Why are they coming to you today? Have they lost their job? Have they been in a domestic abuse relationship and left the house and need somewhere to stay? There’s just a wide range of reasons why someone would come to the government and is really considering those contexts, and when you have that considered, I think your experience will be a lot richer cause you’re not just focusing on the digital channel or the digital part, and you’re not just focusing on optimizing that bit of the journey. You’re actually thinking about how the stories will fit into the experience you’re going to be designing for.
[13:33] Chris: Yeah, and often the stakes are a lot higher than just whether you get a new handbag or something. It’s whether someone’s …
[13:40] Christina: Or new phone.
[13:40] Chris: That would be nice. Mine is getting bit slow, but it’s often like the difference between someone being homeless or not, or being able to feed to their kids. That sort of level of impact, so I guess they…
[13:54] Christina: There’s a bigger responsibility.
[13:58] Chris: Yup. And I think that’s probably one of the key takeaways from this is whilst you are doing lean product design, you really need to as always bear in mind who your users are, why they are using your thing and look at it as an end-to-end journey.
[14:15] Christina: Yes. I’m just thinking about some of the more complex problems we have tackled or tried to look at within the government, and a lot of time it is whatever we do, it is always going back to the purpose, the reason why. We’ve got this design here, but why, what needs is it missing? What need is it meeting? Why would someone come and look at this, and how is that going to help them do the thing they wanted to do in the first place? So examples like they might have received benefit money from the government. How do we then help them understand the money that they received, so they can budget and hopefully not get into debt and so forth. I think those are really important questions and a lot of it is understanding their background, because not everyone has a high financial literacy skills and it could be a wide range of people coming to use the service.
[15:13] Chris: And I think the other thing to mention that may be different about public sector stuff is that it’s always a possibility that you can find out that the project is just a nonstarter. Doesn’t actually meet any of the user needs that you’ve uncovered during your research, and you might go through a couple of iterations of building and testing of products that you think might work. That is perfectly possible. It just doesn’t, and that’s fine, which is a slightly different attitude I think maybe to some private sector projects, which are, here’s some budget, build this thing, make it work, and there’s not really any concept of failure.
[15:52] Christina: But I still think though, some people will consider that to stop in discovery point is a failure. But we should actually be okay with it because there isn’t a problem. You can’t go looking for a problem and creating a problem out of it.
[16:10] Chris: Yeah. It’s not a good use of anyone’s money really, isn’t it?
[16:13] Christina: No, but I think there is this fear of saying, right, we’ve done a bunch of discovery, there is nothing. You should be okay with that, that there is nothing, or perhaps there are some things, but it’s not big enough or not meaty enough for you to look at a big digital solution around it.
[16:32] Chris: Yeah, absolutely. It’s quite an uncomfortable truth. I guess it’s not something people are used to is saying, let’s stop this project and that’s cool. That’s a cool thing to say.
[16:43] Christina: But it’s not even just that, like I’ve done research with user groups, particular user groups, and after maybe one round or two rounds, it’s clear that whatever concept we had in mind isn’t for them, and it’s okay to ask the researcher to say it’s not working out. We should look at other things to test or look at other solutions to help these people, and it is okay to say that. I think that’s what, well at least I would expect that from researchers to be able to go deeper and be comfortable saying, look, it’s not working out. We need to stop.
[17:20] Chris: Yes. Being able to challenge the project itself as opposed to just the design.
[17:26] Christina: Yeah, it’s all about a lot of times about networking and stakeholder management.
[17:31] Chris: It’s always about stakeholder management.
[17:34] Christina: But it’s also about building really good relationships with your product owner, I think. I think that’s always been something that helped me along my career. Like whether they do sketching with me, whether they come out to do research with me and sitting in on the research and observing, they are really the knowledge of the business. They know so much and they can help you sell your ideas to upper management. So why not be buddies with them?
[18:01] Chris: Yeah, exactly. Get that influence spreading far and wide. It’s the way forward. Okay. So you talked about research plans a bit earlier. How would you deal with that in the context of having kind of participants lined up for when you need to do the testing?
[18:19] Christina: Yes. So a research plan helps because it allows you to get a bit of a forward view on what’s coming ahead., and that way it helps you recruit because when you’re going through a recruitment agency for example, to get people into the research lab in time, there’s usually a two to three week lead time for that to happen. So by looking ahead and knowing what’s coming up, it gives you time to provide the recruitment agency the specification you want. So the types of people you would like to see, how many people, mix of gender, maybe different types of income or different education level. Really depends on what your product and service needs are, but it gives you time to get those people in, so research plan helps that way. Or like me, I’ve been doing a lot of research with enterprise users or professional users, giving them two weeks’ notice doesn’t help because they’re really busy and it’s hard to get them in the room, so what helps is that research plan. So you can look forward and start looking at maybe in a month’s time I do need your help on this, so can we find a time then to sit down and go through our feedback on the prototype?
[19:32] Chris: Yeah, I guess it probably depends a lot on the type of person you are recruiting, what channels and what lead time they would need to be in the right place.
[19:42] Christina: And what helps with professional user groups from my experience is providing some kind of information pack or information sheets, explaining what the project is about, what they can expect during the session and be really clear how much time you’re asking for. So if you’re going to speak to a solicitor, it’s quite expensive.
[20:04] Chris: Yeah, they bill by the hour, don’t they?
[20:05] Christina: Yeah, so they are really doing it from goodwill. So it’s actually being very clear how you are going to use that hour with them.
[20:14] Chris: Yup. That might be slightly challenging in that you might not necessarily know what you’re putting in front of them at that point because you haven’t started the design, but you probably have an idea of what user needs at least you’re looking at at that stage.
[20:30] Christina: Yeah, yeah. You probably have, but you’ve got to be flexible as well because you might learn something from around the session. Realize that’s no longer the right thing to be looking at, like we talked about, being able to say no, let’s stop something and just change your plan accordingly.
[20:49] Chris: Okay, cool. I think that probably wraps up your second grilling of today then on the research.
[20:58] Christina: Yup, not doing it a third time though, Chris.
[21:01] Chris: No, that’s enough, so thank you very much. I’m sure we’ll have you on again in future. So it just remains for me to do the various shout outs and stuff. Hopefully Carla will be back from Colombia soon. We might do a special Christmas episode. I haven’t decided yet. If not, we’ll be back in January. If you have any feedback on this episode or anything else, you can tweet us at @designuntangled. You can check out our new and improved from nothing website designuntangled.co.uk or you can email us if you’re so inclined at contact@designuntangled.co.uk I think that’s enough .co.uk’s for now. So until next time, see you later.