Introduction to Lean UX principles, plus experiences of putting them into practice at the University of Edinburgh. Presented to the UX Meetup group in Edinburgh on 25 June 2018
5. Are you sure you want that? Really?
• It's well established in research
that what people say and what
they do aren't the same
• We typically think that we want
more power & more features,
when really we appreciate
simplicity and efficiency
6.
7. What is Lean UX?
"Inspired by Lean Startup and Agile development,
it’s the practice of bringing the true nature of a
product to light faster,
in a collaborative, cross-functional way.
We work to build a shared understanding of the customer,
their needs, our proposed solutions and definition of success.
We prioritize learning over delivery
to build evidence for our decisions."
Jeff Gothelf
@jboogie
8. Or to really boil it down…
Requirements
are
assumptions
Jeff Gothelf
@jboogie
12. Lean UX hypothesis statement
• We believe this [business outcome] will be achieved
• if [these users] successfully
• [attain this user outcome] with
• [this feature]
13. Start hypothesising
• Try to head off the feature-first approach with the
Lean UX hypothesis statement
• Get creative with how you test the hypothesis
• Help your stakeholders by
• Framing their request
• Providing data to inform decisions
• Minimising the effort you commit upfront
• It’s not a validation effort if you’re not willing to kill the idea
(More about our experiences: http://bit.ly/UoE-Lean-UX)
Always start with an inspiring quote.
Any ideas whose words of wisdom these belong to?
Bet you didn’t know Benny Hill knew UX
A great model. In a higher ed context where perhaps the product is one that staff and students have no choice but to use, you might change the top circle to everybody hates the product.
If McDonalds surveyed customers they’d almost certainly claim to have more interest in salads than the evidence shows.
There’s this mythical state of perfection. Of a product we’re working on being finished. Funders often believe we can achieve perfection, and perhaps we don’t do enough to dispel this expectation. In reality development should be continuous.
So this tree is that mythical state of product perfection that we’re trying to reach.
Now think about projects that you run. Do you decide upon a path towards that tree and set away, keeping going til you have to stop (or you believe you’ve reached it)?
What if there’s a cliff edge in that fog? Or some less dramatic but nonetheless fundamental obstacle in your path.
In this situation, what would you do really? Just march off despite only being able to see three steps ahead? Or take those three steps, stop, take stock of what you can now see and then continue for a few more steps.
So why can’t we do this with development?
Or to put it another way (my words), it's about making sure that what you're doing is likely to be a good idea before you put too much effort into it.
How many web pages, or features, or service elements are you responsible for that are not well used, or not fit for purpose, or just basically redundant?
How much does it cost you to maintain?
How much does it interfere with your end users' experience?
How did they come to be there, or be like that, in the first place?
How much time, cost and effort went into getting it there?
Is it because nobody stopped to ask why? Or because the boss said just do it?
Or because what seemed like a good idea at first turned out to be not such a good idea, but by that point you were too far down a particular road?
(Run video from 2m 45s to 4m 51s)
How often have we encountered that? A product vision based around a marketing concept. Or better yet, the brainchild of an exec.
And the thing is, how often do we proceed and deliver pretty much what was envisaged without any indication of how the intended audience will respond?
Despite our misgivings, or those of colleagues a bit closer to the coal face?
So Lean UX is all about doing just enough to establish whether a development is a good idea; using evidence of user interaction and demand to justify continuing down a particular path. A well used phrase in the field:
"Fail fast, fail cheap".
You’ll probably find that using the word fail doesn’t go down so well though. I prefer “learn”.
Agile has had such an impact on how digital services are delivered, but in many organisations the focus can be on feature delivery. Doesn’t matter what, so long as we’re delivering.
I’ve personally found this frustrating at times, but then I am bias towards investing in enhancement over new bells and whistles.
And why? Because at the end of the day a feature is only worth the effort if it adds value for the business and the user. If it’s something that is used, and usable.
This is the Lean UX hypothesis statement.
If you take only one thing away with you today, take this.
And next time someone asks you for something dubious, shape their request into a hypothesis statement and ask them if its what they meant.