🗓 01 May 2020
Research with real-time synthesis
A method for collaborative remote research
This is a research technique I developed when I led a new product development - “R&D” - team. It was designed and iterated on over three years as a response to my frustrations with the then status quo for research, namely the amount of time we were wasting:
- Physically moving to a new space
- Dealing with poor quality conference phones
- Deciphering badly written sticky notes
- De-duping sticky notes
- Recording conflicting interpretations of what was said
- Unnecessarily long periods of synthesis
- Writing up digital copies for dissemination
Implementing this method required some effort and adaptation from the team, but proved to be disproportionally beneficial for the gains in efficiency, speed and shared understanding.
As the majority of our users, customers and research participants were located in different parts of the world – and in-person visits were prohibitively expensive – this method also has the additional benefit of being friendly to remote and distributed teams.
Before describing the method I want to give some context, but you’re welcome to skip ahead.
The genesis of this method starts with a user of a SaaS product we’d developed. One day we got a message through Intercom from this user describing an issue they were having.
While we chatted to this user through the chat window, they suggested a screen-share. The team tentatively put their headphones on and clicked the link and there this user sat, webcam on, screen shared, walking us through their issue.
As the team tried to diagnose and fix the issue in real-time, they shared notes in a private Slack chat. That’s when the thought occurred to me that we could use this method for collaborative research.
As a general rule, teams only tend to change their working practices in the face of an apparent problem. I suspect I wouldn’t have developed this method and the wouldn’t have adopted adopted it without it being a solution to the problems we already faced as a time-poor, Lean team.
You’re more likely to be able to adopt this method if your team recognises the bullet list at the beginning of this post as real problems that need to be solved.
Research means gathering information
A lot of the time when designers talk about talking to customers, they’re talking about usability testing - can you use what we’ve just imagined or created? More recently, as the UX role morphed into digital product design that turned into hypothesis testing - are we focussing on the right problems?
Since this method is generic to these scenarios, and more, the definition of research should be too. I felt “learning”, while a reasonable definition, implied the existence of an answer out there to be found - most of the time we as teams define the answer.
This is a research method that’s suitable for any scenario where gathering information is the goal.
Gather information from multiple sources
When we think about teams carrying out research we most readily think about the users who use our products. But when we’re gathering information the aim should be to avoid limiting your sources of information.
We can still talk to users of course, but we should also consider how to layer on top information from domain experts, customers (customers ≠ users), non-customers (especially those who have never heard of you) and – this is an important one – other people and teams in your organisation.
This is a research method that’s suitable for gathering information from multiple human sources.
Gather information from different resolutions
As a project progresses, so clarity of the problem increases. Over time you move from having a broad understanding of the area, to a deep understanding of a very specific problem. Resolution simply means the depth at which you are gathering information.
This is a research method that’s not just agnostic to who you’re talking to, but it’s also agnostic to resolution.
Method
Pre-requisites
- A team that understands the value of participating in research
- Your research plan, written up in Google Docs and shared with the team for review ahead of the call
- A blank Google Doc ready for your team’s notes, sent around prior to the call.
- Video conferencing software for somewhere to meet virtually - choose one that allows voice, webcam and screen-sharing.
- A good mic/headphone for clarity of conversation
Running the research call
Get notified of new posts
© Jonathan Roberts 2020
I occasionally update articles to fix typos, improve readability or modify content when new information is available to me: view revisions for this article