Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

use experiment stories. Captured by using the same method as your user stories, experiment stories have two distinct benefits:

They visualize discovery work Discovery work is not inherently tangible as delivery work can be. Experiment stories solve that by leveling the playing field. Everything your team works on — discovery or delivery — goes on the backlog as a story.

They force its prioritization against delivery work After those stories are in the backlog, you need to put them in priority order. This forces conversations around when to run the experiment and, equally as impo...

When the experiment is over, bring the findings to the team immediately and discuss them to determine the impact of these findings. Your team should be ready to change course, even within the current sprint, if the outcome of the experiment stories reveals insights that invalidate your current prioritization.

User Validation Schedule Finally, to ensure that you have a constant stream of customer feedback to use for your experiments, plan user research sessions every single week.

The major reason designers feel pressure in Agile processes is that they don’t (for whatever reason) fully participate in the process. This is typically not their fault: when Agile is understood as simply a way to build software, there doesn’t appear to be any reason to include nontechnologists in the process. However, without designer participation, their concerns and needs are not taken into account in project plans. As a result, many Agile teams don’t make plans that allow designers to do their best work.

You can recognize a lack of shared vision when the team argues about what features are important or what should be done first.

Maintain a “Problem Roadmap.” Instead of using a feature roadmap to communicate with stakeholders, transform the roadmap to communicate the problems you’ll be working on. Use this Problem Roadmap to drive planning and check-in meetings with stakeholders.

Proactively reach out to your product owners and executives to keep them updated on your plans. Let them know: how the project is going; what you tried so far and learned; what you’ll be trying next; what risks you see in the product and how you plan to address them.

