Lean UX: Creating Great Products with Agile Teams (Third Edition)

Lean UX, now in its third edition by Jeff Gothelf and Josh Seiden, is an essential guide for product development teams seeking to build better products and services in today’s rapidly changing digital landscape. This book offers a comprehensive framework for integrating user experience (UX) design with Agile development and Lean Startup principles, moving teams away from outdated, document-heavy processes toward continuous learning, collaboration, and outcome-driven results. It promises to break down every important idea, example, and insight from the book, providing clear, accessible language for anyone looking to transform their approach to product design and delivery.

Part I. Introduction and Principles

Chapter 1. More Important Now than Ever Before

This chapter sets the stage by highlighting the evolution of product design and development, emphasizing why traditional approaches are no longer sufficient in the modern digital age. Historically, designers treated software like physical products, requiring detailed plans before “manufacturing” due to high production costs. This led to siloed teams and limited market feedback. However, the internet and the proliferation of mobile devices have transformed software production into a continuous process, enabling companies like Amazon to deploy new code every second. This dramatic shift creates intense pressure from competitors who leverage Agile software development, continuous integration, and continuous deployment to drastically reduce cycle times.

This new reality demands that companies continuously learn how well their products meet customer needs and respond quickly to feedback, raising customer expectations for quality and responsiveness. Traditional “get it all figured out first” methods are simply not workable. Lean UX emerges as the answer, taking the best of the designer’s toolkit and combining it with Agile and Lean Startup thinking. It promotes deep collaboration and cross-functional engagement, stripping away heavy deliverables in favor of shared understanding and faster decision-making. The goal shifts from creating artifacts to driving outcomes, reframing design conversations around objective business, customer, and user goals. Lean UX is presented as more than just a process; it’s a culture change that embraces humility and continuous improvement, and a set of organizational changes that foster inclusivity and transparency. It is, unequivocally, the way we need to work now.

Chapter 2. Principles

This chapter delves into the core principles that govern Lean UX, serving as a flexible framework rather than a rigid set of rules. Given the diverse contexts of product teams, these principles provide guidance for adapting the Lean UX approach. Ultimately, embracing these principles transforms team culture, fostering collaboration, cross-functionality, and a better fit for the agile reality.

The foundations of Lean UX are rooted in three key schools of thought:

• User Experience (UX) Design: Originating from human factors and human-centered design, UX focuses on identifying human needs as the starting point for design. It encompasses interaction design, information architecture, and graphic design, emphasizing understanding the user.
• Design Thinking: Popularized by IDEO, design thinking extends human-centered design methods to a wide range of business problems. It encourages applying design tools beyond typical boundaries and empowers nondesigners to use design methods. Key tenets include collaboration, iteration, making, and empathy for the end user.
• Agile Software Development: Agile methods, born from developers’ frustration with traditional processes, prioritize shorter cycles, regular delivery of value, and continuous learning. Lean UX aligns with Agile’s four core values:
  • Individuals and interactions over processes and tools: Favoring conversation and collaboration over rigid documentation.
  • Working software over comprehensive documentation: Prioritizing viable solutions and market fit through early delivery.
  • Customer collaboration over contract negotiation: Building shared understanding and consensus through direct engagement.
  • Responding to change over following a plan: Accepting that initial designs are likely wrong and adjusting based on market feedback.
• Eric Ries’s Lean Startup Method: This method utilizes a “build-measure-learn” feedback loop to minimize project risk and accelerate learning. Teams develop Minimum Viable Products (MVPs) to test market assumptions and rapidly evolve ideas based on customer feedback, directly influencing Lean UX’s emphasis on hypothesis testing.

Lean UX is defined as a design approach that brings the true nature of a product to light faster, in a collaborative, cross-functional, and user-centered way. It builds shared understanding of users, their needs, proposed solutions, and success metrics, prioritizing continuous learning to validate decisions and improve product delivery.

The principles are organized into three groups:

Principles to Guide Team Organization:

• Cross-functional: Teams comprise diverse disciplines (engineering, design, product, QA, marketing) for continuous, high-level collaboration, fostering better solutions from multiple viewpoints and limiting the need for handoff-based processes.
• Small, dedicated, colocated: Limiting teams to around 10 core people, dedicating them to one project, and placing them in the same location enhances communication, focus, and camaraderie. While remote work has shown virtual collaboration is possible, physical colocation still offers unique benefits in fostering shared understanding and informal interactions.
• Self-sufficient and empowered: Teams are given all necessary capabilities, tools, and permission to operate without external dependencies, allowing them to optimize processes for efficiency and engage directly with users for feedback.
• Problem-focused: Teams are assigned specific business or user problems to solve (outcomes) rather than just features to implement. This builds trust, ownership, and encourages iteration until the problem is truly resolved.

Principles to Guide Culture:

• Moving from doubt to certainty: Embracing the complexity of software development, Lean UX starts with the understanding that everything is an assumption until proven. This promotes enthusiastic skepticism and systematic validation to gain clarity.
• Outcomes over output: The ultimate goal is to create a measurable change in human behavior that creates value (an outcome), rather than simply delivering features. This helps assess feature efficacy and allows objective decisions on whether to keep, change, or replace solutions.
• Removing waste: Eliminating anything that doesn’t contribute to improved outcomes ensures faster progress and a laser focus on value creation, driving continuous improvement in the design process and preventing the creation of unwanted products.
• Shared understanding: The collective knowledge built through team collaboration is the currency of Lean UX. It reduces the need for extensive documentation and debates, promoting faster decision-making and cutting through ego-driven design choices by fostering empathy for users.
• No rock stars, gurus, or ninjas: Lean UX promotes a team-based mentality and cohesion over individual stardom. Large egos can break down collaboration and shared understanding, which are essential for effective progress.
• Permission to fail: Teams need a safe environment to experiment, knowing that most initial ideas will fail. This fosters creativity and innovation, leading to big ideas by encouraging risk-taking without fear of penalty. The “quantity group” ceramics class analogy illustrates that frequent iteration, even with failures, leads to higher quality over time.

Principles to Guide Process:

• Don’t do the same thing faster: Agile isn’t about speed for speed’s sake; it’s about reconceptualizing work to build better products. Old processes shouldn’t be forced into new rhythms.
• Beware of phases: Any “phase” (research, design, development) indicates a problem. Agile teams should be doing all activities continuously in every sprint, moving from finished process steps to finished, inspectable work.
• Iteration is the key to agility: Beyond incremental slices, iteration means a commitment to redoing work until it’s right, solving the problem, and meeting user needs and desired outcomes. This addresses the common UX frustration of not having enough time to perfect.
• Work in small batches to mitigate risk: Inspired by Lean manufacturing, this means creating only necessary design artifacts to move forward, avoiding a large “inventory” of untested ideas. Smaller batches allow design and validation to happen concurrently, reducing wasted effort if assumptions prove wrong.
• Embrace continuous discovery: This is the ongoing process of engaging customers through regular qualitative and quantitative research. It ensures frequent validation, builds team empathy, and reduces the need for extensive debriefings and documentation by fostering shared understanding.
• Get out of the building: As popularized by Steve Blank, this means conducting user research in real-world settings to understand users’ actual behaviors and needs. Testing ideas with potential customers early helps identify flaws before significant resources are invested.
• Externalize your work: Get ideas out of heads and computers onto whiteboards, shared virtual spaces, and physical walls. This creates passive information flow, inspires new ideas, and encourages participation from all team members, regardless of their vocalness.
• Make over analysis: Lean UX values creation over endless debate. It’s more productive to build a first version of an idea and test it than to spend excessive time analyzing hypothetical scenarios. The market provides the real answers, not the conference room.
• Get out of the deliverables business: The focus shifts from producing documents to achieving outcomes. Increased cross-functional collaboration means less discussion about artifacts and more about measurable impact on customers. The goal is valuable products, not specs.

In summary, these principles define the essential attributes of a Lean UX team, guiding its structure, culture, and processes toward collaboration, continuous learning, and customer-centricity.

Chapter 3. Outcomes

This chapter emphasizes a radical shift in how work is framed: moving from traditional requirements and deliverables to strategic outcomes. Instead of focusing on what products or features to build, Lean UX prioritizes understanding why work is being done and what success truly looks like—not just for the business, but for the customer.

The core message is to “get out of the deliverables business” and into the “business of creating outcomes.” This means focusing less on artifacts (documents, mock-ups, features, buttons) and more on the measurable results they are intended to generate. The difficulty in predicting whether features will create desired value necessitates this shift. By focusing on outcomes, teams continually test solutions until they find one that delivers the desired value.

The transition from outputs to outcomes is articulated through the Logic Model, which typically involves:

• Outputs: The tangible things produced (e.g., a website, an app, a feature, new copy).
• Outcomes: A change in human behavior that creates value (e.g., event hosts meeting qualified planners, users paying for a service). These are inherently human-centered and define success by what people do differently.
• Impact: The highest-level targets a business sets (e.g., increased revenue, profit, customer loyalty). Outcomes are the leading indicators of these larger business impacts.

An illustrative story about outcomes describes an agency client who, despite providing a detailed list of feature requirements (outputs) for a new website, was prompted to clarify the site’s purpose and customer behavior changes it aimed to achieve. The agency reframed the goal from building a website to enabling “event hosts to meet qualified event planners for domestic and local events” – a clear outcome. This allows the team to prioritize features that directly contribute to that outcome, deprioritizing those that don’t.

