The term Lean UX is bandied about quite a bit these days. Along with it, there seems to be some confusion as to whether this is just a buzzword, a new way of working, or simply a new description for what people in the user experience realm already do. Jeff Gothelf of The Ladders is a champion of Lean UX, so Jared Spool sat down with him to find out what Lean UX was all about.

Taking inspiration from Lean Product and Agile development, Jeff describes Lean UX as a way of cutting down on the heavy documentation and getting deliverables out of the process. This process gets the entire team into a collaborative environment and helps to knock down silos, all while keeping the users top of mind.

One of the core ideas behind Lean UX is viewing each design iteration as a hypothesis. Jeff says you need to validate the hypothesis from both a customer and business perspective. The more wrong paths you can uncover quickly, the less time you are pursuing the wrong hypothesis. This makes Lean UX a way to integrate user experience into an Agile process.

Jared Spool: Hello, everyone. Welcome to another episode of the SpoolCast. And I have with me today Jeff Gothelf, and he is delivering a seminar for us, coming up, called “Lean UX: Getting Out of the Deliverables Business.”

Jeff and I decided to have a little podcast before our seminar, because there was a whole bunch of things that we wanted to talk about. In particular, for the last few months, I’ve been trying to get my head around what this Lean UX thing is, because every time I talk to different people I get different definitions. And I have a lot of friends and clients who are coming to me saying, “So tell me, what do you think this thing is?” And frankly, I’m still sort of figuring it out myself, and so I thought I would go to the source of all this and we would find out what Lean UX is all about. So that’s why I brought Jeff here.

Jeff, welcome.

Jeff Gothelf: Thanks, Jared. I’m really happy to be here.

Jared: Excellent. So, before we get into the Lean things, I’m assuming that life existed for you before Lean UX was on the scene. So, the pre-Lean days, I guess, back maybe when you had a little bit more weight than you do now.

Jeff: [laughs]

Jared: What precipitated all this? What was before that?

Jeff: Sure. So my career spans a variety of software companies, both large and small, and agency work, consulting work. So in the 14, 15 years I’ve been working, I’ve been around the block as far as the type of companies and the type of projects and the type of clients and so forth. And almost without fail, up until the last three or so years, we worked in what is known as a waterfall design. Whether it was a consulting gig or an internal gig at AOL or at Fidelity, wherever I worked, it was waterfall. It was gated design. It was the “define, design, develop, test, and deploy” methodology that’s defined the software development life cycle for the last 35, 40 years.

So that was my background coming into this. This was the way we had always worked. And there was discussions of Agile here and there on the outskirts of things, but my experience, primarily, has been waterfall.

Jared: Yeah. Well, I mean, Agile’s been around since about 2003 or so, but a lot of organizations really didn’t take to it until recently, right? It feels to me like it’s sort of a new thing, Agile in general, I’m saying.

Jeff: It’s 10 years old, and the momentum that it’s picked up in the last five years largely exceeds the momentum it had in the first five years of its existence. And I think that that’s largely driven by what we’re seeing in the market with the startup economy, the drive to innovate, the drive to get products to market faster, that the traditional ways of developing software seem to be falling short.

And so companies are reaching for other ways to get quality software to market faster, and Agile was there and is now finding its footing amongst a bunch of companies, as a philosophy, initially, and then through the various methodologies that embody that philosophy, like Scrum or Extreme Programming.

Jared: Yeah, OK. So let’s go back. This is a few years back. You’re deep in the waterfall world. And what sort of pain was typical of those days that sort of led to the thinking behind this Lean UX thing?

Jeff: The nature of a gated process is that it’s very, very siloed. Somebody does their work, and when they’re done, they hand you something, and then you do your work. And so the pain that we were feeling, we would design for months on end, with very little validation from users that we were actually heading towards the right thing. There were changes at the whim of executives. So executives would simply say, “OK, I don’t like red. Make it blue. Put that button over there,” with really no real reason or validation for that except whatever drove that particular demand from them.

Jared: That sounds to me like the old executive swoop-and-poop.

