Lean UX: An Interview with Jeff Gothelf and Josh Seiden

From time to time, we revive our in-house book club to catch up on new themes, practices, or ideas out there in the design world. This month, we’re reading Lean UX: Applying Lean Principles to Improve User Experience, written by Jeff Gothelf and ex-Cooperista Josh Seiden. Inspired by Eric Ries’s The Lean StartupLean UX takes aim at waterfall design and development processes and outlines a set of ways that UX designers can more deeply and helpfully engage in product development. The intent is to foster more open, collaborative, and iterative processes, and to break through the organizational red tape that can stifle creativity. The end goals: More trust, more clarity, more fun, and better products delivered quickly by a highly-functioning team. Managing Director Doug LeMoine caught up with Jeff and Josh to discuss the ways in which lean practices can superpower our (and your) UX work.

Doug: UX, as it is commonly practiced, is all about establishing a coherent vision for a product or service. Oftentimes, in striving for coherence, designers can slam the brakes on development, since no one wants to waste effort in developing something that’s not part of that coherent vision. What is to be done with this state of affairs? How does Lean UX help here?

Josh: I do think establishing a vision up front is important. But I think that we often mistake how much work we need to do to establish and articulate that vision. If you’re working in deep collaboration with a cross-functional team, you can establish, test, and validate a vision very quickly. So, instead of “slamming the brakes on developers,” we advocating including them and other team members in the visioning activities early in the project.

The risk with design-centric early “vision” activities is that the work done in the vision phase frequently goes beyond “vision.” Sometimes, in order to communicate a vision to outsiders, you need to articulate the vision with a level of detail that can create problems, because those details, while important to the communication, are not actually important to the vision. The risk is that these explanatory details get misunderstood later–and they start to cross over into requirement and specification. That’s risky, because as you start to elaborate on the vision, you need to continue to validate those elaborations–but too often we build up a backlog of untested decisions.

The Lean UX approach is well articulated by our colleague Giff Contstable, who says, “Lead with vision, then test ruthlessly.”

Jeff: One of the myths Lean UX helps dispel is that only designers have vision. In fact, every member of your product development team has something to contribute to the problem being solved. Including everyone from the beginning builds their points of view into the process. In addition, the feelings of inclusion and buy-in gained by including everyone translate into a much healthier and productive team environment.

Doug: This makes sense to me. You want to communicate a vision with enough detail to give it shape, but not so much that the detail distracts from the big picture ideas. So let me ask what may sound like the same question in a different way: How should designers contribute to a product vision? And how will they know when they’ve arrived at enough detail?

Josh: I think you need to step back and consider the point of the vision work. Who needs to share the vision? Why? In general, I’ve moved to collaborative “visioning” in which the designer facilitates the vision from the team and stakeholders. The designer can still form and express the vision, but it needs to represent a shared concept. In terms of detail, um… 42? I think you’re sensing for evidence of alignment across the team and stakeholders.

Doug: Josh, you have a design background. How do Lean UX methods or techniques help you achieve your objectives as a designer?

Josh: I want my work to create a change in the world. A bad outcome for me is to create a deliverable filled with wonderful ideas that sits on a client shelf for 5 years. A good outcome is when my work helps create a product that achieves a goal for my client. Lean UX uses a variety of tactics to orient design work around outcomes. We recommend that teams consider not just the outputs they create (the deliverables, web pages, apps, and other things we make) but the outcomes of the work: the new user behaviors the work enables and the results those behaviors have on the business or organization that hired you.

Jeff: Designers should facilitate the team’s journey towards realizing the vision. By bringing concepts familiar to designers, like brainstorming, empathy for the user and basic sketching exercises, to the non-designers on the team, designers are steering the team through multiple validation loops for their visions. In the process they are creating empathy not just for their customers but for the design practice as well.

Doug: Have you had success with any specific mechanisms for achieving this shift in focus from output to outcomes? I’m not asking after a magic bullet, but more wondering about techniques you’ve used that help you capture the right level of design, facilitate a focus on perhaps less spreadsheetable things, and remove the crutch of milestone deliverables.

Josh: This is certainly easier to do for internal teams than for consultants, where the contractual relationship is typically defined around deliverables. The basic mechanism for shifting this: “time and materials” to “contracts and trust.”

Doug: Jeff talked about “getting out of the deliverables business” in his Smashing Magazine article. So … What business are you getting into with Lean UX? Is there a buzzy way to encapsulate that?

Jeff: We focus the teams we work with on a specific, measurable key performance indicator (KPI) they’d like to move. This KPI can be an indicator of a greater impact on the whole eco-system but we don’t task the teams with affecting that higher-level impact. For example, we may ask a team to focus on reducing shopping cart abandon rates. This is a specific outcome that can be measured. It happens to affect revenue — but it’s not the only KPI that does that so we don’t task the team with impacting revenue. We want their work to be directly measurable so the team can react to these changes.

I suppose that if you’re getting out of the deliverables business (and we all should be) then yes, we should be getting into the outcomes business.

Doug: How do you ensure that you’re not throwing out the good stuff that (hopefully) gets baked into those deliverables – ie, the vision, the forest-level thinking?

Josh: First of all, the deliverable is not the thinking. It’s a record of the thinking and an attempt to share that thinking. But the best way to share the thinking is to do it together with another human in the first place. So our first recommendation is always to create collaborations that allow teams to create shared understanding.

We don’t advocate throwing away deliverables entirely though. Our friend Lane Halley (another former Cooperista) talks about the difference between leading documentation and trailing documentation. Leading documentation tells people what to do. It’s a spec, a requirements book. We try to get rid of those, and replace them with conversation and collaboration. Trailing documentation is a record of what you’ve done and decided. It helps the team go back and recall what you’ve done and why. We advocate in favor of these documents because they help the team keep a record of their decisions.

Jeff: We advise the teams we work with to come up with a hypothesis backlog instead of a product roadmap. A hypothesis backlog is a prioritized list of ideas the team has come up with and wants to validate. Prioritization is often done using risk as the primary delineator and, as each idea is proven or disproven, the team moves its way through the backlog of untested ideas. This way, none of the good thinking is thrown out or forgotten.

Doug: Are there simple steps to begin implementing lean techniques within an in-house product team?

Josh: What we’ve observed is that the grass-roots approach can work if you start small and build on your wins. Start by reducing the formality of your deliverables and instead have more frequent collaborations. Grab a colleague and sketch together. Work with stakeholders to reframe your projects around outcomes. Set up weekly user test sessions. And get our book, which is filled with very practical descriptions of tactics you can use to get started.

Jeff Gothelf has spent a 14 year career as an interaction designer, Agile practitioner, user experience team leader and blogger. He is one of the leading voices on the topic of Agile UX and Lean UX. Jeff is a Managing Director in the New York City office of Neo.

Josh Seiden has been creating great technology products for more than 20 years. As a designer and leader, Josh has worked in hardware and software, consumer and enterprise, mobile, web, and desktop. He is currently a Managing Director in Neo’s NYC office. Earlier, he was head of product design at Wall Street innovator Liquidnet, and lead pioneering interaction design teams at Cooper. He is a founder and past President of the Interaction Design Association.

1 Comment

Garth V.
how significant would the handicap be for a team of non-dedicated people attempting to follow your process? the members of our team work on the project at different times of the day -- sometimes because they're in a diff timezone, and sometimes because they've got a diff set of priorities (that day, that week) even though they sit in the same room.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment