Why it's tiring to run good user research
By Mark Hurst • May 2, 2019
"That was tiring!" One of the most common responses I get from workshop attendees, just after a research exercise, is how draining it can feel to conduct non-directed "listening lab" research.
I usually tell the attendees: Fatigue is a good sign that you're doing it right. Empathy is hard work.
Despite this, most teams persist in conducting research that doesn't ask much of the researchers: bring the users in, show them the app, ask them "how does this look to you?" and then make sure the users can get through a few key tasks. This sort of validation research is quick and painless. While it can deliver some tactical UI feedback, such a superficial method can't deliver much significant insight.
I'll admit, there are drawbacks to non-directed research:
• It's tiring.
• It doesn't scale.
• It's not taught in most agile, lean, or other product-management processes.
Still, I'm an advocate for sitting down with users, one on one, and actually listening to their context: I want to know what their life is like, and what their goals or pain points are, before I show the product to them. And when I do show them the app (or site or whatever), I want them to show me what the experience is like. That means letting the user lead. The moderator's job is to mostly stay quiet, only asking clarifying questions, until and unless the user needs a direction. (When and how to do that is part of the art of moderating, which I get to in my workshops.)
The results from running research properly far outweigh those drawbacks listed above. Suddenly the team has insights from actual users, unassailable in their legitimacy (given that users were acting voluntarily, rather than answering leading questions), and the findings are relevant to the entire product: the business model, the feature set, the pricing, the language, and the UI elements.
But, yes, it's tiring to run good research.
(Read my book Customers Included for more on non-directed 'listening lab' research.)
(Above: CTRL/Command by Noah Scalin, 2019)
- - -