Toast notification UX: when a toast is the right tool

A toast is a short message that shows up after something happened and leaves by itself. That makes it good for small confirmations and bad for anything a person has to see.

Good uses

Confirm something the user just did: saved, copied, sent. Offer a quick way back, like Undo after a delete. Report that background work finished, for example an export that was running while the user did something else.

Bad uses

Errors the user has to fix belong next to the field that failed, where they stay visible. Anything critical, legal or about money should not disappear after a few seconds. And a toast is one sentence with at most one button. If you need a paragraph or two choices, use a dialog or an inline message.

How long it should stay

Five seconds is a reasonable default for a short sentence. A toast with a button needs longer, because the person has to notice it and then move to it. Hover and keyboard focus should pause the timer so reading is never a race. In Ding, errors, loading toasts and toasts with a button do not time out at all.

One toast or a stack

A stack keeps history but covers the page when many things happen quickly. A single toast that changes in place keeps attention on the latest message and loses the older ones. I think that trade is right for most apps, which is why Ding works that way, but if your users need to see several messages together, stack.

Wording

Say what happened in a few words: Saved, Link copied. For an error say what failed and what to try: Could not save. Check your connection and try again. Leave out exclamation marks and the word successfully, they add length and no information.

Two related pages: the undo pattern and making toasts accessible. If you are choosing a name or a library, see toast vs snackbar.