Also known as:
Modal windowDialogPop upAlertLightboxOverlay

Modal

A modal shows additional content in a layer above the page with a backdrop overlay covering the page behind. Use sparingly.

AnchorNeed to know

  • Modals need a trigger to open like a button.
  • Modals need an overlay behind them and over the page.
  • Choose your type (confirmation, informative, etc.).
  • Use sparingly.

Visuals

Options

  • Presets:
    • Confirmation:
      • Mood:
        • Destructive / Negative
        • Affirmative / Positive
        • Informative
    • Input/edit
    • Information

Copy guidelines

Modals are highly contextual and can be disruptive, so pay close attention to the following language rules:

Consider the flow

Pay close attention to where the user encounters this modal in their flow. Is this new information? Or is this a change in the usual flow? Adjust your language accordingly. A new step might require more context and an intro (like in an information modal). Whereas a change doesn’t require as much context as it does justification for the change and how it affects the user’s usual workflow.

Give it a descriptive title

Make sure that your titles are scannable and describe what the user is about to do. Include a strong verb. Avoid questions. Avoid words like “a” and “an.”

Do:
  • Do
    Data file will be replaced
  • Do
    Notify users
Don't:
  • Don't
    Replace data file?
  • Don't
    Notifications

Provide actionable body content

Write your body content keeping in mind that a user needs to perform an action. Guide them and avoid using superfluous language. Make each word count. Integrate links into your text to keep your writing concise.

Do:
  • Do
    Data file will be replaced
    If you continue, your original data file will be replaced with the one you recently imported.
  • Do
    Notify survey participants
    Let your participants know that the survey report is now live.
Don't:
  • Don't
    Replace data file?
    Continuing will replace all your data.
  • Don't
    Notifications
    Awesome, your survey is now live! Send your users a message.

Give it a complementary Call-To-Action (CTA) button

Your CTA button should complement the title of the modal. If a user scans the title, the CTA button should clearly direct them towards an action. Don’t hesitate to use “next” as a button if the modal includes multiple pages.

Do:
  • Do
    Data file will be replaced
    If you continue, your original data file will be replaced with the one you recently imported.
    [Cancel] [Replace data]
  • Do
    Notify survey participants
    Let your participants know that the survey report is now live.
    [Cancel] [Send notification]
Don't:
  • Don't
    Replace data file?
    Continuing will replace all your data.
    [Continue]
  • Don't
    Notifications
    Awesome, your survey is now live! Send your users a message.
    [Let users know]

Write in sentence case with minimal punctuation

All modals copy should be in sentence case i.e. the first letter of the first word is capitalized and everything else is in lower case unless it’s a proper noun or feature name. Always err on the side of minimal punctuation, so when you’ve written single, standalone sentences, leave out full stops and commas where possible.

To keep in mind

Modals contain smaller pieces of additional content while maintaining the context of the rest of the page, covered by a transparent overlay.

  • Trigger:
    • To trigger a modal, use a button. Alternatively, trigger on page load but this risks people dismissing without reading.

All modals

  • All modals are dismissible (Close button, cancel button, Esc keystroke, Click outside).
  • All modals use a single Primary Action Button. Never two primary action buttons. If a second action is an option, use a Secondary Action button (e.g. Cancel, in Cluny, no underline). Always align buttons to the center of the modal.
  • Where appropriate, use precise language and match the heading and primary button text e.g. heading is “Delete photo” and primary button is “Delete”. Avoid questions like “Are you sure?”.
  • Don't depend on a scrollable modal body. We only support a scrollable modal body as a fallback for when content is unintentionally long, such as when user-generated content is provided. This is strongly discouraged. If there's a high risk of a scrollable modal body:
    • Consider responsive behavior on small screens.
    • A modal might not be the best approach. Consider using an inline page section or a separate page instead.
    • Consider if any content inside the modal might be clipped, such as a Select dropdown section.
  • Close icon sits top right, never outside of modal. Screen reader reads the action for the icon, i.e. “Close”.
  • The backdrop overlay is pure black (not Wisteria) with 50% opacity.
  • We don't use modals as carousels. A Progress stepper in a modal is preferable if you need to guide a user through a flow.
  • Never stacks multiple modals together on screen at the same time.

Confirmation modal

The confirmation modal confirms the end result of an action such as Negative or Positive actions.

  • Small: 300px wide x Height (Header, footer, margins and 1 line of content). Primarily for mobile use.
  • Medium: 600px wide x 600px H.
  • Large: 800px wide x 800px H
  • Header: States what the intent of Modal is. A verb and a noun (e.g. Upload an image, Notify users, Restart imports etc.)
  • Footer: Primary/Destructive action label reflect the action they are performing (relative to the header).

We don't use custom spot illustrations in confirmation modals. Instead, use the standard spot illustrations.

Input/edit modal

Input/edit modals allow people to change data or settings without leaving the page. They support the ability to edit up to 3 fields. Any more becomes crowded and a new page or Isolation modal is preferred.

An input/edit modal may also be used to present data-intensive information such as a list of employees where the information modal is inappropriate.

If data will be lost by dismissing the modal unintentionally, consider autosaving.

  • Min: 300px wide x Height (Header, footer, margins and 1 line of content).
  • Max: 800px x 600px (Must fit in laptop/mobile screen)
  • Header: Should state what the intent of Modal is. A verb and a noun (e.g. Upload an image, Notify users, Restart imports etc.)
  • Footer: Primary/Destructive action label should reflect the action they are performing (relative to the header).
  • Body: Adding a stone colored background will assist the definition of Inputs and will allow product team to clearly identify the modal type.

Information modals

Information modals assist with education. They’re user triggered. They may be relative to a deeper level of information. May be useful for first time users. Heavily optional. Visual aid is good. Primary action optional.

  • Header: State what the intent of Modal is. A verb and a noun (e.g. Upload an image, Notify users, Restart imports etc.).
  • Footer: Does not require a Primary/Destructive action. Avoid using unnecessary acknowledgment buttons, e.g. ‘Okay, got it!’.
  • Visuals: use illustrations instead of screenshots where possible.
    • Illustrations may last longer without needing to be updated as well as potentially have a smaller file size than a screenshot.
    • If you need a new illustration, see illustrations.

When to use and when not to use

When to use
  • Use a modal when you need to change the flow of content or interaction and yet maintain the context of the existing page or task.
  • Modals can be disruptive and intrusive so use sparingly. To avoid “banner blindness” and to avoid people immediately dismissing modals without reading them, show only on user interactions like a clicked button, not system driven events such as immediately on page load.
  • Don’t trigger modals automatically without user interaction at any time other than page load. That is, don’t trigger modals on scroll or after some time viewing a page. This risks inaccessibly stealing keyboard focus, disorienting the user, and introducing mode errors.
When not to use
  • Avoid using modals on small screens.
  • Avoid using modals when the additional content is a huge change in context. Consider linking to a separate page.
  • Avoid using modals containing image content that is difficult to zoom on touch devices.
  • Avoid using modals when you can immediately present actions inline without cluttering the UI. For example, you might show a dropdown instead of a modal containing radio buttons.
  • Avoid using modals when you can display content inline. Consider using a collapsible “disclosure” element.
  • Avoid using modals when people need to see the rest of the screen. Consider using a Popover or Tooltip instead.
  • Instead of an informative modal, you might use an inline notification.
  • Instead of a modal, consider Overview: tooltips, popovers, modals.
  • Instead of a modal, consider a separate page.
  • Instead of a modal, consider collapsible “disclosure” elements.
  • Instead of a modal, consider inline actions.

External Links

Here are some examples of other existing design systems: