Lean UX: Designing Great Products with Agile Teams

by Jeff Gothelf

Last, and perhaps most important, is the mindset shift we gain from adopting a model based on experimentation. Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals.

As we’ve been practicing Lean UX, we’ve learned to overcome the feeling that we are showing work in an “unfinished” or “ugly” state. We now know that our first attempt will inevitably require revision. So the sooner we get our ideas out, the sooner we can figure out what those revisions should be. Waiting too long to get that feedback is wasteful. We invest too much in the initial design and are less flexible to changes because of the effort we’ve already put in.

Teams are now facing intense pressure from competitors who are using techniques like Agile software development, continuous integration, and continuous deployment to radically reduce their cycle times. Take Amazon as an example. The ecommerce giant pushes new code live to their customers every 11.6 seconds.1 And they are using these short cycles as a competitive advantage — releasing early and often, gaining market feedback, and iterating based on what they learn to create a continuous conversation with customers. In essence, they are discovering their product at the same time they are delivering it.

Features and services are outputs. The goals they are meant to achieve are outcomes. In Lean UX, teams are trying above all to create a meaningful and measureable change in customer behavior: an outcome.

Shared understanding is the currency of Lean UX. The more a team collectively understands what they’re doing and why, the less they need to debate what happened and can quickly move to how to solve for the new learning. In addition, it reduces the team’s dependencies on second-hand reports and detailed documents to continue its work.

Requirements present a seemingly immutable path forward. Assumptions explicitly admit that we might be wrong. We use our assumptions

Declaring assumptions is best done as a group exercise. Gather your team, making sure that all disciplines are represented — including any subject matter experts that could have vital knowledge about your project. For example, if you’re handling a frequent customer complaint, it might be beneficial to include a customer service representative from your call center. Call center reps speak to more customers than anyone else in the organization and will likely have insight the rest of the team won’t.

A good design system contains comprehensive documentation of the elements of a design, rules and examples that govern the use of these elements, and crucially, contains the code and other assets that actually implement the design. In practice, a design system functions as a single source of truth for the presentation layer of a product. Teams can sketch at the whiteboard and then quickly use the elements found in the design system to assemble a prototype or production-ready frontend.

To create the new design system, the team spent nearly six months prototyping. Significantly, the team did not work in isolation. Instead, they paired with one of the application teams, and thus were designing components to meet the needs of their users — in this case the designers and developers working on the application teams. This point is really important.

It’s critical to define the intended audience for your prototype. This allows you to create the smallest possible prototype that will generate meaningful feedback from this audience.

Stakeholders, often less familiar with their own product than they’ll ever admit to, will likely need a greater level of fidelity in the prototype to truly grasp the concept.

In the same way that Lean UX encourages designers to take a more facilitative approach, Lean UX asks the same of the researcher. Use your expertise to help the team plan good research, ask good questions, and select the right methods for the job. Just don’t do all the research for them.

We like to use a weekly rhythm to schedule research, as demonstrated in Figure 6-2. We call this “Three, twelve, one,” because it’s based on the following guidelines: three users; by 12 noon; once a week. Figure 6-2. The Three, twelve, one activity calendar

We routinely run tests with remote observers using nothing more exotic than Google Hangouts. The ability to connect remote observers is a key element. It makes it possible for you to bring the test sessions to team members and stakeholders who can’t be present. This has an enormous impact on collaboration because it spreads understanding of your customers deep into your organization. It’s hard to overstate how powerful this is.

You can recognize a lack of shared vision when the team argues about what features are important or what should be done first. There can also be a general sense of tension that the team is not “moving fast enough” or it feels like the team is going back over the same issues again and again.

Product owners, stakeholders, CEOs, and clients all want to know how things are going. They all want to bless the project plan going forward. The challenge for outcome-focused teams is that their project plans are dependent on what they are learning. They are responsive, so their typical plan lays out only small batches of work at a time. At most, these teams plan an iteration or two ahead. This perceived “short-sightedness” tends not to satisfy most high-level managers. How then do you keep the check-ins at bay while maintaining the pace of your Lean UX and Scrum processes? Two words: proactive communication

If you want your stakeholders — both those managing you and those dependent on you — to stay out of your way, make sure that they are aware of your plans. Here are a few tips: 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 goal) not feature sets. Ensure dependent departments (customer service, marketing, operations, etc.) are aware of upcoming changes that can affect their world. Provide them with plenty of time to update their workflows if necessary.

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. This conversational shift is a radical one. Product managers must determine which business metrics require the most attention. What effect are they trying to create? Are they trying to influence customer behavior? If so, how? Are they trying to increase performance? If so, by what measure? These metrics must be linked to a larger business impact. Leadership must set this direction. If not, teams must demand this shift of them. 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 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. In those contexts, the creative director is untouchable. In Lean UX, the only thing that’s untouchable is customer insight. 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.

email, Emily, who is Director of UX at Hobsons, an educational-technology company in the Washington, DC, area, details the changes she’s made in her organization. Here are some excerpts that describe the journey her firm has taken: I think a lot of enterprise companies struggle to figure out the best way to implement these techniques. We initially got a great deal of resistance that we couldn’t do Lean UX because we’re “not a startup,” but of course that’s really not true. We brought in a coach to help reinforce with the team our goal of moving our development process toward a Lean UX methodology (it can help to have an outside voice to reinforce what’s being said internally), and since then we’ve made good progress. In less than a year, our team structure has moved from this: Figure 9-9. Hobson’s original team structure To this: