Guidelines for the best words, with the right voice and tone, to help users efficiently complete their tasks.

Writing is design.

UI copy reinforces our brand. Our voice, tone, and visual components work together to create a unified design and experience.

Be succinct.

Write short, active copy that’s easily scannable so users can get to what they want quickly and easily.

Be unambiguous.

Use clear, direct language. Users should know with certainty what an action will do.

Less is more.

Sometimes the best copy choice is no copy.

Write for flows.

Where has the user just come from? Where will they go? Write for a specific action and situate that action within the larger context of the user's task.

Consistency is good. Clarity is better.

Use the same words for the same actions. Sometimes, strict adherence to rules can lead to confusing or inconsistent copy. If 'Place Order' is industry-standard, don’t change it to 'Submit Order' just to be consistent — always prioritize clarity.

Spell out an acronym the first time it’s mentioned. On subsequent references, use the abbreviation. If the abbreviation isn’t clearly related to the full version, specify in parentheses.

If the abbreviation or acronym is well-known to the average client (for example, APR or ROI), use it on first reference without spelling it out.

Write button text in title case when the text is five words or fewer. For text longer than five words, use sentence case.

  • Add Group
  • New Transfer or Payment
  • Include assets and holdings from external accounts

The desired action goes on the righthand button.

  • Add Account
  • Add New Instruction

Avoid buttons that simply say "Yes" or "No," which are generic and provide no context. Use clear, predictable language, so that users can reasonably know what will happen when they click. Email Technical Support, for example, brings up a composition window. EXCEPTION: Cancel confirmation messages. See that topic for more.

  • Get Information
  • Questions?

It’s OK to use an ampersand in button copy.

Use accept only when legal terms of service are required before a user can proceed. Use OK for a read-only page that the user isn't legally required to accept.

OK is all caps, always.

Use cancel to back out of a page where information has been entered or where legal confirmation is required. Use close for read-only messages or screens. Don't use dismiss.

Use select when the user is picking from a limited number of options presented.

Use choose when the user is making an open-ended decision or picking from a large number of options.

Use edit, not manage.

Use create when users are making something new or bringing separate elements together to form something new:

  • Create an Account
  • Select accounts to create a group

Use add when the user is bringing in information that already exists elsewhere:

  • Add Address
  • Add Phone Number

Use submit for a form.

Use send only for email.

See is the verb. View is the noun.

  • See more
  • Custom view

Exception: Don't use "see" by itself. In that case, use "view"

Ask, not inquire.

  • Ask about securities-based loans

In general, don't go overboard with capitalization. When overused, it makes copy harder to read and sounds stiff, like every word is shouting at you. Terms that truly need to be capitalized, such as the name of our company, stand out more when they're not lost in a sea of unnecessarily capitalized terms.

  • Top-level navigation
  • Section Headers
  • Column Headers
  • Menu Titles
  • Menu Items
  • Department names when they're referred to as departments but not when used in a general sense.
  • Buttons (five words or fewer)
Title case example
  • In-line and stand alone links
  • Checkboxes, radios, badges, sliders, toggles, tooltips, tags, pills, toasts, loading indicators
  • Ghost text inside fields
  • Buttons (more than five words)
Sentence case example

Example of title case vs sentence case in buttons

Example of title case vs sentence case in buttons

Generally avoid contractions, but let your ear be your guide. If writing out the contraction sounds stiff or mechanical, opt for more conversational language, especially when directly communicating with a client.

  • You have chosen to show closed accounts.
  • Third-party transfers are not allowed.
  • Your work is saved, but you won't be able to continue until the issue is resolved.
  • I'm looking forward to our meeting.

Dates automatically resolve to customary formats (i.e., day first, month first, year first) according to a user's location. These are guidelines for American English sites.

  • Use this format: DD Mmm, YYYY
  • Use three-letter abbreviations for months. Capitalize only the first letter. Don't use a period.
  • Don't put a "0" in front of single-digit dates.
  • 12 Dec, 2019
  • 3 Jul, 1928

Use this format (seconds/time zones may not always be necessary): 3:52:17 AM PST

Formatting can be localized where needed and typically follows the formats below





+1 212-123-4567

+44 20-1234-5678

