Understanding Lean UX

January 25, 2013

On January 27, 2013, I’ll be attending a workshop at the Lean UX Week Singapore 2013. So I thought I’d like to do some preliminary study first from the web about it.  Below are my findings and thoughts:

What is Lean UX

  • Inspired by Lean and Agile Development principles
  • Emphasis is on designing and delivering the actual user experiences rather than producing deliverables
  • Traditional documents are stripped down to bare components, if not discarded
  • Favor on very short, iterative, low fidelity cycles rather than long detailed design cycles
  • Process:  Concept -> Prototype -> Validate Internally -> Test Internally -> Learn from user behavior -> Iterate
  • Focus on close collaboration, shared understanding and continuous customer feedback
  • bringing “Think-Make-Check” discipline to projects
  • methods include Guerrilla research, low-fidelity sketching and rapid prototyping as compared to “Fat UX” which includes  month long research engagements and reams of formal documentation.


  • to get a product to market quickly and efficiently
  • validates the product early on
  • validates business goals and identify market needs
  • team ownership of the design is established earlier than “Fat” UX
  • uncover hidden design constraints / designer’s wrong perceptions of the requirements quickly
  • uncover what will work and what will not quickly
  • systematic way of finding the core features that matters most to users that’s cost effective . e.g. coming up with a “Minimum Viable Product”
  • early feedback from users can help reveal what features are important and what are not, or if their mental models are aligned with the way the product works
  • provides a cheap way to correct usability bugs early on
  • minimizes “waste”, waste defined as  anything that is ultimately not used in the development of the working product


  • agencies who are paid for deliverables may have problem with it
  • if development work is outsourced to vendors, where documentation work is important to get work started, Lean UX may not work
  • the tendency of reducing creativity to pure production
  • the tendency to treat deliverables\documentation as not important and rely on sketches and prototype to communicate everything about the product. Prototype may not cover all use cases
  • Things to watch out that could stifle collaboration: Anti-Patterns by Bill Scott
    • Genius Designer – All design emanates from an huber designer
    • Tribal groups – As soon as team gets bigger, tribes reform around disciplines
    • The Stranger – When new team member joins, the lean team assumes the shared understanding will just happen
    • Bad Habits – Old habits will tend to creep back in
    • The Naysayer – A single naysayer can bring the team down in an instant
    • The Visitor – People cycling int and out of the team can cause disruption
    • The Magic Tool – Tools that empower prototyping can enable designers to work in isolation
    • Going Dark – When a team member goes into isolation for more than  a day, the team is losing valuable collaboration
    • Change of Cadence – Whenever the rhythm changes, it can bring productivity down
    • Too Many Cooks – while lots of cooks are great, the work needs to be divided up among different type of cooks
    • Not Enough Pizza – when team suddenly increases in size, the team is in danger of losing cadence, shared understanding and focus
    • Tower of Babel – it is easy to assume took quickly that team members are speaking the same language
    • You Got Mail – teams can revert to email over collaboration. Geographically distributed teams can fall into delivery over collaboration
    • Inmates are Running the Asylum – when engineers drive the design
    • The Perfectionist – the tendency of perfectionist to not share their work till it is perfect
    • The Weakest Link – team members who aren’t up to working in a “lean” environment or no solid talent can really cause a team to stumble
    • The Wall -walls between teams can happen when tribes form, or seeing other teams as separate delivery factories or geo-distributed teams
    • Tangled up – when services and experienced are not separated with the technology stack, rapid progress is hindered


As I’ve mostly read, it seems that the Lean UX method is already what some UX people are doing. I for one have been doing it, not fully,  but I just didn’t call it by that name. It’s bootstrapping UX in a sense. Now that it has a name, the frontrunners of the idea might have created techniques and some best practices of doing Lean UX. I think that’s what I’m interested to learn about more. My hesitations on Lean UX (and this might be my misconception about it) is that I find Lean UX to be restricting on doing more thorough research prior to design (i.e. if thorough research is labeled under “Fat” UX).  When we want a good concept to begin with and not just a good user experience output, I think research is very important.  Nevertheless, I think Lean UX is an efficient way to develop and launch a product quickly to the market.









Leave a Reply