Question about research insights & pain points

When you get insights from doing user research are general insights fine? For example if you get wants and needs but no pain points, is that fine or are pain points a must too?


Wants and needs are usually indicative of pain points. They’re symptoms of a problem (though rarely are they descriptive of the problem itself). Use these as starting points to dig deeper.

There’s the old rule of asking “Why?” five times to get to the source of a problem, and that may work well here. Dig down below the surface to find the root of the problem, and keep asking why until you get there. Don’t assume you know the reasoning behind requests. Eliciting further information may help you get better, unexpected, and actionable feedback.


Great question.

100% second @dougcollins on the 5 Whys.

My additional thoughts: Personally I’ve found making the findings into “To dos” is most helpful when sharing out results.

I almost put out a set of results with the general point:

“People starting looking for products most often on Google.”

Everyone generally knows this, so it’s less helpful as an insight. UX Research can give a lot of “duh” moments because it often confirms things which seem obvious but were never verified.

We noticed when people were using Google, supplemental pages about the product were showing up first in the results. So I changed it to:

“Optimize SEO strategy for Product pages to enhance external search results (Protocols + Tech Manuals appeared first).”

Sometimes the finding might be, as Doug suggested, “Do a follow up activity to learn more about ________.”

I’d advocate it’s always okay to say the research showed we came up short of a clear answer as opposed to pretending we learned all we needed.

Keep up the good work!


Can not fully agree with this. When I started digging into the Pains/Gains thing I was very confused about which needs should be mapped as pains and which are gains. Then I found this article The Practical Guide to Empathy Maps which states:

  • Problems (“Pains”) — Any obstacles worth considering, i.e., an unfamiliarity with technology, or a short attention span.
  • Goals (“Gains”) — What the user hopes to accomplish, i.e., complete the task within 5 minutes.

And with time I developed the criteria for defining this. If a need is something that is core functionality, that’s a pain. For example, if a user is testing a mobile phone and says something like “I can hardly understand what my interlocutor is saying, I want a good quality of voice call” - that’s a pain. Voice conversation is a crucial functionality for a mobile phone.
If a user says “Why my mobile phone can not automatically upload new photos to my PC when I am at home” - that’s a gain. It is about a user being generally satisfied with core functions but dreaming of something above that.

@ralphc_nyc So, I think that a lack of pain points can mean that you mapped some insights as gains while they are pains. Or that you need to go deeper with your research. Or may be that’s fine and there are no pains indeed. Could be anything :slight_smile:

Great. So the way to know when you got to the source of the problem is when they say something along the lines of " I don’t", “I’m not sure”, etc?


That’s one way. You want behavior and motivations. To Doug’s point, why are they doing this activity? What are they trying to accomplish? If you don’t have any pain points, you haven’t dug deep enough. :slight_smile:

1 Like