Section I: Introduction and Principles

Chapter 1 – Why Lean UX?

Lean UX is the evolution of product design. It takes the best parts of the designer’s tool kit and recombines them in a way that makes them relevant to this new reality.

• It’s deeply collaborative and cross-functional
• 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
• Instead of talking about features and documents, we can talk about what works, and measure (market feedback) what works, learn, and adjust

Lean UX is three things:

• It’s easiest to understand as a process change for designers
• It’s a mindset that lets us approach our work in new ways
• It’s also a way of thinking about managing software

 

Chapter 2 – Principles

Lean UX stands on three foundations

1. The Lean principles underlying Lean Startup apply to Lean UX in these ways:

• They help us remove waste from our UX design process. We move away from heavily documented handoffs to a process that creates only the design artifacts we need to move the team’s learning forward.
• Second, they drive us to harmonize our “system” of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration that brings nondesigners into our design process.
• Last, and perhaps most important, is the mindset shift we gain from adopting a model based on experimentation. Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals.

2. Design thinking: takes a solution focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works toward product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light.

3. Agile development philosophies: refocuses software development on value. It seeks to deliver working software to customers quickly and to adjust regularly to new learning along the way.

As you explore the Lean UX approach, keep these principles in mind. Think of your experience with Lean UX as a learning journey. Use these principles to keep you and your team on course:

• Cross-Functional Teams | Small, Dedicated, Colocated | Progress = Outcomes, Not Output | Problem-Focused Teams | Removing Waste | Small Batch Size | Continuous Discovery | The New User-Centricity | Shared Understanding | Anti-Pattern: Rockstars, Gurus, and Ninjas | Externalizing Your Work | Making over Analysis | Learning over Growth | Permission to Fail | Getting Out of the Deliverables Business

 

Section II: Process

Chapter 3 – Vision, Framing and Outcomes

Describes how Lean UX radically shifts the way we frame our work. The goal is not to create a deliverable, it’s to change something in the world—to create an outcome. And how we can reframe our work in terms of outcomes to search for the best solutions to the problem at hand.

Declaring outcomes, an important process, means to start with the project’s problem statements and then acknowledge our assumptions, then transform these assumptions into hypotheses. Also how to write hypothesis statements that capture intended features, audience, and goals, and that are specific enough to be tested. You’ll end up with statements that will serve as the roadmap for the next step of the Lean UX process: collaborative design.

The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements: Assumptions, Vision, Framing, and Outcomes, Hypotheses, Outcomes, Personas and Features.

And the recommended tools to validate hypotheses are: Business Assumptions Worksheet, Subhypotheses, Outcomes, Personas e Features.

Chapter 4 – Collaborative Design

After written the hypothesis, it’s time to determine what you’ll need to test assumptions.

Describes the shift in the design process. Lean UX uses many techniques familiar to designers but shifts the emphasis of work, becoming more collaborative. We aim for speed first. We prioritize learning. We use a key tool to achieve this: the MVP.

It’s shown how the low-fidelity drawings created in Design Studio sessions can help teams generate many ideas and then converge on a set the entire team can get behind. And practical techniques that can be used to create shared understanding, the fundamental currency of Lean UX.

Using tools such as style guides (accessible, continually improved e actionable), Design Studio (example in image below), and simple conversation, your team members can build a shared understanding that allows them to move forward at a much faster pace than in traditional environments.

 

Chapter 5 – MVPs and Experiments

Lean UX is based on the idea that we begin our work with an assumption. We use experiments to test our assumptions and then build on what we learn in those experiments. This chapter shows you how to orient your design process around experiments and learning.

In this chapter, we defined the Minimum Viable Product as the smallest thing you can make to learn whether your hypothesis is valid. In addition, we discussed the various forms an MVP can take, took a closer look at prototyping, and discussed tactics for learning that don’t require building prototypes. For example:

Low-Fidelity Prototypes: Paper and Clickable Wireframes

