Make user research reports modular, not monolithic

Most user research reports are monolithic. What does this mean?

• They combine multiple pieces of information into a single ‘blob’ – often a document like a slide presentation or an email
• The information itself is framed in the context of a particular project: ‘In this project we discovered X, Y and Z’

This doesn’t present too many problems when you create these reports. After all, your primary objective at that point in time is to communicate your research findings to your team, or to a client.

It causes massive problems later.

So, what happens with monolithic reports?

1 Search

Search across multiple reports becomes almost impossible. Sure, on platforms like Google Drive and OneDrive, Confluence, or on your computer, you can theoretically search the contents of multiple documents. But the experience is terrible.

Even finding answers to simple questions like “what do we know about X?” becomes incredibly time-consuming.

With monolithic research reports, the only practical search tool is the human brain. I’m sure you’ve asked someone on the team

So much for the search box!

And what happens when that team member a) forgets or b) leaves the organization?

2 Re-slicing

Re-slicing or combining content in different ways is equally time consuming. If you have a series of research reports about pets, and someone asks you for all of the content about dogs, you have to open up each report in turn, extract the dog information, and combine it into a new report.

3 Pattern spotting

Pattern spotting again relies on the human brain to make connections between reports. In a successful research/design/product team this folk knowledge can be hugely powerful, but it’s also highly fragile.

Modular insight systems

So what’s different in a modular report? And what makes for a good modular insight system?

• In a modular system, each insight or research finding is stored as a discrete object. This might mean it exists in a distinct document, or is stored in a repository like Qualdesk Insights, where each of these objects has its own URL as well as associated metadata
• These findings can be grouped into containers, but not in a strictly hierarchical way. This means that an insight might exist in multiple containers at the same time. So, your insight about dogs might exist in the ‘pets’ container and the ‘dogs’ container. This can be achieved through tagging or by using a system that supports this kind of one-to-many relationship.
• Each object can be tagged and/or categorized individually, to make answering those “what do we know about X?” questions even easier to answer

Those problems with search, re-slicing and pattern spotting described above can be significantly reduced if you store research findings in a modular way.

You also get some additional benefits:

• Insight-level analytics become possible, both on the content and consumption side. Want to know how many insights you have about dogs? Or how many people looked at those insights? With a modular system, you can collect and use this sort of data.
• Insights that don’t ‘fit’ in your current project have a much greater chance of being stored and used. For example, if you’re doing a project about cats, and you find out something about dogs, having a modular system makes it easy to capture those findings. If, on the other hand, you’re busy writing your cat PowerPoint deck, you have to make extra effort to store and communicate the one or two things you discovered about dogs.

At Qualdesk, we strongly encourage our users to adopt this approach, and the Qualdesk Insights platform is designed and built to support it. And with clear benefits over the monolithic approach — why wouldn’t you?