My first year as a UX Researcher -Part 2
This is the second part of my learnings as a first year UX researcher. The first part of this story can be found here.
Tools, Methods and Skills
Skills> Tools
UXR is full of jargons, and every year a few new names get added to the list. But there are some essential skills that are likely to stay regardless of whether the tools stick around or not. If I had to list the core skills I needed to develop as a UXR, they would be: communication (asking questions, listening, presenting, storytelling), observation (being aware of what people do not say, note-taking)and sensemaking (synthesising information from different sources and viewpoints into one objective ‘truth’).
All tools (digital or traditional) are shortcuts made by others who have wanted to find out information in a structured way, and just because some are popular doesn’t mean that they are the best tools to use — it just means that they have been good enough for many other people to work with — and can be replaced as soon as better ones come along.
I’ve realised, there is no substitute for observing the user interact with your product in their natural environment. The next best thing is to speak with them. As a researcher, it is also important to suspend judgement and look with fresh eyes at the information gathered to see patterns. And then, to take your findings to the stakeholders, and tell the story in a way that inspires action — and you don’t need any tools for this.
Importance of note-taking
I’ve always been an avid notetaker, but nowhere has that skill come in handy like it has during research. Good notes, which include quotes, observations about the users’ tone and body language, and very importantly, time stamps are some of the best things you can do while conducting the research. Notetaking, combined with recorded sessions, can make synthesis faster. Suppose, your user says something significant about a key feature which signals their reasons for discontinuing use. You can write the theme/bucket of
the finding, and besides that, write how many minutes into the interview they talked about it (eg: ‘Apprehensive about digital payments’ — 00:18). It will become much easier for you to refer back to the orginal recordings.
When taking notes, assume there will be no recordings to refer back to — only the notes you have made.
Evidence is your real game
“A UX researcher’s currency is evidence. Not design, not recommendations, not methodology. Evidence. Don’t let them shake you from what the evidence from the user directs the team to do” — Joel Barr (in the UXResearch Reddit)
I couldn’t have said it any better.
Focus on Storytelling
Making a 100 page research report describing the details of methods used and processes followed, and then mailing it to stakeholders might make you feel really good about how much work you’ve done, but I can bet most of these people woudn’t even read a few pages in. In whichever way that suits you, learn storytelling — making comics/storyboards, short videos, an interpretive dance (this can have limitations), data visualisation — it’s important to hold the interest of the end user of your insights, because a researcher’s work doesn’t just end at the delivery of the report.
Now I make two stories for each research: a 5 minute overview (for busy stakeholders, also to create interest) and a 30–45 min walkthrough (which starts with the 5 min overview and then goes into the details of the findings).
Tips and tricks
Always test with complete prototypes
Following prototype hygiene is important. Ensure all back buttons, information, progressive disclosure, help, primary and secondary CTA are also working. We may want to test one journey, but we can’t force the user to follow it by making it the only thing that is clickable. The user may end up where you didn’t think they could — but it’s important to know what they associate with your tasks & journeys. If you don’t give them the option, you’ll never know what’s not working for them.
Other things to remember:
Your product is not the centre of the users’ lives. You may categorise the users with respect to your product, but your product will only be a small part. It might often be the centre of YOUR life, but most often, not your users — especially utilitarian products like telco. The only time the user thinks about a utilitarian product for more than a few fleeting seconds is when they’re struggling with the service — which is not a great scenario.
Being a good UXR is never just about research
It’s not just research, like I mentioned earlier. Even if you don’t have impeccable storytelling, the bare minimum is good communication. A researcher’s work includes ensuring the stakeholders have understood your findings (socialising research) and are using it to formulate thir future experiments and inform their design. Lastly, it also includes periodic check-ins with the stakeholders to assess the impact of your research.
You need to put systems in place that work for you, your teammates and other people too. And as a UXR, you’re not just a bringer of good news. Sometimes you need to break the news that a beloved hypothesis has been proven wrong, that we need to go back to the figma file and make things anew.
Do NOT wink and the camera or break into a grin when the user says exactly what you wanted him/her to say. Just, don’t.
Personal Insights:
Humility
You may be treated as ‘an expert’ on the user, but assume you know nothing.
Question everything, including your own interpretation of the situation. In design school, and in design conferences, online resources (basically everywhere), the conversation seems to be ‘Developers don’t understand design, product people don’t understand UXR,’… there’s an unusual focus on other roles being the other. Yes, many of these roles don’t have a direct view of the users of their products — and that’s why you’re here — but to discount their years of experience and perception is a mistake I have made a few times initially. And I’ve been humbled enough times.
To gain trust, bring someone along
The user can really feel like ‘the other’ to those on this side of the journey — a strange, mystical creature who never follows the paths and objectives set by the product team. Nothing like bringing a PM or a designer to sit in for the interview or usability test — it changes perspectives.
Gender imbalance exists
In the organisation I work for, the design team has a fair representation of men and women — and it can be easy to forget that the world may not be equal outside the design team. Here are some challenges I’ve faced: participants not answering my questions because they want to speak to ‘a man’, unwanted sexual advances/flirting during sessions, calling my number at strange hours of the night (sometimes while drunk) and being flooded with Whatsapp days after the sessions. But I’ve found ways to deal with this — I’ve got a different number for calling users, and developed an assertive ‘schoolteacher voice’. No career path is easy, and these are just some of the ‘occupational hazards’ that my male mentor did not warn me about — perhaps because he hadn’t faced a majority of these.
Take care of your mental health
Active listening is draining. Empathising, paying attention for a sustained amount of time to things they are not saying, even more so. To constantly repress your own reactions, to maintain composure takes effort- something that a lot of people don’t understand (After all, all I do is ‘talk to people all day’). It helps to have a ritual to clear your mind. I take 5–10 minute guided meditation breaks between interview sessions to clear my mind. I find this app very useful (iOS only, unfortunately). Headspace is also a good option, and I have a subscription.
Initially, when I was overwhelmed and finding it difficult to disconnect from the sessions, I enlisted the help of a therapist to help me manage my thoughts and feelings. There’s no shame in this — it made me better at my job.
Thank you for reading this far! I hope there was something in here that helped you, especially if you’re a new UXR like I was. If you enjoyed it, please consider reading this other story I wrote about identifying your own point of view, and making sure it doesn’t become a barrier to your objectivity:
