Josiah Renaudin: Today I'm joined by Jeff Patton, who will be delivering a keynote titled "Lean UX: Turn User Experience Design Inside Out" at our upcoming Better Software Conference, Agile Development Conference, & DevOps Conference West. Jeff, thank you very much for joining us.

Jeff Patton: Thanks, Josiah. I am very glad to be here.

Josiah Renaudin: Fantastic. First, could you tell us just a bit about your experience in the industry?

Jeff Patton: Oh, boy. I've been in software development since ... it's getting ... edging close to twenty-five years now; I lose track. I am an art school dropout, and when you're an art school dropout and you go into software development, well at least for me, I design better user interface than other developers that I work with, so that made me the UI guy. But I learned very quickly early on that designing things that looked good wasn't the same thing as designing things that are good. There's a lot more to user experience design than that.

Since 1990, I've served about ... in every possible role in software development. In my company, I've actually rose to the role of product manager and these days, I help other companies figure out how to build better software.

Josiah Renaudin: Do you think your experience in art gave you an advantage when you're developing software and developing the look of these different systems and apps?

Jeff Patton: Oddly, when I went to the university, I was taking a degree in communications art. Part of that degree was fine art. A part of my study was fine art and painting, but part of it was advertising design, and actually that gave me a stronger background in what mattered.

Josiah Renaudin: (laughs).

Jeff Patton: Turning in a first advertising design assignment—and I thought it looked really good—and I put it up on the wall as a critique, and my professor and other folks gave me a ... they threw a WTF exception.

Josiah Renaudin: (laughs).

Jeff Patton: Because advertising has a job to do, it has to communicate something; it has a purpose beyond just looking good. We had to go back to, who is thing for? What message am I trying to communicate? What am I expecting the viewer of this message to do in response? That's the kind of art that made the biggest difference for me, it's recalling some of that advertising design stuff that matters these days.

Josiah Renaudin: You'd mentioned how much time you spent doing this particular field, so you've seen it evolve over time; why did creating smart user design take so much time and expertise in the past?

Jeff Patton: Like a lot of processes that's been turned upside down with agile development ... we're in a conference that is advertising and DevOps, and we're rethinking a lot of what the standard way of doing things is.

The traditional user experience design would start with some sort of ... understanding some sort of business purpose or business requirements would go into some amount of research and as rigorous as we could be, given time limits. Then focuses on some subset of user challenges we were going to solve, then create some design, and then validate that design. It was a fairly long linear process. It just took a long time and what was annoying is that you'd get all the way to the end and you would still not be right and you'd go into a lot of iteration then, and by then, after taking so much time ... it wasn't a lot of time to go back and fix issues that you found in the design as a consequence.

Josiah Renaudin: Before we get deeper in the conversation, can you define Lean UX and explain why this particular approach is different from what has been used before?

Jeff Patton: Lean user experience piles on to a lot of the thinking that came with Lean Startup. Lean Startup is about getting businesses up and off the ground. Lean startup applies to not just brand new businesses, but brand new ventures or brand new ideas within existing companies. And brand new ideas can be whole new products within an existing company, but they can be whole new capabilities in an existing product.

The idea behind lean as it's applied to products is ... instead of increasing the speed that we build things, instead of increasing that throughput of working software, we're increasing the throughput of knowledge. We're increasing ... well, the basic lean startup loop is a build measure learn loop. We build just a little bit, we put it in front of people and then we validate that we're building the right thing. And by build, I don't mean working software or from Scrum potentially shipping software, I mean prototypes or the smallest thing that we can build in order to learn.

What Lean UX does is take that same posture. We try to iterate as quickly as possible. Wherein traditional user experience design, we'd spend time really understanding the problems we're solving, we'd spend time designing, and then we'd spend time validating our solutions. In lean user experience, we do a lot of that all at once. Build a hypothesis about the problems we're solving. We use that hypothesis to come up with a solution, and then we put ourselves in front of users. We spend part of our time validating our problem hypothesis--who these people are and what problems we're solving for them, and the other part of the time validating the solution.

Josiah Renaudin: Now to dig deeper into Lean UX ... Why is it okay to guess and present more half-baked ideas within Lean UX? What changed to allow people to be more lenient in their design?

Jeff Patton: I think we're finally acknowledging our ability to guess right, even with deep understanding of the users we're solving problems for, they're still our guesses … Our ability to guess right aren't so good.

Let me tell a quick story. I do a lot of internal workshops and emergence inside of the companies that I work with. We did a very fast two-day workshop within an organization that did this just a few weeks ago. And on the middle of day two, I asked people to put their ideas in front of users. One of the strong UX people in the room ... well at the end of that day two, we did a highs and lows for this couple-day workshop. His low was being asked to put something in front of users with so little preparation or so little thought behind it, and his high was putting something in front of users with so little preparation behind it.

Basically saying, look, it may be really uncomfortable; have very little information as I was putting a concept in front of people, but in hindsight, I was so shocked at how much information I was able to get out of it. I was able to learn an awful lot by putting just a little bit in front of people and what I learned changed what I would put in front of them next time.

