Agile UX vs Lean UX – How they’re different and why it matters for UX designers

I’ve seen a lot of discussion recently on what the difference is between Agile UX and Lean UX. I am happy to plead guilty to having used these terms interchangeably, as it would seem they are both talking about a more light-weight and iterative UX practice. But when I was recently asked to participate in a Lean UX Roundtable panel, I thought it would be a good opportunity to show that they, in my opinion, really are not the same.

Here’s the slide I used in explaining how they’re different (I’ve added the complete deck below):

Explaining the relationship and differences between Traditional, Agile, and Lean UX

Traditional UX – it’s not like it suddenly vanished

I think it’s easy to think that just because you are adopting an Agile and/or Lean approach to your UX practice, that all the traditional UX practices and principles suddenly somehow vanish. Nothing could be further from the truth. As experience quality becomes an evermore critical factor in product success (ie. if you have 10 apps to choose from that basically all have the same features, which one do you think people will pick?), everything that UX designers have been hemming and hawing about for eons (ahem) about usability and good design principles is as important as ever.  Good design is good design, regardless of if we are living in an Agile or Lean or [insert new term] universe. The only real difference when adopting these methods is in the How, which is what Agile and Lean UX are all about.

Agile UX – Collaboration and Delivery

Agile was created by enterprise developers and looks at the software product from a developer perspective, similarly to how someone working in a restaurant kitchen looks at the restaurant at large. It’s not that the stuff going on in the front of the house, the experience part of the restaurant, isn’t seen as important, it just isn’t the primary focus.  Furthermore, in the enterprise world of old, which was a primary focus of Agile, software products were more akin to an institutional cafeteria anyway, ie highly utilitarian systems where the focus is on delivering the required features rather than a great user experience.  As Ward Cunningham, one of the original signatories of the Agile Manifesto, once said at an Agile UX retreat at Cooper, “Agile is hot food served quickly.”

Ultimately, Agile is about high-quality high-velocity delivery of working software.  In the Agile universe, that is the ultimate measure of progress.  However, a funny thing happened on the way to that Agile Manifesto.  Making great software quickly, it turns out, requires collaborating really effectively with pesky non-binary entities called people.  While basically silent about UX design, Agile thinking offers a fundamental paradigm shift about how to interact and communicate with the people on your team and beyond.

So, while there certainly is a lot that UX designers can learn from Agile thinking on software delivery (such as to automate everything that can be automated), the real pay-off for UX practitioners is in the collaboration part.  Agile UX methods, like Design Studio and Cross-Functional Pairing, help UX practitioners replace slow documents with fast and effective direct interaction.  An Agile UX practice, in other words, replaces document-centered practice with one that is collaboration-centered.  This is a very big deal for UX designers working on Agile teams, because it is this shift that is key in allowing them to integrate their practice with Agile Developers.

Lean (Startup) UX – Measuring and Validating Product/Market Fit

Cool, so now we’ve got this great Agile machine allowing us to be crazy-efficient in shipping software.  But, um, did anyone check to see if we are shipping the right software?  A Lean UX approach shows us that shipping, which basically is the big honkin’ Done in the Agile world, is in fact really only the beginning.  While Agile methods help UX designers turn old ways of designing and communicating on their head, Lean UX helps us overturn old approaches to research and measuring quality.

In a traditional model, research is something you do before starting to create the product, to figure out what the product is that you are going to build.  In a Lean approach, we are continuously building and gathering metrics about what we have built.  The most archetypal example of this is the metrics-gathering landing page, which is created and launched at the very outset of the project, rather than soon before the “finished” product is about to be released.  We turn what was once just seen as marketing fluff into an actual experiment of our hypothesis that others will think our idea is as great as we think it is.  Then, the metrics gathered from that landing page (or it can evolve into a full-fledged metrics-gathering website) are fed back into the product design.

But a landing page is just one of any number of ways one can apply Lean UX.  Another common pattern is to create a simple prototype and GOOB! or “Get Out of the Building!”  Many UX designers give lip-service to the idea of User-Centered Design, but don’t actually spend a lot of face-time with real users.  Regardless if they do, GOOBing both rebrands and reshapes the idea of UCD and also gives UX designers a nice kick in the butt to get out of their cozy cubicles and offices and actually take their ideas to where the users are.

We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process.  While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building, and it is easy to see how these two are very much intertwined.  Like with Agile UX, it allows for much more easily integrating research with how Agile teams work, since it is continuous and not up-front.

