Everything I’ve learned about Lean UX: AMA with Jeff Gothelf

| July 8, 2016
Sign up to get weekly resources, and receive your FREE bonus eBook.
Thank you!

Get ready for some great content coming to your inbox from the team at UserTesting!

Jeff Gothelf changed the way we look at designing products and services six years ago with his book, Lean UX. In a recent AMA-style webinar, Jeff talks about how things have changed since 2010 and what he’s learned as a practitioner, an author, and teacher of Lean UX. There were so many great questions, we wanted to share a few of them, along with a sampling of Jeff’s great answers, with you here. You can also listen to the entire webinar on-demand.

jeff-gothelf-01

What is Lean UX?

Lean UX, the ever-evolving definition that we’ve been writing and evolving, is combining the concepts of lean startup and design thinking with an agile cadence and mindset to bring a user-centric perspective to modern product design and development.

That’s a lot of jargon in there, what does that actually mean? It means that we build cross-functional teams, product, design, and engineering who have the customer at their core and making the customer successful as their mission.

It’s lightweight, it’s iterative, it’s low risk. And the value of the work that you’re delivering increases based on evidence that you’re collecting from those low-risk experiments and tests that you’re running, so that you’re only making further investments in a particular design direction or in the product direction, if you’re getting a signal from the market that says, this is something that we should be working on, and we’re implementing it the right way.

What’s the ideal structure for a Lean UX team? How and where should the UX competencies live and be structured?

Good question. I think that the most successful teams that I’ve seen are cross-functional. That’s the most important thing is to build cross-functional teams of, at the very least, product design and engineering.

Now, obviously, you want to augment those teams with the other disciplines that are required within your company or your domains, so you have subject matter experts that you can consult with.

As far as generalist or specialist, I think the difference really comes down to the size of your organization. The smaller your organization, the more you’re going to rely on generalists.

Does Lean UX create more design debt than traditional workflows?

Interesting. I love this concept of design debt, and I would encourage you to have that conversation with your colleagues because I think regardless of your process or your formula at work, we are incurring design debt as much as we’re incurring tech debt and other types because we have to make choices. We make choices; we make compromises because we’re trying to move forward with our projects and with our companies and products. 

I think that up front, you’re taking a lot more risks, and you’re trying a variety of different ways to solve a particular customer workflow or interaction. You’re going to throw away some designs, and you’re going to launch some things that are sub-optimal. That said, I think ultimately, you’re saving downstream design waste.

What are the pitfalls of Lean UX?

Good question. I’ve learned this firsthand, and so I can share with you some. Some learnings by actually stepping on some of these landmines myself.

First and foremost is, especially, if you’re working on existing systems, is to don’t jump into existing systems and start practicing Lean UX or these lean and agile ways of working. Assuming that there is no previous history or knowledge or worth that has gone into the system. We’d like to come in and think that, “Hey, we know better than everybody who came before us, and we can fix this and make it better.” In most cases, there is a reason why systems have been built a certain way. They’ve been hacked to a certain way. If you dive in without getting that context or that history, you’re going to break those hacks. You’re going to break that rationale, and you’re going to spend a lot of time cleaning that up.

Another pitfall is not advising your colleagues in other areas of the company about potential changes that you’re making to the workflow. I’ll give you two quick examples.

One is customer support. If you have customer support that supports your product or service, and then you run an experiment where you break or change the workflow, what you’ve effectively done is you’ve broken the call center scripts.

Other people who want to know about things that you’re doing are your marketing team. For example, marketers love to tell stories and if you’ve got a new idea that’s starting to get traction and starting to get validated and you think that it might shift, bring your marketing team in sooner.