With 22 years in the field of User Experience, I felt it was about time to provide more career advice for UX researchers; this time for researchers in the middle of their careers.
In 2011, I published Career Advice for User Researchers, aimed at people trying to get into the field and with a few years of experience.
In 2022, I just published Updating My Career Advice for User Researchers, aimed at researchers in the middle of their careers.
I seem to do this every 11 years, so look for a part 3 in 2033. Maybe that one will be advice for researchers thinking about retirement?
Image by Víctor Villamarín under Creative Commons License
When you’ve been regularly writing online articles for 13 years, with an average of six articles per year, eventually you find that you occasionally come up with a great idea for an article, but later you realize that you’ve already written an article on that topic. That’s happened to me a few times, most recently with an idea to write an article about getting up to speed on the subject matter involved in a project. I realized that I wrote an article almost ten years ago. October 6, 2011, I published an article “Learning the Subject Matter” on Johnny Holland, a UX magazine that stopped publishing new articles a few years later.
I thought about writing an updated version with what I’ve learned in the last ten years, but it didn’t make sense with that original article still being online. However, I recently took a look at that article, and found to my distress that JohnnyHolland.com is no longer online. Sometime within the last year it went offline.
It seemed to be a sign that it was time to finally write that update. Luckily I was able to find my Johnny Holland articles on the Internet Wayback Machine, and I downloaded the text. My original Word documents of those articles had disappeared from a few computers ago. So I recycled the original article and wrote an updated version, revising the original article significantly and adding and removing pieces based on my experiences from the last ten years.
On June 21, 2021, almost 10 years later, I published the updated version on UXmatters, Learning Complex Subject Matter.
Image reduce-reuse-recycle-repeat by Phil Gibbs is licensed under CC BY 2.0
I love conducting user research. I’ve been doing it for almost 20 years now. However, I admit there are times when it can try your patience. As a researcher you often conduct the same sessions, asking the same questions, observing the same tasks, and often hearing similar answers – over and over and over again. So it’s inevitable that at times in your career you can suffer from user research fatigue.
In my latest UXmatters article, Retaining Your Sanity as a User Researcher, I provide tips for avoiding user research fatigue and maintaining your sanity, including:
- Don’t schedule more participants than you need
- Don’t schedule too many sessions per day
- Take breaks between sessions
- Get away from the research at the end of each day
- Break up large-scale research
- If you don’t have enough time, adjust your effort
- Ensure your job provides enough variety
- Continue to learn
- Indulge your outside interests
- Remember you’re making the world a better place
So check out the article, Retaining Your Sanity as a User Researcher, or to read more about user research fatigue, check out my article, Overcoming That Dreaded Malady: User Research Fatigue.
“Generic Sign Project – Fatigue” by Kevin H. is licensed under CC BY-NC-ND 2.0
For some projects, your clients can be the best source of user research participants. When you’re looking for their employees, their members, or their customers, your clients are the best source for lists of potential participants. Also they often have a relationship with these potential participants. They may know them personally, or at the very least they are associated with a company with which the potential participants have a relationship. When people get a request to participate in a user research study, they are more likely to pay attention to it, and seriously consider it, if it comes from someone they know or at least if it comes from a person in a company they do business with.
However, there are some perils of asking your clients recruit participants, including:
- They may not have the time or organizational skills it takes to recruit and schedule participants.
- They probably won’t describe the research correctly.
- They probably won’t know the right types of people to recruit.
- They may not schedule the sessions logically and effectively.
- They may give participants the wrong ideas about what they’ll be participating in.
In my latest UXmatters article, I describe these perils and provide tips to avoid them: The Perils of Client Recruiting.
Image credit: George Hodan
What’s so scary about user research? A lot, if you’re a semi-neurotic researcher. Since it’s the Halloween season, in my latest UXmatters article, I delve into some of the scariest aspects of user research, including:
- What if I fail?
- Can I learn something new?
- What if we recruit really bad participants?
- What if the research plan doesn’t work?
- What if there’s not enough time to get through everything?
- What if something goes wrong?
- What if we don’t discover anything important?
- How am I going to analyze all this data?
- How can I present all of this?
But never fear! I also provide advice about how to overcome these fears. Check it out: Fears About User Research.
I’ve heard a lot of bad ideas for user research over the years. Most of these have come from people trying to get around the time, cost, and effort of user research. I write about these in my latest UXmatters article, The Worst Ideas I’ve Heard for User Research. I discuss:
- Management trying to offshore UX work
- Management thinking that anyone off the street could moderate a usability test
- Using your own employees as research participants, because you can’t get the actual users
- Clients wanting to conceal their identities to participants
- Making research sessions too formal and uncomfortable by reading the opening instructions off a card
- A field study participant deciding to move the session to a conference room
- A participant changing an individual session into a group session with coworkers
- Teams thinking that they can save time by skipping the research report
Luckily all these bad ideas failed, but we can learn from them. Check out more in the article at UXmatters.
“innovatiebroedplaats” by verbeeldingskr8 is licensed under CC BY-NC-SA 2.0
It happens to every user researcher at some point. You’re supposed to conduct user research sessions, and you get sick. Sometimes you know in advance. Other times it happens during the sessions. Either way, it’s usually too late to do anything about it.
So much goes into planning, recruiting, and scheduling user research sessions that by the time they’re set, they must happen. And usually the only person who knows enough to conduct the research is the researcher him or herself. So, often there’s nothing else to do but suck it up and conduct the research while sick.
However, there are things that you can do to prepare for the chance that you’ll be sick, and there are ways to minimize the effects. In my latest UXmatters article, The Show Must Go On, I provide advice about how to prepare for the eventuality of being sick, to avoid getting sick, and how to conduct research when you are sick.
Read: The Show Must Go On
“Relief is on the way” by kylestern is licensed under CC BY-NC-ND 2.0
Scoping a project’s user-research phase is a classic Catch-22 situation. Before the project begins, you have to plan the user research activities and the time involved, but you rarely have enough information to make these decisions until after the project begins. In my latest article on UXmatters, I discuss some of the problems you may encounter when trying to scope user research, and I provide advice about how to make scoping more accurate.
Check it out: Scoping User Research
As UX researchers, we tend to focus more time on explaining our findings than in providing our recommendations. Yet, however well we explain the findings and recommendations, there comes a time when we’re not present, and the people who have to implement the recommended changes have to rely on the written recommendations and what they remember from your explanation. So it’s very important to ensure that your UX recommendations are understandable, concise, specific, believable, authoritative, actionable, feasible, flexible, prioritized, and easy to review. I provide advice on how to provide better recommendations in my latest article on UXmatters:
Providing Better UX Recommendations
Any user research is better than doing no user research, right? If you can’t reach your target users, you can do research with your company’s employees, because they’re kind of similar right? If you can’t visit people in person to see them perform their tasks, maybe you can do phone interviews or send out a survey. That’s better than nothing, right?
The truth is that it’s sometimes better not to do any user research than to do half-assed user research. I’m not saying that you always have to the perfect user research conditions or its not worth doing. In reality, we rarely have all the time we need and the perfect circumstances to conduct extensive user research. So it’s understandable that we sometimes have to cut corners and make do with what we’re able to get. However, there’s a fine line between discount user research and half-assed user research.
The danger is when you always cut corners, you can become an enabler. Your shortcuts become the norm, allowing your company to check off the user research checkbox, allowing them to say, “Yes, we do user research.” If you can’t eventually convince them to devote more time and effort to user research, sometimes it’s better to practice tough love and let them fail by not doing any user research, rather than allowing them to rely on poor quality research.
In my latest UXmatters article, I provide advice about how to know when you’re practicing half-assed user research and how to improve. Check it out: Avoiding Half-Assed User Research
Image by Spider.Dog