Designing a notification inbox in Figma

Quick answer

An inbox keeps messages the person might open later. A toast does not. Design the inbox as a list with unread state, a time or type group, and row actions for open, mark read, and dismiss. Put the unread count on the trigger as a badge. Do not also pop a toast for every row you store. Preferences for which messages exist at all belong on the notification settings page, not inside each row.

Who this is for

• Product designers adding “what did I miss?” to an app people leave and come back to.
• Teams that already show toasts and are about to duplicate them in a panel.
• Engineers who need read state, grouping, and what a click does.

Skip a full inbox when the product only has one kind of message and it must be handled immediately. Use a toast or an inline alert.

Inbox, toast, and banner

Pattern	Lifetime	Use for
Toast	Seconds, then gone	“Saved”, “Copied”, a finished action
Banner	Until the page condition ends	A problem with the current page
Inbox item	Until read or dismissed	Something that happened while they were away

If the person must deal with it tomorrow, it is an inbox item. If they must deal with it on this page, it is a banner. If they only need to know an action finished, it is a toast.

Anatomy

A panel or a page both work. Use a panel when the list is short and people check it in passing. Use a page when rows need filters, search, or bulk actions.

Each row needs:

• What happened. One sentence, with the object named: “Alex commented on Billing Q3”, not “New activity”.
• When. A relative time is fine if you also store a real timestamp for the handoff.
• Unread. A marker that is not color alone. A dot plus weight, or a dot plus a “New” label.
• Destination. The row click opens the thing the message is about. If there is no destination, do not make the row look clickable.
• Overflow. Mark read, mark unread, and dismiss live in a menu when they would clutter the row.

The header has the title, the unread count, and one action: “Mark all read”. Do not add settings, filters, and a compose button in the same header.

Groups

Group by time when the product is a general inbox: Today, Yesterday, Earlier. Group by type when the types need different treatment: Mentions, Reviews, System. Do not group by both at once on a short panel. Pick one.

Keep system messages in the same list if they are rare. Split them out when they are security or billing and must not sit under a comment.

States

State	What the person sees
Unread	Marker on, count includes the row
Read	Marker off, row still in the list
Empty	No items at all. Say that nothing is waiting.
All caught up	Items exist and none are unread. Different copy from empty.
Failed	The list did not load. Retry, and do not pretend the inbox is clear.

Empty copy is quiet. “You’re up to date” on a broken request teaches people to ignore the inbox. Use the empty state patterns, with a variant for failure.

Loading uses a short skeleton of rows, not a spinner covering the page. See skeleton screens.

Mark read

Decide this before you draw the rows:

• Opening the panel marks everything read, or only the row they click marks that row.
• “Mark all read” is explicit. Prefer this when messages matter. Auto-marking the whole panel hides items the person has not seen.
• Dismiss removes the row. Mark read keeps it.

Write the choice on the frame. Engineers should not infer it from a hover style.

What to hand off

• Which events create an inbox item, and which only toast.
• Whether unread is per person. It is, unless you have a shared inbox and have said so.
• Click destination for each type.
• Badge rules: cap the count (“9+”) and clear it when unread hits zero.
• A link to notification preferences, placed in the panel footer, not on every row.

Common mistakes

• Toasting and inboxing the same event, so the person dismisses it twice.
• Rows with no destination that still use a pointer cursor.
• Color-only unread dots.
• A badge that counts read items because the query was never defined.

FAQ

Panel or full page?

Panel for a quick check. Page when people search, filter, or handle messages as their job. You can ship the panel first and add the page when the list gets long.

Do comments belong here?

A mention can. The thread itself belongs in comments. The inbox row is the pointer, not the conversation.

Should marketing mail use this inbox?

No. Product activity and marketing mail are different lists. Marketing preferences stay on the settings page.

Next

After someone knows what they missed, the first-run path is a different list: a short checklist, not an inbox. Continue with first-run onboarding. The pattern shelf is on Patterns.