Prefer the audio format? Listen to my podcast on Spotify and Apple Podcasts šļø
Why this guide
Starting a UX Research project can be as exciting as it is stressful. Exciting for all the unknowns and the insights you are about to uncover. Stressful, well, probably for the same reasons. The start of a project in UX Research can be uncertain. Unclear priorities, lack of background information or sketchy requirements are almost a given. After 8 years of experience in the field, I thought about writing this article in order to help anyone conducting research not make the same mistakes that I did when starting a project.
Just like everything that you will repeat several times (in this case for several projects), the more you streamline it the better because it will help you to be efficient and not question the process every time, rather consider the problem at hand.
For instance, I became aware throughout my experience that the following used to happen on a regular basis:
- Not all requests needed UX research.
- Among the ones which did, not all had the same priority.
- Not all projects would deliver insights that would actually be acted upon.
- (You already know this one, but just for the sake of the argument) Time is limited.
Scoping for more impact
As UX Researchers, we strive to deliver impactful research through actionable insights. But what is an insight? An insight represents anything you learn about your userāāāa behaviour, a feeling, a mental modelāāāthat challenges your understanding of the said user and requires you to adapt the experience to the needs of the users. Now, an actionable insight, is actually an insight that led to a redesign of the experience users will have with your product or service.
The same way a product will be successful if it aligns with customersā needs and solve their problems, you research will be actionable if it is meaningful, meaning that it addresses a real problem and answers a real need. How to identify this problem and this need, how to make sure of that?
By actually switching from a linear response mode to a scoping first response mode. Usually, when UX Researchers receive a request from a stakeholder to conduct research, they jump right on it to talk to users and deliver insights. If this is done consistently, we might actually observe that not all insights are acted upon. This is important because it indicates wasted time, efforts and money. The most common example of that that I can think of, because I experienced it a lot, is when a stakeholder asks you to do research to validate an existing idea or solution they have in mind (without any rationale as to what problem this solution is answering). By jumping straight onto the research without questioning 1. the rationale behind the solution that has been designed 2. the need for this research 3. the type of research you should do, your research might still deliver interesting insights, but they might not all be actionable. A practical example of that is when research is required by your stakeholders just before an A/B test, meaning that your stakeholders will probably not iterate on the design before the A/B test and will probably even use the research as āinformativeā and prioritise the A/B tests results as they are directly tied to business KPIs (which can feel more tangible).
By scoping your research, and actually researching first your stakeholder, the business and the market, you will make sure that your research (the product) will actually be needed, useful and used as it answers a real need from your stakeholders, the same way a product will ultimately satisfy usersā needs.
This is described as moving on from the linear response mode to the scoping-first response mode. This time, after you receive a research request, you actually determine if research should be conducted, at all, before sizing it and gathering important requirements so that you can finally run it in the best conditions. That is when your UX Reseach skills and empathising nature should help you strive to be human centred and not only user centered. You must come down to the root of the problem your stakeholder is having to make sure research is the right tool to solve it and if so, what research looks like.
This scoping procedure will also free you from the overpromising and underdelivering well-known issue: if you have more elements brought to your attention before starting a project, you are more prepared to decide the best course of action to run the research and to plan accordingly. Maybe you do not need to test 4 different variations of a flow, if you knew that one of them is in any case more complicated to implement and will more likely not be. Or if you have enough data upfront from previous studies you may not need to use that many open-ended questions (how many times have I regretted this mistakeā¦). See my point?
Your research is to your stakeholder what the product is to your user.
The scoping framework that I use can be conducted through stakeholder interviews and is related to this notion but actually goes beyond that. That is why I will not refer to this framework as stakeholder interviews but rather as a project screener, a pre-kickoff, or simply scoping. Whichever the name, the goal of this step is for you to develop a holistic view of the request and of the problem at hand once conducted.
Finally, it is also crucial that, as the UX Researcher who will carry the project, you take part in the scoping step, rather than leaving it to your UX Research manager or stakeholders entirely. The former, even if skilled in UX Research, might not be hands-on at the moment and might not be the best to determine the best course of action (at least not the only one) and the stakeholders might simply not know enough about research to leave it entirely to them.
What scoping can bring you
By scoping your research with this framework you will:
- Make sure your efforts are put where they are most useful
- Have a higher clarity as to the approximate size of your research
- Gather the necessary knowledge to start your project and make sure you are aligned with your stakeholders
When should you do it?
The answer is pretty straightforward: as early as possible, meaning when you receive your research request from the stakeholder.
The earlier you scope your UX research project and the more you strive to have the scope clear, the less time you will waste later down the road. You will also dramatically reduce the risks of misunderstandings between you and your stakeholders.
Naturally, you might not have all the answers to your questions from the very beginning. That is why my framework is intended to be used as a multiple step process: by first determining if research should be used at all, followed by determining the size that the research project should have and ending with the specifics you need for you to run your research project.
Ideally, a research project should start when all the questions are answered. In practice though, this is oftentimes not the case but I would advise against starting any project without the first 2 sections answered: āShould any research be conducted at allā and āHow big should the research beā.
How should you do it?
The format is actually not that important. What matters is to go through the process of wondering 1. if research can and should be conducted, 2. how heavy the research should be and 3. what you should know before kicking off.
Naturally, the answers to these questions will mostly be provided to you through stakeholders āinterviewsā. Interviews is not the only way though. Do what fits your ways of working and what would fit most to the workload of everyone. You can integrate this framework to the tool you are mostly using (Miro, google sheets), what matters is that you have as many questions answered as possible by the end of the scoping stage.
In the past, and depending on the company I was working at, I would either have a meeting with stakeholders and simply going through the questions together, sending them the questions over email or even through a workshop!
As I said it several times already, the framework consists in several parts:
- Determining if research should be conducted or not
- Sizing the research need
- Researching the research request
The objective of this framework is to provide you with a list of questions from which you can pick the ones you need depending on the circumstances. The list of questions is by not means exhaustive nor it is intended to be used entirely every time. Please do not bombard your stakeholdersāāāas a researcher, you are also expected to try to look for the answers by yourself if you know it will be easier than asking your stakeholders. Finally, it needs to be adapted to the needs of every scenario and company.
Follow me on Medium and on my Substack for more articles š