Lean UX: the what, the how, the where

Lean UX: the what, the how, the where

“Are you ‘lean’?” is what somebody asked me recently. The timing for this was pretty lousy so just after Christmas and I nearly replied with a ‘not as lean as before Christmas’ when I realised that the question referred to our way of working as a company.

Documentation Anyone?
The answer depends on what you mean by lean in the context of UX design. Sometimes Lean UX is interpreted as doing away with documentation, developing things as quickly as possible and then exposing a minimum viable product to end-customers and users to get quick feedback. If it is not spot-on then a new lean UX activity is started to correct it. Fortunately, I hear quite often, we only spend a minimum amount of time on developing the wrong features so our lean UX approach really paid off. For our next attempt we will again spend as little effort as possible so we remain lean.

Trial and Error
My question is, is developing features by trial and error really lean? Is the time spent on developing the wrong thing not a waste of time? Sure, lean UX assures that you only waste a little time possible but it remains wasted time (and thus wasted money). And many small chunks of ‘leanly’ (probably a new word, sorry, leanly expanding the vocabulary although it might be a waste of letters) wasted time still add up to a bigger amount of wasted time. And this is bound to be the case because of another drawback of a lean trial and error development method, you do not know how many iterations you need before you will finally get it right. Chances are you will run out of time and money before you really get there.

A true lean UX method combines agility with efficiency. This includes both what you do, how you do it and where you do it.

Lean UX and Agile UX
The what ensures that we actually get to the end result of an experience that is useful, usable and as intended from the onset of the project. This requires and understanding upfront of validated user requirements and customer requirements. Main issue with a trial and error methodology is that you discover the requirements as you go along. Now, I am the first to admit that you will never be able to define all requirements early on but that should not be an excuse for not addressing them at all. User and customer needs don’t change, the way you meet them does. So, build the foundations for you product by developing a validated understanding of the needs as early as possible. In an agile development environment this will be done during sprint 0 at the end of which you will have the blueprint for your product. In a sense this is the same for the agile software development where the software engineers also build the overall foundations for the implementation in sprint 0. There is no good reason I can think of why the UX component should not follow the same pattern.  This in turn reduces the amount of wasted development time and contributes to a truly lean UX product development cycle.

Working Together
The how focuses on getting product releases out more often. Never has this been more important than for today’s cloud based applications. I don’t know whether you have noticed but version numbers for cloud apps do not seem to exist. This requires short development cycles where functions are improved and added in quick succession. To support this, the ux and software teams do need to work together closely preferably in the same location.

For agile, the UX team develops the details for one iteration one sprint ahead of the technical implementation. This allows the software team to give input to what is and what is not possible. In a constructive environment the focus is on ‘what is possible’ with engineers challenging the UX team (no Dr No’s please). Subsequently while the UX is being implemented by the software team, the UX team moves on to the next items in the backlog but by working in the same environment the software team can now ask the UX team for input.

No Time to Waste
The cycles continue until you end up with a feature rich product of which each feature was developed because we knew that these were the ones needed from our initial sprint 0 research. During the sprints you will have experimented and validated different concepts for meeting the required feature needs but at least we knew that we were working on the right features. No time was wasted on implementing features that turned out not to be needed in the first place.

The result, the shortest path to an optimal experience. If that doesn’t deserve the label lean UX then I look in the mirror again and use the word lean only in the context of a Christmas aftermath.

Dr. Leo Poll is President of Akendi UK.  A firm dedicated to creating intentional experiences through end-to-end experience design, to learn more about Akendi or user experience design, visit www.akendi.co.uk

Leave a reply

Time limit is exhausted. Please reload CAPTCHA.