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.

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.


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”?

About the author

Related Posts:

Product Management versus Project Management

Gartner reports that 85% of executives are now turning to agile product management over projects. Why is this shift occurring and what do you need to know about product management to optimise your strategic investments for greater market share, better ability to pivot, or get your products to market faster?


Big Upfront Planning is Out. Pivoting to Respond to Change is In

With uncertainty at an all time high, the response of many organisations in those early days was to batten down the hatches and the impact may be felt for many months to come. To survive through this, big up front planning will be out and pivoting to respond to change will be the new normal.  


Remote PI Planning – Insights into what worked and what didn’t

Running remote PI planning for the first time 100% virtual was a bit daunting a few weeks ago when the reality set in that with the current crisis, this was now our reality. We prepared, thought through worse case scenarios and had back up plans and felt eerily calm as the day began. It was a great success and here are our tips.


Strategies for successfully leading remote agile teams

Leading remote agile teams was always going to be tricky. Implementing these 6 strategies can help leaders reduce team stress, address concerns about work progress, increase productivity for the  teams, and restore and maintain healthy communication channels.


Copyright © Zen Ex Machina® and ™ (2020). All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close