Bio Jeff Gothelf has spent a 14 year career as an interaction designer, Agile practitioner, user experience team leader and blogger. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the upcoming O'Reilly book (2012), Lean UX: Applying lean principles to improve user experience.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Sure, my name is Jeff Gothelf and I’m an interaction designer and user experience designer by Trade, most recently I launch the company called “Proof” earlier this year, was a design consultancy in New York that recently became a part of New Context, which is a larger application design and development consulting practice based out of here in San Francisco. I’ve been an interaction designer for the bulk of my career and then in the last few years a fairly strong advocate for the idea of Lean UX and Agile UX, in fact so much so that I’m writing a book on it which is called, typically enough, Lean UX and if you are interested in learning more about the book it will be out in March of next year just in time for South by Southwest and you can go to www.LeanUXbook.com and that will take you to the Amazon page where you can preorder the book and learn more about it.
I’ve spent the last 14-15 years doing user experience in interaction design and initially very traditionally in a very waterfall kind of way, a very structured siloed, load serial process and then when I was the director of users experience at The Ladders, that company under went an Agile transformation, start to transform from a waterfall shop into an Agile development shop, and as the head of the design team, I had to figure out how to transition the work that we did to fit into Agile. And there were all kind of ideas and theories that help us take baby steps forward but none that actually made us really we think the way that we did our work, there is a lot of process steps, a lot of things of: do this a little faster, do this a little shorter, but ultimately the realization that I came to was there has to be a fundamental mindset shift, a philosophical shift in a way that we did design.
And when I made that realization, the effectiveness in the productivity and the efficiency of our design teams skyrocketed, because we went from just the people who push the pixels to the people who facilitated the design process and we opened up that design process to a lot of non-designers, and the ideas behind Lean UX and moving towards a much more collaborative design process across functional design process, came out of that transformation.
3. But what was wrong with the traditional, I mean so you have a traditional process where you’ll get some developers, actually you’ll get some front-end designers, you’ll get some business analysts, you’ll get some sales or marketing probably together in a room they decide the product, and then they kind of hand it off to the front-end guys and the back-end guys to finish it, is something wrong with that?
The way that it works in my experience, in many organizations that I’ve worked both big and small, there is some sort of product requirements that get handed down from above. Above can be product management, it could be an executive layer, could be a C-level executive, but somebody said “go and build this thing” and nobody is questioned why we are building it, it was just required, it was a product requirement and then we have to go and build it. In the way that that process works was someone who define what those requirements were and they headed to us and then we designed it and then we headed to developers and they say: “No, we are not building this”, because we don’t have enough time and we don’t have enough resources to build all that things that you design, so now go back and rework your specification documents, so get them to a level of scope that we can actually implement.
And so that process of going back and forth, and then when they finally develop something it was a fraction of what was actually desired and designed and defined initially. And that was nobody’s fault, that was a factor of the process, the process didn’t allow us to go back and rethink what we were doing, nor did it give us opportunities to talk to each other when we are doing our thing in our phase, and we never brought developers into the design phase, we never brought, designers never brought into the requirements definition phase, so everybody is kind of got what they were handed to them and there was such a tremendous amount of waste being generated there, hours and hours of time and pixels being pushed and documents being written. For products they will never going to see the light of day, there had to be a better way and the force of moving towards an Agile cycle, a rapid iteration cycle, forces you to rethink what you are spending time on and how you are spending that time, and if you are spending that time defining documents and living in this bubble where you think you are going to make everything perfect and it gives to somebody else to do their job, you are wasting your time and that was the realization that we made.
If we don’t bring in folks into our process and if we don’t create this collaborative, this cross-functional feedback loop, then no one is going to learn from each other and we are never going to be able to even keep the pace of this delivery cycle and the products that we are going to deliver were not going to be valuable to our customers, which is ultimately detrimental to us as a company and we have to change the way that we are working and it starts for me, coming from Lean UX world, coming from a design world, I felt like a change had to start with us, because in many ways the design phase could be seen by folks on either end of it as the bottleneck. Requirements go in, there is some sort of black box magic, voodoo stuff that happens in that process and then beautiful product designs and specifications comes out from the other end, but those designs never see the light of day in their entirety, and so how can we minimize the time that we spend designing things that are never going to see the light of day, and that was broken with the process.
4. But wouldn’t adding developers and other non-designers to the process earlier upstream kind of lowest common denominator for a design implementation, do you see like designs are getting a water-down because of their inclusion?
Absolutely not, I see the designs getting a much more realistic in terms of viability, feasibility, much more robust because look, there is a term that supply the designers and that term is Creative and some times they even refer to as Creatives or the Creative department, depending on the particular organization that you working in. I don’t see Creative as a discipline, I see it as a skill that everybody has but not everybody gets to utilize in the day to day of software design and development, and so by adding in developers, and QA, and product managers, and marketers, into the product creation, in concepting process, what you do is you are adding creativity for a broader set of folks who have different perspectives, and in return what they are getting it’s a much broader empathy for why they were building the things that were building, who were building it for, what pain points were trying to solve and that drives a level of motivation and efficiency and quality in the product, and ultimately, ownership and pride that is not seen in the waterfall and the siloed world.
5. This seems like almost a natural extension to Agile software development as many people know it where it’s typically build something, get requirements, see how it handles, show to a client, keep building repeat, why aren’t more people doing this already?
There is a very difficult mindset shift that needs to happen here to successfully build these types of teams that work in design product this way, the first thing is, there are two core components here: one is this attitude of experimentation. We are going to work quickly, we are going to work together and we are going to take our best guesses as to what is going to solve these problems. And then what we want to is we want to learn what are those guesses, those hypothesis, were accurate or not. Your organization has to allow you to be wrong for that type of process to take root. You have to not be afraid of fail, you have to not be afraid that you are going to be fired if you get something wrong, and in many organizations that is something that is not allowed, you are not allowed to be wrong, it’s frowned upon, that is the first problem, that is what’s not happening into a lot of organizations.
The second is your measure of success, most organizations measure success with output. What I mean by that is features. An output it’s a thing you put out in the world, the thing that you generate, it’s feature, it’s a product, it’s a service, it’s a widget, it’s whatever that you are building, and it’s easy to manage to output: “Did you write that document? Yes, checked, good job. Did you build that feature? Yes, checked, good job. Did you integrate Facebook, did you build that widget? Yes, ok that it’s great”. That is how people get managed and that is how they get rewarded. “Did you execute these tasks?” The Lean UX is really the startup and Agile approach to product development focuses instead of output on outcomes, and an outcome is the change that you are seeking to affect in the world. We are going to put out this app, we are going to create this feature, this widget and it’s going to generate some outcome in the world.
What is that outcome that we are seeking? Is it newsletters signups, is it increased sales, reduced shopping card abundance, is it customer retention, is it renewal rates? whatever it is, what is the business outcome that we seek to affect in the world, and when we measure your success with outcomes it’s quantifiable, even it’s a qualitative measure it’s still quantifiable and you can measure and manage to that, it becomes much more speculative is to which features will actually achieve that, and said to manager team towards outcomes, your organization has to again allow that freedom of experimentation. We think that building this feature it’s going to achieve this outcome, let’s find out very quickly. Guess what, the needle is not moving in the right way after 2 or 4 weeks of doing this, we were wrong, let’s try something else, and it becomes much more difficult to own that number and to manage to that number, it’s a more subjective play, but it gives you a much clear sense of business success, as opposed to simply productivity.
I think there are a couple of things, first of all there is a big push in the design world now for what it’s called The Unicorn. The Unicorn is essentially a generalist, is someone who can do user experience design, can do some level of visual design and some level of coding, front-end developing typically. I think the folks that you want to add to a team that supports this type of work process are people who, if they are not already generalists or unicorns, they at least have the potential and the desire to learn and become that, and the ability to wear multiple hats if that is necessarily. So maybe they are really good user experience designer with cursory knowledge of front-end development technologies and visual design. If you tell that I need you to get smarter about this, they will say: “Ok, I understand why, let me do that”, and you need to add people like that to your team and in addition you just surround them with technologists and product managers who are opened to their contributions into their world, and who want to contribute back to what the design team is doing, and then finally the organization has to support this culture of experimentation and this culture of outcomes and that is key, the freedom to fail is key to success to all these teams.
The best way for them is to be a part of the team, so the team configuration that I would advocate for is a, Jeff Bezos calls The Two Pizza team, it’s a team that you can feed with two pizzas, anything more than that it’s too big, and that seems to be comprised of technology, design, product management at the very least, and then any other if marketing needs to be involved, if business analyses needs to be involved, that is good, QA should be a part, but this should be small teams that are dedicated to a single initiative. So these are the same folks who are on initiatives from the beginning to the end, and that it’s how they learn to work together, There is no: “I’m going to talk to the tech team and figure out if they can do this”. That phrase would never happen in a true Lean startup Lean UX advocating team, because those conversations are happening organically because the team is sitting together, working on the same thing day-in and day-out, they are standing in the daily standup together and they are solving problems together on a daily basis, and the transparency that that builds drives a level of trust among those individuals, that again enhances the productivity and the efficiency of that team.
This is an evolution of software design. I think ultimately where this ends up is in this process that my friend and fellow QCon presenter Jeff Patton talk to that yesterday, which is this idea of co-making, where you are building these balanced teams of software developers, designers, product managers, etc, and they are collectively solving problems, they are contributing with their competencies and not exclusively with their job titles or their roles. So just because it’s a designer under a business card or product manager, doesn’t mean that they can’t write code, and just because it’s a developer on someone’s business card, doesn’t mean that they can’t contribute to the design. So you are building these balanced teams that are contributing all the comprehensives that they have to an effort and they are solving problems together from the beginning, and I think that is ultimately where this is going to end up, is in these small balanced collaborative teams.
Harry: Thanks a lot for your time today, Jeff!
My pleasure, thanks for having me!