Lean UX Is Dead. Long Live Lean UX.

If we’re going to get pumped up about a new method, then let’s get pumped up for the right reasons. Lean UX isn’t about a new way to just make stuff and avoid deliverables. It’s about a new way to be strategic actors in our organizations.

Related posts:

Don’t get me wrong. I like Lean UX. It’s pioneered by people whose work and writings I’ve found to be very influential in my own career. It’s about time we focus less on the beauty of our deliverables and more on how we create value for our organizations.

The problem, for me, is this: It is becoming just another way for UXers to talk to ourselves about ourselves, and in the process continues to position UX as a tactical discipline with little strategic value.

At its best, it challenges us to bring a “think-make-check” discipline to our projects, thus transforming how our organizations create valuable digital products. As such it is a key part of formulating product strategy. At its worst, it indulges our laziest propensities and reduces creativity to pure production (see David Malouf on The Corruption of Making in Design for an eloquent take on this). To me, there’s way more promise in the former.

In this discussion, I’d like to explore how Lean UX gets us closer to being strategic actors not just more efficient and productive bit players.

The purely tactical

Here’s the stuff that for me is purely tactical, of little long-term consequence, and least compelling; yet these ideas have good traction within our discipline and often dominate our thinking of Lean UX.

Deliverables and documentation don’t matter anymore

Some tendencies within Lean UX treat deliverables and documentation as the equivalent of clerical work, or worse as “waste.” To me, systems with any strategic value to our organizations require you to think through complex user stories. This will require some thought experiments, many of which need to be written down and shared with others who are not part of the small, co-located team. I have to agree with Austin Govella: “Deliverables are not the problem. User experience practitioners are not in the deliverables business. We’re in the business of finding and evaluating problems and solutions.” Sometimes it takes deliverables to facilitate the thinking process.

Further, anyone who has needed to communicate design decisions for a complex set of use cases to a team that is not co-located with you knows that you have to document what is going on. The fact of the matter is that you’re going to do it anyhow. Questions will arise about what happens under different use cases. If you haven’t documented these, then you’ll either miss them in your design (and have to rework), or you’ll end up communicating your assumptions in writing — probably via the ephemeral medium of email — when questions inevitably arise. Just do it formally and get it over with. The extended team will thank you when it comes time for testing. (Yeah, that still needs to be done.)

Prototypes communicate everything

“The prototype now become[s] your documentation. It is ‘the Spec.’ Very little if anything more is needed” (Lean UX: Getting Out of the Deliverables Business). A prototype can be many things, but the complete specification is impossible (unless you’ve embedded notes in it, or you’ve hooked it up to a fully representative database). If the prototype communicates everything, then it is–by definition–the product. You haven’t built a prototype; you built the thing itself. Prototypes work well for getting stakeholders to remember requirements that they “forgot.” They work well to test with users when lower fidelity deliverables won’t do it. They work well to communicate to developers how transitions between screens work. But a prototype can’t, by its nature, cover all use cases. You’re going to need to document the exceptions not covered in the prototype.

Waste is the thing to be avoided

It’s not all about production. To arrive at what is truly valuable, you need to overproduce and throw stuff away. You learn from “waste”. Thought experiments that seriously and honestly engage a complex problem are not waste when they fail. They teach you something about the right solution. That’s not waste. Documentation that helps an offshore development team efficiently turn around code is not waste. It may seem like waste to those who think documentation is “boring” or clerical. But it isn’t waste. Get over it; write it down. The prototype and your sketches are not covering everything.

What’s Old Is New Again

Finally, much of what passes for Lean UX isn’t new, which is why so many UXers claim to have been doing it all along without realizing their business-as-usual approach needed a(nother) brand name. (Check out this blog post.) Anyone who has done a clickable prototype to test some assumptions with real users was doing it. (See @DesignStaff’s recent post, which doesn’t mention Lean UX but makes a compelling case for a UX technique that has existed well before we embraced the “lean” label.)

All that aside, I do like Lean UX

Here’s what makes the most sense to me, and what I have found truly transformational in my own practice no matter the size and complexity of the project.

Business-savvy design

Good, business-savvy design has always been about systematically finding the core features that matter most to users – no more, no less – and finding them at the cheapest possible cost. Design is almost always a process of trying to identify what is really valuable to users and what is less important. Doing it systematically is smart business and good design. Lean UX in this sense is good business..

Moving as quickly as possible through the “think-make-check” loop

Giving yourself time to think about the problem you’re trying to solve is important. But don’t assume you’re right. Spend your “thinking time” figuring out what you need to learn and what you can build to get the right answers. This is the work of a UX strategist. Writing down hypotheses and describing how you’ll validate them is hard work that is valuable whether you’re consciously doing “lean” or not. Some of those hypotheses will not be strictly related to UX. Some of them may go the heart of the overall Customer Experience your organization is trying to create. Knowing when your invalidated hypothesis is more than a system issue is an important strategic skill. You’re going to need to communicate that — with a deliverable, in writing.

Creating the most effective, least-cost deliverables to yield “validated learning”

The “Minimum Viable Product” (MVP) concept is central to Lean Startups and Lean UX. Though it is often confusing, it’s valuable. Designing just enough to deliver value and learn what to do next is also smart business and good design. As a discipline, we UXers don’t typically think too much about cost and benefits. We’re not typically held accountable to profits-and-losses. But MVP’s are a good discipline for us — they make us think about how to cost effectively make good decisions. They reduce product strategy to its fundamentals — what features move the business forward, fastest. That’s not typically the way we think.

These are the parts that I find useful and valuable no matter the size of the project. Whether it’s a startup or a large organization, there is always uncertainty and the opportunity for validated learning. Lean UX gives you a way to systematically deal with the uncertainty.

