UI Content

Best practices when using copy in specific Meta components and Toolkit locations.

Buttons

Button text should always be actionable and descriptive, but succinct. It's a balance. A button that says "OK" is neither of those.

Do This:

  • Submit Order

  • Delete Item

Not This:

  • OK

  • Send

  • Click Here To See Your Item

Empty States

Empty states should include a clear call to action or information regarding the state. While empty state copy can provide an opportunity to inject a bit of personality, be aware that an empty state has the possibility of being frustrating or confusing for a user if they're expecting information.

Error Messages

Error messages are great opportunities to educate the user.

Be succinct, but don't omit details that give context to the issue. Use plain language that anyone will understand. Don't use language that blames the user, but if the error is something that the user could have prevented, educate them as to how to avoid the error in the future.

Provide a solution to the problem or suggest a list of alternatives. Users should always leave an error state feeling confident in what comes next.

Challenge the "why". What could have prevented the error beforehand? The best error message is no error message at all.

Do This:

  • A PO isn't a PO without any terms. Fill 'em out to submit the request.

  • Whoa, this looks like uncharted territory. Sorry about that. While we work on adding this tool to Toolkit, why not check out one of these other pages?

Not This:

  • Cannot access termValue of variable UNDEFINED at line 63 of poManager.js

  • error code 404: page not found. The resource you were looking for is not available at location CUSTOMERSERVICE/ISSUEOPTIONSENDER/INDEX.ASPX

Forms

Set expectations clearly. For forms that may require outside info, outline the kind of information the user may need to have available before they get started.

For complex and lengthy forms, give users a clear picture of how long the form may take, and how many steps there are to complete.

Ensure labels are concise, but are clear about what information is required or how it will be used.

Provide clear instructions as to how to complete a field if it's not immediately clear. Clarity can be included in the interface (such as a dropdown input for selecting a state abbreviation), or via the copy ("Please enter your state's abbreviation"). If you can create clarity through the interface rather than using copy, err toward doing that.

Do This:

  • Your Name

  • You will need a copy of the PO and the order date to complete this form.

Not This

  • Name

Links

Links should always succinctly describe the destination. They should never include beginning articles (a, an, the, etc.), and should never end in punctuation.

Don't include links that contain the entire URL, except where specificity is needed.

Do This:

  • Visit the home page for more information.

  • Items are listed on Spreetail.com!

Not This:

  • Visit the home page for more information.

  • Items are listed on Spreetail.com!

Status

Statuses can encompass Toasts or in-line status messages.

Statuses should give a clear picture of what is currently happening. If it provides further clarity or an opportunity to educate the user, include what the user should be doing or what comes next.

Avoid overly long status messages, it should just be a quick snapshot to set the user's expectations or confirm an action has occurred. Avoid using overly technical jargon, a status shouldn't read like Chrome devtools. For more information regarding states, check out Error States and Success States.

Do This:

  • Posting your blog, please wait.

Not This:

  • Working

Success States

Success messages are an ideal spot to inject some fun and personality into your interface -- avoid being overly technical. You should still provide additional context -- what was successful? What, if anything should the user do next?

Do This:

  • Your form has been completed -- now sit back, crack open a Lacroix, and wait for your request to be approved.

  • You have successfully entered this item into the database. To check up on its status, click here.

Not This:

  • Yay! Success!

  • Your form has been completed, thanks.

Tooltips

Tooltips should be used to communicate identifying or contextual information when that information is not obvious in the interface, and isn't necessary for a user to see every time they use the feature. Tooltips should not be used for critical information.

Tooltip copy should be as to the point as possible -- sentence fragments are okay. The copy should be unique to the tooltip, and not included in the UI. Tooltips can be displayed on hover for most UI elements, or can be included on hover for an information button to provide additional contextual data for a task.

Do This:

  • "Search by image"

  • "We’ll use this email to identify your order."

Not This:

  • Use a tooltip that says "This button will submit your form" on a button that says "Submit Form."

  • "Your password must be eight characters and include both capital and lowercase numbers."