Here at 18F, several product teams (including CALC, Discovery, and EITI) have been experimenting with a lean product design approach to building software, often called “lean UX.” In a nutshell, it is a set of ideas about design and project management that help us focus not just on what we build, but on the outcomes our tools enable.

What is lean product design?

The core of lean product design is “hypothesis-driven development,” which is actually not as scary as it sounds. Basically we try to acknowledge that much of what we believe about a problem, solution, and our users are assumptions that need to be tested. To do this, we build in small, iterative pieces with the primary objective being learning whether the intended idea or feature is having the outcome we want.

Why use a lean approach?

When building new digital services for government (or outside government), it’s very easy to think about our work in terms of building new “features” or “sites” or “platforms.” But our users don’t care about what features our sites have; they care about what they can accomplish with them. And the people and agencies who own the sites don’t actually care about features either. They care about what mission the site helps them accomplish — our partners across government use their websites to help them accomplish their own broader goals.

Even in an agile development process, it’s easy to lose track of the outcomes we’re trying to achieve. And we often don’t measure them until the end. Lean product design forces us to check, as we build each piece, how it works and what it accomplishes.

Key principles

  • The goal of each sprint is to create an experiment, then learn and respond.
  • Teams should be cross-disciplinary, closely integrated, and include the client product owner as an active design participant.
  • Strive toward shared understanding at all times: The entire team participates in all activities together, from planning and problem framing to research, design, and execution.
  • Make your assumptions explicit, and test the riskiest or most critical first.
  • Take a holistic view of what to tackle with the team. In other words, don’t silo “product strategy” work and assumptions (for example “how will we reach our users?”) from the “building.”
  • Keep experiments as light as possible.
  • Prioritization is the (not so) secret weapon to keep your efforts lean and focused.
  • Always start a project by taking a fresh look at the problem(s) and doing some discovery.

The guide

In order to reflect on what we’ve learned in trying this approach, and to help other digital teams who might be interested, we’ve written a detailed step-by-step reference guide, which includes:

  • Steps for planning and executing a project with lean in mind
  • A process for distilling assumptions into hypotheses
  • How to use existing tools to efficiently track hypothesis-driven development
  • Tips for doing user research within an agile development process

“Lean” approaches to user experience vary, so keep in mind that this is just one perspective on trying to pull it all together. That said, we’re excited to open source our guide and share it with you!

Who’s this guide for?

We originally wrote this guide to communicate our process (and serve as a reference) to colleagues who are less familiar with this approach. While we have used it primarily in a digital software context, it may be useful to anyone involved in planning and building a project.

How should I use this guide?

At 18F, we’ve used this guide:

  1. As a beginning-to-end reference for our project process. It offers suggestions on kickstarting a project development process, grooming a hypothesis-based backlog, and leading agile sprints that incorporate user research.
  2. As a “fill-it-in-yourself” worksheet for clarifying a project’s purpose. Fill in the first few steps of the guide with your team to decide on clarify (to everyone) what problem a project is trying to solve, what problems you might want to solve with it, and why.
  3. As a list of tips and tricks to make your own agile process “leaner.” Although you may not want to adopt our whole process, some of our teammates use pieces of our guide (like research-driven acceptance criteria) in their own processes.

We want to hear from you!

Give us your thoughts, advice, and edits by emailing us or opening an issue directly in the GitHub repository.