When Your Client Is Wrong

Contrary to the old adage, your client is not always right. No matter how "client-focussed" you think your business is, the fact is that you are the expert (that's why they're employing you, after all) and sooner or later, part of your expertise is going to be needed to save your client from themselves. You're going to have to say "No" to your client in a professional manner, without making them feel stupid.

Your No needs to be reasoned, one that comes with a suggestion for something better - or at the very least, time to have another look at the design to see if there's anything better that can be done.

For businesses where the client can't do the work themselves, or can't see the workings of the system, this situation is less common; it's rare (but not unheard of) for clients to look at code and take it upon themselves to tell developers how to implement a solution, line by agonising line.

When it comes to user experience, however, everyone and their mother are users; so everyone has an opinion about the user experience. This too often means that clients can take it upon themselves to identify problems, design solutions, and expect you - as resident UX expert - to rubber-stamp your approval of them.

Sometimes - not always, but sometimes - your client gets it wrong. And it's your job to tell them so, as nicely as possible.

Some example scenarios (and how you might say "No" in similar situations) below.

How it starts

You get a call from your client, telling you there's a couple of "usability issues" they want to talk through with you. They've had some feedback from users (good) and they've designed some solutions (uh-oh!) that they want you to check and implement (bad).

The thing is, you realise when you take the meeting (or, more often, when you're called into a meeting halfway through), that the proposed solutions don't work, for one reason or another.

Example Scenario 1

Maybe the proposed change moves a navigation button out of the recognisable, familiar navigation area, and into the area used for breadcrumbs and navigation context.
("Yes, I see that action button doesn't seem to fit anywhere else, but your users aren't used to looking for completion routes in that area of the screen. Where you're proposing to put it is inconsistent and confusing. Let's have another look at the intent of that screen.")

Example Scenario 2

Maybe some text has been added to the screen, instructions to help the first time or occasional user; and that has resulted in a muddled screen that's going to confuse first timers and infuriate regular, expert users. In fact, it turns out that the screen was already quite complex, and adding additional elements to it only makes it more so. Time to go back to the design and consider a different approach.
("You're right; it looks a multi-screen process. Perhaps it would be clearer to use a wizard-style step-by-step approach, which expert users can bypass to get to...(a simplified version of) the screen we originally designed.")

Example Scenario 3

Or perhaps the solution breaks one of the guiding principles of the design.
("Yes, I understand that you want the instructions to stand out, but by covention we've only used red for errors. Using that bold red font introduces a jarring inconsistency. Let's have another look at the colour pallet and see if there's another colour we can use.")

These examples all identify real problems experienced by real users; they're the result of user testing (very good!) and do need to be resolved. The point here is that the proposed solution is often too reactive; focussed on solving a specific issue at a micro level, for the particular set of test users that identified the problem. And in doing so the fix damages the user experience for the larger set of users. Or the suggested fix breaks established interaction principles, but "it's okay because it's just this one screen, and that's already a bit special anyway".

In short, whilst they might not realise it, the client is breaking the user experience principles they've signed up to, under the banner of fixing "usability issues". They're effectively picking and choosing; creating exceptions to the design where they see fit. Before you know it, the clear, consistent user experience you've designed and tested is a muddled mess that confuses the whole user community.

In these situations, it's your job to take the step back and consider the holistic view, and tell your client, honestly, what they need to hear: No. You need to put them back on track, save them from themselves, pull them up from the detail.

And yes, you might also need to re-consider the user experience design following the user feedback; as Steve Krug says, there really is no substitute for user testing.

---

How often do you come up against situations like this? And how do you manage your clients and preserve your professionalism?