Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Is There Any Meat on This Lean UX Thing?

by Jared M. Spool
on November 30, 2011

Out of nowhere, Lean UX is now a hot topic for UX professionals, generating the complete
range of responses, from complete buy-in to calling it complete bulls**t. Is there
really something to this? Or is it, as I’ve heard several times now, an attempt to rebrand
what we already do in the name of selling more workshops?

I was very curious about all this, so I set out to learn what Lean UX was all about. I’ve
talked to dozens of folks in all areas of the UX field and dug into what people mean when
they talk about it.

My conclusion: There really is something here. Lean UX is an important new way to think
about what we do, and I think there’s real meat on it. Let me explain.

Step Into the Wayback Machine, Sherman

To get a solid handle on why I think Lean UX is now important, we have to go way back into
the past—to the 1960s and 1970s. In those days, computers (albeit large mainframes)
were catching on. Businesses were using them for more and more functionality. They were
finding applications within all sorts of the enterprise.

However, as people found new uses, the size of the software projects grew. As those
projects grew, it became exponentially more difficult to deliver working code on
reasonable budgets.

To keep everything under control, the field of software engineering started to emerge and
one of its biggest contributions at that time was a management technique known as the
Software Development Life Cycle. The SDLC showed everyone a standard way of building large
applications, by dividing them into phases, each phase acting as a relay race, handing off
it’s deliverables to the next phase.

For these initial mainframe applications, the SDLC brought a ton of order to what
otherwise was a lot of chaos. It made delivering applications, especially big ones,

However, it didn’t take end-user needs into account and, frankly, it didn’t need to. In
those days, the end users weren’t consulted on what they wanted in the applications. The
only choice they had was to use the computer or to do the same work by hand. Every user
was trained (and often tested before hiring to discover if they were even competent enough
to use the software).

Since there was no need to accommodate the users’ needs, the SDLC pretty much ignored any
notion of what we’d today call design or user experience. It was simply not part of what
anyone thought about.

Fast Forward: The Business Takes Control

With the advent of the first mini-computers, then with the subsequent wave of the first
personal computers, businesses started taking more control over the software they were
receiving. They demanded features to make them more efficient and effective.

Unfortunately, the mainframe era’s SDLC didn’t take incremental feature improvements into
account. There was no idea of building forward-looking architectures that could
accommodate enhancements that weren’t even imagined at the initial creation. The IT
developers needed a new model to work from and what we now call the waterfall approach was

Waterfall took the phases of the SDLC and added the idea of requirements up front. Those
requirements would come from business analysts and subject matter experts, who would then
drive what the features would be all the way through the development process.

Moving from Hundreds to Millions

In the late 1970s and early 1980s, only the most popular applications broke the
thousand-user mark. Most applications only had, at most, hundreds of users. Because of
this, it was easy to figure out what those users needed. If the application was complex,
you could easily train those users on the operation. And because features took a long time
to build, that training would remain up-to-date for a long time.

However, as personal computing power really took over, the first million-user applications
arrived on the scene. More followed and soon it wasn’t unusual to be building software
with a ton of users.

Once again, the way we were building our applications was pushing the boundaries and chaos
was emerging. Finally, in 2001, the Agile Movement arose, to get things under control one
more time.

UX in the Waterfall World

For most applications, during the pre-Agile waterfall era, developers didn’t take users
into account beyond asking them what “requirements they had” for the features that the
team was building. Even then, the end users were rarely brought in, as the requirements
came from others in the process.

Yet there was a growing desire to do something better. GUI interfaces gave the developers
more power and users had more choices in tools. Suddenly, there was a demand for better

Waterfall, like its SDLC ancestor, didn’t know how to incorporate UX into the process.
However, its phases could accommodate a notion of design.

A UX practice emerged, one based on creating documents that detailed every idea of the
experience. This practice plugged into the waterfall design phase. To ensure that the
designers’ wishes would be carried into later stages, extensive documentation and
specifications were created. The goal was to eliminate any deviation during the
development process, by telling the developers exactly what we expect of them.

The Agile Tornado Uproots Waterfall UX Practices

Developers started rejecting the chaos coming out of waterfall method and many turned to
the growing Agile Movement to regain their control over the process. However, like its
ancestors, Agile also didn’t take UX into account. Several of the Agile methods, such as
Scrum and XP, recommended users sitting with the team during the development process, but
that isn’t the same as design.

