I’ll out myself immediately: I believe having dedicated user researchers on a product team is preferable to product designers doing their own research. It’s a topic for another time, but suffice it to say that things like hard research skills and increased objectivity that researchers tend to lend themselves to increased reliability. 

That being said, we’re amid economically uncertain times, which means many designers don’t have a research team to work with. 

Overall, when there isn’t another choice, I’d frame this as a great opportunity for designers to gain or refine another set of skills and new perspectives that contribute to excellent product design. Here are five things you should know before incorporating UX research into your work.

Design thinking is essentially creative and practical problem-solving. As a product designer, you’ve already got the same mindset as a researcher in the sense that you’re an investigator of the user experience. You’re always sniffing out user problems and brainstorming solutions in your day-to-day work, and that’s precisely what user researchers do.

The fact that product teams often talk about research using casual semantics like talking to users or just doing a few user tests is misleading, and this is an important fact to accept right off the bat.  

User research includes a huge variety of methods—interviews, usability testing, diary studies, ethnography, concept testing, participatory design, and more. 

Planning, executing, analyzing, and churning out actionable insights with user research methodology is not intuitive. Doing it reliably—so that you get accurate information to arm your whole product team with—requires you to hone those skills. 

It’s completely possible, especially for a design thinker like you. Still, you’ll have to approach it with the humility that you may not know everything yet because, somewhat shockingly, many design educations do not include robust research methodology coursework.

If you’re tasked with doing your own research, you’ll likely be conducting user interviews since it’s generally considered a core research practice, and for that reason, I’ll delve into it a bit here.

Before interviewing users, you’ll want to read as much as possible about best practices (try this one, for example). Here are a few critical rules of thumb for you to keep in mind as you get started:

Don’t ask leading questions. As you read more about how to conduct good user interviews, you’ll learn that how you ask a question greatly influences the answer you get—and leading questions are one of the most common culprits when it comes to asking questions in a way that makes users’ answers less reliable. 

Generally speaking, a great way to avoid this is to ensure your question doesn’t include a potential answer. For example: “Do you find it easy to search for specific recipes within the app?” suggests to a user that they should find it easy or that you want them to say that they find it easy. 

However, asking: Tell me more about your experience searching for specific recipes within the app invites the user to tell you whatever comes to mind about their experience. It makes it much more likely that you’re getting a close-to-reality version of their perspective.

We are all terrible at predicting our future. When possible, ask about past or current behavior and sentiments instead. 

We’d all love it if we could simply ask users, would you use X feature if we added it to the platform? Would you pay extra for it? Then, we could ask the right people at the proper volume and always know what we were building would affect our bottom-line metrics. We’d never waste any time, ever again. 

So while I hate being the bearer of bad news, here it is: human behavior depends on so many things, and when you ask people to predict their own, the responses are often people-pleasing, aspirational, or given without much thought. 

Your best bet is to ask for previous or current behavior examples to assess the likelihood of future behaviors. For example, asking a user Tell me about the last time you cooked something using a recipe in the app and hearing about what was challenging will give you a better clue about how you can help over asking if we build a voice feature, so you don’t have to keep checking the recipe, would it make it easier for you? Remember: past or present > future predictions. 

Who you interview matters. Write out your research goals—what questions are you trying to answer? Then spend some time defining who the research sample should include. 

Do you want to interview your current users? People who use your competitors? Users who are in a certain geographic area? Don’t skip over this part because who you interview greatly influences the data you generate. 

For example, suppose you only interview your power users in a research project where your goal is to find your product’s most frustrating pain points for a certain user segment. In that case, you won’t likely collect any perspectives from your most frustrated users, who are valuable considering your research goal.

I’ve seen people conduct great interviews—and then just list what is top of mind regarding takeaways without doing any qualitative analysis process. This is a huge mistake and almost certainly results in inaccurate insights and misguided product iterations.

Why?

Let’s say you conduct ten user interviews on a specific topic or conduct 20 usability studies. That’s a lot of data collected. What you remember when you “sum it up” in your mind is what stood out to you when you’re summarizing, not an accurate analysis of the scope and frequency that various points came up in your research.

What you remember and keep top-of-mind is subject to many biases that can trip up your ability to get accurate insights. For example, confirmation bias is the tendency to remember what confirmed our pre-research assumptions—or recency bias, which is the tendency to remember what happened toward the end of your research versus the beginning. 

As a researcher, this is my absolute favorite part of the research process because it always surprises me in some way. Whether you feel that way or not, embrace it—because it’s a must-have, not a nice-to-have.

I find affinity diagramming the simplest analysis method that aligns with design thinking and has a relatively small learning curve. 

In its simplest form, affinity diagramming involves clustering data by theme. Check out this guide to affinity diagramming on Dovetail for more direction on getting started with this analysis method.

As a product designer doing your own research, you’re being asked to question your assumptions and potentially critique your work for the good of the user experience. 

Whether it’s obvious to you or not—this can be difficult. It’s hard to have been completely convinced you’ve designed the perfect solution for a user need over several months and then conduct research that suggests otherwise. 

You have to not only admit to yourself that you were wrong about something but likely to your colleagues as well.

When conducting and analyzing research, forget that you’re the designer. Forget that you’ll be moving pixels and backtracking on things you said yesterday. 

Research is a time to view yourself simply as a truth seeker. Remind yourself that the purpose of doing user research in the first place is to get to the bottom of things so that your whole team can generate good ideas, improve the user experience, solve problems, and move forward based on true insights rather than assumptions.

Overall, being tasked with doing your own user research as a designer can be overwhelming—but armed with design thinking and enough humility to refine or hone the necessary skills, you’re well on your way to demystifying the user experience for the benefit of your entire organization.