Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

A problem-focused team is one that has been given a business problem to solve, as opposed to a set of features to implement. In other words, this is a team that has been organized around an outcome.

rather than focus on the feature, it’s better to focus on the value we’re trying to create, and keep testing solutions until we find one that delivers the value — the outcome — that we desire.

If you’re familiar with Test-Driven Development (TDD), hypotheses are very similar. They are, in a way, a form of Test-Driven Product Design and Development.

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

Users

User outcomes

Features

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

Figure 3-2. Problem statement template for existing products and services

New product: problem statement template 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

Problem statement template for new products and services

(null)

Assumptions Worksheets

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].

Feature hypothesis template

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?

Does the customer exist?

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

Would they value a solution to this problem?

What is the user trying to accomplish?

How does the user want to feel during and after this process?

How does our product or service get the user closer to a life goal or dream?

to generate many ideas in silence

We’re looking for features we think will help users achieve the user outcomes they seek.

we measure success by how well our customers can achieve “some goal” initially and ongoing.

Ajax and jQuery events,

What’s the most important thing we need to learn first (or next) about this hypothesis? In other words, what’s the biggest risk currently associated with this approach? What’s the least amount of work we can do to learn that? This isn’t lazy: it’s Lean. There’s no reason to do any more work than you need to in order to determine your next step.

with some (like Axure), you can create basic data-driven or conditional logic-driven simulations.

the ideal result of a design sprint is a backlog of hypotheses.

You can recognize a lack of shared vision when the team argues about what features are important or what should be done first.

For Lean UX to succeed, your organization needs to adopt a mantra of “competencies over roles.”

there must be some block of time every day during which colleagues can have conversations and participate in collaborative exercises.

“Speed first, aesthetics second.”

In Lean UX, working quickly means generating many artifacts.

SHIFT: Fall in love with the problem, not the solution

Teams need to embrace the concept of UX debt and make a commitment to continuous improvement of the user experience.