Lean UX Is Not Anti-deliverable

A lot of people now consider Lean UX to be solely a tactical “anti-deliverables” practice that seeks to reduce the number of wireframes and spec pages. While they are partly right, they are mostly wrong. Let me debunk some of the myths.

Debunking Lean UX Myths

A lot of people have an opinion about Lean UX. Some are based on knowledge and facts, while others seem to appear out of the blue. In this series Jeff Gothelf debunks some of the myths.

See all posts

Related posts:

Reducing deliverables is only one relatively small benefit of shifting our mindset away from traditional UX practices and thinking “lean.” Some of the most ardent promoters of thinking lean, towards UX and other disciplines, are practitioners outside of the UX world. The cross-functional collaboration, constant communication streams and customer-validated learnings that Lean UX provides broadens the impact that UX has on an organization. It does so tactically but even more so strategically. Lean UX opens up the discipline and invites others in to engage and educate them in all the good, bad and ugly twists the UX discipline goes through to arrive at viable solutions.

In his recent post “Lean UX is Dead. Long Live Lean UX.” Greg Laugero noted, “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.” Let me be very clear: Lean UX is not “anti-deliverables.” It is a refocusing of UX efforts away from the documentation for which we’ve become known inside and outside organizations. It moves towards validating product hypotheses that relieve the organization of wasteful practices that include designing and building products and features customers don’t actually want. We achieve this by creating interactive experiences – the ultimate manifestation of our work – earlier and more quickly. Inevitably, as Laugero notes, we will have to create artifacts along the way. The focus should still be to design the best experience while minimizing the amount of time designing the wrong ones — not to design documentation that describes these design hypotheses.

We all face many challenges to successful team collaboration including working with distributed teams. Testing and communication to distributed teams requires different types of communication. However by facilitating these communications through regularly cadenced, cross-functional conversations, the depth and complexity of the documentation you’ll need to create will be diminished. Subsequently, any rework of that documentation will also be diminished. This is the waste that is being removed.

———–
Thumb image NC-BY-2.0 by juhansonin

Jeff Gothelf

Jeff Gothelf has spent a 14 year career as an interaction designer, Agile practitioner, user experience team leader and blogger. He is one of the founding partners of Proof and one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the upcoming O'Reilly book (2012), Lean UX: Getting Out of the Deliverables Business.

