Modal, Drawer or Page? A Decision Framework

When should something be a modal, a drawer, or a page?

Decide by how much context the task needs and whether it can be abandoned. A modal is for a short task that must be finished or cancelled now. A drawer is for a task that benefits from seeing what is behind it. A page is for anything substantial, linkable, or likely to be interrupted.

Most product teams do not decide this at all. The pattern gets chosen by whatever the component library made easiest, and six months later the settings live in a modal nobody can link to and the quick rename takes a full page load.

So here is the framework we use, with the research behind it and the keyboard obligations that come with the modal option.

What is the actual difference between these three?

Whether the rest of the interface stays usable. Nielsen Norman Group defines a modal dialog as one that appears on top of the main content and moves the system into a special mode requiring user interaction, disabling the main content until the user explicitly interacts with the dialog.

Non-modal dialogs, by contrast, do not disable the main content, and NNG notes that users can continue interacting with the interface while the dialog remains open. A drawer is usually this: a panel that slides in and leaves the page behind it alive.

A page is neither. It has a URL, it appears in history, it can be bookmarked and shared, and leaving it is a navigation rather than a dismissal. That last property is the one teams undervalue most.

What does the research say about modals?

That they work for forcing a decision and cost you attention. NNG recommends modal dialogs for preventing critical errors with irreversible consequences, requesting information essential to continuing a process, breaking complex workflows into simpler steps, and gathering information that significantly reduces user effort.

The drawbacks are named just as clearly. NNG says modals require immediate attention and interrupt the user's workflow, causing users to lose context and forget what they were doing. They also block the content in the background and create an extra goal, dismissing the dialog, which increases interaction cost.

Read those two lists together and the rule falls out. A modal is a tool for interruption, so use it when interruption is the point. Using one for a task the user chose to start wastes its only real power.

What is the three question test?

Ask whether the task is short, whether it needs the background, and whether it needs a URL. Three yes or no answers get you to the right pattern almost every time, and they are questions a designer and an engineer can both answer in a meeting.

If the task is short and does not need the background and does not need a URL, it is a modal. If it needs the background visible, it is a drawer. If it needs a URL, or it is long enough that someone might leave and come back, it is a page. When two answers conflict, the URL question wins.

The reason the URL question wins is that it is the only one you cannot retrofit cheaply. Changing a modal into a drawer is a styling job. Giving a modal a shareable address after the fact means rebuilding how state is stored, and by then there are support tickets asking for a link.

How do the three options compare?

Each one trades focus against context and permanence. This is the summary we keep coming back to when a team is arguing about a specific screen.

Property	Modal	Drawer	Page
Background usable	No, main content is disabled	Yes, main content stays live	Replaced entirely
Has a URL	Usually not	Usually not	Yes
Good task length	Seconds, one decision	Short, with reference to context	Minutes, or resumable
Can be abandoned safely	Should be cancellable without loss	Yes	Yes, with saved state
Best for	Confirming something irreversible	Editing an item while seeing the list	Settings, creation flows, anything linkable
Main risk	Lost context, extra dismissal cost	Hidden behind the panel, easy to stack	Feels heavy for a tiny change

Nothing in that table is absolute. It is a starting position that saves the argument happening from scratch on every ticket.

When is a drawer the right answer?

When the thing behind it is the reason you are there. Editing one row while the list stays visible, inspecting a record without losing your filters, reviewing a detail while comparing it to its neighbours: in all of these the background is reference material, not an obstacle.

Because a drawer does not disable the main content, it keeps the user oriented in a way a modal cannot. That is its whole advantage, and it disappears the moment the drawer covers most of the screen. A drawer wide enough to hide the list it came from is a modal with a slide animation.

Drawers also suit tasks where the user might want to act on something else next. Closing a drawer and opening another is cheap. A modal makes that same sequence feel like three separate interruptions. Our notes on filtering and search in product UI cover the list-and-detail pairing this usually sits inside.

When does it have to be a page?

Whenever someone would reasonably want to send a link. Settings, billing, a specific record, the second step of onboarding, an error state worth sharing with support: if the answer to how do I show this to my colleague is take a screenshot, you made the wrong choice.

Length is the second trigger. Anything with more than a handful of fields will be abandoned partway through by someone whose meeting started, and a page can hold that state while a modal usually throws it away. Our notes on designing wizard flows cover resumability properly.

The third trigger is complexity that needs its own hierarchy. Once a task needs sections, headings, and its own navigation, it has outgrown an overlay. Cramming it into one produces the scrolling modal, which is the clearest sign a pattern decision was never made.

What does a modal owe the keyboard?

A specific contract, and the ARIA Authoring Practices spell it out. On open, focus moves to an element inside the dialog. Tab moves focus to the next tabbable element inside the dialog, and from the last element it wraps to the first. Shift and Tab does the reverse. Escape closes the dialog.

On close, the practices say focus returns to the element that invoked the dialog, unless the invoking element no longer exists, in which case focus is set on another element that provides logical workflow. Skipping that return is the most common accessibility failure in custom modals, and it leaves keyboard users at the top of the document.

The platform now does most of this. MDN notes that showModal makes the rest of the page inert, places the dialog in the top layer, gives you a backdrop pseudo-element to obscure the content behind, and closes on Escape automatically, with Baseline widely available since March 2022. Our notes on the dialog element cover the implementation detail.

What about stacking?

Do not. A modal opened from a modal has no good exit, no clear focus story, and no way for a user to tell what dismissing will cancel. NNG's work on overlay overload describes overlays doubling user annoyance and often becoming buggy and working against each other.

That article gives a concrete picture of the cost: a user facing overlapping modals who had to dismiss multiple prompts before proceeding, left extremely frustrated. Each overlay in isolation looked reasonable to whoever shipped it.

The practical guard is a rule rather than a code review. One overlay at a time, and if a flow needs a second decision, it becomes a step inside the first overlay or it becomes a page. NNG's advice to audit by testing your top tasks is a good way to find out whether you already have this problem.

How do we apply this in practice?

We write the decision down once per project and then hold to it. The framework is only useful if it is the thing people reach for instead of their preference, and that requires it to live somewhere a new engineer will find it.

We default to a page more often than most teams expect. Overlays feel lighter to build and heavier to use, and a page that is slightly over-engineered for a small task ages better than a modal that quietly became the home of something important.

And we treat the keyboard contract as part of the component, not part of the feature. If focus return and Escape handling live in the shared dialog component, every future use gets them for free. If they live in each feature, half of them will be missing. Our notes on progressive disclosure cover the related question of how much to show at once.

What changes this framework in the next few years?

Better platform primitives, not new patterns. The three options have been stable for a long time because they map to three real situations. What keeps improving is how cheap it is to implement each one correctly, and the native dialog element has already removed most of the excuses for a broken modal.

Our bet is that the teams who get this right are not the ones with the most sophisticated components. They are the ones who decided, early and in writing, which situations get which pattern, and who notice when a modal starts growing a scrollbar.

If you are looking at a product where the pattern choices have drifted and nobody can link to anything, we are happy to go through it with you. Find us at phoenix.studio.