Strategies For Qualitative User Research

*I originally wrote this many months ago as an internal wiki post at the company I worked for at the time.

Why do research in the first place?

• To match business decisions and assumptions to real world use. Making major product decisions without checking them with our users first could put your business at a huge risk.
• To save time and money in design and development, and iterate in a smarter, informed way. Iteration can and should happen both within design, and after your work is released to market. To only iterate in one way would be limiting your potential.
• To achieve an understanding of the people who are actually using your product. You can’t make assumptions based on your own beliefs about how one should use your product.

How? Your research strategy should depend on the scenario.

If the team / business wants to make an impactful product decision, you need to do validation testing.

• Your goal is to validate or disprove assumptions held by the business (or find out if you need to dig deeper).
• Keep an open mind (don’t let confirmation bias cloud your judgment).
• This doesn’t have to test a UI prototype; for example, you could test copy or a video this way as well. You can also validate assumptions through an interview alone if it’s something that can’t be tested.

If the team is working on a new feature, and you don’t know anything about what the user is going through at that step in the journey, you need to do exploratory research.

• This can be a survey if you’re in a rush (better than nothing and easy to send out!).
• Go into testing with goals on what you’re hoping to learn. Unfocused interviews end up wasting everyone’s time.

If the team is working on a prototype for a feature that has already been validated, you need to do usability testing.

• You already know you’re building the right thing, now you want to learn how to build it right.
• This doesn’t require excessive interview questions before the test.
• This can be done with less planning and more spur of the moment. There is no excuse to avoid this — just turn to the person sitting next to you and make sure they can accomplish the desired task in your prototype.

When you have extra time, build a base of foundational research.

• This can take the form of surveys or user interviews. You may not have very specific goals for the study, and can take the time to look at the user journey in depth, with perspectives from different regions/markets.
• The reason this is important is to gain a collective understanding and empathy for our users. When you inevitably have to move too fast to test, you’ll have a better instinct for what the user might need.
• This information can inform personas, empathy mapping, and eventually user journey maps.

Things to remember

• These principles can and should apply to internal staff interviews as well, especially if they’re heavy users of the other side of the product.
• Document all interviews/tests if possible — it will make synthesizing the results much, much easier.
• Ask one question at a time.
• Don’t be afraid to go off script.
• Always ask why.
• Listen to tone of voice or watch for body language to get the full picture.
• No leading questions.
• Sometimes you won’t find the answer or you’ll realize you’re asking the wrong question — that’s okay. Keep going.