Escape the Groundhog Day of Testing (part 3)

Forming Hypotheses

“Whenever known and sufficient causes are available, it is anti-scientific to discard them in favour of a hypothesis that can never be verified.”

Max Weber

In a forthcoming article, I’ll walk you through a group sketching and collaboration process for brainstorming hypothesis with your team.

I recently ran a workshop at UX Bristol using updated materials and have some refinements to make before I write it all up for you. Suffice to say, it’s a useful and practical way to get better quality hypotheses into your testing pipeline.

The information you share or present to others during hypothesis formation has a huge impact on your focus and priority — so it’s vital stuff. If you’re trying to fix known problem domains on a page or interaction within a page, this is far easier to zoom into, understand and find a riposte to — than to randomly try to jiggle the content or functionality around.

You have to have a freaking reason to be forming the hypothesis, not just because you think it sucks right now. Let’s examine a good thought process example:

“Because we saw the huge dropoff rate in our postcode lookup routine inside our web form, we looked at the session replay recordings.

We added some analytics tracking and could see we lost 12% of people who couldn’t find their address.

We did some user testing and know all the problems driving this loss rate from failed form submissions.

We’ve built a new version and will test it against the old one.”

Now that’s what we’re talking about!

Because we observed something bad, which we quantified, we then supposed that we can do something that would change behaviour in a measurable way.

And here is the Hypothesis Toolkit, which we’ll run through a section at a time in the next article.