Lean UX workshop with Jeff Gothelf – my top takeaways

Last month I enjoyed a trip down to Brighton for a day long workshop with the author of Lean UX, Jeff Gothelf. UX enthusiasts from across the UK and some from as far as Sweden came down to the south of England to learn more about Lean, UX and all things in-between.
I’m going to run through my top takeaways from the workshop and explain how they can be applied within your product teams.

1.Don’t solve problems that don’t exist

It’s a waste of time, money and resources making solutions for problems that don’t exist. How do you know if a problem actually is a problem? Well, get out of the building (GOOB), talk to your users, ask them about their problems and observe their current behaviours or current workarounds. They might be happy with their current solution but you won’t know until you talk to them.

pop-corn-hoodie

Within your team, get together and write down your assumptions of what you think the problem is and create a problem statement that you all agree on (you can use a problem statement template - see Jeff Gothelf Lean UX).

2.Focus on the ‘M’ in Minimum Viable Product (MVP)?

Every organisation, every team will have a different opinion of what an MVP is, “a stripped back version of the final product”, “our must have features”, “version 1" the list goes on…

What Jeff helped cement in my mind about MVPs was two things:

- that MVPs are for learning, not basic versions of the “final” product
- and they’re not restricted to digital means

Think of MVP’s as tests or experiments to gauge interest/viability of a certain feature or product. The first question to ask yourself is “what are you trying to learn?”, then ask yourself “how can we learn that by doing the smallest amount possible?”. At this point don’t be restricted by thinking that you can only learn by shipping a basic version of the final product. What you can do instead is leverage existing technologies/services/products in order to create an experiment to test your hypothesis by using methods like landing page tests, feature fakes or wizard of oz/concierge tests.

It’s important to set a threshold for success when creating  your MVP, e.g. when we see more than 100 clicks per day on this feature we know it is worthwhile to continue with this, or if 1000 people subscribe on our landing page test in the first week we will know we are successful. If you’re not clear upfront what what success looks like then how will you know when to stop the experiment?

3.Write tactical hypothesis statements

A hypothesis is a hunch, it’s our best guess of what we believe to be true. They are a great place to start when at the beginning of building a new product or feature, but remember they are still our assumptions so they need thorough validation.

They are quite tricky to get right as a good hypothesis statement is made up of a lot of variables with a lot of assumptions baked into them. They are usually comprised of a KPI or success metric, a persona, a user goal and a feature.

Jeff Gothelf has a great template in his book Lean UX that combines them all in a succinct way:

- We believe will will achieve [KPI] if [persona] will attain [user goal] with [feature].

The most valuable lesson I learnt from the workshop was to be tactical about how you write these, think about what is in your control and think about what you are trying to learn. If something isn’t in your control then don’t go ahead with it, have a rethink and move forward swiftly.

4.Start learning more

What I mean by this is, add stories to  your product backlog purely aimed at learning something or running an experiment. Treat learnings the same as you treat other user stories and get your team invested in learning more.

These can be treated in the same way as regular user stories, scope them, define the problem, write a hypothesis and go out and test it. In doing so you are likely to learn something you didn’t know before and it’s good practice at getting everyone in your team involved in the collaborative exercise of writing hypothesis statements and creating MVPs.

5.Getting buy-in to Lean UX in the enterprise

This was a topic that had a lot of interest from the attendees of the workshop and the best pieces of advice was to speak the language of the people you are trying to convince to buy-in to Lean UX and in doing so try to bring them closer to the process.

There is a lot of technical jargon that gets thrown around day-to-day and understandably it can be quite off-putting and intimidating. What’s important when trying to get buy-in to Lean UX in the enterprise is to speak the same language as the stakeholders and understand what they value. If their interests are in acquisition and conversion, then speak to them in this terminology, don’t start talking about progressive enhancement or typeahead as this will only cause more confusion and more unproductive conversations.

In summary…

We all aim to create great products that people need, and Lean UX provides us with guidelines to help move teams from doubt (assumptions) to certainty through evidence based decision making. As the UXer, start by getting your team on the same page by facilitating hypothesis workshops and design studios to help identify the problem and create actionable hypotheses that you want to validate through testing. You and your team will learn every time you speak to or test prototypes on your users so make sure you do this as frequent and early on in the process as possible, seeing as these are the people that you are designing for you need to create a dialogue with them as often as possible to ensure that you are on the right track.

Resources
1. Lean UX - Jeff Gothelf- http://www.jeffgothelf.com/blog/lean-ux-book/#sthash.Y6ULPslO.qI01GYOY.dpbs
2. Popcorn hoodie - http://www.ohgizmo.com/wp-content/uploads/2013/02/Pop-corn-hoodie.jpg
3. Feature fakes - https://www.industriallogic.com/blog/fast-frugal-learning-with-a-feature-fake/
4. Wizard of oz/concierge tests - http://www.usabilityfirst.com/glossary/wizard-of-oz-prototype/

This is only a brief summary of some of the things we covered throughout the day so if you’ve got any questions then please get in touch on twitter or comment below.