Your dialogs are too long
Twitter managed to get something right.
After studying how hundreds of people read UIs at Google, we learned a magical fact: no one really reads anything. If they do, you’re lucky if they get sixteen words in.
Contrary to popular belief, attention spans aren’t actually getting shorter. However, attention is tightly associated with tasks, and how much attention a user may want to dedicate to that task. This is partially why context switching is so expensive. Thankfully, we designers have only shoved long, verbose, dialogs into every task to get in the way of users as…
…much as possible. As a result, users reflexively mash buttons to close dialogs.
Not yet a dialog-less world
If users just close dialogs, why have them at all? Good point. If your UI doesn’t actually need a dialog, get rid of it. Chances are, no one will read it (fully) anyway. Informative dialogs that don’t result from a user gesture are the worst — make your information architecture self-explanatory or, at least, use some reasonable progressive disclosure.
That said, there are a few cases where dialogs do make sense:
- You urgently need to interrupt the user. The user might do something dangerous like visit an unsafe website.
- You require confirmation. The user might do something irreversible, like delete a file.
In these cases, it’s important that to (at least try to) get in the way of the user. And, in the case where someone does read a dialog, the words better count.
Tips for writing a dialog
Text in UIs should always be concise, clear, and comprehensible. This is particularly true for dialogs.
Here are some general tips for writing a dialog:
- Keep text as short as possible, without sacrificing grammar or comprehensibility. Aim for sixteen words or less. Write essential things only. If your dialog is highly technical or complicated, reconsider the dialog. In the worst case, aim for clarity over pure correctness.
- Use consistent language. Companies usually have language guidelines. Consistent language helps users understand what something means and banner-blindness over the cruft.
- Have two options. The more options, the more stressful a dialog can be. But, if you only have one option, why have a dialog at all? Strive for two options, and provide a good, mashable, default, if possible. The default should be the safer option. Use consistent wording in your options.
- Cut introductory phrases and wordy tenses. If your language guidelines allow it, cut introductory phrases such as “Would you like to…” and avoid more wordy tenses, like the present perfect tense in English. For example, choose “E-mail sent” over “Your e-mail has been sent.”
- Omit jargon. Use language everyone can understand. Most people don’t know what “clear the cache” means.
- Use progressive disclosure. Put the important information up front because users probably won’t read the whole thing, if at all. Start with the task description and/or warning first, and then follow with description.
- Don’t show an ad. Don’t show text that isn’t directly related to the task at hand. Otherwise, the dialog feels like an ad, and no one likes ads. If your entire intention is to show an ad, consider not doing that, or at least remember that somewhere, out there, someone will be annoyed with you.
Users with a task are like fast moving trains. A sign that says “STOP” is likely more useful than a sign that says “There is a person ahead. Are you sure you want to continue?”
If you don’t need a dialog, don’t show a dialog. If you need one, keep it quick and get out of the way.
hshieh.com | @chunggukpanda