A deeper look at outcomes reveals:

• Behavior Change: Outcomes are defined by what people do differently. This could be a new behavior or a more efficient way of performing an existing one.
• Value Creation: The behavior change must create value, not just for the user, but also for the organization (e.g., customers paying for the service, returning, or recommending it).
• Point of View: Value depends on the perspective—what creates value for the user might also create value for the organization, or even society at large (as in the Facebook example). It’s crucial to consider a broad range of stakeholders, both direct and indirect.
• System of Interrelated Outcomes: No single outcome describes a complex system; instead, successful systems are composed of many interconnected outcomes that combine to achieve higher-level impacts.

The chapter concludes by linking outcomes with iteration and validation. Shifting focus from outputs to outcomes fundamentally alters the definition of “done.” Work isn’t finished when software is built; it’s done when it’s validated—meaning it’s released and observed to see if it actually changes behavior as intended. This necessitates an inherently iterative process, where teams continuously inspect and adapt (the “build-measure-learn” loop) until the desired outcomes are achieved, marking the end of the “one-and-done” approach.

Part II. Process

Chapter 4. The Lean UX Canvas

This chapter introduces the Lean UX Canvas, a central tool for orchestrating the Lean UX process by guiding teams through a series of assumptions. It challenges the traditional notion of “requirements” in software development, arguing that in today’s unpredictable digital landscape, requirements are simply assumptions expressed with authority. The rapid pace of change, exemplified by Amazon’s one-second deployment cycles, makes rigid, predetermined requirements anachronistic and an impediment to effective product development. Software and human behavior are complex and unpredictable, meaning initial solutions are likely to be partially wrong.

The Lean UX Canvas helps teams humbly admit their best guesses (assumptions), creating a space for product discovery, experimentation, and continuous adjustment. It is a single-page, “at-a-glance” tool designed to frame work for features, epics, or entire products, collecting key tools, methods, and techniques into a unified structure. Its purpose is to facilitate conversations within the team and with stakeholders, building a shared understanding and a clear path forward.

Using the Canvas:

• When to use: Ideal for kicking off any significant initiative—a new feature, major initiative, or new product—where important unknowns, uncertainty, or complexity exist.
• Early-stage vs. sustaining innovation: Effective for both, as long as there are significant unknowns to explore.
• Who should work on it: All team members (designers, developers, product managers, etc.) should participate to foster shared understanding. Stakeholders and clients should also be involved, especially for defining business problems and goals.
• How long to spend: Typically a half-day session at minimum, extending to several weeks for larger, more important projects. The goal is to avoid analysis paralysis; when unsure, note the uncertainty and move on.
• Necessity: While not mandatory for Lean UX, the canvas is an effective way to structure the process and ensure critical conversations happen. Individual boxes can also be used as standalone techniques (e.g., Box 3 for proto-personas if user clarity is needed).

Facilitating Each Section:

• Be inclusive: Use variations of the 1-2-4-All pattern (individual work, then pairs, then subgroups, then whole group) to ensure everyone participates, accounting for diverse styles and power dynamics. This pattern helps generate ideas quickly and then converge on them.
• Remote versus in-person: The exercises can be done remotely using videoconferencing and shared whiteboard tools (e.g., Mural, Miro). Breaks are essential for remote sessions, and time should be allocated for onboarding less experienced participants to the tools.

The canvas guides the conversation from the current state (NOW) of a product to its desired future state (LATER), ensuring all assumptions are explicitly declared and tested.

Chapter 5. Box 1: Business Problem

This chapter focuses on Box 1 of the Lean UX Canvas: Business Problem, emphasizing that for Lean UX to succeed, teams must be given problems to solve, not solutions to build. Business problem statements explicitly reframe work to demand product discovery.

A good business problem statement should:

• Provide a specific challenge: Frame the work as a problem for the team to solve, not a list of features to implement.
• Anchor in a customer-centric perspective: Ensure customer success is integral to the end goal.
• Focus effort: Specify guidelines and constraints that clarify what is in and out of scope.
• Provide clear measures of success: Express success as key performance indicators (desired impacts) or specific target audience outcomes.
• Not define a solution: Avoid prescribing “how” the problem will be solved.

Fundamentally, business problem statements have three parts:

1. Current goals: Why the product/system was created and what value it was intended to deliver.
2. Changes and negative effects: How the world has changed and negatively impacted the product, causing unmet goals.
3. Explicit request for improvement: A solution-agnostic request quantifying “improvement” in terms of outcomes.

Facilitating the Exercise:
The process begins with the product manager providing context (e.g., observed issues, target audience, broader company program, impact of fixing/not fixing the problem).

1. First draft in pairs/trios: Divide larger groups to draft the statement, spending no more than 30 minutes.
   • Template for existing products: [Our service/product] was designed to achieve [these business/customer goals and deliver this value]. We have observed [in these ways] that the product/service isn’t meeting these goals, which is causing [this adverse effect/problem] to our business. How might we improve service/product so that our customers are more successful as determined by [these measurable changes in their behavior]?
   • Template for new initiatives: The current state of [the domain we are working in] has focused mainly on [these customer segments, these pain points, these workflows, etc.]. What existing products/services fail to address is [this gap or change in the marketplace]. Our product/service will address this gap by [this product strategy or approach]. Our initial focus will be [this audience segment]. We’ll know we are successful when we see [these measurable behaviors in our target audience].
2. Team review and critique: Groups share drafts, providing clarifying questions and feedback.
3. Subgroup consolidation: Larger groups combine drafts into a single statement (30 minutes).
4. Pan-team consolidation: The broader team consolidates into one final statement (30 minutes).

Remember that this is an assumptions declaration exercise; perfection is not the goal. It’s about building initial alignment and understanding that discovery work may reveal the need to adjust the problem statement itself. Stakeholder commitment should be sought if they weren’t involved in the drafting.

What to Watch Out For:

• Don’t specify the solution: Avoid inserting “how might we implement a mobile app” phrases; solutions belong in Box 5.
• Get the level right: The problem statement must be solvable by the assigned team; avoid framing problems too high-level if the team lacks the influence to act.
• Be specific: Avoid vague terms like “intuitive UI” or “great user experience.” Include explicit metrics and evidence to frame importance and success criteria. Specificity helps clarify the problem and prevent premature focus on abstract features.

Chapter 6. Box 2: Business Outcomes

This chapter focuses on Box 2 of the Lean UX Canvas: Business Outcomes, which refines the high-level success criteria from the business problem statement into core behavior changes. While the problem statement often deals with impact metrics (revenue, profit), this section identifies the leading indicators—the specific, valuable behaviors customers will be doing differently if the solutions work. Every outcome here should start with a verb, representing either existing valuable behaviors, behaviors to reduce, or new valuable behaviors.

Using the User Journey:
Understanding customer behavior often begins with mapping user journeys. Several models can be used:

• Pirate Metrics (AARRR): This popular funnel framework (Acquisition, Activation, Retention, Revenue, Referral) helps identify outcome metrics at different stages:
  • Acquisition: Getting customers to the product (e.g., downloads, sign-ups).
  • Activation: Customers actively using core functionality (e.g., accounts created, purchases made).
  • Retention: Customers continuing to use the product regularly.
  • Revenue: Customers paying for the product.
  • Referral: Customers recommending the product to others.
• Metrics Mountain: A preferred metaphor over the funnel, Metrics Mountain visualizes the customer life cycle as a climb, where teams aim to get as many users to the top as possible, acknowledging natural drop-offs.
  • Facilitating with Metrics Mountain:
    • Start at the base: Identify the first user action to begin using the product or feature.
    • Define plateaus: Map subsequent steps of the customer journey, determining the user behavior required for each.
    • Set success percentages: Determine target percentages of users to reach each step of the mountain. For example, 75% discovery, 50% trial, 25% weekly usage, 10% paid.
• Service Journeys and User Story Maps: For products where funnels or mountains don’t fit, teams can create custom maps that visualize user flow. The key is to visualize the flow, zoom in on critical parts, identify crucial behaviors, and define outcome metrics for success.

Outcome-to-Impact Mapping:
This technique visualizes the connection between tactical outcomes (customer behaviors) and high-level impact metrics (executive concerns). It clarifies the relationship between leading indicators (outcomes) and lagging indicators (impacts). Many leading indicators often contribute to one or two impact metrics.

• Process:
  1. Gather the team and product leads.
  2. Write the high-level strategic goal (impact) on Post-it notes at the top of a whiteboard.
  3. Below that, list the measures of success for that strategy (lagging impact metrics).
  4. Draw lines to identify customer behaviors (leading indicators/outcomes) that drive those impact metrics, brainstorming individually with Post-its.
  5. Continue adding rows of driving customer behaviors, creating a detailed map.
  6. Use dot voting or other selection methods to prioritize the top 10 outcomes to focus on.
  7. Establish a baseline and a target goal for each selected outcome for the next cycle.

This exercise provides a clear link between daily work and strategic business goals, aiding prioritization and ensuring stakeholders understand the “why” behind the team’s efforts.

What to Watch Out For:

• Not every metric is an outcome: Ensure metrics represent customer behavior, not product strategy decisions or system features. For example, “percentage of products on the shelf that are our brand” is a product decision, not a customer behavior. Focus on what the user does.
• Charts can get messy: Real-world business complexity means these maps won’t always be perfectly linear. One outcome might drive multiple impact metrics. Prioritize content clarity over aesthetic neatness.

Chapter 7. Box 3: Users

This chapter addresses Box 3 of the Lean UX Canvas: Users, emphasizing the critical need to keep the user central to thinking, especially when making assumptions about business and desired outcomes. It introduces proto-personas as a dynamic tool to define target audiences. Unlike traditional personas born from lengthy research, proto-personas are the team’s best guesses about who will use the product and why, sketched collaboratively on paper. They are designed to be living documents, continuously refined through ongoing research.

Proto-personas serve two key purposes:

• Shared understanding: They ensure that all team members have a consistent mental image of “the user,” preventing individual biases and promoting a unified perspective.
• Remembering “we are not the user”: They help the team focus on external users’ needs, goals, and behaviors, rather than projecting their own preferences or assumptions onto the product.

The chapter recounts an example where a team initially assumed their app’s users would be women who cooked, but through early research, quickly discovered their primary audience was young men, leading to a crucial revision of their proto-persona and saving significant development time.

The Proto-Persona Template:
Proto-personas are typically sketched on paper with three sections:

• Upper-left: A rough sketch of the persona, name, and role.
• Upper-right: Basic demographic, psychographic, and behavioral information, with an emphasis on “differences that make a difference” (i.e., information relevant to predicting behavior, not just arbitrary data).
• Bottom half: The most important details—goals, needs, desired outcomes, and obstacles. The focus here is on what users need to accomplish, rather than simply features.

Facilitating the Exercise:

1. Brainstorm persona types: Team members offer opinions on target users and how they might use the product (e.g., “college students,” “streaming enthusiasts”).
2. Narrow down: Select three to four most likely target audience personas, prioritizing differentiation by needs and roles over demographics.
3. Complete templates: Small groups complete a proto-persona template for each selected persona.
4. Review and revise: Groups share their personas for feedback, then revise based on collective input.
5. Share broadly: Share personas beyond the immediate team for wider input.

Early Validation:
This is a crucial point for early assumption testing before deeper investment. Proto-personas serve as recruiting targets for initial research. Three key validation points:

• Does the customer exist?: Can you find and recruit individuals matching your persona? If not, the persona might be unrealistic.
• Do they have the needs and obstacles you think they do?: Do direct observations and conversations confirm the problems you’re trying to solve? If not, you risk building solutions for non-existent problems.
• Would they value a solution to this problem?: Just because a problem exists doesn’t mean users will value your solution. Understand how customers currently solve these needs and the likelihood of displacing incumbent solutions (e.g., the banana slicer analogy). The angel investor example highlights this: while investors existed and had problems, their infrequent investment activity meant they wouldn’t value a specialized tool over existing, familiar solutions like email and Excel. This critical learning occurred early, preventing wasted effort.

What to Watch Out For:

• Living documents: Proto-personas must be continuously adjusted based on new information from customer conversations and usability studies. Failure to revise makes them static and outdated.
• Feature-focused pitfalls: Avoid writing features as user benefits (e.g., “calendar integration” instead of “never be late to another meeting”). The goal is to uncover latent needs and emotional motivations.
• Ambiguity: Avoid vague phrases like “intuitive UI” in the persona itself, as they lack specific meaning for design and testing.

Chapter 8. Box 4: User Outcomes and Benefits

This chapter focuses on Box 4 of the Lean UX Canvas: User Outcomes and Benefits, emphasizing the importance of keeping the user and their goals at the forefront of the design process, despite the typical feature-centric debates. Achieving broader shared understanding and empathy for users’ aspirations requires declaring assumptions about what users are trying to do, both functionally and emotionally.

The chapter clarifies the distinction between business outcomes, customer outcomes, and user outcomes using the example of corporate expense tracking software:

• Business Outcome: For the company selling the software (e.g., acquire/retain customers, increase subscription revenue).
• Customer Outcome: For the companies buying the software for their employees (e.g., improve accounting efficiency, reduce un-reimbursable expenses, lower operational costs).
• User Outcome: For the employees using the software (e.g., get expenses reimbursed quickly, reduce time inputting expenses correctly).

Beyond behavior change, the chapter highlights emotional goals at both the customer and user levels. Buyers want to feel successful and look good to their bosses. Users want to feel confident their expenses will be reimbursed without hassle. While harder to quantify, these emotional goals are crucial for defining the desired experience and ultimately drive quantifiable metrics. All these outcomes are important, and their inherent point of view (who is getting value) should be acknowledged.

Facilitating the Exercise:
Using the proto-personas (from Box 3) as a base, the team collectively explores user outcomes. Prompts for discussion include:

• What is the user trying to accomplish? (e.g., “I want to buy a new phone.”)
• How does the user want to feel during and after this process? (e.g., “I want to feel like I got the phone I need at a good price and that I’m keeping up with my peers.”)
• How does our product or service get the user closer to a life goal or dream? (e.g., “I want to feel tech-savvy and respected for it.”)
• Why would your user seek out your product? (e.g., “I want to fit in with my friends at school.”)
• What behavior change can we observe that tells they’ve achieved their goal? (e.g., “They bring their new phone to school every day.”)

This exercise allows the team to delve into the emotional aspects of user experience, which is invaluable for crafting compelling content, calls-to-action, and instructional text, and for understanding user motivation.

What to Watch Out For:

• Avoid feature-centric language: A common pitfall is listing features (e.g., “calendar integration”) instead of user benefits or latent needs (e.g., “never be late to another meeting”). The goal is to understand the user’s “why,” not just the “what.”
• Ambiguity: Phrases like “intuitive UI” or “great user experience” are too abstract and don’t provide actionable insights for understanding user motivation or desired behaviors.

Chapter 9. Box 5: Solutions

This chapter marks the point in the Lean UX process where the team finally discusses solutions (Box 5). By design, this comes after defining the business problem (Box 1), business outcomes (Box 2), users (Box 3), and user outcomes/benefits (Box 4). These prior steps serve as constraints that foster creativity and ensure solutions are focused, solving the right problem for the right people.

Facilitating the Exercise:
Various brainstorming techniques can be used to generate solution ideas that address the defined problems and outcomes for the target personas.

• Affinity Mapping: This is a simple and quick method:
  1. Individually, brainstorm solution ideas on Post-it notes that solve the business problem and achieve desired outcomes for the personas. The framing question is: “What solutions can we design and build that will serve our personas and create their desired outcomes?”
  2. Write words or small sketches on each Post-it.
  3. Share ideas with the team, sorting similar ones into groups.
  4. Dot vote on approaches believed to have the greatest chance of success.
• Collaborative Design: A More Structured Approach (Design Studio): A more deliberate method for visualizing potential solutions, born from the architecture world’s “Design Charrette.” It brings cross-functional teams together to build shared understanding and trust.
  • Running a Design Studio: This highly specific technique can be adapted, but the core idea is collective problem-solving.
    • Setting: A dedicated 3+ hour block, a room with tables and wall space (or virtual whiteboard tools like Mural/Miro for remote sessions).
    • The Team: 5–8 people per team; larger groups split into parallel teams that converge later. For remote, use breakout rooms.
    • Supplies: Pencils, pens, markers, sketching templates (six-up sheets), easel pads, drafting dots. For remote, digital tools are key.
    • Process:
      1. Problem Definition and Constraints (15 minutes): Review all assumptions from previous canvas boxes (business problem, outcomes, users, benefits).
      2. Individual Idea Generation (10 minutes): Each person, using a six-up template, sketches six low-fidelity solution ideas (UI sketches, workflows, diagrams) for persona/problem pairs. The emphasis is on visual articulation, not words. Encourage simple shapes.
      3. Presentation and Critique (3 minutes per person): Participants share their sketches, explaining the persona and pain point addressed. Feedback should be question-based (“How does this feature address…?”) rather than opinion-based (“I don’t like that…”), promoting clarification over defense.
      4. Pair Up to Iterate and Refine (10 minutes): Pairs choose the most promising ideas from the individual round, revise them, and produce a single, more evolved sketch on an 11″x17″ six-up sheet. The goal is to make decisions and get more specific.
      5. Team Idea Generation (45 minutes): The entire team converges on one or a few best ideas, sketching components and workflows on a large easel pad or whiteboard. This stage involves significant compromise, prioritization, and paring back of features. A “parking lot” for good but not-selected ideas helps release attachment. If multiple teams, they present and converge.

Using the Output:
The Design Studio’s output directly informs the creation of hypotheses and experiment design (Box 6). Converged ideas are put to the test. All drawings should be posted visibly for reference and archived (photographed) to preserve decisions and ideas for future use.

What to Watch Out For:

• Even participation: Facilitation is key to ensuring everyone contributes, especially if using more involved techniques like Design Studio. Simple exercises (Post-it notes) are naturally inclusive, but complex ones require skilled guidance to prevent team members from disengaging.
• Design facilitation as a core skill: For designers, leading these collaborative sessions effectively is paramount to success.

Chapter 10. Box 6: Hypotheses