8 comments on this article

  1. Nick Eubanks on

    “The focus should still be to design the best experience while minimizing the amount of time designing the wrong ones — not to design documentation that describes these design hypotheses.” This is the single most frustrating aspect of working with people or teams that are not keen to the value of delivering UX as a form of problem solving. Open and consistent communication is the most efficient way to inform all stakeholders and reduce the need (and hopefully requirement) for documentation. Cheers!

  2. Pieter Jongerius on

    Hi Jeff, great post!
    Try this: all design is documentation. Just a very expensive way of telling others or yourself what the /product/ should be like :-)

    That said, it just so happens that I wrote a book on Agile UX, design & development (for which, btw, also the big kahuna Jeroen van Geel has written a very nice chapter. :-)
    It will be published late summer.

    I’ll paste in a shortened fragment on documentation, that gives our nuanced view on documentation in Agile UX, more specifically Scrum:

    “Eliminate waste” is the first principle of Lean software development, and Scrum has borrowed many of its principles. But is documentation “waste”? Sometimes it is, but not always. Ask yourself what the purpose of the documentation is, and take a different approach to each type:
    1. Documentation used to establish project preparation, such as program of requirements, negotiated business rules, sitemap. You must be very careful with these documents. They are typical waterfall documents. A sitemap is only useful if you’re prepared to adjust it as more insight is gained.
    2. Documentation used to guide design & development on a continuous basis, such as brand values, user insights, a product statement, coding guidelines-—this is what you need. Use PowerPoint style not reams of text, so it can be displayed on the wall and seen from a distance. Remember, nobody will look at documentation that’s put into a folder on a server. Waste of energy!
    3. Documentation used to transfer knowledge among various disciplines-—flows, wireframes, and PoRs-—are rarely needed when team members work together in the same room. Usually a simple sketch or a quick one on one is all it takes to run through a story. We believe that only very complex functions or interactions need to be specified and worked out on a computer.
    4. Documentation for comprehending the project at a later stage—such as an editorial guide for when the project has gone live, a corporate identity manual, description of important technical preferences. This kind of documentation is essential. It is an intrinsic part of your product. Provide something tangible—not just an email with attachments.

    – I’d be happy to hear your thoughts!
    Pieter

  3. Matthias Schreck on

    Great post, and spot on, I believe. Having worked in various large organisations as a UX professional, it seemed to be part of the UX mind set to not only create deliverables as outcomes and recommendations, but also to point out exactly how much the UX professional had done to arrive at these recommendations. This is what really annoys me with a lot of UX people:they spend so much time on explaining their process and the structure of their own work, completely ignoring the fact that in a good team, other team members trust them and their processes and don’t have to be told about every step on the way. This is one of the reasons why these deliverables get inflated so much.
    My other frustration is the delivery of ‘dead’ documents, where UX people ignore shifting goal posts and changing circumstances (like new technical limitations) and stick to their one-off recommendations. In a lean environment, use one lean deliverable and build on it and adjust it as you go along with the rest of the team.

    It’s one of the major challenges of UX as a professional field to pull people out of those outdated mindsets.

  4. Vesa M on

    Let me add to the subject of documentation: the border is vague between the documents you create for your self to process things and documents you create to communicate.

    You will need some format to process your thoughts to get things going. Many times (some of) that stuff gets in to the communication documents. I was in a project that had a leader who wanted to cut out **all** the waste. That included all stuff that looked too much like something presented in a formal waterfall documentation. And it did not work out.

  5. Pingback: Why have you not written anything here in 2 months? | Perception Is The Experience

  6. Eric Reiss on

    Great article, Jeff. I wish, though, that you’d summarized the key features of LEAN, as I think many readers are unfamiliar with these, treating the concept like all the other cool buzzwords that come along.

    There are three key concepts, as defined by Toyota (who pioneered this concept):

    muda = elimination of fluctuation (e.g. quality)
    muri = eliminating unreasonable work (planning)
    mura = reactive elimination of causes

    What we should be considering is what kinds of deliverables we are creating and WHY in relation to these three issues.

    Are we proving we did the work? (documentation)
    Are we communicating an idea to others (specifications)
    Are we just showing off (complicated but meaningless spreadsheets, graphs, journey maps, and such)

    Anything in the third category should be eliminated. And a lot of stuff in the first category should probably die a death, too. The proof should be in the results, not the process description – when I write a book, the value lies in the finished book, not my journal.

  7. Michael Griffith on

    Great thoughts Jeff.
    For me, the greatest thing about a lean approach is that it forces us to think about the things Eric mentions in his comment. Why are we doing what we do and does it make sense. It breaks the dogmatic adherence to a process or production of a deliverable.
    So, my greatest fear is that as Lean UX gains more traction, the human tendency will be to turn the approach into a process, then a methodology and ultimately a dogmatic activity. Back where we started.
    Let’s fight to keep it about smartly doing the right thing at the right time in a way that keeps things moving the project forward.

  8. Adam Polansky on

    Thanks for the post!

    It seems inevitable that any approach predicated on assessment prior to outlining some sort of roadmap is greeted with an oversimplification skewed toward a polar extreme. We all heard the same thing in Agile when “avoiding needless documentation” was interpreted by some as “avoiding documentation”.

    I agree that over the years, we’ve become our own worst enemy in terms of the general perception of UX in the mix; over-thinking, dogmatic obedience to a prescriptive approach and more than a little superiorism breeds a backlash that get’s the baby thrown-out with the bathwater.

    What has never changed is the fact that we have to demonstrate our value in practice to be credible. In the absence of being able to provide algorithmic predictions to revenue increases or cost savings, trust is how we gain leverage. When you can deliver solutions that show active consideration of business and technical constraints and how that consideration translates into visible decisions about both what TO do and what NOT to do, you break-down the bad perceptions.

    “Let us train our minds to desire what the situation demands.” – Seneca