11 June 2019
Since starting YupGup nearly two years ago I’ve had a bit of a crash course in contract writing and negotiations. This experience has allowed me to see that any freelance contract I maintained prior to this was not especially thoughtful or airtight—oops.
While I’m certainly no expert in these I have learned a lot through trial and error, making these a not so dreadful task any longer. In fact, I mostly get endlessly excited about them now since it’s the kickoff point to a new project with new and fun people.
There are many fine and large print items that have become standard and expected within these types of client contracts, such as: pricing, liability terms, and project termination and warranty language. In addition to these I’ve also discovered six other important bits of info to add that make project management and communication much easier and the agreement overall less risky.
Let’s take a quick look.
Since this is the document where the potential client is making their final decision, I use it as an opportunity to reiterate that I understand their needs and goals. After a title page I jump into a brief overview of the project. My understanding of the work needed is based on this stated objective and can be reassuring to potential clients that are feeling uncertain over the process itself or teaming up with a design agency in general.
So I demonstrate that I understand their issues and then outline the steps necessary to carry out the project successfully in the next section.
At this point in the “onboarding” process the prospective client has been given a proposal for review, which I wrote more about recently here. Since the contract is the actual signed document, however, I carry over this outlined scope of work and add additional nitty-gritty details.
This section gets broken up by high-level work required, and then by more detailed tasks and specifications. For YupGup this generally includes brand direction, print design, and front-end development. Each of these includes a list of project deliverables, specific file formats that are guaranteed, and number of concepts and iterations that are included; details that are not significant at the proposal stage but should be spelled out and agreed to before work begins.
Though this had never technically been an issue for me, sharing project assets for promotional purposes felt a bit odd with spoken approval only, gained after the project’s completion.
Before the project even begins I want the client to know that I will at some point use imagery and non-sensitive information from the project within my portfolio and for promotional materials to communicate the agency’s work and capabilities. They then have the opportunity to agree to this upfront or request that this not be done and I know right away whether or not I can count on sharing this later.
Previous work samples play a huge role in securing future contracts and I don’t want anyone to feel surprised by how this will be shared and for what purpose.
Nearly as important as the full scope of what’s included is to specifically mention what is not included. Assumptions can rightfully or wrongfully be made in regards to certain deliverables and as the person drafting the contract you have the power to eliminate any mystery, protecting the time and budgets of everyone involved.
What to include here will largely depend on what type of work you do and what you experience coming up consistently. For example, since I do a fair amount of print design it has to be stated that I prepare these files for print but do not actually manage the printing or shipping process unless this is explicitly agreed to in the defined scope of the project.
Developing sites? What browsers and devices will you not test against? Will you be hosting? What about server configuration? Mention these types of things specifically now to spare everyone confusion and distress later.
My contracts always state that feedback is needed from the client within three business days for the proposed timeline to remain valid.
Also be sure to mention that the timeline is based on a specific “no later than” start date, since a later than anticipated start date will throw off the entire timeline of this project and likely others.
Last but definitely not least, be sure to include a date to which the terms outlined are valid. If you are ghosted after sending this contract along for review you certainly cannot be expected to stick to these same terms, timeline, and pricing a year out if the potential client were to circle back at that time.
This can help avoid awkward conversations later and places an appropriate level of urgency in making a decision on the contract at the time of sending.
It’s impossible to account for every weird scenario when managing design and development projects. The best we can do is learn from our own mistakes and the mistakes of others when they are kind enough to share their insight. From there we can add and iterate on this supplemental-type of contract language that aims to proactively avoid not so obvious pitfalls. If you’ve also learned to add additional items to your contracts like these that have proved to foster a smoother project and healthier client relationship I’d love to hear about it on Twitter.
