On his site, The Oatmeal, designer Matthew Inman has created a comic strip /*slash*/ poster entitled, How A Web Design Goes Straight To Hell. In this hilarious and all-too-true scenario, the client continues to make more and more horrific changes to the design. Under each subsequent “suggestion,” Inman has inserted footnotes to the effect of “I actually had a client make this request …”
Prospects are from heaven. It’s the promise of a new project, a new relationship, and some new money in your bank account. It’s the hope and expectation of how we can make all our client’s web marketing dreams come true. Prospects and leads are the lifeblood of the freelancer. As someone once told me: I eat what I kill.
If prospects are the honeymoon, then clients are the marriage. And wherever fallible human beings are involved, assumptions and misunderstandings are sure to follow. So how do you prevent the relationship, much less the design, from going “straight to hell”? Here are two potential stumbling blocks you’ll encounter with even the best of clients, and how to be prepared for them when you do.
The Content Will Arrive Late … if at All
This quote from Kelly Goto of Goto Media says it all:
The myth is that the content will arrive on time. The mystery is that no matter how organized both you and the client are, the content will inevitably arrive late.
The content will arrive late, so how do you deal with it? As I explained in my first-ever SitePoint article, Bulletproof Web Design Contracts, if you’ve made the mistake of attaching payments to production milestones, then you’ve got a problem.
Project milestones are things like: start of the project; the design phase; HTML markup phase; copy writing phase; back-end coding phase; and of course, project completion.
So here’s the scenario: The client has agreed to pay 25 percent up-front and the remainder upon completion. He immediately sends you photos, so you mockup and code the site, create all the pages and links, but … he delays for seven months before sending any copy.
Not that I’ve ever done this … but suppose you were even more foolish, and agreed that the client didn’t have to pay a dime until the site was finished? So seven months later, the site is 95 percent complete, and I’m still waiting … that is, you’re still waiting for this guy to give me …err, you … a few text files so you can complete the site and get paid.
Okay, I was that young and dumb once, but I eventually hit on a better way:
Never attach payments to production milestones. Oh, did I already say that? Instead, require payment within a certain number of days. Here’s what I did.
After a several sites under my belt, I figured out that, even with client delays, I completed most projects within 60 to 90 days. So, using 90 days as the benchmark, I set up payments like so:
25 percent up front
25 percent 45 days later
Remainer at 90 days—regardless of whether the site was finished or not.
Now, if it was my fault the site wasn’t finished, I had the option (and the obligation, I might add) to complete it before demanding final payment. Yet, if the client was the reason for the delay, I still got paid.
The Client Will Want to Make Changes to Your Masterpiece
Coming from a graphic/print design background, one of the things I struggled with early in my web career were client changes to my design. It took a few projects for it to dawn on me that the site I was designing was a business tool—not a work of art.
It’s a given that clients will want to make changes to your initial design. And just like with your payment schedule, your contract should state exactly how many he’ll get. Regardless of how many or little you’ll allow, sometimes dealing with any type of client change can be the most difficult thing of all, especially if the “change” comes in the form of criticism.
Clients will have opinions. Some will make sense. Many will not. One client told me that they didn’t like all the “empty spaces” on the site I was designing. Once I figured out what they meant and explained the concept of white space, they deferred to my expertise. It’s your responsibility as designer/developer to advise the client. Most will allow you to be the expert. Some will not.
Maybe you’re fine with what the client had to say about your design, but you don’t like how he said it. Perhaps he was less than kind. Maybe he was even a little mean.
Assuming you don’t have the luxury of firing clients, how will you deal with this?
Don’t misunderstand. I’m not talking about abusive clients who demand the world, yet take their time paying you for it. These clients deserved to be fired. I’m referring to the 70 percent sandwiched between your upper-end “cream of the crop” clients and the low-end cheapskates. It’s the overworked, small business owner who has so much on his plate that he forgot to be as “nice” as you think he should have. When this happens, do you take all your marbles and go home?
Here’s some simple, yet difficult advice. Don’t take offense. Remember, it’s not personal; it’s just business. Your client is making decisions he thinks are best for his business—however illogical they may actually be. Once you’re offended, everything you say to the client about why you disagree with him will drip with defensiveness. The interesting thing about that phrase is the word “take.” This tells me that I have a choice. I can take it, or I can refuse to pick it up. Not taking offense goes a long way towards turning the client around to your point of view. After all, isn’t that what you want?
So there you have it, the two biggest client challenges you’ll face in your web development career—at least in my opinion. What do you think? Are those your top picks? Post your experiences in the comments below.
Animating with CSS
Researching UX: Analytics
Rails: Novice to Ninja
Designing UX: Forms
- 1 4 Virtual Reality Startup Ideas Entrepreneurs Can Jump On Now
- 2 Developing Add-ons for Enterprise Apps like JIRA
- 3 Oh, the Lengths We'll Go: Extreme Stories on Getting the Job Done
- 4 Freelancer Mistakes: 5 Things You're Saying to Make Your Client Hate You
- 5 3 Ways to Work More Effectively in a Web Development Team