The Research Funnel
When I started at Monotype four years ago, I was the only dedicated researcher in the company but research formed part of many people’s jobs. As a way of supporting a culture of customer research and insights, I created a research knowledge base for those people who conducted, commissioned or used research as part of their job. As I wasn’t responsible for doing all the research (and nor could I hope to) it became necessary to have a way of talking about the kinds of projects I could really add value to and which projects people should do under their own steam. I came up with a simple category system that I called The Research Funnel. I wrote about it on my blog and iterated on it over time.
Research should be designed to address a problem — either to solve it or to get closer to a solution. The funnel categories describe research as something that can and should happen at every stage of a product/project lifecycle. They describe how close you are to the problem or solution. At the top of the funnel you are furthest from the problem and at the bottom you are closest to the problem.
It also describes how broad the data collection should be — how wide or deep to go. The funnel isn’t one way and research doesn’t necessarily need to move through the stages in order. For example, insights from the bottom of the funnel can be dripped back into the top or middle of the funnel to inspire creativity, inform strategy or provide direction and tactics.
Much of the day to day research done in the UX industry sits in the tactical and operational research categories and is often handled within product/production teams directly rather than centralised siloed research teams. Tactical and operational research work really well in agile and ‘everything all the time’ workflows and in ongoing product development.
Exploratory and strategic research work well in a ‘discovery phase’ in a waterfall workflow or at the start of a redesign or new project. You often can’t do strategic or exploratory research without data gathered operationally though. Whilst analytics give us a lot of detail, they need charting, tracking and interpreting to be useful. We need to think about what this builds into — how we join the dots into a bigger picture or strategy.
How does this work in practice? If we use the product we built at Mark Boulton Design — Gridset as an example, here are some ideas of how research could be used along the whole lifecycle of the product.
Let’s remind ourselves of the double diamond again.
An exploratory project to shape the problem space might be to research a completely new market or underserved customer group. For example, if we cast our minds back around 7 years, we know that Responsive Web Design was hard and grids and layout were also really hard to do. Back then, we had some ideas about how this might affect different people in different ways — for example, a designer designed a layout and then the front end developer had to work out how to make it work for different screen sizes. As we had some broad areas to investigate and an idea of who to speak to, we could have done an exloratory piece of research perhaps using one of the methods I describe here. At the end of it, we might have come to the realisation that there was an opportunity for us to create a solution.
With the problem space defined, we would need to understand what to build. A strategic project might be to do some research to define the strategy or to define the target users more closely. For example, we might have had a hunch that we could create an app that helps with Grids but needed some personas and scenarios to encapsulate the target users and user needs.
With our roadmap prioritised, we could start to build the thing right. During the design process, you might conduct remote user interviews to get some feedback on your prototypes. This would be an example of a tactical project.
With our MVP shipped, we may have noticed a drop off in the sign up process. An example of an operational project would be some A/B testing on the copy used in the user flow.
The funnel doesn’t just work in a linear way however. It’s highly likely you’ll need to run further tactical usability testing but as you iterate you may need to do further strategic research also. An example of this might be to get some broad feedback of the whole service via a customer satisfaction survey. The outcome might be a set of trackable measures to look at over time — an operational set of metrics.
We found The Research Funnel pretty useful at Monotype but I’d be interested to find out what you think of this system? Is this way of thinking about research helpful? Particularly for non researchers — maybe designers (or developers) carrying out their own research. Does this help you come up with an appropriate research solution for a problem you need help with? Does this make you think beyond just the same old methodologies?
