The best way to get your UX Research project started
How to kick off your research project the right way
The key to a successful research project is kicking it off well. This gives a project the best chance to have a fruitful delivery and not waste anyone's time or miss the mark completely. This was the first thing I learned and implemented when I started working as a UX Researcher. This is the original article that inspired how I think about it.
There’s a Notion template available for you to copy and tailor for your projects further down in this article.
Photo by Brett Jordan on Unsplash
Invest in making sure everyone is on the same page about:
Is there a need for research?
Is the development team going to deliver something regardless of the results? Do they already have enough information to make a decision?
What is the appetite for potential findings?
Are they willing to listen if the outcomes are contrary to institutional belief?
What are the drivers for doing the research?
Is it pressure from a senior stakeholder, lack of contextual knowledge or using research as a panacea for general uncertainty?
“Failing to prepare is preparing to fail” — Benjamin Franklin
Goals of the kick-off meeting
A kick-off meeting is a great way to get your stakeholders together so you're all on the same page. This could be done asynchronously through a document with comments. Asynchronous works if your stakeholders have done a similar process with you already.
Assess whether the research project is needed.
Collect context about the project including business and team goals.
Understanding of expectations from all sides.
Identify other stakeholders.
Prioritise this request against other projects. Compare impact and risk and alignment with business goals.
Who should be involved in the kick-off meeting
The core research team are those who would be involved in data collection, interviews, analysis or the sharing of the output. Ideally, the core team learns about the insights early as part of participating in the whole research process. The research report becomes a formality.
Your core team should have these members at least:
For other people to attend the kick-off, you could consider- Engineering, PMM, Data, Success. These attendees might be consuming or using the insights, or helping out with some inputs or customers to take part.
What should your research plan cover
➡️ Here’s a Notion template of the research plan for you to copy & use ⬅️
These are the essential elements of a good research plan. You could always add more or fewer sections depending on what your organisation needs. The key is to use it as this collaborative document and the single source of truth. I often send it to stakeholders either partially filled out with what I know about the project, or a template ahead so that they know these are the sections we want to cover in our kick-off.
Tip: Keep this plan to a maximum of two pages for readability. I also avoid analysis paralysis. It's simply a plan and outlines everything to keep everyone clear and accountable.
1. Context and background
This section is the place to gather existing documents, understand what the business is trying to do overall
What you already know, and what the team is assuming
What the organisation as a whole is trying to achieve with the feature/product/area - business goals and objectives
Links to relevant documents to pre-read
By having this clear and understood, as a researcher, you can suggest the right approach. Referencing the context and background will give you a sense are these real hypotheses the team needs answers to or do they already know all of this.
An example of a hypothesis could look like this.
People want to use messaging for all kinds of situations to communicate to others, there’s no situation where messaging isn’t useful.
3. Participants and demographics
It should tie in again with your goals outlined in the context and background. Usually, the development team has an ideal customer in mind, and if they don’t then think about the customers that your organisation as a whole is focusing on.
Another way to look at this is users and non-users.
For one particular project, I included participants who had used a feature, those who tried it and stopped using it, and those who would benefit from the feature and didn’t try it.
Choose an appropriate method or methods which matches the project objective and timeline. You might need to use different methods for the different hypotheses or goals.
Use this section to make it clear for stakeholder expectations.
What is the actual deadline, and where there is flexibility
What needs to be done and when
Who needs to do what and when
Tip: Allow time for recruiting, especially in a B2B organisation this one can take a while.
List out all your stakeholders to ensure there are those that are involved in kicking this off and are aware of the efforts and will wait and those who simply need to be informed.
What would you do first after a kick-off meeting?
Recruitment for participants OR Writing an interview script (if it’s interviewing) (Click to vote)
Time well invested
Spend the time upfront shaping this and making sure everyone is on the same page. There’s nothing worse than spending a good chunk of time on a project only for it to miss the mark completely.
Revisiting the plan - not everything is set in stone
It should be readily available to all stakeholders and easy to reference throughout the whole project.