Components

Toast

Toasts are messages containing confirmations, notifications, and acknowledgments that require minimal user interaction.

Types of toasts

TypeIconDescription
InfoUsed when neutral information is being communicated.
SuccessUsed to communicate to the user when some action is successful.
WarningUsed to communicate to the user when extra care should be taken.
ErrorUsed to communicate to the user when something has gone wrong.

In addition to these types, toasts can also be timed or persistent. Persistent toasts remain on the screen until the user has taken the desired action, or until they manually dismiss the toast. These toasts are useful for things like a billing failure, out of date credit card information, etc. Persistent toasts should be used sparingly to limit showing more than one on screen at a time.

Timed toasts, which are the default, automatically dismiss after 6 seconds (4 seconds on mobile). When using timed toasts, do not display more than 3 toasts on screen at one time. Toasts are delayed until the oldest leaves the screen. If three toasts are present on screen, the toasts are ordered oldest to newest, with the most recent toast appearing at the bottom of the stack.

do
Keep the title and body copy used in a toast short and direct
do

Use the type of toast that best corresponds to the event driving the toast.

don't
Place toasts anywhere on screen other than the bottom right-hand corner.

Toast contents

Toasts can contain any combination of the following three items depending on the desired functionality.:

  • Title
  • Body
  • Link

Use the following tool to toggle the title, body, and link on/off and then fire a toast to see the result.

For better accessibility, toasts with links should be persistent. This is so users using assistive technologies, especially keyboards, have enough time to navigate to the links inside toasts.

Best practice would be to avoid using links at all in toasts. If you need to use a toast with a link, it should:

  • Persist on the screen until dismissed manually.
  • Be triggered by scenarios like errors e.g. billing failures, out of date credit card information, etc.
  • Not be triggered by common actions or workflows as this might result in many duplicate toasts displaying on screen at a time.

Questions to ask when considering the use of Toasts

  • What will the volume of these toasts be in the app? Avoid overwhelming the user with toasts.
  • What action will trigger the toasts? Be considerate of the user, question whether the action warrants a toast at all? Could a lighter method of feedback be used instead or is feedback even necessary?
  • Is it a destructive action? If so, consider using a confirmation modal as a secondary confirmation of the destructive action instead of a toast.
  • Does the toast merely provide a shortcut to a workflow that already exists in the app? Consider not using toasts in this scenario. Focus instead on the existing workflow and improve it.

Mobile considerations

When using toasts on mobile devices, there are some additional guidelines to consider:

  • Only one toast appears on the screen at a time. New toasts are delayed until the previous one leaves the screen.
  • The user is able to take action on the screen while the toast is still visible.
  • Toast disappears when the user navigates away from the current screen.

iOS

Toasts on iOS devices appear by dropping down from the top of the screen, and disappear by moving up and off of the screen. Toasts are placed near the top of the screen, mirroring the position of system push notifications, and can be manually dismissed by swiping up.

Android

Toasts on Android devices appear by moving up from the bottom of the screen, and disappear by moving down and out of the screen. They can be manually dismissed by swiping down.

Android Toasts follow the Google material Snackbar designs.