Modal Design
Designing dialogs that block the page to demand a decision — when one is justified, what it must contain, and how a person gets out.
UI ComponentsA modal stops everything. It takes focus, blocks the page behind it, and refuses to let the user continue until they answer. That cost is worth paying for exactly two things: a decision that must happen before anything else can (confirming a destructive action), and a short self-contained task that would be lost if the user navigated away. Everything else — a form with eight fields, a settings panel, a record the user needs to read the page to fill in — is being put in a modal because it was easier to build than a route.
The mechanics are where modals fail, and they fail silently for the people you are least likely to test with. Focus has to move into the dialog on open and return to the trigger on close. Escape has to dismiss anything non-destructive. Focus has to be trapped inside while it is open, the background has to be inert to screen readers, and the page behind must not scroll. None of this is visible in a mockup, which is why it is usually missing.
Modal vs drawer vs popover
A modal blocks the page because the decision cannot wait. A drawer slides in and keeps the page visible because the work needs that context. A popover is anchored to the control that opened it and holds something small. If the user needs to read the page to answer, you wanted a drawer.
In practice
A crypto exchange put its whole KYC form — 9 fields plus two uploads — in a modal. Users who got interrupted lost everything, because closing the modal cleared it. Completion sat at 46%. Moving it to a route with a URL per step, so a refresh or a returning session resumed where it left off, took completion to 71%. The fields did not change.
Where teams get it wrong
- Stacking a second modal on the first. If a dialog needs its own dialog, the flow needs a page.
- No escape route: no Escape key, no close button, backdrop click does nothing.
- Focus left on the page behind, so keyboard and screen-reader users are tabbing through content they cannot see.
- Long forms in a modal, where state is lost on dismiss and there is no URL to return to.
- Destructive confirmations that say “Are you sure?” without naming what will be deleted or whether it can be undone.
Learn more
You may ask
Frequently Asked Questions
When should you use a modal?
For a decision that must be answered before anything else continues, or a short task that would be lost on navigation. If the user needs to see the page behind to decide, use a drawer. If the task has more than a few fields, use a route.
What is the difference between a modal and a dialog?
In practice they are used interchangeably. Strictly, a dialog is the component and “modal” describes its behaviour — blocking interaction with everything behind it. A non-modal dialog leaves the rest of the page usable.
Should a modal close when you click outside it?
Yes for anything read-only or trivially repeatable, no for anything containing unsaved input or a destructive confirmation. An accidental backdrop click that discards ten minutes of typing is a bug regardless of what the spec said.
Related terms
All terms- Drawer (UI)A panel that slides in from an edge and leaves the page behind it visible — for work that needs the context it came from.
- PopoverA small overlay anchored to the control that opened it, holding content or actions without blocking the page.
- Form DesignDesigning the fields, sequence, validation and error handling of a form so people can finish it without stopping to think.
- AlertAn in-page message about something needing attention — persistent, placed where it applies, and gone only when the condition is.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us