User research graveyards

24 September 2019
Peter ParkesPeter Parkes

User research graveyards

In the worlds of business, government and the third sector, I’m convinced that almost all qualitative research and insight ends up in graveyards.

How does it get there? And what does a graveyard look like?

Let’s start with the research outputs or writeups. These might be captured in a variety of different ways:

  • A debrief email written at the end of a research session such as a focus group
  • A slide presentation put together to communicate the results of a project
  • A long-form text writeup of a body of research work

If you work in user research or another qualitative research field, you’ve almost certainly come across all of these in various different situations. You might have preferences for one over the other, but none of them seem intrinsically bad at face value.

But they are.

Why are these formats graveyards?

Using emails, slide presentations and text documents to communicate and store qualitative insight is a terrible idea.

Even if you do manage to salvage that email from the archive or dredge up the slide deck from the shared folder, you’ve only solved a fraction of the problem.

Why?

Let’s consider what you might want to do with research data or insights:

  1. Search either for something specific or for a broader category of information – e.g. ‘show me all the information we have about our onboarding process for enterprise customers’
  2. Put together a new report from existing data (we call this re-slicing) – e.g. having done a lot of research about pets in general, you want to put together a new report specifically about dogs
  3. Spot patterns in data – e.g. highlighting emergent themes or trends

All of these tasks are made challenging with emails, decks and documents for two reasons:

A Emails, decks and documents are monolithic, not modular

They consist of large ‘blobs’ of unstructured information, usually are organised hierarchically and extracting specific pieces of information requires searching within a document and copy/pasting into a new one.

Let’s look at the tasks in more detail:

Monolithic Modular
Search Limited to text search within one document at a time Text search across all available data plus metadata filters
Re-slicing Manual and requires re-writing Easy
Spotting patterns Manual Can be automated

B Emails, decks and documents are static, not connected to live data

If you discover some new evidence to back up an insight, you have to go around and update every deck with that insight in, and resend all of the summary emails. Of course, none of this happens in reality and so insights in graveyards become stale and ultimately useless.

What’s the solution?

Any solution to the problem of research graveyards, then, needs to store modular data and make it update-able and accessible in realtime.

This leads us away from two categories of general purpose business software:

  • Document storage platforms like Dropbox, Google Drive, OneDrive, and so on (these store monolithic data)
  • Communication platforms like email, Slack, Teams and so on (these generate static, disconnected objects that can’t be edited later)

and towards things that look more like databases.

Many people we’ve spoken to in our own research are using tools in this space – tools that allow you to store modular data and maintain a live, always-up-to-date repository of knowledge:

  • Spreadsheets like Airtable, Google Sheets and Excel
  • Wikis and wiki-like platforms such as Confluence, SharePoint and Notion

These are a radically better solution than decks and emails, but I argue that they don’t go far enough. Yes, they’re good storage solutions, but they’re terrible sharing solutions.

Why do people use decks and emails in the first place? It’s because they’re great sharing tools – you can build a narrative around some research findings and communicate them to your colleagues much more easily in a bullet-pointed email or a PowerPoint deck than you can by sending them a link to a spreadsheet with some filters applied.

In my previous post about insight repositories, I argue that there’s a strong case for building a dedicated solution. One that’s as good at storing information as a spreadsheet, and at the same time as good a communication tool as email, Slack or slide decks.

Without a solution like that in place, there’s a risk that maintaining both the storage solution and the sharing solution becomes too much of an effort, and that behaviour tilts back towards sending research to the graveyard.