The problem with toast messages and what to do instead

There’s been some comments about this on Twitter.

Snackbar as shown on Google’s Material Design guidelines

Snackbars—also known as toast messages—are little messages shown on top of the interface to give users feedback in response to an action they just did.

They’re designed to keep users focused on what they’re doing, which is why they’re small and automatically disappear after a few seconds.

But snackbars are problematic for lots of reasons. Here I’ll share what they are and offer some alternative solutions that don’t have these problems.

Problem #1: They disappear automatically

Snackbars automatically disappear after a number of seconds. This rushes users to read or access them which can cause anxiety and stress.

Snackbars are especially challenging for people with cognitive and motor impairments, and people working in a busy environment.

Take someone who gets a phone call just as a snackbar appears and misses the message. They won’t know what’s happened after they put the phone down.

Problem #2: They’re hard to use via keyboard

When snackbars appear, they don’t receive keyboard focus.

This makes it difficult for keyboard users to select the available actions because the snackbar is far away in terms of the tab sequence and will probably have disappeared by the time they get to it.

Problem #3: They can change state erratically

Snackbars can change multiple times within a short space of time which makes them difficult to use.

For example, when you send an email with Gmail, the snackbar status changes 3 times:

It’s being sent

Firstly, it says the email is being sent. The user can cancel or close the message.

Gmail’s snackbar as an email is being sent

This state is shown for less than a second which makes it almost impossible to click cancel. And there’s little point in closing the snackbar because the next state appears almost instantly.

It’s been sent but you can undo the send

The snackbar updates to say the email has been sent. The user can undo, view the email or close the snackbar.

Gmail’s snackbar when it’s just been sent

It’s been sent and you can’t undo the send

After 5 seconds ‘Undo’ disappears, which leaves the user with the ability to view the email or close the snackbar.

Gmail’s snackbar when it’s been sent and 5 seconds has passed

It stays visible for 10 seconds before disappearing.

This erratic nature makes snackbars really hard to use.

Problem #4: They’re distracting and can obscure the screen

Snackbars block out some of the screen which may cause users to stop what they’re doing in order to dismiss them. Or they could just wait for them to disappear.

Either way, distracting the users like this can be highly frustrating.

Problem #5: They’re hard to spot

Snackbars are small and are shown at the bottom of the page—to the edge of the user’s view. This means there’s a risk the user won’t see them.

This problem is even worse for users who zoom in using a screen magnifier because there’s a good chance the snackbar will be completely out of view.

Problem #6: They’re inconsistently located compared to other messages

Most system messages appear at the top of the page above the content. But snackbars appear at the bottom of the screen.

As different messages will appear in different locations, users will need to keep an eye on both locations which increases cognitive load.

Problem #7: It may not be clear what the message relates to

If the user archives 2 emails in quick succession the toast message will not appear to update.

And this also makes the interface feel unresponsive.

Archiving 2 emails in quick succession

What to use instead

The short answer is to:

  • show a prominent message at the top of the page
  • draw focus to the message
  • keep the message on screen until the user navigates away (or dismisses it)

The long answer is that alerts and notifications are complicated and need to take the specific context into account. More on this at the end.

Handling constant feedback

Sometimes you need to give users constant feedback.

For example, when working on a Google doc the file is constantly switching between saved and unsaved states.

While the user needs to know whether the file is saved or not they don’t want to be constantly interrupted while they’re writing.

A Google doc showing a status area in the header

Google Docs puts a status message next to the menu at the top which works well in this context because it:

  • doesn’t get in the way
  • doesn’t draw user’s attention
  • can be viewed at a glance
  • can be clicked on to see what’s previously happened


Notifications are meant to give users confidence about an action they perform so that they can proceed with confidence.

But, snackbars take control away from the user and can cause stress— turning the interface into a race against time.

If the user is working on something that requires close-to-constant feedback—like working on a Google doc—then add a persistent status area to the UI that users can check at a glance.

In most other cases just show the message front and center, without it automatically disappearing so users can see it and act on their own terms.

Thanks to Amy Hupe for editing this.