Tips to enhance your team’s user research insights
“We should test this.”
“Are we going to test this?”
Congratulations! If you’re a designer or member of a product team and hearing this, you are already seeing some signs of UX maturity within your organization. Your team is aware that you are not your users and understands that investing in data-driven design yields return on investment. That’s great!
Until it’s, well, less great.

“Any data is better than no data” is one of my design refrains, but the fact of the matter is that a few basic pitfalls can undermine the good intentions of your research, generating specious insights that can lead to inaccurate conclusions or heading down the wrong path. Misleading data can be worse than no data at all.
User Research is-like so much of what we do-a broad and deep area of subject matter expertise. Even seasoned user researchers with years of practical experience are constantly learning and honing their craft, learning new techniques and modulating their approach both across time and in the moment during a series of interviews alike. By no means will three tips sort out your research program, but these tips can help you avoid a few very common traps and encourage conversations that help develop your team’s practice. Without further ado, I give you 3 ways to improve your research results.
Start at the very beginning, it’s a very good place to start.
It’s not just wisdom from “The Sound of Music”, it’s a fundamental step toward more substantial research outcomes, and it’s as simple* as a single question. Really. Literally just one question. In an organization that’s begun doing some (or even a lot of) user testing, the statement “Let’s test this” or the question “Have we tested this?” leads to a somewhat kneejerk reaction. Testing is scheduled, it’s part of the assembly line. The box is checked, phew! You or your product manager won’t face the dreaded “Did we test this?” from Jane Q. Executive at an upcoming review.
But experience has taught me this is a moment to pause and ask a single question that is the most important, fundamental, and yet frequently missed step in conducting user research.
#1: Always ask “What do we want to learn?”
That’s it! That’s the tip!
Whether you as designer will be running the test, whether you’ll be working with a dedicated user research professional or even outsourcing your study, asking this question can avoid wasting a lot of time and energy. Most importantly, it will help put you on a path to conducting research that can provide meaningful data and actionable insights vs. research that just checks a box on your process workflow.
At times, the answer to the question will be immediate and substantive:
We want to know if users have difficulty completing checkout since we’ve changed this payment step.
How do users react to this change from using illustrations to photographs?
Does the user immediately understand this icon means ____?
Sweet! You’ve got a pretty clear idea of what you’re after. You may need to dig a bit deeper or flesh out more of the “why”, but you’re off to a good start in terms of knowing what’s meaningful, gauging what testing methodology will work best (spoiler: more on this later), and achieving some meaningful insights.
Just as often, unfortunately, you will hear the familiar sound of meeting crickets, that unique species known to create uncomfortable silence in remote meetings and conference rooms alike.
Don’t sweat the silence; this is an opportunity for you to lead, facilitate, and educate. Let your collaborators know that a short discussion clarifying what you’re attempting to learn will pay exponential dividends in efficiency. Sure, you may encounter the occasional “Well, we just need to test it.” Moving beyond that initial resistance is a bit outside the scope of these tricks, but you’ll get there. In the meantime, you’ll likely find that your design team and/or sprint team members — whether product, dev, QA, etc.–will be delighted to be included in the conversation and, what’s more, they almost certainly will raise awesome questions and perspectives beyond what you’ve already penciled into your research plan.
“What do we want/need to learn?” Ask it. Every time.
#2: Just say no to yes-or-no questions.
Whether you are facilitating research in the form of a survey, user interview, or even socializing a design around the larger team, changing the way you ask questions can yield a remarkable improvement in both the richness and accuracy of your data and subsequent insights.
Even the grouchiest among us are, fundamentally, people pleasers. When faced with a yes or no question (also known as a closed question), acquiescence bias and other factors will lead many of your users to a default “yes” without engaging in the question¹.
Not the best path to robust learnings, amirite?
Like any habit change it will take some time, but whenever you find yourself drafting (or asking) a yes or no question, take a moment to pause, center yourself on what it is you want to learn, and re-form your question. Here are a few simplified examples:
“Do you like this icon?” might become, depending on your goals “What do you think will happen when you tap on this icon?” “How does this icon look similar to or different from other icons you’ve seen on this page?” or “What do you notice about this icon?”.
“Do you understand how to exit this page?” might become “What would you do next?” “Show/tell me what you’d do if you wanted to move away from this page.” “How do you expect that you’d exit this page?” and so forth.
It takes learning, experience, and habit-building to avoid yes or no questions (especially in conversational interviews), but with a bit of practice you’ll begin to catch yourself. And in the environment of a conversational interview, don’t be afraid to rephrase a question on the fly. Working with a team member to read through your testing script or survey or asking a team member to listen in on an interview and cue you are effective ways of reducing unintended closed questions and enriching your data.
#3: There is more than one way to test.
Again, if your organization is doing user interviews, running surveys, or doing any lean or guerilla testing: you’re on a good path. But one of the biggest pet peeves of user researchers and pitfalls of product research might fall under Maslow’s Hammer, also known as the law of the instrument. This is the bias of defaulting to your most-used tool. In other words, when all you have is a hammer, everything tends to look like a nail.
Many organizations are stuck in a trap of thinking user research takes a single form, and very often that takes the form of either user interviews or usability studies. Not only is this not the case, relying on a single research modality can waste time and dilute results. Teams will often imprint on the type of research they did first or do most often.
In organizations that are set in their ways or have a lot of restrictions on tools or user recruitment, breaking out of this habit may be long game effort, but it’s well worth undertaking. In some cases, simply running a different type of study-say, a design survey with a larger sample size vs. a user interview–will provide results that build interest, curiosity, or even immediate support for letting the test suit the question.
Always return to “What do you want to learn?” If you want a view into task completion, a usability test is your friend. If you’re in an early phase, building towards how to solve a problem, or want to get general feedback or learn more about a population of your users — absolutely get in there with some user interviews. If you’re looking for reaction to iconography, copytext, or want to compare a few design treatments early on — look into design surveys. Whether you homebrew something using Google Forms or leverage one or the other of many great platforms out there, you’re going to achieve richer feedback.
Again: user research is a deep area of subject matter expertise and any user researcher will spend their career honing their craft. These three tips alone can’t promise actionable data, but they certainly will move you closer toward it. Most importantly, I hope they will lead to some fruitful and maybe even fun discussions amongst your team, time saved, and happier users.
[1]https://miro.com/guides/ux-research/surveys-questions, https://www.userzoom.com/interviews/what-are-leading-questions-in-ux/, https://uxdesign.cc/five-pitfalls-to-avoid-when-writing-ux-research-questions-854b19d94f02
For a great primer (or refresher) on user research, I highly recommend “Just Enough Research” by Erika Hall.
