It is impossible to use any modern digital product and not come across a modal. If we try to save a file on our desktop or laptop, we’re quite likely to encounter a modal that will ask us to define the file name and location. In certain situations where a mobile application is asking for audio or video permission, we’re prompted to grant or deny this access request via a modal.
With modals being nearly ubiquitous, you’ll likely be tasked with implementing them at some point. Let’s explore why modals are so prevalent and whether they’re the best option to achieve your goals so you’re better equipped to create modals that won’t harm users’ experiences.
Let’s first define a modal as simply as possible: a modal is a window that sits on top of the main application. UX designers use modals to display additional actionable content, to assist the user to accomplish their desired task.
On a desktop or laptop, clicking on the number of reactions on a social media post opens up a list of users who reacted to that post in a modal. The user can then use this information to perform additional tasks beyond the scope of the initial content. For instance, the user can discover new users or conversations to follow.
An even more common use of modals is the settings page of various desktop applications. If we try to print a file, we’re bound to be faced with a modal because simply clicking Print is not always enough instruction to make the print happen.
There are many variables that have to be defined to print: paper size, color, orientation, number of copies, and so on. To speed things up, most print settings modals have a Default setting, and usually, we can just click print without tinkering too much.
Nielsen Norman Group aggregated the different types of modals into classifiable groups, as follows:
Even though Nielsen Norman Group helps us understand the different types of modals, we need to explore a little more of their use case–specific implementation and how they vary.
A dialog is a system message, and a dialog box is a type of modal that conveys this message to the user, such as an alert or confirmation. In some cases, this can also be a fullscreen message to grab the user’s attention. Furthermore, dialog boxes can be classified into two types. They are as follows:
A modal dialog box is a blocking object. We must close this dialog box to proceed to any other tasks.
An example of this is a confirmation dialog box. For instance, if we try to close an application with unsaved work, it prompts us to either save or not save before exiting. The modal blocks us from exiting the application, but it also reduces user frustration in case the unsaved work was because of user error.
A modeless dialog box is a nonblocking object. We can interact with other user interface elements that are not part of the dialog box without closing the dialog box. An example of this is a search box, which we can keep open on the side and perform queries when needed.
We can find examples of modeless dialogs in older versions of Microsoft Office products; the latest versions have moved these to the sidebar instead of modeless dialog boxes. Another example of a modeless dialog box is the New Message prompt that opens when we press the Compose button in Gmail.
Overlays are modals that usually contain noncritical information. Overlays can be of several types: pop-up, lightbox, or fullscreen.
These usually appear automatically without any user action, such as an opt-in form on a website. They tend to be skippable but keep appearing repeatedly. They either disappear on their own or require some user action to close the popup. In order to prevent bad UX, we have to keep the following points in mind when implementing pop-ups:
Lightboxes make the content of the background less prominent such that the overlay content is the primary focus. We discovered this in the Nielsen Norman Group classification. You often see the lightbox effect with pop-ups like the one above to focus your attention on one area of the screen.
A fullscreen modal is one in which the content occupies the entire screen and the content beneath the modal is completely hidden. These types of modals are particularly useful when we want the user’s undivided attention and we don’t want them to be distracted by the content lying beneath.
Where would a fullscreen modal make sense? For instance, we might implement a fullscreen modal when we want the user to select their location on a map. This ensures good accuracy because the user is solely focused on the map.
The following is an example of a fullscreen pop-up that shows when a user moves the cursor outside the body area of the website (i.e., the user is trying to exit the website).
From a user perspective, modals are frustrating when they disrupt the task at hand. Modals by their inherent nature are disruptive because they sit on top of the main application. However, modals are most annoying in the following scenarios:
The main consideration when implementing a modal becomes: do we want the modal to be blocking or nonblocking?
If the modal presents something that is optional and the user can skip it, then it makes sense to have it be nonblocking, such as an opt-in form for a newsletter. If the modal presents some critical information such as account verification, then it makes sense to be a blocking modal with the background dimmed.
Let’s look at some examples of modal types, their pitfalls, and how and when to use them well.
One crucial dilemma we faced when implementing modals is the concept of nested modals in web and desktop applications. In general, we should avoid using a modal within another modal at all costs; otherwise, our application gets confusing and complicated like a house of mirrors.
The only outlier where a modal within a modal can be acceptable is when we’re implementing a double confirmation for critical actions such as deletion or anything that requires password confirmation.
So then, what can we do when we need to show additional contextual information? There are three options.
Something that’s not given too much thought is the sizing and placement of modals. Good modals will have ample whitespace and will be a delight to look at due to their excellent proportions and the way they’re presented using visual hierarchy and spacing.
However, the most important aspect is making sure that the modal is in the user’s focus. If it’s a lightbox modal where the background is dimmed, then focus is quite easily achieved.
If we implement modals where the background is still visible, then we have to be mindful of the placement so that the modal does not create visual clutter. It is also generally a good idea to add motion to small modals that appear in the UI without the background dimming, to ensure that it catches the user’s attention.
A further step to make a modal design even more inclusive is to make them accessible to keyboard users and screen readers. You can achieve this by making the modal objects switchable as the selected item using the tab key.
Screen readers should also be able to hear out loud the appropriate labels for each object. When designing components, we already define an intermediate state known as a hover or select state. This intermediate state is an important cue for our users to understand where they are performing their actions.
It is also a good idea to save the user’s last active state so that the user can pick up where they left off when reaccessing a modal.
Another thing to consider is the scalability of modals. A modal cannot contain an infinite amount of content. Therefore, similar to UI screens and pages, modals themselves can have pagination or steps where we can click Next to move on to the next step.
In such cases, it’s vital that we show a progress bar so the user expectations are properly managed and they have the context of where they are in the process. The user’s last entered data should be autosaved to avoid frustration.
Since we know modals are disruptive and they divert the user’s attention, we should try to use more subtle UI for use cases such as user onboarding and feature announcements. Tooltips are more appropriate for drawing attention to features and guiding users, instead of modals.
And lastly, I have several miscellaneous tips for getting your modals on the right track. We have to be attentive when implementing modals, or we’ll lose users permanently:
To implement modals that don’t hurt UX, we must maintain good modal anatomy. A modal must not interrupt key user interactions and should be properly timed. The most important aspect of the modal design is deciding when a modal is appropriate to use, so be sure to keep this advice in mind.
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Call it what it is. Product designers and UX designers have unique roles, even if their titles often get swapped. In this blog, know the difference and own your expertise.
Search bars are more than icons and inputs — they can be a retention magnet or a churn trigger. Sharing my tried-and-tested search bar design principles in this blog!
Are your colors clashing or cohesive? In this blog, I talk about clashing colors, their impact, and how you strike the perfect balance with colors in your designs.
You know that good design is all in the details. And nicely used kerning impacts readability, user flow, and brand professionalism in your UI design — more on that in this blog.
Learn more →
