Modals get a bad reputation because most of them deserve it. Interrupting a user to confirm they want to leave a page they haven’t edited, or dimming the screen to push a newsletter signup, are failure modes of the pattern. Used correctly, modals and dialogs are one of the most focused and efficient tools in an interface.
When to Use a Modal
The core question is: does this action require the user’s complete attention before they can continue?
That’s a narrow brief. Modals work well for three things. Destructive confirmations: “Delete this project? This can’t be undone.” The user must respond before proceeding. Short, bounded tasks: adding a tag, renaming a file, adjusting a single setting. Completing the task doesn’t require navigating away or consulting anything behind the overlay. Critical alerts: authentication failures, session timeouts, state changes that can’t be reversed.
Modals fail when the task is long, when the content is complex, or when the user needs to reference what’s sitting behind the overlay. A multi-step form spanning five screens doesn’t belong in a modal. A settings panel with thirty options doesn’t belong in a modal. If the user would need to scroll heavily, cross-reference, or close the dialog just to check something on the page below, a full page or a side panel serves better.
The test: if a user would reasonably want to shrink or move the dialog to see what’s behind it, the task isn’t a modal job.
Dialog vs. Modal: The Distinction That Matters
The terms are used interchangeably in most product discussions. They’re not the same.
A dialog is a UI container that appears above the page and requests input or attention. A modal dialog traps focus: the user cannot interact with anything behind the overlay until they respond. A non-modal dialog (a popover, a side panel, a flyout) allows continued background interaction.
The distinction matters because it changes the stakes. Modal dialogs are the most interruptive pattern in an interface. Overusing them trains users to dismiss without reading. A simple micro-interaction, like a shake on invalid input or a colour shift on success, can often replace a confirmation dialog entirely when the action is recoverable. Reserve the modal for when you genuinely need undivided attention.
Anatomy of a Well-Designed Dialog
Getting the mechanics right is straightforward once the use case is justified.
Title and body copy
The title should be a clear label or question, not an instruction dressed up as concern (“Are you sure?”). “Delete document” is clearer than “Are you sure you want to delete this document?” The body copy, if present, adds context the title can’t carry. Keep it to two sentences. If you need more, the problem is the use case, not the copy.
Actions
Use at most two buttons. Label them with verbs that describe the action, not affirmations: “Delete” and “Cancel” rather than “Yes” and “No”. The primary destructive action should be visually subordinate. Don’t make it red and prominent. Forms that people complete covers button labelling in detail, and the same principle applies here: the label is a contract with the user about what will happen.
Dismissal
Always provide a visible close mechanism: an X in the corner, a Cancel button, or both. Pressing Escape should dismiss the dialog. Clicking the backdrop is a convenience affordance, not a substitute for an accessible close control.
The Accessibility Layer
A modal dialog that isn’t keyboard-accessible isn’t a dialog. It’s a trap.
When a modal opens, focus must move to the first interactive element inside it, or to the dialog container itself. Tab keypresses should cycle only within the dialog (a focus trap), not through elements hidden behind the overlay. When the modal closes, focus returns to the element that triggered it. This is the correct behaviour, and it matters for screen-reader users, keyboard-only users, and any sighted user who tabs through forms.
Getting this wrong is one of the most common accessibility failures in production interfaces. Test with a keyboard before shipping. The ARIA role="dialog" and aria-modal="true" attributes signal the semantics to assistive technology; the focus management is still the developer’s responsibility.
Stacking context and portals
Modals should be rendered in a portal at the document root, outside the component tree that triggered them. Stacking context bugs, where a modal appears behind a sticky header or a peer overlay, almost always come from mounting the dialog to the triggering component rather than to document.body. The same applies to notifications and toasts, which share the same high-z stacking surface.
Sizing, Motion, and Mobile
Centre the dialog horizontally and vertically on the viewport, with a semi-transparent backdrop that signals the rest of the UI is temporarily inactive. Width should be proportional to content. A two-line confirmation doesn’t need a 700px container.
A modal that appears instantly feels abrupt. A 150–200ms ease-in with a small vertical offset grounds the overlay in physical space. The exit animation should be slightly faster: users waiting for it to disappear shouldn’t have to.
On mobile, full-screen or bottom-sheet patterns generally serve better than a centred overlay. A bottom sheet is thumb-accessible by default and avoids the scaling problems of a small floating card on a small screen. For product flows that involve multiple modal-style interruptions, like onboarding sequences, the mobile pattern deserves its own design pass. Don’t just shrink the desktop version.
Common Mistakes
Stacking modals. Opening a second modal from inside the first. Users lose orientation immediately. If the flow needs sequential steps, build a stepped dialog with a progress indicator, or reconsider whether a modal is the right container at all.
Using modals for errors. Showing an overlay to communicate a recoverable mistake. Inline validation belongs on the form. An empty state belongs on the page. Modals for errors add friction precisely when users need the least friction.
Auto-opening on page load. Newsletter capture, unsolicited onboarding walkthroughs, promotional overlays that fire before the user has done anything: these are the fastest way to train users that your dialogs don’t deserve attention. They’ll click out before reading, and that habit carries to the dialogs that matter.
Vague confirmation copy. “Are you sure?” is not a useful message. State the consequence plainly. If the action is permanent, say so.
How Strynal Approaches Modals and Dialogs
At Strynal, the question of whether something should be a modal is asked during information architecture, not during component build. By the time a dialog appears in Figma, the use case has already been pressure-tested against the alternatives.
When the answer is yes, we build dialogs with keyboard accessibility and focus management from the start. We also design every state: loading, error, success, and empty. The close-button position, the backdrop behaviour, the animation timing, each is a deliberate call, not a library default left unreviewed.
Our UI/UX service covers the full range of component and interaction design, from individual patterns like dialogs to complete design systems. If your product overuses modals, or if your current dialogs feel clunky at small viewports, get in touch and we can review what’s there.