When the Client asks for something ludicrous and insists

Question

Ok, so the client is insisting that I make a control that is essential to the website I am doing (it's the nav) into something that, frankly, no one would know what it was much less would click on it.

I mean, this isn't an opinion issue, he is straight out wrong. It's not revolutionary. It's not different. I just think if we took a .jpg of a bear that said "click me roooooooooar" it would be a more usable navigation.

We have disagreed before, and it wouldn't be a big deal if I didn't have a stake in how this site does and my name wasn't all over it.

However, he is the man that pays the bills. What do you do in this situation?

EDIT: It's a flash nav, that I'm not even doing. I am the most Sr. person and we have a flash guy and he's estimating three weeks time when we want to launch in three weeks. I can ask him to make a mock up but it would still take time away from us.

Answer 1

Could you do a mockup or functional prototype? He could give it a try and, if it's that bad, he'd probably see it for himself. Also, as finnw pointed out, you may not understand it correctly and he can better explain himself.

@Edit: 3 weeks to go and now he wants this? Tell him it'll take 6 - which is how long till take anyway, it being weird, it'll be harder to do - and see if he can deal with the delay/extra money.

Answer 2

Are you the most senior contact person for this client? I have found it helps when your own higher-ups back you up. Another thing that I have found helpful is to determine "what" the client wants to accomplish and suggest other ways to do the same thing.

Answer 3

Implement it then ask him to personally test it.

You may find he didn't mean what you thought he meant.

Answer 4

Tell him you have an idea that will work better and ask if you can code both up for him to look at. Show him your better way (and explain why it is more usable) alongside what he is asking for (and explain why his doesn't work as well). If he chooses your version, problem solved. If he chooses his version, then implement it his way and either retain him as a customer or tell him you think he ought to find someone else in the future.

EDIT: If you feel that the site will damage your reputation, you could insist that if it has to be done his way, that all reference to you or your company be removed from the site. Perhaps this will help him understand how strongly you feel about it.

Answer 5

Get him in a room with a few users (preferably his peers rather than yours), and explain both options to them. If they agree with you, he may bow to the weight of opinion.

Answer 6

My rule is, try to change his mind twice, then either do it, or find another gig. But if you do it, do it the best way you can, (cause you've already let him know you don't approve), and make sure there are no negative ramifications that could later be used to make you into the fall guy for any project failures or overruns...

Answer 7

You answered your own question. he is the man who pays the bills. do it, show it to him. If it's as bad as you say he might realize it once he sees it designed. I used to have arguments with my boss all the time over design issues... bottom line came down to, and he said this, its my bat, my ball, my bus... play the game or get off the bus. do what I tell you to do.

Answer 8

The Contractor's Creed

Tell'm what they need.

Give'm what they want.

Make sure the check clears.

The first point is so you can look at yourself in the mirror.

The second point is so you pay the mortgage on the house the mirror is in.

Answer 9

I used to work with a project manager who handled these kind of requests by adding an additional, and I quote, "fuck off factor" to the invoice. Some ridiculous sum which the client just wouldn't stomach.

Where reality impinges on such gratuitous responses, I find the best - indeed only - recourse is to A). pressure him into changing his mind or moving towards a different plan by weight of opinion (public, colleagues, managers) or B). just doing it and letting it fail. Hopefully the light will be seen after Option B, but it's never assured.

Edit: 3 weeks?

If he makes changes to the spec, you should be in a position where that demands another development iteration or a time extension. If this does impact your schedule, something failed in the contract area.

Answer 10

Implement it, charge for your work and wait.

If he asks to change it, change it as he desires and charge it again ;)

Answer 11

If you are sure you understand him correctly, and have explained the down side, and he still wants it, then do it.

He's an adult and can invest his money however he wants. Who are you to argue with him? (sarcasm not intended)

Answer 12

Show him two options, and try to be completely unbiased when presenting it:

• His idea, with an estimate of how much it costs, how much income/traffic/whatever this generates, etc.
• Your version, with an estimate of the same data.

After presenting the two choices (where it should be totally obvious that your version is much better), let the customer choose. This way he still feels like he is in control, but he will feel like a moron if he chooses his version. Its just a little psychology trick.

Answer 13

it sounds like this isn't a technical issue but a usability issue

you could refer him to useit.com where empirical studies confirm that custom flash-based navigation systems confuse the users, but it would probably be simpler to just get a few users (real users) into a room and show them paper prototypes of both navigation systems, then ask them how they think they would perform some common navigation tasks. Videotape the results and show it to the boss.

in the ideal world of technology and usability, you would be saving the boss from a GUI disaster that would lose business and credibility

in the real world, you would be telling him his baby is ugly

you've given your opinion, as a good consultant is required to do, and he has overruled your stellar advice. So, is it more important to be right, or to be paid? ;-)

Answer 14

You were hired for your professional abilities. If your professional opinion is not being respected and trusted, then that leads me back to the first point - why were you hired? If you weren't hired for your professional abilities and your professional opinion is either not trusted or not respected then why are you doing this job?

If you're only doing the job because you need the money, then you've gotta suck it up and bow to the guy that pays the bills... or find another job that will pay you what you need.

If you're doing this job because you believe in it and you have a stake in it, then state your objections and back it up with tangible data - usability tests, popular opinion, peer review and whatever else it takes to change their mind.

If you're not doing the job just because need the money then it's time to draw a line in the sand - on one side of the line you can suck it up and complete the project, on the other side of the line you quit and find something else. Pick a side of the line, state your terms and stick to your guns.

In the programming industry your name and your reputation are all you have - if you don't honour your own principles and standards, then how can you expect others to live up to them?

Answer 15

It sounds to me like you've made a rookie mistake. Correct me if I'm wrong, but it sounds like he is paying part of your salary as a percentage of revenue.

If you are a regular employee, then this is normal and you should just take his direction and execute.

If this is a contract gig, then we'll call that mistake numero uno. There is a fundamental difference in how clients treat you depending on how big a check they have to write. If part of your "pay" is a percentage of upcoming sales, then you will always get screwed. However, you will have to take his direction and execute.

If this is a real partnership, then obviously something isn't quite working out and you guys really need to decide who is in charge of what. Which, incidentally, should have been worked out before any work began.

Answer 16

There is a controverial yet simple rule: Don't discuss solution with the client, discuss requirements.

It is almost by definition that client knows much less about what it takes to build a robust solution than the craftsman, in the opposite case they would have built it themselves or hired someone less qualified and told them exactly what needs to be done.

It is unrealistic to expect that you will be able to teach the customer everything you know, and although you can be expected to justify most important decisions and trade-off you've made as part of the design the customer will need some basic domain knowledge to understand your choices.

I understand you've listened to the client carefully and this is the best solution to the problem as you understood it you could come up with given all your accumulated expertise and the timeframe. If the customer does not like the solution this is probably either because:

• You didn't fully understand the problem that needs to be solved or didn’t undertake a thourough testing of the solution. Back to the drawing board then.

• The initial requirements have changed. Not that unusual; make sure you’re still happy with profitability or any other interest you’ve got in the job. Study new requirements and devise a solution.

• The work standard is below expected. Well, you’ve done your best, haven’t you? Subsequently you won’t learn any better overnight, especially by doing something you know is wrong.

• The customer does not appreciate the standard of your work. Well, there is nothing you can do, really.

As the bottom line your customer has the right to reject a solution and during everyone's work life that is guaranteed to happen more than once no matter how good the solution is. Don’t loose your sleep over it, just move on. In the long term, this relationship won’t do you much good anyway.

On the other hand probably the next greatest thing about loving your job you can do as a professional is to develop an impartial standpoint. You won’t be able to do either if you let folks who is ignorant about the subject to mess up with your work, this is a certainty. Quite simply: “take the solution as it is or we need to discuss the original problem again".