Your question was "Why is it okay?" I think we're learning to loosen up a little bit and understand that we don't need to know a lot to put a hypothesis in front of folks, and we can learn an awful lot by just putting a little bit. This is what makes it lean again. Lean is a bit about throughput in reducing cycle time and for focusing on that cycle time of learning, find that we can learn in little tiny batches a lot faster than learning in big batches.

Josiah Renaudin: How much of the communication between developers and their users alters how the user interface is designed? I'm a writer. I'm a journalist, and I'm publishing things weekly and sometimes daily, and a lot of what I do is I see … comments coming in critiquing what I'm doing. I'm guessing that's a similar relationship with you. You're putting something out there and your audience is responding and often giving you advice on what to do. How seriously do you take these critiques and comments from your user base?

Jeff Patton: Two things there to think about. First one, you're engaged in the lean process, and if you got a commercial product or a consumer product, you don't put it out in front of your whole audience, especially if it's half-baked. There's fast, and there's stupid.

Josiah Renaudin: (laughs).

Jeff Patton: (laughs) There's a few mantras that come out of the community; one is "Scrappy, not crappy."

Josiah Renaudin: (laughs).

Jeff Patton: So one of the things you do, if you're putting things out there fairly quickly, your first group that you're putting things in front of are individuals that you set up time with to review ideas and you let them know these are rough ideas and you get feedback. When you move up to something that you might be A/B testing or putting on a live site, you'll put those in front of us very small subset of your audience, and I've worked with some organizations that put things in front of what we'll call a CDP or “customer development partners,” the people that have opted in to look at early versions of products. So we want feedback from those people.

So we're cautious about getting feedback from everybody. The other pithy mantra that comes in is "Nail it before you scale it." We want to nail it or get it right with a small subset of our audience before we roll it out to everybody.

The other part of your comment ... or other part of the question was, yes you get a lot of comments back, but one of the core product-thinking concepts that I want people to understand is you choose your customers. I know people, for instance, that still think iPhones are stupid or still don't like them.

The market has spoken on that particular product and it does pretty well. You got to be fairly clear about who your customers are and aren't and when it comes to taking feedback back, it needs to be qualified feedback. You've got to have some understanding of who's giving that feedback, and if you expected a bad reception from one group ... but if you get a bad reception from the group you were really focusing on that's when it really matters.

Josiah Renaudin: And we were talking earlier about half-baked ideas and leniency in design when we were talking about Lean UX. Can it be difficult for people to comfortably break common and often established UX rules? How often do teams ... maybe even avoid Lean UX because they feel it might just be too risky and out-of-the-box?

Jeff Patton: What's interesting ... what I hope to talk about of the conference is, I'll be honest, most people don't understand user experience practice. In commercial and consumer products, there's a stronger UX discipline. If we don't really think about user experience and get it right, our products fail in the market. Within a lot of traditional IT development where we're building software for our own internal use, user experience is often an afterthought and we don't necessarily have trained UX people doing user experience.

Basically, if you don't have a user experience person on your project, it doesn't mean your software doesn't have user experience, it just means it wasn't designed very deliberately or at least designed by someone who's had a lot of training or background in doing that stuff. For people who are trained in traditional user experience thinking ... they spend a lot of time carving out room to be able to do it well or do it right and spend time doing research to really make good decisions first, and it really goes against the grain to throw a lot of that out. It feels wrong to start with.

There's a lot of similarities to ... maybe practices like test-driven development, where I as a developer may have spent a fair bit of time thinking through the design of building something first and being clear about the design of the code and then building it. Test-driven development asks us to leap before we look, or build a simple test to support a very simple design, then write a little bit of code, and then move forward. It's backwards for a lot of developers and it's counter-intuitive for a developers and it's a skill that some have learned and some still struggle with. Same is true for user experience people. We're asking them to leap a little bit before they look and it's counter-intuitive. It feels wrong...

Go back to the story I told earlier. It wasn't until trying it for the UX person I was working with a few weeks ago that it started to ... well he started to understand why, okay this can work. It wouldn't have been the way you would have chosen to do things.

Josiah Renaudin: I don't want to give away your entire keynote, so we'll end with this ... More than anything, what message do you want to leave with your audience in Las Vegas?

Jeff Patton: More than anything I want people to understand what user experience work is, why our products suffer when we don't do it at all, and how we can do it a lot faster and more effectively than we ever could before, and how ... there's one other key message that I'll point out ... how it's no longer a job just for user experience people. One of the things that's fundamentally changed about user experience is that user experience work now can effectively involve whole teams, developers, QA people, product managers, business people, business analysts ... everybody can be involved in doing this work with a good user experience person as a guide.

Josiah Renaudin: Thank you very much, Jeff. I appreciate your time today and I'm looking forward to hearing more about user experience at the upcoming conference.

Jeff Patton: Thank you, Josiah.

Jeff Patton started in software development in the early ’90s as a project leader for a small, software product company where he learned that well-written code and fast delivery are not the secrets to success. What makes the difference is understanding your customer and creating a great product. In 2000 Jeff worked as a product manager adopting Extreme Programming, gaining a strong appreciation for the discipline that agile thinking brings to software development. He received the Agile Alliance’s Gordon Pask Award for contributions to agile development and authored User Story Mapping. Learn more about Jeff at jpattonassociates.com and agileproductdesign.com.