Agile and Lean User Experience evolved because many smart people wanted to find a more effective way of working. I attended a workshop recently where the instructor asked the group a direct question: “How many of you have stayed late at work to create detailed specifications that were never realized?” Nearly everyone raised their hand. Despite our best-laid plans, most of our technology projects never match the detailed specifications or requirements we have laid out. This wasted effort is always frustrating.
In an effort to recognize the inevitable changes that arise during a project and to build better products, many designers, developers, and even the U.S. government have embraced Agile and Lean User Experience.
Waterfall Methodology: This is a product development methodology that ensures that you are building the product right. It assumes you’ve done all necessary specification work ahead of time.
Agile: This product development methodology focuses on collaboration. It is also a mindset of being flexible and adapting to change.
Lean User Experience (UX): Lean UX is a product development approach that arose from lean start-ups and views user research and design as more outcome driven. The Lean UX process pairs well with Agile methods because its recommends continuous research rather than great amounts of upfront user research. In a Lean UX, we are continuously measuring and validating the product market fits with a few users to answer the question: “Are we making the right thing?”
Build the Right Thing
Your organization has worked hard to secure a budget for the upcoming technical project. You’ve probably spent countless hours, perhaps months haggling over what needs to be included, what success will look like, making presentations to your board, and perhaps even selected a vendor to help you implement your idea. You’re eager to get this thing launched. Sound familiar?
Along the way you’ve made some assumptions about your target audiences, goals, and the way you expect the project to unfold. This initial work is important; however, these assumptions need to be validated so that you are not spending resources on something that won’t be used. Greg Laugero explains this well:
“Good, business-savvy design has always been about systematically finding the core features that matter most to users — no more, no less — and finding them at the cheapest possible cost. Design is almost always a process of trying to identify what is really valuable to users and what is less important. Doing it systematically is smart business and good design. Lean UX in this sense is good business.”
The goal with any technology project is to launch something of high value to your audience, but at a low cost to your organization. In an Agile and Lean UX approach, the design and development team are consistently collecting feedback about the design, your assumptions, and iterating toward a better product. The money you invest goes directly toward the improvements that will have the biggest impact on your goals.
How to Do It?
At Forum One, our project delivery methodology lets us iteratively refine product design through a loop that can best be described as Think » Make » Check » Repeat. The key difference between our approach and a traditional waterfall approach is that we prioritize working software over paper-based documentation.
Think: First, we brainstorm possible solutions that may address the problem. We have a defined problem space and what we want to do is quickly generate as many ways we could solve that problem. This is sometimes referred to divergent thinking.
A common practice at Forum One is to have each team member sketch as many solutions as they can that solve this problem in five to eight minutes. If each person on a five-person team creates five sketches, that means we may have 25 different ways to address the problem. We present our ideas to each other, critique them, and decide on which appear to be the most viable.
Make: Then we make a prototype, or low-fidelity representation of the solution (a refined sketch, a wireframe, functioning software, etc).
Check: We test the prototype with representative users to determine if it addresses the issue/problem we hoped to solve. We are not conducting in-depth usability sessions, rather we are hopefully engaging three to five users to watch them use the product in its current condition.
Invariably, we will uncover one or more items that can be improved in each testing session. However, sometimes areas we assumed to be a potential hazard are not a problem for the users — which means we can focus our efforts elsewhere.
Repeat: Once we’ve identified which will have the biggest impact on our product goals, we repeat the Think » Make » Check cycle. Each time we test the prototype, we are learning more about how our users interact with the product and we are validating our assumptions. We are able to incorporate these lessons into the next iteration of our design and create products that do the best possible job of supporting client goals AND meeting user needs (these aren’t always aligned, and doing both is critical for success).
Do You Need Documentation?
A common misconception about the Agile and Lean UX approach is that you don’t create documentation. This is not true. We create documentation; however, it is just different than the specifications that are developed in a waterfall methodology.
For example, rather than creating “requirements,” we document user stories in a backlog. Instead of creating functional specifications, we create functional prototypes. We document the findings of our research, design rationale, and other strategic information because we need to communicate that not only amongst members of the team, but also to other stakeholders.
The key to this documentation, just like the key to launching your product, is to document what is important to your stakeholders — no more, no less — and doing so at the lowest possible cost. In a waterfall methodology, the design team is often concerned about creating the “deliverable” and ensuring that all of the necessary details are contained within those documents. In an Agile and Lean UX approach, the focus is on working software and creating documents to facilitate conversation.
This article has been greatly influenced by user experience leaders and their articles on Lean UX and working in Agile environments.
If you want to learn more, you should read:
- Lean UX: Getting Out Of The Deliverables Business By Jeff Gothelf
- Agile UX vs Lean UX – How they’re different and why it matters for UX designers By Anders Ramsey
- Lean UX Is Dead. Long Live Lean UX By Greg Laugero
- Lean UX Is Not Anti-Deliverable By Jeff Gothelf
- Is There Any Meat on This Lean UX Thing? By Jared Spool
- Learning to Play Ux Rugby By Anders Ramsey
- Designing with Agile Workshop By Anders Ramsey
- Introduction to Design Studio Methodology By Will Evans
Their thought leadership is greatly appreciated.