Why Provide Any Deliverable At All?
First, you might question whether your project needs a formal deliverable. Some project teams are tempted to simply translate their research findings into a product’s design without producing any documentation of their research findings. This saves time in the short term, but the danger is that, without some kind of description of the findings, the research knowledge remains in the brain of the researcher. When that person moves on to another project or another employer, you’ll lose that knowledge. I experienced this problem recently when I took over a project from a researcher who had left our company. It was extremely difficult to understand the previous research, because there were only raw notes and no deliverables.
Choosing a Deliverable Format
When choosing the type of deliverable that would best communicate your findings, two important things to consider are:
- Who is the audience?
- How soon do they need the findings?
Who Is the Audience?
Ideally, you should tailor your deliverables to the needs and interests of your audience, but a common difficulty is that you often have to serve a variety of audiences. High-level executives typically want only a brief overview. But the people who have to implement your recommendations—the application’s owner, designers, and developers—need to understand the details. So you may need to create several versions of your deliverables, each with varying amounts of detail. For example, once you’ve created a detailed version, you could strip it down to the essentials to create an executive summary version.
Your audience also determines the formality of your deliverables. If you are presenting findings to a client, your deliverable needs to be more formal than if you were doing research for your own, internal project team.
How Soon Do They Need the Findings?
Obviously, how quickly your audience needs the results of your research determines the detail and formality of your deliverables. For example, if you’re conducting iterative usability testing in the middle of a project, your goal is to quickly evaluate and make changes to the design, then test again. In this situation, you may prepare no deliverable at all and, instead, just have an informal discussion of your findings and the design changes your team needs to make.
On the other hand, if you’re conducting more exploratory user research, you may not have a distinct deadline, so it would make sense to take the time to do detailed analysis and present your results. Unless there is an important deadline you need to meet, it’s always best to give researchers time—within reason—to produce quality results. I’m always dismayed when a client spends a great deal of time and money conducting research, yet wants to rush through to the presentation of findings.
Types of Research Deliverables
There are various types of deliverables—from no deliverable at all to a full report. You should choose the deliverable that best allows you to communicate your findings and recommendations, in the time available, and considers the needs of your audience.
No Deliverable
It’s rare that you can get away with providing no deliverable, but if the right people are involved throughout the research, you can just discuss the findings afterward and make changes to the design, without spending any time creating a deliverable. However, remember that there will be no record of your findings for later use.
Quick Findings
If time is a consideration, the quickest deliverable format is an email message or informal Word document with bullet points describing your overall findings and proposed design changes, as shown in Figure 1.
Another good option is to annotate the designs, pointing to the problem areas and describing your recommended changes, as shown in Figure 2. It’s usually quicker and easier to annotate designs than it is to describe problems only in text. It’s also easier for people to understand problems when seeing them in the context of a design.
When you have to document your findings quickly, you usually won’t have much time to go through your notes. Instead, you must rely on your memory of the main issues that you observed. An effective way to document these is to go through your testing protocol, question-by-question, and write down your overall conclusions about each task or topic. You’ll be surprised how much you can remember from the research off the top of your head. When doing this, you’ll naturally document your overall conclusions based on what you’ve observed rather than the details, which is exactly what you want to document in quick findings.
Detailed Reports
A report gives you the freedom to describe your findings and recommendations comprehensively and in as much detail as needed. However, it’s also easy to become verbose. In the past, I’ve written 100-page heuristic evaluations and usability test reports. But did anyone have time to read them? No wonder people have said that no one reads reports.
Though many people don’t read reports, they are valuable to the people who have to understand the problems and implement the changes. Web site and application owners are responsible for understanding any issues and prioritizing which recommendations to implement. Designers and developers need to understand user needs and the problems they face to design effective solutions for them. Even if each person reads only the parts of your report that apply to the aspects of a design for which they’re responsible, a report serves its purpose.
Reports are also valuable as a detailed archive of your research information. Once a project ends, even those who were involved in the research will gradually forget much of the information. Reports usually contain enough detail and context that someone new can read them later on and understand the findings.??
Lastly, reports have value as proof of the value of the research. If a client has just spent a lot of money and time doing extensive user research, they expect to see some substantial documentation from it. A high-level PowerPoint or a brief summary of findings usually doesn’t cut it. The hearty thwack that comes from slapping down a thick report on a conference room table is impressive, even if no one reads it. To some people, a hefty and detailed report says, “Here’s some impressive, comprehensive research. We got our money’s worth on this one.”
Presentations
The problem with a report is that there’s no way to easily present it. You certainly can’t just read it to your audience, and you usually can’t just tell people to read it themselves. You need to present something. So you have to create two deliverables—the report and the presentation.
As with reports, presentations can provide either a summary or the full details. If you have a detailed report, you can create a summary presentation and tell people to refer to the report if they want the full details. The problem is that many people see only the presentation and won’t read the report, so you often find that you have to convey most of the information in your presentation anyway.
To save time and money and avoid the duplication of effort involved in creating both a detailed report and a presentation, some people skip the report and, instead, create only a detailed presentation. However, it’s difficult to convey voluminous user research findings in the format of a presentation. And it’s unreasonable to expect an audience to stare at dense slides or absorb the kinds of data that are characteristic of robust findings.
When your only deliverable is a presentation, you’ll run into the two competing goals of a presentation: You need to optimize it for effective delivery, but because it’s your only deliverable, it also needs to be understandable on its own by those who view it later, without the explanations you initially give during your presentation.
The extra explanatory text that makes a presentation understandable on its own doesn’t necessarily make a presentation a compelling experience when you deliver it to an audience. One solution is to record an audio track, so those who view your presentation later can hear your explanation of the slides. However, not everyone wants to take the time to sit through such a presentation.
You’ll walk a fine line between providing enough explanatory text and overwhelming your audience with too many bullet points. One solution is to provide an appendix of additional material that you don’t present during a meeting, but that others can read later for more details.
Findings and Recommendations Matrix
Reports and presentations provide a lot of context and examples, so people can understand your findings and recommendations, but once your audience has this initial understanding and a project team simply want to view and discuss your recommendations, all that extra content gets in the way. A findings and recommendations matrix is an additional deliverable that gathers all recommendations together in a simple table format—usually in Word or Excel—with a brief summary of the findings that led to each recommendation and, often, a severity rating for each issue. This matrix provides an easy format that lets a project team review the recommendations, prioritize them, and refer to them throughout the rest of a project.
Other Deliverables
Other ways of describing and visualizing user research findings include scenarios, personas, workflow diagrams—like that shown in Figure 6—task analysis diagrams, customer journey maps, and experience maps. These forms of documentation are often better at conveying the information and bringing your research findings to life. For example, people who might otherwise be turned off by the thought of reading a long report often take the time to look at a deliverable that takes a more novel and visual approach—such as a set of personas.
