Designing a good product – one that meets user needs and is both a viable value proposition as well as technically feasible – requires us to be both gamblers and scientists. When we say ‘gamblers’, we don’t mean we’re reckless and irresponsible. We work in an agile way which massively reduces financial risk and helps us find (or discount) solutions to problems quickly. Gambling for agile teams like ours is about speculating and taking risks in the hope of getting a desired result.
Reducing the risk of building something useless
User-centred design tries to reduce the risk involved in building a product by focusing on what users do now, or what underlying job they’re trying to achieve. It involves determining who your users are, analysing their needs, and determining likely demand for different possible solutions. It’s as much art as it is science but done well it can reduce the risk inherent in deciding on a thing to build. And from these findings, these informed reckons, you do some research and start to shape a product.
If you gamble on your product decisions early you learn more, and the odds on creating a good product fit for your target user base start to shorten.
When to take bigger risks and embrace the long odds
Taking bigger risks at the start of the product life cycle usually pays off. At the start, you’re unlikely to have much data on your users and their behaviour, so prototypes will have a set of assumptions about your users to test.
Because you’ll probably only have relatively few users to test with, your gambles need to be stark in their differences. Be radical in tests as this helps discount huge swathes of things and sets you in roughly the right direction. As the product matures, you need to gamble less and make smaller, more educated guesses as the graph below highlights.
Stakeholders: if we don’t take risks, we won’t win
Researcher Sam Ladner sums up the idea of being both gamblers and scientists in her post Design researchers must think fast and slow. She says:
Design researchers should embrace less structure and more openness at the early stages of product design, and rigour and structure in the mature stages of product sales.
Sam Ladner
The graph below, taken from Ladner’s post, illustrates this. It shows the move towards more structure as a product matures. You could plot the decline in uncertainty around market fit, target users, user journey and experience for example, as the product matures too.
That’s how it should work.
However, being comfortable with uncertainty and embracing the idea of taking risks can make stakeholders and our non-Digital colleagues a little uneasy. And that’s understandable – this is an unfamiliar way of working to them. The Digital team know this though and we’re keen to work inclusively and show how testing assumptions is relatively cheap compared to traditional business.
How it works in practice
We can see from some of our projects at the Co-op that the propensity to gamble differs hugely from one project to the next.
The Digital Product Research team moved quickly to test new propositions in the market: things like a white goods subscription service, and a service to ‘scrobble’ (automatically get and process) your utility bills to help you work out how your spending changes, and if it might be cheaper to switch. These were ideas spun out quickly and tested with real users. We learnt from doing the work that as products or services, they were unlikely to provide sufficient return for the investment needed.
Then there’s online Wills. We had more belief in this idea, ie, it exists in the market and is clearly already a thing. Here, it was a case of working out where our proposition would best fit with users and the existing business process. The gamble was on shorter odds, but in many ways felt far harder as we were working with an existing business and its staff, and embedded processes in a tightly regulated market.
Strategies for success
Navigating through product decisions and keeping our colleagues in other areas of the Co-op on board is not trivial. We’ve learnt 2 things which have helped us:
- Stay focused on the problem you’re trying to solve. Your experiments are trying to prove that it meets the user’s needs effectively.
- Business stakeholders prefer the language of data to qualitative research, so use data and qualitative findings to prove out whether the experiment worked and whether it met the user need effectively.
Good luck 🙂
James Boardwell, Head of User Research
Anna Goss, product manager
Great article James. You mentioned at the end to ‘…use data and qualitative findings to prove out whether the experiment worked’ how would you suggest qual research for eg an a/b test variation? Maybe remote user research whilst the experiment is in full flight? Or how else could get gain qualitative insights?