Jeff: Exactly. Exactly. And the seagulls were everywhere. Certainly everywhere in the waterfall worlds that I lived in. And then, ultimately, our focus was never the experience. Even though it felt like we were designing an experience or a product, we were actually designing a document. It was a document that depicted that product, the spec. And there was this feeling of empowerment: “Well, if it’s in the spec and I get everyone to sign off on that spec, then that’s what’s going to get built, and that’s the perfect vision that I have for this product.”

And then, in reality, the spec takes such a beating in the approval process, and then in the development process even worse, that I can’t remember a project where more than 50 percent of the spec actually got built as depicted in that document.

And that’s extremely frustrating for designers and doesn’t really get at what the customers need. Right? You’re developing for this document, which the developer needs to then go and build something that hopefully will work for someone down the line. And so you’re potentially building irrelevant products, and that was the outcome of a lot of the projects that I worked on.

Jared: So, when did this idea sort of come to you of what you now think of as Lean UX?

Jeff: TheLadders, where I work today, was a waterfall company, a startup, working waterfall, when I joined over three years ago. And as that company transitioned from waterfall to Agile, as the head of the user experience team, I took it upon myself to figure out how to integrate UX into Agile. So the roots of this really came from an Agile transition. Now, it doesn’t necessarily mean that Lean UX can only work in Agile, but the foundation, for me, came from figuring out how to take the Agile approach and make user experience work in it, which was a very challenging, and I think still is, a very challenging dilemma for a lot of companies.

Jared: Yeah. My take on this is that Agile was never really considered to be a user experience design tool or a process, right? I mean it was all about creating code more efficiently, and it was all about the code part of it.

Jeff: Absolutely. It was created by a bunch of developers. Actually, I was in Utah this summer for the 10th anniversary of the Agile Conference, and many of the signatories of “The Agile Manifesto” were there. It was kind of a big deal for them. Again, very, very few designers, very few UX folks. There is a UX stage at that conference these days, but again, it’s still not even a main point of consideration for folks considering this, certainly not at its inception either.

Jared: Right. And that makes sense, right? It was never a big center for it in the waterfall world either. I mean that was one of the complaints that we had was that waterfall didn’t really take UX into account in any sophisticated way, most of the time, when people did it either.

Jeff: But ultimately, we did get the design phase, right? The big, upfront design phase, that chunk of time, whether it was a week or three weeks or three months, that designers got to do their thing. They may not have understood what that thing was, but they got time to do it before the developers started doing their thing.

Jared: In the more enlightened projects, for sure. I think there’s still many, many projects where there wasn’t a designer to be seen, and it just got built the way it got built based on what the developers did. But yeah, that definitely makes sense.

But you’re right. In Agile, it feels like the design part is never there. In fact, I’ve had countless number of people tell me that they’ve been in some sort of Agile or Scrum Master training or something, and they’ve gone up to the instructor and said, “So, where does the UX stuff come in?” And they just get that sort of deer-in-the-headlights look from the instructor.

Jeff: And it happens a lot, and because there is no clear methodology. Now, there are several books that are being written on the topic. But the bottom line is this: I think there is a level of assertion that a senior UX practitioner needs to take in an Agile environment in order to make it work. I think, because of the developer-centric nature of Agile and because of the momentum that that has inside an organization, it’s easy for UX to get steamrolled by that process. And so there’s a level of self-determination that the UX folks in that environment need to take in order to inject themselves into that process.

Jared: OK. So here you were at TheLadders, and you guys were putting this Agile thing into play, and you were trying to figure out, “How do I get my UX stuff into that?”

Jeff: Yes. And so I’m doing research. I’m speaking with people who, in theory, have made Agile and UX work. I’m reading heartbreaking stories of Agile and UX failure on the web. And then I’m also paying attention to a gentleman on the West Coast named Eric Ries, who’s talking about this concept of the Lean startup. And Eric has been kind of the poster boy for this particular movement, and he’s written a book on it. And what he’s saying is resonating with me. It’s really interesting.

In essence, if you listen to what Eric’s saying and you read his book, he’s describing user experience and user research and, you know, getting out of the building and talking to customers and validating your assumptions. But his focus was: do the least amount of work necessary to reach those validations.

