Home

Notifications

UsageContent

About

Notifications are short messages meant to provide users with or request users for information. Riverty Design System offers several components that may be used as notification components. This notification pattern aims to help designers and developers choosing the right component for each notification instance and provide usage guidelines.

When to use

This notification pattern can be helpful when:

  • You’re evaluating your notifications in general;
  • You’re searching for the right component to implement;
  • You’re looking for notification examples (see Best practices and Content).

How to use

There are different factors that can help determine the purpose of your notification, and therefore what component is suitable:

  • Type: A notification can be passive or action-required. Passive notifications inform users in a way users don’t have to take any action. Action-required notifications inform users about an action to be taken before proceeding is possible.
  • Trigger: A notification can be triggered by a system event (e.g., a system error, no connection) or as a result of users’ interaction.
  • Importance: The need of users reading and/or interacting with the notification can be high, medium or low.
  • Statuses: Some notification component come with specific statuses (Error, Warning, Info, Success).
  • Behaviour: A notification component can behave modal or non-modal, which means that components with modal behaviour don’t allow for any interaction in the background until users have taken action.
  • Usage: A notification can be global or contextual. Global notifications are not related to a user flow directly, contextual notifications are specifically related to where users are in their flow.

Dialog


dialog-wireframe-image
  • Type: Action-required
  • Trigger: System event or user interaction
  • Importance: High
  • Statuses: None
  • Behaviour: Modal
  • Usage: For global notifications users need to interact with right away

Alert


alert-wireframe-image
  • Type: Passive
  • Trigger: System event only
  • Importance: Medium
  • Statuses: Info, Warning, Error
  • Behaviour: Non-modal
  • Usage: For global notifications that are informing users about something critical coming up

Floating toast


floating-toast-wireframe-image
  • Type: Passive
  • Trigger: System event or user interaction
  • Importance: Medium
  • Statuses: Success, warning, error, info
  • Timed: Yes, possible
  • Behaviour: Non-modal
  • Usage: For global notifications that are not crucial to users and therefore don’t have to interrupt their flow

Inline toast


inline-toast-wireframe-image
  • Type: Passive or action-required
  • Trigger: System event or user interaction
  • Importance: Medium
  • Statuses: Success, warning, error, info
  • Timed: No
  • Behaviour: Non-modal
  • Usage: For contextual notifications. Inline toasts with success and warning statuses shouldn’t require an action from users, whereas inline toasts with warning and error statuses may require an action

Popover


popover-wireframe-image
  • Type: Passive or action required
  • Trigger: System event or user interaction
  • Importance: Low
  • Statuses: None
  • Behaviour: Non-modal
  • Usage: For extensive contextual information that would support users, or prompts with contextual input or confirmation requests

Tooltip


tooltip-wireframe-image
  • Type: Passive
  • Trigger: User interaction only (users need to hover to see the tooltip)
  • Importance: Low
  • Statuses: None
  • Behaviour: Non-modal
  • Usage: For short contextual explanations about icons or labels. These explanations shouldn’t communicate anything crucial

Best practices

Correct way to use a Dialog component.
Do use a Dialog for critical, global notifications.
Do

Incorrect way to use a Dialog component
Don’t use a Dialog for non-critical, contextual notifications (use an Inline Toast instead).
Don’t

Correct way to use an Alert component.
Do use an Alert for important, global notifications.
Do

Incorrect way to use an Alert component
Don’t use an alert for contextual notifications that result from user interaction.
Don’t

Correct way to use a Toast component.
Do use an Inline Toast for contextual notifications users should pay attention to within the context they are operating.
Do

Incorrect way to use a Toast component
Don’t use a floating toast for contextual notifications that users need to pay attention to within their current context.
Don’t

Correct way to use a Tooltip component.
Use a Tooltip to provide a short, additional explanation (2–3 words) for an icon, for example.
Do

Incorrect way to use a Tooltip component
Don’t use a tooltip to explain concepts or terms that are crucial for users’ understanding and require more than a short explanation (four words or more).
Don’t

Resources

About

The structure, length and exact wordings of a notification message matter. This part of the notification pattern helps designers write clear notifications that help users perform specific actions and enhance their experience.

Structuring messages

