You’ve designed an elegant project. You’ve recruited the right participants. You’ve run great sessions. Your analysis has been thorough and revealing. But if you don’t succeed in turning your research into action, then you’ve probably been wasting your time.
It’s common to associate the end of a research project with some kind of debrief session or report, where the person who did the research tells everyone else what the answer is. Actually, that’s the wrong way to think of it, because it’s only part of the picture.
As we noted in Chapter 2, you need your wider team and stakeholders to feel ownership of the research if it’s going to be successful. You can achieve that in a number of ways:
There are a number of ways you can involve your colleagues and stakeholders throughout the project. This isn’t a complete list – use it as a starting point to add your own ideas to.
It might sound obvious, but one of the best ways to get your colleagues thinking about the research is to persuade them to attend some of the interview sessions. Hearing about users’ needs directly is much more powerful than having a researcher relay them second hand: it establishes a personal connection with customers that can have a lasting effect. The more actively involved in the sessions your observers are, the more powerfully involved they’ll feel, so try to get them to take notes, contribute on Post-Its, or participate in a follow-up workshop discussion (see Chapter 6). We find that if stakeholders attend the first couple of sessions they’ll often want to stay for more. One note of caution: stakeholders who only attend one or two sessions can sometimes over-generalize from what they’ve seen, so make sure they’re aware of the full range of interviews.
Show and tells are a great way to build interest and engagement with your research project, before the final results are ready. Firstly, the rough-and-ready format makes it clear that the results are provisional, not the final word. Secondly, it’s a flexible approach that allows you to focus on the topics your audience are interested in. Finally, it brings your audience closer to the project by showing them the actual material that’s been generated, without the need for lots of preparation on your part. If you’ve got a project space set up, you may find that show and tells happen naturally. If not, you may want to invite a broad audience to a separate session, part way through the project. The actual show and tell should be short – anywhere between five and 20 minutes – but allow plenty of time for questions and open discussion afterwards.
Here’s an approach you can use:
Show and tells are also known as pizza sessions, for the obvious reason that it helps to entice people along if there’s free food on offer. Of course, lunchtime pizza may not be the most tempting or appropriate reward for your audience, so try experimenting with different times and treats.
Once your research sessions have begun, it’s a good idea to share a regular update of your findings. It’s best to keep this rough, and not go into too much detail, because you don’t want to waste time or suggest that these are definitive answers. An ideal format is a page or so of bullet points, with a message at the beginning making it clear that these are early findings and there’s more to come.
Even if most of your audience attended the research sessions, it’s still a good idea to create topline findings. It reduces the risk that your attendees will pass on a version of events that you disagree with, and it helps to keep everyone on the same page, by summarising the current state of your rolling hypotheses.
Some people like to summarize topline findings at the end of a day, either off the top of their head or in collaboration with the other observers. Alternatively, you can ask an observer to capture and iterate findings through the day, in a rough format such as Markdown, or as a Trello board. Doing it in this way makes it easier to share, however you may need to tidy it up somewhat before it will make sense to other people.
Taking the idea of topline reporting a step further, it’s worth considering a project blog, website or intranet page.
Creating a resource like this takes time, but it’s a good way to give the project an ongoing presence (especially if your audience works across multiple locations), and minimize the amount of in-person communicating you need to do. In terms of content, we’d recommend including:
Even when you’ve successfully engaged your audience throughout the project, it’s likely that you’ll still want to create some sort of documentation. By doing so, you’re helping to ensure that your work lives on in the organization, because your findings will probably be relevant to future projects, too. This isn’t an alternative to the communication you do through your engagement plan: they’re complementary.
When you document research, there are three elements you need to be aware of:
Ideally, you should decide how you’re going to document your research early in the project, because it will have a bearing on the way you set up and conduct the sessions. There are many different formats open to you, each with their own strengths and weaknesses, so bear these factors in mind:
Once you’ve considered these questions, you’re ready to choose a format for your documentation. You don’t just have to choose just one of these formats. They’re actually more effective if you combine them, because the strengths of one cancel out the weaknesses of the other.
What it is | Timing | Insight vs evidence vs ideas | Effort | ||
---|---|---|---|---|---|
Show and tell (aka pizza session) | Informal runthrough of the research so far, with Q&A | Midway through the project, or at the end of a sprint | High insight, medium evidence | Low | |
Topline findings | One page bulleted summary of findings so far | After first round of research sessions | Medium insight | Low | |
Project blog / website | Online resource capturing project background, progress and findings | Throughout the project | Medium insight, medium evidence | High | |
Report deck | Slide deck summarising the findings, detailed feedback and recommendations | At the end of the project | High insight, medium evidence, low ideas | High | |
List reporting | Cataloguing and feeding back on research. Takes place in the project space | After each sprint | High insight, medium evidence, medium ideas | Medium | |
Journey map | Graphical representation of the sequence of steps taken by users to complete a task | At the end of the project | High insight | Medium | |
Experience map | Large-scale representation of the entire customer experience | At the end of the project | High insight | Very high | |
Personas | Personification of a set of user needs and behaviours | At the end of the project | High insight | Medium-high | |
Showreel | Compilation of video highlights, taken from research recordings | At the end of the project | High evidence, medium insight | High | |
Debrief workshop | Presentation of findings and workshop activities to determine actions | At the end of the project | High insight, high evidence, high ideas | High |
The classic format for documenting research projects is a slide deck. They’re popular because it allows you to combine images and text easily, and they’re also easy to present in a debrief session. They’re a flexible format that can showcase insights, evidence and ideas equally well. The downside is that they take time to create, which could perhaps be better-spent on other tasks, and they run a risk of sitting unnoticed and unread once the team have moved on to the next project. If you’re working in an agile environment, you probably don’t have time for this.
Your deck will need several sections:
You may want to produce different versions of the report for different purposes. For example:
A blank report template is available at https://www.cxpartners.co.uk/ux-resources/, along with many other free deliverable formats.
In contrast to report decks, list reporting dispenses with the frills and gets straight to work listing the problems and recommendations. The upside is that the output is action-focused. The downside is that it’s not so persuasive or engaging, so don’t use this approach unless your team has already bought into the project and its findings.
To produce a list report, follow these steps:
Alongside this form of documentation, it’s helpful to maintain a project area with photos, example screengrabs and sketches (see Chapter 8), and to use regular show and tells as your method of sharing back with the team.
Journey maps show the steps taken by a user to complete a specific task. They represent a sequence of steps or touchpoints, which might involve multiple devices or channels, and might take place over a few minutes or several days. Journey maps are an excellent way to record users goals and expectations, and the problems that they encounter in completing them. On the downside, they can become overly-complex if the exact sequence of steps needs to be recorded.
To create a journey map, follow these steps:
An experience map is like a journey map on a grander scale. Instead of focusing on a specific journey, it takes in the entire customer experience for a particular product or service. Think of it as a planning tool rather than a design tool, enabling your team to identify where changes are needed rather than how to implement them.
Because they’re high-level, holistic documents, experience maps have a long shelf life. They’re often printed out on a wall-size piece of paper, and put in a prominent place. They’re a great reference point for potential projects, because they can be related back to the most pressing customer needs within the overall experience, and used to track progress.
The downside of experience maps is that they’re large, unwieldy and difficult to scan. They also don’t give much direction on how to solve a problem, so you’ll probably need to conduct further research to understand it better before you’re ready to implement a solution. Compared with some of the other methods described in this chapter, experience maps are a pro-level skill, and you should expect to put in a lot of time and effort to create them.
To create an experience map, follow these steps:
A persona is an abstracted set of user needs, normally presented in the form of an imaginary person.
Personas can be a great way to build empathy, especially if your team live very different lives from your users. They’re also a powerful tool for making decisions, because in the process of creating them you deal with a lot of the difficult discussions about prioritizing one set of user needs above another. That’s helpful later on, because you may not have time for further research, and you don’t want to keep derailing your product development process with repetitive arguments about priorities.
Personas have several downsides, too:
The trick to producing effective personas is in their creation. If the people who are going to be using them aren’t involved in generating them, they’ll flop. But if they are involved, personas can be really effective. Here’s how to create them:
Personas discriminate. In fact, they’re a tool for making difficult prioritization decisions. They deliberately don’t cover everybody. The point of the exercise is the prioritization and debate. By getting it out of the way early, you can avoid continually revisiting arguments about who takes priority. That means your team can make better decisions, move faster and have fewer arguments along the way. You should make sure you update personas when you do additional research, too.
Showreels are compilations of video clips. They’re great for providing your audience with direct exposure to your users, and it highlights their experiences like no other format can. The downside is that they’re time-consuming to produce. Also, on their own they can give a skewed view of the findings, so they’re best used alongside another form of documentation like a report, experience map or personas.
Although showreels are the most common format for sharing the evidence directly, there are others. For instance, you might choose to create a scrapbook or website of photographs.
How to make a showreel:
It’s worth mentioning that this is a very short summary of these deliverables: there’s a lot more information out there in books and blogs on each one, so keep exploring if you want to know more.
In most research projects, you’ll want to mark the end of the cycle with a face-to-face debrief session. There are a number of benefits to doing this:
If you created a project area, then that’s the best place to hold the session. Allow at least an hour, to enable you to cover a mix of activities. For a larger scale discovery project, you might need as many as three hours for a workshop. The first part of the session is a playback of findings: this could be a show and tell, or a more formal presentation. The second part of the session is about agreeing actions.
Firstly, present back the findings. If everyone in the room was present throughout the project, and took part in the analysis, then this could be very brief: just a quick recap to confirm you’re all agreed on the same interpretation. Usually, though, you’ll need to spend the first part of the session playing back the findings to the team. To do this, use a combination of the pyramid story you generated during the analysis process (see Chapter 8,), documentation such as a report deck or experience map, and any additional pieces of evidence like photos or videos.
Tailor your presentation to your audience. It’s normal to encounter a lack of knowledge, as well as resistance and blinkered expectations when you feed back, so you need to think of the best way to counteract this. As you can see from the diagram below, you can deploy the different elements of your research project to increase buy-in. Encourage questions and discussion through the presentation too.
The whole purpose of your project is to generate action. As we’ve mentioned already, the best way to do this is by continually engaging and making the research relevant to your stakeholders. Now, though, you can use collaborative activities to shape and assign actions. There are many techniques on offer, but these are some of the most useful:
Complete a different empathy map for each set of users. Ask your audience to work in groups to a worksheet like the one below, reflecting what they’ve seen and heard about user needs.
Create a 2x2 framework like the one below. One axis should be labelled ‘effort’, while the other should be called ‘impact’. Map possible solutions onto the framework. When you’ve finished, focus your efforts on the solutions that are in the low effort / high impact quadrant.
If you’re already managing a backlog of product changes, you can add the actions from the research onto your existing list. If you’re starting from scratch, then work as a group to create recommendations in a list report (see above).
This is a particularly good activity if you’ve created an experience map. Looking at the experience map, identify user problems you could address with new initiatives and add them as Post-It notes in a different color. Or if you’ve got an existing roadmap, add the activities to the experience map to double-check you’re targeting relevant areas.
Ask each participant to complete Post-It notes capturing recommendations for action during your presentation, or generate them in small groups afterwards. Group these together on a wall to remove duplicates, then get the whole team to vote with sticky dots on the ones that should be top priority.