And that really hit home, for me, in figuring out how to get this UX integration into Agile. Because we’re working in such short cycles, and with a much smaller level of scope, what was the minimum amount of work that my team could do in order to keep feeding the dev machine? Developers can’t sit idle. You have to keep giving giving them work to do, keep giving them code to write. What was the minimum amount of work that we could do to keep that machine going and make sure that we’re developing valid products for our customers and for our business? And that’s really where a lot of these ideas came from.

Jared: So it really did come out of Eric Ries’s Lean startup stuff, which, in turn, came out of Toyota’s Lean manufacturing stuff. Right?

Jeff: Yeah, that was definitely part of the inspiration, kind of helped me figure out how to mix these two things that weren’t necessarily meant to go together initially.

Jared: OK. So that makes a lot of sense as to, then, why that term got on there. And I know that there’s a lot of confusion about it, right? There’s a whole world of people who think that Lean UX means, basically, taking shortcuts left and right. But that’s not what it is. It’s this idea of doing very short iterations, very focused work, cutting out any sort of fat that might be in your process that isn’t advancing that question of, “What is it that our customers and our users need us to build?” And then give that to developers, get it in front of them, and then see if, in fact, that really worked. Right? I mean, that’s sort of what we’re talking about here.

Jeff: Yes. Really, the two fundamental, I think, pillars of Lean UX, in the way that I’m defining it in my writings and in my talks and stuff, is that designs are hypotheses. No matter how great of a designer you actually are, whatever you put forward is a hypothesis. And so you need to validate that hypothesis, both from a business perspective and a customer perspective. And so you want to minimize the amount of time that you’re spending pursuing the wrong hypotheses.

Jared: That’s excellent. That’s excellent.

Jeff: Hence, the Lean aspect of it. The more waste I can cut out, the more wrong paths I can figure out quickly, the sooner I’ll find the right path. And what’s really interesting is that as you do this, as you discover that right path, if you do this in a collaborative fashion, you build a shared understanding across your entire team.

And with that shared understanding comes less of a need for the thick design documentation and the deliverables. So the reliance on the spec, to tell the team what we’re building and why we’re building it and what it needs to do, diminishes as the team understands why we’re pursuing certain paths and not others.

Jared: OK. That makes perfect sense to me. I remember for a long time thinking that every design is a prototype. Which is sort of the same thing here, right? So, Microsoft, when they finish the last version of Word, that’s really a prototype for the next version of Word, because they’re going to go off and study how people use Word to figure out what features to build, what items to go into it. They don’t just sit down and, for version 11 of Word, think to themselves, “Well, we’ve never done a word processor before…” They’ve got 10 versions of prototypes that they’ve built and shipped, and then there are all the prototypes that they built that they didn’t ship that go into this.

So, when you say it’s a hypothesis, it’s sort of along the same thinking there, that, in essence, you’re constantly trying something out and then learning from it for the next thing you’re going to do.

Jeff: Yes, absolutely. The main difference between Word is that you’re doing this in as short a cycle as possible, on an 18-month cycle, to figure out what that delta is for the next iteration.

Jared: Absolutely. So this, to me, seems quite smart, right? It’s very much looking at bringing down the time that it takes in order to get to the information you need, to know what you should be building.

Jeff: Yes. That’s exactly right.

Jared: OK. So that’s basically it. That’s the essence, and then everything that you do when you say “I’m going to practice Lean UX” are the activities you do to get to that shorter state.

Jeff: Yes. And it’s a significant shift in the way that many designers are used to working. So there’s this mentality, and I think it’s been built into designers, especially folks who spend a lot of time in agencies, but also internal folks, that they have to get it right the first time. The first design has to be right, and if I get it wrong, I’m going to lose the client, or they’re not going to like it. They’re not going to believe that I’m a good designer.

And so there’s this need to put something very polished and final out as the first iteration. And I’m pushing back on that and saying let’s reeducate our clients, let’s reeducate our stakeholders, and say, “Guess what? No one else in the process has to get it right the first time. Designers don’t have to do that either. Let’s get these ideas, these raw ideas, out early. Let’s validate them, as a team, understand why we’re making these design decisions, and get to the right path as quickly as possible.”

