Interview with Laura Klein: Lean UX, Patching, and Pain-Driven Design

Laura has spent more than 15 years as an engineer and designer in Silicon Valley. Her goal is to help startups learn about their customers so that they can build better products faster. Her book, UX for Lean Startups, and her popular design blog, Users Know, teach product owners what they need to know to do research and design. We wanted to get to know her better before her webinar, "Lean UX" with Eric Ries on October 8th.

What is lean and how is it different than agile?

Lean is all about learning and about shortening the cycle time to getting information.  It’s not about being cheap, or even about being fast. It’s about learning quickly and validating hypotheses and it’s about not having untested assumptions. Lean UX is about getting feedback from users, doing good user testing and understanding how to do user research.

All of those pieces have always been a big part of user-centered design (UCD), but what makes Lean UX different from just regular UX is that it tends to be done in an agile environment.  There’s a lot of feedback from things like metrics and analytics, which was not possible back in the old days of waterfall and packaged products that showed up on store shelves.

What makes something lean is when we’re getting user feedback and iterating throughout the life of the product. We have the mindset that the product is always changing and always growing. We try things and we learn from what we try.

"Lean UX is about getting feedback from users, doing good user testing and understanding how to do user research."

A big part of that is reducing deliverables. We need to avoid the mindset that we need to develop a picture perfect Photoshop mockup for every deliverable.  Instead, get feedback earlier. If we work as part of a balanced, cross-functional team, then we can constantly get feedback from other members of the team and learn more quickly than if we design on our own. It’s all about learning.

One of the concepts in your book is “pain-driven design.” What does that mean?

I believe design doesn’t happen in a vacuum.  Design is not art.  Design should solve a problem for humans. We can find the problems that we’re causing for humans by looking for pain points. Usability testing helps us understand the very obvious pain that we’re causing for users, which is fantastic. But beyond discovering user pain in our products, we should be doing user research on various demographics and understanding what in their lives is causing them pain.

If you can identify something that is causing people pain and you can develop a product that takes that pain away, that product is very likely to be successful.  The goal is to find the most important pain point and then to find a way to solve that pain for people in a usable way that doesn’t actually cause them more pain.

"If you can identify something that is causing people pain and you can develop a product that takes that pain away, that product is very likely to be successful."

Designers should be working to identify and solve root causes, not address symptoms. I actually have a word for addressing symptoms, it’s what I call patching. For example, on Amazon clothing pages, right above the “add to cart” button, there’s some text that says “before you can buy, you need to select size and choose from the options on the left.”

The reason this copy is there is because people look at the coat and say “Oh, that’s cute” and try to add it to their cart, without noticing the selections on the left that aren’t anywhere near the “add to cart” button. It’s not obvious to the user that they need to do these things. The solution to this problem would be to put all of the selections closer to the call of action so it’s obvious to the user in the first place. Instead, they “patched” the problem. They added some microcopy that tells users to go over to the left, and even added a “no-clicking” icon that prevents users from clicking the add to cart button.

I’m sure the clothing team knows this is a problem, but can’t get another team to modify the template. Instead, they can only add copy that helps patch the problem. They’ve exposed their org chart in the interface of their product page.

The doctor analogy in my book is good because it’s one thing to be able to diagnose pain and it’s another thing to be able to actually treat the root cause. I think people tend to be better at identifying pain than they are at thinking about the root cause of the problem.

Why do startups seem to be more successful in lean implementation?

Typically startups are more nimble and more agile because they have fewer people involved in the decision-making process and so they can learn faster.  If you work for a larger company, you’ve probably got a whole user research department that is responsible for going out and talking to users and then taking all that information and communicating it to five different people who are responsible for actually making product decisions.

That’s a much longer cycle time for learning than if I’m a product owner and I want to learn something about a user. In that case, I’d just go out and talk to some users and then I just know. That’s a shorter cycle time for learning.

So should enterprises even try lean?

I think it’s always worth trying, even if the iteration time is longer. Even if the iteration time is longer, you should still be improving old things. This is a big question for companies. Do we release a bunch of new stuff or do we improve what we already have? I think the companies that do better are the ones that really improve their core products instead of just adding new ones. Users don’t pick products because they can “do 97 things.”

"Most people don’t want a product that does 97 things. They want the thing they want and want it as easy, fast and seamless as possible."

Most people don’t want a product that does 97 things. They want the thing they want and want it as easy, fast and seamless as possible.  People always ask me what my favorite mobile apps are. My answer is the ones that I don’t even remember that I use them because they’re so easy to use. I want an app that is so easy I no longer have to think about, it’s just a part of my life—something I do.

Apple just released the new “swipe to go back” gesture in iOS7. How would you suggest organizations approach changes like this through the lens of lean UX?

I would be fascinated to see how many people who’ve just downloaded iOS7 find that gesture and use it regularly.  I don’t know the answer to that.  Is it 100% or 5%? To me, undiscoverable or hard to discover gestures seem to be a kind of “advanced user mode.” For instance, I’ve been using Macs for 10 years, and I literally just found a new track pad gesture by mistake.

Undiscoverable or hard to discover gestures seem to be a kind of an “advanced user mode."

I watch real (a.k.a. "non-tech") people use products a lot and I’m fascinated by the stuff that basically everybody I know in tech just takes for granted that non-tech people don’t discover at all. Based on that understanding, I always encourage startups specifically not to innovate too much on the standard stuff.

Take the new swipe gesture, it’s a great feature, but if Apple hadn’t introduced it, I probably wouldn’t recommend a startup build an app that depended on the functionality. It’s one thing for Apple to introduce something, but it’s another thing for your company with a couple hundred users to try to introduce a totally new paradigm for interacting with the application. If you were really set on building an app with that type of paradigm-changing functionality, you’d better test your product and watch real people use it in order to see how discoverable the new feature is for real users.

We love this quote in your book: “Lean UX is not bad UX. Building a good user experience isn’t cheap.  You can’t refuse to spend money on research and design and then say you’re being lean. You’re not. You’re being stupid.“  

When it comes to UX research, people often say things like, “Oh, we didn’t have time to do research,” or “we’re moving fast,” or “we’re breaking things.“ (that’s for sure!) Lean isn’t about being cheap. Lean is about learning, and you can’t learn without some form of research. If you try to learn without research, it’s called guessing.  The goal of lean is to eliminate waste.  So in that respect, it is cheaper because you hopefully will research and learn and avoid costly mistakes.

I often have conversations with people whose new product launch did not do too well. When I ask them about the usability research they did before the product was launched, it typically goes like this:

Them: “We didn't have time to do any usability research, we had to get it out the door.”

Me: “Did you have time to fix it after all your customers complained because your product was broken?”

Them: “Yeah.  We had to fix it after that happened.”

Me: “Then you had time to discover the problems before you shipped it. Now you have to build your product twice, which is slower and more costly than building a prototype, testing it, and building it right once.”

So it's not necessarily about building it small, it's about building it right. Build it, test it, and make sure you're on the right track. You're not going to build it right the first time, that's the point. Admit that you're not going to get it right the first time and find ways to figure out what you're doing wrong. Like what you've read? Go ahead and watch the informative on-demand webinar.