Lean User Experience, or Lean UX, is a software development discipline that can be a game changer for Web and mobile applications. The goal is to get digital products to market quickly after an idea is born, without compromising design quality.
Lean UX is based on a model in which the project leader, whom I'll call the Lean UX designer, must work with designers and developers, rather than relying on the traditional waterfall model in which the UX professional is in charge of finding all pieces of the solution and getting the client's approval before development starts.
This article examines how Lean UX works and provides pointers on using the technique to improve the agile development of an interactive experience.
The User Experience
There has been a lot of discussion about the formal definition of UX and how it works. Lean UX designers (sometimes referred to as product stewards) are responsible for creating interaction models that improve the user's experience. They ensure that designers and developers work in tandem to amplify the UX based on the business vision.
The word "lean" in Lean UX can be misleading and is incorrectly associated with using a shallow approach that seeks to speed software development at the expense of user-centered design and design fine tuning. The term is borrowed from Eric Ries's book, The Lean Startup, where it refers to the principles first enunciated in the now-famous Toyota Production System. (Toyota revolutionized manufacturing by introducing process changes that simultaneously increased value and reduced waste. Some elements of Toyota's approach have recently been rediscovered in software development with the emergence of lean IT and lean software development, both evolutions of agile methodologies.)
The blogger Luxr coined the term Lean UX, defining it as "a cross-functional, principle-driven process characterized by rituals that predispose teams to high-quality, high-velocity user experience outcomes." While "quality" is self-explanatory, "velocity" in agile methodologies is a measure of a team's productivity and should be maximized at all times.
The exact definition of Lean UX isn't terribly formalized. If you're following Lean principles when implementing your UX strategy and depending on a lean, agile development process, then you're doing Lean UX. So even if you aren't strictly following the Lean UX requirements, you're still moving toward a leaner UX development process.
A New Way Of Thinking
Lean UX is a disruptive approach to traditional software development with its discovery, design, development, and deploy steps and waterfall transitions. In the traditional model, steps occur sequentially, with a handoff from one team to another at the end of each.
Lean UX breaks up the traditional sequential approach. Designers — including Information architects, interaction designers, UI designers, and UX designers — work beside developers as a solution-finding team. This is the main difference between Lean UX and the traditional model.
In the traditional approach, all the specifications of the UX — site maps, wireframes, flow diagrams, content inventory, taxonomies, and mockups — are the final result of the design phase. In Lean UX, these specs are discussed and laid out throughout the process, and emphasis is on the deliverables needed for each step of the process. Several years ago, my company, which does software and UX development, made a big transition from the Rational Unified Process (RUP) to an agile methodology (scrum). We went from a heavy, documentation-driven process to a lightly documented, dynamic one.
Over the past three years, we took the next step: integrating the full UX and software process. We're now moving toward implementing Lean UX, focusing first on our mobile services team (see Figure 1.)
Traditional Development
The reality in the vast majority of projects being carried out every day is that companies still favor the waterfall model.
For example, let's assume you've already completed the discovery phase, since that's typically necessary before you decide that you even have a project. You probably had business, product, and marketing managers participate in idea-generating sessions that produced an awesome briefing document about your product. The document represents the business vision of the idea, but not the visual formats that make it easy for people to buy into the idea.
This leads to the design phase, which has many steps, including turning the briefing document into a formal requirements document, getting approvals, transforming the requirements document into high-level site maps and wireframes. Then, after further approvals, you design the implementations in more detail, get more approvals, and after several cycles of refinement, you end up with a spec containing a large amount of detail.
After several months of work, it's time for the development team to bring the design to life. You hand it off to the brightest engineers you can find who make it look and work exactly the way it was designed to. So far, it's mostly waterfall.
Now you're at the development stage, and perhaps you have a great agile team at your disposal. One good approach is for them to go through the specs and prepare a product backlog (that is, a collection of user stories) to be implemented. This process involves software architects for feasibility analysis. Work with them to do value engineering to prioritize stories in sprints, interact daily with a product owner, develop the stories, do demo meetings of workable software at the end of each sprint, rework the changes, and move on to other user stories. Remember to get back to anything that was identified as missing. And, finally, deliver an awesome product that may, or may not, look exactly as it was designed originally, but it works.
Some people will do usability tests in between the design and development phases but not using real workable software because, obviously, they don't have it yet. In any case, the best thing to do is to collect data, learn from user behavior, and iterate, changing what didn't work and exploring what did.
Even with so many processes and careful steps, about half of all software developed fails during execution. A good percentage of the remaining software fails to reach business goals, or at least make the users happy. It would make sense, then, to find a faster way to determine if an idea has the potential to succeed. Lean UX is one way to do that.
