Often teams postpone or avoid user testing because it seems like so much work. People assume that you need a usability lab with sophisticated equipment, multiple cameras and recording tools to run such a test.
At Parallel, we host user tests in the same week we run our Design Sprints. To set up and run all our tests in just in one day, we use a no-frills approach. Here's how we do it.
Let's talk about how to conduct user tests.
Often people postpone or avoid conducting user tests, because it just seems like too much work. It seems like you'll need a usability lab with sophisticated equipment, you'll need recording devices and stuff like that.
The more that you think you'll need these details and you plan to do it with them, the chances are very less that you'll actually do the user test.
At Parallel, we use a no-frills approach to conduct user tests. Can you conduct these tests using a very basic setup that you already might have — maybe a laptop, a video-conferencing software, a webcam, maybe a microphone?
We follow the process recommended by Google Ventures, which is called the Five-Act Interview. What this process does is, it simplifies how you need to go about a user test into five very simple steps that you can follow.
The first step is Friendly Welcome. The idea of this first act is to really get them comfortable to start sharing unbiased insights about how they perceive this product with you.
Make sure that they're really comfortable, make a personal connect, crack a joke, talk about the weather... whatever it takes to get them to be comfortable and open up.
The idea of doing this well is that this helps them really open up. Talking to somebody about their personal experiences, their life, their preferences, is something that could be really personal, which people might hold back.
So that's what you do in the Friendly Welcome.
The second act is called Context Questions.
Before you show them the prototype, which you might be very tempted to, just hold on for a bit longer. Make sure you ask them certain context questions, which will help you profile the user better.
You'll get to know who they are and what their general preferences are, which will help you understand the test or observations that come out of the test much better.
Sometimes we end up going down the rabbit hole of making it into an interview, versus just trying to get some context. You need to be careful that you're just asking enough for you to get some context and profile the user, rather than going into real details.
Let me give you an example. If you're trying to design a travel app and you want to ask them, "Where do you book your tickets?", and they say, "I do it on Expedia for blah blah blah", that's very relevant information for you.
The idea is for you to just get enough information to profile this user on what they do, their habits, their preferences, and then quickly move on to showing the actual prototype and getting them to play with it.
The third act is Introducing the Prototype. It's the most exciting part, when users actually get to see the prototype and start playing with it.
You might need to set the context of what a prototype is — it's something that might have some broken links, it might have some things that work, it might have some things that don't work.
Remind them, again, we are testing the prototype and not them.
PARALLEL TEAM: We are not testing you, so feel free to play around with the design.
You can tell them that you value the negatives way more than positives. It's the negatives in the user test that will help you make the product better.
A very important thing in this step is to get the users to think out loud. It's a mental switch that you need to help them make, where you need to really ease them into speaking out loud whatever is coming in their mind while they are looking at the prototype.
The fourth act is Tasks and Nudges.
When you've already introduced the prototype and set some context around how the tests are going to run, you need to give them some nudges around the different aspects of the prototype that they can navigate to.
You can tell them, "Maybe you can click this button and see what happens" or "Sign up for a free trial" — anything that helps them get started and explore a particular journey.
If they hit dead ends, which is very likely to happen, you need to just guide them to come back and start over. Just nudge a little bit here and there wherever they get stuck.
One really cool trick you can use to get more insights from users is to use incomplete statements. Let's say it's a travel app where they're trying to book a flight. You can say something like, "To find really cool offers, you can..." and then pause. "Why don't you try and find out?"
That will give a nudge to the user to navigate and figure out where they can get that information. And there, you can observe and see how they're reacting to the prototype and how they're finding information.
The fifth step is a Quick Debrief.
When they've gone through the entire prototype and pretty much given you their insights or observations across it, it's time to do a quick debrief where you walk them through what they said, what are the things they really liked, where they got stuck, and what they did not like.
After that, you can ask them if there's anything else that they really want to share, as an open-ended question.
Try avoiding questions which are more survey-type — asking questions like NPS, "Would you recommend it to a friend?", "Would you buy it?".
Typically these questions don't yield any valuable, unbiased insights, so try avoiding them. You should derive those insights based on the questions that you've asked them so far.
Lastly, make them feel that their insights were really valuable for you, and thank them for their time. If you've incentivised them, tell that they'll be getting their reward very soon.
If you have any questions around product design, user testing, or anything that you would like us to talk about, do let us know in the comments.