Disarming Problem Clients

As designers, we go through quite a hazing when setting out on client work. At first, it seems exciting, all the ideas exploding in your brain, all the possible things you could do, all those opportunities. And then reality strikes, you present your ideas to the clients and they don’t like them, furthermore as the process goes on the clients opinion and yours move further apart, sometimes the relationship even breaks down entirely, by the end you wonder why you should even bother at all. Some time passes and once the dust has settled, you convince yourself the customer was in the wrong all along and move on to the next project.

Sound familiar? This is a pattern some designers never seem to break out of. Others repeat this process every so often, but not many manage to avoid it all together. The reality of the situation is some clients are problematic, but most aren’t. They’re great people who want the best for their product or service.

Some of these problems stem from the creative process, it’s hard to grasp by those who are not creative, they struggle to understand it. This is compounded further by the fact the thing you are designing is also a virtual object (sites are the worst for this).

Human beings have evolved over centuries to understand a thing by how it feels, how much it weighs and how often they have seen it. These factors help an individual subconsciously weigh up a thing and determine its worth to them. If you built them a physical object made of carbon fibre that was really tall, they could understand where the money was spent in achieving the task because they could see the physical size of the object and all the rare materials used in its construction. Defining something virtual is much harder, much of the work is hidden away, that’s part of the reason why designers show wire-frames and mock-ups and anything else during the creative process to try to help anchor the ideas and creative thought in “worth”.

While I believe we need to touch on points with the client on showing them the design process, they often don’t really understand wire-frames and can’t picture in their head (as you can) the vision of what is unfolding. That’s why for years mock-ups have been the touch point between clients and designers, the closest thing the designer could use to demonstrate the idea, without delivering the project. Obviously mock-ups don’t tell a larger part of an interactive piece leading to much more work down the line on the implementation and that’s why we now use many other tools like wire-framing and interactive prototypes to try to poly-fill these gaps and reassure the client:

It’s going to be all right I haven’t spent your money with nothing to show for it at the end.

My issue with these processes is that they are tools for us, not the client. More often than not they help us refine our idea but to a non-creative they can be just as mind boggling as showing them a static mock-up. All these things we do to help ourselves aren’t really helping the client understand the process, they are more about us spending their money wisely (which is a good thing) but they don’t solve the problem of understanding.

This is why clients get nervous, their grasp on the understanding of what is happening unsettles them, they remember how much money they have paid for this process (which is probably a lot to them) and they panic. At this point they begin making suggestions in order to try to bring some control back to them, they feel once they are in control that they will get what they want, of course once they wrestle this control back it inevitably spins further out of control, a monstrosity is born and communications break down, mission failed.

This is not what we wanted to happen, but it happens too often.

Speaking to clients is a skill, some designers are good at this, some are not. But under either circumstance you need to understand how to:

Handle issues when they arise.

Remain in control of the creative process and still let the client feel in control of the project.

Remedy the situation where both yourself and the client disagree on how to solve a problem.

Let’s look at how to solve these issues:

Handle Issues When They Arise

When an issue happens, and at some point it will, I give it a priority, I stick with low or high (keep it simple). If it’s a low priority issue unless it’s going to hold anything up I schedule it for the next call/meeting with the client. It’s important not to worry the client unnecessarily it will shake their confidence that you can deliver.

If it’s a high priority issue, you next need to assess the urgency, can you sit on it for 10 minutes? It’s amazing how many issues that are urgent get escalated to a client, and then disappear moments later because a mistake was made or something mis-understood. Check through the issue again before contacting the client, and make sure before speaking to them to boil it down to a concise problem with options for answers and a recommended approach, don’t call them if you are panicked or agitated, calm yourself down and show your are in control but the client has the power to make the final decision.

For example:

We have noticed that on mobile the contact form for the clients site doesn’t fit.

Break the problem down in to the options available and do your best to remove as much tech speak as is necessary unless the client is really comfortable with it, like so.

We can either:

Re-design the form to fit. This will impact the delivery by 1 day, and incur a small fee.

Remove the form completely on mobile, and replace it with a clickable email link. This will remove the problem entirely and not influence the delivery date, but will mean you receive free form emails that don’t fit the required fields on the site.

Next consider each option and make a recommendation for the approach, be brief and justify your reasoning, Keep it logical, you have arrived at this recommendation because in your professional opinion you have weighed up the options and made a decision, which is partly what the client is paying you for:

We would recommend re-designing the form and give the users the same experience off-line and on-line, reducing confusion for your workforce over mixed email types. If costs are a problem at this time, we could remove the form at launch and use one of your support days to implement it after release.

Notice at the end of the response I also gave the client a way to have their cake and eat it. This is the approach I actually expect them to take, but it is also sub-consciously doing something else. It’s getting the client use to change, encouraging them to think it’s OK to make a change to a live site. It sends the message that change can and will happen on the new site and that’s OK.

Not only does this now show you are in control of the project but it keeps the client feeling that they are are also in control and that they are affecting change and contributing, they are less likely later to try and interject something to assert control because you are presenting facts and options and doing your best to extract the tech speak.

Project Control

This is the hardest thing to change in your process, because it’s changing your own behaviour, something you must work hard at to change. It is about your personal way you conduct business.

You have to remember at all times that you being paid by the client to achieve a given task. If you have a high horse, get off it you can have an opinion but don’t get opinionated. Pick and choose battles to win, you will rarely (if ever) get everything your way, and that’s OK. You want to build a working relationship with this client, so if they make a decision you disagree with or force you down a path you aren’t comfortable with, unless it’s a moral or legal issue you should view it as a point to update later. Try to think, all they are doing is exploring in their mental process the option they would like to pursue. You may be further down this process than them. In the end they are creating more work for you to do further down the line, so try not to get too hung up if it happens, your still winning too. Of course there is always the possibility that they are right and you are wrong, so don’t be closed to that outcome either!

Solving Disagreements In A Way That Everybody Wins

My observations over the years on dispute is that first issues take the form of differences of opinion, this is OK, people view things differently and often there is more than one way to tackle a problem. The difference of opinion sometimes then escalate and can causes conflict because unless one party quickly cedes to the other on the approach that will be taken, both parties argue their way is superior and an impasse is reached.

Eventually one side shouts louder than the other and a direction is taken, with one party losing out. Hardly ideal, the nature of human interaction then dictates that the party hard done by are now going to try and “win” in other areas so they don’t feel taken advantage of, this imbalance that occurs is what erodes a perfectly healthy relationship until the trust is gone. The trick is to remove the personal opinions from the whole dispute and everybody feels they won.

Let’s say a client disagrees with the button layout you have chosen for a form on the site. They come to you with their concern and want the button moved to another placement. You disagree with their reasoning.

At this point, if you have a good logical or creative process with reasoning for your decision write down the process and read through it a couple of times, so long as you are happy you made the right decision and still disagree with the proposed direction. Pick up the phone and politely talk the client through why you made this decision. Sometimes they will be happy once its been explained and drop the issue, but sometimes they will insist on still changing it. At this point you have 2 choices, or you risk conflict and losing the clients trust.

Do what the client asks - You can’t win every difference of opinion, and unless you feel it may fundamentally de-rail or undermine something major, agree with the client on their approach and make a note as something to review later as you may need to implement your original solution later down the line.

Set up a test. Tell the client it’s interesting you both have a different way to solve the problem and why don’t we set up an A/B test to trial both solutions over a fixed time period. After that period you will implement the one that gets the largest amount of users using it.

Setting up an A/B test is really great in this situation because you remove all personal opinion from the matter and it’s instantly resolved by science. These issues often mean a lot at the time but later on you can feel that (for example) perhaps you argued to heavily over using “that” shade of red when it didn’t matter to much.

Run the test over a sensible period 1-2 months should suffice and report back to the client on the results. Later on when reviewing the A/B tests you’ll find your more interested in the results and making the site/App etc better than who’s opinion was right, which had seemed so important at the time.

Defusing problems like this as soon as possible keeps the project on schedule and everyone happy, not only that, but A/B testing to solve disagreements can yield far better results for the client’s project and help to build your relationship with the client.