Figma notification components

"Message sent." "Invite accepted." "Your export is ready." Notifications are the small confirmations that make a product feel responsive without taking anything over. They arrive in a corner, say one thing, and go.

Toast is the informal name and it is a fair one: the message pops up, the message goes away, and nobody is expected to do anything about it.

Nine types, and what each one is for

Type is the only property besides the breakpoint, and it covers a lot of ground. A primary icon and a gray icon for neutral messages, success, warning, and error icons for outcomes, no icon at all for plain text, an avatar for anything a person did, an image for anything with a preview worth showing, and a progress indicator version for work that is still running.

That last one is the useful oddity: a toast carrying a live bar is how an upload leaves the screen it started on without disappearing entirely, and it is why progress indicators turn up inside this file.

Desktop toasts are 504px wide, the image type a little wider at 544px, with every type also drawn at 375px for mobile.

Toast or alert

Ask what happens if the user misses it. If nothing is lost, a toast is the right container. If they will need the information later, or need to do something about it, it belongs in an alert in the page or in a persistent list they can return to.

Nielsen Norman Group's breakdown of indicators, validations, and notifications includes a case of someone missing an error entirely because it faded after five seconds, which is the argument in one anecdote.

Errors that require a fix do not go in toasts. Anything that has to outlive the session belongs in one of the transactional email templates instead.

How long it should stay

Four to six seconds is a sane default for a short confirmation, longer when there is an action inside it, and no auto-dismiss at all when the toast holds something the user cannot get back.

WCAG's timing adjustable criterion is the reason this is more than a matter of taste: content that removes itself on a timer has set a reading speed for everyone, and not everyone reads at that speed.

Keep a close control on every toast so people can clear a stack early, and pause the timer on hover, because a cursor resting on a message means somebody is reading it.

Prototyping toasts, and the stacking problem

The realistic version in Figma is an overlay: trigger the notification with "open overlay" positioned in the corner you intend to use, then wire an "after delay" interaction back to close it.

Figma's guide to interactive components covers building the hover and dismiss states into the component so the behavior travels with every instance rather than being rewired per frame.

Stacking is where prototypes stop helping and you have to decide on paper: newest at the top or the bottom, a hard cap of three visible at once, and what the fourth does when it arrives while the first is still animating out. That last question is the one that gets discovered in production.

When it's time to build, the same toasts exist in code. Untitled UI React notifications are open source, built with Tailwind CSS and React Aria, with queueing, dismissal, and screen reader announcement already handled.