Overlays & feedback

This is the most important warning here. When a client says "add a popup", do not write it down as-is — ask: ① a new window? ② a modal over the screen? ③ a notice banner at the top? Those three differ completely in build, cost and experience.

"Show a modal" strictly means "show a dialog in a modal way". The essence of a modal is not a pretty box — it is blocking what is behind. Use it only when a response is genuinely required to continue.

Modal or non-modal is a product decision, not a matter of taste. Interrupt the flow → modal. Just for reference → non-modal. Overuse non-modal and the screen turns into noise.

A dialog can be either modal or non-modal. So: "dialog = the thing", "modal = the way that thing blocks what is behind". Grasp that and all three words settle.

The browser's built-in alert() cannot be styled at all and freezes the whole page. Matching the mockup requires a custom alert, and that is separate work. Draw the mockup and then say "just use the browser default" and you will get a screen that does not match it.

Label the buttons only "OK/Cancel" and people lose track of what they are agreeing to. The rule is to write the action itself — "Delete" / "Keep". Destructive buttons go red.

Korean practice says "딤 처리", Material Design says "scrim", and code says "backdrop". Always write down whether pressing it closes the thing — leaving that out is a very common source of QA tickets.

This is the test for whether a modal was built properly. Without it, keyboard and screen-reader users get thrown out to invisible elements behind the modal and lose their place. Pressing Tab during review reveals it instantly.

On a phone a bottom sheet is almost always better than a centred modal. Going modal on desktop and bottom sheet on mobile is common — just remember that means building two of them, and put it in the schedule.

An iOS-specific term. Android and the web build the same thing as a bottom sheet. When an iPhone user says "like an action sheet", this shape is what they mean.

Put a button or link inside and it is no longer a tooltip — it is a popover. Also, there is no hover on mobile, so anything living only in a tooltip is invisible to phone users. Never put important information in one.

There is exactly one test against a tooltip — can you operate what is inside. Operable → popover. Read-only → tooltip. Popovers open on click; tooltips open on hover.

Only for light feedback that does not interrupt. The content must be safe to miss. Never use a toast for error messages — people can scroll past them and have no way to see them again.

A Material Design term; in practice people use it interchangeably with toast. If you must split them: with a button it is a snackbar, without it is a toast. Adding undo lets you drop the confirm dialog before deleting, which makes the flow much smoother.

The difference from a toast is persistence. Anything that has to stay until the person does something — "scheduled maintenance", "payment method expiring" — belongs in a banner. Decide whether it gets a close button too.

Form errors belong inline, not in a toast. Show "Please fill in the required fields" as a toast and nobody knows which field. Errors always attach to the place that has the problem.

Progress bar when you know the progress, spinner only when you do not. A spinner turning for more than three seconds reads as "has it frozen?", so pair it with a skeleton or a message.

It does not make anything faster, but the wait feels shorter, because people can see how the screen will fill in. It is effectively standard now, so draw the loading state into the mockup as well.

Only for tasks with a known end, like file uploads. Filling a fake bar when you do not know the progress destroys trust. Multi-step forms sometimes pair it with a step indicator.

The most commonly forgotten screen in agency projects. Leave it out of the mockup and the developer invents one, or you get a blank page. An empty screen must carry two things: ① why it is empty ② what to do about it. Put it in the quote and the schedule.

Like the empty state, frequently missing from mockups. A good error screen is not an apology; it offers the next action — retry, go home, contact us. Never show people the technical string you would hand a developer ("500 Internal Server Error").

Never hold it on purpose. People sometimes keep it up for three seconds for "brand exposure" — to a user that is simply a slow app. Move on the instant it is ready.

Memorise it as one sentence: "A dialog (the thing) shown in a modal way (the manner); the simplest kind, which only informs, is an alert (the type); and popup is the sloppy word for all of it."