What to do if client insists that we use an inferior design?

Question

This question is inspired by my co-worker's response to my perfectly adequate reasoning as to why Approach A would be more beneficial to us and the users than Approach B.

Rather than get into the specific issue we're talking about regarding A vs B, I want to ask the community here what to do in the case of a client (who is non-UX proficient) insisting that we use an approach that is inferior in terms of user experience, just because they are used to the old ways.

As their developer, I want to give them the best possible product, but I can't do much if they're not letting me.

Has this happened to you? What do you recommend I do about it?

Answer 1

The client wants to achieve business goals, and they hired you to help them do that. So frame your pitch in terms of their objectives. What business metrics will the decision at hand affect?

• Could an unnecessarily tedious sign-up form lose potential revenue? Could you perform a user test to prove it?
• Would a confusing experience generate avoidable work for the support team? Would simplifying the experience therefore decrease costs?
• Could small annoyances add up to a bad overall impression of the company, thus losing existing business?

This is also a good test of what’s really important about an experience. If you can’t defend a decision in business terms, consider re-evaluating your UX priorities.

For a more in-depth exploration of the topic, watch Jared Spool’s UX Strategy Means Business.

Answer 2

Without knowing the specific contours of your situation, my general workflow would be:

1. A/B testing can be very effective in this sitatuion.

• If you have the means, user base, and budget to do this. The measurable results can be very helpful in making a case.

• If you don't have the time, budget, or user base to do A/B testing, then consider other approaches (e.g. sampling, hallway testing, etc) to help generate primary data for your case.

2. Assemble the rational argument

• Prepare a paper, presentation or note listing the pros and cons of A versus B.
• Add the data from #1 to your case if it's available (even if it works against your preference...it's your professional responsibility).
• Using an objective/impartial voice helps provide credibility...as does citing facts, measurable data, academic papers, or articles to support the key points.
• If there is some change management involved (e.g. retraining users, or getting past cranky engineers or internal IT team), provide suggestions on how this can be managed. This can often help remove friction in a client decision.

3. Make your case

• Figure out who the key influencers and stakeholders are at the client site. FIgure out what sequence to orchestrate your case in (e.g. you may want to approach their internal UX team before the business guys, to help internal lobbying, etc).

• Figure out how to make your case without causing the client embarrassment. You may need to divide-and-conquer, or make the client believe it was his/her idea to begin with. You will usually also have to adjust your rational argument to fit the office politics/team dynamics/client relationship issues in play.

• Unless there is a safety, legal, or ethical issue at stake, your professional duty is not to convince the client of one particular solution, but to help the client make an informed decision.

4. If it doesn't go your way, try to measure-and-iterate

• If the client makes a decision you don't agree with, figure out a way to measure the performance (or lack of performance) of the decision and gently concede and suggest revisiting the decision later on after collecting some performance stats and/or user feedback.

  • Often UX decisions aren't won in the beginning, but are won over time as a client gets more familiar with UX and also with trusting your professional opinion. Creating a way to revisit the deicsion down the road helps de-escalate the tension today and provides a way to re-engage to find a better outcome once more data (and less emotions) are available in the future.

Answer 3

You're Wrong!!! (lol)

There are a few key points. First and foremost you can not approach the problem as B is better then A. Better is an opinion. There is no way to say "better" that doesn't come off like opinion. Instead focus on the projects goals. If the goal is to make 500 sales, then prove, with real quantifiable numbers that B will have more conversions then A.

For an example, one client I work with has a horrid looking site, that is difficult to use, and hard on the eyes. Anyone coding or designing the site would try to push it towards a "better" design. However, the site exceeds their current goals. They convert sales much better with an ugly, hard to use site, then they do with a nice clean design.

Next, remember that it's their money. If they want to pay you to implement a bad design, that's their call. It's your job to lay out the fact that it's a bad design, but it's theirs to make the decision on using A or B.

Finally, keep in mind that the "best" design is the one that meets the users' needs. A lot of times I see people go "flavor of the week" on site/app designs, when it's not the best design for the project. Sure a certain method may be more user friendly, but look down at your keyboard. QWERTY is by far not the "best"... and yet...

