Lean UX is about reducing risk

Lean teams are already geared toward building marketable products more efficiently and with less risk, but Lean UX will get you there faster and with less guess work.

If you’ve worked in a Lean product environment for any period of time, you’ve likely heard that Lean is superior to big-bang product development approaches because Lean is focused on building marketable products faster and with less waste. By involving customers earlier, iterating on solutions with them with them frequently, and (based on this data) validating product hypotheses, Lean teams ensure they’re building the right thing for the right audience. This iterative feedback cycle, known as “Build, Measure, Learn”, defines the Lean product development process.

The cornerstone of the “Build, Measure, Learn” is customer validation. Validating a product hypothesis ensures that you’re efforts are not wasted, and furthermore, that ongoing development of said component is worthy of pursuing. Because of this, a notable benefit of Lean development is reduced product risk.

The diagram above is a version something we show to clients at Pivotal Labs. Its goal is to illustrate that delayed customer validation results in increased risk for a product. The longer you go without validating ideas with customers, the riskier your assumptions become, as you pile on risky assumption atop of risky assumption. Lean reduces this risk throughout the product development journey by frequently validating shippable components of a product with customers.

However, there is an important caveat here…

Engineering work is expensive (even if you’re Lean)

What isn’t discussed in the refreshing simplicity of “Build, Measure, Learn” is the inherent risk in the Build phase, where most teams start after forming a hypothesis. Software development takes time, and even small tests can translate into weeks (or more) of engineering effort. This results in opportunity costs for an engineering team who could be working on less-risky endeavors.

While you may be mitigating long-term product risk by validating concepts with customers after build, you still have to build the thing in the first place. Even if the feature you’re testing is a painfully bare-bones version of your original vision (which you should be doing anyway), you’re still spending time and money which could be spent doing other things.

Lean UX starts with “Learn”

So, if engineering work is costly, but how else can a team test their proposed feature or product with a customer? By starting with “Learn” instead of “Build” to validate concepts earlier. This is where Lean user experience design can help mitigate risk: it is faster and cheaper for a design team to validate a hypothesis compared to an engineering team.

Lean UX is different from classical UX in that it is modeled around rapid experimentation. Rather than spending long cycles on a hypothesis, Lean UX focuses on small, incremental tests with the goal of validating (or invalidating) the assumptions around a hypothesis. This not only includes validating the usability of a feature, but the business purpose and direction.

By shifting product validation to design, you’re also saving the amount of time needed to validate. Since designers are generally faster at iterating on concepts than developers (using low-fidelity prototypes and designs), your team can get the product in front of customers faster, and thus validate the concept sooner. Ultimately, this means you can answer the question “are we building the right thing?” with less effort.

This is not to say that there is now zero risk in the build cycle: customers may report you’re missing the mark, or usage of the feature may be low, even if you tested your hypothesis with them. The point is that Lean UX absorbs this riskiest assumptions of the product, which allows you greater freedom to experiment with lofty hypotheses during the design cycle.

Habits of Lean, solutions-driven UX teams

A culture of rapid experimentation

The diagram above is something I created to help explain the basics of Lean UX. It distills what design teams should focus on in their process. When a team has a hypothesis or assumption, it should be researched, designed, and validated with users. Hypotheses which are proven out should be fleshed out further and built, while invalidated hypotheses should be left out entirely (“killing your darlings”). If an idea doesn’t get traction after testing with users, or you can’t really find anyone who has the problem in the first place, leave it aside and move on.

Classical UX teams tend to belabor this process, and overload experiments with too many hypotheses or stacked assumptions. Lean UX starts with learning as a goal with experimentation as a tool to reach that goal.

Validate business value (not just usability)

Any product designer worth their salt has experience testing the usability of a product. What designers have less experience with is business validation, which aims to measure the value of the thing you’re building for the audience you’re building it.

Lean UX teams couple business validation alongside usability testing. Rather than asking “would you use this?”, they ask strong validating questions like “will you buy this?”. This is an important step, as it addresses the usefulness of a feature versus simply understanding if your customer can use it. This is perhaps more useful to a product team than simple usability testing: usability can be fixed, building a product on a weak foundation can be deadly.

Avoid handoffs and deliverables

Traditionally, design teams would package their user research findings, lo-fidelity and hi-fidelity designs into documents to be handed off to development teams. This synchronous process acts as a huge blocker for development teams who only truly need lo-fi designs (including sketches) to get started, and hi-fi guidance once the feature is rolling.

Lean teams will have few (if any) such handoffs, instead focusing on producing design artifacts that the team needs to move the feature forward. They start with a high-level vision that everyone on the team can follow and work directly with team members for more tactical work. This may involve designer-developer pairing, which greatly reduces “design rejections” on feature work.

Bring non-designers into the research and design process

Along with the aforementioned designer-developer pairing on development tasks, you should also bring developers, testers, and other roles into the design process early and often. I’ve often found it most helpful to bring in non-designers during interviews with customers and other research-related activities. Brainstorming sessions focused on helping the customer succeed in some narrow way (often called “moments of delight” sessions) are helpful to illicit divergent ideas from those not on the product team, who can often fall victim to group-think.

Involving non-designers in the design process helps distribute knowledge about the problem to the rest of the team, so more team members understand why (and are involved in how) you’re building a particular component. This also helps speed up the development process as design intent can more easily be inferred from sketches and wireframes.