User research in 5 days, getting things done!

Mike Tattersall is a Product Manager and Researcher at Hippo, here he blogs about how to get user research done quickly

I and two other Hippos recently had the opportunity to work with a household name retailer on a problem they had with a new service they were investigating. Nothing that unusual about that request as we’re currently working with lots of different organisations on a myriad of problems. The difference this time was we only had 5 days to conduct user research and present our findings.

Why 5 days?

This organisation had been doing user research for a number of months around a service they are looking to introduce. They had spoken to a number of people about problems they needed to be solved however they had got stuck in a cycle of research. They had just ended up validating existing research and finding out nothing new.

There was a looming deadline to support a proposal to move the service forward as a business opportunity. The situation was they hadn’t yet validated some of the problems or what those potential solutions could be.

They were in effect going round in circles.

They needed a prioritised list of Alpha tests to take the project forward and another viewpoint from a neutral organisation who would not have any preconceived ideas around their proposal.

This is where we felt we could help.

Coming up with a 5 day plan.

We have previous experience of working to such timescales although it doesn’t happen too frequently, we’ve used design sprint formats previously and we wanted to do something similar.

We had a number of problems with this approach to overcome, the main one is that we wouldn’t have access to the team that had done the existing research except for an hour on day 1. This would mean we would not have enough time to really understand the process and research so far.

We would need to tweak the format of our user research, this is what we came up with as a plan:

Day 1 — Understand

• Talk to company Subject Matter Experts (SME) who have existing understanding of the opportunity and research
• Carry out desk based research on competitors and market
• Map assumptions based upon importance and existing supporting user research
• Confirm which assumptions to test.

Day 2 — Map the opportunity

• Using existing research we have found along with the findings from day 1, map the potential end to end user journey. Agree which product features we will focus on.

Day 3 — Sketch and Analysis

• Sketch the product design
• Ensure the assumptions we’ve agreed to focus are on able to be tested
• Research with a small number of users. Analyse the opportunity and potential implementation.

Day 4 — Prototype and plan

• Using feedback from day 3 we will refine the product idea and prototype it in code
• We will form a plan to test the product and assumptions.

Day 5 — Research and consolidate

• Research the product by understanding value to users
• Answer assumptions
• Consolidate the week into a digestible output and provide recommendations for Alpha testing.

Sprinting to solve the problem:

Day 1

We immediately had an issue as the researcher from the team couldn’t make our conversation. They shared some research but we had hoped to spend a quality hour with them to understand what had been done and why. So day 1 hour 1 we pivoted our approach. We started mapping our own assumptions about the service against if we believed it was important or not.

We spoke to the person leading this piece of work in the organisation and validated what they believed was important to find out and why. Then we analysed the research we had been given and began doing our own desk research. We ended the day by revisiting our assumptions and mapped them against a scale of known to unknown. This gave us a focus of more important and mostly unknown.

We checked in with the stakeholder to update them.

Day 2:

This started with the conversation with the user researcher, we played back the work from day 1 and some of our assumptions moved to the more known side of our map. This sharpened our focus.

We began mapping an end to end user journey that could be tested on day 5. By the end of day 2 we had a potential journey to test with our assumptions mapped onto different parts to test in research. We started lining up the research session for day 5. At the end of the day one of our team did a research trip to go see a similar product that was already live. This would fit into our user journey so we understood it fully.

Day 3:

A day that began with the news that we wouldn’t be researching on day 5 but day 4 as our target user group wouldn’t be available as previously planned. Time to pivot again. We immediately began sketching the parts of the journey we planned to prototype and ensured our assumptions were still mapping against this and that our tests for research would be valid.

Next we set about prototyping the service based upon these sketches. We began putting together a discussion guide for the research, as we were doing a research akin to “pop up”. It was essential to have a clear discussion guide that helped us in our conversations quickly. It was important to check our prototype against the assumptions again before finishing day 3.

Day 4:

We travelled to Manchester where we would be carrying out our research, set up and began the user research.

We spoke to over 15 people during the few hours we were there. Users were engaged with the service we had designed and it resonated with them around some of their problem areas. We even managed to get the stakeholder in charge for this piece of work to come along.

Day 5:

It was time to consolidate the user research and tidy everything up into a clear output. We carried out a mini show and tell by working through the work we had done with clear explanations and feedback. This allowed the organisation to digest the research ask any questions they had.

Conclusion

The overall output was positively received by the organisation and we were able to find an answer to most of the assumptions on the service and whether it was a viable product. This has allowed the stakeholder to present options for funding to the organisation and to work on the next stage of this proposed service.

Have you been involved in a sprint at speed like this one to solve a problem? How did it conclude for you and your team?

Do you need help solving a problem in your business and would like to talk to Hippo about how we could help? Get in touch with Hippo or me on twitter at @tmikes18