It’s no secret that we love being lean, and I’m not talking about physique. The spirit of lean methodology is what allows our company to tackle any objective head-on (rather than being cornered by constraints), and it’s what creates the flexibility for us to adapt, iterate, and evolve our design solutions in both an informed and effective manner. But speaking of applying lean principals to UX design, there’s actually an UX extraordinaire named Jeff Gothelf who wrote all about the subject!

Of course we’ve been wanting to mind meld with Jeff on all things lean UX for a while now, so today you can read all about his insights and thoughts on the industry in this Q&A we’ve had the pleasure of having with him. Enjoy!


So, how do you pronounce your name? (And where did your twitter handle come from?)
It’s pronounced as if there is a dash between the GOT and the HELF as opposed to GOTH and ELF.

When Twitter first came out I found it intriguing and as an early adopter by nature, I signed up. However I didn’t take it seriously and never expected it to last too long so I decided to use a “throwaway” username. I was listening to a lot of Lauryn Hill at that time and in her recordings she refers to herself as L-Boogie. It wasn’t too much of a stretch from there to JBoogie. And here we are…

I squat on the @Gothelf username but don’t use it much. I’ve often considered switching over to it but it seems the whole JBoogie thing has stuck at this point.

For the readers who may not be familiar with Lean UX, can you give us your elevator pitch about what you do and what your book is about?
I work for a company called Neo. Neo is a product innovation company. We partner with companies to help them build and reinvent their digital businesses. Lean, Agile, Design Thinking, UX and great software engineering are at the core of what we do. Within Neo I function as the company’s Lean evangelist, spreading the gospel of great team collaboration, product innovation, and evidence-based decision-making.

In that role I consult with companies as a speaker and thought leader on the future of product development and user experience design, often teaching workshops or giving talks on building cultures that support teamwork and innovation.

jeffgothelf_03

In March of 2013, along with my co-author Josh Seiden, I published Lean UX. The book is a practical look at adjusting the way UX design is done today to accommodate for greater team agility, transparency, and collaboration. It asks tough questions – e.g., how do we know we’re designing the right product? How do we know our designs will work? How long should we wait before we find out? How do we decrease the waste in our product design process?

Lean UX advocates for an open and collaborative design process that focuses on building the team’s shared understanding of the problem being solved, eschewing thick documentation (for the sake of documentation) in favor of real-time communication, and objective decision-making criteria (i.e., evidence from the market).

Objective-Based Design: A creative approach to solving any business challenge

How did you start your career in UX and what kind of “a ha” moments did you have that led you to your current methodology?
In the 90’s I was a touring musician with a couple of East Coast bands. At the end of the decade the bands were winding down (it’s hard out there!) and the Internet was becoming a “thing.” I was always a computer geek at heart since my first 300-baud modem and Commodore 64 so it wasn’t long before I was deconstructing websites to get the basics of HTML down. I started building sites for bands using my nascent markup skills and an on-the-job training in Photoshop basics. Shortly after that I got hired as a web designer at iXL – one of the bigger web consulting shops during the first dot com boom – and started actually getting paid for doing this work. Shortly after joining iXL, my boss came to the team meeting with the, now legendary, “Polar Bear Book” (aka Rosenfeld and Morville’s Information Architecture for the World Wide Web). He asked, “Who wants to be an IA?” Of course none of us knew what that was but I volunteered to take the book home. I read it over the weekend and realized this was exactly what I wanted to do. From there my career progressed with the evolution of the Web from information architecture to interaction design and finally to broader user experience work and team leadership.

Ten years into my career I was at a crossroads. The work I loved doing for so long had devolved into primarily “spec writing.” I wasn’t designing as much any more and felt very frustrated especially since much of the design I was documenting wasn’t getting implemented anyway. I was beginning to question my career choice if the future was comprised of increasingly more documenting and less actual design work. The timing of this lined up nicely with the rise in recognition and popularity of Agile. I was working at a company that was just beginning their Agile transformation and was tasked with building a UX team there. In studying other Agile/UX teams I learned that most of them were failing to bridge these two methodologies. This didn’t make sense to me. Agile is iterative. Design is iterative. Why couldn’t they work together?

jeffgothelf_05

