A short read on the use of lean methodologies to design digital products. Design only what you need, deliver it quickly and maintain enough customer contact to get meaningful feedback fast.
The Lean principles underlying Lean Startup apply to Lean UX in three ways
- Help remove waste from UX design process
- Harmonize our “system” of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration.
- Mindset shift we gain from adopting a model based on experimentation.
Part 1: Introduction and Principles
Foundations of Lean UX
Innovation powered by...direct observation of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported...[It’s] a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity. — Tim Brown, IDEO CEO
Agile Software Development
Four core principles:
- Individuals and interactions over processes and tools.
- Ideas must be exchanged freely and frequently.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
Lean Startup uses a feedback loop called “build-measure-learn” to minimise project risk and gets teams building quickly and learning quickly (build and ship MVPs quickly to start learning ASAP).
“Lean Startup initially advocates the creation of rapid prototypes designed to test market assumptions and uses customer feedback to evolve them much faster than more traditional software engineering practices...Lean Startup processes reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible.” — Eric Ries
Bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed.
- Cross-Functional Teams — the creation of these diverse teams collapses the gated-handoff process known as waterfall.
- Small, Dedicated, Colocated — dedicate them to one project and staff it all out of the same location.
- Progress = Outcomes, Not Output — features and services are outputs. The business goals they are meant to achieve are outcomes.
- Problem-Focused Teams — a problem-focused team is one that has been assigned a business problem to solve, as opposed to a set of features to implement.
- Removing Waste — (lean manufacturing) team resources are limited.
- Small Batch Size — creating only the design that is necessary to move the team forward and avoiding a big “inventory” of untested and unimplemented design ideas.
- Continuous Discovery — the goal is to understand what the users are doing with your products and why they are doing it.
- GOOB: The New User-Centricity — "getting out of the building.” Speak to customers. The sooner you give them a voice, the sooner you’ll learn whether you’ve got an idea that’s ready to be built.
- Learning over Growth — ensuring that an idea is right before scaling it out mitigates the risk inherent in broad feature deployment.
- Permission to Fail
- Getting Out of the Deliverables Business — less about what artefact is being created and more about which outcome is being achieved.
Part 2: Process
Vision, Framing and Outcomes
The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements: assumptions, hypotheses, outcomes, personas, features.
Assumptions (problem statement)
The problem statement gives your team a clear focus for their work and defines any important constraints.
- The current goals of the product or system
- The problem the business stakeholder wants addressed (i.e., where the goals aren’t being met)
- An explicit request for improvement that doesn’t dictate a specific solution.
[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?
Transform each assumption statement into a format that is easier to test: a hypothesis statement.
We believe [this statement is true]. We will know we’re [right/wrong] when we see the following feedback from the market: [qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].
High-level outcomes you are hoping to achieve (e.g., increasing signups, increasing usage, etc.).
Consider how you could break them down into smaller parts.
Unconventional method: start with assumptions and then do research to validate our assumptions.
As we learn from our ongoing research, we quickly find out how accurate our initial guesses are, and how we’ll need to adjust our target audience (and persona)—and thus our design.
Method: team brainstorm, arrange post it's into themes.
We’re looking for features we think will drive customer behavior in the desired direction.
Method: Design Studio — a way to bring a cross-functional team together to visualise potential solutions to a design problem.
Design Studio follows this path:
- Problem definition and constraints
- Individual idea generation (diverge)
- Presentation and critique Iterate and refine (emerge)
- Team idea generation (converge)
MVPs and Experiments
Create the smallest thing you can to determine the validity of each of these hypothesis statements.
Is there a need for the solution I’m designing? Is there value in the solution and features I’m offering? Is my solution usable?
- Be clear and concise
- Stay agile
- Measure behavior — Build MVPs that allow you to observe and measure what people actually do, not just what people say. In digital product design, behavior trumps opinion.
- Use a call-to-action
- Be functional
The mantra to keep in mind when creating non-prototype MVPs is this: you can always go leaner.
To plan your MVP, ask yourself the following questions:
- What am I trying to learn?
- What are the main signals I need from the market to validate my hypothesis?
- What’s the fastest way for me to find this information?
Feedback and Research
Lean UX research is
- continuous; this means that you build research activities into every sprint.
- collaborative: you don’t rely on the work of specialised researchers to deliver learning to your team.
A critical best practice in Lean UX is building a regular cadence of customer involvement.
As soon as possible after the research sessions are over—preferably the same day, or at least the following day—gather the team together for a review session.
- Look for patterns As you review the research, keep an eye out for patterns in the data.
Customers can provide feedback through many channels
Customer support agents talk to more customers on a daily basis than you will over the course of an entire project. Involve them (e.g. reach out, monthly meetings).
A few tactics for getting other points of view:
- Search logs — clear indicators of what customers are seeking on your site.
- Site usage analytics — show how customers are using the site, where they’re dropping off, and how they try to manipulate the product to do the things they need or expect it to do.
- A/B testing — gauge which of two (or more) relatively similar concepts achieve a goal more effectively. The trick is to make sure that the changes you’re making are small enough that any change in behavior can be attributed to them directly. If you change too many things, any behavioural change cannot be directly attributed to your any one hypothesis.
Part 3: Making It Work
Integrating Lean UX and Agile
- User Story — As a [user type]. I want to [accomplish something]. So that [some benefit happens].
- Backlog — A prioritised list of user stories. It is through the active grooming of the backlog that the team manages their daily workload and refocuses their efforts based on incoming knowledge.
Managing Organisational Shifts
Shifting from output to outcomes
- Lean UX teams measure their success not in terms of features completed but in terms of progress toward specific outcomes.
Moving from limited roles to collaborative capabilities
- Adopt a mantra of “competencies over roles.”
Embracing new skills
- Designers must add facilitation as one of their core competencies.
- Designers must bring teams into the design process, seek their input, and build that insight into the design.
Placing speed first, aesthetics second
- By sacrificing the perfection of intermediate design artefacts, your team will get to market faster and learn more quickly which elements of the whole experience are working for the users and which aren’t.
Image credits: Lean UX by Jeff Gothelf & Josh Seden