The other day I wrote a quick response to the question ‘What are the weak points of the Lean UX design methodology?’ on Quora. A couple of people have asked me to explain a bit more about my post so I thought I’d elaborate a little.
The app I’m currently working on is focused on developing a Minimal Viable Product (or MVP) for use in schools. Unfortunately the project has had strict time and budgetary constraints imposed on it so, from the outset, there was a real pressure to deliver as many stories as possible in the given time. (In a true Lean environment MVP wouldn’t be a deliverable as it is here but a state of flow but thats the situation we have.)
Due to the restrictions of this project its concentrated a lot of the Lean UX implementation headaches into a short period of time which prompted me to write this post.
One of the many problems with the ‘feature first’ approach is that in order to include as many features as possible any UX and design consideration is stripped so far back whats implemented could have a negative impact of the usability of the feature in question. While none of the changes made are huge compromises the cumulative effect can be damaging to the experience of using the product.
The other problem is that in order to deliver as quickly and efficiently as possible any delighter or exciter elements often get removed in order to fit the feature into the sprint. Once that happens there is almost zero chance of it ever getting retrofitted.
“In the rush to deliver a minimum viable set of features (the threshold elements in the Kano model) we often ignore the elements that make the product really great (the exciters and delighters in the Kano model). As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.”
In order to mitigate this problem each story or feature should come from the users themselves and should have a hypothesis which we, as a team, should seek to validate.
For example say I wanted to introduce a new brand of ketchup to the market. The hypothesis could read something like:
“We believe that lovers of spicy food will want to use our new brand of super spicy ketchup as a condiment with their food.
We will know this to be true when:
– We see a week on week increase in sales of our ketchup in supermarkets
– Our customers tells us they like the taste”
(not a great hypothesis but you get the idea!)
To continue with this rather clunky analogy – If we imagine that our ketchup is in the wild and our test supermarkets put it on a high shelf, out of reach for most people, we would probably find that hardly any ketchup is sold. From this you might assume that no one wants the new ketchup and the product is a failure. If however you put the same ketchup on a shelf which is easier for people to reach then we may find that more people buy it and our hypothesis has been proved correct and people love super spicy ketchup.
The point being if the feature we our trying to introduce isn’t given a fair chance by being implemented as well as it could be then we shouldn’t be surprised if hardly anyone uses it and its widely ignored.
So whats the solution? Well the bad news is there isn’t a silver bullet which will cure all the ills, more a few things that, if implemented well, may help.
- Better integration between the devs and UX. This first one is a no brainer. Work together to design easily implmentable features with minimal overhead.
- Spend more time talking to the PO so when they are grooming and prioritising the backlog they have the full picture and understand what the implications of their decisions are.
- A key hypothesis for new features. What problem is this feature we’re implementing solving and how will we know when its succeeding? Include a hypothesis not just for the product but for each story and also include a KPI to test that its doing what its supposed to. Which leads nicely onto…
- Once a feature is live keep testing it. Keep questioning its validity and seeing how the experience of its usage can be improved for the end user. Schedule points to revaluate features and see how the experience could be improved through iterative design.
- Ditch the burn down chart. Burn down charts are only useful for management types who like graphs. The proof of progress should be in the features and stories which you’re pushing live which users using. (Theres a blog post in there somewhere but I’ll save that for another day!)
- Continuous deployment – Don’t wait till the end of the sprint to release new stuff. Release early, release often.
Theres probably a bunch of other things that you could do but thats all I’ve got for the moment.
For the record I love Lean and Agile as a process for designing and building products, it just feels that sometimes in the excitement of getting stuff out there, we lose sight of the detail which separates the ok products from the great ones.