More important for UXers, it gets us closer to product strategy. Focusing on cost-effective ways to reach a market, creating a competitive differentiator, introducing a true innovation, or discovering that your company’s assumptions about its customers are wrong — these are strategic outcomes that will require deliverables beyond prototypes. Those deliverables (formal or informal) are where the strategic thinking gets done and communicated. Don’t give them up to someone else. Relegating ourselves to pure production is to further constrain the UX discipline as a subset of IT. That’s not where, I think, we want to be.

Greg Laugero

Greg Laugero is a digital product strategist and Co-Founder of Industrial Wisdom. He helps companies turn their ideas into real products with great user experiences. You can follow him on twitter: @prodctstrategy.

11 comments on this article

  1. Nathaniel on

    Just wondering… why can’t a prototype cover all cases? that would really depend on how comprehensive the prototype is.

    But I do agree that there should be notes/interaction rules in context with the prototype, the main thing is making it understandable for the team to build it, as opposed to a big ol’ spec document.

  2. Greg on

    Nathaniel — Thanks for the feedback. It depends, as you say, on how comprehensive the prototype is. I think of prototypes as demonstrating the major application functionality — especially the transitions from one screen to another. You identify the user stories you will cover and build to those. The prototype can cover all cases if the cases are relatively simple. That doesn’t happen too much in my world.

    Even if it does cover all cases, then the development team will need some way to “discover” all of the cases and how they play out in the prototype. Without some documentation that explicitly ties the prototype to the user stories, it seems like we’re leaving a lot of room for error and rework — especially if the development team is offshore.

    That said, you’re right that the issue is to “make it understandable for the team to build” and I equally resist the notion of giant spec documents, which we know that no one reads, yet they are required to sign off on them. There is a middle ground that applies in the majority of situations.

  3. Lis Hubert on

    I could not agree more with this article. Fantastic piece!

  4. Kate Williamson on

    I love your comment that we “learn from the waste.” I can’t wrap my mind around the ideology that anything not used in the end development is not valuable. The “waste” helps us communicate and think through the problems we’re trying to solve. Thanks for this great breakdown of the tactical ideas.

  5. Pingback: What To Use Prototypes For | Project Wolverine

  6. Andrew Mottaz on

    Greg – great point about the prototype — it’s not at all clear that even a complete prototype where all of the functionality was completely implemented could be used by developers to implement effectively ( I’ve seen this in real life where prototyped behavior was not discovered ) . Prototypes can be used to iterate and discover, and you should only prototype what you need to to get your point across. I saw Jeff Goethelt speak yesterday, and I think what Agile and Lean have in common is that you need to validate your hypotheses with users, and that both developers and UXers need a shared understanding. Giant spec docs don’t solve this. Pixel perfect prototypes dont’ solve this. Only studying and solving the users problems together ( of otherwise communicating these things ) can give UX’ers and developers that shared understanding.

  7. Pingback: Collaboration for UX Teams | Wireframing Tool - ProtoShare

  8. Damon on

    Frankly, I think Lean UX is just a workshop buzzword. It’s agile. It’s just agile. There’s nothing new here. If you’re UX shop wasn’t validating design hypothesis to begin with, it wasn’t doing UX, it was doing pure design. The whole Lean UX concept feels like it came out of a company that didn’t understand agile, figured it out, and then someone thought “wow, look at this cool new thing I figured out” without realizing that they’re just rebranding something that’s been around for a while.

  9. Matthew Hodgson on

    @Kate: If gaining knowledge and insight that is shared with the team which results in the end-product being better, then it isn’t waste insofar as Lean is concerned. That is where Lean differs from other process engineering methods that look purely at the mechanics of the process.

    The question inferred by @greg in his article is only whether you’re creating artefacts just to create artefacts. Knowledge theory tells us that only a small % of knowledge can be transferred by documentation. The rest of it is embedded in shared experiences. Given this, we should always be questioning how valuable a UX artefact is likely to be before we create it. It means that collaborative workshops with the team, end-users, and others, or collaboratively prototyping a solution until the team gets the gist of the intent of your designs, are likely to be far less wasteful than making a beautifully detailed prototype.

    M

  10. mary on

    I’ve been really annoyed with recent articles on Lean UX because it misses many of the great points you’ve brought up here (specifically the Smashing Mag article you referenced). The idea of “waste” is ridiculous. Would anyone in their right mind consider the architect’s original blueprint a waste simply because it wasn’t incorporated into the actual physical building as material? Of course not!

    To lump design thinking and its output as “waste” only goes to subvert our own hard-earned experiences as UX designers because it sends the message that you are only as good/useful as your final documentation. If it wasn’t useful, of course it is waste, but that just also means that you failed in your COMMUNICATION of the concept in the first place. The documentation only serves as a reminder; it is not the end-all. You must still communicate with your stakeholders and developers throughout. It’s not a throw-it-over-the-fence mentality. So let’s not confuse the PROCESS that led you to your insights (and you are documenting whether you are doing it on a napkin or in Word, for the record) as being “waste”. This is like saying your vacation photos are a waste. They are not (unless you had a crappy vacation); they are only a reminder of what happened. Their worth is defined by what you put into it.

    It is also a fallacy of the inexperienced. Maybe this works for small organizations or start-ups, but work for a large company for a while (and through multiple versions of product) and you soon see that documentation is not the enemy.

    Sorry for the rant, but ughhhh… I’m so tired of this repackaging old concepts as new and slapping a new label on it and everyone without understanding it cheering in the streets like mindless drones (you can be excused if you are new to the industry, but everyone else, no excuse).

    That said, I’m all for this. It’s what we’ve been (or should have been) doing all along. So here’s to the old. Cheers!

  11. Pingback: UIUConnect » Understanding Lean UX