Talking Lean UX with Jeff Gothelf

Noted designer, agile advocate, and public speaker Jeff Gothelf has poured a good measure of his expertise into a new book, Lean UX: Applying lean principles to improve user experience (co-authored by Josh Seiden; part of “The Lean Series” from O’Reilly).

UX Magazine talked with Gothelf about the difficulties getting a buy-in on lean methods, ways to get lean strategies implemented, and the advantages of focusing on oucomes over deliverables.

You’re quoted in the foreword of the book as saying we should, “get out of the deliverables business,” and return our focus to customer delight. How uphill a battle is it getting companies to shift their mindsets from focusing on artifacts to outcomes?

For most companies this is very difficult. There are several reasons for this. The first is that managing outputs (and by proxy deliverables) is easy: Did you implement the new sign-in page? Great. You did your job. Good work. It’s very clear whether or not a deliverable or some other output was created.

Managing outcomes is harder because many organizations are simply not instrumenting their software to measure the right performance metrics. If they don’t have the data, they can’t manage to those business goals. Second, it’s harder to manage people to outcomes because there are many more shades of grey between failure and success. If your goal was to increase subscriptions by 30% but you raised it by 28%, did you fail? I would argue that you didn’t and that you are on your way to achieving and exceeding that goal.

“Did the new sign in page increase registrations by 30%?”—the conversation companies need to be having—is a much more difficult discussion.

Finally, executives want the shiny objects. They want to know exactly what they’re going to get for their investment in your project or team. All too often these conversations focus on a feature or a mobile app instead of what business goal the team should achieve. Changing this historical momentum of how companies operate is very challenging.

One of the biggest challenges with implementing lean UX across an organization seems to be getting past the fear of failure present within silos. What are the best ways to demonstrate the value in failure to those who are reluctant or uninitiated?

The best way is to start small and then build on your wins.

Pick a small team (designer, engineer, and product manager) and give them a compartmentalized, time boxed, and (perhaps) internal challenge. Let them work together to not only figure out the best way to solve the problem but to start [moving past] the organizational speed bumps that keep teams from working this way. As they make incremental progress, they build on that to take greater risks, take on bigger projects, and build internal momentum for this new way of working.

Is there a danger of losing focus in a process that relies on rapid and constant iteration over thorough documentation?

There is always a danger of losing focus (in any process) especially once you start optimizing an experience. We must always be vigilant against getting caught up in the local maxima and not keeping an eye out for fertile opportunities for progress outside of our current focus.

Are there projects or scenarios where lean UX isn’t the right approach?

Lean UX is not a silver bullet. It’s one approach to help teams maximize the time they spend building the right product together. There will certainly be situations where the process breaks down. This is especially true when working with third-party vendors (who require thorough documentation to do their work) or with clients whose internal processes simply won’t allow for lean’s rigor of experiments, failure/learning, and iteration.

Were there some things you were surprised to learn?

What surprised me most when writing the book was the pushback I was getting from designers when discussing the “open-sourcing” of the design process. Many people I spoke with were not interested in letting non-designers into the connecting phase of the product design process. They failed to see the value those folks would bring and, I also believe, were scared that they would be seen as less valuable if “everybody could design”—which of course was the furthest thing from the truth.

You note that lean UX teams function better without the presence of rockstars, ninjas, and evangelists. Do you see the same notion—that a group of people eagerly sharing their ideas and talents works best—applying readily to the UX field at large?

Yes. This is not a concept unique to lean UX. It is a concept of broad team collaboration—regardless of discipline. Different perspectives bring depth and context to your ideas. The sooner you can bring those perspectives into your thinking, the more complete and thought-through your ideas will be. This is true if you’re a designer, engineer, product manager, or a marketer.

What are the main takeaways from the book with the broadest appeal in the great big realm of user-centered research and design?

1. Focus on outcomes not outputs and features.
2. Share the design and research process with your team.
3. Every design you put forward is a hypothesis. Ruthlessly test it and learn from your failures.