Tips and tricks for making effective research docs
Writing a research report can make or break your project, and often researchers struggle with making these documents. Following are some hacks for researchers just starting out in their careers for making effective research reports that make sense and get stakeholders excited.
Mapping data always comes in handy
Learning how to present the info you have gathered in your research beyond affinity diagramming is important. There is thematic analysis and qualitative coding, but that is not enough while documenting as they are methods to analyse and not present. Making various kinds of information maps from your gathered data can really make large amounts of information available in a single diagram and make it digestible and makes a great impression at executive meetings. It can also be referred by everyone easily at a later stage.
There is this book called Mapping Experiences by O’Reilly. It is a really good resource on learning how to map the info you have gathered in your research with journey maps, service blueprints and beyond. I suggest everyone struggling with synthesis to go through that book. It personally was quite helpful to me in my college and early career days.
You can also find some references of various kinds of journey maps here which you can adapt to your data. Alternatively, you can make your own data visualisation as well like it is explained here. See if you can go through Dear Data project and their weekly postcards, it seems really good way to learn how to visualise any kind of data. WaitButWhy also has some very interesting graphics to visualise qualitative information if you are looking for inspiration, although they may not follow the conventional aesthetical norms but they making quite relevant diagrams.
Apart from the above mentioned resources, you can also deep dive into Figma and Miro communities where a lot of research and design templates and toolkits are there. You can find map templates, presentation templates, analysis tools and what not. However, this activity requires a good amount of time so make sure you include that when planning your project.
Findings are not insights
When you are young, it is easy to get confused between findings and insights. According to the Cambridge Dictionary, a finding is “a piece of information that is discovered during an official examination of a problem, situation, or object”. A finding can be articulated by the user herself or observed by the researcher. It is a piece of factual information.
An insight is by the same dictionary defined as “a clear, deep, and sometimes sudden understanding of a complicated problem or situation”. An insight captures unarticulated truths and applies knowledge to facts. It is actionable and transformational.
When working in a low maturity org, it might be important to highlight the difference in your communication with the stakeholders. An article that has helped me a lot in this battle is this one. Insights usually come after synthesising the collected information. If you struggle with synthesis, you can find info on how to synthesise here.
I have often shared it with my stakeholders when they question on why the document doesn’t just has a list of things users said. Understanding the difference yourself and helping your counterparts too is important for researchers to learn not just as an analytical skill but also as a communication skill.
Communicating an insight
It is really important to work on your writing skills as that is instrumental in communicating your research insights to your audience. How you write an insights makes a huge difference to how your work is viewed by your stakeholders.
I prefer to follow the pyramid structure where I write the key insight first, then detail it out in the next paragraph, add some supporting data below and finish it off with some user quotes. If you can add video snippets and/or photographs from interviews (if they are contextual inquiry sessions) then all the better. However, not many documenting softwares support videos so that can be a hurdle.
Adobe Indesign has an Interactive PDF option that supports videos so you can explore that for your documentation, however Figma is a great alternative too because you can present it in Figma itself but the PDF doesn’t support videos. Powerpoint is also used by many and supports multimedia slides but its visual design capabilities might seem a bit limited.
Kinds of documentation and their dis/advantages
There are various kinds of documentation that exists. And they all have their advantages and otherwise. When you are working in a small team, and just starting out in your career, a question answer format kinda doc might seem a good strategy with an option for everyone to comment and build the document.
This might be disadvantageous for a more mature team/org where refined analytical understanding is required. While the length of the doc and depth of the info to be mentioned depends on the team you are working with, it is usually a good strategy to make an ‘Insights Forward’ document where you present the insights supported by findings and user anecdotes.
Structuring the report
Making a report is all about building a narrative. And that narrative depends upon carefully selecting the structure of your report. Although there are many ways to structure a report, one of most effective way is:
- Executive Summary
- Background (essential for context setting, although can be clubbed with the brief also)
- Research Brief and Objective
- Research Methodology (include a link to the research plan)
- Key Insights (can include data viz, journey maps, personas, analytical matrix etc.)
- Recommendations (along with wireframes if time permits)
- Prioritisation of features suggested (along with a framework, if applicable)
- Suggested next steps (if applicable)
- Appendix (optional): Includes your interview session recordings, participant details, link to transcripts, analytical notes and codes, bibliography etc.
Note: For a usability report, the feedback feature matrix can be before the key insights section.
While the level of detail depends on the amount of time you have, making a document with above mentioned structure should be feasible for all timelines and kind of projects. This is an excellent article on how to formulate your report. I strongly recommend you go through it.
Be objective in your reporting
This is the most important tip that I can give you: Your tone matters.
“The elements of your story should should work together in service of a larger narrative — one that is encapsulated in a mission statement or a product strategy. No matter the kind of story we tell with user research data, it should allude (or speak directly to) these larger narratives”, says Ben Weidmayer of User Interviews.
Sometimes we have insights that contradict our understanding and point of view, it could also be contradicting the opinions you have shared with your colleagues, or your stakeholder’s ideas. Try to be empathetic while presenting but it is really important to be completely objective, without leaning to any side. That’s where the communication and negotiation skills come in handy.
It also important to be aware of our biases while formulating the report. Building a narrative is important but if you present your insights in a leading narrative then you are simply making your org devoid of some of the opportunities that could have been found and maybe made a fortune.
Speak the language of your stakeholder(s)
In my experience, there is no universal shoe that fits all. Similarly, there is no one format of report that works for all projects and stakeholders. You need to understand what is your stakeholder’s mental model and accordingly what kind of report might work for them.
Also, it is a good practice to start learning your stakeholder’s languages quite early in your career, because it will be quite useful in your negotiations. Depending on whom you are talking to, your argument adapts. For example, if talking to a product manager, you need to talk about the metrics and KPIs that concerns them like acquisition, retention, revenue, cost of success/failure, engagement, ARR and other frameworks etc. When speaking to designers, you can talk about UX heuristics, laws and principles of design, customer delight, design patterns, etc. Talk about the ROI of your work. And so on and so forth.
Your stakeholders don’t care about research, they care about how can that research help them achieve their goals. Your job as a researcher is precisely to do that. Remember, research is not an end in itself, it is a means to an end.
Talk to your stakeholders before starting your research and understand what are their goals from the project (not just from your research but their quarterly goals too), what are they struggling with and what do they hope to do with the insights. When presenting to different stakeholders at different meetings, tailor your presentation according to your target audience. If you make an effort to understand them, they will definitely respect that and trust your work.
