Banner

Products sometimes have to speak first. A card that expired, maintenance planned for the weekend, a trial with three days left — none of these are things the user asked about, and all of them have to reach the user anyway.

The trouble was finding somewhere to put them. A toast appears for about three seconds and then disappears, so anyone not looking at that screen in that moment loses the message entirely. Teams that announce payment failures through toasts all end up in the same place. The user was in another tab writing a document, and only after the account locks a month later does support hear "nobody ever told me." The notice did appear. Nobody saw it.

At the other extreme sits the modal, a window that dims the screen behind it and blocks everything until the user answers. Put a billing notice there and it certainly gets seen, but interrupting the task every time teaches users to close the window without reading it.

The banner exists to fill the space between those two. It stays on screen without blocking the work, and it changes what makes a notice go away: not elapsed seconds but the state of the problem. Whether it shows depends on whether the issue is still there.

A single full-width row sits at the very top of the page and pushes everything below it down. It occupies real space in the layout rather than floating over the content, so nothing underneath gets covered.

That row usually holds four things.

1. A status cue — an icon and a background color on the left that signal severity. Blue for information, yellow for caution, red for errors, defined once in the design system. Color alone reaches nobody who can't distinguish those hues, so the icon and the wording have to carry the same signal.
2. The message — one sentence covering what happened and what follows if nothing changes. "Payment failed" is weaker than "Your card was declined; this workspace becomes read-only in 3 days." The second version carries a deadline and a consequence, which is what gives the user a reason to act now.
3. An action button — a direct route to the screen that fixes it. For an expired card, one button leading to payment settings is enough.
4. A dismiss button — so the user can clear it. Notices where ignoring the problem stops the service, like a failed payment, are sometimes shipped without one.

What happens after dismissal has to be decided deliberately. Hide it forever and one accidental click erases the message; show it again on every refresh and the user reads the same sentence ten times a day. The usual middle ground is to hide it for the current session and bring it back on the next visit, or, for anything with a deadline like scheduled maintenance, to let it expire on its own.

Never run two at once. Two stacked rows bury the top third of the screen under announcements, and from then on users skip that whole region.

It fits situations where ignoring the notice costs the user something and fixing it requires the user to act. At Pagedeck five places qualify.

1. Billing problems — a declined or nearly expired card, stated together with what gets restricted and when.
2. Planned maintenance — service paused for two hours starting at 2am Saturday. It clears itself once the window passes.
3. Trial expiry — a countdown of days left, with a route to the plan selection screen.
4. Restricted state — opening a shared document with view-only permission, where the user needs to know in advance what this screen won't let them do.
5. Environment problems — a notice that some features won't run in a browser version that is no longer supported.

Teams often reach for it to promote new features, and that is where its value starts draining. Once users read the strip as advertising, the payment failure notice that appears next week gets skipped along with it. The space behaves less like a channel and more like a budget that can only be spent on one thing at a time.

"This needs a banner, not a toast. If they miss it, billing stops."

The consequence is too heavy for a notice that disappears, so it should move to a spot that stays.

"Dismissing it hides it for the session and it comes back on the next visit."

One dismissal shouldn't hide the message permanently, and the rule for that is set.

"There are two rows up there right now. Let's rank them and keep one."

Stacked notices mean neither gets read, so one has to come down.

At Pagedeck this argument came up most often over the failed-payment notice. Theo originally shipped it as a toast, and over three months, twenty-eight of the thirty users whose accounts locked on an expired card said they had never seen a warning. Noa moved it to the top of the screen and rewrote the text to include the days remaining and the lockout that followed, and the share of users who replaced the card before locking rose sharply.

The team also made a rule out of it. What goes in that row is decided by Noa together with an accessibility review, and marketing announcements stay out of it. When Ravi wanted to announce a feature launch there, it went somewhere else in the product instead.

Because the spot is so visible, it is tempting to collect every important notice in it. The top of the screen really is where the eye lands first, so the logic holds at a glance. But when something is always sitting there, users learn to treat the region as decoration. The same thing that happens to ad slots on the web happens inside the product. After that, even a warning posted three days before an account locks gets skipped at the same speed, and the row loses its effect while still eating screen height.

The other common assumption is that a dismiss button makes any amount of nagging acceptable. Users can clear it, the reasoning goes, so a little friction is fine. In practice people don't read and then dismiss; they dismiss because something is in the way. Unlike a snackbar, which offers a way to undo what just happened, this row leaves no trace once it's closed. So when the problem outlives the dismissal, bring the notice back on the next visit and keep the same message in email and in settings.