The Digital Product Research team at Co-op Digital has been exploring what the future might look like for the wider Co-op. We’re about to move onto a new phase of work, so this is a good time to write up some of the things we’ve learnt.
Our team of 6 has been learning by doing. We’ve looked at things like Life after work, Everything is connected, Financial freedom through early planning. Our most recent work was about energy and co-operation: Collective switching for good. You can read about more of our experiments at dpr.coop.co.uk.
This is the first in a series of posts covering design principles and ways of working that have emerged in the last 12 months or so.
Getting out there matters
Our research started out much as you might expect: we spoke to Group colleagues, Co-op members and spent time with people in research labs. But we quickly became aware we were spending too much time in artificial settings. Research is best done in the context of the problem you’re trying to understand, so we made sure we got out of the office.
This took us to lots of different places — sometimes with a discussion guide that outlined areas of interest, sometimes with a digital prototype people could interact with.
Hoping to understand how people use energy in their home, we took a trip to Lichfield and knocked on doors. We’ve looked for jobs at the Uber offices in a bid to understand a bit about what it’s like to be a driver. We also wandered down a high street to talk to shop owners about their relationship with other traders and with their customers. Doing all these things gave us greater confidence in the direction we’d take the projects.
Reflecting and adapting
We hit prototype testing fatigue after following GV’s Sprint method for a few weeks. We started to reflect on what the GV Sprint method offered us. We found it wasn’t providing enough insight into people’s problems, motivations and feelings. One of our experiments, Protecting your stuff, really highlighted that failing. The prototype was good, in lots of ways, and so was the idea of insurance based on trust within your community. But it didn’t explore people’s behaviour as a part of a real community in the context of our proposition.
We weren’t getting under the skin of the problem.
This sort of misstep led us to rethink how we thought about researching with prototypes. How might we prototype communities? How might we understand the mechanics of group behaviour to enable co-operation on a Job To Be Done?
Research is a team sport
We’ve each had ideas on how we might get closer to the user. Reading research papers helped our understanding of switching energy providers. And we used targeted Google Ads to get people to a website and used an Intercom chat widget where we could speak to them, in real time, at their point of need.
All of this was a collective effort.
Rather than have a dedicated user researcher, every member of the team has been involved in the research which is great. (Looking back, if we’d had a researcher, they might have helped make sure the time we spent with people clearly pointed back to the assumption we were trying to prove or disprove).
We’ve found that when every member of the team gets involved in the research process, they can understand people more and design our proposition better. As user researcher Simon Hurst says, getting each team member involved “ensures they design with the user, and not themselves in mind”.
We’ve poked and prodded along without a user researcher on the team and I wonder whether this has forced us to think differently. Learning from others — like GV’s Sprint method, or best practice led by an embedded researcher — is a good place to start, but there’s a lot to say for taking that baseline and adapting it to the specific problem at hand.
We’re also lucky to have a community of user researchers to guide us when needed. Research is integral to what we do and the onus is on us to question how we use it. We’ll keep doing that, as we move on to our next project.