Editor’s Note: Andy Clarke1 is known for his design work, books, conference presentations and contributions to the design community. Over the last 14 years, he has designed for amazing clients, written two books, and has given over 50 conference presentations and hosted workshops and training events for Web professionals all over the world.
Image by Geri Coady.
Do you remember those “10 Useful Legal Documents for Designers2?” Well, it turns out that you, designers who read Smashing Magazine, liked one in particular: a plain-language, straightforward “Contract of Works for Web Design3,” which is based heavily on Andy Clarke’s “Contract Killer84”. Since Mr. Wong published that template ten months ago, more than 1,600 designers have downloaded it on Docracy alone.
Why is this legal template so popular? Does it really work better than other contracts? Can it help you close that job faster and protect you from getting stiffed? Could it become an industry standard, like grid systems5 and agile development6? Could it help designers save money on legal fees? Who better than Mr. Andy Clarke himself to answer these questions!
Question: Hi, Andy. Your company is called Stuff and Nonsense7. That’s how many people would define contracts. Why do you think contracts are often unreadable and puzzling, and what brought you to write your own model from scratch?
Andy: Being at best obscure or at worst intentionally misleading is precisely how many people view contracts. That’s likely because the contracts we are so often asked to sign have been written in language that’s unfamiliar to most of us. You might think that contracts must be written this way, but they don’t. Contracts can be written in any style you like, in language that’s as formal or as informal as you are. Use your contract to set the tone for the relationship with your clients. Of course, you’ll need to cover all the issues, but there’s no reason you can’t do that while still being you.
I appreciate plain speaking, and I try to be as direct as possible in the way that I talk with my clients. Over the years that I’ve run Stuff and Nonsense, I’ve seen a lot of contracts, and none of them either had my “voice” or covered the specific aspects of Web design or development that are important to my work. I was frustrated with what I found, so I sat down one day to write my own contract, the “Contract Killer84,” and published it9 for anyone to use.
That was, amazingly, four years ago, and although some of the details of that original Contract Killer have changed, the fundamental principles have stayed the same. That’s because many of the issues that designers and developers and our clients face have also stayed the same. Still, in the latest version, Contract Killer 310, I’ve made some changes to reflect what many of us are doing now, particularly in relation to responsive and mobile design.
Andy: The original reaction to Contract Killer was astonishing, and over the last four years the feedback I’ve received from designers and developers has been overwhelmingly positive. I know of some people who say that the contract has helped them get work. Many use Contract Killer out of the box, while others include their own payment terms and copyright assignment. Some have added whole new clauses — for example, about termination. I feel very, very happy that so many people have found Contract Killer useful.
Reaction from my own clients has been overwhelmingly positive, too. No one has ever refused to sign it, and no one has asked for it to be replaced with another contract. In fact, the simple straightforward language has encouraged my clients to sign and return it faster than any other contract I’ve ever used. I guess that’s because being clear means there’s less need to check with a lawyer.
Question: You’ve been using this contracts for years now. Has it held up? Did you find some edge cases that exposed certain weaknesses? And, if so, how did you fix the problem?
Andy: I’ve used Contract Killer with every client for the last five years. Occasionally I’ve made changes to specific clauses — often around copyright assignment — when clients have requested that. But you know what? That’s OK. A contract is just another point for us to communicate — in this case, negotiate — with our clients. Changing a few words doesn’t matter much. How we handle changing those words matters a lot.
I’m now much more explicit about the fact that browser testing is about ensuring that a person’s experience of a design should be appropriate to the capabilities of the browser or device they’re using and that websites will not look the same in browsers of different capabilities or on devices with different-sized screens. I’m also particular about the desktop and mobile browsers I test on, although I know this will vary between designers and developers.
Question: Do you have any tips on how to use a contract as a communication tool? For example, how do you handle a client who requests an overly broad license?
Andy: Many clients, too many in fact, know little about what’s expected or involved in a successful Web project. They may have had a poor prior experience, so even if they don’t come right out and say it, they’re looking to you to show them how it’s done. Your contract is a great place to start showing them how you do business. Handle this stage well, and your project will run much more smoothly. Let’s look at an example from Contract Killer 3, the copyright ownership clause:
We’ll own the unique combination of these elements that constitutes a complete design and we’ll license that you, exclusively and in perpetuity for this project only, unless we agree otherwise. We can provide a separate estimate for that.
It’s a fair clause that’s designed to prevent a client from using and reusing the work for other projects without agreement. This means that if you design an e-commerce store for them, they can’t launch a second site using the same design. This is a sticking point for many people, who wrongly expect that they will own the rights to everything they pay you to produce for them for any purpose.
When this happens, explain the good reasons why the clause exists and, if it’s appropriate, offer them a new price that includes complete ownership and that reflects its potential value to them in the future. Don’t be afraid to stick up for what you’re asking, and always, always remember, this is your contract that you’re asking them them to sign. Make it work for you.
Question: In Contract Killer 3, you argue against fixed pricing, but you also promise flexibility. Can you explain how to negotiate a pricing scheme with a client who prefers fixed pricing or insists on a cap?
Andy: Fixed or project-based pricing has its roots firmly planted in the old-fashioned waterfall development process. But many people, including me, have moved to a more agile-based way of working. In an agile workflow, change is embraced, even encouraged. This means that fixed-price contracts quickly become irrelevant because if the requirements change, the price might change, too.
I organize my projects into week or two-week long sprints. Each sprint has a theme, a set of requirements that I’m going to finish during the period. It might be a sign-up process one week and a shopping cart the next. We’ll cover all the areas of a project across these sprints; and because the client knows the price in advance, he or she can budget. If a client has a great idea for something new or wants to change their mind, no problem. I roll up those requests into another sprint week, and the client can then make a business decision about spending money on those items.
Question: Have you ever faced a situation in which a client was asking for too many changes, one after another? How did you deal with that?
Andy: Several years ago I worked with an agency on a new site for a travel company. The agency had negotiated the price with its client, and I worked on a fixed price. Although the agency had drawn up the original brief and I followed that up with my own scoping meetings, things quickly went downhill as the client flip-flopped through ideas and change requests that were costly and complicated. I tolerated the situation as long as I could, but it became apparent I was making a loss on the project, and I withdrew.
This problem arose not because the client changed their minds — no, that shouldn’t ever be considered an issue; in fact, it should be encouraged — but because the agency and I were working to a fixed price. This left everybody with a bad taste in their mouth. Had we all worked in the agile way I just described, changes would never have been an issue, and it’s likely the project would have been a success, rather than a failure.
Question: What are the top three things a designer should keep in mind when preparing or reviewing a contract?
Andy: First, and possibly most importantly, you should ask your clients to sign a contract every time you work with them. It doesn’t matter whether they’re a first-timer or you’ve worked with them a dozen times: it’s vital that you agree on the scope and terms of the work. It took a while, and one or two unfortunate experiences, for me to learn that contracts are intended to set out what both parties should do.
Make the contract your own. It’s great that people like Contract Killer so much that they’ll use it out of the box, but your contract should be in your voice, not mine. Use the writing of a contract as an opportunity to put your personality into your paperwork. There’s no reason why a contract shouldn’t be funny and a joy to read. After all, you want someone to sign it.
Lastly, take the time to tailor a contract to a particular client and project, and make sure you’ve addressed everything you’re going to do for them. If you get a hint of any potential issue — for example, that they personally use an old browser or device — write about how you’ll handle that in your contract.
Question: Despite the saying, the client is not always right. How can you say that to them without being the a*shole?
Andy: No one, no matter who they are or what they think, is always right. (Well, except my wife. She’s always right about everything. Obviously.) One thing I’ve learned over the years is that clients love to feel involved in the design process. Sometimes, though, they make suggestions only so that they feel they have put their stamp on the project. There are simple ways that designers and developer can prevent this from happening. This is something I wrote about recently for Smashing Magazine15:
- Don’t email pictures of websites to your clients and then ask for their “thoughts.”
- Don’t wait until after weeks of work to have a “big reveal.”
- Set up the proper environment to receive structured feedback, and then ban all unstructured feedback you might receive by telephone or email.
Please remember: you are the designer. You are the person who has been hired to solve a problem that the client either can’t or doesn’t have the time to solve themselves. Your solution to that problem is worth a lot to their business, so never underestimate your role, skills and influence in the design process.
Question: I hear you are working on a “Killer NDA” (non-disclosure agreement). Sounds great.
Andy: Writing a Killer NDA has been on my mind for a while, as I’ve been asked to sign some horribly confusing examples over the years. I have no idea why NDAs have to be so complicated; after all, their intent is to make sure that everything that’s shared stays secret.
I’ve called this contract “Three Wise Monkeys” — see no evil, hear no evil, speak no evil. Three Wise Monkeys deals with just three things:
- What’s confidential?
- What can we say?
- How long does the agreement last?
Question: Last question: who are the “men with big dogs” referenced at the very end of your contracts?
Andy: I’m not afraid to say that on several occasions we’ve been forced to hire a debt collection agency to recover our money. On one occasion, we hired a debt collector from the client’s town, because we knew he would be ashamed if it became known locally that he was a bad payer. There’s no excuse for late or non-payment, and you should never be apologetic about wanting your money. Always remember, if you’ve done the work, you deserve to be paid. So, when all else fails, hire a professional. Preferably one with a big dog.
Have you used Contract Killer or a version of it? Share your experience in the comments!
- 1 https://www.smashingmagazine.com/author/andy-clarke/
- 2 https://www.smashingmagazine.com/2012/08/15/free-download-useful-legal-documents-for-designers-pdf/
- 3 https://www.docracy.com/3884/contract-of-works-for-web-design
- 4 http://stuffandnonsense.co.uk/projects/contract-killer/
- 5 https://www.smashingmagazine.com/tag/grids/
- 6 https://www.smashingmagazine.com/2012/11/06/design-spikes-fit-big-picture-ux-agile-development/
- 7 http://stuffandnonsense.co.uk/
- 8 http://stuffandnonsense.co.uk/projects/contract-killer/
- 9 http://24ways.org/2008/contract-killer
- 10 http://stuffandnonsense.co.uk/blog/about/contract-killer-3
- 11 http://www.flickr.com/photos/stevensnodgrass/5480662846
- 12 http://en.wikipedia.org/wiki/Offer_and_acceptance#Battle_of_the_forms
- 13 http://www.flickr.com/photos/stevensnodgrass/5480863464
- 14 http://stuffandnonsense.co.uk/
- 15 http://www.stuffandnonsense.co.uk/blog/about/encouraging-better-client-participation-in-responsive-design-projects
- 16 http://stuffandnonsense.co.uk/projects/three-wise-monkeys/
- 17 https://gist.github.com/malarkey
- 18 https://www.docracy.com/0j44xhcpbb7/three-wise-monkeys-nda-
- 19 http://stuffandnonsense.co.uk/projects/three-wise-monkeys/
- 20 http://www.flickr.com/photos/ektogamat/2687444500/
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 New York, on June 14–15, with smart design patterns and front-end techniques.