What Happens When You’re Gone?

Related posts:

In last month’s Johnny Holland column, I made the radical recommendation that UX professionals stop making recommendations to their clients. Nick Gould, CEO of Catalyst Group, commented that this wouldn’t work for him:

My clients would fire me if I didn’t come to them with ideas / recommendations for how to address problems identified in research. But we discuss the ideas and prioritize approaches together. We have a shared stake in the outcome. Maybe we’re already doing what you’re suggesting, but I don’t really see it as eschewing recommendations completely.

Chris Fahey, who runs the UX consultancy Behavior Design, thought we were talking about the wrong approach to the process:

This is why I think it’s silly that design research and design are ever done by different people. Or that strategy and implementation are done by different people.

This is why I run a design company – we don’t make recommendations, we make plans and execute them.

The Spectrum

We could plot these strategies on a spectrum.

On the one side is Chris’s approach of designing all the way to execution, delivering a detailed specification to the tech team, solving every design detail.

On the other side is my approach of letting the clients build and maintain the entire thing on their own, only providing coaching and guidance so they do it better. Nick seems to be right in the middle, providing recommendations to help them build it out. (Nick tells me some of Catalyst Group’s projects go all the way to execution—however, most go up to research deliverables.)

Spectrum

The Implementation Spectrum

This spectrum doesn’t only apply to UX consultancies, like Catalyst and Behavior. If you’re a UX professional working with an internal or external client, helping them create a better design, you’ll find yourself somewhere on this spectrum. Either you design the entire thing, teach the team to do it themselves, or are somewhere in the middle.

Should We Give Clients What They Ask For?

Clients, left to their own devices, will ask for all sorts of things. Some clients want the Behavior approach—to have the UX professional provide everything they need to implement the design—solving all the issues and providing exact instructions. These aren’t recommendations-—they are marching orders. This approach works best when the design, once built, will likely not change and the client shows no interest in developing their own design skillset.
For example, Behavior designed the award-winning site supporting HBO’s project for the TV series The Alzheimer’s Project. Once deployed and the final touches applied, this site probably won’t change much. Even if it does, it’ll be a discrete project that Behavior (or someone else) can rework, soup to nuts.

In contrast to Behavior Design’s approach, at UIE we assume the client team will make all the important decisions. We help them by giving them a process that informs their decisions. We look at the skills the team has and assess where they need help. Then we work closely with them on their techniques and process, giving them a way to tackle both their current and future projects.

Over at Catalyst Group, Nick’s team works with the client’s team while conducting their research. However, as Nick said, his clients ask for recommendations, so he gives them. The client is happy to get a great set of recommendations (and I’m sure that Nick’s group produces some of the best out there), so what’s the harm? He’s doing what they want.

Obligatory Ancient Philosophy Reference

I’m sure you’ve heard some variant of this wise ancient philosophy:

If you give a child a Nintendo, he’ll play all day long.
If you teach him to build his own Nintendo, he’ll become a millionaire, date hot chicks, and eventually start a foundation solving the world’s problems.

Is giving in to the clients’ desire to receive a list of solid recommendations the best for the clients?

What Happens When You’re Gone?

When Chris and the Behavior team are done with the HBO site, they move on. The HBO team doesn’t need to change the site, so they’ll move on to other projects too. The site keeps running as long as the servers are plugged in. Everyone is happy.

When we finish our engagement with our clients, they’ve learned how to do the work themselves. They can continue researching and enhancing their designs, using the techniques and tricks we’ve taught them. We’ve done our job and they’re happy continuing on their own.

When Nick and the Catalyst team have delivered their recommendations, their client goes off and makes changes. The question I have, however, is this: are they left in a situation where the only way they can make any further changes and enhancements is to call Nick’s team back?

Unfortunately, many projects aren’t like Chris’s HBO site. They need to evolve as the business, the technology, and the customers mature. They need new features, new enhancements, and new ways of thinking about the problems they’re solving.

Are we leaving our clients with the best possible experience? Are we considering that when we first pitch the project and its deliverables?

Preachy Professional Responsibility Section

Dumping a Jenga tower of recommendations in the client’s lap only delivers a short-term solution. It doesn’t give the client the tools to survive in the world for the long-term.

Yes, they asked for it. But clients ask for lots of things we tell them we won’t give them, like that really big fluorescent green blinking tagline. Just because they ask for it doesn’t mean we should give it to them.

This is where I get preachy:

In any new project, one of the first things we, as responsible professionals, need to consider is what will happen after we leave. Are we preparing our clients for their long-term best interest? Or, are we only shooting for the short-term deliverable, figuring if they wanted something more, they would’ve asked for it?

Once Again, Do We Need To Make Recommendations?

If we’re taking the entire thing through to execution, behavior-style, we don’t have to make recommendations.

If we’re helping the team learn how to make good decisions themselves, we still don’t have to make recommendations.