Preferably, a notification message consists of a headline, text and Call To Action (CTA) if applicable.

While the structure of most types of notification messages is the same, the content of each headline, body text, and CTA varies depending on the type of message and what we need to communicate to users.

See a breakdown for different types of notifications below.

Confirmation messages

Confirmation messages help users make decisions.

Here are some guidelines to help you craft an effective confirmation message to support users in their decision making:

  • Lead with the action you are asking users to confirm;
  • Make sure users only have to confirm one action at a time;
  • Use the same verbs in the headline, body, and CTA (e.g. don’t switch between “remove”, “delete” and “discard”).

Headline

  • The headline should clearly refer to the action users are about to take;
  • It should not start with “Are you sure…” but lead with the action itself.

Text

  • Use the text to describe any important consequences of the action.

CTA

  • Clarify the possible actions or decisions users can make in the CTA(s): instead of “Yes” or “No”, try e.g. “Keep file” or “Delete file”.

Do use consistent verbs (e.g., “Remove”), and a clear CTA.
Do use consistent verbs (e.g., “Remove”), and a clear CTA.
Do

Don’t use inconsistent verbs (“Remove” vs. “Delete”) and unclear CTAs.
Don’t use inconsistent verbs (“Remove” vs. “Delete”) and unclear CTAs.
Don’t

Error messages

Error messages help users make progress by helping them navigate a bump in the journey. Some general guidelines to follow when writing error messages:

  • Avoid overly negative language;
  • Do not blame or shame users;
  • Be as clear and specific as possible about what happened and why…
  • … but do not be too technical either;
  • Always offer an action or solution.

Notification pattern error message content (good example).
Do write specifically about the error and offer a solution.
Do

Notification pattern error message content (bad example).
Don’t be vague and negative. Don’t forget a clear CTA.
Don’t

Headline

  • Use the headline to tell users in short (and clearly) what happened;
  • No need to say “Oops!” or “Error!”
  • If the notification is a result of a user interaction, it helps when the headline is written from a user’s perspective (e.g., “You are unable to pay with Riverty” instead of “Riverty rejected this request”).

Text

  • Explanation of what happened or what’s needed;
  • Explanation of why it happened;
  • Explanation of how it can be solved: Make it easy for users to correct the error or get help;
  • Provide some reassurance, if appropriate (or if space allows).

CTA

  • Use the CTA to direct users to a solution.

Success messages

You can think of a success message as the end point of a journey. Success messages are a way to give users clarity or closure.

When writing success messages, the following things are important to take into account:

  • Confirm that users completed an action successfully (and be specific about the action they completed).

Headline

  • Let users know succinctly what they have successfully just done;
  • If appropriate (i.e. for a friendlier tone), you can also thank them, e.g. “Thanks for your payment!” instead of “Payment successful”.

Text

  • Give more context to what was successful, if necessary;
  • Inform users about any next steps.

CTA

  • Use the CTA to redirect users to a new point in the journey, if appropriate.

Notification pattern success message content (good example).
Do use a positive headline, a body text that gives more context and a CTA if appropriate.
Do

Notification pattern success message content (bad example).
Don’t give the same information in both the headline and body text. Don’t forget a CTA if appropriate.
Don’t

Text length for all types of messages

The optimal length for text line is 50-80 characters. The optimal sentence length for user comprehension is 8-15 words. Confirmation, error, and success are messages preferably 40 words maximum.

Best practices

Notification pattern toast closing (good example).
Do use just one way to allow users to close a Toast (inline or floating).
Do

Notification pattern toast closing (bad example).
Don’t use the CTA for communicating and allowing the same action as the close icon does.
Don’t

Notification pattern headline usage (good example).
Do use the headline to explain immediately what happened.
Do

Notification pattern headline usage (bad example).
Don’t use a vague headline that makes users read the body text.
Don’t

Notification pattern status usage (good example).
Do use a status that resonates with the message.
Do

Notification pattern status usage (bad example).
Don’t use a status that does not resonate with the message.
Don’t

Notification pattern label usage (good example).
Do use another label (e.g., “Not now”) if main action is to cancel something.
Do

Notification pattern label usage (bad example).
Don’t use “Cancel” as a label if main action is to cancel something.
Don’t

Resources