Modal Design

A modal is a dialog layered over the page that blocks interaction with everything behind it until it is dismissed. The blocking is both its purpose and its cost. It guarantees attention, and it takes control away from the person using the product.

That trade is worth making for a short, consequential decision that has to happen now. It is a poor trade for most other things, and modals accumulate in products because they are the easiest way to add something without deciding where it belongs.

Modal, drawer, popover, page

The question that resolves most cases: does the person need to see or use what is behind it? If yes, a modal is the wrong container, whatever the layout looks like.

What a modal has to contain

A title that states the decision. "Delete workspace?" rather than "Confirm".

Enough information to decide without leaving. A confirmation that does not say what will be deleted, or how much of it, forces somebody to cancel and go looking, which is the failure the modal was supposed to prevent.

Buttons labelled with the action. "Delete workspace" and "Cancel", not "OK" and "Cancel". A destructive action must be visually distinct and must not sit where the confirming action usually sits. See button design.

A way out that is obvious. Escape, a close control, and the backdrop, with the caveat that unsaved work should not vanish on a stray backdrop click.

Nothing scrollable, if it can be avoided. A modal that scrolls is usually a page in the wrong container.

Focus, which is where modals fail

The behaviour that separates a working modal from a broken one is invisible to anybody using a mouse.

When it opens, focus moves into the dialog. While it is open, focus cannot leave it, so tabbing cycles within. Escape closes it. When it closes, focus returns to the element that opened it. The content behind is hidden from assistive technology, not merely visually covered.

Miss the last step and a keyboard user closes the dialog and lands at the top of the document with no idea where they were. This is the most common accessibility defect in the component and one of the easiest to test: open it, press Tab repeatedly, press Escape, and see where you are.

Confirmation modals, and why most should not exist

The reflex when an action is risky is to add a confirmation. It is usually the wrong instrument.

A confirmation charges a click on every use, forever, including the overwhelming majority of times the person meant it. After the third occurrence it is dismissed reflexively, which means it has stopped protecting anything while continuing to cost.

Undo is better wherever it is technically possible. It costs nothing when the action was intended and recovers the case where it was not, which is the actual objective.

Reserve confirmation for what genuinely cannot be undone, and make the friction proportional: deleting one row and deleting a workspace should not feel the same. For the truly irreversible, requiring the name to be typed is defensible precisely because it is annoying.

Modals in B2B products

Stacked modals mean the flow is wrong. A modal opening another modal is a sequence that needed a page or a wizard.

Bulk actions need a partial-failure answer. Forty rows selected, six of which cannot be processed. The confirmation has to say what will happen to the six, and this is almost never designed.

Long forms are not modal work. Configuration and record editing want a drawer or a page, where the work can be linked, resumed and reviewed against what is behind it.

Permissions change the content. A viewer opening a modal built for an admin should not meet a form with everything disabled and no explanation.

In practice

A product uses a modal for editing a customer record, because the record list is where people start.

It works while records are small. As fields are added the modal grows, then scrolls, then gains its own tabs. Someone adds a second modal for editing an address inside it. Support starts hearing that people lose work when they click outside by accident.

Each step was a reasonable local decision, and the accumulated result is a page living inside a dialog, with none of a page's advantages: no URL to share, no back button, no room, and a dismissal gesture that destroys work.

Moving it to a drawer restores the list behind it and the ability to link to a record, and the nested modal disappears because there is now room for the address inline.

Where teams get it wrong

• A page inside a dialog. Scrolling, tabs and nesting are all the same signal.
• No focus management. The defect that only affects people not using a mouse.
• Confirming the routine. A click charged forever, dismissed reflexively by the third time.
• Backdrop click discarding work. An easy gesture with an expensive result.
• "OK" on a destructive dialog. Answerable without reading the question.
• Stacked modals. A flow that needed a different container.