Jared: So one of the things that I’ve seen in teams — you can tell me if you see this with the people you’ve worked with — is this mentality that we have to get everything into whatever this next iteration of what we’re building is, because the world is actually going to end the day after. And if we don’t get it in, we will never have a chance to get it in next.

It’s not just the designers putting it into their designs, but it’s the whole product mentality of the next release has to have every possible feature we can think of. There’s all this sort of cramming stuff in, then when you give yourself permission to say, “No, this is not the end of the world. We will have many other times to get this right. What we want to do is figure out whether we’re going in the right direction or not.”

That permission to not have to get everything into the design, not have to get anything into the release suddenly frees you to really focus on putting something out there and getting some feedback, and then learning from that.

Jeff: Yeah, and that there are two organizational commitments that you need to make that a success. This has to be built into the culture or introduced into the culture of the organization in which you work.

One is the freedom to fail, so that there has to be a sense that if this is wrong, I’m not going to get canned. I’m not going to lose my job if I get this wrong. And then the idea of iterations, the idea of saying, “We’re going to incrementally improve this and iterate on this idea over the course of a couple of weeks, a couple of months, a couple of years” — whatever it is, whatever is relevant for that context.

But without that iterative approach the idea fails, because again, without that, then the designers have all the burden of getting it right the first time. So the iterative approach has to be built in there, and then the freedom to get it wrong the first couple of times also has to be in there.

Jared: So this idea, you’re trying to do things as fast as possible. You’re trying to get as many iterations into your release as possible. Each iteration allows you to micro correct and get to the right place.

What I hear you saying is that you have to be OK with the fact that sometimes you’re going to go off in the wrong direction. But because you’re going very quickly and each iteration is, in essence, pretty small, you’re not going to go off in a majorly wrong direction; you’re just going to go off in a small wrong direction and you can correct for that. The fact is that you’ve learned something and that’s really valuable.

Jeff: Yeah, and that’s the key. The key is to make the iterations short. Again, minimizing the waste, staying lean — this is kind of tying back to the whole Toyota thing — and designing the minimum amount that you have to to communicate your idea to your target audience.

So whoever you’re trying to validate with today or tomorrow, design the least amount that you have to to communicate your idea to that person. So for some people that could be a Word document. For other people it’s a whiteboard sketch. For others it’s a fully coded prototype. You have to understand who you’re trying to get validation from as you’re working towards these iterations.

Jared: Yeah. OK. I’m beginning to get this here. So when I talk to folks, some people seem to think that Lean UX is the latest Methodology, with a big M. It’s this packaged thing that has predefined processes and rules and things to do.

Then others are telling me, “No, no, no, no, no. It’s a mindset. It’s just a way of thinking. There are no set processes and rules. It’s just an attitude.” It’s sort of like being a hippy. “With no rules, man, we’re just going to go with flow.” It’s The Dude abides, type thing. Then there are others who are saying, “OK, there’s nothing new here. This is what we’ve always been doing. Someone’s just slapped a brand name on it and we’re running with it because it sells to executives.” Where are you sitting in that?

Jeff: So here’s the way I see it. The way I see it is this, I’ve laid out an example methodology in the work that I’ve published to date on Lean UX. That is one way that this process could work. If that process works for you contextually, that’s fantastic. In that case you can see it as a methodology.

But ultimately what happens in my experience is as you practice this methodology as a ritual over and over, it becomes a mindset. It becomes a way of thinking about software development and software design that’s different from the way that many organizations are working today. So by practicing the methodology, it becomes a mindset.

Now for me, as I was coming up with these ideas, I said, “This is really working for me well inside TheLadders. I really want to publish this and see what the community thinks about this.” As I was figuring out how to lay this out, I needed a wrapper for it. I needed a handle, something to put around it that said, “This is the thing.” Agile UX felt a little compartmentalized because I truly believed that this process can work in non-Agile environments as well.

So Lean UX, coming out of the work that I was getting from Eric Ries and others, seemed to be the right idea for wrapping. It’s just as a wrapper for me. It’s a handle for all of these ideas to go into one spot.