This chapter focuses on Box 6 of the Lean UX Canvas: Hypotheses, where all the raw material from previous boxes is used to write tactical, testable hypotheses. A hypothesis is defined as “a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.” Lean UX, inspired by the scientific method, explicitly acknowledges that ideas are assumptions that need to be tested.

The recommended hypothesis template is:
We believe we will achieve [this business outcome]
If [these personas]
Attain [this benefit/user outcome]
With [this feature or solution]

The process of writing hypotheses involves filling in the blanks from Box 2 (business outcomes), Box 3 (personas), Box 4 (benefits), and Box 5 (solutions). The act of writing a hypothesis serves as the first test of the solution’s validity. If a compelling hypothesis cannot be formed—one where the feature clearly benefits the user, and the user’s behavior change helps solve a business problem—then the idea shouldn’t proceed.

Facilitating the Exercise:

1. Create a hypothesis table: Organize ideas from previous canvas boxes into a table where each row represents a potential hypothesis (columns for business outcome, personas, user outcome/benefit, and solution).
2. Physically move Post-it notes: Transfer notes from earlier boxes into the table, making rows of related ideas. This often reveals gaps where some business outcomes lack features or some features lack clear user/business value.
3. Fill gaps or deprioritize irrelevant ideas: Add new sticky notes to fill logical gaps, or remove less relevant ideas from the chart.
4. Extract hypotheses: Write out 7-10 compelling hypotheses using the template. Ensure each hypothesis is specific enough for meaningful testing and focuses on one feature if multiple features drive similar outcomes.

Hypotheses vs. Agile User Stories:
The chapter clarifies the subtle but powerful difference:

• Agile User Story: As a <type of user>, I want <some goal> so that <some reason>. Often, “some goal” becomes “this feature,” leading teams to ship features without validating their value or desirability. Success is typically defined by whether the system “works as designed.”
• Hypothesis: Focuses on behavior change (business outcomes) as the definition of success. Shipping a working feature is just the start; success is measured by how well customers achieve their goals. A single hypothesis can generate multiple user stories. The key is to connect feature-level work to higher-level user and business outcomes.

Prioritizing Hypotheses:
Lean UX demands ruthless prioritization because resources are limited. The goal is to identify and test the riskiest hypotheses first. The Hypothesis Prioritization Canvas (HPC), a two-by-two matrix, is introduced for this purpose:

• X-axis: Risk: Evaluates technical, brand, or design capability risks.
• Y-axis: Perceived Value: Assesses whether implementation will meaningfully impact user experience and business.

Mapping hypotheses on the HPC:

• Quadrant 1 (High Value, High Risk): These hypotheses are the ones to test first. They “graduate” to Boxes 7 and 8 of the Lean UX Canvas.
• Quadrant 2 (High Value, Low Risk): These are ready to be built and shipped immediately. User stories are written, added to the backlog, and implemented, but their performance must still be measured live.
• Quadrant 3 (Low Value, Low Risk): Generally not tested or built, unless they represent necessary operational features that don’t differentiate the product (e.g., a payment system).
• Quadrant 4 (Low Value, High Risk): Discarded. No need to test or build.

What to Watch Out For:

• Hypotheses too big to test: Teams often write overly broad hypotheses initially. They should be refined to be smaller and within the team’s ownership.
• Lack of specificity: Hypotheses, like problem statements, benefit from specific numbers in business outcomes and clear feature descriptions. Avoid ambiguous phrases like “better user experience” and instead use concrete terms like “one-click checkout.”

Chapter 11. Box 7: What’s the Most Important Thing We Need to Learn First?

This chapter addresses Box 7 of the Lean UX Canvas: Learning, which focuses on identifying the major risks within each prioritized hypothesis. This involves asking the first of two key Lean UX questions: “What’s the most important thing we need to learn first about this hypothesis?”

This question is fundamentally a conversation about risk. A cross-functional team will bring diverse perspectives on potential risks:

• Software engineers: Might highlight complexities in developing the feature.
• Designers: May raise workflow issues or usability concerns.
• Product managers: Could question whether the solution will deliver anticipated business benefits.

All these risks are valid, but the immediate focus should be on those that could invalidate the hypothesis quickly. In the early stages of a hypothesis’s lifecycle, the biggest risks are typically related to value:

• Do people need this solution?
• Will they look for it?
• Will they try it?
• Will they use it?
• Will they find value in it?

If the answers to these initial questions are “no,” then there’s no need to invest in designing or building the solution. For more mature hypotheses, where value has already been validated, the next logical risks to explore might be technical challenges, usability, or scalability.

Facilitating the Exercise:
This step is primarily a conversation. The team reviews prioritized hypotheses and collectively decides what needs to be learned first.

• If the discussion stalls, brainstorming, affinity mapping, and dot voting can be used.
• Alternatively, the product manager or a team member with strong insights might make the call.
• It’s important to remember that hypotheses, assumptions, and risks are not abandoned forever if they’re not pursued immediately. If an idea proves false, the team can return to the backlog of hypotheses.

What to Watch Out For:

• Lack of consensus: If the team can’t agree on the most important thing to learn, it indicates a need for more information. In such cases, a decision must be made to move forward to Box 8 and design an experiment, rather than getting stuck in analysis paralysis. The goal is to move forward and gain the necessary information to achieve consensus later.

Chapter 12. Box 8: MVPs and Experiments

This chapter focuses on Box 8 of the Lean UX Canvas: MVPs and Experiments, answering the second key Lean UX question: “What’s the least amount of work we need to do to learn the next most important thing?” The answer to this question is the experiment that will test the hypothesis, which is also the definition of a Minimum Viable Product (MVP).

An MVP, in this context, is a small and fast way of learning something. It’s not necessarily a software release; it could be a drawing, a landing page, or a prototype. The primary concern is learning, not just creating value, although a good MVP often does both. The chapter provides an example of a company testing demand for a newsletter by simply adding a sign-up form to their website—a quick, cheap way to learn if there was interest before investing in content and design.

Creating an MVP:

• The first question is always: “What is the most important thing we need to learn next?” This will guide whether the MVP focuses on value or implementation.

Creating an MVP to Understand Value:

• Get to the point: Distill the idea to its core value proposition.
• Use a clear call to action: Measure intent through opt-ins or sign-ups.
• Measure behavior: Observe what people actually do, as behavior trumps opinion.
• Talk to your users: Understand why behaviors occurred (or didn’t).
• Prioritize ruthlessly: Be willing to discard invalidated ideas.
• Stay agile: Work with tools that allow easy updates.
• Don’t reinvent the wheel: Leverage existing tools (email, social media, no-code platforms) for testing.

Creating an MVP to Understand Implementation:

• Be functional: Integrate with existing application context for realistic usage.
• Integrate with existing analytics: Measure performance within current workflows.
• Be consistent: Match current look and feel to minimize bias.

Some Final Guidelines for Creating MVPs:

• Not easy to be pure: Often, MVPs learn about value and implementation simultaneously.
• Be clear about learning goals: Define what data needs to be collected.
• Start small: Build the smallest MVP possible to reduce investment in case of invalidation.
• You don’t necessarily need code: Rely on UX tools like sketching, prototyping, and copywriting.

The Truth Curve: This concept, adapted from Giff Constable, illustrates that the effort invested in an MVP should be proportional to the amount of market evidence. More evidence allows for higher fidelity and complexity; less evidence demands less effort. The core question remains: “What’s the smallest thing that you can do to learn the next most important thing?”

Examples of MVPs:

• Landing Page Test: Creates a marketing page with a value proposition and call to action to measure demand (e.g., Kickstarter campaigns).
• Feature Fake (Button to Nowhere): Creates the illusion of a feature to measure interest before building (e.g., Flickr’s “Use as screensaver” button, MapMyRun’s photo upload prompts). These should be used sparingly and removed once a threshold is met.
• Wizard of Oz: Simulates a fully functional digital service with human manual operations behind the scenes to understand mechanics (e.g., Amazon Echo’s early testing, Taproot Plus online marketplace). This approach helps learn high-risk business processes before significant engineering investment.

Prototyping: A highly effective way to create MVPs, allowing simulation of an experience without full development.

• Factors in choosing a technique: Target audience, learning goals, existing knowledge, time.
• Types of prototypes:
  • Paper Prototypes: Quick, cheap, easily rearranged. Good for validating concepts and high-level structure, but artificial interaction.
  • Low-Fidelity On-Screen Mock-Ups: Clickable wireframes offering more realistic feel, good for workflow and findability of core elements.
  • Middle- and High-Fidelity On-Screen Prototypes: More detailed, fleshed out with interaction and visual design. Good for testing branding, aesthetics, and visual hierarchy, but still limited interactivity and can be time-consuming.
  • No-Code MVP: Functional prototype using existing tools (Airtable, Zapier, Webflow) without custom code. Rapidly tests functionality before writing custom software, focusing on unique service parts, but lacks brand representation and long-term maintainability.
  • Coded and Live-Data Prototypes: Highest fidelity, replicate final product. Coded prototypes can be hardcoded (simulations) or use live data (closer to production, useful for A/B testing). Powerful for realistic simulation, but time-consuming and risk of perfectionism.
