How I work
How I work on projects as a UX researcher
My work process has been iterated over the last 4 years working as a UX researcher. The projects I have worked on have been different in length, constraints, type of project and clients. So I have tried to make a research process that is more or less the same. Here is how I work on projects.
Step 1 – Meeting with stakeholders
This is an underestimated step in most researcher’s processes. I find this is the most important. Meeting with stakeholders allows for open discussions of expectations for the project. How much are they invested? What do they want to learn? What do they want to achieve?
From this meeting, I also want to find out their roles (whether they are in the company or outside of it), how they can help the project (can they help drive recruitment and interest for the project?) and how much they understand the agile work process and the importance of user research.
By the end of the meeting, I expect that the product team and the stakeholders are on the same page about the project, that they understand what will go into our roadmap and how we will work together.
Step 2 – Workshop to discuss what we know and what we don’t know
This is something I usually do with just the product team, sometimes it can include the stakeholders. I find this workshop useful for new products or for ones that have been running for months/years. The sessions are usually planned out slightly differently.
If the product is something new and the product team are all starting together, then it is useful to come together and discuss what we have learned from reading previous documents, what we have learned working in the space before and what we learned from stakeholders. Everyone is essentially starting fresh and we can think about what we should get from the project.
If the product is not new, the workshop is more focused on getting research questions from the group rather than discussing what we know. We decide these research questions by discussing what we don’t know and would like to learn.
Step 3 – Defining the research goals
From the workshop, stakeholder meeting and some desk research on previous research conducted, I’m able to define the research goals for the project and more specific questions for rounds of research we know we should conduct. The research goals also differ depending on which phase of the project the team is in (discovery, alpha, beta, live).
Step 4 – Creating documents and online spaces
From projects I have worked on, I have received great feedback on how I document projects, findings and insights and other research outputs. I make sure to document things as they happen, rather than when the project finishes. I create ‘living decks’ which are decks that I continuously add to when something happens on the project. This helps when I need to create slides for other presentations and reports at the end of a project.
However, it also depends on what type of project I’m working on. If I’m working on a short term project in which the client expects a research report at the end, the living deck is more of a ‘diary’ in which I document events and research. I then strip apart the deck and create a more clean cut report which is aimed towards the client reading and absorbing the findings and insights.
When I’m working on a longer term project where the audience of my work is my product team. I use the living deck for everything going on in the project. I will put research plans, roadmaps, findings and insights and other events in this deck. The product team can easily find all the research related documentation in one place and in order of when it will happen. The roadmap in the deck shows what will happen and when and the slides that proceed contain research goals, questions and activities.
I also make sure to create the right folders for the online spaces too. So my product team and myself can easily find research documents, consent forms and recordings. This makes it easier to keep research data safe too.
Here is an example report and living deck:
You can see that in the research report, that findings and insights are more high level and aimed at those who are not designers. From the living deck, you can see this deck contains the research plans and the findings and insights which are more specific to smaller changes within the design or basic learnings about the company or space we’re working in.
Step 5 – Recruitment
Once it is clear what the research goals are, we can narrow them down into research rounds. Then recruit the users we need for the research. This step vastly changes depending on the project.
I have mainly worked on government projects where the users are civil servants. Therefore I use contacts within the civil service (other researchers and stakeholders) to help with recruitment. Users will need to volunteer themselves to conduct research. I also need to make sure to recruit strategically so that I speak to a range of people and make sure I have the right permissions from managers.
When working on projects where the product is public facing, I sometimes use a recruitment agency. This ensures that we are getting users from different backgrounds.
Step 6 – Conducting research
This one is straightforward. We conduct the research we planned. For research, I like to make sure people from the product team are involved. I usually get them to take notes or just observe the sessions. It depends on the team you get, how much they would like to be involved. If people are hesitant to join, I make sure to explain the importance of seeing users, hearing what they have to say and seeing how they interact with the product.
If people from my team do not join sessions, I run a rota. This gives people a heads up on which sessions they will attend and creates responsibility for them to join.
Step 7 – Analysis and synthesis / research playback
Depending on the type of research conducted, I will either analyse data myself or with the product team in a workshop format.
More exploratory research requires several brains to analyse data. You’re able to think together and collaborate on what was learned from the sessions. I usually get people to think individually then come together for a group discussion.
For research that is testing the usability and understandability of a product, I usually analyse it myself. This gives me an opportunity to analyse the data and find patterns. Then make findings and create insights to share with the team through a playback session. Then we discuss as a team what the research shows us about the product and which changes should be prioritised.
Of course, these steps can change, some will be missed and some steps will be added. This is a generic process I follow to ensure that I can do my job as a UX researcher. Working in this cyclical way also helps the team know how I work once we are working in sprints.
Finishing projects or phases within a project
Depending on the type of project, it will determine the outputs I produce for research. A few examples include user personas, user journey maps, service maps, user needs documents, living decks and reports. Please find examples of my previous work:
