What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget? [1]

—Eric Ries

 

Lean UX

Lean User Experience (Lean UX) design is a mindset, a culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments, and determines success by measuring results against an outcome hypothesis.

Lean UX design extends the traditional UX role beyond simply executing design elements and anticipating how users might interact with a system. Rather, it encourages a far more comprehensive view of why a Feature exists, the functionality required to implement it fully, and the benefits it delivers. By getting immediate feedback to the Dev Team on whether or not the system is evolving to meet the real business objectives, Lean UX provides a closed-loop system of defining and measuring value.

Details

Generally, User Experience (UX) represents a user’s perceptions of a system—ease of use, utility, and the effectiveness of the user-interface. UX Design focuses on building systems that demonstrate a deep understanding of end users. It takes into account what users need and want, while making allowances for the users context and limitations.

A common problem when using Agile methods, is how best to incorporate UX design into a rapid Iteration cycle that results in a full-stack implementation of the new functionality. When teams attempt to resolve complex and seemingly subjective user interactions, while simultaneously trying to develop incremental deliverables, they can often “churn” through many designs, which can become a source of frustration with Agile.

Fortunately, the Lean UX movement addresses this by using Agile development with Lean Startup principles and implementation approaches. This new thinking is now reflected in the mindset, principles, and practices of SAFe. This process often begins with the Lean Startup Cycle described in the Epic article and continues with the development of Features and Capabilities using a Lean UX process described here.

As a result, Agile Teams and Agile Release Trains (ARTs) can leverage a common strategy to generate rapid development, fast feedback, and a holistic user experience, which delights users.

The Lean UX Process

In Lean UX, Gothelf and Seiden [2] describe a model that we have adapted for our context, as Figure 1 illustrates.

Outcome Hypothesis

The Lean UX approach starts with an ‘outcome hypothesis:’  Agile teams and UX designers accept the reality that the ‘right answer’ is actually unknowable, ‘up-front’. Instead, they apply Agile methods to avoid Big Up Front Design (BUFD), focusing instead on creating a hypothesis about what business outcome to expect from a new feature, and they implement and test that hypothesis incrementally.

The SAFe Feature and Benefit matrix (FAB) can be used to capture this hypothesis, as the feature moves through the Continuous Exploration cycle of the Program Kanban:

Feature – A short phrase giving a name and context

Benefit Hypothesis – The proposed measurable benefit to the end-user or business

The hypotheses may be expressed as end-state outcomes, (examples: business result, or market share). But they’re more likely leading  measures (see Innovation Accounting in Ref [1]) used to evaluate how well the new feature is likely to deliver the intended benefits. For example, “The administrator is able add a new user in half the time it took before.”

Collaborative Design

Traditionally, UX design has been an area of specialization. People who have eye for design, a feel for user interaction, and specialty training were often fully in charge of the design process. The goal was “pixel perfect” early designs, done in advance of the implementation. Often this work was done in silos, apart from the very people who knew the most about the system and its context. Success was measured by how well the implemented user interface complied to the initial UX design. In Lean UX, that changes dramatically:

“Lean UX literally has no time for heroes. The entire concept of design as hypothesis immediately dethrones notions of heroism; as a designer, you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.” [2]

Agile teams apply Principle #2 – Apply System Thinking, to their Lean UX design activities, moving from a siloed specialist approach to a collaborative, cross-functional design model. Agile Teams and Agile Release Trains are perfectly suited for this model. They should include all the design-build-test cross-functional skills. They also include the essential broader perspectives (Product Management, System Architecture, Business Owners, information security, operations, Shared Services, DevOps and more). This ensures that the design is fit for use—not just for the end user, but also for deployment, operations, and support.

Principle #9 – Decentralize Decision Making, provides additional guidance for the Lean UX process: Agile teams are empowered to do collaborative UX design and implementation, and that significantly improves business outcomes and time-to-market. Moreover, another important goal is help teams deliver a consistent user experience across various system elements, or channels (e.g. mobile, web, kiosk) or even different products from the same company.  Making this consistency a reality requires some centralized control (following Principle #9) over certain reusable design assets.  A design system [2] is a set of standards that contains whatever UI elements the teams find useful, including:

• Editorial standards, style guides, voice and tone guidelines, naming conventions, common terms, and abbreviations
• Branding and corporate identity kits, color pallets, usage guidelines for copyrights, logos, trademarks and other attributions
• UI asset libraries, which include icons and other images, standard layouts and grids
• UI widgets, which includes the design of buttons and other similar elements

Making these assets available and easy to use allows the team to ‘do the right thing,’ as part of their natural workflow.  Simply, it’s less work to reuse proven assets than to come up with an original set for each case. Moreover, this approach supports decentralized control to the teams, while realizing that the common elements of the ‘design system’ need to be centralized. After all, these decisions are infrequent, long-lasting and provide significant economies of scale, as prescribed in ‘Principle #9, Decentralized Decision-Making.’

Build MMF

With a hypothesis and design in place, teams can proceed to implement the functionality in a Minimum Marketable Feature (MMF). The MMF should be the minimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not. By doing this, ARTs apply SAFe Principle #4-Build Incrementally with Fast, Integrated Learning Cycles, to implement and evaluate the feature.

In some cases, the MMF could initially be extremely lightweight, and not even functional (e.g. paper prototypes, low fidelity mockups, simulations, API stubs). In other cases, a vertical thread (full stack) of just a portion of a MMF, may be necessary to test the architecture, and get fast feedback at a System Demo. However, in some instances, functionality may need to proceed all the way through to deployment and Release, where application instrumentation and telemetry [4] provide feedback data from production users.

User Stories

SAFe teams implement features via user Stories. Conveniently, user stories are written using a format that supports the outcome-hypothesis approach  of Lean UX:

As a <user role I can <activity> so that <business value>

When teams implement stories, the feature is realized incrementally, and the results can be tested continually against the outcome hypothesis (or proposed business value).

Personas

In order to better understand their users, Agile teams apply “user personas,” which are representations of the characteristics, goals, and behavior of different types of end users. Developing and maintaining a deep understanding of primary and secondary user personas is a common practice of successful Agile teams. (For more on personas, see Ref 3.)

Evaluate

Once an MMF is implemented, there are a variety of ways teams can determine whether or not the feature delivers the right outcomes. These include:

Observation – Wherever possible, teams directly observe the actual usage of the system, an opportunity to better understand the user’s context and behaviors.

User surveys – When direct observation isn’t possible, a simple survey can obtain fast feedback.

Usage analytics – Lean-Agile teams build analytics right into their applications. This is a key strategy, not only for understanding initial usage, but also for installing the application telemetry necessary to support a Continuous Delivery model, providing constant operational and user feedback from the deployed system.

A/B testing – This is a form of statistical hypothesis testing of two samples.  This practice acknowledges that user preferences are unknowable in advance. This is truly liberating. Rather than endless arguments between designers and developers—who won’t likely use the system—teams follow Principle #3 Assume Variability and Preserve Options to keep design variations open as long as possible. And wherever it’s practical and economically feasible, they should implement multiple options for certain critical user activities. Then they can test those options with mockups, prototypes, or even full stack implementations. In this latter case, differing versions may be deployed to multiple subsets of users, perhaps sequenced over time and measured via analytics.

In short, measurable results deliver the knowledge teams need to refactor, adjust, redesign—or even pivot to abandon a feature, based solely on real objective data and user feedback. This creates a closed-loop Lean UX process that iterates toward a successful outcome, driven by objective evidence of whether a feature fulfills the hypothesis, or not.

Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc.

[2] Gothelf, Jeff  and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. 2016.

[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[4] Telemetry is an automated process by which measurements and other data are collected at remote or inaccessible points and transmitted for monitoring and analysis. This could apply to both technical and business aspects of the functionality (e.g. performance monitoring of solution components, automated A/B testing).

Last update: 27 May, 2017