Now if people have been doing this — and some people have definitely come up to me and said, “Hey, I’ve been doing this for years” — that’s fantastic. And I’m jealous of that. I wish that I had spent the bulk of my career working this way. But there are many, many, many practitioners who don’t actually work this way who would like to work this way and introduce this concept to their teams.

Jared: OK. Yeah, so I get it. What it reminds me of is sort of like what happens in a professional kitchen. So a new chef comes into a well-established kitchen that’s run by a very competent head chef. That head chef has a way of doing things. If you’re a new chef, you’re not going to tell that guy who has been doing this for 30 years how to run his restaurant. If you’re smart, you’re just going to shut up and you’re going to do it his way and in essence learn his methodology.

But over time you’re going to internalize that and start to be able to do the things that he needs you to do his way. At some point you’re going to go off and open your own restaurant. You’re going to take that even further and do it your way, but it’s going to have those influences of that early person on it.

Jeff: Absolutely. I mean it’s the Karate Kid thing, right? He comes in every day and he tells him to paint the fence. He doesn’t understand why he’s painting the fence. Every day, paint the fence, paint the fence, paint the fence. Then all of a sudden he knows karate and then he goes off and he puts the pieces together that he learned when he was waxing on and painting the fence, etc., to build his own version of karate.

Jared: So what you’re saying is if designers read your book and follow what you say, they’re going to get a really cute girl.

Jeff: [laughs] At the end, yes. Yes.

Jared: And beat up the bully.

Jeff: Yes, yes.

Jared: OK. Now we know the purpose of Lean UX.

[laughter]

Jeff: It’s the purpose of everything, isn’t it?

Jared: Yes, I guess it is. Now that you mention it, yeah. Perfect. OK.

So it really does seem like there’s a pony in here, right? There is something to this; this isn’t just some branding of some activities that have been well-established. There is something here that’s different than what people are doing who aren’t really paying attention to their process.

And it’s important because — this is what I think — we could think of this almost as a statement that’s been running through my head for the last few days as I’ve been putting all this together. That statement is this — tell me how this works for you — UX in Agile is a question, right? We don’t really know, if you just look at it at the outset, if you look at what Agile processes are all about, there really is not a discussion of UX.

So there’s a question here. How do we do UX in Agile? And Lean UX is one answer to that.

Jeff: That’s correct. Lean UX is an answer to that. If it makes sense in your organization, it’s a great place to start. But it’s not the only place that it could work. I mean even within waterfall organizations I think Lean UX can make a lot of improvements. But it’s definitely a great place to start if you’re looking to integrate UX into Agile.

Jared: I think that one of the things that’s really nice about it is that unlike other approaches to UX, Lean UX to some extent sounds like you’ve built the techniques and the tricks from the ground up to fit in an Agile framework versus retrofitting old stuff into this new, faster way of developing.

Jeff: That’s correct. That was the genesis of this.

Jared: OK. So while there’s a lot of stuff that is in Lean UX that comes from other traditional UX practices, everything’s been rethought to say, “OK, it has to meet these constraints of really fast iterations, to work within the sprints, to be able to produce stuff really, really quickly.”

Jeff: Yes. The constraints really don’t waste effort on paths that will not ultimately yield some sort of value. That value could be learnings, it could be software, it could be customer dollars, whatever it is. But minimize the time spent on those avenues.

Jared: OK. This is all feeling very, very comfortable for me, and very smart I might add. You’re a very smart dude.

Jeff: Thanks, man.

Jared: Here’s a thought, just something to end on here. Do you think that Lean UX is actually a starting point and maybe five or 10 years from now we will have transitioned into something else? Or do you think that this is something that’s got even longer legs to it that will be around for a long time?

Jeff: I think this is it. I think we’re done. I think I’ve defined the end of it. [laughs]

Jeff: No, I sincerely hope that this is the beginning of an evolution towards a few things. First of all is the evolution of the user experience practice as stewards of the product and facilitators of experience design. I’m not saying we should stop designing, but greater facilitation of the creation of that experience itself.

