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?
—Eric Ries
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 a benefit hypothesis.
Lean UX design extends the traditional UX role beyond merely executing design elements and anticipating how users might interact with a system. Instead, it encourages a far more comprehensive view of why a Feature exists, which functionality is required to implement it, and which benefits it delivers. By getting immediate feedback to understand whether the system will meet the real business objectives, Lean UX provides a closed-loop system for defining and measuring value.
Generally, UX represents a user’s perceptions of a system—ease of use, utility, and the effectiveness of the user interface (UI). 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 those 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 development.
Fortunately, the Lean UX movement addresses these issues by combining Agile development with Lean Startup implementation approaches. The mindset, principles, and practices of SAFe reflects this new thinking. This process often begins with the Lean Startup Cycle described in the Epic chapter in Part 8 and continues with the development of features and Capabilities using the 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 that delights users.
In Lean UX, Gothelf and Seiden [2] describe a model that we have adapted to our context. This model is illustrated in Figure 1.
Figure 1. The Lean UX process (adapted from [2])
The Lean UX approach starts with a benefit hypothesis: Agile teams and UX designers accept the reality that the ‘right answer’ is unknowable up-front. Instead, teams apply Agile methods to avoid Big Design Up-Front (BDUF), focusing on creating a hypothesis about the feature’s expected business result, and then they implement and test that hypothesis incrementally.
The SAFe Feature and Benefit matrix (FAB) can be used to capture this hypothesis as it 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
Measuring the outcome is best done using leading indicators (see the ‘Innovation Accounting’ discussion in [1]) to evaluate how well the new feature is progressing toward its benefits hypothesis. For example, the indicator might state, ‘We believe the administrator can add a new user in half the time it took before.’
Traditionally, UX design has been an area of specialization. People who had an eye for design, a feel for user interaction, and specialty training were often placed in charge of the entire design process. The goal was ‘pixel-perfect’ early designs, done in advance of the implementation. Usually, 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 with the initial UX design. In Lean UX, that situation 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 systems thinking to their Lean UX design activities, moving from a siloed specialist approach to a collaborative, cross-functional design model. Agile Teams and ARTs are ideally suited for this model, which should include all the design–build–test cross-functional skills. The design perspectives of Product Management, System Architecture, Business Owners, information security, operations, and Shared Services should also be included, thereby ensuring a solution that is fit for use both for the end-user and supports deployment operations and for customer 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 to deliver a consistent user experience across various system elements or channels (e.g., mobile, web, kiosk) or even across 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 the following:
Editorial rules, style guides, voice and tone guidelines, naming conventions, standard terms, and abbreviations
Branding and corporate identity kits, color palettes, 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 include the design of buttons and other similar elements
Making these assets more accessible allows the team to ‘do the right thing,’ as part of their natural workflow without friction. Moreover, this approach supports decentralized control, while realizing that some elements of the design system need to be centralized. After all, these decisions are infrequent, have long-lasting effects, and provide significant economies of scale, as described in Principle #9.
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 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 an 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 provide feedback data from production users.
(Note: Telemetry is an automated process by which measurements and other data are collected at remote or inaccessible points and transmitted for monitoring and analysis. Telemetry could apply to both technical and business aspects of the functionality. For example: performance monitoring of solution components and automated A/B testing.)
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>.
Incremental implementation of features using stories enables continuous testing of the results against the benefit hypothesis.
To better understand their users, Agile teams apply user personas, which are representations of the characteristics, goals, and behaviors 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 [3].)
When implementing an MMF, there are a variety of ways to determine whether the feature delivers the right outcomes:
Observation – Wherever possible, directly observe the actual usage of the system; it’s an opportunity to understand the user’s context and behaviors.
User surveys – When direct observation isn’t possible, a simple end-user questionnaire can obtain fast feedback.
Usage analytics – Lean-Agile teams may build analytics directly into their applications, which helps validate initial use and provides the application telemetry needed to support a Continuous Delivery model. Telemetry offers constant operational and user feedback from the deployed system.
A/B testing – This form of statistical hypothesis compares two samples, while acknowledging that user preferences are unknowable in advance. Recognizing this fact is truly liberating, eliminating endless arguments between designers and developers—who likely won’t use the system. Teams follow Principle #3: Assume variability; preserve options to keep their design options open as long as possible. Wherever it’s practical and economically feasible, they should implement multiple alternatives for critical user activities. Then they can test those other options with mockups, prototypes, or even full-stack implementations. In the last 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 that teams need to refactor, adjust, redesign, or even pivot to abandon a feature, based solely on objective data and user feedback. Measurement creates a closed-loop Lean UX process that iterates toward a successful outcome, driven by actual evidence of whether a feature fulfills the hypothesis.
LEARN MORE
[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House. Kindle Edition.
[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.