The need for recommendations may just be a placebo, to help a client think they are getting one thing when we are really doing something else. Or maybe recommendations are just a way for us to sell more project work.

What this comes down to is a philosophical approach to our work in general. Are we looking at the short term, or do we want to take a long-term view?

Where do you sit on the spectrum?

Jared Spool

Jared spends his days researching how teams create great designs as part of the team at User Interface Engineering. You can hear his latest research on how teams create their design principles at the upcoming UIE Web App Masters Tour across the US this spring. He is also behind the recently published masterpiece, Web Anatomy, even though his co-author, Robert Hoekman, Jr., deserves all the credit for the good bits. Make sure you follow him on the Twitters—he's pretty funny.

12 comments on this article

  1. Jesse on

    Good thoughts and an interesting article. The question I’m asking myself is: Is it important for all clients to have an internal UX competency? it seems both costly and maybe even unrealistic to ask all of them to expand their skill set to support this expertise when really what they mostly want to focus on is selling widgets. I’m always on-board with the idea of user-centered design thinking driving business thinking, but then again, not all companies can be Apple.

  2. Jesse asked:

    The question I’m asking myself is: Is it important for all clients to have an internal UX competency? It seems both costly and maybe even unrealistic to ask all of them to expand their skill set to support this expertise when really what they mostly want to focus on is selling widgets.

    Great question.

    It all comes down to who is making the decisions. If the consultants always make every UX related decision, with no input or influence from the client, then it would be a waste to improve the clients’ UX competency.

    However, once we deliver recommendations, we give the client the choice of following them or not. (That’s why they are recommendations, not marching orders.) Once they have that choice, they need to be competent enough to understand the options.

    Inevitably, part of the recommendation submission is an education process on why they should consider it seriously. I’m suggesting we take that education process a step beyond, to the point where that same client could’ve come up with the recommendation on their own.

    It’s a radical idea, but one that has worked well for us.

  3. Pingback: uberVU - social comments

  4. Jared I had this thought,

    Jesus said, “give a man a fish and he’ll eat for a day. Teach a man to fish and he’ll eat for a life time.”

    that is the major premise of your argument, right?

    But Jesus was a carpenter, not a fisherman. Isn’t your grand ethical approach a long term plan towards career suicide?

    Or am I over simplifying this (as usual)?

    I’m all in favor of the internal team approach and its great to get mentorship from folks like UIE when there are internal teams, but even when I am a member of an internal team and I hire an outside force to do work for me that I can’t do (happens a lot!) I would rather hire a Behavior Design methodology. So if I need mentorship, I hire for a mentorship. if I need to get shit done. I hire people who will get the shit done. Never worked some place w/o a UX competency b/c well I was there. ;-) But it does seem to me that those places need “shit to get done” more than anything else.

  5. Hi Dave,

    A quick search on the InterTubes says the original quote was from Lao Tsu.

    Of course, the same InterTubes says this about Lao Tsu:

    Popular legends say that he was conceived when his mother gazed upon a falling star, stayed in the womb for 62 years, and was born when his mother leaned against a plum tree. He accordingly emerged a grown man with a full grey beard and long earlobes, which are a symbol of wisdom and long life.

    You said:

    So if I need mentorship, I hire for a mentorship. if I need to get shit done. I hire people who will get the shit done.

    [I might recommend you hire for punctuation training. :) ]

    Part of the question here is: How much does the doctor let the patient self-diagnose?

    If you’re an experienced UX professional, being called on by an inexperienced client, do you let the client solely decide what’s best for them? Or do you have a responsibility, through the proposal process, to suggest on an outcome that will serve the client better than what they’re asking for?

    If the same client came to us insisting any crazy UI concept (think bad colors, blinking, tiny fonts, etc), we’d work hard to talk them out of it. How is it different if they come to us with a process that isn’t good for them?

    Is there an equivalent to the Hippocratic oath? :)

  6. Thanks for the kind words about Behavior’s work, Jared. I should add, however, that although the HBO project you cite is a fairly typical of Behavior project, we (and many other agencies) also work with clients in a variety of different ways. The “spectrum” you suggest can’t apply broadly to *firms* as much as to the *projects* we do, or even to different *phases* of a project or client engagement.

    Agencies, whether boutique-sized like Behavior or larger full-services firms, have complex client relationships where the actual work can fit into many positions in your “implementation spectrum”. The HBO project you cite, for example, is one of about 35 projects we have done for HBO over the last 7 years — every project with them is, in a way, part of a continuity of synergistic creative direction. With clients like this, we are never (as your title presupposes) “gone”. While such long-term relationships are typically chunked into discreet projects, between projects we constantly think about, propose, and talk about continuing ideas for such clients. I would hardly characterize them as a client disinterested in developing their own skillset. Rather, they want smart collaborators.

    With some clients, in particular web-based businesses, there are no big honking giant “launches” of new sites, but rather there is a continuous development and tuning of the system. In such relationships, we need to be incredibly intimate with the client’s team, product(s), and business — and, again, there is no “gone”.

    Even in a one-off project (and we do many of those, too, don’t get me wrong), there are of course aspects of the project where our work is dropping off deliverables and working products/sites, but if the site has a back-end component, or a content strategy, or a style guide, we need to train the client team on how to use those tools effectively.

    Finally, there are those clients who are already pretty damn smart. They don’t hire Behavior because they’re ignorant of design and technology and need outside experts to tell them how to do the interaction design thing the right way. They hire us because they want and need people *as smart as them* to work *with* them. I wrote an article about this last year called “The Myth of the Ignorant Client“. Many clients have great ideas. Sometimes theyb have bad ideas that we can talk them out of, or re-shape into good ideas. And yes, sometimes *we* have bad ideas that our smart clients talk us out of! Smart clients are the best. Again, HBO is one of these.

    This isn’t to dispute your ideas, but rather to add nuance. A vertical axis, perhaps, for the “level of engagement” (whether in terms of time or in terms of team-to-team integration) with the clients in question? Top=marriage, bottom=one-night-stand? I think it’s possible to be an “implementor” *and* have deep, meaningful relationships that are healthy and synergistic, just as it is possible to be a “coaching and guiding team” that, once done, walks completely away from the relationship without the least bit of ill will.

  7. We finished an engagement this week and have been thinking about this issue a fair amount as the dust settles. We were asked to provide insights about customers and help develop product and service ideas that these insights support. This was a lovely request, because we often have to point out to clients that they absolutely need to work collaboratively on generating the possible solutions if for no other reason than the best way to really “own” research findings is to begin to think about how to act on them. So the fact that our client was on board with that without us having to convince them it was a necessary step was fantastic.

    We talked with them ahead of time about how we would help them think divergently but we agreed that the next step was for them to huddle and think convergently. We gave them a heuristic for structuring that discussion.

    But as we were walking out the door, the walls covered with hundreds of ideas supported by their new customer insights (crazy ones, good ones, bad ones, obvious ones, challenging ones, easy ones, etc. etc.) there was more of an “oh, shit” than an “oh, wow” reaction. They’ve got some serious decision-making to do. So we’re doing a bit of head-scratching: did we not deliver as much value as we could have by leaving them in this state? We can’t make the decision for them; they need to decide and act and make stuff (and that’s what this team DOES). It’s a really interesting point in the engagement where it’s not 100% clear if offering more is working against our positioning, or if it’s crucial to provide this extra enablement, or if it simply delays the inevitable (and unenviable) activity of deciding and moving forward.

  8. Pingback: Stop rekomendacjom – czy dawać klientom, czego chcą?

  9. Chris:

    I agree with your points. I think there is more nuance than I let on in my original post (mostly due to my attempts at being concise).

    While I do agree it’s probably more project- than client-based, I wonder if there’s a problem with typecasting. The way we approach the first engagement with a client may have a heavy influence over our future engagements. If they see us as a consultancy that they only hire when they want a complete “one-night stand” project, then they may not consider us for other types.

    So, I think we need to be thinking about the outcomes, not only of the first engagement, but of all the future engagements, when we’re pitching that first project.

  10. Steve,

    You make an excellent point. When I say that we shouldn’t deliver recommendations, I’m not suggesting we stop the project short of the recommendation stage.

    On the contrary, I’m saying that we should see our role as guiding the client to the right recommendations. If they go in a direction we wouldn’t take, we work with them to understand the downsides of that approach. We make sure they get to where they need to be to intelligently pick up and continue.

    I don’t think your client would’ve been in a better position if you had done the synthesis and delivered a list of Here’s-What-You-Need-To-Do recommendations. It sounds like they just needed more assistance with internalizing, synthesizing, and deciding what they need to do next—something you’re very talented at doing.

    Again, this goes back to how we pitch the work in the proposal process. We need to start with the thought of the outcome—what do we want out clients to end up with, that will make it a win-win for both parties?

  11. I wonder if there’s a problem with typecasting. The way we approach the first engagement with a client may have a heavy influence over our future engagements.

    That is so true. An important consideration for any consulting engagement.

  12. The battle between delivering recommendations and the ongoing education is something I and my team face daily. As an internal UX team we work for stakeholders that have a wide range of opinions and agendas. This tends to force us to be the ones who provide recommendations which in turn get mulled over, debated and “prioritized”. Usually this turns the recommendations into something entirely different and what gets implemented is nothing like the original ideas.

    However, it is my belief and part of my team’s mission to continue our efforts of educating stakeholders on the value of a UX process and the ongoing benefits it holds. By teaching stakeholders (brand teams, product managers, etc.) how to think like UX designers and ask the right questions it makes handing over a set of recommendations more like a living document, fluid and open for change, rather than something that is seen as an all or nothing approach.