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.
- Who is the user?
- What outcomes do they want to achieve?
- What features will they need in order to do so?
- 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.