Mid- and High Fidelity Prototypes

Hand-coded and live-data prototypes
There are two levels of fidelity for coded prototypes: hand-coded and live data:

• Hand-coded prototypes: look and function like the end product, but don’t account for any kind of real-time data input, processing, or output. They are still just simulations.
• Live-data prototypes: will connect with real-time data and process user input. These are often deployed to real customers and offer a level of analytical insight into customers’ usage of the prototype that is not available from hand-coded prototypes. They can also be used when A/B testing certain features or changes to the current workflow.

And finally there are Types of Non-Prototype MVPs as Email, Google Ad Words, Landing Page and the button to nowhere.

Chapter 6 – Feedback and Research

User Experience work in any form requires good input from users. Lean UX puts a premium on continuous feedback to help us guide our design process. This chapter shows techniques that Lean UX teams use to get feedback early and often, and how to incorporate that feedback into future product iterations.

It’s presented many ways to start validating the MVPs and experiments built around hypotheses. The main techniques are: Continuous Discovery, Collaborative Design, Sketches, Onsite Feedback Surveys, incorporate the voice of the customer throughout the Lean UX cycle (static wireframes, mockups, prototypes) and using A/B tests in your research.

And how to build a lean usability-testing process every week and covered what you should test and what to expect from those tests. These techniques, used in conjunction with the processes outlined in Chapters 3 through 5, make up the full Lean UX process loop. Your goal is to cycle through this loop as often as possible, refining your thinking with each iteration.

 

Section III: Making it work

Chapter 7 – Integrating Lean UX and Agile

Here will be demonstrated the tactics discussed in Section II and show exactly how they fit into a typical Scrum process and how they make it more effective. First of all, read more about Scrum and be familiar with definitions (user story, backlog, sprint, stand-up, retrospective, planning meeting).

Building Lean UX into the Rhythm of Scrum

Themes: many people frown on Scrum meetings, but if you use them as mileposts during your sprint, you can create an integrated Lean UX and Agile process in which the entire team is working on the same thing at the same time.

Kickoff Sessions for Sketching and Ideation: each theme should be kicked off with a series of brainstorming and validation exercises like the ones described in Section II. The point of this kickoff is to get the entire team sketching and ideating together, creating a backlog of ideas to test and learn from.

Iteration Planning Meeting: the output of the kickoff session should be brought to the IPM. You made the artifacts (sticky notes, sketches, wireframes, paper prototypes) together and because of that, you have the shared understanding necessary to extract stories from them. Then evaluate and prioritize the stories.

User Validation Schedule: to ensure a constant stream of customer voices to validate against, plan user sessions every single week. Your team will never be more than five business days away from customer validation but still your ideas will have ample time to react prior to the end of the sprint. Use the artifacts you created in the ideation sessions as the base material for your user tests. Remember that when the ideas are raw, you are testing for value (i.e., do people want to use my product?). Once you have established a desire for your product, subsequent tests with higher fidelity artifacts will reveal whether your solution is usable.

In addition, we can see how cross-functional collaboration allows a team to move forward at a brisk pace and how to handle those pesky stakeholders and managers who always want to know what’s going on.

 

Chapter 8 – Making Organizational Shifts

In this chapter, we’ll discuss the following changes your organization may need to make in these areas. It’s not just software developers and designers who need to find a way to work together. Product managers, project managers—in short, your whole product development engine—is going to need to change if you want to create a truly Agile organization.

• Shifting from output to outcomes
• Moving from limited roles to collaborative capabilities
• Embracing new skills
• Creating cross-functional teams
• Creating small teams
• Creating open, collaborative workspaces
• Not relying on heroes
• Eliminating “Big Design Up Front”
• Placing speed first, aesthetics second
• Valuing problem solving
• Embracing UX debt
• Shifting agency culture
• Working with third-party vendors
• Navigating documentation standards
• Being realistic about your environment
• Managing up and out