Storytelling in User Research

Listen to the stories told by your organisation then tell the story of your research.

Introduction

People make sense of the world by telling stories. During a project we start by talking to each other. We talk to our users then we we report back to clients and stakeholders. Sometimes we talk to developers too, to help them build something useful and usable. When we finish a project we hope our work will live on in the organisation who hired us. We hope it goes on telling stories after we leave.

It’s easy to find templates for communicating research: personas, user flows and service blueprints. In this essay I’ll explain my approach to finding stories and retelling them to other people.

Start by listening

When I start a new project, I begin by researching my own team: I meet everyone I can for a half-hour overview of what they do and get them to suggest people outside the team I should talk to.

Colleagues can provide me with research questions, help me find existing research, and recommend who else I should talk to.

Like a detective story by Raymond Chandler, I make my way through a cast of people to get to the truth.

Research questions

When I first meet people, I collect their questions. Anything a team member is interested in is a valid question. I’ll try to answer them during the the time I have. If there’s a product owner or a least a senior decision maker involved, I’ll check in with them for the main question which needs to be answered. I’ll write this up a a ‘problem statement’. Asking someone what they want to know empowers them and gives them a stake in the research.

Finding existing research

I often find my clients don’t always make good use of the research they already have. I’m surprised at how valuable insights get buried in an organisation, sometimes by people working in silos. If a team doesn’t have a dedicated researcher and they buy in research from third parties, the findings may be forgotten about.

Make friends with marketers, data scientists and customer insight professionals in the organisation. A few of them I’ve known have to work hard to keep colleagues interested in their reports. They can be surprised and flattered if you show an interest.

Some stories get buried over time. See if you can dig any up.

Mobilising a team

Ideally your team has the time and motivation to help you write the research questions, shape the research and view the outputs. I’ll often end up with a core team of people who I work with then a wider network of people who help me or are interested in what I’m doing.

Doing contract research work, it’s rare to find people who have been freed to work with me in advance: I often have to persuade people to give up their time and fit the project in with their schedule. Getting time with executives can be particularly challenging.

My advice is: show an interest in the people you work with and focus 100% on their problems and ideas, and their aspirations for the product. One way to do this is just to remember what they’ve told you and the way they phrased it.

When I finish talking to one person I ask them who else I should speak to. Everyone has a story to tell and usually has a source of knowledge to share. If I’m working on delivering a product or a service I try to make friends with the data science team, marketing and possibly customer insight or someone who works in a contact center.

If I’m not allowed to talk to someone that tells me something about the office politics of the organisation, or its values, or the competing priorities or rivalries the organisation has.

Resist the urge to make heroes or villians out of everyone. People are complex.

Remote working games

I’m writing this during the COVID-19 lockdown of summer 2020 and it’s not that easy for me to working my way around a workplace and get to know the humans. Meeting people lets you get a sense of their personality — how they present themselves, where they sit, the items they keep on their desk.

A lot of the time you’re dealing with voices on a dial-in meeting. It’s the same if you’re working remotely with people in other countries. I’d suggest making a list of people and their role as well as their stake in the project.

Some teams play online games on Fridays, so try to get in on these.

Occasionally I run a quiz where I get people to share photos of items in their home. We run a session where everyone gets to ask a yes/no question of everyone else, like: ‘Are you a musician?’. If there’s a photo of a guitar, you know it might belong to anyone person who said yes.

This way, you can let your team tell you their personal stories.

Taking notes

As I tour the workplace I start telling my own stories. I tend to retell what I’ve been told before: the next person may agree, have more to add, or disagree. At the same time I’ll try to identify areas of controversy. I also try to understand the boundaries of the team and find out what I’m allowed to share with people outside it.

This process works for me because I’m curious about people and enjoy meeting new ones. Humour, passion and ‘soundbites’ make their stories memorable. If they tell me something particularly interesting, I might give it a call-out box in my notepad or an emoticon-style doodle. It’s easy to annotate quotes with a smile, a crying face or an angry face.

