Components

Notice

Usage

Use notice when the user needs to understand status, risk, or the next step without leaving their flow.

Always choose the smallest notice level that gives the right visibility, and let status reinforce the message rather than carry it on its own.

Use for

Service updates, account status, and guidance with a clear consequence.

Avoid for

Marketing messages, general tips, or noise without real impact.

Start with

The smallest level that is still clearly visible to the right audience.

Anatomy

All notice levels share the same core parts, but surface area and priority differ.

This keeps the content consistent whether a notice is shown as a system notice, at page level, in a section, or inline.

System notice

System notice anatomy
  1. Title – a short heading that quickly summarises the situation.
  2. Icon – reinforces the selected status and follows the notice semantics.
  3. Body copy – explains what happened and what it means for the user.
  4. Action – an optional link or CTA when the user can act directly.
  5. Container – the surface that holds the notice content.

System notice specs

System notice specifications
  1. Padding 16 / 16 / 16 / 20 px (top/right/bottom/left)
  2. Icon gap 12 px
  3. Content gap 12 px
  4. Title/body gap 4 px

Page notice

Page notice anatomy
  1. Title – a short heading that quickly summarises the situation.
  2. Icon – reinforces the selected status and follows the notice semantics.
  3. Body copy – explains what happened and what it means for the user.
  4. Action – an optional link or CTA when the user can act directly.
  5. Visual status indicator (stroke).

Page notice specs

Page notice specifications
  1. Padding 16 / 16 / 16 / 20 px (top/right/bottom/left)
  2. Icon gap 12 px
  3. Content gap 8 px
  4. Title/body gap 4 px

Section notice

Section notice anatomy
  1. Title – a short heading that quickly summarises the situation.
  2. Icon – reinforces the selected status and follows the notice semantics.
  3. Body copy – explains what happened and what it means for the user.
  4. Action – an optional link or CTA when the user can act directly.
  5. Container – the surface that holds the notice content.

Section notice specs

Section notice specifications
  1. Padding 8 / 8 / 8 / 10 px (top/right/bottom/left)
  2. Icon gap 8 px
  3. Content gap 4 px

Inline notice

Inline notice anatomy
  1. Title – a short heading that quickly summarises the situation.
  2. Icon – reinforces the selected status and follows the notice semantics.
  3. Body copy – explains what happened and what it means for the user.
  4. Action – an optional link or CTA when the user can act directly.

Inline notice specs

Inline notice specifications
  1. Outer padding 0 px
  2. Icon gap 8 px
  3. Stack gap 0 px

Best practice

Good notices are short, close to the context, and show a clear way forward when one exists. When there is no actionable path, the notice should acknowledge the situation and set expectations.

The content should help the user move forward, not compete with the rest of the interface. In cases where no workaround is available — such as a service outage — be honest, set expectations, and avoid forcing a call-to-action that leads nowhere.

Three principles

Use notice to explain the situation quickly and clearly.

Lead with the consequence

Start with what happened and what it means for the user.

Place it close to the context

Place the notice close to the area or step it relates to.

Avoid stacking

Show one notice at a time and only replace it when the priority increases.

Escalate correctly

Use section or inline when the issue is local to a step, a panel, or a field.
Do not use a system notice across the whole experience if only one flow or feature is affected.

Be clear about the next step

Describe the consequence and link to a relevant action when the user can solve it directly.
Do not write generic error messages without explaining what the user should do next.

Appearance

Choose the level based on how much of the experience the message affects and how many users need to see it.

System

System notice

Affects the wider product or several key flows at once.

Page

Page notice

Applies to all content on the current page.

Section

Section notice

Applies to a module, panel, or step in the flow.

Inline

Inline notice

Applies to a field, a row, or a small area close to the action.

Status or notice levels

Semantic colours direct users and clearly convey messages.

Information

Information notice

Neutral guidance or a status update.

Success

Success notice

Confirms that something worked or has been resolved.