+65 1234-5678

Dialogs ask users to take an action–to acknowledge, dismiss, confirm, or allow something. These are pop-up modals that interrupt workflows, so use them only when the inconvenience is warranted.

Dialogs are made up of a title, supporting text, and buttons:

  • Use a succinct statement or question.
  • Don't apologize or use alarming language ("Warning!").
  • Don't say "Are you sure?"
  • A brief sentence or two explaining what action is required and what consequences, if any, may result.
  • Give users enough information to make the best decision.
  • In simple dialogs, no supporting text may be needed.
  • Usually these will be side-by-side buttons, with the desired or consequential action on the right.
  • The left button usually is Cancel, returning users to their flow.
  • Don't use "Yes" or "No" on buttons, even when the title is a question. Instead, specify the action: Accept, Sign Out, Delete.
  • If the purpose of the dialog is to have the user acknowledge something, there can be just one button that says "OK".

When clients cancel out of a process, the dialogs asking them to confirm are handled a little bit differently. Follow this template:

Cancel Dialog
  • This is an exception to our general rule against Yes and No buttons. Without Yes, the Cancel button would be confusing: Does it confirm the cancellation or cancel the cancellation? Adding Yes removes confusion.
  • Use Back, not "Cancel," to return users to their flows.

These appear briefly after a user completes an action. Copy should mention the item involved in the action but not details about what the user changed, created, or added. Err on the side of the generic.

  • Email changed
  • Email changed to
  • Custom account created
  • Custom account All Family Accounts 2020 created")

Write toasts in sentence case. No periods at the end unless there are two or more sentences (which there usually shouldn't be).

Whatever form an error message or alert may take — modal, toast, banner, etc. — follow these guidelines.

  • Describe the problem in simple, straightforward language
  • List steps, if any, the user can take to correct the problem
  • Always use OK, all caps.
  • Apologize
  • Blame the user ("You entered an invalid character")
  • Use technical language
  • Use alarming language such as "fatal" or "catastrophic"
  • Say "oops". Seriously, don't.
Good example of an error message
Bad example of an error message

Be careful not to overuse this word. We don't need to ask the user to please perform common online actions, such as entering passwords or clicking a button.

When overused, "please" loses its meaning, taking up valuable UI space where useful copy could go. The greatest courtesy we can grant our users is concise language that lets them complete their tasks efficiently.

Enter your password is perfectly fine, but if you want to soften it a bit, express the value the user gets from a particular action: Enter your password to continue

Of course, we never want to sound abrupt. We aren't monsters! It's OK to use please in these situations:

  • If only two words would remain after removing "please," leave it in: Please try again.

  • In the case of a connection failure or outage, which leaves the user unable to do anything: Data currently unavailable. Please refresh the page or try again later.

  • In client emails when a polite touch is needed.

Unless the text is a question or contains more than one sentence, don't use punctuation in:

  • Labels
  • Tooltips
  • Hover text
  • Bulleted lists
  • Ghost/hint text
  • Badges
  • Radios
  • Loading indicators

In general, don't use an ampersand in place of "and" except:

  • In common, accepted terms and navigation items: Transfers & Payments Confirmations & Prospectuses General & Regulatory

  • In common abbreviations. In these constructions, don't put spaces on either side of the ampersand. B&B R&D Q&A

  • When the ampersand is part of an organization's formal name. Follow the organization's style for spacing around the ampersand. H&R Block AT&T

Never use a comma before an ampersand.

Use periods in text that:

  • Contains multiple sentences
  • Is a sentence followed by a link.

Use a comma after the second-to-last item in a series, before the conjunction ("and," "but," or "or").

  • This includes assets not held in custody, managed, or independently verified by Goldman Sachs.
  • On the site, clients can open an account, change their addresses, or confirm a transfer of funds.

It's username, one word. Not user name.

Always use sign in to refer to the action of entering credentials.

Use login (one word) as a noun or an adjective.

  • Enter your login information.
  • Go to the login page.
  • Sign in now.
  • Login to
  • Log in to
  • Enter your signin credentials
  • Sign on to

To avoid confusion with “sign in,” don’t use the phrase “sign up.” Instead, use “create an account” or similar phrases.