Messaging

Messages provide information about changes in a system or persistent conditions. Messaging applies to a range of components such as badges, banners, dialogs, flags, notification trays, section messages, and tooltips. Language used in these components is critical as they increase trust, reduce the likelihood of errors, and improve system performance.

For specific guidance on how to decide on the right component for your context, where to place it, and its level of disruption, visit Feedback and status.

Anatomy

A. Title (optional): Descriptive text previewing the purpose of an alert.
B. Message (required): Text elaborating on the nature of the message or providing important context.
C. Call to action (CTA) (required): Buttons or links enabling users to respond to alerts by taking relevant actions.

Best practices

• Always use sentence case except for proper nouns or acronyms.
• Use plain language and avoid abbreviations or jargon.
• Be brief, descriptive, and direct.
• Keep the information useful. Don’t disrupt the user’s experience unless necessary.

Titles

• Limit titles to three to five descriptive words, using the description to provide additional details.
• Avoid using unnecessary articles like “the” or “an”.
• Don’t include punctuation.
• Use descriptive language that indicates the purpose of the alert instead of terms like “warning” or “error”.

Messages

• Provide details on the reason for the alert without being technical.
• Use contextually relevant language to help users understand why the message is important.
• Clearly outline the simplest way to fix the problem (if applicable) without sending them to another location for answers.

Calls to action

• Give users the opportunity to edit, view, or in some cases undo their actions, especially if they’ve just created something or changed important settings.
• Use clear, actionable language that is easy to understand without additional context or information.
• Avoid using unnecessary articles like “the” or “an”.
• Don’t include punctuation.
• Avoid ableist verbs that focus on senses. For example, use “Play video” instead of “Watch video”.
• Include a “dismiss”, “cancel”, or “close” button if the alert doesn’t include a close “x” in the top right corner.
• Learn more about calls to action in Grammar and punctuation or by visiting Button.

Voice and tone

Voice and tone are key elements to creating alert messages that are helpful without placing blame on the user. The guidance below discusses voice and tone recommendations specific to messages. To learn about voice and tone recommendations in other use cases, visit Grammar and punctuation.

Active and passive voice

Using active or passive voice depends of the context and purpose of the message. As a general rule, active voice works better for providing clear, direct instructions, while passive voice is better for explaining errors or mistakes.

Use the active voice whenever possible. If the message sounds harsh, adjust to the passive voice to soften the message.

Learn more about active and passive voice in Grammar and punctuation.

Active voice examples

Use the active voice to communicate success, instructions, or neutral updates. This ensures it’s clear to the user what actions they must take or when they’ve completed a task successfully.

Passive voice examples

Use the passive voice to communicate errors and warnings. This helps avoid placing blame on users and softens negative updates. It’s also helpful when the cause of an error is unclear or nobody is at fault, such as network connection issues.

Tone

At Visa, our tone is flexible depending on the context. When writing alert messages, prioritize giving clear, efficient information to help users complete their goals quickly. The tone should be neutral, clear, and helpful.

• Inform the user without causing alarm. Provide clear, concise instructions that help complete tasks.
• Be direct when providing next steps or instructions for correcting errors.
• Avoid using technical jargon, codes, acronyms, and terminology that assume the user has advanced knowledge.
• Avoid overly playful language, tongue-in-cheek references, or plays on words that aren’t widely understood.
• Avoid accusing or patronizing the user for failing to follow directions or misusing the system.

Examples

Informational message

Informational messages should provide information without disrupting the user’s workflow. They can communicate a change in state or important information about an experience or feature.

Success messages

Success messages are used to confirm a user’s action or task completion. They usually don’t require additional actions unless providing a pathway to undo the action being confirmed.

Warning messages

Warning messages are used to indicate a potential change in the user’s workflow or access to the system. Warning messages should use clear, informative language that conveys the appropriate level of urgency so the user knows how to respond.

Error messages

Error messages are used to indicate a a problem has already occurred or that there’s been a mistake during the user’s workflow. They should draw attention to what has happened, communicate the consequences, and tell the user what to do to move forward.

Error messages should use clear, informative language that conveys the appropriate level of urgency so the user knows how to respond.

Inline error messages

Inline error messages are common across a range of components. For help prototyping content for common error messages, VPDS offers component variants with pre-written messages. Access these in the assets panel of our Design kits.

Badges

Badges are compact components used to communicate status with limited text. There are generally two categories of badges. The first is numeric badges, which display a count or tally of notifications. The second is informational badges, which provide status updates when the number of notifications is unknown or irrelevant.

To learn more, visit Badge guidance.