It was a situation that I had been in before: trying to get developers and interaction / UX designers to work together effectively. Not always easy. The UX person had worked out a vision of what the monitoring tool could look like, we then used these visuals as a starting point for internal discussion, trying to figure out the key requirements to concentrate on. When a developer saw the visuals however, his face contorted in an expression of shock. “What were you thinking!? This is a typical case of ‘Big Design Upfront’, this is a complete fallacy!” As a strong believer in cross-discipline collaboration in product development, there was a clear challenge here to get the different disciplines on the same page, to agree on an appropriate approach.

Reason enough for me to start reading “Lean UX: applying lean principles to user experience”, a book recently published by Jeff Gothelf with Josh Seiden. Jeff is a New York-based product designer who has led cross-functional, Agile development teams and now runs a design studio which was recently acquired by Neo a company co-founded by Eric Ries. Josh Seiden is a managing director at Neo who specialises in user experience design and has worked closely with Jeff Gothelf on the Lean UX book.

Like Ries, Jeff Gothelf specialises in Lean practices which he applies to user experience and user-centric design thinking. In “Lean UX” Gothelf explores a more collaborative and ‘lean’ way of designers, developers and product managers working together. Gone is the idea of interaction or UX professionals thinking up a design in isolation, then passing their design on to developers to implement. In contrast, Gothelf proposes a more cross-functional and incremental approach to user experience.

These are the main things that I learned from “Lean UX”:

1. Collaborative and cross-functional – Gothelf stresses the importance of ‘one product team’ where the product manager, developers, designers and any other stakeholders work closely together on product development. It’s therefore critical to come to a shared understanding with your teammates of the product outcomes that you’re trying to achieve.
2. Measuring outcomes – One of the key principles of Lean UX is the measurement of progress in terms of outcomes (instead of outputs or deliverables). Gothelf’s point is the effectiveness of features can only be proven once they’ve been launched. He therefore suggests an approach which concentrates on specific, well-defined outcomes. This approach also means that you can test your product features against these desired outcomes as you develop a product.
3. Design in small batch sizes – True to the concepts of Agile and Lean, Gothelf urges teams to avoid working with big “inventories” of untested and unimplemented design ideas. I agree with Gothelf that it’s more effective to work in small batch sizes instead, using the release of each small batch to learn and improve, however, I nevertheless believe that it can be very valuable to have an underlying vision of what it is that a product is trying to achieve. Such a vision can be visualised through some rudimentary sketches or a more detailed design. This can subsequently be broken down in small batches that can be worked on. As with the recent example I mentioned earlier, I learned that when you create such a vision upfront, the challenge is in ensuring that stakeholders don’t view this as set in stone or to be delivered exactly as the visual suggests. In my view, any design done upfront can only act (and be presented) as a guide; getting feedback on the direction you’re thinking of following and having a starting point for specific features to work on.
4. Design based on assumptions – The whole premise of the “Lean Startup” movement by Eric Ries is the notion of validating assumptions. In Lean UX Gothelf applies the same thinking to user experience: don’t get too hung up on fixed features but concentrate instead on testable assumptions (see Fig. 1 below). He goes on further by recommending to focus on the riskiest assumptions first, “the higher the risk and the more unknowns involved, the higher priority to test those assumptions.”
5. Test your assumptions using hypotheses – The bit in Lean UX which I probably found most helpful was the creation of hypothesis statements as a way to test (or validate) assumptions. A hypothesis statement is a more granular version of the original assumption which is easier to test (see Fig. 2 below). You can use these hypotheses to test a specific product area or workflow. Outcomes are the market signals that help us to validate or invalidate these hypotheses (see also point 2. above). These signals are often quantitative but can also be qualitative.
6. Lots of tools you can use! – “Lean UX” offers a wide variety of tools and techniques that you can use to achieve collaborative design. Whether it’s practical tips on how to run a design studio or create personas, Gothelf outlines the practical use of each tool (and provides real-life examples). This in my view makes books like Lean UX, “Rocket Surgery Made Easy” and “Undercover UX” such valuable and helpful references.

Main learning point: I found “Lean UX” a comprehensive and very helpful book. The book provides a clear departure from a more traditional way of thinking around the inclusion of user experience / interaction design in product development. In Lean UX, Jeff Gothelf stresses the importance of ‘collaborative design’, getting all stakeholders involved as early in the process as possible. He makes a strong case for cross-functional product teams which are continuously looking to validate certain assumptions, developing products iteratively and learning along the way.

Fig. 1 – Assumptions Worksheet template (by Jeff Gothelf, “Lean UX: applying lean principles to user experience”)

Business Assumptions

1. I believe my customers have a need to _________ .
2. These needs can be solved with _______ .
3. My initial customers are (or will be)  ______ .
4. The number 1 value a customer wants to get out of my services is ___________.
5. The customer can also get these additional benefits ___________.
6. I will acquire the majority of my customers through ___________.
7. I will make money by __________.
8. My primary competition in the market will be _________.
9. We will beat them due to _______.
10. My biggest product risk is _________.
11. We will solve this through _________.
12. What other assumptions do we have that, if proven false, will cause our business/project to fail ________.

User Assumptions

1. Who is the user?
2. Where does our product fit in the user’s work or life?
3. What problems does our product solve?
4. When and how is our product used?
5. What features are important?
6. How should our product look and behave?

Fig. 2 – Common hypothesis statement format (by Jeff Gothelf, “Lean UX: applying lean principles to user experience”)

• We believe [this statement is true]
• We will know we’re [right/wrong] when we see the following feedback from the market: [quantitative feedback] and/or [key performance indicator change]

A way to break a hypothesis statement into smaller, testable parts:

• We believe that [doing this/building this feature/creating this experience] for [these people/personas] will achieve [this outcome]. We will know this is true when we see [this market feedback, quantitative measure, or qualitative insight]. 

A simple way to include personas in your hypotheses:

• We will [create this feature] for [this persona] in order to achieve [this outcome]

Related links for further learning:

1. http://www.jeffgothelf.com/blog/
2. http://founderswiki.com/wiki/UX_%26_Collaboration_techniques
3. http://blog.crisp.se/2013/03/24/jeff-gothelf/lean-ux-in-the-enterprise
4. http://www.slideshare.net/jgothelf/lean-ux-getting-out-of-the-deliverables-business