• What Should Go into My Prototype?: Focus on core workflows that test the biggest risks in the hypothesis, creating “temporary tunnel vision” for the team.
• Demos and Previews: Share prototyped MVPs internally (teammates, stakeholders) and externally (customers) to gather insights.
• Example: Using a Prototype MVP: A startup revamped its business model, using a five-wireframe clickable prototype (MVP) to test two-fold concerns: current user acceptance and new market segment interest. Taking the prototype to a conference provided immediate market feedback within eight business days, allowing the team to pivot and refine effectively before significant investment.

Chapter 13. Bringing It All Together

This chapter concludes the “Process” section by demonstrating how the Lean UX techniques, from problem framing to experimentation, coalesce into a cohesive workflow using the Lean UX Canvas. It acknowledges the messiness of the real world and provides stories illustrating how teams adapt Lean UX principles, whether using the full canvas or individual techniques.

The Lean UX Canvas in the Enterprise:
A product and design leader at a large enterprise software company recounted using the Lean UX Canvas for a product’s second release. The team planned to enhance a beautiful data display feature that had received positive feedback. However, working through the Canvas, specifically Box 4 (User Outcomes and Benefits), forced them to revisit existing customer feedback. They discovered a critical overlooked pattern: customers loved the map, but wanted the product to be more proactive and highlight areas for attention. The Canvas process made them “actually listen” to the data, shifting their priorities from “making the map better” to delivering what customers truly valued. This led to a more effective pilot, accelerating broad release by six months, proving the Canvas’s power in forcing methodical data examination and crucial insights.

Validately: Validating Your Product with Customer Interviews and a Two-Day Prototype:
Serial entrepreneur Steven Cohn launched Validately to streamline user research. Through customer interviews (Box 4), his team discovered researchers spent over 50% of their effort on post-study work (connecting notes to video timestamps, creating highlight reels). This validated a significant problem worth solving.
For the solution (Box 5), they created a clickable prototype in InVision in just two days, hypothesizing a streamlined tool combining note-taking, time tracking, and report/highlight reel creation. This prototype served as their MVP. It effectively answered the “How are you better?” question for potential customers. Critically, Steven used the prototype as a selling tool, asking customers to commit to purchasing the non-existent product on the spot. This secured three levels of validation:

• Time: Customers willingness to spend 30 minutes discussing the problem.
• Social: Customers’ willingness to introduce them to others in their organization.
• Money: Customers’ commitment to purchase.
  This approach validated the solution’s viability and helped build a thriving business.

Kaplan Test Prep: Using Lean UX to Launch a New Business:
Lee Weiss and Liz Laub at Kaplan Test Prep sought to reinvent university partnerships by offering online college and career readiness courses for high school students.

1. Initial Hypothesis/MVP: A PowerPoint deck testing leadership interest. Approved, they got 90 days to explore.
2. Most Important Thing to Learn First (Box 7): University interest.
3. Least Amount of Work to Learn It (Box 8): Simple, serendipitous conversations with universities. Within 90 days, 20 universities engaged, two major ones signed. This provided enough information for a detailed budget request.
4. Product Offering (Box 5): Initial assumptions about real-time interaction were “smashed on the rocks of reality” due to time zones, learned through continuous conversations with students. They pivoted to asynchronous courses, then added cohort-based communities and live mentoring in response to student/parent demand.
5. Organizational Viability (Box 5): Hypotheses about staffing, pricing, and operational costs were initially wrong but refined through iteration.
6. No-Code MVP: They stitched together a lightweight experience using SaaS products (CRM, LMS, CMS) outside Kaplan’s tech ecosystem to move fast.
7. Early Sales & Iteration: The first free course (8 students) got strong positive feedback. But the first paid cohort saw low interest due to a long application and high cost. The team’s one-week sprints allowed rapid experimentation: removing the application fee, shortening the process, and cutting prices in half. Sales quintupled the day changes were made.
8. Outcome-Based Metrics: As they scaled, they defined outcome-based metrics (e.g., 48-hour login rate, 80% course completion, NPS 50) to maintain quality.

This case study powerfully demonstrates how continuous learning, data-driven decisions, and short cycles enable a team with an outcome-based mandate to pivot, scale, and build a successful business unit.

Part III. Collaboration

Chapter 14. Collaborative Design

This chapter explores collaborative design as a cornerstone of Lean UX, emphasizing that the “user experience” is the sum total of all interactions, shaped by every team decision. Therefore, UX design should be a collaborative process, involving designers and nondesigners in cocreation. This approach generates bigger and better ideas than individual contributions, avoiding “design by committee” by ensuring designers orchestrate and facilitate the process, leading to shared ownership and a common understanding of the design problem and solution.

Key aspects of collaborative design:

• Benefits of Collaboration:
  • Yields better results than hero-based design.
  • Increases the product IQ and design IQ of the team.
  • Allows all team members to articulate their ideas.
  • Provides designers with a broader set of ideas for refinement.
  • Builds team-wide shared understanding, which is the currency of Lean UX, reducing the need for extensive documentation.
• Designer’s Role: Designers remain responsible for producing designs but take on the crucial additional role of facilitator, guiding the team through exercises.
• Low-Fidelity Output: Sessions typically produce low-fidelity sketches and wireframes, making contribution accessible to all and maintaining malleability for quick pivots if tests reveal issues.

Collaborative Design: The Informal Approach:
This involves informal chats and sketching sessions, often with a designer and a developer at a whiteboard. An example with Jeff and Greg at TheLadders demonstrates how such a two-hour session can converge on a usable and feasible solution within a sprint, building shared understanding and allowing parallel work to begin immediately.

Conversation: Your Most Powerful Tool:
Lean UX champions conversation as the primary means of communication, aligning with the Agile Manifesto’s emphasis on “individuals and interactions over processes and tools.”

• Unites teams around a shared vision and brings diverse insights early.
• Allows quick challenges to new ideas or changes, which a lone designer might miss.
• Enables parallel work streams (e.g., engineers starting backend infrastructure while design is refined).
• Promotes transparency, building common language and deeper trust among teammates, leading to higher-quality work.
• Cultivating social ties (e.g., shared meals) eases work-related conversations.

Lean UX and Design Sprints:

• Design Sprints: A popular, five-day process (described in Sprint by Knapp, Zeratsky, and Kowitz) that gathers a team to define a question, develop ideas, build a prototype, and test it within a single week. They are “Design Studio on steroids” or a “mini-cycle of Lean UX.”
• Compatibility: Despite some apparent differences (e.g., framing problems, using hypotheses), Jake Knapp affirms deep compatibility. Lean UX is like a “cookbook” for the entire product cycle, while Design Sprints are a “single recipe” for specific moments.
• Flexibility: While the recipe is robust, it can be adjusted after trying the original. The goal is to treat adjustments as experiments and learn from them.
• Strengths of Design Sprints: Excellent for starting big projects, improving product/market fit hunches, building team momentum and alignment, resetting team culture, encouraging risk-taking, fostering customer understanding, and bringing joy to work by focusing on what matters.
• Limitations of Design Sprints: Not for designing every detail or planning the entire development schedule. They don’t replace an MVP or provide a path from zero to launch; they’re best for kicking off a project.
• Using Design Sprints in a Lean UX Process:
  • Reframe work: Go into a sprint with a problem to solve, not a “thing to build.”
  • Articulate assumptions: Use Lean UX to frame hypotheses as input for the Design Sprint.
  • Test assumptions: Use the sprint to break apart, test, and refine these assumptions.
  • Next steps: The sprint’s output becomes input for the next cycle of Lean UX work.

Design Systems:

• Purpose: Design systems are crucial for bringing designs to the pixel level efficiently. They act as style guides on steroids, containing comprehensive documentation of design elements, usage rules, and crucially, the actual code and assets that implement the design. They serve as a single source of truth for a product’s presentation layer.
• Value for Teams:
  • Design faster: Avoid reinvention with pre-built components.
  • Prototype faster: Frontend developers work from a kit of parts.
• Value for Organizations:
  • Increased consistency: Developers use standardized parts, adhering to brand.
  • Increased quality: Centralized design by specialists leads to top-notch results.
  • Lower costs: Investment pays off in increased developer efficiency and quicker onboarding.
• Design Systems Teams are Product Teams: These teams work on an internal product, focusing on adoption (their measure of success). They should use Lean UX methods, leveraging collaborative design to understand user needs (other developers/designers).
• Don’t Skip the Fat Markers: Despite the ease of high-fidelity tools, designers should start with low-fidelity sketches. High-fidelity mock-ups in early stages can bias feedback towards details rather than core concepts. Design systems teams can aid this by providing sketch-fidelity elements in their toolkits.
• Case Study: GE Design System: GE Software (later GE Digital) built the Industrial Internet Design System (IIDS) in 2013 on Bootstrap, scaling design impact. Its success led to Predix, requiring a new system built with Polymer. The design system team grew to 15, working collaboratively with application teams (their users) for six months of prototyping. This hybrid approach—designing with internal users—was key to its evolution, showing that collaborative design takes many forms.

Collaborating with Geographically Distributed Teams:
Physical distance poses challenges, but tools like Zoom, Slack, Mural, and Figma enable real-time and asynchronous collaboration.

• Level the playing field: Insist on tools that allow everyone to participate equally (e.g., shared online whiteboards).
• Create social connections: Build in time for informal chats, social calls, and non-work channels to foster essential social bonds that ease collaboration.

Making Collaboration Work:

