The definitive guide to dialogs, popups and overlays

Having studied many different design systems and sat through many a sermon on the subject, I know there’s an unhelpful amount of variety in how people define and use dialogs, popups, overlays, modals, and lightboxes. The words get used interchangeably, which is a problem: if a team can’t agree on what a thing is, it has no hope of agreeing on how it should behave. Let’s iron out the terminology, then talk about when to use each.

Dialog vs. popup vs. overlay

Both dialog boxes (just ‘dialogs’) and popup windows (just ‘popups’) are containers that appear on top of the main content. Both are technically overlays, a broad term for any element that lays over the page. So an overlay is the category; a dialog and a popup are two species within it.

Some would argue a dialog is just a type of popup. Maybe once, but the dialog has evolved into its own distinct species and deserves to be treated as one. The difference lies in purpose, behaviour, and how each interacts with the user, and honouring that difference is what helps users know how to respond.

A dialog requires the user to act before they can carry on. It’s for tasks that need input or confirmation: an error that must be acknowledged, a preference that must be set, a destructive action that must be confirmed. A dialog:

• interrupts the user’s workflow until a specific action is taken;
• contains controls for that action, such as “Save changes” or “Cancel”;
• may carry fields or forms for the user to complete;
• has one clear purpose, and focuses attention on it.

A popup appears on top of the page to offer additional or secondary content (a tooltip, extra detail, a notification) without fully interrupting what the user is doing. A popup:

• appears over the content temporarily;
• may or may not require interaction;
• carries supplemental, not essential, information;
• can be dismissed by the user;
• should be designed to avoid disrupting the primary task.

In short: a dialog gathers input, confirmation, or acknowledgement; a popup offers information without demanding the user stop what they’re doing.

Modal vs. modeless

‘Modal’ means the user is held in a particular state, a mode, that can only be changed by acting. As the Nielsen Norman Group puts it, with a modal the rest of the page is disabled until the user interacts with the overlay. The opposite is ‘modeless’: no such fixed state, and the user is free to keep working with the page behind.

This follows directly from the definitions above. Because a dialog is meant to interrupt, it should be modal. Because a popup is meant not to interrupt, it should be modeless. If you find yourself building a modal popup or a modeless confirmation dialog, stop. You’ve probably mislabelled one of them.

Overlays and lightboxes

A common mistake is to call the darkened background behind a modal an ‘overlay’. It isn’t. The overlay is the content that appeared on top; when that overlay dims the page behind it, the dimming is called a lightbox.

Darkening the background does one useful thing: it tells the user, unambiguously, that their attention belongs to the overlay and not the page. That makes it a natural partner for a modal dialog and a poor fit for a popup. You can build a lightbox popup, but please don’t. A popup exists to avoid disrupting the primary task, and obscuring the whole page is about as disruptive as it gets.

When should an overlay trigger another overlay?

Now the awkward case: when should an overlay open another overlay on top of it?

As rarely as you can manage. Stacking overlays buries the user under layers of interrupted context, and each layer makes it harder to remember what they were originally doing. There’s really only one situation that justifies it: when dismissing the first overlay would cause an irreversible or costly loss, and you need to confirm intent.

The classic example is a form in a modal. The user has typed for two minutes, then clicks “Cancel” or the close icon. Silently throwing the work away is hostile, so a small confirmation dialog (“Discard your changes?”) is warranted on top of the first. The test is simple: stack a second overlay only when not doing so risks destroying the user’s work or triggering something they can’t undo. If the consequence is trivial, don’t stack; just let them close it.

Do you need a close icon on a modal?

This one divides people, so here is the principle I use. The “X” icon ambiguously closes a modal: the user dismisses it without explicitly responding to what it asked. The program has to assume an implicit answer, usually “cancel” or “abort”.

That’s fine when there’s nothing meaningful to respond to. It’s a problem when there is. Consider a modal asking the user to confirm deleting something. The real choices are “Delete” or “Cancel”, not “close”. An “X” lets the user dismiss the question without consciously choosing, and it lets them pay less attention to the content. Its absence forces them to read and choose.

So:

• Leave the “X” out when the modal has a real, consequential response. If the content is directly tied to a user action and it matters that they respond deliberately, don’t hand them an ambiguous escape hatch.
• Include the “X” when the modal has no actionable response, or the response doesn’t really matter, as with an informational message or a dismissible tip. Here, let people close it quickly and get back on task.

Get the words right and the behaviour follows. Once your team agrees that a dialog interrupts and a popup doesn’t, that a modal locks focus and a lightbox signals it, most of the design decisions stop being arguments and start being obvious.