Most people won’t read the terms when signing up for a new service, because most terms are impenetrable and unfriendly to reading, both in design and content. But as a team, we care deeply about the related crafts of good writing and good typography and felt it was important for our terms to reflect those beliefs. So we set out to do the unthinkable: draft a terms of service that we could be proud of, one that would adhere to our high standards for writing in general, while still meeting our important legal obligations.
We think the results speak for themselves (and we’re delighted that others noticed as well). In the process of working on them, we learned a lot — about why terms typically read the way they do, the best ways to adapt and revise them, and which so-called legal requirements are not actually written in stone. Just as importantly, we learned that a little effort here goes a long way: it wasn’t difficult to produce a readable, meaningful contract between us and our users. It took a small amount of time and attention, but we believe that time will be more than offset by the reduced likelihood of misunderstanding, and the chance to build a better relationship with our users.
We’d like to share what we learned, in the hopes that other services may benefit from it too. In fact, since nearly every service kicks off the process of drafting terms by starting with some boilerplate, we’re offering our terms up as a better starting point. As of today, we’ve released our terms under a Creative Commons Attribution-ShareAlike license, so you can use and adapt them as you see fit.
Note that we mean these as a starting point: your service is unique, and your terms need to reflect that. As you adapt these to your own purposes, we offer up the advice that follows. (Note, also, that we are not lawyers, and this post does not constitute legal advice. The very first step in drafting a terms of service is hiring a good lawyer to work on them with you. We’re grateful to our counsel, Gabe Levine, for putting up with our incessant questions as we iterated on our terms.)
Keep it readable
This is the first, most difficult, and most important goal when drafting terms. There is no legal reason for your terms to be opaque or confusing. Approach the writing process the same way you would any other communication with your users: use plain language, and speak like a human. Keep your sentences short and simple. Make generous use of numbered and bulleted lists where possible.
Don’t assume that commonly-used legalese is required; much oft-repeated language is the result of laziness, not a legal mandate. If your lawyer suggests language that’s thick or confusing, ask for clarification about why it’s needed, or what it intends to communicate. Then translate that into language you’d be comfortable using if you were sitting across a table from a colleague or friend.
Reflect the present, not the future
The tedium and legal cost of working on a terms of service can inspire you to include language that covers not only your current feature set, but future releases as well, thus prolonging the document’s lifespan. But don’t be tempted down that path. Your users should not have to agree to terms in the absence of understanding how they relate to the service you provide. At the same time, that feature you’re working on may yet change before you ship it — so the terms you’re planning today are likely to need review and revision in the future anyway.
Rather than trying to “set it and forget it,” assume your terms are an ongoing work in progress, and consider updates and revisions to be part of the process of releasing new features. As an added bonus, communicating updates to your terms in the context of the features they make possible will help your users better understand your goals and obligations to them.
Don’t overreach
It’s tempting to define your company’s rights expansively, so you can experiment and iterate without worrying about whether or not the terms limit your imagination. But the flip side of that convenience is that overreaching has the potential to alienate and offend your users. For example, if your terms cover the ability to resell your users’ content, but you don’t yet have any mechanism to do that, your users are likely to presume your purposes are nefarious. Be especially careful of overly permissive licenses or copyright claims over your users’ content, as these are likely to be met with disapproval (and you probably don’t need them anyway). Claim only the rights which your service needs to operate, and no more.
Provide examples
Abstract legal language, even when translated into more accessible terminology, can be hard to relate to. Provide clear and relevant examples to make those concepts easier to parse.
For example, the Editorially terms include a privacy policy outlining how we may share our users’ personal information. An early draft included the phrase, “we will not share your information with any third parties, except as necessary to provide the services offered.” But that “except” clause, on its own, sounded worrisome; why would it be necessary to share personal information to provide the services? In a revised draft, we added an example to clarify:
We will store your personal information, but will not share it with any third parties, except as necessary to provide the services offered. For example, we may store your personal information along with your files and data on a third party server such as Amazon Web Services.
Examples can clarify otherwise vague promises, and make it easier for your users to understand your intentions.
Don’t annotate bad language
Many terms attempt to annotate otherwise opaque language to make it easier to understand. But such annotations, however well-meaning, only serve to complicate an already complex document. Now, instead of one text, your users have to comprehend both the legal document and the explanatory annotations layered on top of it. If a user’s reading of the original text doesn’t jibe with the annotation, or if either leaves room for confusion, you’re left with a situation significantly more complex than any single document could suggest.
If it’s possible to translate opaque legal language into human readable language, then use the latter as the text of your document rather than simply window-dressing the original language.
Don’t get cute
There are lots of opportunities for fun and clever language in your service; the terms are not one of them. These are serious, legal documents which have consequences for both you and your users. Save the cute for elsewhere.
Refrain from yelling
If you’ve read any terms, you’ve probably noticed the large sections of ALL CAPS language, usually somewhere near the end. The purpose of this offensive typesetting is ostensibly to call the reader’s attention to provisions that have important legal implications. In reality, however, DENSE ALL CAPS IS MORE LIKELY TO DISCOURAGE READING THAN TO INSPIRE IT. We elected to highlight these sections with a yellow background, drawing attention to them without reducing readability.
Draft, get feedback, iterate, repeat
Your terms are an extension of your product, and they can be subjected to the same process for user-centered design as everything else you’re building. Draft, get feedback, iterate, and repeat. Bake in the time to solicit and act on that feedback, and your terms will improve in concert with your product.
Remember, also, that your terms are a reflection of your values: if you care about your users and take seriously your responsibilities to them, it will show. Likewise, if your terms are readable and reasonable, your users will better understand your intentions. It’s been said that a good contract is the basis for trust. We couldn’t agree more.
