Documenting research and design work
In 2021 I worked on creating a template to document my research and design documentation more efficiently and to make my process and communication around design and product decisions more transparent and efficient.
How I use the template document
It’s the starting point for all my research and design work. The aim is to have every relevant bit of information centralised in one place from initial context gathering and research insights, all the way to design decisions, feedback on higher fidelity designs and team feedback.
Here’s the structure I’m currently using for this document.
I. Background and problem space
In this section, I share as much context as possible about the problem I’m trying to solve, from previous research insights to user feedback and customer support reports. Everything is valuable at this stage.
Here are some of the questions I want to answer in that section:
What is the problem I’m trying to solve?
How was the problem identified and by whom?
How does the problem impact our users?
How does the problem impact the business?
II. Scope of work
Defining the scope of work early on helps me prioritise and focus on what’s going to bring the most value to our users. It also helps me figure out what’s a nice to have but isn’t detrimental to users and their experience if we don’t tackle it just now. Of course, the scope of work can radically change once I start learning from users and testing solutions with them so I’m keeping an open mind knowing that the focus could change.
I want to answer the following questions:
What problem am I focusing on solving?
What am I not solving now and why? (Think about edge cases here)
III. Research
It’s the section for all the insights I’m going to be gathering from users, interviewing and testing prototypes with them. While the “Background and problem space” section focuses on context gathering and establishing a foundation for the work, the research section is used to define our learning goals and how we’ll get there and to document new learnings.
I want to answer the following questions:
What do I already know about the problem? (Analytics, customer requests or quotes, previous research insights…)
What do I want to find out? (Our learning goals)
What are my assumptions about the problem and user behaviours?
How do I plan to learn more about this problem? (Detailed research plan)
What did I learn? (Share the most important insights)
As you can see from the above structure, that section is a constant work in progress for the duration of the user research phase and a great way for teammates to understand how I approach the problem to solve.
IV. Ideation
I feel confident that I have gathered enough insights from users and I feel ready to articulate rough ideas on the direction I’m taking and how the design solution could work.
At this stage, I like sharing things like:
User flows
Journey mapping
Rough sketches, wireframes and prototypes
V. Alternatives considered
What other ideas have been discussed and why aren’t we pursuing them? Documenting alternative ideas comes in handy in future conversations about product decisions and how they were made. It doesn’t have to be very detailed and can be more visual than written.
VI. The solution
I include links to Figma files and a written rationale for my solution, including:
How this solution solves the problem
Its key functionalities and interaction
Introduction of new design patterns — if applicable
How this solution fits with our product
💡Tip: I use video recordings to communicate ideas and design solutions to my team and find it an efficient format for share information async.
Some things to consider when sharing design solutions:
Does the solution meet accessibility criteria?
Are there any edge cases I should be aware of?
Is the solution scalable and does it allow for future iterations?
VII. Design feedback
I used this section to collect feedback from the team and decisions that we make on how I use this feedback.
Conclusion
With this document, I have greatly increased collaboration and communication with my team. It’s been a great way to show how I approach product challenge and to show the various steps it took to get to the end solution. It has enriched conversations with product managers, engineers and design peers.