The Lean UX Process
Lean UX: Designing Great Products with Agile Teams
Prioritize learning over delivery and outcomes over deliverables. Maintain a position of humility to enable openness to learning.
Lean UX Principles
Lean UX is the way you do design in an Agile process
Lean UX teams work “collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback.”
Our goal is not to create a deliverable, it’s to change something in the world–to create an outcome.
Lean UX focuses on shared understanding that is embodied in working software which can be tested with users rather than detailed design documentation.
The beginning of a Lean UX project is a hypothesis statement which clarifies vision and goals for the team and company leadership. It shifts the emphasis from outputs to outcomes. The hypothesis statement has four parts: assumptions (things we believe to be true); hypotheses (areas of the product we are targeting); outcomes (qualitative or quantitative criteria that will prove or disprove the hypotheses); personas (sketches of the type of customer we are serving); and features (the functionality that we believe will achieve the outcomes we have identified).
The overall process cycles between declaring assumptions, creating an MVP to test a hypothesis, running the experiment to prove or disprove the assumptions, and establishing a process for continuous customer discovery.
Assumptions
The first step of the process is to document and review your assumptions. The assumptions you make about your customers, their problems, and your desired outcomes are the basis for the hypotheses you will test during the Lean UX process. Identifying assumptions is a group activity which benefits from different perspectives.
Problem statement
The problem statement includes the current goals of the product or system. The problem can be something that business stakeholders are requesting or it can be an explicit request for improvement. Gothelf provides a template for the problem statement
[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]?
Gothelf advises teams to dissect their problem statement and excavate the embedded assumptions. There’s a “business assumption” worksheet in the book with some suggested questions to help surface the assumptions behind the business problem at hand.
Prioritizing and testing assumptions
The higher the risk and the more unknowns involved, the higher the priority to test those assumptions.
Because Lean UX is “a process of ruthless prioritization”, assumptions should be ranked based on level of risk and number of unknowns. Assumptions with the most unknowns and the highest risk should be tackled first.
Hypotheses are created from the assumptions the team identifies early in the process. This allows tests to be built. This process is analogous to test-driven development in which tests are written before the code.
Proto-personas
In the spirit of Lean and Agile methodologies, Gothelf argues against protracted user research which takes many weeks or months to develop an expensive deliverable which seeks to define personas. Rather, he advocates creating a rough sketch of proto-personas and then talking to customers to validate or invalidate the hypotheses around user types.
Collaborative design
Gothelf advocates collaborative design exercises in which designers and non-designers participate in co-creation. He calls conversation “your most powerful tool.” The book outlines a design studio process which starts with a problem definition and list of constraints, then moves to individual idea generation, presentation of ideas and a critique by the group, then iteration of the ideas and refinement, and finally team idea generation and choice of final designs.
Experimentation
Create the smallest thing possible to test your hypothesis
Experiments can be run with a variety of prototypes, features, or product versions. Gothelf has the team ask: is there a need for the solution I’m designing?, is there value in the solution and features I’m offering?, and is my solution usable? These key questions set the tone for prototype development and experiments. To start with, teams should ask themselves: what am I trying to learn? This will guide the type of questions and prototype to put in front of users.
Continuous Customer Discovery
Your team must adopt a “test everything” policy
The Lean UX process relies heavily on repeatable and continuing feedback and research with customers. Gothelf gives the example of a team which schedules three customer interviews/research activities each Thursday. This relies on a regular cadence of identifying assumptions to learn about, creation of interview questions, and recruiting users for in person meetings. Documentation and communication ensure that information is disseminated to the entire team. Gothelf says to look for patterns, put aside outliers, verify findings with other sources of data in order to make sense of the data will come out customer conversations.
5 Years of Lean UX
In this video, Gothelf reflects on five years of Lean UX practice. In his early career, he says a lot of his time was spent making documents and “half of what I designed got built, and the other half was thrown away.” This resulted in a lot of waste. During this time, he attempted to take a waterfall process and compress it into two week sprints. At one point, his team had a meeting without him and created a document which outlined all their frustrations with Agile, design, engineering, and product management practices. The document and subsequent conversations spawned what would be later called Lean UX. Lean UX began with Gothelf’s article about “getting out of the deliverable business?”
As the Lean UX conversation started, two themes emerged: design had to change and stop being a black box; product development had to change.
Design must change by moving away from archives towards transient artifacts (what’s the least amount of design do I need to do to convince my audience of something) which enable conversations. Artifacts must be produced quickly in order to facilitate progress and conversations. The second thing about design which needed to change is enabling radical transparency (no more black boxes to enclose the design process). Similarly, non-designers can no longer be excluded from the design process. Lastly, design research must move away from interrogation and towards informal continuous discovery. Gothelf tells the story of being in AOL Design Reviews in which each of 25 VPs in the room needed to justify their existence by offering design feedback. Rather than waiting for monthly design reviews, Lean UX shortens the duration between informal design conversations.
Continuous learning enables a continuous conversation
Product development changes by modifying the way that success is measured. Previously, shipping was the definition of success. We did not ask “so what?” Product management had to redefine their definition of success to positively impacting customer behavior. With on-line software, we can build continuous learning into the product development process because we can deliver continuously. This allows companies to start a conversation with the market and change the pace of learning. Gothelf says Shipping and Sensing are easier because those two activities are amenable to willpower and resources. However, responding requires organizational maturity and the willingness to be wrong and adjusting. This requires humility and acknowledging that you don’t know how your product or service will end up.
Gothelf gives an example of humility when he sent a frustrated tweet to Microsoft and a member of their design studio replied to him, acknowledged the challenges, and requested help. In terms of proposing options to customers in the context of use and learning directly, he talks about how MapMyRun offers a social photo posting feature when the user pauses the application. This allows MapMyRun to test intent, value proposition, intent to purchase, and price. Gothelf says that humility puts you in the position to learn effectively because you ask first and build later. A position of humility allows you to say: “we are going to see what happens and let ideas emerge from the system itself.”
It doesn’t matter how many times you’ve been right in the past, you have to maintain that position of humility in every new initiative that you take on
Gothelf talks about the amazon fire phone–he says that one of the reasons it failed was because Jeff Bezos threw out the key amazon principle of customer first and made a huge assumption about the amazon brand being equal to the apple brand. He says apple is an aspirational brand while amazon is a utility. When asked why they built the product in a Fast Company interview, members of the team said “because Jeff wanted it.” Gothelf acknowledges this perspective because Bezos created the largest ecommerce company which spawned the largest cloud services company so why wouldn’t the be right about the phone? Gothelf says: “they lost that position of humility that says: we might not be right.”
You don’t increase the investment until you’ve got truth
He then goes on to talk about Giff Constable’s “The Truth Curve” which depicts an effort as starting out as a fantasy and progressing through a learning curve until the final product is created. Due to the iterative nature of development and learning, research becomes part of product development. The previously monolithic chunk of user research is divided up into smaller parts throughout the entire product lifecycle. This builds responsiveness and agility into your organization. Customer discovery and customer data gives you objectivity–decisions are no longer based on force of personality or past track records of delivery.
The definition of success is changing customer behavior.
