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!
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.
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!
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
