UX Musings: Why Do We Still Have Modals?

In User Experience, "modals" are interruptions which must be dealt with before proceeding to use the program further.

Because they are an interruption and must be dealt with before proceeding, they have a cost. The flow of the experience is broken. Focus is lost. Reading is interrupted. Half-words or even half-sentences are typed into nothingness.

The bottom line is: UX suffers every time a modal dialog comes up. Is it worth it?

Are Modals Ever Legitimate?

There are situations where a modal appears because the user requested it. For example, you wish to pay for something, and you are asked to confirm whether you really wish to charge the credit card you have on file. Because it stems from a user's intent, this is acceptable.

Another example of intent-based modal interfaces is the vim text editor, which has several modes (text editing, navigation, execution, etc). This is, of course, perfectly fine.

There are many other situations, however, where the user did NOT intend to request a modal, and one shows up anyway. What would be acceptable scenarios for this?

1. A security risk. Your operating system has detected an outgoing connection, a new background process about to be launched, or an unknown file to be executed, and wants to make sure that the user wishes to allow the action to proceed. Because the integrity of the system is at stake, and because the action is blocked until a decision is made, it can make sense to require an immediate decision from the user.
2. An irreversible action is about to occur. Emptying the trash, quitting without saving changes, etc. This can be interpreted as an intent-based modal, though it may not always be obvious to the user that they are about to perform an irreversible action, so the line between the two can be blurry.

When to Use Modals?

I am tempted to say: never.

Modals are so annoying, so costly, in terms of UX, that they are almost never worth it.

Here are the main offenders:

1. Applications claiming focus because of some background task completing, or failing to complete, or even worse: simply because the app finished starting up. This is insidious because we don't typically think of reclaiming focus as a modal interruption, but it is. I need to take an action to get back into the original application I was in. Thankfully, this does not happen on mobile devices, which (at least usually) do not allow background apps to yank focus. If you're a desktop application developer: never do this. Bounce your app icon, display a non-modal notification, or even ring a bell if you must, but do NOT yank focus unless you have a critical time-sensitive reason to do so.
2. Asking to login, or to connect a social network account. Is this necessary? If having an account is necessary to use the service, then you have no choice. But you should strive as much as possible to lower the barrier to entry, and one of the ways to do this is to offer a useful set of features to non-logged in users as well. Of course, a non-modal login feature is perfectly acceptable.
3. A website asking the user to download a native app. There is already a standardized template to show a header linking to the App Store. Why are you not using this non-modal way to promote your native application, rather than a modal? Seeing such poor taste in UX is not a strong endorsement of the ability to develop an enjoyable native app, and is therefore almost always going to result in a refusal.
4. A promotional offer. Is your business in such bad shape, that it would be preferable for you to stop incurring the cost of serving a user, than to keep the user around? If the answer is yes, then by all means, do drive your users away with modals. But really, avoid doing this as much as possible. Don't forget that promotional offers can be displayed very successfully in non-modal ways as well.
5. An ad. This is similar to promotional offers, but at least you are (hopefully) getting some revenue from the display of the ad (and from users occasionally clicking on the ads by mistake). That being said, you can also have non-modal ads. If your service is so indispensable that users are willing to put up with modal ads, then sure, you can try, but you better be paid handsomely because you are sacrificing users by subjecting them to this.

If you are a UX designer: please, weigh the cost of your modals. Do not blindly choose modals for any of the above scenarios.

Why Modals?

The question I am leading towards with the title of this post is:

Why did modals become so prevalent?

In today's data-driven world, where many companies roll out changes with A/B testing in order to measure their impact, it is easy to assume that if modals exist, it is because they must be beneficial. They result in increased revenue, or more user engagement, etc.

I am tempted to suggest an alternative explanation: while modals do provide real tangible benefits, their cost is not appropriately modeled and measured. The UX cost of modals is akin to death by a thousand paper cuts. It will take time for a user to become so annoyed by a service that they will ditch it. Typically, A/B tests are performed over the course of days or weeks. The fast pace of changes in today's services mandates this. This is likely not enough time for the thousandth paper cut to strike its killing blow.

Would it be possible to benefit from fast-paced A/B testing, but while also measuring the long-term negative impacts of bad UX? Perhaps.

What if a company took the policy of not ramping successful A/B tests to 100% too rapidly. What if a successful A/B test only allowed a team to ramp a new feature to 95% or 98% if it involved disruptive UX? In such modus operandi, the full 100% ramp could be limited to 6 months after the 98% ramp occurred and an analysis of user loss occurred. Then it may be more realistic to gauge the actual cost of the feature, and make a more informed, truly data-driven, decision.

Share your thoughts in the comments!

N.B.: The views in this article are my own and do not necessarily represent those of my employer.