In the opening plenary of IWMW 2016, Neil Allison from University of Edinburgh introduced the key concepts of Lean UX, how it can help you better meet business and user needs, and how it can nudge your colleagues to think about their requirements differently. In this post we summarise his key points…

Neil’s talk was inspired by a workshop and book by Jeff Gothelf on Lean UX, focussing on how organisations can adapt, which had a profound effect on how he approaches projects.

He is key argument is that requirements are actually assumptions. You need to make sure that what you’re building a good idea before you get too far down the road. Institutions often end up building a lot of web pages and products that are essentially redundant. How did this come to be? Often no-one stopped to ask why. Neil illustrated this with a clip showing Willie Wonka’s failure to do lean UX in Charlie and the Chocolate Factory:
 

 
There is often a marketing vision – or an idea from a Vice Principle – that drives development, and may even be successful when measured against the Vice Principle’s expectations, but gets the reaction ‘that’s weird’ from the final users.

Lean UX is about doing just enough to establish if development is a good idea and using evidence to justify continuing down a particular path. The common expression is “Fail fast, fail cheap”. Neil argued that “Learn fast, learn cheap” might be more appropriate.

Within his own work at the University of Edinburgh, he has found that a focus on features can be frustrating. He would prefer to see development focussed on making existing features better, rather than adding new features without evidence that they are actually needed. He advocated creating a Lean Hypothesis statement for each new feature:

  • We believe this [business outcome] will be achieved
  • if [these users] successfully
  • [attain this user outcome] with
  • [this feature]

Note that the feature comes last. The business outcomes and the user aims are explicit, rather than implicit. What can the feature do for the business/user?

To do this, you need to start with learning. However, asking users is not always the answer. There is lots of research showing that what people say they want and what they actually want are different. You need to look for ways to observe behaviour cheaply and easily so you can learn what they really need as quickly as possible so you can decide if an idea is worth investing time and effort developing. Most people think they want more power and more features, when really they appreciate simplicity and efficiency.

Neil demonstrated this by highlighting the results of a web survey, which suggested that users were keen to see an advanced search feature. They tested this by adding an advance search button, which when clicked simply asked people to complete a survey asking what they wanted out of this feature. This was clicked only 0.003% of the time whilst it was shown on the site. Nobody took part in the survey. This meant they killed it as an idea and saved the development time so they could spend this time more smartly.

Neil concluded by encouraging delegates to get creative when testing hypotheses, and to help their manager frame their requests. He also stressed that it is not a validation effort if you are not willing to kill the idea.