January 28, 2018
Evidencing Your Work
When conducting research, your work and findings should live on beyond you. If you decide to move on, are busy with a new project, or focusing on another part of the design process all of your findings should be easily accessible.
I’ve had luck in the past building a central repository of research findings tied back to your design files or product planning documentation. I’ll go into my method of filing documents below, but first, let’s review the three core documents that will be part of any research project:
1. Research Plan
2. Raw Notes
3. Insights Document
Research plans help you define what you are going to get out of user research. Having goals, hypotheses, and agendas before walking into a research session will help you be prepared to make the most of your time.
Basics of a Research Plan
Ensure that every research plan contains the following core prices:
Descriptors of this research session
Include which product team or engineering squad is associated with the project. (Include your name, obviously.) Lastly, add the estimated timeframe for research and appropriate field locations if you’re going on site.
Include a brief list of questions you are hoping to solve, processes you are hoping to better understand, or designs you are testing. (With links to the design files or InVision mockups.)
List user research participants or proposed candidates. Use this document and emojis to designate if they have been contacted and or scheduled. It should look something like this:
Have an Agenda for Your Interview
Don’t go blindly into an interview with a user. Pace out your time allotment with the user with the set of questions. If multiple researchers are conducting the interview make sure you denote who is asking each question. (I’d recommend you break the questions into sections run by one of the researchers.)
Break apart the questions into sections that make it easy to segue between:
- Document Overview — 10 minutes (Mary)
Let’s talk first about documents in general.
- What information is most important for you when you first review a contract?
What information is most important for you the day before / day of the event
Here you have the general subject for these questions to help you set the context, the specific questions that we want to be asked, and who will be asking the questions (Mary, in the above section).
When taking notes with a participant or set of participants, there are a few hard and fast rules you should keep in mind.
Meet with your team for 5 minutes before the session to review who is attendance, go over the agenda, and review any background material on this particular research participant.
Record the Session
Make sure you gain permission to record those in the room. Remind them this the recording is for your personal note taking and will not be shared. This is so you can actively focus on the session and not on documenting the process.
If no recording is allowed, or you don’t feel comfortable asking, take “stream of consciousness notes”. Either on paper or using a smartphone app like Apple Notes, Bear, or Evernote. Ask for the notes of all of your team members that were present (even if they weren’t obviously taking notes).
Ensure you get the names of those present, including spelling, pronunciation and contact information. Include both employees working for your team and those we are interviewing. If you are recording, just ask our participants to “Please say your name and spell it.” Get business cards for participants if possible.
Ask to Take Photos
If on-site, ask permission to take photos of the office or workspace. Take photos of computer screens, the environment, processes, and documents.
Send it Now
If you are on site and participants promise to send documents after you leave, ask to have them send it now. Or take photos with your smartphone of their documents. I have gotten stuck in situations where participants forget or decide not to send documents after the fact. If they are concerned with sharing private data, review with management or remind them of previous privacy/non-disclosure agreements already in place between your users and you.
Meet with your team briefly after each participant to triage any immediate tasks that arose. Occasionally, current users and clients will raise support issues to your attention during the research session. Be sure to designate who is handling this issue. Ensure one team member follows up with your participant directly confirming that you have taken the necessary next steps to address their concern.
Use this brief syncing period to collect any additional artifacts and review the next steps. You can also use this as a time to adapt and make small tweaks to your agenda or process.
Review in HQ
Focus on taking notes once back at the office. It’s better to sit down and take notes separately from those employees who were present. Start each note-taking session with a Raw Notes document. After we have completed our research sessions, we’ll make an Insights document that we can share.
Automated Voice Transcription
Use a tool like VoiceBase or Chorus.ai to provide rough, searchable transcripts of these sessions.
Build a Raw Notes document
For each session, make a Raw Notes document inside Google Drive to use. Use this as a scratch pad to take notes as you replay the audio of the meeting back.
Suggested Formatting Conventions
Inside each raw notes document, format the header as:
- Raw Notes — User Name — Date
At/via: Where / how it was conducted (Location or conference or phone call)
Participants: List names and titles
Internal Team Members: Who on our side was present?
Stage: Exploratory, Product Discovery, Product Validation, Design Discovery, Design Validation, After Care
Basics of Insights Docs
When you have finished conducting your research sessions with partners, ops, or clients, it’s time to document and pass on your knowledge. Insights documents are meant to be shared across an organization, so it’s important to be clear, concise, and readable. Lean into our evidence-based principle and links to assets and documents that act as proof.
Each insights doc is broken into a few sections:
1. What is this / Who did you do research with?
Include what project this is for and who the research participant with. Keep this section to 1-2 sentences long.
2. TL;DR(Too Long; Didn’t Read)
Focus on 3 or 4 bullet points to highlight your insights. This acts as the primary area for takeaways and what those reviewing this document in 30 seconds could learn. You must provide evidence to support your decisions. Include links or comments to indicate which sessions act as key evidence for your decisions.
Denote what status of the design (Product Discovery, Product Validation, Design Discovery, Design Validation, After Care/Feedback) has and hasn’t changed. List recommended next steps for this project.
4. Full Summary
Provide condensed, cumulative notes for the research conducted. Use your raw notes document to build a cohesive story around each point in your research plan agenda. Link to evidence when at all possible.
Include quotes from participants, organized into sections based on the research plan agenda. Indicate the person who was quoted, their role/job, and the context of their quote.
Link out to relevant research artifacts. Include links to:
Raw note documents
Additional artifacts and files
Include links relevant JIRA Epic or tickets, engineering plans
Links to any customer support cases in your ticketing system
Now for the fun part! Let’s talk about file naming, folder structures, and naming conventions! ? —Just kidding.
When setting up your user research library, do spend a moment to outline how to name files and folders – even as a team of one. This helps your audience (from product managers, to marketers, to your executive team) to easily find and digest your findings. Highlighting the knowledge gained for the organization will make it easier to integrate user research into all parts of your organization.
Next, read Methodologies