Design better modal window

A modal is a window that appears on top of a parent screen. It’s called ‘modal’ because it creates a mode that disables the parent screen but keeps it visible. Users must interact with the modal to return to the main screen.

Designers use modal windows to grab users’ attention. The information and actions in the modal window will have the entire user’s attention.

In this article, I want to review a few simple rules on how to design better modal windows.

1. Do not use modals to show error, wait, or success states

Designers often use modals to display error, loading and success states. But modals aren’t effective for this purpose because they block the parent screen:

Example of modal error message. Image by angularscript
  • Errors. Errors should be provided in the context of user input or as a separate screen. The first approach is preferable for input forms because it allows the user to read and understand errors in the context of their input. The second approach is preferable for global error messages such as no internet connection.
Inline validation. Image by Paul Macgregor
  • Loading. A modal window with a “Loading” message is a common solution for long operations. The use of the modal window for this case seems logical since the modal prevents the user from interacting with the screen. But it’s possible to find a more elegant solution — a better approach is to add a loading state right in the button that initiated the operation. It gives users a signal that they have to wait and prevents the user from clicking on the button again.
Adding loading state to the button. Image by Dribbble
  • Success. It’s always better to display the success message either inline or on a separate page.

A quick note on using modal windows for warning states: It’s possible to use modal windows when the user is about to take an action that has serious consequences and is difficult or impossible to reverse.

You might want to show a modal for irreversible operations. Image by tailwindui

2. Be careful with system-initiated modal windows

There are two types of modal windows—user-initiated and system-initiated.

  • The user-initiated modal appears on the screen when the user triggers it (i.e. taps on a button). Users know why the modal becomes visible.
  • The system-initiated modal interrupts a user’s current task. One of the biggest problems with this type of modal is that they interrupt users from whatever they were doing before the modal appeared. Users might not have a single idea why they see this modal.

On the web, designers tend to use system-initiated modals for promotion purposes. Such modals interrupt users and force them into doing a specific action. Uninvited modals often create a bad impression on users — people instinctively search for dismiss button. Users find such windows annoying and, in most cases, search for dismiss button.

Unexpected modal window with an email signup form. Image by RollingStone

The safest strategy is to restrict modals to only user-initiated actions or truly urgent messages. In all other cases, it’s possible to offer the same information/actions modeless (in the context of existing pages). By doing that, you give users the freedom to choose what content they want to consume or what actions they want to perform.

3. Ensure users understand what they need to do

People might wonder why the modal window appears (especially when it’s a system-initiated modal). Having a clear and descriptive message will explain the window’s usage. Users should be able to read the text and understand the message you’re trying to tell them and possible actions.

Try to match the primary button text with the modal window title because it makes it easier for users to understand the context. It’s recommended to use an explicit button label that states exactly what will happen when the user clicks it. For example, when you ask users to delete their files, instead of saying “Free your storage?” with actions “Yes” and “No,” you should ask “Do you want to delete your files?” with actions “Delete” and “Cancel.”

4. Prioritize content and functional elements in a modal window

Try to avoid situations when the content in a modal window requires a scrollbar. Scrolling makes sense on a long page, but the modal window contains only essential information and actions. That’s why when you find yourself adding a lot of content within a modal window, it’s time to stop and rethink your approach. In many cases, a regular page will better work for your users.

  • Ideally, you should put a sentence or two sentences in your modal windows.
  • Modal should not include more than two actions. A third action, such as “Learn more” which is typically used to navigate users away from the dialog, increases the risk of leaving the task unfinished.

5. Make a dismiss controls visible

Users should be able to leave the modal state whenever they want. Give users controls that allow closing the window. There are a few popular ways to achieve this:

  • Add explicit ‘Close’ / ’X’ button at the top right corner of the window.
  • Add explicit ‘Close’ / ’Cancel’ button to the bottom of the modal window.
  • Support click/tap outside the window to close the window.

6. Size the window appropriately

The size of modal window shouldn’t be too large — the modal window shouldn’t take the entire screen. Ideally, it shouldn’t take more than 25% of the screen for the overlay. If you cannot fit your content in a window and want to use a scroll bar, its’ probably better to create a separate page for that purpose.

7. Put a modal window in a focus

Here is how to give users a clear signal that the window is modal:

  • Put modal directly in the users’ line of sight. When a modal window isn’t visible in the user viewport, users will have to scroll to find it. The problem is that users may not recognize that they need to scroll, which will lead to confusion about the app being non-responsive.
  • Ensure that the modal window is visually distinct from the background page. Darkening the window’s background will help users understand that the modal window is located above the parent page.

8. Make content in a modal window accessible to keyboard users (for desktop)

Once the modal window is open, the keyboard focus needs to be moved to the window. The user should be able to navigate the functional controls in the window using a keyboard.

Allow clicking the Escape key to close the modal. When users open a modal window by accident, many of them will instinctively hit the Esc key to go back to the previous page.

9. Don’t use nested modals

Never design a modal window that triggers a modal window. When you follow such approach, you add visual complexity to your design.

Creating nested modals is a sure way to create bad UX. Image by Drupal | Modal-dialog