How much effort is saved by using lean UX research?

Episode Transcript

Moderator:  Hi, welcome to One Question with UpTop Health. In today’s article we’re going to cover our article, “4 Real-World Examples that Prove The Value of Lean UX Research.” After reading this article, the one question I had, Mike, to start off with is, how much effort is saved, I guess compared to not doing anything and doing lean UX research similar to the examples you gave. How much effort is saved by doing that?

Michael: Yeah, that’s a good question John. I think it’s hard to quantify, as every project is different. However, I do feel feel like it saves weeks, if not months in some cases, again, depending on the project. The reason why I say that is some companies out there want summative or quantitative results to base decision making on. And what that really means is, they want large sample sizes or “statistical significance” in the results that they can believe in and are not just happenstance. But doing things like that could take weeks if not months to complete depending on the activity.

With us, a lot of what we do is based in design thinking. We have that mindset of definitely putting the user first and not getting bogged down in all the formalities. We want to keep moving fast, making progress; a bias towards action. And going back to why we even think that lean UX research is good practice, is oftentimes teams are constrained by time, budget, and resources. What we’ve seen is some teams get paralyzed by this and the knee-jerk reaction is to put any available resources into the tangible parts of design itself, such as the wireframes or the visual part and skip research altogether.

What we’re saying is embrace those limitations and milk it for everything you can. To do that you really want to focus on high-value activities that are relevant to your project and will directly contribute to your end goals. That means choosing the right activities that will provide the actionable insights you need to again make progress in the actual project space. That’s the way to go about it these days because things are moving so fast and with companies not wanting to lose market share or don’t want to delay getting their new and improved experience up, you always have to keep moving fast and build that velocity. Otherwise, it’s this feeling of getting stuck in the quick sand. Craig, what do you think?

Craig: Yeah. I think all of that makes a ton of sense. And I think the key thing that you said was providing actionable insights and having a bias for action. We’ve done very formal research projects where the sample size needed to be qualitative, but because there was X number of personas and X number of use cases and scenarios that needed to be tested, just the recruiting and set up for that was almost a month. Then doing the actual user testing, interviews and analysis, then summarizing all that into a report was another month or two. So, you end up spending a quarter working on this. That is an example of trying to find out too broad of answers with too broad questions.

When we’re doing lean research, we’re really focusing it more on specific questions that need to be answered to make decisions to move forward and if we keep looking at things in that way, then it really fits into the agile process and methods. That’s the sensibility that we bring to it. Saying “what’s the best approach?”, “how much research is enough research to get us to where we need to be?” and then “what’s the client’s appetite for having a few unknowns versus all knowns as we move forward?” The lean research approach that we’ve taken saved a lot of time and a lot of money, especially if we’re doing it during the concept definition or the early stages, because then we’re really making an impact before any code has been written. It gets expensive to change things once something’s built and that’s oftentimes when usability testing happens is after its already been built. So that’s my thought.

Moderator: Hey, thanks guys.

Craig/Michael: Thank you.