Being too attached to methods
Whether you went through a bootcamp, switched from another research-related career or were self-taught, there’s a good chance that you like some research methods over others.
You might choose to conduct user interviews to answer every research question because you’re good at them and you like the direct, 1-to-1 interaction. However, not every research question is best studied using the same method!
Why it’s a mistake:
Using the same, preferred method for every study can lead to distorted findings or stop you from fully answering a research question (as an example, if stakeholders prefer numbers, a card sort or survey might be more appropriate than user interviews).
It also limits your growth as a researcher, because you get really good at one method while allowing yourself to grow weaker in others.
Focus on the decision
Try to figure out what do stakeholders hope to do after the study and what information will help make (or not make) that decision. The info you need to collect might be done better with a method that isn’t your preferred one.
Try new methods & approaches, when you can
Pick a study that you can try something new on and expand you and your team's understanding of research. Try unmoderated studies, field research or even having stakeholders assist with the work.
Not sticking up for the user
You’re sitting in a meeting where your larger team is discussing removing a feature. This feature is not used a lot, seeing high activity for a small group of passionate users. In the lens of the business & engineering, removing it will save them money because they won’t have to support or maintain it in the long-run. The primary stakeholders are very happy to remove this feature and move on to the next topic.
However, as a UX researcher, you know from your studies that this feature is incredibly enjoyed by this group of users. For them, this feature is the make-or-break function that keeps them using their product. They love it so much, they actively tell their friends about it!
Why it’s a mistake:
Keeping quiet in these types of fake scenarios does happen. And it happens a lot. When business teams lead conversations, they can frame a product in the way that makes the business run. They want to cut costs and increase profits and sometimes that’s not aligned with the best user experience.
Representing the user internally and helping guide the team in making user-centered decisions is the job! If this happens over time, not only will the user experience depreciate, you’ll likely see profits decrease because the product no longer adds value, but friction.
Ask questions often
Get in the habit of asking your team members questions about why they want to do something. Questions like “How does adding or removing this feature directly after the user?”, “What data do we have to help make this decision?”, and “How does this work fit with our short-term and long-term goals?” can help your team check their assumptions.
Having other voices can give you the support needed to have difficult conversations. Sometimes the best user experience goes against business strategy in the short-term and that’s a discussion that should be had by many perspectives.
Making unfeasible or actionable recommendations
You’re wrapping up a 6-week research study and putting on the final touches to your research report. You’re going over it one last time, stopping for a moment to review some of your recommendations. “Change the blue call-to-action (CTA) to red so that users can find it faster” and “the drop-down menu should only have 6 menu items, instead of the 10.”
At first glance, these all look like decent recommendations…until you realize that your job isn’t to make solutions!
Why it’s a mistake:
In the first example, your recommendation to change the CTA to another color actually stops a UX designer from solutioning. Most companies have some form of design system they use to ensure that their designs are consistent and that engineers don’t have to ask for specifics. It’s likely that the CTA is blue because it’s an agreed upon design element, not just for fun. Recommending the color change breaks the system and forces both design & engineers to reevaluate their implementation which can add time, cost and complexity.
The second recommendation might incorrectly assume that there might be a clear business need to have 10 menu items. Perhaps some are used infrequently but drive lots of revenue. Your recommendations cannot be made in a vacuum! Many teams have a stake in the product, not just you and the user. The best products have collaboration from many angles.
Focus on the behavior
Narrow down the scope of your recommendations to what’s critical & possible. If you’re only able to change the front-end and not back-end processes before a big release, communicate what’s helpful to change with the front-end design. Mark down bigger issues for later discussion though!
Set expectations and give options
Before a study starts, ask if stakeholders are expecting recommendations out of the research. If they are, ask them if they have any examples of decisions they’d expect you to propose.
They might come back with something like “I’d expect to you to help me pick option A or option B. I don’t like B but it’s cheaper for us to do that.” When you present, provide a few options the team can take but select one as your research-backed recommendation.
When stakeholders start to use your research to make a decisions, they slowly start to buy-in into the process of research. This can make it easier to start another study or have stakeholders come to you with specific research questions.
Not thinking about analysis before a study starts
You just finished the last day of your field study. You're exhausted but you have one full notebook of insights, observations, quotes, diagrams and more. You are confident you have reliable data that will help your stakeholders.
The next day, you get back to your desk and start to comb through your field notes. However, you quickly realize that your notes are all jumbled, you can’t read some of your own handwriting and you’re not sure why you drew some of these diagrams. You spend the next two days essentially repeating the entire field study, but this time it’s through your half-remembered notes.
By the time you’ve started actually going through the data, you have less than 2 days to make your report and deliver it.
Why it’s a mistake:
Lots of new researchers don’t account for the time it takes to actually analyze their data after a study. You might be in a rush to write down the best question to ask in an interview or how you want to structure your Likert-scale items. However, when it comes down to analysis, you’ll struggle with putting the raw data into a format that’s easy to analyze or knowing how to interpret any quantitative findings.
Whether you’re a UX team-of-one (check out this book), or on a larger UX team, you will always have the same limiting factor: time. You don’t have extra days to re-format your data when the deadline is fast approaching. Missing deadlines for a study that you’ve run is a sure-fire way to set a bad tone with stakeholders.
Clean your data regularly
Update typos, move data into analysis-friendly columns, relabel audio/video/images to find them faster and back-up your data regularly to more than one location.
Reporting should inform your study planning
Stakeholders will expect certain information after you study. You’ll communicate that in-person, through a report or both. Knowing what decisions they need to make and how you’ll present it can and should affect your planning. Avoid collecting data that’s not directly helpful to your understanding of the research question or to reporting.
You don’t want to start analyzing your data when in your a study. Just organize it so that it’s easier for you to start finding patterns after your study ends.
Not having a human relationship with stakeholders
You have a pretty good understanding of what the business, design and engineering teams think about for the product you’re all working on. However, whenever you go to pitch a study that can help answer a product issue that the team is having, you’re continually shut down.
Stakeholders give you the typical “we don’t have time for research” or “we’ve got a lot of log data we can use instead of research” and that’s where the conversation ends. You also notice a sense of camaraderie and dedication amongst the other parts of the team, but not necessarily with you or the UX team.
Why it’s a mistake:
Stakeholders are people! They are passionate about things outside of work, have families and friends they spend time with and struggle with the long commute to work just like you! There is a very real element of human-ness when it comes to building a product.
Sometimes, you’re not able to conduct research because stakeholders don’t know or trust you. Other times, they want research but don’t know how to ask for it without being seen as “dumb”. This lack of a human relationship can be a huge blocker in you conducting timely and useful research.
Have coffee and catch-ups
Regularly spend time understanding and evolving with your stakeholders. They’re people too so get coffee, have regular work and non-work decisions and make yourself accessible when you can.
No one has a complete understanding of everything research, design, product, or business. And that’s okay! Let stakeholders know that you’ve never used a particular method or haven’t heard about a type of design exercise. You might find that others are feeling the same and that can lead to a strong researcher-stakeholder relationship built on trust and being open.
Reading about these mistakes doesn't mean that you won’t make them yourself, but it can help be aware and make a plan of action to avoid them.
You’ll make different mistakes as you grow in your career but these basic ones can quickly help you become a better researcher today.