Everyone who figured out how to get what they wanted from plugging UX into a phased
waterfall approach was now struggling to work inside the Agile methods. The Agile
principles, that focus more on communication and less on contracts, didn’t fit the status
quo UX processes.

Adapting UX Waterfall Into Agile Processes

There were many early attempts to adapt to the very iterative and experimental Agile
process, but most of them basically just created a design phase before the sprints kicked
in. It was tacking waterfall onto the front of the Agile process, which didn’t work.

The status quo UX process had two aspects that made it work well in the waterfall
environment. First, it knew the project’s objectives to stay the same from kickoff to
launch. The process was suited to defining things up front that would remain intact
through the development process.

Second, many of the aspects of the process were about creating a contract between the
designers and the developers. The developers were agreeing to implement what the designers
intended. The documentation and specification deliverables were there to ensure developers
knew exactly what they should do.

These two aspects of the waterfall UX process aren’t desirable for an Agile UX process. In
the Agile world, we don’t expect to predict the final design from the start. The entire
purpose of Agile’s rapid iterations are to explore what that design should be — what would
be best for the users and the business, by producing a series of experiments.

Similarly, when you’re iterating quickly, heavyweight deliverables, like specifications
and even wireframes, get in the way and slow you down. Rapid prototypes and team
discussion turn out to be more effective.

Retrofitting the waterfall UX process to Agile was doomed from the beginning. It’s a shame
we kept trying for as long as we did.

Lean UX: Redesigning UX from the Ground Up

If you think of UX in Agile as a question, then you can think of Lean UX as an answer.
What I’ve learned is the principles behind the new Lean UX movement are about taking the
best parts of our current UX practices and redesigning them specifically for use in an
Agile world.

It’s really not about what’s in Lean UX that’s interesting; it’s about what’s been left
out. Gone is the precept that the project objectives will stay the same and that you can
design for a single solution throughout the project. Gone is the need to create
heavyweight documentation because you have to set up a contract with the developers for
the phase handoff.

Jeff Gothelf told me that, at the core of Lean UX, you treat each design iteration as a hypothesis.

“You need to validate your hypothesis from a customer perspective and from a business
perspective,” Jeff told me. “You want to minimize the amount of time you’re pursuing the
wrong hypothesis. The more wrong paths you can figure out quickly, the sooner you’ll find
the right path.”

Following the Lean UX principles, you focus on iterating through the hypothesis. You think
you know what users want at the beginning, but by the end, you discover that they wanted
something different. Taking advantage of Agile’s fast iterations, you can quickly test
your hypotheses and get to a great design in the end.

To compensate for the absence of heavyweight deliverables, Lean UX works on team
collaboration. Lean UX methods involve the entire team as they are happening, with
constant discussion.

For example, when Twitter was redesigning their desktop experience, live usability tests
were projected on the wall of the development war room, as the developers were working.
When something interesting happened in the test, the user researcher (observing from the
war room), would say, “Hey everyone, you need to see what’s happening here.” Real time
user research is a component of a Lean UX process.

The Beauty Is There’s Nothing New Here

What makes Lean UX most interesting is that it’s built from well-understood UX practices.
Nothing in what I’ve seen about Lean UX is new.

In fact, it’s very reminiscent of what we were doing in the 1990s. We made a lot of
headway teaching techniques like discount usability testing and paper prototyping back
then, but then the results were always packaged up for the end-of-phase contracts that
waterfall demanded. Those same techniques now have a comfortable home in Lean UX and
dovetail nicely with the Lean UX practice.

You can think of it another way: Lean UX is just UX. But UX isn’t always Lean UX.

There’s definitely meat in the Lean UX world. If you’re not paying attention, you should

Correction: The original version of this article incorrectly stated that Jeff Gothelf coined the term Lean UX. It was coined by Janice Fraser of LUXr. We apologize for the mistake.

Want to know more about Lean UX?

We’ve invited Jeff Gothelf (who
coined the term Lean UX) to talk about how he’s using it to get his company, The Ladders,
out of the deliverables business. If you’re working in Agile or another fast-moving
environment and want to know core essential techniques for good design, you won’t
want to miss this virtual seminar. Read the details.

Share Your Thoughts with Us

What’s your take on Lean UX? Is it something you’ve been working with? How has it helped you? Share your thoughts on our Brain Sparks blog.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.