8 Lessons I’ve learned in 2 years of being a UX Researcher
Learning UX (research) on the job — Part 1
This is part 1 of a 2 part series.
November 7 made it 2 years since I started out as a UX Researcher at Co-Creation Hub.
29 products, 8 workshops (with over 120 people), and 4 talks later, I want to talk about some of the things I’ve learnt.
This is article 1 in a 2 part series on things I’ve learnt after 2 years of being a UX Researcher. It will cover things I’ve learnt specific to the work of being a UX Researcher, and building a research process and practice that helps you work efficiently.
Part 2 will be about general life and career lessons
Plan before you start, and document your plan
For the first year of working as a UX Researcher, I didn’t know about research briefs or research plans. I’d have a vague idea of the things I wanted to do and why I wanted to do them (e.g. would I be doing interviews or focus groups. Or, I’ll be doing a usability test because I want to see if people can find X in this app or prototype). Sometimes, it’d be written in emails to the other people involved in the project and that would be that.
But since I discovered research plans, my life has become easier. A written out research plan helps guide the entire process from defining objectives and research questions, to who to recruit and how to recruit, determining research methods, creating screeners and scripts, budgeting, identifying required resources and equipment, timelines, and milestones. This is your source of truth for what you’re doing and what’s happening with a particular research project, and this ensures that everyone is on the same page.
It especially helped when I started freelancing because I was able to clearly define the work I’d be doing and not underprice my work. I was also able to clearly define outcomes and deliverables for clients.
Always do a pilot
So you’ve made your infallible research plan and everything is perfect. You have all your questions and your script is tight. You launch into your session. Then 10 minutes into the session, you realise that nothing is going according to plan and you’re asking the wrong questions or irrelevant questions.
Piloting your studies (whether interviews, surveys, usability tests, card sorts etc etc) will help you identify whether you’re asking the right questions, using the right methods, and help you catch mistakes. Always test everything, whether you’re doing remote usability tests, surveys, interviews or any other method. It’s best to pilot with someone from your target group, but you can pilot with your colleagues or friends.
Participant recruitment is not as easy as it seems
Because my first project was redesigning the website and all the stakeholders were kind of internal, participant recruitment wasn’t something I considered until I had to work on my first client project at Co-Creation Hub. It’s easy to think that participants are everywhere, just waiting for you to snap them up, especially when you’re giving incentives, but I’ve found that this is often not the case.
Except you’re conducting guerrilla research (which requires its own type of planning), you have to think about how you’ll recruit participants, where to find them, how you’ll reach out to them, if you’ll be giving incentives, what the incentives will be, how you’ll give them to the participants and much more.
Recruitment can take a considerable amount of time to plan depending on a number of factors including your user group, if they’re coming to you or you’re going to them, the research method you’re using, how long the session is and so on. These also influence the size of the incentive you’ll have to give. Always factor this into your research planning, and if you’re a freelancer, factor this into your fee.
Not all deliverables are relevant all the time
UX research is probably the least flashy component of Design, and I think that’s why many people gravitate towards UI and other visual design. Deliverables are one way to visualise the findings from the research work that we do. Think personas, user journeys, user flows etc. There’s the temptation to always have the same deliverables for every project that you do, but that’s not necessary.
When I first started out, I was always creating personas, but now, I rarely use them.
Embrace awkward silences
It’s tempting to want to jump in when your participant becomes quiet, but you might lose valuable insight. Participants are more likely to continue talking if you just wait a bit. Staying quiet will also help you avoid talking over the participant.
Always take notes, even if you’re recording
Technology won’t always work the way you expect it to. Things will crash, restart, or just not work. So write your notes and don’t rely on video or audio recordings.
Another reason to take notes is that there are some things that you might observe that won’t be picked up by the recordings, and there’d be no way to get these insights if you’re not writing them down.
Remember Sod’s law
Everything that can go wrong will. People won’t show up for their sessions. Recording equipment won’t work as planned. Your recordings will erase. Your remote recording tool will have server issues and won’t record your sessions. Your prototype won’t work as planned. Only 1 person will show up for a 7-person focus group session.
There are three things you can do when things go wrong: (i) have a contingency plan (ii) work around the issues, (iii) call it a day.
All of the above scenarios have happened to me. In the last example, what I did was turn the focus group into a one-on-one interview session with the participant who came.
Finally
The best way to get better at conducting research is by actually conducting research. No amount of reading articles and books and watching video tutorials and taking online courses can equate actually getting out there and doing something. It can be terrifying the first time, but it gets easier, and the more you do it, the more efficient you become.
Want to talk about research and design? Send me a DM on twitter: deaduramilade.