• Retrospectives: The most powerful tool for improving collaboration. Regularly scheduled meetings (e.g., end of each sprint) to honestly examine what went well, what didn’t, and what to improve, focusing on actionable changes for the next sprint.
• Team Working Agreements: A continuously updated “rule book” created by the team covering process, ceremonies, communication, culture, conflict resolution, working hours, requirements, development, WIP limits, and deployment. Checked in during retrospectives.
• Psychological Safety: Essential for creative activities like collaborative design. It’s “the shared belief that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.” Without safety, teams can’t experiment and learn effectively.

In essence, collaborative design evolves the UX process by deepening team involvement, fostering shared understanding through techniques like Design Studio and Design Sprints, and leveraging design systems for efficient execution, all while upholding psychological safety.

Chapter 15. Feedback and Research

This chapter details how Lean UX transforms user research into a continuous and collaborative activity, moving away from outsourced, “big bang” studies. The goal is to build deep shared understanding across the entire team, making research bite-sized and integrated into every iteration.

Continuous and Collaborative Research:

• Continuous: Research activities are built into every sprint, minimizing time between hypothesis creation, experiment design, and user feedback.
• Collaborative: Research responsibilities are distributed across the team. Researchers act as expert guides, helping teams plan and lead studies, but not doing all the research themselves. Outsourcing research is discouraged as it filters information, limits team building, and wastes time.

Collaborative Discovery:
This approach gets the entire team (literally and figuratively) “out of the building” to learn from customers directly, multiplying the perspectives for gathering insight.

• Process:
  1. Review: Team reviews hypotheses, assumptions, and MVPs to decide what to learn (Box 7).
  2. Method: Team chooses research method, identifies participants (Box 8).
  3. Interview Guide: Create a concise cheat sheet of questions and topics.
  4. Research Pairs: Team breaks into mixed-discipline pairs (e.g., developer with non-developer).
  5. Tools: Each pair gets MVPs/prototypes to show participants.
  6. Fieldwork: One person interviews, the other takes notes; roles switch halfway. Focus on open questions, conversations, and observations before showing the MVP.
  7. Referrals: Ask participants for referrals to others.
• Example: A PayPal team, including designers, researchers, developers, and a product manager, split into pairs and visited malls to test a clickable prototype. They brainstormed interview guides, conducted two-hour sessions, and reconvened to debrief, instantly seeing patterns and adjusting their design. This built shared understanding for the next sprint.

Continuous Learning:
Addresses the conflict of long-cycle research (e.g., 8-week studies) within short Agile sprints.

• “Done” redefined: Scrum’s insistence on “done” means transparency and value delivery every sprint. For research, this means delivering experience reports, early conclusions, or new questions, rather than waiting for a conclusive “study.”
• Research is never done: High-functioning Agile teams conduct research continuously. Regular customer conversations minimize the time between hypothesis creation, experimentation, and feedback, enabling quick validation. This reduces pressure on individual decisions, as teams know they’ll get market data soon.

Continuous Learning in the Lab: “Three, Twelve, One”:
A weekly rhythm for scheduling qualitative research.

• Monday: Team decides what to test, starts participant recruiting (ideally outsourced).
• Tuesday: Refine design/prototype/product for testing.
• Wednesday: Finalize MVP, write test script, confirm recruiting.
• Thursday: Test! Spend the morning testing with customers (max 1 hour per customer). The entire team observes from a separate location. Immediate debrief with findings after the last participant.
• Friday: Plan next steps based on new insights, deciding whether hypotheses were validated.
• Simplify test environment: No need for dedicated labs; a quiet office space with a computer, webcam, and tools like Zoom suffice. Remote observation is key to spreading customer understanding across the organization.
• Who should watch?: The entire team should observe to absorb feedback in real-time, reducing the need for debriefings and fostering humility and motivation.

Continuous Research: Some Examples:

• ABN AMRO’s Customer Validation Carousel: Weekly speed-dating style research where five customers meet groups of interviewers (designers, product people). 15-minute interviews with topic rotations, followed by a debrief. Learnings are captured in a single-page insight template and added to a shared database, democratizing research.
• “Testing Tuesdays”: A financial services firm researcher started reporting on usability study results at every Sprint Demo, publicizing contents in advance. This increased attendance and grew demand for various types of research, including early-stage formative studies.
• Sperientia Labs: A UX research agency running one-week research sprints, synchronizing with Agile clients. They deliver discovery interviews and usability tests, with a debrief by Wednesday afternoon, and a full report by Friday. This rapid cycle, though qualitative, can build quantitative data over time. They also use two-week sprints for prototype-based questions.

Making Sense of the Research: A Team Activity:
Synthesis of raw data should be a team effort, not outsourced to specialists.

• Review Session: Immediately after research, the team gathers to read notes, transcribe findings onto sticky notes, and sort them into themes. This builds shared understanding.
• Confusion, Contradiction, and (Lack of) Clarity:
  • Look for patterns: Identify consistent user opinions.
  • Place outliers in a “parking lot”: Don’t ignore them, but wait for potential patterns to emerge over time.
  • Verify with other sources: Cross-reference feedback (e.g., customer support emails, site analytics) to confirm validity and assess disproportionate skew.

Identifying Patterns over Time:
Lean UX’s continuous approach means small, regular studies can reveal long-term trends not evident in single, large studies. TheLadders’ team, through weekly job seeker interviews over several years, observed a shift in attitudes towards SMS communication, demonstrating the power of consistent “vital signs” data aggregated over time. This approach allows teams to plan for both urgent and big, long-term questions.

Test What You’ve Got:
Embrace a “test-what-you-got” policy for weekly sessions, using whatever artifact is ready. This liberates teams from perfectionism and provides continuous insight at every stage of design and development. However, feedback type varies by artifact fidelity:

• Sketches: Validate concept value, good conversation prompts. No usability feedback.
• Static Wireframes: Assess information hierarchy, layout, taxonomy, navigation. Some workflow feedback, good for copy.
• High-Fidelity Visual Mock-Ups (not clickable): Detailed feedback on branding, aesthetics, visual hierarchy, calls to action, color palette. No natural interaction or workflow.
• Clickable Mock-Ups: Simulates product experience, good for workflow and observing user interaction. Visual fidelity can vary.
• Coded Prototypes: Highest fidelity for functionality, replicates design, behavior, workflow, can test with real data. Most complex to produce, but authoritative feedback.

Monitoring Techniques for Continuous and Collaborative Discovery:
Beyond direct testing, organizations gather invaluable customer insight from various internal channels:

• Customer Service: The “treasure troves” of daily customer interactions. Reach out, hold regular meetings, tap their product knowledge, incorporate hypotheses into call scripts. An example from Jeff’s past highlights how tracking top customer complaints led to focused UX efforts and continuous feedback.
• On-site Feedback Surveys: Simple email forms, forums, community sites. Repurpose them to count issues, test hypotheses, or recruit users.
• Search Logs: Clear indicators of what customers seek, find, and struggle with. Useful for validating test content on new feature pages.
• Site Usage Analytics: Show how customers use the site, where they drop off, and how they manipulate the product. Essential for understanding real-world context and validating publicly launched experiments. Integrate from day one.
• A/B Testing: Compares two (or more) concepts to see which performs better. Release proposed solutions to small subsets of users, measure performance against a control, and determine if the new idea moved the needle. Small changes are key for clear attribution.

In summary, this chapter provides a detailed roadmap for building a continuous, collaborative research practice that deeply integrates customer feedback into every stage of the Lean UX cycle, driving iterative refinement and validated learning.

Chapter 16. Integrating Lean UX and Agile

This chapter explores the crucial integration of Lean UX with Agile methods, particularly Scrum, acknowledging the common frustration designers face in fitting into these processes. While Agile, born from developers’ need for adaptability (as per the Agile Manifesto’s “responding to change over following a plan”), is the default aspiration for most organizations, its implementation often prioritizes delivery velocity over true agility and continuous learning.

Make the Agile Process Your Own:

• The core of agility: work in short cycles, deliver value each cycle, hold brief daily planning (Daily Scrum), and conduct retrospectives after every cycle.
• Retrospectives are key: Honest, blameless retrospectives are the most powerful tool for building cohesive, cross-functional Agile teams. They provide a regular opportunity to examine what worked and what didn’t, allowing teams to adjust their process based on learned insights, rather than rigidly adhering to prescriptive rules. This fosters true agility.

Redefining “Done”:

• In Scrum, “done” means meeting quality standards and planned functionality (acceptance criteria, definition of done). However, for most Scrum teams, this is where involvement ends.
• Lean UX expands “done” to include “validated with customers.” Software isn’t truly finished until it’s shipped, observed for its impact on customer behavior, and iterated upon based on feedback. This shifts the team’s focus from merely shipping features to making customers successful. Design is integral to this, providing tools to understand and refine solutions.
• Example: Reframing password authentication from “requires password entry” to “percentage of users successfully authenticating on first try is 99% or higher” changes the goal from functional completion to demonstrable customer success.

We’re Still Doing Staggered Sprints. Why?:

