[This post follows on from our last post on Why You Should Challenge Your Assumptions]
Hoping and guessing are pretty poor ways to go about developing your app or website.
But that’s exactly what you’re doing if you don’t stop and:
- identify your design assumptions
- challenge your assumptions
- test your assumptions
- make changes if your assumptions are invalidated
Here’s an example of how to do it…
Assumption 1: Doc Not Ready
Doc Ready’s team assumed that young people would want to take their mobile phone into their GP consultation and read their agenda off of it to their GP.
Matt Skinner, Doc Ready’s Design Lead explains how they dealt with this assumption:
We assumed that just because young people would be able to read from the Doc Ready app that they would feel comfortable doing this. However we knew this was an assumption because we were only guessing how young people would want to use their phone in a particular context.
We decided that the best way to challenge this would be to get out and give them a simulated experience of using Doc Ready then ask them about how it might work best
To do this we set up paper prototyping sessions and asked young people to tell us what features would be their priority for development. It was clear that rather than reading their agenda off of their mobile device that they preferred the idea of being able to take a professional looking printed agenda into their consultation. They perceived paper as implying preparation, and reading from digital devices as potentially rude or barrier creating for their GP.
This invalidated our assumption and also provided us with a clear steer on the direction we needed to pivot in. We’ve since changed our priority feature set so that using Doc Ready is geared towards enabling users to print off their agenda ready for their GP consultation.
By testing out their assumptions the Doc Ready team saved themselves from making a fundamental mistake by building DR as an app to be used within GP meetings. Had they not found out that young people preferred paper then the app would have failed on a vital part of its usability and probably failed to be used by young people.
So, how can you follow Doc Ready’s approach?
Identify Your Design Assumptions
You need to work out what your assumptions actually are. Here’s how to do it:
- Brainstorm as a team. List all the possible assumptions you could be making, then sort and reword them into tangible statements. By making them concrete you’ll make them easier to test and measure later on.
- Priority sort your assumptions by level of risk and potential impact. That way you can assess which ones are most important to challenge first.
- Whenever someone makes a statement about how the product should be ask “why?”. Often the reasons for their statement may be indisputable but when you come across an assumption that may not be valid, then you’ve found something that you need to test. Doing this will help you weedle out any potentially project-threatening assumptions.
Challenge and Test
So you’ve identified your assumptions. Now you need to work out how to test them, starting with the riskiest ones first.
When you’re working out what tests to use consider what is the least labour intensive method? Here’s some options:
- Do some research and phone calls – can you pick up the phone to someone or challenge your assumption through what others have already done?
- Use face to face meetings. Get out of the building and talk to your users as they do their day to day thing.
- Do some split testing – where you set up two versions of a web page and see how people respond to each version
- Build a Minimum Viable Product. Release a prototype version of your product as soon as possible, and use it to test assumptions
There is no one right or wrong way to test your assumptions and depending on the nature of each one you may need to design your own tests.
While you’re testing avoid gimmicky pat-on-the-back metrics that don’t tell you enough about how well you’re doing. Any metrics you use must be “actionable, accessible and auditable”. Often, less is better.
Keep asking why, over and over. Often as users or customers we’re not sure, we don’t know what we want and when we do we don’t know how to ask for it. But if you keep going back to asking “Why do you think that? What makes you sure? Are there other possibilities?” then you’ll eventually discover what you need to validate your assumption.
Learn and Iterate and Make Changes
So you’ve tested your riskiest assumption and found that it’s correct. Now just move onto the next riskiest and test it.
However if you’ve found that your assumption was invalid then take your learning and pivot your project towards solving a different problem, or meeting the needs of a different customer.
Then repeat the process.