So, the main approach to take is that "You're Wrong" and you need to prove you're right. Prove that B is better then A using real quantifiable numbers. If you can't then you're still "wrong", and all you're doing is trying to force your opinion on them. If it comes right down to it, it's their money and they can always give it to someone else.

P.S. - Right and wrong in this answer are meant to demonstrate a clients feeling. You may very well be correct that B is better then A, but that's not going to stop the client from feeling like you're wrong, and that you're trying to bully them into doing it your way.

Answer 4

Just to go against the grain here:

• Do not rely on A/B tests.
• Do not use strong head-on rational argumentation.

These approaches are both saying "see, I'm right", when that's not how design works. For a good perspective on the limits of A/B testing, see this article. Yes, it's a useful tool, but it will not lead you blindly to a good design. Neither will hard rational arguments: even if you are 100% provably correct in every way (which you probably aren't), that will just cause them to dig their heels in. The better your argument, the less likely you are to get your way.

Here's a plan for getting to a better design:

1. Break the stalemate. Right now you and your client are opposing forces and only one can be right. Find a way to release this tension quickly, because the longer it lasts, the less likely they are to give up their position. As an example, you can decide that you will use their preferred design as a starting point, but to add another design sprint to do some testing and to see if the concept can be improved.

2. Small commitments. Do not ask them to switch sides in one move. That's not how humans work. Just get them to dip their toe in the water. Start with tweaking some details, or the option of a redesign after the first delivery.

3. Work on common ground, and mutual understanding. Yes, you want to optimize the user experience, but there are many other goals. The thing needs to make money, it needs to be secure and it needs to be done on time. Make sure that everybody around the table knows the elements of the application that they're responsible for. Create a picture of what everybody would like the app to be, and spend some time on crystalizing that ideal before you start making decisions.

4. Talk about your process. Spend time on discussing how you will design the app together. Don't just assume that people know, or that you have to do everything the boss/client says. Educate your client in the ways you work, and discuss what dimension of the app (costs, secutiry, UX) everybody will look out for.

5. Write user stories together. Broad ones, that make no assumptions about specific features. Focus on the who the user is and what the user wants. Ultimately, all stakeholders should have the same, clear picture of this in their heads. That will be your common ground.

6. Do informal user tests. Forget about A/B testing. It's not about showing your boss you're right, it's about showing him how users respond to the design as it stands. You can do this immediately, using nothing but a paper prototype. Make sure all the stakeholders watch the test live. Once the team sees how users actually behave, they'll grow a common ground. Do not set the test up as a decision maker, set it up as a source of information and insight into the user.

It seems as though you're already quite far into the process, so there may not be money or time to do some of these things (although there is always money and time to test). Use these principle to see what you can still salvage, and keep the rest in mind for your next process.

Answer 5

It's happened to me. What I can tell you is you present your case, use facts if you can ("this will save the users x seconds" or "X% of sites are doing this for these reasons"). Facts are important.

Ultimately the client pays for it, so they get what they want. I've had to make some silly design decisions before (nothing too bad thankfully), but you just move on to another project and do something else innovative. Small victories.

Answer 6

You are providing the client a user experience yourself.

The end product, be it tangible, intangible or mid-way will be theirs. They have the choice to ultimately decide the end user experience. You are hired to assist this development with your expertise.
If you feel like it violates the end user experience, make sure to notify them at the appropriate level.
If you keep nagging them, even though the product you provide will be more valuable, their usercustomer experience will deteriorate.

Answer 7

The best possible product that you can give them is the one they want, not the one you want. That's what you signed up to do. You take your best shot at convincing them of your ideas, but if they don't agree, then you are wrong. And in the end, you are a developer, not an evangelist.

Answer 8

This is an old book, and Dale Carnegie then could probably not have seen how the title wording would strike us now, but How to Win Friends and Influence People is indispensible reading for situations like this. And it is NOT Machiavellian; Carnegie trades in things like developing a genuine interest in the other party.

Another minor vignette came when a top business negotiator was fielding questions from the audience after a lecture. An audience member said, "If I could follow you around all day for one day, and learn and observe, what in a sentence would I pick up?"

The negotiator said "I only need two words for that. Listen better."

People who are better at communication (not sure that includes me) might include links to other essential works in comments.

Answer 9

It's not mentioned in other answers, but it's worthwhile to explain that your client and the end-user have different preferences. To put it bluntly, you're not making the design for the client, the client asked you to make a design for THEIR clients. Whether or not your client likes how something works doesn't matter.

However, this argument swings both ways; whether or not you like how something works doesn matter either.

So consider that as well. Do you want to implement X because YOU don't like "the old way"?

Answer 10

Show some evidence. Run an experiment.

An A/B test as @tohster suggests. Or do some usability testing on mock ups. Or do some paper prototyping. Or run a card sort. Or do some customer interviews. Or… whatever.

Without knowing the specific issue being discussed it's hard to recommend a specific mechanism. But there is pretty much always some rapid low cost mechanism to explore the issue that would be cheaper than making the wrong decision.

Answer 11

One thing not mentioned by other contributors is how to lessen the chance that they'll choose an inferior option. These are not my ideas, but unfortunately I can't remember the places I read them:

1) Only show the ideal option. It's your job to do all of the the thinking, consideration, and design in the area you've been hired for. Sure, prepare reasoning behind why that's the best one and have other options in your back pocket, but don't give them an inferior option to choose.

