What really is Lean UX?

How effective are your UX deliverables?

Many of us produce amazingly beautiful, nuanced and comprehensive UX deliverables:

  • Personas
  • Storyboards
  • Content inventories
  • Concept maps
  • Information maps
  • Empathy maps
  • Experience flows
  • User flows
  • User journeys
  • Use Cases
  • Wireflows
  • Wireframes

How often, though, do we ask how effective are these at communicating our knowledge to others of what needs to be built? This is where Lean thinking is now stepping into the Agile UX arena.

Image
How effective is our documentation in communicating the UX requirements to the team? Image by Claire Murray.

Lean UX promotes continuous assessment of where waste is occuring in your processes

As I continue my agile journey and work within agile methodologies like Scrum as a member of a larger, multi-disciplinary team, I’m constantly asking myself whether there are more effective, faster, less wasteful ways of communicating the intent of my designs to those who will realise them. This issue is further complicated by the fact that Knowledge Theory tells us that only a small percentage of knowledge can be transferred by documentation (explicit). The rest of knowledge is held as tacit of experiential and cannot be codified. This knowledge is akin to riding a bike — it’s only in seeing it and doing it that you can really understand how to do it.

Lean isn’t anti-documentation — it’s about adding value to the end product

Lean doesn’t say that documentation is wasteful. The mistake most developers and designers make is in assuming that Lean asks people to re-think documentation in terms of wasted effort contributed toward the build of a product. Lean only asks us to look at where waste is occuring as it applies to the end-product, learn why it is happening, and act to remove it. The result is simple — we have more time to focus on what produces value in the products we’re creating.

In essence, Lean thinking asks:

  • How do we preserve value with less work?
  • How do we improve the delivery of overall customer value?
  • Does a task add value to the end-product for its users?
  • What ways of sharing knowledge about the UX requirements are more efficient?
  • What documentation or artefacts are the most effective for communicating different aspects of the UX?

Applied to software development, Lean can be summarised by seven principles, that are very similar to Lean manufacturing principles:

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team to self-manage
  • Build integrity in — including how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems
  • See the whole — that is, not simply the sum of their parts, but also the product of their interactions from defects in code to poor experiences by users

Lean promotes light-weight methods so they can be updated in real-time

Documentation that creates a placeholder for a collaborative discussion with the Team or end-users to quickly and efficiently reach a consensus about requirements is not wasteful.This might be a wireframe set developed in Axure or Balsamiq as part of the planning for that meeting with annotations captured on a whiteboard where the improvements or additions are required. A beautiful, high-fideliy, comprehensive end-to-end prototype that dictates to a developer every aspect of the interaction design is likely, however, to be largely wasteful. This is because Lean promotes the drawing of maps and concepts as the primary way to deepen the shared understanding of the value in a product. Pencil and whiteboard drawings are favoured by Lean thinking because they enable real-time, simple and iterative adjustments as they are needed.

Conclusions

The path to Lean UX is rather simple. It means undertaking exploration tasks that are designed to gain knowledge and insight that can be shared with the team and results in the end-product being of greater value to end-users. The challenge, as always in adopting more agile work practices, is letting go of the dogma of years of established practice, and ask ourselves “how can I ensure that the time I spend adds more value to the end product for its users”?

M

Advertisements