Lean UX

I’m re-reading Lean UX in light of recent discussion about our process at Metro.co.uk. You can buy it here.

Here’s a snippet from the intro.

Lean UX is deeply collaborative and cross-functional, because we no longer have the luxury of working in isolation from the rest of the product team. We can’t continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective. This continuous engagement allows us to strip away heavy deliverables in favor of techniques that allow us to build shared understanding with our teammates.

It then goes on to describe the principles of Lean UX…

Principle: Cross-Functional Teams

What is it? Cross-functional teams are made up of the various disciplines involved in creating your product. Software engineering, product management, interaction design, visual design, content strategy, marketing, and quality assurance (QA) should all be included in a Lean UX team. Lean UX demands a high level of collaboration between these disciplines. Their involvement must be continuous, from day one of the project until the end of the engagement.

Why do it? The creation of these diverse teams collapses the gated-handoff process known as waterfall. Insight on each idea is brought in from all relevant disciplines earlier in the process. Conversation is encouraged across functional silos, which drives greater team efficiency.

Principle: Small, Dedicated, Colocated

What is it? Keep your teams small—no more than 10 total core people. Dedicate them to one project and staff it all out of the same location.

Why do it? The benefit of small teams comes down to three words: communication, focus, and camaraderie. Smaller teams are easier to keep current on project status, changes, and new learning. Dedicating your team to one project keeps everyone on the team focused on the same priorities all the time. Having the team all in one place allows relationships to grow between colleagues.

Principle: Progress = Outcomes, Not Output

What is it? Features and services are outputs. The business goals they are meant to achieve are outcomes. Lean UX measures progress in terms of explicitly defined business outcomes.

Why do it? When we attempt to predict which features will achieve specific outcomes, we are mostly engaging in speculation. Although it’s easier to manage toward the launch of specific feature sets, we don’t know in any meaningful way whether a feature is effective until it’s in the market. By managing to outcomes (and the progress made toward them), we gain insight into the efficacy of the features we are building. If a feature is not performing well, we can make an objective decision as to whether it should be kept, changed, or replaced.

Principle: Problem-Focused Teams

What is it? A problem-focused team is one that has been assigned a business problem to solve, as opposed to a set of features to implement. This is the logical extension of the focus on outcomes.

Why do it? Assigning teams problems to solve shows trust in those teams. It allows them to come up with their own solutions and drives a deeper sense of pride and ownership in the solutions the team implements.

Principle: Removing Waste

What is it? One of the core tenets in Lean manufacturing is the removal of anything that doesn’t lead to the ultimate goal. In Lean UX, the ultimate goal is improved outcomes; hence, anything that doesn’t contribute to that is considered waste and should be removed from the team’s process.

Why do it? Team resources are limited. The more waste the team can eliminate, the faster they can move. Teams want to work on the right challenges. They want to be effective. A discipline of waste removal can help teams keep their laser focus where it belongs.

Principle: Small Batch Size

What is it? Another fundamental from Lean manufacturing is the use of small batch sizes. Lean manufacturing uses this notion to keep inventory low and quality high. Translated to Lean UX, this concept means creating only the design that is necessary to move the team forward and avoiding a big “inventory” of untested and unimplemented design ideas.

Why do it? Large-batch design makes the team less efficient. It forces the team to wait for big design deliverables. It keeps the team from learning whether their ideas are valid. It keeps some teammates idle and inevitably results in design assets that go unused. This approach is wasteful and doesn’t maximize the full learning potential of the team.

Principle: Continuous Discovery

What is it? Continuous discovery is the ongoing process of engaging the customer during the design and development process. This engagement is done through regularly scheduled activities, using both quantitative and qualitative methods. The goal is to understand what the users are doing with your products and why they are doing it. Research is done on frequent and regular schedules. Research involves the entire team.

Why do it? Regular customer conversations provide frequent opportunities for validating new product ideas. By bringing the entire team into the research cycle, the team will develop empathy for users and the problems they face. Finally, as the team learns together, you reduce the need for future debrief conversations and documentation.

Principle: GOOB: The New User-Centricity

What is it? It may sound like a baby’s first word, but GOOB is actually an acronym for what Stanford professor, entrepreneur, and author Steve Blank calls “getting out of the building.” It’s the realization that meeting-room debates about user needs won’t be settled conclusively within your office. Instead, the answers lie out in the marketplace, outside of your building.

