Collecting Research Requests: Listening, Consultation, and Documentation
In a recent essay, I decided to start a series of posts for sharing hands-on experience of what I’ve learned as a junior researcher. Based on the research projects that I have conducted, the process of user research projects can usually be broken down into six phases as below:
- Collecting research requests
- Project kickoff meeting
- Conducting studies and collecting data
- Analyzing and interpreting data
- Delivering and communicating research findings
- Wrapping up project
As the very first step of a user research project, collecting research requests allows researchers to get fully exposed to needs and expectations of stakeholders. In the industry, this step is usually done by holding a couple of meetings with stakeholders. While the subject of collecting research requests can be easily identified from the name itself, it might not still be clear to you regarding what concrete things would be done in the meetings of collecting research requests. With the remaining part of this post, I will share the nitty gritty details that I experienced from the phase — collecting research requests.
To make my experience sharing easy to digest, I’d like to communicate by introducing three keywords in the step to collect research requests.
- Listening
If I would be asked to quantify the time when I kept listening to stakeholders when collecting research requests, the following pie chart can visualize it.
As the research plan and research questions that will be crafted later on highly reply on the needs and expectations of stakeholders, I choose being a listener and giving much time to stakeholders to tell the reason for requesting the efforts from UX research. The essential things that I focus on when listening to stakeholders are
- The context of the product/service. For example, the Product Manager introduces the product/service, talking about the features based on different use cases.
- The questions to be answered. For example, according to the analytics results, the product feature didn’t get much traffic; the stakeholders want to figure out its reason.
- The assumptions to be tested. For example, the stakeholders formed assumptions on user behaviors and designed product features accordingly; they want to get user feedback on the designs.
- The relevant artifacts. Besides listening to stakeholders, I usually ask for relevant artifacts such as a product requirements document (PRD), a demo, or design prototypes. Getting access to the relevant artifacts allows me to align with stakeholders’ interests when planning and executing the research. For example, I usually ask the product manager to give me a walkthrough of the product features and the designer to walk me through the design prototypes. These walkthroughs give me the opportunity to quickly resolve confusions about the product and its features.
- The expectation of user research. For example, with their mental model, stakeholders talk about what things they would expect to get from the user research.
- Consultation
After spending much time on listening to stakeholders and getting walkthroughs of the product and the designs, I will get the chance to speak. While the consultation is the time I talk about how user research will work, I usually limit my ideas to simply providing an overview of the user research project that fits in with stakeholders’ interests. Specifically, what research goals and top-level research questions would be addressed, what appropriate research methods might be used, and how the research will be executed including the recruitment process and the user sessions. The reason why I don’t spend much time on the consultation when collecting research requests is the ideas without enough time to think over might unintentionally mislead the stakeholders. Therefore, as a junior researcher, I prefer to share more comprehensive ideas about the user research project in the project kick-off meeting when I have the research plan to share with the stakeholders.
- Documentation
I know you might argue that documentation is important everywhere in the industry. Yep. Your argument is fair because documentation allows thoughts and experiences to be recorded in a written format for future reference. The reason why I highlight documentation as a keyword when collecting research requests is documenting thoughts and ideas of the stakeholders from the beginning step of a user research project helps me get rid of the situation — shooting at a moving target when things turn to be more complex as the project goes on.
In a nutshell, with my experience, spending much time on listening to stakeholders, giving considerate consultation, and keeping documentation neat and organized are things to do to have a good start in conducting a user research project.
Hope you get what you want from this post. I’m trying to update the post about the project kick-off meeting in a few weeks. Stay tuned.
