Picture of App Wireframes

“Survival mode never did me any good. I didn’t get an award for working long hours to make deadlines.” – Clarice Bouwer

The Requirement vs. The Hypothesis

Have you been on a project where you have been handed a list of requirements and told to build them? Whether it’s UX Design or code, that list of requirements can seem arbitrary when they come across your desk. Who decided on these specific requirements? Why? How do we know these are the right requirements for what we are building?

The following two statements can seem similar, but at the core they are very different. Take a look:

  1. Create a system that people can use to find design consultants on the internet.
  1. We believe that people will pay for a service that makes it easier to find design consultants on the internet. We’ll know that’s true when we see…

Unlike requirements, hypothesis statements can be large or small. Requirements, on the other hand, are either very vague, or super specific.

Because the hypothesis statement is questioning instead of demanding, it is easier to scale that question to something larger or smaller.

Product Level Hypothesis:

We believe that people will pay for a service that makes it easier to find design consultants on the internet.

Feature Level Hypothesis:

For registered users who are having trouble logging in to our system, we believe that masked passwords create an obstacle. Unmasking passwords will allow them to log in successfully at a higher rate.

The Hypothesis Statement

The hypothesis statement contains four parts in order to be complete.

We believe that…

  1. doing this [feature]
  2. for [these users]
  3. will achieve [this business or user outcome].

We’ll know this is true when we see

  1. [this market feedback].

A large part of writing hypothesis statements is it is a cross-team activity. It can’t be done by just the Product Manager, or the CEO, or some VP.

Before you even put words to paper, you need to collect assumptions.

Frequently, a lot of people think they know the user. But have you asked three different people in the company the same questions about the user(s) and gotten the same answers?

Just by looking at the hypothesis statement above, here are some assumptions you need to answer before you can start writing your statements:

  1. Who is the user?
  2. What outcome do they want to achieve?
  3. What features will they need in order to do so?
  4. What business outcomes are important to us?

The Experiment

The outcome of requirements are the final code and user acceptance testing feedback. That’s great, you just spent x number of hours building something and have no idea if it is the right thing or if it will be successful in the market. Instead, you should build small experiments that test a feature, an interaction, a concept. It’s the classic MVP (Minimum Viable Product). There is a reason for doing this, and it’s so you don’t shoot yourself in the foot with money and time.

You know if your experimental test is correct by the following signals:

  • Qualitative outcome and/or
  • Quantitative outcome
  • That improves this key performance indicator.
Always test the most riskiest assumptions first. Always test with real users. Click to Tweet

Final Comments

Hypothesis statements can be too large to test. If you feel like that is happening, then break your hypothesis into sub-hypotheses. A common misconception is that since there are “tests” involved, there will be conclusive evidence to make a decision. However, this is not hard science, but a method to prove or disprove assumptions. As a UX Designer, you will still need to use your best judgement.

“You still need vision, intuition, and all that soft stuff. This is about data-informed design, not data-driven design.” – Josh Seiden

Ready to join the tech revolution? Check out our user experience design program today!