Josh Seiden, the Managing Director of Neo, delivered a webinar session on the role of Hypotheses in a Lean UX design environment. His description of the talk:

It’s easy to talk about features. Fun, even. But easy and fun doesn’t always translate to functional, profitable, or sustainable.

That's where Lean UX comes in-it reframes a typical design process from one driven by deliverables to one driven by data, instead. Josh Seiden has been there, done that-and he's going to show us how to change our thinking, too.

The first step is admitting you don’t know all the answers; after all, who does? You’ll then write hypotheses aimed at answering the question, “Why?”, then run experiments to gather data that show whether a design is working.

My notes from his talk follow:

 

1. Hypothesis VS Requirements

• Thinking an idea is a good one and then working months on a solution is far too common in our industry.
• The lean cycle is to build, measure, then learn and repeat.
• Build small bits of your product, and push them live all the time to slowly build up a product.
• Lean UX encompasses development as well as design.
• Hypothesis statement: We believe. Be sure to always include a statement containing when you will know whether the hypothesis was true or not. This can be qualitative or quantitative. I can also be a business-focused outcome.
• Translate your design requirements into hypothesis to better understand the asks. You are taking out personal assumptions this way.
• Hypotheses scale up and down. We can use them on tiny small details, all they way up the entire structures of our projects.
• Hypotheses should include the full cross-functional software team from design to development for best results.

2. Writing Hypotheses

• The key to science is "If it disagrees with experiment, it is wrong". This was shown in a 1964 video lecture on science delivered by Feynman.
•  It doesn't matter who made the guess! We need to integrate this idea into our workplaces. A managers opinion does not matter if you can test it and prove that it is incorrect.
• Output = the software we build, the materials we produce / easy to measure.
• Outcome = the change in the world after output is delivered/ harder to measure.
• Impact = the change we see over time / very hard to measure.
• Every project begins with assumptions, this can be hard to admit in the business world. You are making guesses as to what products you should build.
• Ask your self "What assumptions, if proven wrong, could cause my business to fail?" and test these assumption immediately.
• Identify all assumptions at the beginning of a project. Then, you can write the hypothesis for the project.

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

• Using a three column table layout can help for this ideation in the workplace.

3. Testing Hypotheses

• MVP is viable in the sense of testing your hypothesis. NOT making a profit with your product.
• Test your hypothesis and achieve your learning objective.
• Testing your hypothesis is all about how do we know when we are right and/or wrong about our assumptions.
• Use clever design to test in the fastest, cheapest way possible. Build a link to measure demand for a feature, as opposed to building out the feature itself. Users must be tolerant of this type of experiment.
• Minimize the development efforts however possible to capture demand for features and investment in those features.
• Concierge MVP. Build the front end and fulfill the backend requirements by human hand, to test the hypothesis. Zappos did this for example. The CEO bought shoes locally with a front end only website to get started and test people's need to buy shows online.
• Landing page to capture demand for something with Google/Facebook ads. Sign up to be notified when it is available.

4. Avoiding Common Problems

• Too big to test. The hardest part of this process is making your hypothesis small enough to test.
• If you're having trouble designing the test, there is a good chance that it's too big. Try breaking it down into a series of smaller tests.
• Test the risky stuff first! Don't waste time testing the easy things, these aren't always worth testing at all.
• Features or assumptions with the highest ability to ruin your product are the most urgent.
• Test with the real market. This is data-informed design, not data-driven design.
• Lead with vision, then test against this vision ruthlessly.