Jeff Gothelf on Lean UX in an Agency World

Jared Spool

April 15th, 2012

After listening to my interview with UX Immersion speaker, Jeff Gothelf, Ziv posed this this question:

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.

I sent the question off to Jeff, who supplied this awesome answer:

In an agency context, especially with existing clients, making Lean UX work requires the proper expectation setting up front. From the beginning of the engagement, even before the pitch, start setting the expectation with you client that this engagement will be different. There will be frequent check-ins, reviews, requests for access to customers and no clear, defined scope at the beginning of the engagement. Instead, establish a time box (a period of time for which the agency will be engaged) and agree on a problem statement the agency is being hired to solve. The other key thing to articulate and agree upon with your client is how you will measure success. What metrics will you use to determine that you’ve built the right solution to the problem statement? Once that is agreed upon, the iterative Lean UX process can begin. As you iterate note how your design hypotheses are measuring up against your goals.

At the end of the time box the client gets the best possible solution your team could come up with in that time frame. It will be a better solution than the one you would have scoped out in the traditional up-front heavy planning approach because you will be several iterations into it and have some level of validation to your designs.

What do you think?

9 Responses to “Jeff Gothelf on Lean UX in an Agency World”

  1. Peter Merholz Says:

    The problem with agency lean UX is not on the agency side, but the client side. Clients, particularly those with “procurement” practices, want a set of clearly defined outcomes/deliverables outlined in an RFP. Jeff presents here an approach that, while appropriate given the reality of the situation, has greater uncertainty than 95% of clients are willing to accept.

    What’s needed is not lean UX — it’s breaking clients free from an industrial era mindset that buying design services is the same thing as buying pencils.

  2. Jeff Sussna Says:

    I think that introducing Lean UX faces the same challenges as does Agile SW Development. It’s more than just expectation-setting. The agency needs to educate the client about how the lean process works and how it gives the client better results and greater value.

  3. Thomas Wendt Says:

    I think an absolutely crucial part of this process is having an account services team that understands how to articulate the benefits of lean. We can talk to clients about it, but at the end of the day, account people are the ones managing that relationship. If account people are not on board, the conversation usually revolves around delivering wireframes and not much else. That’s what so many clients believe UX is.

    Agencies need to battle against the deliverables problem by both managing expectations, as Jeff said, but also by actually believing in the lean process, scoping projects accurately, and being willing to explain the process in great detail when clients ask where all their money is going.

  4. Linda Says:

    Agreed a tough sell, but hey, we have been part of the problem and now we can be part of the solution. We have taught our clients how we expect to be paid and what we will deliver and invented all kinds of mechanisms to continue to get paid while project outcomes were uncertain. We have become experts at “managing scope creep” and “change control”.

    I think that part of the answer here is continuing to develop skills in value-based billing. This is the complementary piece to lean and agile implementation. We have to align our billing method with the delivery method. Right now we have supported a waterfall business model and it is this disconnect that is causing us pain.

    Haven’t agencies really been agile for a long time, but didn’t describe themselves in those terms? Didn’t agencies already iterate with mockups? Didn’t agencies already figure out ways to deal with cases where customers pushed back on designs to make sure they still got paid for the work? Didn’t agencies already have relationships with clients whereby the client didn’t know exactly what they were going to get, but trusted the reputation of the agency and their relationship with them such that whatever they got would be good, or the agency would work with them iteratively until it was “good”. Didn’t agencies already build in “focus groups” to validate design ideas and concepts (and I’m not suggesting that focus groups and usability testing or ethnographic research are the same thing, but the idea is that testing mockups with non-project, non-client people was part of the process)? Ironically, I think that agencies more so than services based IT consulting and integration companies, have always had an “agile” read “iterative” based process, based on trust, value and results. It seems like we are tripping over acknowledging that if we shift the validation step to customers/users, we are suggesting that we are no longer the wizard-like experts who know best (even though we never were). Instead, we are providing an enhanced way (through iterative model/build/test cycles) to arrive at the best outcome for the people the product is ultimately for.

    I agree completely with Peter that the mis-alignment of RFPs and other formal procurement processes have been problematic for years. Heck! They are even problematic for waterfall-style projects! Maybe that’s who we need to target with our thought leadership: the folks in those departments who set up the “rules of engagement”. Perhaps it is time for them to re-vamp their methods for selecting agencies, and service (consulting) vendors and funding/resourcing projects. My experience has been that often (especially for government contracts) the economic buyer’s hands are tied by the limits of their organizations antiquated procurement process. In the meantime, we need to find a way to “fit” our process into the language and requirements of the procurement process and perhaps the way we win with agile is through the old language of fit gaps, phases (each sprint can be a “phase”, why not?) “change control” can be used to deal with the inherent changes and shifts in a lean/agile project etc…

    Lastly, we have always had to deal with responses and demos where the potential client asks us to “do the projcet” to demonstrate the ability to do the project. This isn’t an agile mis-alignment issue, this is part of the problem with the procurement process. I think we have to have the courage to walk away from those engagements, with an explanation as to why.

    So, I think we aren’t as far off as we might think. It isn’t going to be easy, but it is doable, of this I am convinced.

  5. Alexander Says:

    I agree with Peter. Sarbanes-Oxley and similar procedures changed how we approach projects.

    Rather than saying we’re going Lean UX (or any flavor of agile) we divide the project into multiple, clearly defined parts. The individual parts vary depending on our relationship with the client, their internal procedures, and their experience working with agencies. In general, they divide into requirements gathering, design, build/launch, and maintenance. We always use the client’s terminology and adjust our process to match theirs.

    We don’t tell our clients the engagement is different. It scares them. We just don’t give them a choice. They get to choose the deliverables, but we specify the process. Our contracts states we will be on site, interviewing people, running tests, and having weekly meetings. Our client contacts are very appreciative and excited to be heavily involved in the process. Getting and keeping people involved creates project champions in the company.

    We don’t tell them the scope may change. We are professionals and we will deliver the best solution to the project requirements. However, the interviews and workshops we conduct expose new or irrelevant requirements. Our client contacts have told us to solve the new problem while they proactively talk to their managers to reset expectations.

  6. Lawrence Lipkin Says:

    It is going to required re-education on both sides of the relationship. The big challenge is having buyers work with Procurement. Procurement is all about saving cost and managing risk within corporate culture. From the buyer perspective: if not getting a (fictional) whole solution, why not just augment staff? Best answer I have so far: value from experienced co-collaborators, who can accelerate the cycle.

  7. Adam Says:

    In defense of waterfall, i like waterfall my clients like waterfall. A lot of dynamic factors in agileUX. Curious to see if it’s a trend in SW or is it gaining traction. My biggest issue is that the client does not understand agile as well as billing. yes time boxed etc.. how do bill for agile? and its not suitable for a distributed team, unless each team knows exactly what they are doing / goals on the same page style doc etc..

  8. Jerry York Says:


    You hit the nail on the head here. I have repeatedly heard that customers won’t accept agile practices. But I have not found this to be fact. Almost every customer I have worked with, agency or otherwise, has been very receptive to iterative user testing, rapid prototyping, collaboration and time-boxing. I found that direct and thorough communications solves most of these problems. The key seems to be agreeing on a problem statement and getting early buy-in from the executive class.

    Users/customers seem to love the involvement early and often. They see progress as it happens.

  9. Andrew Mottaz Says:

    I agree with the commenters who talk about this being a tough sell, maybe an impossible one. Having seen Jeff talk yesterday at UXImmersion Portland, I’m convinced that lean UX has a couple of core ideas that can function in any environment. The first is user-testing, validation and iteration which you can do in UX at the prototyping level. And I agree with Jerry York – this stuff is obviously beneficial and you won’t get pushback.( You can do it again in Agile Development, but at least you will have narrowed the scope ). The second, tougher one to do at an agency is to get a shared understanding with the developers. I guess if you’re doing design and development, you can get the shared understanding. But if the agency is doing UX and the client is doing development, the shared understanding part is going to be rough. ( Same with outsourced teams ).

    Our process involves both iteration and prototyping at the UX level, and further iteration and prototyping ( both with prototyping tools, and with prototyping in code ) during development. It’s effective for us, and our prototyping tool helps us bridge the gap by keeping the iterations and communication visible. It links the UX team to the dev team, even though its more of a ‘shadow sprint’ process than embedding UX in the sprint. My sense is that this method could be adopted between agency and client to get a shared understanding even with 3rd party or outsourced development teams.

Add a Comment