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.
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.