2) Don't ask for really broad feedback like "So, what do you think? Do you like this color/font/picture?" Ask questions that they have the skills, background, and knowledge to answer--stuff they don't need you for, like what the UI/page/product should accomplish. For example, after describing what a part of the UI should be accomplishing (e.g. "I designed this part of the interface to direct users to call to action #1, while making it clear where they can go for more information if they're not ready for #1."), ask if that's what they wanted.

In general, as stated by others, try to make your conversations about how what you designed will or won't accomplish the goals they have for it.

(And I shouldn't need to say that this: all must be done in a very respectful, non-condescending way, or they'll smell your pomp.)

Answer 12

The best way to convince is to use empirical data: Ask Your Actual Users. Run some user feedback sessions with them. Show them B and A, let them play with the user flow, then ask questions. Be prepared for both parties to be surprised by the answers (and new questions) that will arise.

Answer 13

I will probably get push back on this, but I'm going to say it anyways.

Let me first iterated that I enjoy colaboration. Working with other people and melding ideas it's absolutely the best part of what we do. I believe in exhausting all resources, and doing everything I can to help my clients achieve ultimate success.

While I agree to most of the feedback that tells you to listen, research, show supporting data, appeal to reason, show use cases etc. In the end you, the work you do and the reputation you get doing it, will be here long after clients have moved on for another designer/agency or perhaps their business has failed.

Sometimes when it gets right down to it, if you can't do good work. You absolutely know it's a mistake, and not an arbitrary artistic disagreement. You just might need to fire that client.

In some cases this has worked out positively for agencies. For instance when I first got out of design school, an advertising agency made headlines stating They had fired Nike as their client. The CEO stated that Nike hired them do what they do best, and Nike needed to let them do that. A small time later Nike came back and agreed with the agency. In the end of the agency was very successful.

I believe in life, art advertising and perhaps even more in a quantifiable, research, and case study, fact not oppinion driven field of UX. Where fighting for the customer is more than an idea. I'ts a passion driven empathetic roll, defined by each of us, and represented by our work, results, and integrity to question what we think we know. I remind myself before every qestion regarding UX, that even with two decades of experience my opinion is my own. without solid current research, and interaction with the user I can only attest to how I feel about the product.

Scary as it can be. To have big successes sometimes you have to take big risks. Sometimes you will fail and sometimes you will succeed! The truth is, all great ideas started with a person like you and me who was willing to take a very big risk. Today those are the design heroes we look up to.

I wish you the best of luck, and ultimate success for you and your client.

McLemore

Answer 14

Almost all the points have been covered here. I have gone through the cycle, and quite often, honestly, in spite of all the facts, researches, the client remained adamant on going his way.

What to do:

• Put all the facts and figures in front of client.
• Explain the implications of using the same old way. In series of discussions
• At last, when you see the deadlock not getting resolved, accept the situation but not before gently (not hurting or sarcastically) telling client that "you will be responsible for the results" "Only if you say so..."

Reason being simple,

• sometimes clients don't want to change
• Its their money and product and its more closer to them than to you
• They are humans too, some carry big egos. (Exceptional case)