My first year as a UX Researcher -Part 1
Almost exactly a year ago, the stars aligned and I made the transition from Product Design to UX research within my team at Airtel. How that happened is a story for another day, but here are some things I have learnt in the past year. I wrote this down as a set of guidelines for myself, but if you’re just starting out in your UX Research journey, I hope this will help you navigate your first few months.
Understanding UX research
Research can be a fuzzy concept. Many people imagine research to be a painstaking, academic activity which has no end. As interested as I was in the field, I started with some of the same perceptions. Over the last year, my understanding of UX research has deepened.
“In design, you’re solving for user needs and business goals. In research, you’re solving for a lack of information.” — Erika Hall
Any research — academic or not — is a process to reduce uncertainty. UX research isn’t done for its own sake, though. The most important thing about UXR is to inspire action. UXR reduces uncertainty about the user and helps stakeholders such as designers and product managers make better decisions. Like Erika Hall, author of Just Enough Research, says — UXR is also a design problem.
UXR is different from the academic research I’d been used to doing during my masters. Here are some:
- It is definitely faster (it needs to be).
- You don’t research for the pleasure of finding something out, or because something is interesting — you research behaviour that has a direct effect on the business bottom line. UXR isn’t done for the sake of knowledge creation — it needs to inspire & inform action.
Before the research
Always define a research objective.
It’s tempting to find out ‘everything you can’, and keep questions ‘open ended’ to facilitate discovery — don’t. Define what a successful research looks like, and then stop when you get there. Having a clear objective means outlining the things that you will need to find out, and eliminating directions which will likely not have an impact. You need to make peace with the fact that you can’t find out everything about every user at once.
If you need to find out, for example, how a particular user group experiences the onboarding on your app, then call that out. Don’t forget to ask about that, and when you have adequate information about the topic, or if you get to a point where you’re getting repetitive answers, stop.
You might feel that you can go beyond and ask about the usage experience too, but your user is a human being who will get tired at some point during the conversation. Be empathetic. If you find a fascinating direction, then note it for later investigation.
I have met two types of people when discussing research — ones who say ‘Research is a never ending activity’ and use that as a way to avoid it altogether, and ones who are overly enthusiastic. Clearly defined objectives will help you align with both of them.
Break it up
Research plans are important. It is also important to not be stringent about them. Things change. Priorities keep changing.
Break research down into smaller pieces. Always validate that a problem is a problem when starting out. A simple exercise of calling people up and having a 10 minute conversation will tell you what users are thinking, and is much better than assumptions.
It’s not necessary to go and conduct a full ethnographic study for every project — something simple can facilitate a reduction in uncertainty.
Take buffer time
No matter how well planned your research is, recruitment will take time. Users will not show up for the sessions. Others, you will drop because they don’t fulfil your criteria. There will be internet problems. There are ways to shorten the recruitment cycle (like setting up a tester programme), but some things remain out of our control. People don’t get angry if you manage to deliver ahead of time, but not taking buffer will leave your teammates/stakeholders hanging.
During the research
Don’t jump to solutions
As someone trained in design, it’s easy to immediately start thinking of solutions the moment you encounter a pain point. Your role is to understand the problem as much as possible, and staying focused on uncovering the problem will reveal surprising behaviours, thoughts and reasons.
Take notes
Don’t compromise on this. You may think ‘I’ll remember this — I can’t forget something so important or so unusual’ or ‘I can always return to the recording of the interview and write about it’ but trust me — you will forget it. And no, you will not have enough time to listen to 8–12 hours of recordings. And without notes, you wont know which recordings to listen to and what part of each conversation is worth going over again.
Don’t help your users!
Sometimes, the best thing you can do for the users is not help them.
It pains me to watch people struggle with new technology. Unless you got into the profession out of some twisted pleasure in seeing other people suffer, chances are, you feel the pain too. Especially in usability tests, the participants mention problems that I know how to solve, and I have to use all my self control to not provide the answer. It’s like being a gym instructor in a way — you need to be a little sadistic — to watch them suffer without easing their pain. There are two reasons for this:
1) If I help them out, I’ll never be able to understand the extent of their frustration with the journey, and
2) The moment I start answering the participant’s questions, I portray myself as an expert, which creates an imbalance of power.
Awkward silences are your friends
Don’t try to fill them. It’s a rookie mistake I’ve made too often. If you just stay silent for 5 seconds, your user will elaborate on what they were saying earlier. Or talk about something else you may not have thought about. Repeat after me: the awkward silence is your friend.
After the research
Debrief, debrief
Right after an interview or usability test is a good time to discuss the major findings and observations. Possibility is that your observer (most likely, the designer) noticed things that you didn’t. It’s best to do this after each interview, so that
1) You write things down while they are still fresh in your mind
2) You don’t carry one participant into the next session
Clear your mind
Read #2 from the point above. It’s important to clear your mind and approach the next interview without looking for the patterns from the previous participant, especially when multiple sessions are scheduled in the same day. This is hard to do, but doing a 10 minute meditation between sessions can be life changing. I use an app called Balance (iOS only, for now), and it comes with a free subscription for one year.
Present actionables first
People are busy, and don’t care about your process if they don’t know how it affects them. Only when your stakeholders come across something that either challenges their beliefs, or amazes them, would they want to dig into how you got to that point. And this isn’t something to be offended by — it’s just how people are. Remember this when making presentatins.
Use buckets
When presenting findings, group similar insights and observations together for easier consumption and navigation. Clubbing them also allows different stakeholders to find what is relevant to them.
Measuring Success
Numbers aren’t always needed. Sure, if you can gather the numbers to prove the impact of your research, there’s nothing like it. But numbers are a cumulative outcome of a lot of moving parts working together, and its hard to divorce your contribution from that of the team. Even when numbers are available, it can be a long time before your research outcomes go through the design-development-deployment-use-etc cycles. There are interim ways I use to see whether I am on the right path:
1) A PM returns to us with a new project, or the new phase of the project
2) Designers/PMs reference the research/research repository while making their decisions
3) Teams who we haven’t worked with contact us to fill in their information gaps
4) Results of early stage experimentation based on our recommendations
I know this has been a long read, but this past year has been full of learning, and I simply can’t put everything together in one article. In the next article, I will be covering my learnings about:
1) Skills, tools & methods
2) Personal skills & experiences
3) Tips and tricks
The next part of this story can be viewed here
If you’d like to see that in your home page, consider following me :) Meanwhile, do let me know what you think in the comments below.