• Desiree Sy’s “cycle 0” (or “sprint zero”/”staggered sprints”) model, where design happens one sprint ahead of development, was an early attempt to integrate UX and Agile.
• Misinterpretation: Many teams misinterpreted this as a mini-waterfall, leading to handoffs and lack of collaboration, effectively recreating silos.
• Drawbacks: Leads to teams never working on the same thing simultaneously, relying on documentation, and delaying feasibility assessments (waste).
• Root Causes for persistence: Design teams not integrated into dev, outsourced development, or “cargo cult Agile” (focus on features/deadlines, not learning).
• Staggered sprints are a stepping stone, not an ideal end state, and a symptom of organizations not fully embracing agility.

Dual-Track Agile:

• The most successful model for integrating Lean UX into Agile, where one team performs both product discovery (Lean UX) and product delivery.
• Antipatterns:
  • Separate discovery/delivery teams: Recreates mini-waterfalls, breaks shared understanding.
  • Limited discovery knowledge: Teams resort to suboptimal learning tactics without broader knowledge of tools.
  • Not feeding back delivery evidence to discovery: Symptom of incremental thinking, ignoring post-launch data for future discovery.
• Dual-track works when it’s one team: Discovery (active learning via design/research, passive via analytics) and delivery are performed by the same team. The quantity of each fluctuates based on sprint needs.
• Planning dual-track work:
  • Dedicated designer on every team: Non-negotiable for quality UX and discovery.
  • Design and discovery work is a first-class citizen of the backlog: One backlog for all work (dev, QA, design, research). Differentiates work (e.g., “experiment stories”) but prioritizes all together. Addresses velocity concerns by measuring both delivery and learning velocity.
  • Cross-functional participation in learning activities: Everyone participates to build shared understanding, reduce debrief time, and drive curiosity. Target “exposure hours” (e.g., 2 hours every 6 weeks of direct user contact).

Exploiting the Rhythms of Scrum to Build a Lean UX Practice:
Mapping Lean UX activities onto the Scrum framework helps integrate practices:

• Sprint Goals, Product Goals, and Multi-Sprint Themes: A Product Goal (or multi-sprint theme) guides work over several sprints, linking to a strategic focus. Success is measured by outcomes.
  • Kick off theme with collaborative design: Use Lean UX Canvas and Design Studio to sketch, ideate, and speak to customers, creating a backlog of ideas and defining scope.
  • Subsequent brainstorming: Shorter sessions to use latest insights for next sprint’s backlog.
• Sprint Planning Meeting: Bring Lean UX Canvas and design sprint output to write, estimate, and prioritize user stories.
• Experiment Stories: Represent discovery work in the backlog, making it tangible and forcing prioritization against delivery work. Includes hypothesis, learning tactics, responsible team members, and effort estimate. Allows for “blank experiment stories” for emergent discovery needs.
• User Validation Schedule: Plan weekly user research sessions (e.g., “3 users, 12 noon, once a week”) to ensure constant customer feedback. This creates a natural learning point and rhythm for experiment stories. Use ideation artifacts for testing (sketches for value, high-fidelity for usability).

Designers Must Participate in Planning:
Designers need to participate in sprint planning (and all Scrum events) to voice concerns, negotiate time for design preparation, and ensure their needs are considered. This prevents “Agilefall” and builds shared understanding, which is more productive than delayed debates.

Stakeholders and the Risks Dashboard:

• Proactive communication: Essential for managing stakeholders. The Risks Dashboard is a simple three-column chart (risk, severity/trend, what’s being done) to communicate project status, learnings, and upcoming risks.
• Benefits: Informs stakeholders, drives important decisions, contextualizes discovery with business impact, and highlights blocked progress. An anecdote about PayPal highlights the necessity of informing dependent departments (e.g., customer service) about upcoming changes.

Outcome-Based Road Maps:

• Traditional linear, feature-centric road maps are outdated and output-focused. Agile product road maps are iterative and focus on outcomes.
• Components:
  • Strategic themes: High-level organizational strategies (e.g., “Expand market share in Europe”).
  • Quarterly OKR goals: Outcome-based goals (customer behavior metrics) tied to strategic themes. Defined with leadership.
  • Feature/product hypotheses: Teams’ best guesses for achieving quarterly OKRs, becoming less certain further out. Boxes for future quarters fill as learning from current quarters is synthesized.
• Visualizing work: Puts uncertainty front and center.
• Frequency of Review: Annual review of strategic goals, quarterly check-ins with leaders to assess progress toward outcomes, learn, and adjust plans.
• Measuring Progress: Not by delivered features or deadlines, but by how well customer behavior has changed for the better. Learning drives future backlog ideas and organizational agility. These are living documents, adjusted as reality changes.

Lean UX and Agile in the Enterprise:

• Scaling Agile: A hard problem with few easy answers. SAFe (Scaled Agile Framework) is critiqued as providing an illusion of agility while hardening traditional ways of working, prioritizing production and predictable delivery over continuous discovery and learning. It’s “not Agile” in spirit.
• Truly Agile scaling: Requires leadership to rethink strategy, team assembly, and work assignment, allowing teams to organically find productive cadences and scale incrementally.
• Techniques for Lean UX at scale:
  • Aligned outcomes: All teams on a project share the same overarching success metric, reducing local optimization.
  • Central knowledge management: Wikis, regular leadership meetings (Scrum of Scrums), and open communication tools (Slack channels) for sharing learning and minimizing duplicate effort.
  • Self-sufficient “full-stack” teams: Teams have all necessary capabilities internally, coordinating with discipline-specific meetings but doing work locally.

This chapter comprehensively outlines how Lean UX integrates with Agile practices, offering practical strategies for teams and organizations to embrace a culture of continuous learning and customer-centricity.

Part IV. Lean UX in Your Organization

Chapter 17. Making Organizational Shifts

This chapter asserts that implementing Lean UX requires not just a shift in mindset and process, but also fundamental organizational changes that are not optional. In today’s digital landscape, every business, regardless of industry, is a software business, making the adoption of Lean UX urgent for competitive advantage. Many organizations attempt to scale product development using Agile rhythms but often fail to adopt its core values (collaboration, transparency, continuous learning), leading to “design-as-production” where design value is lost. Lean UX aims to break this cycle, fostering a continuous improvement loop for true organizational agility.

The rise of DesignOps is acknowledged as a movement to operationalize design at scale. However, the chapter warns against “designers have always done it this way” solutions that do not embrace the true spirit of Agile and Lean UX.

The shifts needed are categorized into three areas:

Changing Culture:

• Be humble: Organizations must accept that software is complex and unpredictable, and success cannot be fully predicted upfront. This requires a strong vision coupled with willingness to change course based on market evidence, fostering a safe environment for experimentation, failure, and learning.
• Embrace new skills: Designers must expand beyond tactical UI skills to include facilitation as a core competency. This means designers opening up the design process to team input and taking a leadership role in conceptualizing products collaboratively, showcasing synthesizing capabilities.
• Create open, collaborative workspaces: Break down physical and virtual barriers. Colocate teams in open spaces with whiteboards, or provide tools for distributed teams that allow for easy communication and shared work. The aim is to make spontaneous collaboration effortless.
• No heroes: Lean UX demands team-based collaboration over individual “rock stars.” The concept of design as a hypothesis inherently dethrones heroism, as designers must embrace failure and iteration. The focus shifts from individual recognition (e.g., awards for glossy deliverables) to collective problem-solving and validated learning.
• Fall in love with the problem, not the solution: Designers must shift their pride from perfecting “finished” artifacts to demonstrating their problem-solving skills and the journey from idea to validated learning. Organizations should value problem-solvers and their ability to adapt designs based on evidence.
• Evolve agency culture: Traditional agency models (paid for deliverables, high utilization, hero design) conflict with Lean UX. Agencies must transition to time-and-materials or outcome-based contracts and foster deep client-agency collaboration, pulling clients into the process earlier and more frequently. Development partners must also be involved from the start.
• Be realistic about your environment: Change can be scary for managers. Implement Lean UX by asking for forgiveness, not permission, proving value through quantifiable success. If organizational resistance to change remains, consider alternative employment.

Shifting Team Organization:

• Think competencies over roles: Move away from rigid job descriptions that silo individuals. Encourage team members to contribute across disciplines based on their secondary competencies, fostering more engaged and efficient teams.
• Create cross-functional teams: Break down single-discipline “hideouts.” Put product managers, developers, QA, designers, and marketers on the same team, working towards a common goal at the same level. This reduces reliance on detailed documentation and speeds up learning. Robert Dailey’s study (late ’70s) linked productivity to task certainty, task interdependence, team size, and team cohesiveness.
• Create small teams: Adopt “two-pizza teams” (Jeff Bezos), where team size necessitates focusing on smaller problems, making it easier to maintain MVP discipline. Large tasks are broken down and aligned to a single outcome across several small teams, encouraging self-organization.
• Work with distributed teams: If colocation isn’t possible, provide tools for seamless communication and collaboration (Zoom, Slack, Mural, Dropbox). Crucially, ensure sufficient time zone overlap for daily conversations and collaborative exercises. Occasional in-person meetings are also valuable.
• Build flexibility into third-party vendor relationships: Traditional fixed-scope contracts with outsourced development conflict with Lean UX. Opt for time-and-materials or outcome-based contracts that allow for flexibility and responsiveness to learning. Choose vendors willing to embrace experimentation and iteration over strict production.

Shifting Process:

