Drawer Preview

Resources

Types

Inline

An inline drawer is a passive surface that sits side-by-side with main page content. Use inline drawers when it’s helpful to view and interact with main content and drawer content at the same time.

Overlay

An overlay drawer is an intrusive surface that covers all or part of the main page content. Use overlay drawers to draw more attention to the content in the drawer.

Behavior

Modality

Overlay drawers are elevated above main page content and are modal by default. The default behavior will gray out main page content and disable interaction with it.

Save modality for important tasks that are clear and quick to accomplish. As with all modal patterns, avoid surfacing too many of them at a time. It should always be clear what someone’s next step is. Too many blocking surfaces can distract from the original context and make it hard for people to interact with the content.

Don’t invoke multiple overlay drawers at a time

Drawers should give people helpful context and a clear next step.

Optionally, you can turn off modality to allow people to continue interacting with the main page content. This behavior is helpful for content that is more informational than actionable and easily dismissed, like viewing items in a cart or checking new notifications.

Use overlay drawers to provide at-a-glance info that can be easily dismissed

Use overlay drawers with caution. They almost always block something, images or text on the page and even actions like dismissal.

Collapsing vs dismissing

Drawers are usually opened by interacting with a button on screen. They can be closed again by interacting with the same button or an included dismiss icon. If a drawer includes components to gather information, like inputs or checkboxes, make sure to alert people if they might lose progress when they close the drawer.

Dismiss

Collapse

Prolonged flows and multi-step tasks

Drawers allow for multi-step tasks, but should be kept to two to three steps. Drawers should always offer information and actions relevant to the parent view. For example, a drawer asking for feedback can have an initial screen with form fields and a secondary screen with confirmation and follow-up steps.

For longer or more complex tasks and workflows, consider a more focused surface.

Errors and confirmation messages

Communicate the status of drawer contents using message bars or empty states in the drawer. Place the components closest to the status they’re communicating. For example, if only one section of the drawer is in an error state, put a message bar inline with that section. If there are multiple errors, put a message bar at the top of the drawer.

If the whole drawer can’t be rendered, try an empty state.

One section failed to load

Multiple sections failed to load

Entire drawer can’t be rendered

Use a dialog to confirm actions someone tries to take in a drawer, especially if those actions might lead to data loss. Avoid putting actions in drawers that need confirmation frequently, especially in overlay drawers. Showing too many additional surfaces can distract people from their original contexts.

Wrapping and overflow

Drawer content will wrap to fit the width of the drawer. If content exceeds the height of the drawer, the overlow content won’t scroll by default. Wrap the body content in the <DrawerBody> component to enable scrolling.

Layout

Placement

Drawers should provide a predictable surface for contextual actions and information. Be consistent in how you place drawers of similar content throughout experiences. Check other Microsoft apps for how they may be placing drawers for consistency among products.

Don’t break conventions. For example, people generally expect navigation patterns on the left and notification patterns on the right.

Anatomy

Think of a drawer as having three parts: a header, a body, and a footer.

1. Header (required) contains a descriptive drawer title, an optional close button, and any top-level quick actions, like back or refresh.

2. Body (required) contains the main information or actions in the drawer. Drawer bodies are flexible to fit many different content types that will help people accomplish their tasks: lists, data visualizations, checkboxes and radio groups, etc.

3. Footer (optional) contains any prominent button actions. Make sure to place primary buttons to the left of other buttons.

In drawers with long content, the header and footer can be sticky and stay at the top and bottom of the drawer. In a scroll state, the header and footer will elevate and the body content will scroll behind. At 400% zoom and in small viewports, the header and footer become non-sticky to give prominence to the main content.

Size

Out of the box, drawers are available in small, medium, large, and full widths. The default width is small.

Like modal overlay drawers, full-width drawers obscure the content behind them. Don’t use them if it’s helpful for people to reference the information on the main page.

Small (default)

Medium

Large

Responsive drawers

Some inline drawers appear or disappear based on breakpoints defined by the product team. Often, these drawers are always expanded with no option to collapse them. However when the layout reaches a particular breakpoint, the drawers will collapse. While collapsed, the drawers can be invoked again on hover or focus.

Content

Summarize the drawer’s contents in the title

Make the title brief but informative. It should give people an idea of what they’ll find in the drawer or what it might help them accomplish.

Use sentence style capitalization—only capitalize the first word. Don’t use end punctuation. For more info, go to Periods in the Microsoft Writing Style Guide.

Communicate the main message in the body

Use the body to get to the point—fast. Drawers need to be scannable so they don’t distract people from the main task. Don’t use them for long blocks of text, like privacy statements or terms and conditions.

When including form fields, use labels, helper text, and placeholder text to make it easy for people to enter information. For more info, go to the Field content guidance.

Button labels should respond to the title

Buttons should use concise, active language that clearly communicates what will happen next. Usually a single verb is best, but include one or two more words if it will aid clarify.

Whenever possible, buttons in the footer should be a response to the title.

Header

Footer