Attention

Attention notice

The user needs to react soon but can often continue.

Critical

Critical notice

A blocking error or a larger disruption that requires clarity.

Accessibility

Notices communicate status and often require immediate attention, so they must be accessible to all users including those using assistive technology.

Use the right ARIA roles and attributes so screen readers announce notices at the correct urgency without interrupting the user unnecessarily.

ARIA roles and live regions

Match the ARIA role to the notice urgency so assistive technology announces it correctly.

Critical and Attention

Use role='alert' with aria-live='assertive'. The screen reader announces these immediately, interrupting the current task.

Information and Success

Use role='status' with aria-live='polite'. The screen reader announces these at the next pause without interrupting.

Focus management

Move focus to the notice only when the user must act before continuing. For non-blocking notices, let focus stay where it is.

Behaviour

Define whether a notice stays visible, can be dismissed, or disappears on its own so that the user always knows how to move forward.

How a notice enters and exits the view should match its urgency. Critical notices persist; informational ones can be dismissed or auto-close.

Dismissibility

Information and Success notices include a close button. Attention and Critical notices persist until resolved. For brief success messages ("Saved", "Copied"), use the Snackbar instead.

Visibility

All statuses stay visible until manually dismissed or resolved. For brief, transient confirmations that auto-dismiss (5–8 s), use the Snackbar instead.

Animation

System and Page notices slide in from the top. Section and Inline notices fade in. Exit animations mirror entry direction. Critical notices appear instantly.

Responsive behaviour

Notices should remain readable and actionable across all viewport sizes without competing for space.

On narrow screens the notice spans the full width. Action link is stacked below body.

Desktop and tablet

System notices span the full viewport width. Page notices match the content area width. Section and Inline notices fill their parent container. Actions always stack below the body copy.

Mobile

All notices span full width. Actions always stack below the body copy. System notices remain fixed at the top. Padding scales down to 12 / 12 / 12 / 16 px for System and Page levels.

Content guidelines

Clear, concise copy helps the user understand the situation and act on it. Write for scanning, not reading.

Titles should be under 60 characters. Body copy should be one to two sentences maximum. Always lead with the consequence, then explain the next step.

Write actionable copy

"Your payment method expires on 15 Aug. Update it to avoid a service interruption."
"Error. Something went wrong. Please try again later."

Keep titles short and specific

"Payment method expiring" — short, scannable, tells the user what to look for.
"Important information regarding your account payment method status update" — too long, buries the point, impossible to scan.

Placement

Where a notice sits in the layout determines how quickly the user sees it and how much it interrupts their flow.

Always position the notice at the level where the issue occurs. A broader placement than necessary adds noise; a narrower one risks being missed.

Position each notice level where it has the right visibility for its scope.

System notice

Fixed at the very top of the viewport, above all content and navigation. Spans the full width. Use for platform-wide outages, maintenance windows, or account-level issues that affect every page.

Page notice

Positioned below the page header and above the main content area. Spans the content width. Use for messages that apply to everything on the current page, such as a missing permission or a draft state.

Section notice

Inside the relevant card, panel, or step — at the top of that section. Use when the message only affects one module or step in a multi-part flow.

Inline notice

Directly adjacent to the affected element — below a form field, beside a toggle, or next to a row. Use for validation feedback or contextual hints tied to a single control.

Stacking and priority

When multiple notices compete for the same space, follow a clear priority order to avoid overwhelming the user.

Handle competing notices

Show one notice per level at a time. When a higher-priority notice arrives (Critical > Attention > Information > Success), replace the current one. Queue lower-priority notices and show them once the higher one is dismissed or resolved.
Do not stack multiple notices vertically. Stacking creates a wall of messages that users ignore and adds layout shift that harms readability.

Feedback

We always want to improve the Design System and would be thrilled to get your feedback.

Please share your wisdom with us.

Microsoft Teams [internal]

Designsystem@svenskaspel.se