• Plan work using outcomes, not output: Leadership must define outcomes, not just feature road maps. Teams must be empowered to decide which features best achieve these outcomes, shifting conversations from fixed scope/deadlines to customer behavior as a measure of success.
• Beware of BDUF sneaking into Agile environments (Agilefall): Recognize this as a “new disguise” for Big Design Up Front, where an up-front design phase is handed off to engineering. This removes essential collaboration and leads to waste, as it prioritizes predictability over embracing change. Push for outcome-based conversations to dismantle this.
• Embrace speed first, aesthetics second: Prioritize getting ideas out quickly for validation. Ask: “Who do I need to communicate with? What’s the least amount of work I need to do to communicate that?” Polish and aesthetics are vital for finished products but can be wasteful in early-stage artifacts.
• Tackle UX debt: Treat UX debt (unimproved UI) like technical debt. Create “UX debt” stories in the backlog. For large-scale issues, create “current” and “ideal” customer journey maps, identify gaps, and assign UX debt stories to responsible teams, ensuring continuous improvement of the user experience.
• Rethink documentation practices: While regulatory compliance may demand documentation, avoid letting it block progress. “Lead with conversation, and trail with documentation.” Conduct informal discovery, then formalize documentation as designs solidify, capturing decision history for future teams.
• Manage up and out: Proactively communicate project plans and progress to stakeholders and other departments (customer service, marketing, parallel business units). This informs them, allows them to do their jobs better, and reduces resistance to change, ensuring smoother validation cycles. The Risks Dashboard is a key tool for this.

This chapter underscores that successful Lean UX adoption requires a holistic transformation across an organization’s culture, team structure, and core processes, fostering adaptability and continuous improvement.

Chapter 18. Lean UX in an Agency

This chapter specifically addresses the unique challenges of implementing Lean UX within an agency setting, where the primary obstacle is often the client relationship and the agency’s traditional business model. Agencies, defined as organizations selling services to clients, must navigate client expectations and internal structures that conflict with Lean UX’s collaborative, outcome-focused approach.

What Business Do You Want to Be In?

• Conflict with Deliverables Model: Most agencies are in the deliverables business (paid for designs, prototypes, software), which directly conflicts with Lean UX’s focus on outcomes. This model encourages functional silos and “project phases” to maintain high utilization (keeping people billable).
• Transforming the Business Model: Agencies must move away from exclusively selling deliverables. Instead, consider time-and-materials agreements or, more radically, outcome-based contracts. The agency doesn’t sell “an app” but a collaboration to discover the best solution to a client’s problem.
• Team Structure for Agencies: Propose small, fixed-cost teams (e.g., 4 people: product manager, designer, two developers) for finite, renewable periods (e.g., 3-month blocks). This reinforces short cycles, reduces agency risk (easy to end bad fit engagements), and allows flexible internal staffing without client re-approval.
• Staffing Impact: This business model shift also affects current and prospective staff, as it changes the “way of working” promised by the agency. Agencies must ensure clients align with this Lean UX approach to retain staff.

Selling Lean UX to Clients Is All About Setting Expectations:

• Clients often expect the traditional “throw it over the wall” agency relationship. Agencies must proactively differentiate themselves.
• Consistent Communication: Embed your Lean UX approach in your brand, marketing, website, and content (blogs, publications, social media).
• Early, Frequent Conversations: From the first in-person meeting, explain how you work and why it’s critical for customer-centered results. If clients indicate they haven’t “digested” this collaborative model, pause and re-explain before signing the contract.

Nobody Wants to Buy Experiments:

• Clients want tangible products (apps, software, designs), not “experiments” which they perceive as risky failures.
• Reframing the Pitch: Avoid leading with “experiments.” Instead, highlight the outcome that the Lean UX process achieves (e.g., “Our process ensures we make the best decisions to help solve your mobile commerce challenge”). Experiments are a tactic, not the desired end result.

You Made the Sale! Now Navigate Procurement:

• Even after client buy-in, the procurement department often reverts to traditional fixed-scope, deliverable-based contracts (“What are the specific deliverables we will get in return? And on what date?”).
• Pre-contract Discussion: Clients must understand the need to move away from fixed-scope contracts towards time-and-materials or (rarely) outcome-based contracts. The latter offers variable payment based on the agency’s ability to generate the agreed outcome, though usually with an upper limit. This grants agencies the flexibility to iterate towards meaningful, high-quality solutions.

You’re Not an Outsourcing Partner Anymore:

• With Lean UX, the agency becomes a collaboration partner. The client is no longer passive; they become an active member of the team.
• Client Engagement: Clients must commit to regular participation in stand-ups, decision-making meetings, and product discovery efforts. The agency should emphasize that the client (e.g., product owner) holds responsibility for backlog prioritization.
• Physical Co-location: Insisting on the client setting up shop in the agency’s studio can remove daily distractions and reinforce the collaborative team dynamic.
• Contractual Commitment: These high levels of client engagement must be explicitly stated in the contract. Without client presence in discovery, synthesis, and decision-making, the agency is forced back into a document-heavy, approval-based process.
• Firing Bad Clients: The authors share an anecdote about firing a financial services client who, despite agreeing to terms, created obstacles to collaboration (limited access, tried to recreate their own culture). This highlights the importance of protecting team integrity and refusing to work in ways that compromise the Lean UX approach.

A Quick Note About Development Partners and Third-Party Vendors:

• Mandatory Early Involvement: Development partners (internal or third-party) must participate throughout the project lifecycle, not just during a “development phase.” They must be side-by-side with designers, not passive observers.
• Flexibility in Vendor Contracts: Prioritize time-and-materials contracts for third-party vendors to allow for iterative changes inherent in Lean UX.
• Vendor Selection: Choose development shops that embrace experimentation and iteration, understanding the difference between prototyping for learning and developing for production.

In conclusion, transforming an agency to Lean UX demands a dual shift in business model and culture, proactive expectation setting with clients, and a deep commitment to collaborative partnership over traditional outsourcing.

Chapter 19. A Last Word

This concluding chapter reflects on the persistent feedback from readers of earlier editions: that while individuals could adopt Lean UX methods, true transformation required organizational change driven by leaders, a daunting challenge for many. The authors aim to provide a starting point for addressing this.

The Product that Makes the Product:

• Inspired by Barry O’Reilly, the chapter posits that a product development organization is “the product that makes the product.” This means organizational development can be approached using the same Lean UX tools as product development.
• Applying Lean UX to Organizational Change:
  • Define Outcomes: Clearly articulate the desired organizational change in terms of a measurable outcome (e.g., “on future research projects, ensure every team member participates in at least one direct customer interview session” or “in the next quarter, half of the epics we work on will be defined by a user outcome rather than a feature list”).
  • Experimentation: Treat desired changes as hypotheses and run “minimum viable process” experiments to find the right way to achieve the outcomes. This involves designing new processes for new “users” (stakeholders, peers, collaborators).

The chapter concludes on a positive note, affirming that change is possible and that individuals, even without formal authority, can initiate transformation by enlisting collaborators and applying Lean UX principles to their internal processes. It reiterates the authors’ pleasure in seeing Lean UX adopted and their continued desire to hear from readers about their journey.

Key Takeaways

Lean UX fundamentally redefines how products are designed and developed, shifting the focus from rigid requirements and deliverables to continuous learning, collaboration, and measurable outcomes. It’s about building agility into the very fabric of an organization.

The core lessons to remember are:

• Outcomes over Output: Success is measured by positive changes in customer behavior and business value, not by the completion of features or documents.
• Embrace Assumptions and Experimentation: Recognize that everything is an assumption until proven. Use hypotheses and Minimum Viable Products (MVPs) to test ideas quickly and cheaply, learning from failure.
• Continuous, Collaborative Everything: Design, research, and learning should be ongoing, bite-sized activities involving the entire cross-functional team, fostering shared understanding and reducing waste from handoffs.
• Problem-Focused Teams: Empower teams to solve problems, rather than just build solutions, giving them ownership and driving iteration until the problem is truly solved.
• Cultivate Humility and Psychological Safety: Accept that initial ideas will be wrong. Create an environment where teams feel safe to experiment, fail, and learn without penalty, promoting creativity and innovation.
• Optimize for Learning and Agility: Speed is valuable for accelerating the learning loop, not just for faster delivery. Adjust plans based on new insights, rather than rigidly adhering to predetermined roadmaps.
• Organizational Shifts Are Essential: True Lean UX adoption requires changes in culture, team organization, and process, moving away from traditional silos and fixed-scope thinking towards adaptability and customer-centricity.

Next actions you should take immediately:

• Start with the Lean UX Canvas: Use it for your next initiative to frame the problem, define outcomes, identify users, brainstorm solutions, and articulate testable hypotheses. This will immediately shift your team’s conversations.
• Integrate weekly user conversations: Even if it’s just “three users every Thursday,” commit to a regular cadence of direct customer interaction. Have your whole team observe.
• Lead a “Risks Dashboard” session: Proactively communicate the major risks and learnings of your project to stakeholders, shifting their focus to outcomes and building trust.
• Refactor your team’s “definition of done”: Work with your team to expand it to include “validated with customers,” focusing on behavioral changes and measurable impact.

Reflection prompts:

• In what areas of my current work am I prioritizing output over outcomes?
• How can I empower my team, or myself, to take more risks and learn from “failure” in a safe way?
• What is one small collaborative change I can initiate this week to foster shared understanding with my colleagues and customers?