February 24th, 2012
Lean UX can eliminate the contractual obligations inherent with specification documents and other deliverables. Designers and developers find it frustrating to put so much effort into a project then not see it ship at the end. Using the Lean UX process, you’re constantly validating your designs, especially early in the process. This motivates the team to work towards the same end goal.
Jeff Gothelf spearheaded this approach during his time at TheLadders. Through his own experience and through coaching other organizations, Jeff notes that teams implementing this process focus on a collaborative working process. Having the entire team on the same page allows for success in shipping better products, earlier.
A key part of attaining this efficiency and shared understanding is pairing designers and developers. By working so closely together, they engage in a consistent and open dialogue. Not only do they learn each other’s craft, they also work towards the right solution.
Check out Jeff’s full-day workshop from UX Immersion 2012, now in our All You Can Learn Library.
As always we want to know what you’re thinking. Share your thoughts in our comments section.
Jared Spool: Welcome, everyone, to another episode of the SpoolCast. And I have returning here Jeff Gothelf, who is now out on his own and at… what is the name of your new company? It’s so new I don’t even know the name of your company.
Jeff Gothelf: It’s called Proof.
Jared: Proof. Proof as in half the alcohol.
Jeff: Yes, exactly right.
Jared: Awesome. And Jeff is going to be speaking at our upcoming UX Immersion Conference, which is going to be April 23rd through 25th in Portland, Oregon, and he is one of the sort of thought leaders behind this whole Lean UX thing that’s been happening that we’ve been very interested in, because it’s got some really interesting attributes to it.
A few weeks ago, he and I had a chance to record a podcast where he sort of explained what the Lean UX thing is, and if you haven’t listened to that, we’ll put a link to it in the show notes.
But today I wanted to talk to him about sort of the downstream effects that happen when you get this stuff in here, because I’ve been realizing that this is really powerful, and there’s really something to it. So I’m very excited about what Lean UX means. It’s a new way of thinking about your process and everything.
So Jeff, welcome.
Jeff: Thank you, Jared, happy to be here.
Jared: And so, just sort of quick recap, Lean UX in 17 words or less.
Jeff: Oh wow, uh… Wait, that was three words right there.
Jeff: Lean UX is a rethinking of the software design philosophies and methodologies, moving away from the contractual obligations of spec documents and focusing really more on validating your designs through building products and experiments.
So in essence, your designs are hypotheses; let’s validate or invalidate those hypotheses as quickly as possible so that we can spend time going down the right path and less time going down the wrong paths.
Jared: Yeah, so you’ve actually had a chance, when you were at TheLadders, you sort of put this into play there, right?
Jeff: Yes, absolutely.
Jared: And then you’ve also been coaching and working with other organizations that are putting this into play. And they’re all seeing really positive results, and that’s what’s got me all excited about it.
Jeff: Yeah, the end results of this are really, really impressive. I mean, the most demotivating thing any team can undergo is to work on a project and then not have it ship. Nothing demotivates designers or developers or anyone else who’s involved with a particular project, is to work on it and then not have it ship.
And what I think is really powerful about Lean UX is that because you are validating your ideas early and often, when you get to the end of a project, when you are ready to ship, the thing actually ships. And that is a very powerful motivator for a team as they’re working towards some kind of end goal.
And when I’ve done this with teams at TheLadders, and I’ve helped other organizations put these teams in place, those teams who have successfully implemented the process have built a collaborative working process between designers and developers and marketers and product managers and business owners have been able to ship product, first of all, much sooner than they would have in the past, and to much greater efficacy. And so they’ve seen greater success, and the learnings that they get help them improve and refine the products on a much more regular basis.
And so then what you see happening is whatever problem statements or whatever metrics those teams are tasked with moving forward, they begin to actively move the needle on that. And that is impossible to hide within an organization, so whether or not they’re publicly touting their wins or not, the organization begins to see that there is success happening with this group over here.
And so what happens after that, what’s really interesting is that the other teams in the organization start peeking, kind of looking over the wall, looking over the cube wall or looking at other teams, and saying, “Hey, what are those guys doing? How are they doing it? Why are they able to move their metrics so significantly in such a short amount of time, whereas we haven’t actually done a thing to move our project forward?”
And I’ve seen this happen. The team becomes the envy of the organization, and ultimately, when that gets recognized by senior management, that team becomes the model upon which other teams and really the entire organization’s methodology is based on. It’s extremely rewarding, and a very powerful win for the Lean UX process.
Jared: So this is really interesting to me. And so let’s go back to what you were saying about shipping, we’ll start there.
So there are a lot of teams where something ends up shipping, but it doesn’t look anything like what the designers had in their head at the time that they turned it over to development, right? You know, in the traditional waterfall process of design and development, you work on all these documents, and you try and specify everything out to formulate this, what’s in essence a contract.
We say we want this to be built, you as the developers, you promise to build this thing that we want to be build, and we give it over to you, we pass it over the wall. And then development goes off, and some months later, through the rumor mill, you’ll hear, “Hey, guess what? That thing you worked on, it’s shipping next week.” And then you get a chance to see it, and it’s like, “whoa, that’s not what I did.”
Jared: Right? So help me understand, does Lean UX help in that scenario because we get much closer to what the shipping version will look like?
Jeff: Yeah, absolutely. And the reason for that is because there’s a shared understanding across the entire team almost from the get-go as to what exactly is being built and why it’s being built that way and the decision history that went into that.
And so as you iterate through this lightweight design process that’s focused on really just gaining as much insight and feedback as possible, you’re pulling in the other members of the team and you’re saying, “OK, we ran this sketch, what do you guys think?” and they give you some feedback. “Well, when we showed it to customers, they said X, when we showed it to business owners, they said Y, so together, we’ve decided to kind of move it forward in this particular direction.”
And as that’s happening, the entire team is coming along during that… it’s not a negotiation process, right? Whereas in the old days, like you said, it’s a contractual binding between the team that says, “I wrote this down, now you go build it this way,” and that’s really kind of where the beginning of the negotiation process starts with development and anybody who was traditionally downstream from UX and design.
When you employ Lean UX, what I’ve seen happen is the teams are in constant conversation around what this thing is going to look like, how it’s going to evolve, why it’s going to be that way, which is really critical, right, why. It’s not because the designer said so or because the business owner demanded it, it’s a combination of those factors, technical feasibility, input from the team, input from customers. And the team builds this shared understanding of what the end result is and what it should be.
And what’s extremely powerful is that they’ve set off to solve this problem together. Instead of saying go build this particular solution, the team has together come up with the right solution. And so there’s a greater buy-in from developers, from product managers, et cetera, and there’s a much heavier investment in the quality and the efficiency of getting the work out, and so they know all along the way what this thing is going to look like, there are no surprises.
Jared: That no surprises thing I think is huge, right? Because it’s really what snags a lot of folks. You know, the developers are surprised because they didn’t know this requirement was coming, the designers are surprised because nobody told them that they had to design for this implementation constraint.
You know, it’s really interesting, I was talking with one of the folks who worked on Google+, and we were talking about the constraints that she was under as she was designing it. She said, “You know, all my constraints came from engineers. I didn’t have any constraints from the business owners. All my constraints came from, ‘I don’t think we can do that technically.'”
And in a lot of organizations, the developers aren’t even in the conversations when they’re creating design, so those constraints don’t surface until they see these deliverables, and then they’re like, “How the hell are we going to do that?”
Jeff: Yeah, it’s really interesting. I’ve actually seen the opposite happen. When the developers are integrated into the ideation or the creation phase with designers the way that Lean UX advocates, I’ve seen developers come up and actually suggest features and suggest fixes and suggest UX enhancements. It’s not for the sake of, “Hey, I want to do it too,” it’s more, “Hey, I started building this idea, and I thought this would be really helpful in here.”
And it’s actually a very empowering conversation to have with a developer, because all of a sudden, you’re talking about the same things and almost in the same terms. They’re familiar with your language, they’re familiar with the toolset, they’re familiar with the users, because they’ve seen the users react to these products, and that has been one of the other most powerful things that I’ve seen come out of this process.
Jared: So a lot of the feedback I get from sort of folks who’ve been doing design for a really long time is that, “well, developers don’t know how to design”, right? ,”And if we let them design, they’re going to produce crappy stuff, that’s why we have designers in the first place come into the scene.”
And the other sort of objectionish-type thing I hear is, “well, if the developers start designing, what do we bring to the table?” When you were implementing this, did you ever see an instance where a designer somehow became suddenly obsolete?
Jeff: Absolutely not. Absolutely not. No, in fact, I’ve seen them only become more and more valuable.
Look, design is very tangible. Everybody feels like they have an opinion on it, they can see it, they like blue, they don’t like yellow, they think the button should be to the right or to the left. Everybody can have that opinion because the interface is so tangible.
But when you start to bring the team into the design process, and you show them everything that goes into that design process, the balancing of user needs, business needs, and brand and usability and mental models and motivations and psychology, they start to recognize the value of the designer, the strengths and everything that goes into creating these.
And so they will suggest things that perhaps they think will make the experience better, but they always have deferred back to the designer to say, “Do you think this makes sense?” or, “Does that work?” In this particular process, when they’ve been involved, they never bypass the designer and say, “OK, we’ve got this. We know how to design. Thanks for telling us how to put the pixels in the right order, we’ll see you later.” I’ve never seen that happen.
Jared: So is what’s happening, the developer maybe brings an idea to the table, and some of that idea actually has potential, but other parts of it, the designer says, “Oh, yeah, I immediately can see flaws in that.”
And now you have a way to have a conversation, I’m thinking, that says we can establish a vocabulary, we can establish an understanding, and I can help you as a developer understand what I know as a designer might work, might not work. Plus we can then create some experiment and see if either of us are correct, and suddenly we’ve got this collaboration thing happening, and we have this sort of shared understanding of what is possible, what works, what doesn’t work, in a way that you wouldn’t get when you’re siloed, right?
Jeff: That’s right. That’s the key, is that it’s not just, “Well, I’m the designer, I know what’s best, so you be quiet and just do what I say.” It’s more along the lines of hey, I’m the designer, you’ve seen everything that I do and what goes into all these decisions, so let me give you my opinion about this particular feature or this particular suggestion. And let’s validate this. It’s easy enough to run an experiment, let’s validate this with customers, or with stakeholders, or whatever the need is, and bring in that extra perspective that then says not only is designer instinct and designer expertise at play here, but there’s actual validation from the market and from the field.
Jared: And another thing that jumps into my mind is that from a distance, and we’ve all run into this, right, design is this color and font aesthetic thing, right? It’s the, “oh, what designers do is they put the nice layer of shininess on top of the wires so that when everybody looks at it, it looks like a real thing.”
But we as designers know that in fact, that’s the least important thing we bring to the table. The most important thing we’re bringing to the table is what is the right flow, are we asking the right questions, is the language on the screen the right screen? From a visual design standpoint, it’s not even aesthetics as much as it is prioritization of information, you know, is the most important thing jumping off the screen while the least important things are just whispering at the user at the moment they need it?
When you have the designers, the developers, and the business owners all in the same room sort of working on this collaboratively, suddenly all that subtly and nuance as to what design is about, that surfaces doesn’t it? I mean that stuff becomes transparent.
Jeff: Absolutely. That’s exactly what I was getting at. The value of the designer becomes even more evident when the collaboration is working at the highest levels. The expertise and the different disciplines that all go into software design and user experience design start to emerge and become very obvious to the team.
There is a much more… I don’t want to say legitimate, but it’s a conversation where it’s no longer us versus them. It’s more, “Well, these are the competencies that I bring to the team. Just because my title says ‘designer’ I actually bring in these different competencies.”
There is a recognition among the team that those competencies add value and that they justify opinions and suggestions through that expertise.
The conversation becomes much, much different and much more productive and less combative. Like I said, it’s much less of a negotiation than a conversation around what’s the best thing for the user and the business during this particular transaction?
Jared: OK, so I like this idea. I mean, I can imagine this scenario happening, right? A problem manifests itself. I’m the designer. You’re the developer. We both go off and take our own stabs really quick over a matter of minutes at what we think the solutions are.
You as the developer bring a solution to the table that’s pretty good, but I bring in a solution from my experience in having dealt with these sorts of things before that takes it to a level that’s beyond what the developer is seeing.
Suddenly as a developer you say, “Wow! I see where you got to, and I see how much better it is. I see how you got there, but in a million years I wouldn’t have been able to do that.”
I took a cooking class a few months ago, and I know how to cook. I love cooking, and I spend a lot of time in the kitchen. But this person could do things that I never even imagined one could do in the kitchen. He could slice onions faster than me in a way that I’ve never been able to do and things like that, and just to combine ingredients.
I was like, “Wow!” I was really impressed at that level of brilliance that, of course, I wouldn’t see if I just tasted the final meal. It’s a level of… You’re right. It’s some sort of collaborative transparency that doesn’t have a real good word for it. But it’s an appreciation.
Jeff: It is, and the more you have that and the closer you work with your teammates and the more these siloed walls erode, that transparency builds trust. And with that trust comes an even greater acceptance of the other team members’ competencies and the values that they bring in. So again, the same thing holds true for developers as well.
Jared: Yeah, I was thinking that. I was thinking it goes the other way.
Jeff: Just because their title is “developer” it doesn’t mean that they actually don’t have any design sense or that they don’t have any business sense. It just happens to be the field that they’ve chosen, but we should be open to hearing all of those opinions from the team as you get to know them and as you begin to trust them.
Jared: Oh, that’s interesting because I can see that. But I was thinking that as a designer I could learn a lot about development. I could learn more about what’s technically possible.
Like if we’re moving to a mobile platform, and this is one of my first times working in mobile but you had a lot of experience working in mobile, suddenly I could learn a whole bunch of things about that environment that I wouldn’t have known before and what is possible, what isn’t possible, what’s easy, and what’s hard.
Suddenly, I’d be learning sitting next to you in a way that I wouldn’t get if I just saw your final product at the end without seeing the process.
Jeff: Absolutely. I mean that’s another huge benefit of this transparency. As you’re sitting there with the designer and I advocate for designer developer pairing on projects so that you’re both learning each other’s crafts right away from each other. Obviously, at the end of that particular process you actually have a product as opposed to a document describing a product.
But as you’re doing that you’re learning things like the challenges of rounded corners and drop shadows [laughs] and et cetera and everything else that goes into building applications. That informs the design process moving forward. So it’s absolutely a very symbiotic relationship there.
Jared: Right, right. I remember when I first started doing design work, one of the things that I had to learn was that some dialogue boxes populate very fast, and others, because of the way the underlying database architecture works, you can’t populate quickly at all because you have to go off and look at every record and there are millions of records.
Whereas some, maybe you have some keys or shortcuts that let you get to that data really fast and sort of cache. It wasn’t until we started to build it that I could start to tell which types of queries were going to be fast and which ones were slow. I would be very bad at predicting that.
And of course, that speed thing is essential to good design, yet it doesn’t show up in wireframes. It doesn’t show up in most of the design deliverables that traditional UX design has. Then you end up with very sluggish systems when you don’t want them to be.
Jeff: Yeah, it’s easy to forget, but it’s critical to remember that the user experience of the product is not only the pixels, the workflows, the words, and the transactions. But it’s the systems underneath it that, to your point, make it snappy, make it responsive, make the transitions interesting, make things flip, make things turn [laughs] over, et cetera.
All of those things make up a portion of the user experience, and without a true understanding of our partners in development as to how those things happen, we still create these artificial confrontations. Unnecessary confrontations.
Jared: Yeah, and I wonder if you’ve ever had this experience, which I had a few months ago, where we were talking about a design idea. The immediate developer’s reaction was, “Yeah, we can’t do that. We can’t do that.” Then he had what I call a “shower moment,” where he came in the next morning.
He says, “You know, I was thinking in the shower this morning, and I came up with a way to do this.” Sure enough he’d solved the problem. Sometimes you need that away time to think about it but then come back and go, “Oh, OK. That’s how we do it.”
Jeff: The key is to build those relationships in your team to inspire those shower moments and to make your teammates care about the experience and the customer as much as you do so that when they are not at work they’re thinking about how to solve these problems.
Jared: Now that I hear you say it, I’m thinking we need a new term for “shower moment.”
Jared: Something about that just is on the verge of creepiness. We’ll have to come up with another way to do it.
Jared: OK, so now the last thing I want to talk about here. So you mentioned how other teams in the organization think about all this, and it reminded me of something that one of our clients is doing. So we have a client that’s got dozens and dozens of Agile Scrum teams throughout their organization, and this is all new for them, right? So they’re all moving to Agile. It’s all a new first time thing.
I want to point out here that you and I have talked about how Lean UX isn’t specific to Agile. But if you’re in an Agile environment, man, it can really help. So these guys are looking at this. So they’ve been looking at doing Lean UX-like stuff. They’re going out and taking their developers, their business owners, and their whole Scrum team out to visit customers and they’re doing all this stuff.
But they’re not doing it across the organization all at once. They’re doing it one or two teams at a time. Like I said, they have dozens, right?
So this is going to take a long time for them. So the way they did it was they got a couple of teams that were really feeling the pain of not having a good process and not producing and not shipping and all of this craziness.
They found a couple teams that were really feeling that pain, and they said, “Hey. We’ve got this new experimental process. We want to do this just with you.” They said, “OK, let’s try it.” They went off and then they did it. Within weeks you could start to see the progress. I mean, you could see them sketching and working together and creating this UX stuff.
Other teams started to notice, so they said, “OK. We want to do this.” Here’s the crazy thing. The folks behind this, the people who were driving it, said, “Uh, no.”
Jared: “It takes a lot of energy. We can only train a few teams at a time, so of the 10 or 20 teams that are really interested in this now, we’re only going to pick two. So we’re going to come up with a little contest, and you guys have to actually prove that you are worthy of learning this technique.”
Jared: OK? Man, did that make everyone nuts to have it! [laughs]
Jeff: Wow, that’s really interesting, to keep a process away! I’ve never heard teams clamoring, [laughs] competing to use a particular process. That’s fantastic I guess. [laughs]
Jared: Right. So once they finally got it, they were in this mindset not of, “Oh, my God! We have another process we have to learn. Oh, this is going to be awful.” They were like, “Finally we were picked!”
Jared: “We’re going to get to do this”, right? “And then we will be one of the ones who know it, and everybody else won’t be.” It magnified that sort of envy thing you were talking about earlier.
Jeff: Yeah, that’s amazing, and especially with so many teams to drive them to want to do that because I can imagine with an organization that large it’s difficult to see if one or two teams are doing this, they could hear about it. They may not interact with that team on a regular basis, so this is a good way to drive demand for that type of collaboration through an organization. That’s really interesting.
Jared: Well, one of the other things that really appealed to me about it is it signaled that we understand that not all teams are ready for this, right? Maybe the work you’re working on can’t be disrupted even by a moment because it would slow you down from an already critical path thing, and management is staring over you. Or maybe you’re not feeling the pain of whatever problems this new thing solves is.
It’s that open acknowledgment. But at the same time it also says, “Look. We have limited resources to roll this thing out, and we’re going to do it right. We’re not going to rush it and then screw it up and then not do it well across the organization.”
I could see that happening that if you tried to do too much at once with too many teams, nobody does it well. Then people blame it and say, “See? I didn’t work.”
Jeff: Yeah, especially if it’s a big organization with dozens of teams. You can’t coach the entire organization all at once and try to be successful. It’s just too much to the point they are doing it is focused on one or two teams, make sure they’re nailing it, and then move on to the next two teams and the next two teams and the next two teams.
My guess is that, as you go through the organization, the actual amount of coaching that you have to do becomes less and less, becomes a much more prevalent approach to doing work in that organization.
Jared: Yeah, and here’s another thing they were doing that was really cool. They were taking key members from other teams that were not on critical path, and they were basically putting them into the teams they were training. So when they were training a team, it was the original team’s members plus two or three other people who were not from that team but from other teams that would be there in the future.
Those people were like the foreign exchange thing. They were the kids from Germany. They were coming in, and they were participating in this as if they were team members for the duration of the project. Then they went back to their teams. Now, when they go back to their teams, they look at their processes and say, “You know, there are ways we can do this.”
Even though that team hasn’t been completely trained or learned how to do this, these guys are bringing that message back. And they’re cross-pollinating through the organization, and that seemed to really help a lot, too.
Jeff: Yeah, we actually attempted that at TheLadders where we would bring in folks from other teams onto the Lean UX teams and have them sit through our standup meetings and go through a project or two with us. They got a sense of it, and that helped at least plant the seed of the Lean UX process.
Then when they went back to their teams, they could at least start softening the beachhead a little bit for when we got over to that team to try to actually coach them explicitly on that. So they laid the foundation for the transition, and we did find that to be very helpful.
Jared: Cool. Yeah, this is all very exciting. I really am very excited about Lean UX in general, and I’m very excited to see your workshop coming up. So this has been really fun. Thanks for taking this time out of your day to talk to me about this.
Jeff: My pleasure, Jared. It’s been a lot of fun for me as well.
Jared: Cool. So everybody, if you are really working to get better designs out the door to actually ship them and to really make a difference, you want to find out what this Lean UX thing is all about. You’ll have a chance to do that at the UX Immersion Conference that’s going to be in Portland April 23 through 25.
Jeff Gothelf here is going to be speaking. He’s going to do a full-day workshop on this Lean UX stuff. You’ll work your way through an entire project and get a chance to experience it. Jeff, thanks for spending the time with us.
Jeff: Thanks for having me again, Jared. It’s been great.
Jared: And everybody else, thank you very much for encouraging our behavior. Hopefully we’ll see you in Portland. If not, see you on the next SpoolCast. Thank you very much.
During the podcast, Jared references a previous podcast he recorded with Jeff. You can listen to that podcast on our blog.Tweet