Even more importantly, a significant tearing down of the walls. Tear down, man. Tear down the walls between teams, between developers and designers and product managers and business analysts and stakeholders. Really breaking down those silos and focusing on working as a cohesive unit towards solving a business problem.

What happens when you achieve that, and what I hope to see this evolve into is higher output teams that are more productive and that are wasting less effort and creating better products in the end. But I definitely see this as an evolution in the way that we work with our counterparts in software development.

Jared: Yeah, this makes perfect sense to me. I was working with a client just a few weeks ago. They have a group of designers who spend weeks and weeks and weeks producing these multipage documents that describe 12 or 14 new things that they want in the next release. Then they meet with somebody who then says, “You know what, we can only do half of those.” Then they collaborate together on what the “half of those” things are.

Then that group of people goes and meets with somebody else who says, “You know, we can only do half of that.” By the time they’re done they only get to do two things that actually get into the release after they’ve done all this work of producing all these documents. None of the design feels coherent when it’s done because it’s this hodgepodge of random things that were chosen because they could fit it into the execution schedule. It felt so broken to me. I see that over and over and over again.

It does feel to me like if you have everybody talking, and it sounds like what you’re talking about is that developers are understanding what design is about and participating in the design. The designers are understanding what it takes to get something developed and are participating in the development cycles so that it’s these tight little iterations instead of these really long 12 or 18-month processes. That just changes everything when you do that.

Jeff: Absolutely. What the Lean UX approach really espouses to do is to build transparency into the design process. By building that transparency and demystifying the black box of design, there’s a sense of trust that begins to grow between the different teams, between the different team members. It’s through that trust that higher productivity happens,that that shared understanding can develop, and that less CYA tactics, where I’m not running a lot of code until that wireframe is fully signed off, happens. Less of that happens because there’s a trust between the team members.

Jared: OK. Yeah. That just sounds so awesome.

[laughter]

Jeff: I think so, too.

Jared: That’s what’s happening at TheLadders. That’s what you’re doing, right? This isn’t just a wish; this is how you’re getting stuff done, right?

Jeff: Yes. We’ve had this in place for a while now, for well over a year. We’ve refined it and iterated on it and figured out how to make it work. What I’m really honing now is how to export it. So we’ve gotten one or two teams working very, very tightly together, working very, very well. How do we take that, how do we bottle that up and export it to the next team and the next team and so forth? That’s the big challenge that I’m facing right now.

Jared: That sounds really cool. That sounds really cool. So now, December 7th, you’re going to be doing a virtual seminar for us.

Jeff: Yes. I’m very excited.

Jared: So just really quick, what are some of the key pieces that people are going to get out of that seminar that makes this all worthwhile here?

Jeff: Absolutely. We’ll cover very explicitly what Lean UX is and what this core process is, and again, the foundational process that you can take and build off of and how that works. We’ll cover how to engage developers and stakeholders and other members of the team as well as customers in a leaner fashion and what to do with that feedback.

At the end of it, I’ll do two things. I’ll go through a case study that shows how we actually took this approach and scaled it up to a large portion of TheLadders organization to solve some business problems. Then at the end of the presentation I’ll give five very tactical things that everyone who attends the webinar can apply literally the next day or that afternoon at work, to start trying these things out and see how they work out within their organization.

Jared: That’s incredible. I’m very excited about it. I can’t wait to hear it. Thanks for taking the time and helping me understand about this Lean UX thing.

Jeff: My pleasure, Jared. Thank you for having me.

Jared: So as you heard, December 7th you can come and hear Jeff talk about getting out of the deliverables business with Lean UX at the UIE Virtual Seminar. You can found all of that out at uievs.com for UIE Virtual Seminar. Check it out. We’ll love to have you there.

Love the comment about “Design is a hypothesis..” interesting way of thinking and looking at it. It’s def how I’ve been doing stuff I develop on my own, never final polish my designs if I am planning on dev’ing them out, because they invariably change while I am working on them.

Definitely sharing with my team hear. Be curious to get everyone’s take.

I was wondering about the viability of integrating this methodology into a design agency that basically ends it’s work with a recommendations document with no real access to the development teams. It sounds like major shifts in people’s understanding of the process are needed to accommodate that.