User Tools
design:error_messages
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| design:error_messages [2021/02/02 15:41] – 10.91.120.28 | design:error_messages [2021/06/25 10:09] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== How To Write Effective Error Messages ====== | ||
| + | |||
| + | ===== Error Messages Should Be Clearly Visible ===== | ||
| + | |||
| + | * If a user makes a mistake i.e. an error occurs, they should get feedback on screen informing them of this. | ||
| + | * A good example of this is saying in an email that you'll attach a file but don't. | ||
| + | * Gmail now reminds you of this before you hit send. | ||
| + | * The error message should visually stand out on the screen - ensure contrast | ||
| + | * Try to use a different color to the rest of your color palette. | ||
| + | * Never just rely on color to convey a message to ensure accessibility for people with color-blindness. | ||
| + | * Use icons and other UI elements in addition to color. | ||
| + | |||
| + | ===== Error Messages Should Have Human Readable Text Without Code Or Jargon ===== | ||
| + | |||
| + | * Don't use the default code output as an error message as this will be very hard to decipher for the user. | ||
| + | * This type of detail belongs in the logs. | ||
| + | |||
| + | ===== Error Messages Should Be Polite In Tone ===== | ||
| + | |||
| + | * Don't use terminology that blames the user for making a mistake | ||
| + | * Avoid: | ||
| + | * "you did.." | ||
| + | * "your action caused.." | ||
| + | * "you have entered the incorrect information" | ||
| + | * upper case and ! at the end of a sentence - it seems like you're shouting at the user! | ||
| + | * Blaming the user is only going to cause more frustration | ||
| + | * Don't see the user as the problem. | ||
| + | * We cannot know how every type of user will interact with what we design so errors are bound to occur. | ||
| + | |||
| + | ===== Error Messages Should Have Helpful Text ===== | ||
| + | |||
| + | * You need to tell the user: | ||
| + | * What happened | ||
| + | * Why it happened | ||
| + | * what the user can do to resolve the issue | ||
| + | * Guide the user on how they can fix the error. | ||
| + | * If possible, determine what the correction action is a and let users pick from a small list. | ||
| + | * Users should be able to understand what error message buttons (delete, cancel) do by simply reading their labels. | ||
| + | * You shouldn' | ||
| + | |||
| + | ===== Error Messages Should Be Short And To The Point ===== | ||
| + | |||
| + | * Most users will scan a page to find exactly what they' | ||
| + | * As a result, the more text on screen, the harder it is to scan, and the less likely it is for the user to read the error message. | ||
| + | * Remove any unnecessary detail. | ||
| + | * Use progressive disclosure to provide information on how to troubleshoot a problem if it's required. | ||
| + | * Don't put all of this in the error message box. | ||
| + | |||
| + | ===== Make Sure You Preserve The User's Work ===== | ||
| + | |||
| + | * When a user is interrupted to deal with an error, it stops their flow and prevents them from completing their task. | ||
| + | * Make it easy to resolve the issue so they can go back to their work. | ||
| + | * Let users correct where they went wrong rather than starting from scratch each time | ||
| + | |||
| + | ===== Modal Or No Modal? ===== | ||
| + | |||
| + | When designing an error message ask yourself: | ||
| + | |||
| + | //Does the user need to be interrupted to read this message?// | ||
| + | |||
| + | If so consider putting the error in a modal. | ||
| + | |||
| + | If not, don't use a modal. | ||
| + | |||
Page Tools
