The old adage says that the customer is always right, but anyone who has ever worked with a client knows that isn't quite as easy as it sounds. Even so, we do our best to meet their needs/wants/whims. We are trained to think that saying yes to clients is the way in which we can deliver good value. After all, we're agreeing with them and giving the client what they want.

That's good, right?

Actually, it isn't always. By saying yes too often, you're not only hurting your client, you're hurting your team. Here are some compelling reasons to start saying no.

Problems vs solutions

Your clients spend a lot of time with their problems - they live with them every day. As a result, they've spent a lot of time thinking about them before they've even walked through the door. By the time they speak to you, they've moved past the problem and are already on to generating potential solutions.

Here's an example client thought process to show how this works:

  1. I want to increase my profits.
  2. I could sell more products if customers can find what they want more easily.
  3. Amazon has a good search facility and makes lots of money.
  4. I want to have a search facility like Amazon.

The requirement which they would then give to you is the final one, "I want to have a search facility like Amazon". They've given you a possible solution (not even the only solution, since there could be multiple ways to approach this). A search facility isn't actually the problem they were trying to solve.

As developers, we want to understand the problem. If we built the Amazon-like search facility the client asked for and their profits didn't increase as a result, we wouldn't have actually helped them achieve what they wanted. They would actually be worse off, because they would have spent money on development that they didn't need.

Luckily for us, we can easily avoid this by asking a few investigatory questions to help us drill down to the root issue. For example:

  • "If we build X, what do you think that will achieve?"
  • "How do you think that X will help your company/service/team?"
  • "What benefit will X give to your users?"

Your client may not know the answer to these questions, because they may not understand the problem that they're trying to solve. Although this can be a frustrating situation, there's also a considerable benefit to knowing what you don't know. It's often a good idea to go right back the drawing board and use a process like double diamond to clarify what is being asked for.


In most cases, your client is not a developer. If they could develop this thing themselves, they wouldn't need you. They are coming to you, the expert, for advice. This is why they pay you the big bucks.

If your client comes to you with an idea and you use that as your requirement straight out of the box, you are actually depriving them of your expertise. Expertise that they have, in fact, paid for. (At Design It; Build It, Chris Hammond called this the "Would you like fries with that?" mentality - taking requests and translating them directly into requirements, without doing any additional analysis.)

Below are a small sampling of topics which you most likely know about, but your client doesn't:

  • Usability principles
  • Accessibility laws
  • Industry standards
  • What's supported in different web browsers
  • Best practice for building things in JS/HTML/CSS/language of your choice

I could go on and on.

This doesn't mean that you should just ignore everything your client asks for. But you should take everything that they say with a grain of salt. Get to the root of what they want (problem vs. solution, remember), and then apply your own expertise to help them come up with something better. You also have the benefit of experience - you do this every day for a living, whereas your client will only go through this process once (or at most occasionally). You will be aware of far more possibilities than your client will.

Occasionally, you will get clients who believe that they are experts. These are the people who will email you saying things like, "Why isn't the font/colour/image size exactly like it was in the Word document I sent you?!?" This is, to put it mildly, annoying. However, these people still want your expertise (presumably, since they are paying you).

You can deal with these types of clients by offering counter-evidence to back up your arguments. For example:

"I've moved the nav items to the left because usability research says that users are more likely to look at elements on the left side. There is evidence to support this (insert reference links). You can also see that this pattern is used on a lot of popular commercial sites (insert reference links)."

Most of the time, this type of attitude comes from worry. Just like your mum calling to check that you are eating well and dressing warm, your client just wants to be reassured that you are doing a good job. Show them that you know what you are doing, and they will usually back off.

Assumptions aren't facts

In the same way that your client is not an expert developer, most of the time they do not come prepared with all of the facts to hand. They started with an idea of the problem they wanted to solve. Then, they've made a few assumptions to get to a possible solution.

For example, let's go back to that client thought process I showed earlier:

  1. I want to increase my profits.
  2. I could sell more products if customers can find what they want more easily.
  3. Amazon has a good search facility and makes lots of money.
  4. I want to have a search facility like Amazon.

When we examine this, we can see that the client has made quite a few assumptions in reaching a solution:

  • My current search features are not sufficient to help customers.
  • My customers want to be able to find products easier.
  • Improving my search features will lead to more sales.
  • An Amazon-type search facility is the best design for my users.

The thing is, none of these are proven. They are simply ideas that the client has about how they might reach their end goal. Before we actually invest time and money on any of these, we'll want to do a bit more verification to check that these ideas are correct. This is why we do user research. In the same way that we wouldn't release code into a production environment without testing it first, we shouldn't commit to any of our ideas without testing them first.

Saying that you want to do research can sometimes scare clients, as it sounds expensive. Give them a concrete example of what you want to do to reassure them (you don't even need to use the word "research" at all). For example, "How about we grab a few of my co-workers to get some quick feedback on this idea?" There are plenty of ways to get user feedback cheaply, so I won't go over them here. By the time you get to the point where you may need to do more in-depth research, your client will understand better what they are getting for their money.

Seeing the big picture

So far I've gone over a few reasons why saying yes isn't a great idea for your client, but it can also hurt people in your team (including yourself). For each client, there is a cap on the amount of money they are willing to spend. Even when clients are willing to pay more, we still have other clients that need our attention. There is really only a limited number of hours that we can devote towards their project. As a fellow developer said to me recently: "I only have two hands. And I need to sleep."

By saying yes to everything the client asks for, we will most likely end up with far more than we can actually complete. This isn't fair to our teammates (they need to sleep too), and it isn't fair to the client - we've promised them something that we can't deliver on. This is where we need to work with the client to understand their priorities. Just like the song, when new requirements come in, some of the other requirements need to roll over and fall out.

Sometimes, the client will also ask us to do things which break our own standards. In this case, it's really important that we question why this is being asked for, and stand up for our own beliefs - especially if it crosses an ethical boundary. Being able to see the big picture like this is (in my opinion) what separates a good developer from a great one.

"NO" photograph by Dan Brady.

© 2019 by Marissa Warner-Wu. All rights reserved.

Proudly published with Ghost