Is There Any Meat on This Lean UX Thing?

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

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

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

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

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.