Practical research at every stage: Expert tips for the entire product life cycle

Struggling with UX research? You're not alone!

Christopher Nguyen, product designer, creator, and founder of UX Playbook, recently hosted a live Q&A with Andrew Millar, the Product Design Manager here at Lyssna. They tackled those all-too-familiar research challenges: working with minimal budgets, choosing the right methodologies, integrating research throughout the product life cycle, and knowing when you've gathered enough data to move forward with confidence.

This wasn't just theory talk, though. Chris and Andrew dove into real solutions for conducting meaningful research at every stage of your product's life cycle. They shared practical advice that won't break the bank, plus ways to make research a natural part of your design process rather than a checkbox.

Whether you're designing solo or with a team, struggling with limited resources, or just wanting to sharpen your research skills, we've pulled together the most valuable takeaways from their conversation. 

How does research fit in the product life cycle?

Research can fit into almost every single part of the process. There are lots of frameworks out there that talk to the product design process – you can speak to any framework that makes sense to you.

For me, I often think about the first diamond in the double diamond framework as the problem opportunity. What's the problem or opportunity you're trying to solve? You really want to understand that as much as you can, and research is really key at that moment. Talking to people is critical, so user interviews are essential.

Other things you might do at that early stage include competitor analysis. You can do that through surveys or by literally testing a competitor’s product. At Lyssna, we have a live website testing feature. You can get other people to look at your competitors' sites and give you feedback on what's working and not working so well, which you can use to inform what you build next.

You might also want to do card sorting or tree testing to understand how people think before you even get into designing pixels or wireframes – how they navigate information architecture.

Then you move on to developing and delivering solutions. What are we going to build here? What's the best solution for this particular problem? There are so many moments in the process, but at the early stage, you want to get feedback as early and as often as you can. A good way to do that is running a preference test where you might ask "option one or option two?"

The other big one is prototype testing. Whether that's through a full UI mockup or even at a wireframe stage, you're presenting a flow that you think is going to solve the problem and testing it with people. That's how you're going to keep improving as you go as a designer.

Do you have any go-to methodologies that you use personally, or that the Lyssna team uses often?

There's probably two that come to mind. The two that I think of are prototype testing and live website testing.

Once you've built a prototype – and like I mentioned earlier, it doesn't have to be a fully designed mockup, it can actually be pretty high level wireframe-y – I think that's a really good way to get people testing whether or not they can perform a particular task.

For example, we did a prototype test where we asked people to see if they can add red capsicums (or red peppers if people are from the states!) to the cart and complete the purchase. You can quite quickly see that 85 percent of all participants were able to perform that task. I think that's a really good way to test flow because quite often you're thinking, “what does it look like?”, but actually the key thing is really: does it work?

We also recently added a Recordings feature. You can actually record a participant’s screen, camera, and audio. You get so much insight from watching particular participants. We asked for those participants to think aloud as well. So they're not just clicking, they're actually speaking to what they're seeing. That's a really powerful way to get insight into flows you're building.

The other one I mentioned is live website testing, which builds off the back of recordings. This is where you can send people to a live website and ask them to find information, like how to return an online order. You can do this for live sites – you don’t have to prototype anything. Participants have an instruction menu, which shows the live site and the instructions that they have to follow. That's a really powerful way to see how they're using your real-life product or a competitor's.

In one example, we asked "was the information where you're expected to find it?" and 70 percent of people said no. That's pretty amazing – we built this thing, this site's live, and yet 70 percent of people don't think the info was easy to find or where it should be.

What if I need insights quickly, but I have a small budget?

I've been there as well myself, and sometimes it can be quite hard, whether it's budget or time or whatever else.

The first and most important thing is to be clear about your research goals. Then obviously it depends on the kind of problem you're trying to solve, the area, the information you're trying to gather.

I think you can spin up tests that are really small and can be really effective. Our panel is actually pretty affordable as well, and you pay as you go with panel credits using Lyssna, so it's not like you're having to spend a bunch of money up front and then get stuck.

A preference test or even just a design survey – you can do that even with a relatively small number because really all you're doing, especially at the early stage of a project, you might just be looking for "are there any things I'm missing?" Especially if you're a design team of one.

Another thing that's really cool with our panel is you can target other designers. You can actually go and say, "I want to speak to 10 other people who work in the UX design product space." And you can ask them questions, just to get feedback on your design. That's actually a pretty cool way to do it as well.

How do you know when you’ve done enough research?

I think the key for me is that it's not one size fits all – every project is different. That might mean you've got less budget or less time. Or maybe you've got a lot of information when you're starting, and maybe there's already a big piece of research that's been done, or other data that helps inform your decision making.

You don't need to do it all. You don't need to be stopping at every single moment. You don't need to feel guilty for it. I think sometimes as designers, especially when I was early in my career, I went from doing nothing to being like, "Oh man, if I don't do research at every stage, am I doing the right thing?" I think it's just about finding the right amount of research to help you move forward. And it doesn't need to be big, time-consuming things – you can run small tests pretty quickly and get information to help inform your decision making.

You can learn a lot through that early research. You can definitely save a lot of time and money by not building the wrong thing. I think it's still critical that you keep your customers as part of the conversation throughout the design phase. But like we said, once your product or feature is live as well, that's when you can get more information.

Ready to improve your research?

Try Lyssna for free and turn insights into better products. Our simple tools help you gather user feedback at every stage of your product life cycle – no matter your budget or team size.

Sign up for free

Sign up for free

Sign up for free