A visitor opens a small window to check one detail. Suddenly the page behind it is unavailable, the close control is hard to find, and the message they were writing has disappeared. The interruption may look polished, yet the experience has become fragile. A useful dialog needs a reason to interrupt, an obvious way out, and a considered return to the work already underway.
First, ask whether a window is necessary
Before drawing an overlay, write down the decision it helps someone make. If the answer is merely “read a little more,” try placing that information beside the relevant choice. Delivery details can sit near a delivery selector. A short explanation can expand beneath its label. These arrangements let people keep the question and its answer in view together.
A dialog is worth considering when a short, separate decision genuinely needs attention before the current task continues. Longer explanations, comparisons and multi-step forms deserve a page of their own. During a design review, compare both arrangements using real-length content rather than an empty rectangle.
Give the interruption a clear purpose and exit
Use a heading that names the task and buttons that describe the result. “Discard message” is clearer than “Yes” when someone risks losing a draft. Keep secondary choices understandable rather than making the preferred action large and every alternative faint. Closing an invitation should feel ordinary, not like refusing a negotiation.
MDN distinguishes modal showModal(), which makes the background inert, from nonmodal show() or open. WAI’s modal pattern keeps focus inside, cycles Tab, closes with Escape and normally restores focus to the opener. It also calls for an accessible name and recommends a visible close button.
Our guide to keyboard navigation and visible focus provides the wider context for reviewing the journey around that interruption.
Protect the work already done
Imagine a fictional project enquiry. Someone has drafted a paragraph, opens a note about preparing a brief, then returns to their message. Decide before implementation what happens to that paragraph when the note closes, the main form closes, or the person tries to leave. Those are different events and need not erase the same information.
Prefer preserving a draft during the current interaction. If an exit will discard it, explain that consequence and offer a clear choice. Do not claim “saved” unless saving actually succeeded. When submission fails, keep the useful input and help the person recover, as discussed in form errors that help people continue.
Review the phone with its keyboard open
A centered desktop mockup cannot answer the mobile questions. Open the longest version on a small phone, activate the last field, and bring up the keyboard. Can the person see what they are editing and reach the next action without an awkward scroll hunt?
Review longer translated labels and enlarged text too. Decide which area should scroll, and check that the page does not jump to an unrelated position after closing. If a compact window becomes a cramped page inside a page, reconsider the format rather than shrinking everything to fit.
Test a whole journey, including an unfinished one
Start halfway down a page. Open the dialog, read its purpose, enter a realistic draft, inspect a supporting note, and return. Then leave without submitting and reopen it. Repeat on a phone and with a keyboard. Ask someone unfamiliar with the design to explain what they expect each exit to do before selecting it.
Record mismatches between that expectation and the result. A dependable dialog earns its place by helping someone complete a small task while leaving their wider journey intact.