Every time I get an overview I take a sketch note. I then go back over these and highlight the pictures. It helps my memory.

As you gain knowledge and start relationship building, some bias will creep in. Our view of reality is coloured by personal preferences, experience and plain old deductive errors in reasoning. Dan Ariely has written a series of very readable books on people’s innate irrationality. Keep thinking critically about what you’re told: try some gentle questions about how they came to their current way of thinking.

At the end of a project, I shred my notes. It’s best practice to hand over polished deliverables and destroy the notes I took along the way: when I meet colleagues I don’t ask them to sign anything, so it’s best not to keep a record of what they told me.

I take all the different impressions of the project and collate them. At the kick-off meeting I usually put together a powerpoint. I’ll use this session to play back the research questions as well as a high-level problem statement.

Playback time

Simon Jones’ medium post ‘Insight Delivery: if your clients don’t already know you’ve done it wrong’ makes the case for continuously engaging with your team during and after the research rather than relying on a final ‘reveal’. He makes a convincing argument for scheduling in team participation from a strong kick-off meeting through analysis meetings and observation workshops. See also the GDS approach captured by Will Myddleton’s excellent Research is a team sport.

When playing back research to people, beware of ‘anchoring’. The first result you share will be the reference point for anything you share after that. If someone breaks down and cries in your first interview that will colour every other playback you make. Perhaps they were just having a bad day? Your colleagues will remember it, though.

It’s therefore important for you to define, early on, who you need to involve in the project and how to engage with them. The main thing is to have a good relationship with decision makers.

You need to control the narrative — as they like to say in politics.

Users are heroes

I like to think we cast our users in the role of the hero. They go from the rags of the old services to the riches of the new one.

Good products and services retell the story we heard when we engaged with our customers. Our users need to recognise the content we offer when they see it. We’re telling them what they already know.

Indi Young’s ‘Mental Models’ (2008) offers my favourite paradigm for this. Her research practice generally involves running a series of interviews (a minimum of four) which encourage people to tell their own stories about how they use products, as well as live their lives. Analysing the transcripts gives you mental models based on their verbatim quotes. If a movie buff says ‘I check reviews before I decide to visit the cinema’ you might use the phrase ‘check reviews’ as a call to action in an app or website.

Telling a story to clients

When telling stories, rely on your personal style.

Some people are great at using engaging visuals. For the majority of people visuals are a shortcut to understanding complex ideas and information

I’m a rubbish visual designer, to be honest. I don’t have much sense of what colours go together. To me Ariel looks like Helvetica. What does it matter anyway?

As English Literature graduate so I rely on compelling quotes than slick visuals. Audio and video recordings tell their own stories as well.

There’s perhaps one rule which is useful no matter what medium suits your style of delivery. Everything you deliver should be ‘telegraphic’ — it can be understood at a glance, or within a couple of pithy phrases.

Beware of huge research write-ups. The only people who will read that particular story are other researchers.

Beware of User Needs

In User-Centered Design the phrase User Needs really describes the sum total of the insights you get from the research. They can take the form of personas, empathy maps, user flows or service blueprints.

A well-meaning gov.uk post also suggests they can and should be written in the same format as User Stories -

As a User Researcher I need to be paid lots of money so that I can focus on doing great work and won’t be tempted to switch careers.

Note how some personal bias has crept into the example above.

I personally don’t think this kind of output is useful, for the following reasons:

1. The As a … I need … so that … format is very repetitive. It’s hard to read and scan a list of User Needs. You’re creating a cognitive burden for your colleagues.
2. The name can easily be confused with User Stories and User Flows — don’t make your colleagues have to think — see Steve Krug.
3. The existence of a list conveys a meaning in itself — they’re guilt-inducing and people don’t always react well to guilt.

User needs tell the wrong stories.

People throughout history have failed to follow Moses’ Ten Commandments even though they came directly from God, the great Product Owner in the sky. Most of us prioritise commandments five and seven. Your product owner is likely to prioritise some User Needs over others too. Which Need will they action and which do they leave alone? If you prioritise the Needs for them, you’re making decisions for them too, which could be overstepping the bounds of the researcher role.

