Hypothesis driven design-thinking explained

At Code, every new idea for improvement starts with something that we’ve observed – when our users have demonstrated to us that something isn’t quite right. Then comes the theory, the pontificating and the ‘what if’…

Instead of grasping around for what exactly we’re trying to achieve, we turn these thoughts into something that we can definitively act on: a simple, measurable hypothesis that ensures everyone’s clear on what we’re aiming for and why.

The hypothesis tool we use isn’t rocket science; in fact you might have even come across it before. We use the following structure to create it:

Because we saw A we believe that by doing B we will see C. We will know this is true when D happens.

It forces us to think about why we are doing something, what the possible solutions might be and exactly how we will measure whether it’s made an impact for our users and our business or not.

Here’s a couple of examples of hypotheses we’ve used recently:

Because we saw that Transform patients were excited to take the next step when they came to our website, we believed that by matching that excitement we would increase conversion to consultation. We will know this is true when we see the completion rate of the form increase and drop-offs reduce.

Transform

The results: happier, more excited users and an increase in conversion rate.

Because we saw that users were taking their time to renew their NUS Extra card or weren’t renewing at all, we believed that making the process as simple as one-click would increase the renewal rate. We will know this is true when we see an increase in conversion rate for card renewals.

NUS extra renewals

The hypothesis might not always prove to be correct, but the format ensures we can always learn from what we’ve done.

Give it a try – it’s something that can work for everything from a big idea or a small copy change –and let us know how you got on @computerlovers on Twitter


Using design sprints to drive product innovation