One more thing about Lean UX: I think it’s kinda’ confusing.  The term “Lean” has its origins in Lean Manufacturing and refers to the practice of minimizing waste and maximizing flow, which, in turn, is a cornerstone of Agile methods.  Lean UX, on the other hand, is really a reference to Lean Startup a la Eric Ries (and Steve Blank, basically the godfather of Lean Startup, and creator of concepts like Customer Development and Getting Out of the Building), which extends Agile ideas to include methods for ensuring that there in fact is a market for the product you are doing such a good job designing and shipping early and often.

Bottom line: in everyday conversation, whether one uses the term Lean or Agile or what-not is probably not important.  What’s more important is an understanding of how Agile and Lean help make traditional UX a more whole practice.

Oh, and here is the complete deck from my 10-minute opening talk at the Lean UX Roundtable Panel:

265 thoughts on “Agile UX vs Lean UX – How they’re different and why it matters for UX designers

  1. Pingback: Quora

  2. John Hunter

    Lean is also very concerned with customer value http://curiouscat.com/management/voiceofthecustomer.cfm From that perspective usability is directly relevant and fits perfectly in the lean context. Lean focused on the ideas of usability for customers in the world of physical products. Usability of software fits with this perfectly.

    The focus of reducing waste in lean context is to look at the “value chain” and eliminate what doesn’t add value to the customer. The primacy of user is there (though some applying lean don’t understand this).

    Dr. Deming said the customer is the most important part of the production line. He understood the customer (end user) had to be the focus of your efforts to improve. Toyota took Deming’s ideas and create the Toyota Production System, which is what was name “lean manufacturing.”

  3. Pingback: Tweet-Parade (no.19 May 2012) | gonzoblog.nl

  4. Ross Williams

    Great article – and its becoming an increasing thorny issue between being free at the conceptualisation level to create and communicate information on a level I want to – without having to have already locked into traditional UX deliverables. Would love to know your thoughts on a post I wrote http://tinyurl.com/bp5kq96

  5. John McFarlane

    Its quite a lot to juggle now when you stop and think about it, to combine agile development with customer development and UX into that. Its requiring a huge amount of reading by myself, i feel its worth it though.

  6. Pingback: Vattenfallsträsket del 2 – Jakten på korrekta estimat « Helt Sonika

  7. Pingback: Prezentacja – Lean UX Anti-Patterns « UX Labs - nieregularne ?ród?o wiedzy o user experience

  8. Pingback: Just another Agile UX post

  9. Matthew Hodgson

    Nice article Anders.

    I’d disagree, though, when you suggest that “Agile was created by developers for developers to solve developer problems”. This is because agile methods go back much further than the agile manifesto (creaed only 10 years ago). Many agile methods, like Scrum, are product focussed (of which software would be considered a product). Today there are records of Scrum used to produce financial products, Internet products, and medical products by ADM.

    So long as the UX community considers Agile to be a “software thing” we’re going to miss the opportunity (as you rightly infer) to take part in its collaborative aspects and, together, produce amazing products.

    M

    1. Anders Post author

      Hi Matthew – thanks for your thoughts. The reason I’m saying Agjle was created by devs for devs to solve their own problems is, quite simply, because the 17 people who participated in authoring the Agile Manifesto were all developers, or software development consultants.

      Now, the fact that they are focused on solving their own problems doesn’t mean that other problems don’t get solved as well. They way I like to explain it is to use a restaurant as a metaphor for a software product. Agile methods are all about how to make an ultra-efficient and successful kitchen. Factors that determine the success of a kitchen include: quality, consistency, and velocity. Sound familiar?

      But the success of the restaurant as a whole is also determined by the quality of the dining room, in which a completely different set of factors rule the game, such as ambiance, aesthetics, the tactfulness of the wait staff, and all kinds of other fuzzy variables, for which methods like Scrum or XP offer little support. That is not to say that the staff in the kitchen don’t care about what goes on in the front of the house; it is just not something they are focused on. The same is true for Agile methods like Scrum. Of course the overarching goal is product success, but Scrum will only allow you to deliver a quality product on a frequent basis. Whether or not that product is usable, useful, or successful is a different story.

  10. Pingback: UX in Agile environment - Roger TSAI

  11. Pingback: Agile UX vs Lean UX

  12. Pingback: Agile Lean UX: Achilles’ Heel or Trojan Horse for Competitive Advantage? | TheLadders Blog

  13. Suzanne

    Interesting post. There’s clearly a lot of confusion around the two terms. Playing devil’s advocate, who cares how the design team gets to the best experience as long as the experience is compelling and satisfying?

    I work at a B2B company that is focused on bringing the best possible experience to our users, agnostic of the dev/design methodology. We happen to build software per the Scrum process with multiple Agile dev teams and a UX designer per team. For each feature we build, we embark upon a brief period of customer discovery / research, which I believe would be described as “Lean” under this post’s definition, followed by rapid iterative sprints where we test and refine our hypotheses, which perhaps the author would describe as “Agile.” We schedule meetings with three users each week to facilitate both types of interaction.

    My question is, why these carefully nuanced buzzwords? At my company, we happen to describe the customer discovery portion of the journey as “visioning” and the rapid iteration piece as “validation.” Same users, different stage. Visioning requires that UX and Product work a bit ahead of the agile team; it’s broad and aims to get users to help us identify and remove giant boulders from the road. Validation happens in-sprint; it keeps us on the right path during development (as guided by the vision) and kicks aside any smaller rocks and stones that might turn up. It’s a nice progression from broad to narrow that doesn’t seem to require comany-wide adoption of lesser-known concepts,

    Put simply, the common ground between what my company calls visioning / validation and this post calls Lean / Agile is regular, repeated interactions with users. If UX practitioners just insisted on talking to users constantly, maybe it wouldn’t matter what methodology they were using. In other words, if you don’t go too long before you make sure what you’re building will satisfy your customers’ needs, happy days!

    P.S. UX is a goal, not a process, so what if we separated out the methodology (lean/agile) from the result (user experience) when we discussed this stuff? i.e. Iterative Design rather than Lean UX.

  14. Pingback: Lean UX med effektkartan « Helt Sonika

  15. Charles Lambdin

    But it’s not just that people are confusing the two terms. Even the experts in the movement use the terms practically interchangeably. Jeff Gothelf calls his approach ‘Lean UX’ and InContext Design experts such as Hugh Beyer call theirs ‘User-Centered Agile,’ when they are more or less describing the exact same process. Also, I would recommend Craig Larman’s book for the history of Agile. He points out that Agile qua Agile has actually been around since the 1930s or so and that ‘modern Agile’ is really just a reaction against Waterfall and an attempt to slay that beast.

  16. Michael_emmett

    A couple thoughts on this:
    - The Venn diagram is a rather confusing way to present these three approaches to UX. The Venn implies that the intersection of the three is the ideal… well… something (UX should be capable of bringing all 3 “skills”?).
    - Traditional UX and concepts of User Centered Design are more than usability and design principles and has always embraced the “How do we make it”. The Lean/Agile approaches have a lot to offer UX as a practice, but it’s misleading to say that Traditional UX hasn’t involved the “How”.
    - The UX (and product team) world seems to be rushing towards a metric-driven design methodology as a “way to build the right product”. This turns its back on the role of UX at helping ask the “right questions” through different methodologies. Do you want to “prove” that one iteration of the product is better than the previous? Metric-based design is perfect. But do you want to explore and validate whether or not there is a completely new set of latent requirements out there? Or an innovative way of delivering the same solution? Breakthrough designs that takes you to another level? Then don’t pin your hopes on Lean (Startup) UX and A/B testing. You need a broader set of customer and market inputs (via different research methodologies) that UX teams are (hopefully) trained to collect, interpret and turn into product UI. Joshua Porter’s presentation here http://www.slideshare.net/andrew_null/metrics-driven-design-by-joshua-porter explains the problems of metric-driven design, look for the slide titled “Imagie your design is a mountain”

  17. Pingback: Interesting workshop/talk about agile ux « linabanina

  18. Pingback: Agile UX och Lean UX tar över projektgrupperna | MKSE.com - All about CMS

  19. Pingback: Agile UX vs Lean UX | sameer halai

  20. Pingback: Why Agile UX in 2013?

  21. Pingback: Episode 18: James and Per satisfy their clients - UX Podcast

  22. Pingback: Lean UX Thinking and Agile development | UX & Design

  23. Pingback: mcgregoronline » Agile is wrong for UX?

  24. Pingback: Visiones sesgadas de la Experiencia de Usuario - Guindo

  25. Pingback: Visiones sesgadas de la Experiencia de Usuario « Mosaic

  26. Pingback: Agile UX vs Lean UX: How they’re different and why it matters for UX designers | We Love Lean – Lean startups, design, happiness and everything in between

Comments are closed.