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.