I spent the next four years experimenting, learning, and ultimately building a set of teams that managed to overcome the Agile/UX divide. The “a-ha” moment came when we realized that without early and frequent input from the rest of the team into the design, we were wasting tons of time. The leap forward we made after the first time we held a cross-functional brainstorming session was transformative. All of a sudden we didn’t have to wait days or weeks to find out what the developers were thinking. It sounds simple in hindsight but it was groundbreaking at the time (and still is for many teams).

What do you feel is the biggest misconception about UX?
It’s tough to believe this is still happening in 2014 but there are still many companies, leaders, and project heads who see UX as strictly graphic design – a last level of polish to make the software pretty. They fail to invest in great UX design because they assume they know most of the things a great design process ultimately reveals. If all there is left to do is “make it pretty,” the designers are handed whatever shred of time is leftover after the rest of the team estimates their work and these projects rarely succeed.

Here at DT, we’re big fans of building Lean. As you know, a core component of the Lean Startup methodology is the build-measure-learn feedback loop, and part of that is determining the minimal viable product (MVP). How do you go about defining an MVP? Moreover, how do you stay focused on the MVP as other great ideas come during the design process?
We defined MVP in the book as “the smallest thing you can make or do to test your hypotheses.” As a team we make a ton of assumptions about who we’re building for, what problem we’re solving, and what success looks like (for them and for us). These assumptions form the building blocks of hypotheses – testable statements we believe to be true. This is the biggest risk in software development. We take (often educated) guesses at what we think will work but we rarely test these guesses before investing heavily. MVP’s are these tests.

To create an MVP the team must sit down together and build consensus and a shared understanding around:

That last point is the key to it. You can’t build an MVP to learn everything. You have to decide that the first thing you want to learn is, for example, “do our users actually have the problem we’re fixing” or “will the context of use allow us to deliver content on a tablet.” Once you decide what the first (or next) thing is you need to learn, the next question is, “What is the least amount of work we can do to learn that?” Anything more than that is wasteful. MVP can be, and often are, software based. But they don’t always have to be. Perhaps it’s a landing page or an in-person sales pitch backed with a paper prototype. It all depends on what you need to learn.

Lean teaches us that we’re always moving from doubt to certainty – preferably in small steps. As our level of certainty in our assumptions increases, the fidelity and sophistication (and subsequently the investment level) of our MVP also increases.

Focus comes from discipline. Discipline is derived from vision. The product’s vision serves as a constraint on the team. It helps us define what problem we’re solving and what’s in and out of scope for us. As great ideas come up, we have to ask ourselves if they are within the project’s constraints. If they’re not, we don’t work on it. If they are, we have to then prioritize these new ideas against our existing backlog. This is why it’s critical to have team alignment on the vision of the project.

On the topic of conceptualizing, do you feel there are diminishing returns when it comes to UX research? At what point do you stop researching and get it live?
Again, I would ask the team what they’re trying to learn next. If it’s related to customer intent, usage patterns, and problem statement validation, user research works great. When you want to get into usability, actual usage and efficacy of certain workflows you need to move to working code. How much code you need to write is, again, dependent on what the riskiest question is at the moment.

jeffgothelf_02

You’ve built your career on great UX. What is your driving motivation behind what you do, and what do you feel fuels your inspiration?
When I started my career, I was motivated to make things easy to use. I have an innate sense of logic and organization that made information architecture and interaction design natural fits. As my career has evolved and the complexity of the software we’re making increases, I’ve realized that the only way to build great products is to change the way we work together. While great design and user experience is still very much inspiring, these days I get fired up when I see teams working well together and releasing successful products regularly. This is a reflection of great collaboration but, perhaps more importantly, a culture that supports learning. To me, that’s endlessly inspiring.

Comments
  • Fantastic interview and piece overall 🙂 Thank you!

  • Charles

    “Agile is iterative. Design is iterative. Why shouldn’t they go together?” They often don’t gel well in part because though, yes, Agile is “iterative,” it’s really only iterative in the project’s solution space. “Iterative,” to Agile, often means hill climbing, the refining of a decided-upon solution, all post-decision. This is very different from the iterative vetting and abandoning of ideas. Agile assumes you already know what the right thing to build is, which is really the difficult question to answer. Would be curious what Gothelf’s thoughts are here.

    • Hi Charles –

      You’re spot on. Agile processes have been optimized to get features out the door. They’ve not been optimized to determine *which* features to get out the door and how to best implement them. The lean process helps put a “brain” on this Agile process to ensure we spend our iterations on the most promising ideas.