Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

Principle: GOOB: the new user-centricity

Test your ideas with a strong dose of reality while they’re still young. Better to find out that your ideas are missing the mark before you’ve spent time and resources building a product that no one wants.

Ultimately, the success or failure of your product isn’t the team’s decision — it’s the customer’s.

Principle: externalizing your work

Externalizing means getting your work out of your head and out of your computer and into public view. Teams use whiteboards, virtual shared spaces, foam-core boards, artifact walls, printouts, and sticky notes to expose their work in progress to their teammates, colleagues, and customers.

Principle: making over analysis

There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room.

Debating ideas without market-based data is waste. Instead of analyzing potential scenarios, make something and get out of the building with it.

Principle: getting out of the deliverables business

Traditionally, software projects are framed by requirements and deliverables.

In many cases, the strategic context for those requirements is not communicated, is missing, or is simply not considered. Lean UX radically shifts the way we frame our work by introducing back the strategic context for our feature and design choices and, more important, how we — the entire team, not just the design department — define success.

Our goal is not to create a deliverable or a feature: it’s to positively affect customer behavior or change in the world — to create an outcome.

the first step in the Lean UX process is to explicitly declare your assumptions. Every project starts with assumptions, but mostly we don’t acknowledge this fact. Instead, we try to ignore assumptions, or worse, treat them as facts.

There are four types of assumptions that are particularly important in Lean UX:

Business outcomes

Users

User outcomes

The goals of the people for whom we are building products. These can be end goals (e.g., completing a specific task), emotional or experience goals (e.g., not feeling like a technological luddite), or long-term goals (e.g., keep as much of my money so I can retire comfortably).

Fea...

By working together in this cross-functional capacity you are raising the Product IQ of the entire team. Team members not only get to voice their opinions and concerns, but equally as important, they get to hear other points of view. This moves team members away from discipline-specific views of the product to a more holistic, product-focused one.

Give the team advance notice of the problem they will be taking on. Provide them the strategic context for the work to ensure that their tactics agree with the broader goals of the organization.

Important things to prepare in advance include the following: Analytics reports that show how the current product is being used Usability reports that illustrate why customers are taking certain actions in your product Information about past attempts to fix this issue and their successes and failures Justification from the business as to how solving this problem will affect the company’s performance Competitive analyses that show how your competition is tackling the same issues

The team needs to have a starting point for the exercise. We’ve found it helpful to begin with a problem statement. (See the templates for this statement that follow.) These statements are created by key stakeholders as they begin to address the strategic vision for the business.

Problem statements for existing products are made up of three elements: The current goals of the product or system The problem the business wants addressed (i.e., where the goals aren’t being met) An explicit request for improvement that doesn’t dictate a specific solution

Finally, it provides clear guidelines for how the team should proceed without dictating a specific set of features for them to build, instead opting for an outcome, a change in customer behavior, for them to achieve.

Problem statements for new products are also made up of three elements (see Figure 3-3): The current state of the market The opportunity the business wants to exploit (i.e., where current solutions are failing) A strategic vision for a product or service to address the market gap

Generally, hypothesis statements use this format: 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].

The first field is completed with the outcome you’ve determined is your measure of success. This is the business outcome you’d like to achieve. The second field describes exactly which of your target users you believe you should focus on first. The third field speaks to the end goal, benefit, or the emotional state those customers will get if we design and implement our feature well. The final field speaks to the way we believe we should improve our product or the new features we’d like to build.

It’s easy to jump to features first. Most teams do this. By structuring your conversations with hypotheses you force the team to think through the context first, and especially, the problem you’re trying to solve. This constrains the space for determining which features to work on. Each assumption you put in place increasingly confines the team’s thinking to a more accurate set of potential features. This focus makes any feature discussion more productive, more targeted, and ultimately more relevant to your customers.

To create your hypothesis statements, you will need to begin assembling the building blocks. Here is what you are going to want to put together: The business outcomes you are trying to achieve The users you are trying to service The user outcomes that motivate them The features you believe might work in this situation

The Startup Metrics for Pirates framework is condensed into the acronym AARRR (Pirates!) and, when expanded, looks like this: Acquisition Can we get customers to our new feature or product? Activation After we get them there, can we get them to use it? Retention Can we get them to use it again? And again? Referral Can we get them to tell their friends, colleagues, bosses, or others about it? Revenue Can we get them to pay us for this feature?

three different measures of success:

Output These are features we design, implement, and ship. As a measure of success they are very common because they are clearly visible and easy to measure (you either shipped the feature or you didn’t). What they don’t measure is value to the customer. They only capture the team’s delivery performance.

Outcome This is the change in the world we hope to see after we’ve created the output. As a measure of success, these are rare primarily because they are not binary and instead operate on a sliding scale. If a team is asked to improve retention by 50% but only manages to ...

Impact These are high-level measures of business health. Most companies measure these in the form of revenue, profits, sales, Net Promoter Score, and so on. As a measure of team-level success, these are usually too high level because it is often difficult to attribute a direct correlation between the launch of a tactical feature or a system optimization and an impact-level improvement. There are far too many factors that regularly...

We also change persona-creation from a one-time activity to an ongoing process — one that takes place whenever we learn something new about our users.

Instead of spending months in the field interviewing people, we spend a few hours creating proto-personas. Proto-personas are our best guess as to who is using (or will use) our product and why. We sketch them on paper (Figure 3-7) with the entire team contributing —

Remembering we are not the user It is often easy to assume our users are like us — especially if we consume the products we make. The reality is that we have a level of understanding and tolerance for the digital ecosystem that our customers rarely share.

Remember that users rarely need “features.” What they need is to attain some kind of goal. (It’s not always a concrete goal: sometimes it’s an emotional goal, an unarticulated desire, etc.) It is our job to decide how best to get them to their goals.

we like to start the persona creation process with a brainstorm.

After you’ve narrowed down the list of potential users, have the team complete the template for each one. Review this internally and, upon agreement, share with your colleagues beyond the team for their initial input. At this point in the process, you can begin to validate some of your early assumptions.

Immediately, there are three things you can determine based on your proto-personas: Does the customer exist?

Do they have the needs and obstacles you think they do?

Would they value a solution to this problem?

As new information is revealed, bring it up for discussion and adjust the personas so that future research efforts can be more targeted and more successful.

Despite the proliferation of Agile techniques like user stories, the user and their goals often become lost in the lengthy debates over features, designs, and implementations. Empathy is at the heart of great products and services. Designers often have been responsible for advocating for the user from an empathetic point of view. As we now know, this is not uniquely a designer’s responsibility. To achieve broader shared understanding of users and a deeper sense of empathy for what they are trying to achieve, we ask our teams to declare their assumptions about what users are trying to do, in the form of user outcomes.

User outcome brainstorming process: Again, sticky notes and whiteboards are our preferred tools here (see Figure 3-11). Allow individuals on the team to generate many ideas in silence and then organize those ideas with an affinity mapping exercise to drive the team toward convergence.

In Lean UX, features exist to serve the needs of the customer and the business.

Feature brainstorming process:

Have each team member write each idea, using a thick felt pen, on a sticky note. When time is up, ask everyone to post their notes to the wall. Finally, have the group arrange them into themes.