Design Guidelines

Interface Feedback Guideline Overview

Interface feedback provides reactive responses and contextual information that help instill trust in the system.

An illustration showing a variety of examples of Interface Feedback.

Notifications vs. Interface Feedback

While notifications and interface feedback communicate using similar patterns, they have two key differences.

  • Notifications are traceable, meaning a user can view or dismiss a notification, and revisit its content later. Dismissed interface feedback however, is not retrievable.
  • Interface feedback is the system's response to direct user input—for example, a confirmation toast confirming a record change. Notifications, on the other hand, are not always reactive and not necessarily system driven.
A wireframe showing an example of a success toast.
An example of interface feedback: A green success toast.
A wireframe showing an example of a drop down notification tray.
A notification tray
A wireframe showing an example of an error pop over.
Another example of interface feedback: A red error popover.
A wireframe showing an example of two notification tiles.
Another example of a notification: Notification tiles.

Feedback Types

There are four types of feedback: system, engagement, access, and standard.

A spectrum of proactive informational to reactive validational showing the four feedback types as well how source and user feedback interact. System feedback is on the far left indicated as most proactive informational, followed by Engagement, Access, and finally Standard feedback on the far right indicated as most reactive validational.

At the highest level, feedback types are categorized by user interaction type:

  • System feedback alerts users to important system-level issues or statuses. It's initiated by the system, not a result of user actions.
    Example: System maintenance this weekend.
  • Engagement feedback nudges users to update data or explore a new feature.
    Example: No activity on Opportunity X in the past 30 days. Create a task or schedule an event.
  • Access feedback appears when users try to access unavailable items, perhaps because a record has been deleted or the user doesn't have access to certain data.
    Example: Lead X unavailable.
  • Standard feedback responds to most create, read, update, and delete (CRUD) actions.
    Example: Account created.

Optimizing the Feedback Experience

Here are three simple steps to help make the feedback experience both relevant and helpful.

  1. Select the appropriate feedback type based on user's interaction with the application.
  2. Pick a pattern from the category that makes sense given the user flow and UI, and has the appropriate visibility ranging from discrete to urgent.
  3. Determine which state best characterizes the feedback message.
Feedback TypeInline TextPopoverToastAlertIllustration & Inline TextModalPromptDocked Composer

Feedback Design Principles

Keep these principles in mind when designing feedback:

  • Timely, not noisy. Provide feedback at the right time. Not every interaction requires feedback.
  • Informative, not verbose. Say what's necessary and not much more.
  • Actionable, not static. Enable shortcuts for relevant actions to improve efficiency.
  • Cross device, not duplicative. When appropriate, alert users on all their devices, but clear the message once a user has read it.


Icons may be used in feedback components. Follow these guidelines when deciding which icon to use:

IconUse When
1Error Icon indicating that something is wrongErrorSomething is wrong
2Info Icon indicating that more information is availableInfoMore information is available
3Offline Icon indicating that the user is currently offlineOfflineUser is in offline mode
4Sussess Icon indicating that an action has been completedSuccessAn action has been completed
5Warning Icon indicating that there may be a problemWarningThere may be a problem
6User Icon indicating that a user-related message is available.UserA user-related message is shown
7Wrench Icon indicating that a maintenance-related message is availableWrenchA maintenance-related message is shown

Determining Feedback Characteristics

A salesperson finalizes a sale, but some of the initial numbers have changed. She updates the record. How should the application confirm that the record is saved?

  1. To determine the feedback type, look at the user interaction flow:
    • The user initiates the interaction.
    • The record is accessible, and the user successfully saves changes.
    • Feedback type: Standard
  2. Choose from the four standard feedback components:
    • Inline text is used for empty and inaccessible states, field-level error messages, and in-between states such as saving and loading. (Use a more prominent component for success messages.)
    • A popover suggests a user action or communicates an error after the user submits data.
    • A toast confirms a create, edit, or delete action.
    • A modal warns the user, confirming that an action is intentional, not accidental.
    • Feedback component: Toast
  3. Determine the feedback state.
    • In this case, the user has successfully saved changes to the record.
    • Feedback state: Success

Based on this analysis, the application should show a success toast.