I'm David Little, a user experience researcher and designer

Pragmatic UCD part 2: Lean UX

Posted: November 12, 2013

I’ve been learning more about Lean UX recently and am finding it fits very well with some of the comments I made in my pragmatic user-centred design ramblings back in July.

Whilst I still hold that any methodology should be considered on its merits and not adhered to dogmatically there’s a lot in Lean that makes perfect sense to me, not least in its emphasis on quickly and iteratively testing ideas and assumptions, rather than becoming bogged down in creating deliverables. I’ve wrote about how I’m working to adapt our current UX workflow into more of a Lean process at DDH on our blog.

Without wanting to repeat myself here, the main advantages I see of Lean are:

  • Using what we know about our users (e.g. user stories or personas) to inform the prioritisation of design work; and breaking this down into small testable chunks.
  • Working with functional prototypes rather than with static documents such as wireframes (although with caveats).
  • Collaborative design sessions: by getting designers, developers and subject specialists to sit down and think about problems together instead of isolation we might start to remove some of the friction in the design process.
  • Building up a comprehensive library of design patterns and design principles to avoid anyone having to re-solve similar problems.
  • Considering ways in which usability testing can be incorporated more into the project life-cycle–there are logistical and financial challenges to this but these could be considered at the project proposal stage.

On the other hand, I think certain caveats must be borne in mind:

  • Functional prototypes can take some time to build, even when using tools such as Foundation or jQuery–sometimes time could be better spent by discussing an idea via lower-fidelity means–so there’s still a place for wireframes and sketches.
  • In an ideal world, testing with end-users might take place regularly (on a monthly or weekly basis). This is currently not practical on most, if not all, of our projects due to us creating products for specialist audiences who will often be time-poor and geographically dispersed.
  • Due to the fact that some projects have long timescales, care must be taken to ensure the final product’s consistency when working on small, individual parts of functionality across the project life-cycle.


No comments? The comments haven't exactly been coming thick and fast recently so I've disabled them for the time being. Instead, why not drop me a Tweet at @littlednet or email me at info@littled.net?


‹‹ More writing