If you insist on using this format I’d recommend adding some kind of priority; grouping the needs by theme; basing them on user quotes from research; and highlighting the key phrase in each one:

As a User Researcher I need to be paid lots of money so that I can do great work without being tempted to switch careers.

Personas

This format has become slightly controversial in the user research field since Alan Cooper introduced them in The Inmates Are Running The Asylum. My advice if you use this format is:

• Base them 100% on quotes from users from research.
• Avoid using pictures, demographics or back story — these create bias.

If you have interviews to draw on, you can combine quotes from different ones to construct a persona.

I personally haven’t found personas to be a very useful way to tell stories as they tend to rely on cliches, from the stock photo pictures to the stereotyped people. I was always amused by the persona of the older user who struggles with computers. ‘Luddite Len needs as much help as possible even though there’s been an internet since 1989.’

Conclusion (and some heuristics)

This has been a quick tour of storytelling in User Research. I hope it was a story that made sense.

On 3 June 2020 I held a Zoom discussion at the monthly UX Glasgow meet-up. Some other authors from this book were present. I challenged the group to come up with advice under the following two topics. I’ve reproduced them here in full as a rough set of ‘heuristics’ — problem-solving suggestions and guidelines.

Updating colleagues on your research

1. Many colleagues don’t know what to expect from UR or what to do, so ‘break them in’ by getting them to help with desk research and note taking. Run sensemaking as a group to take notes from transcripts.
2. Make things hands-on and interactive. This encourages colleagues to ‘do the work’ even if they don’t necessarily realise they’re doing it. Create a collective sense of ownership around the research.
3. Beware of ‘top findings’ — identify any problems you had and give colleagues hypotheses with appropriate caveats.
4. Communicate using clips and powerpoints — audio and video can be particularly powerful. Avoid doorstep-sized reports.
5. Direct quotes are also compelling.
6. Consider a storytelling structure — ‘once upon a time’. Tell the story you want to tell every day and know how to end it.
7. Check how the team wants to proceed.
8. Create research walls or, in lockdown, a virtual Miro space.
9. Take advantage of infographic templates and comic strips. Canva has 1-page infographics built in. Call out interesting statistics about participants — but beware of suggesting the research is quantitative.
10. Miro is a useful tool for collaboration. Team’s can see each other; boards can be the focus for regular stand-ups and they offer some traceability.
11. It’s best to actively involve team members. For example, developers can collaborate on affinity mapping.
12. One participant books entire half-day events to watch research clips and prioritise improvements. He sets up a cabaret-style room for this.
13. Try David Travis’ Red Routes for an approach; also ‘Think like a User Researcher’ at uxresearchbook.com.
14. Always use plain English rather than UX lingo; define what research is.
15. It can be too early to share any research findings.

Making findings permanent

1. One researcher uses MS teams to share findings. A lot depends on the quality of the documents you create.
2. Try to anticipate colleagues’ questions. Describe the kind of research which took place, the tasks, the problems you encountered and the outcomes. Consider a podcast-style output as some people prefer this.
3. One participant favours a repo of research data for when someone joins the team. Try Miro or an internal or external blog. Try to keep things in a standard format to make it easier to digest findings from different projects. There’s a danger of creating a repo of Word documents.
4. Meetings are the most engaging ways of communicating findings. Make sure the whole design team is aware of the research and keep the outputs in one place.
5. Write a report to cover important insights. Your conclusion sums up where the research stands and identifies further resources. Beware of using a format which might not exist in future.
6. Try to educate your team to get into good research habits themselves. Encourage them to do things right.
7. If you leave a project, try a hand-over to someone else but try not to bias it — appreciate a new set of eyes. It’s generally easier handing over quantitative data — qualitative can be mis-interpreted.
8. Be mindful of the audience — why was the research done, what were the objectives and who was it done for?