Summary: Established wisdom holds that good error messages are polite, precise, and constructive. The Web brings a few new guidelines: Make error messages clearly visible, reduce the work required to fix the problem, and educate users along the way.
The guidelines for creating effective error messages have been the same for 20 years. Good error message should include:
The Web's most common error message, 404, violates most of these guidelines. I recommend that you write a custom 404 error message instead of relying on the server's built-in "page not found" message. New Guidelines The complexity of Web pages has introduced the need for a guideline that wasn't required in the old days. With a DOS interface, users type a command and the error message is displayed on the next line of the TTY. In modern GUIs, users click a command and the error message is displayed in a big dialog box in the middle of the screen, and it doesn't go away until users acknowledge it. On the Web, however, error messages are often hidden as modest text on an overloaded page, leading to a new guideline: Error messages should be
I have frequently observed users make a mistake in a Web form, only to get exactly the same form back from the server with no visible indication of what went wrong. Often, a small error message appeared on the top of the page, but since users look at the page's actionable part first (i.e., the area with the form fields), they don't typically notice the error.
A related design flaw is to indicate an error state solely by turning the field label red. This violates one of the oldest and simplest rules for making technology accessible to users with disabilities: Never use color as the only encoding mechanism; always include redundant cues that color-blind users can see.
Two other guidelines can make the error situation less unpleasant for users:
Opportunity to Educate Users Finally, you probably already know Nielsen's First Law of Computer Documentation: people don't read it. This finding is even stronger for websites, where users truly shy away from any reading that is not essential to their task. Click on Help? Never.
Users read system documentation only when they are in trouble (that's the Second Law). They are particularly attentive when they want to recover from an error. Given this, you can use error messages as an educational resource to impart a small amount of knowledge to users. Of course, error messages should be brief and to the point, as should all Web content. However, error messages can still teach users a bit about how the system works and give them information they need to use it better. To further that end, the Web's underlying technology makes another guideline possible:
Consistency in interaction: make users learn once, consistency solidifies learning. Users will expect interaction elements to look, behave and be found in the same way throughout the site. If consistency is taken away, the user is forced to learn something again making your site that much harder to use. Making things inconsistent has value only when you want to get things noticed. With great power comes great responsibility: break only when it makes sense to do so.
Another means of getting things noticed is contrast. Use color to favor your design and communication strategy.
Go for convention. Semiotics (the study of creating meaning in communication) explains how conventions are established socially as a tacit agreement to decypher the code that communication builds upon. Straying from convention means your user will have difficulty in understanding your message, which could lead to drop offs.
For example: the color red is associated with danger and prohibition as established by social convention. Talking about the environment in red colors will confuse users and distract from the message trying to be communicated.
Strip down forms to the absolute bare minimum. If you have optional fields don't include them in a signup form, set them aside for a later step within your app. Each field you ask for runs the risk of making your visitors turn around and give up. Sign ups should be as frictionless as possible.
Repeat info if the user has already input it earlier with smart defaults. By no means should the user have to repeat themselves (unless it's a matter of security, like passwords or credit card numbers).
Fast loading and reacting times: help users with a loading icon or a task that'll keep their mind off of the loading screen. Feedback is important even while the screen is loading.
Use animations and transitions instead of showing changes instantly. As elements respond to a user's interactions, it might be easier for them to understand what just happened if the element transitions into view with time. Feedback is just as important when calling out a menu, bringing out a pop up, shifting and moving elements around, etc. A built in intentional delay in the form of an animation helps understand changes.
Extra padding instead of overcrowding elements.
Not necessarily UI but general advice: say no to stock photos. People smiling for no obvious reason undermine trust. Don't fake it. Also, stock photos give the impression that the photographic choice was made in a hurry and without much care. Bespoke photography and better, more realistic shots will connect with your users in a much more intimate way and create a feeling of trust and proximity.
https://www.nngroup.com/articles/ten-usability-heuristics/
Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
(Read full article on preventing user errors.)
Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
(Read full article on recognition vs. recall in UX.)
Flexibility and efficiency of use Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
Attractive Things Work Better
The aesthetic-usability effect refers to users’ tendency to perceive attractive products as more usable. People tend to believe that things that look better will work better — even if they aren’t actually more effective or efficient.