After years of advocating for customer research, the UX community has a champion from the business world in Steve Blank. Blank’s prescription: give potential customers a chance to provide feedback on your ideas sooner than you would have in the past. Much sooner. Test your ideas with a strong dose of reality while they’re still young. Better to find out that your ideas are missing the mark before you’ve spent time and resources building a product that no one wants.

Why do it? Ultimately, the success or failure of your product isn’t the team’s decision—it’s the customers’. They will have to click that “Buy Now” button you designed. The sooner you give them a voice, the sooner you’ll learn whether you’ve got an idea that’s ready to be built.

Principle: Shared Understanding

What is it? Shared understanding is the collective knowledge of the team that builds up over time as the team works together. It’s a rich understanding of the space, the product, and the customers.

Why do it? Shared understanding is the currency of Lean UX. The more a team collectively understands what it’s doing and why, the less it has to depend on secondhand reports and detailed documents to continue its work.

Principle: Anti-Pattern: Rockstars, Gurus, and Ninjas

What is it? Lean UX advocates a team-based mentality. Rockstars, gurus, ninjas, and other elite experts of their craft break down team cohesion and eschew collaboration.

Why do it? Rockstars don’t share—neither their ideas nor the spotlight. Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. When collaboration breaks down, you lose the environment you need to create the shared understanding that allows you [to avoid repetition] to move forward effectively.

Principle: Externalizing Your Work

What is it? Externalizing means getting your work out of your head and out of your computer and into public view. Teams use whiteboards, foamcore boards, artifact walls, printouts, and sticky notes to expose their work in progress to their teammates, colleagues, and customers.

Why do it? Externalizing gets ideas out of teammates’ heads and on to the wall, allowing everyone to see where the team stands. It creates a passive, ambient flow of information across the team. It inspires new ideas that build off the ones that have already been shared. It allows all the members of the team—even the quiet ones—to participate in information-sharing activities. Their sticky notes or whiteboard sketches are equally as loud as those of the most prominent person on the team.

Principle: Making over Analysis

What is it? Lean UX values making over analysis. There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room.

Why do it? The answer to most difficult questions the team will face will not be answered in a conference room. Instead, they will be answered by customers in the field. In order to get those answers, you need to make the ideas concrete—you need to make something for people to respond to. Debating ideas is waste. Instead of analyzing potential scenarios, make something and get out of the building with it.

Principle: Learning over Growth

What is it? It’s difficult to figure out the right thing to build and scale a business around that thing at the same time. They are contradictory activities. Lean UX favors a focus on learning first and scaling second.

Why do it? Scaling an idea that is unproven is risky. It might work. And it might not. If it doesn’t work and you’ve scaled it out to your entire user base, your team has wasted valuable time and resources. Ensuring that an idea is right before scaling it out mitigates the risk inherent in broad feature deployment.

Principle: Permission to Fail

What is it? In order to find the best solution to business problems, Lean UX teams need to experiment with ideas. Most of these ideas will fail. The team must be safe to fail if they are to be successful. Permission to fail means that the team has a safe environment in which to experiment. That philosophy applies to both the technical environment (they can push out ideas in a safe way) and the cultural environment (they won’t be penalized for trying ideas that don’t succeed).

Why do it? Permission to fail breeds a culture of experimentation. Experimentation breeds creativity. Creativity, in turn, yields innovative solutions. When teams don’t fear for their jobs if they get something wrong, they’re more apt to take risks. It is from those risks that big ideas ultimately come. Finally, as the following anecdote illustrates so beautifully, frequent failures lead to increased mastery of skills.

Principle: Getting Out of the Deliverables Business

What is it? Lean UX refocuses the design process away from the documents the team is creating to the outcomes the team is achieving. With increased cross-functional collaboration, stakeholder conversation becomes less about what artifact is being created and more about which outcome is being achieved.

Why do it? Documents don’t solve customer problems—good products do. The team’s focus should be on learning which features have the biggest impact on the their customers. The artifacts the team uses to gain that knowledge are irrelevant. All that matters is the quality of the product, as measured by the market’s reaction to it.


Leave a Reply

%d bloggers like this: