Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

The Lost Files – Plagues in Web Design Business & How To Deal With Them (part 8 of 9)

← Plagues in Web Design Business (7/9)41TOC5263

Plague of the Approaching Finish Line

Eventually, the project will be done. The client will be excited and nervous and will eagerly await for the website to go live. The pressure is on. What bugs will you find at the last minute? What still isn’t working? The content that the client gave you was proofread, so why are typos popping up? Inevitably, the client will mention a couple of concerns that they didn’t want to raise early on.

Pre-launch testing has gone smoothly, and let’s say, just for fun, that the client has given the go-ahead, and the deadline to go live approaches. This is when most problems occur. All parties will be nervous and filled with anxiety. The client wants a great website, and you want it to be perfect and attract the attention and accolades of your peers and prospective clients.

Despite all the excitement, this is when you have to check, double-check and then recheck again. As hard as it is to admit, having lived with a project for so long, we overlook little things because we’ve gotten so used to them and consider them as set. But things will be wrong. Never skimp on proofreading; that is the number one area for mistakes. The next is dead links and browser incompatibility.

The project manager won’t sleep for a few days. Although this may sound like design-by-committee, it’s not: have everyone possible check for typos, links, browser issues and general usability and functionality. They can point out problems but not request more advanced changes.

And then it’s time. Launch away. I recommend going live after working hours on the day before the launch date. Get everything set, and have a point person at the client’s office first thing in the morning. Make an event out of the launch. Take pictures and order a cake in the shape of something related to the client’s business (unless it’s a plumbing or sewage company).

This is when you can boast your feats and gauge the reaction of the client. The client’s reaction will tell you whether the project is a success and, more importantly, whether you have a regular client. If you’re on staff, you’ll know whether you will have a job on Monday.

Pharaoh Changes His Mind

Before moving on to the scenario in which the client is in love with the results, let’s address the possibility that the client is not pleased.

The first step is to ask the client what they perceive to be the problem. Is it tangible or emotional? (The latter is just as serious, because unhappiness turns into resentment and then anger. Having an angry client is not good.) And what do you need to do to make them happy?

The problem will often be emotional. Buyer’s remorse is a dangerous problem on expensive projects. The client might feel cheated. Meanwhile, you just want to be paid. I will deny ever writing this, but when a client has an emotional problem with the project—usually because they feel they weren’t involved enough or because that “creative” friend of theirs critiqued the website and said that they overpaid (remember how we shot down their idea earlier on?)—you just want to slap them like General Patton used to slap his soldiers. Naturally, you can’t, but you will need to do damage control, and quickly.

Statistics are always a good indicator of success. You should have been tracking them from the minute the website went live. Show the client how well things are going compared to similar websites. Then crush that creative friend’s assessment so that it never comes into play again.

Problems can usually be easily talked through, and sometimes you just have to throw in some extra effort—basically, free work—after the fact. It’s a small price to pay to get a happy client and to strengthen the working relationship, especially when the price of failure includes losing even more money.

If you arrive at a stalemate and there is just nothing you can do to keep the client happy, don’t take it too hard. It’s never personal; the client is usually just trying to get out of paying for the work rendered. The last time that happened to me, I kept a positive demeanor; the client grumbled after the project was completed; I apologized and said there would be no charge… and no project. It wasn’t time-sensitive, so the client could have gone with another designer. They didn’t, and I got paid.


Unfortunately, some clients want you to work but don’t want to pay. This is why a contract is essential. Among the clauses that frighten clients, include one that places all of the costs for collection on the client. When you have to turn the account over to a collection agency, the updated invoice should reflect collection and interest and penalty costs. Just make sure to inform the client in writing and give them 10 business days to render payment before turning the account over for collection. You have my sympathy if you meet this ending. But smile: we are still paid to be creative more often than not.

← Plagues in Web Design Business (7/9)41TOC5263


  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Trainee @ Smashing Magazine

  1. 00

    No comments have been posted yet. Please feel free to comment first!
    Note: Make sure your comment is related to the topic of the article above. Let's start a personal and meaningful conversation!

Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top