Overview
This section outlines how we style content within key elements and surfaces. For component-level guidelines, see individual component pages.
Keep emails short, ideally less than 150 words. To emphasize a point, use a single sentence paragraph. Otherwise, each paragraph should cover one topic in no more than four lines (about 50 words). Lean on subheaders and bulleted lists to structure complex or lengthy information.
1
Subject lines (SL)
Keep subject lines under 10 words or 40 characters and don’t punctuate them. They should communicate the most important information, like a deadline or required action.
2
Pre-headers (PH)
This is the sentence that appears next to or near the subject line in an email inbox. It’s often clipped, so keep it under 10 words or 40 characters as well. Write it as a complete sentence with punctuation that reinforces the subject line, continues the conversation, or entices action.
3
Headers
Not all emails need headers, but they can be a helpful way to highlight and frontload the main message. Headers often repeat or expand upon the subject line. Ideally, headers are contained to one line.
4
Body
Keep body copy concise and use formatting, like subheaders or bulleted lists, to improve readability. Paragraphs should cover one topic and not exceed three lines.
5
Calls to action (CTAs)
Always include at least one call to action, even if it’s just to go to the app. To test for readability, ask if the main message of the email can be understood by reading the subject line, header, and CTA alone.
6
Footers
Optionally, you can add a secondary CTA, like linking to the Help Center, in the footer. Always include the standard footer with our business address, a link to unsubscribe, and links to download the app.
Push and SMS notifications are an effective way to communicate time-sensitive, actionable messages — especially to pros who are on the job. Assume you’re writing for a smaller phone screen with a standard font display setting and keep content under 90 characters.
To avoid inundating users with communications, waterfall the push and SMS instead of sending both. In other words, send a push notification first and, if the user has push notifications turned off, send an SMS.
1
Headers
Fit headers to one line and use them to communicate the main message. Emojis that are associated with specific features (like the lightning bolt for Instant Book) can help communicate context in fewer characters, but don’t rely on them alone.
2
Body
Body copy should be no more than three lines. Make sure that it indicates where the user will navigate if they click through the notification.
Buttons and links should always be sentence case, unless they contain a proper noun. Buttons should be 4 words or less and links should be 8 words or less.
When writing copy for buttons and links, remember these 4 guidelines from Nielsen Norman Group:
Use buttons for primary actions and links for navigation. Unless you’re following a common button pattern, like “Done” or “Continue,” buttons and links should follow the [action verb] + [noun] pattern.
Remember, image-only buttons and links need alt-text.
Do | Don't |
---|---|
See policy details | Learn more |
Start free trial | Try it now! |
Set reminder | Set a reminder |
When writing error messages, explain what went wrong and how to fix it. Avoid generic language and focus on getting the user back on track (rather than explaining what happened).
Encountering an error isn’t fun no matter the severity, so approach tone with this in mind. Don’t make jokes to try to put the user at ease and use passive voice when helpful to avoid sounding accusatory. When it’s our fault, take responsibility and emphasize how we’re making it right.
Keep headers to one line and no more than 10 words. Generally, headers communicate what went wrong. If a user only reads the header and CTA, they should have all the information needed to resolve the error.
Use complete sentences and keep body copy to two lines total. This space is generally used to provide additional context on the reason for the error — avoid technical jargon (e.g. “Error 404”) and focus only on the information that helps the user resolve it.
Keep CTAs to four words or less and don’t punctuate them. If the user can resolve the error on their own, direct them to do so in the CTA (even if it’s just trying again or refreshing the page).
Do | Don't |
---|---|
We weren’t able to process your payment. | The payment failed. |
We’re working to improve. | We’re sorry. |
That doesn’t look like the right password. | You entered the wrong password |