When using an application the user must always be confident that he/she knows whether an action was successful or not and how to react in particular in the event of negative feedback.
Helpful feedback not only makes working with the application easier, but is also relevant for the application itself. If a user is not sure if an action was performed, multiple clicks on critical functions or frantic page reloads may result in inconsistent data or an unclear application status (e.g. multiple submissions of an order).
Thus, in addition to clear labeling of input fields, uniform and descriptive labeling of buttons and dialogs, and the use of tooltips or context-dependent help, system feedback also plays a critical role in the issue of user-friendliness.
5.3.1.Validation and feedback
After unsuccessful validation, e.g. of a mandatory field, this must be indicated with a red border and an additional icon (see section on feedback).
Depending on the application, it may, of course, be too much to inform the user every time an action has been performed successfully. As a rule of thumb, however, feedback should be provided for every basic "CRUD" operation, i.e., when creating, updating or deleting.
- Make sure the error message is descriptive, i.e. it must be clear to the user where the faulty data was entered.
- Error messages should be written in simple language, with the problem described precisely and a constructive solution offered.
- For both mandatory fields that have not been completed and incorrect data entry, the entry field that resulted in the error should be highlighted with a red frame and a corresponding icon.
- In addition to highlighting the entry field, a summary of the error should be provided at the beginning of the page.
- The software should provide a warning before potentially problematic actions are performed.
- Do not use cryptic error codes (e.g., "Error 13892"). Purely technical messages can also be provided for support purposes, but they should be clearly marked ("Please provide the following error code when contacting the service hotline"). In general, however, they should not be included in the user front end.
- The application should provide the user with appropriate information at all times about what is happening and the current status of the system.
In addition, this type of widget is also recommended because it can cover all dialog forms with a consistent interaction format:
- Simple two-value confirmation dialogs ("Yes, delete | Cancel")
- Three-value dialogs that are not browser-standard but that are often needed ("Yes | No | Cancel")
- Freely definable dialogs (for example, "Save | Save as...")
- Smaller complementary form components, selectors or filters can be accommodated elegantly in the same format
- Alerts and notifications
- Additional information or shorter help texts if, for example, a tooltip is insufficient
Every application must have clean error and exception handling on the user end as well, i.e. no default server or framework error pages should be displayed (for example, Java stack error pages, yellow .NET error pages or server code error pages).
Simple messages such as "The error has been recorded and we will look into it" should also be avoided. When a generic system error page cannot be avoided, at least one contact option should be provided as well as a non-critical link back to the application. Otherwise, the error may be displayed again, for example, if data is reposted or the back button is used.
Accordingly, planned downtimes should be announced in good time and, where possible, an informative outage page should be provided for this period (instead of the generic message "Service temporarily not available", which may lead to questions).