Keep the conversations focused on outcomes (how you’re trending toward your ...

The concept of managing to outcomes applies to a set of teams as much as it does to individual ones. To ensure that all the teams working on the same project have a shared vision, assign them all the same success metric. Working together, they can define the leading indicators that drive that metric and divide those leading metrics between the teams on the project.

Teams that work on mobile apps fall into a gray zone here. You can update frequently, but not continuously, so you’ll need to become crafty with your techniques. Using feature flags to turn some features on and off can help. You can also deliver experimental features inside apps by using a browser container within the app itself. Finally, it’s possible to test really early versions of features on the mobile web.

Changing Culture

Adopting a position of humility Embracing new skills Creating open, collaborative workspaces No more heroes Falling in love with the problem, not the solution Shifting agency culture Being realistic about your environment

Finally, your product development processes will change as well: Shifting from output to outcomes Eliminating Big Design up front Speed first, aesthetics second Embracing UX debt Navigating documentation standards Managing up and out

In many cases, the best features of a system emerge over time as people use the system. (Twitter’s hashtag is a great example of this: users invented this feature, and then Twitter added support for it after the fact.)

your organization must adopt a position of humility. Your organization must accept that, in the face of all this complexity and uncertainty, we just can’t predict the exact shape our service will have to take to be successful. This is not an abdication of vision. Instead, it requires a strong opinion about the shape the system should take, coupled with the willingness to change course if evidence from the market reveals that initial vision was wrong. Adopting this mindset makes it safe for teams to experiment, fail, and learn.

Lean UX teams measure their success not in terms of completed features, but in terms of progress toward specific outcomes.

Teams using Lean UX must be empowered to decide for themselves which features will create the outcomes their organizations require. To do this, teams must shift their conversation with leadership from one based on features to one centered on outcomes.

Teams must ask, “why are we working on this project?” And, “how will we know we’ve done a good job?” Managers need to be retrained to give their teams the answers to these questions. They must be given the freedom to work with their teams to determine which features best achieve these goals. Teams must move from feature roadmaps to backlogs of hypotheses to test. Work should be prioritized based on risk, feasibility, and potential success.

For Lean UX to succeed, your organization needs to adopt a mantra of “competencies over roles.” Every team member possesses a core competency — design, software development, research, and so on — and must deliver on that skill set. However, members might also possess secondary competencies that make the team work more efficiently. Allow your colleagues to contribute in any disciplines in which they have expertise and interest. You’ll find it creates a more engaged team that can complete tasks more efficiently.

Designers must open up the design process

Designers must take a leadership role on their team Your colleagues are used to giving you critique on your design work. What they’re not used to doing is co-creating that design with you. Design leadership and facilitation in group brainstorming activities like Design Studio can create safe forums for the entire team to conceptualize your product and showcase the synthesizing capabilities of the design team.

Perhaps the most important thing to remember if you’re trying to implement Lean UX with distributed teams is this: the members of these teams must be awake at the same time. The overlap doesn’t need to cover an entire work day but there must be some block of time every day during which colleagues can have conversations and participate in collaborative exercises.

For Lean UX to succeed in your organization, all types of contributors — designers and nondesigners — need to collaborate broadly. This can be a hard shift for some, especially for visual designers with a background in interactive agencies.

Agile-fall is the combination of an up-front design phase that results in work that is handed off, waterfall style, to an engineering team to then break up into stories and develop in an “agile” way. The argument for this way of working centers on the engineering team’s desire to stay the course during implementation and to be able to predict when the work will ship with some degree of confidence. This is done in the name of predictability and efficiency.

Agile-fall is a symptom of a broader management issue that continues to push teams toward fixed scope and fixed deadlines. Engineers rightly feel the only way they can make scope and deadline commitments is if they have a crystal clear understanding of what needs to be developed, along with a promise that nothing will change.

By sacrificing the perfection of intermediate design artifacts, your team will get to market faster, and learn more quickly which elements of the whole experience (design, workflow, copy, content, performance, value propositions, etc.) are working for the users and which aren’t.

Although your organization must continue to value aesthetics, polish, and attention to detail, other dimensions of design are equally important. The ability to understand the context of a business problem, think fast, and build shared understanding needs to get a promotion. Designers can demonstrate their problem-solving skills by illustrating the paths they took to get from idea to validated learning to experience.

“It’s not iteration if you do it only once.” Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt, it also means reworking and improving user interfaces. Teams need to embrace the concept of UX debt and make a commitment to continuous improvement of the user experience.

Create a customer journey map of the current experience Work together with your team to create a second journey map that shows the ideal experience Make these two artifacts clearly visible (on a wall) next to each other Identify teams responsible for portions of that customer journey and invite them to the wall to review the gap between current and desired states Work with these teams to write UX debt stories to go on their backlogs Clearly identify on the journey maps when the current experience has been improved and who is working on other improvements

Cross-disciplinary collaboration can also be difficult in big agencies, where the need to keep utilization high has led to processes that encourage functional silos. These, in turn, lead to “project phases” that encourage deliverable-centric work.

Third-party software development vendors pose a big challenge to Lean UX methods. If a portion of your work is outsourced to a third-party vendor — regardless of the location of the vendor — the Lean UX process is more likely to break down. This is because the contractual relationship with these vendors can make the flexibility that Lean UX requires difficult to achieve.

When working with third-party vendors, try to create projects based on time and materials. This will make it possible for you to create a flexible relationship with your development partner. You will need this in order to respond to the changes that are part of the Lean UX process. Remember, you are building software to learn, and that learning will cause your plans to change.

When selecting partners, remember that many outsourced development shops are oriented toward production work and see rework as a problem rather than a learning opportunity. When seeking partners for Lean UX work, look for teams willing to embrace experimentation and iteration, and who clearly unders...

Some managers can be threatened by proposals to work in a new way — which could end up having negative consequences for you. In these situations, try asking for forgiveness rather than permission. Try out some ideas and prove their value with quantifiable success. Whether you saved time and money on the project or put out a more successful update than ever before — these achievements can help make your case.

stepping away from a feature roadmap approach, and instead empowers teams to discover the features they think will best serve the business. But abandoning the feature roadmap has a cost — it removes a key tool that the business uses to coordinate the activity of teams. So, with the freedom to pursue your agenda comes a responsibility to communicate that agenda.

You must constantly reach out to members of your organization who are not currently involved in your work to make them aware of what’s coming down the pike.

There are always other departments who are affected by your work. Ignore them at your peril. Ensure customers are aware of any significant upcoming changes and provide them the option to opt out (at least temporarily).

The team realized that just throwing a cross-functional array of professionals together in one room, although a good start, was not enough to build productive collaboration. The team needed to rethink how it worked and not just what it was doing.

They learned when to create sketches collaboratively and when to create and present pixel-perfect mockups. They figured out how to get thinking time, and at the same time, avoid going too long without broader team feedback.

The team began by creating empathy maps during each contextual interview with a customer. This helped team members realize insights and recognize consumer behavior patterns.

Experience Stories are mini-scenario statements that ensure designers stay focused on solving the problem at hand without becoming lost in the minutiae of feature details.