Humans tend to make mistakes. Errors occur when people interact with user interfaces. This sometimes happens because users make mistakes. Sometimes errors occur in the application itself. Regardless of the cause, errors and their handling have a huge impact on UX. Incorrect error handling, coupled with useless error messages, can cause a backlash from the user, which can subsequently lead to the user's refusal to use your application.

In this article, we'll explore how you can optimize your application design to prevent custom errors and how to create effective error messages when errors occur regardless of what the user enters. We'll also look at how a well-handled error can turn failure into admiration. Adobe has introduced a new design and engineering application Experience Design (Adobe XD), which allows you to design interactive projects and error states. You can download and try Adobe XD for free.

What is an error state?

An error state is a screen that is shown to the user when something went wrong. This is an example of a situation where the user does something other than the desired state. Since errors can occur in unexpected combinations, these states can include very different problems, from incompatible user operations (for example, incorrect data entry) to the inability of the application to connect to the server or even the inability to process the user request.

Error screens

Every mistake, regardless of its cause, becomes a stumbling block for the user on the way to progress through the UX. Fortunately, a well-formed error can reduce the unpleasant effect.

Prevention is better than cure

If you are building an application, you need to understand what basic user interactions with the application can lead to an error. For example, it is usually very difficult to fill out a form correctly on the first try, or it is impossible to sync data correctly if the device has a bad network connection. You should keep these points in mind to minimize the possibility of errors. In other words, it is better to prevent the possibility of error by showing tips, using constraints, and flexibility.

For example, if you give people the ability to search and reserve hotels, why leave dates available in the past and display an error if the user selects such a date?

As shown in the example of Booking.com, you can simply use a date picker, which only allows users to select today's date and future dates. This will prompt users to select only valid dates.

Date picker in Boocking.com app. The full month is displayed, but dates in the past are not available.

Form validation error screen

Form is communication. Like any communication, it must be a serial communication between two parties - the user and your application. Validation plays a major role in this communication. Form validation is designed to guide users through complexities, errors, and misunderstandings. When properly validated, this communication becomes clear and understandable. In general, good form validation has four important elements:

• Correct time to report errors (or successful completion)
• The correct place for the validation message
• Correct message color
• Understandable language of the message

Correct time (string validation)

Form validation is inevitable and is a logical part of user input (since user input can be error prone). Of course, states that can cause an error should be minimized, but error validation cannot be removed. So, the most important question is: "How can you make it easier for the user to recover from an error?"

Users do not like the process of filling out the form, especially when they receive an error notification at the end. It is especially frustrating to receive error messages in multiple fields after filling out a long form. And the most annoying thing is the lack of clarity about what mistakes you made and where.

Validation should immediately inform the user about the correctness of this answer immediately after the user has entered the data. The main principle of good validation is: “Talk to users! Tell them what's wrong! ” and string validation in real time informs users about the correctness of the entered data. This approach allows users to quickly fix errors and not wait for errors to be displayed after clicking the submit button.

However, you should avoid validating every keystroke because in most cases, you will not be able to verify the data before the user has finished typing their response. Forms that validate the value immediately during the typing process begin to annoy the user as soon as he begins to enter data.

Google Forms displays an email error even when you haven't finished typing yet.

On the other hand, forms that validate after data entry do not promptly inform the user about the error.

Apple Store validation takes place after data entry.

Mikhail Konzhevich in his article “String Validation in Forms - Creating Experience! researched different validation strategies and proposed a hybrid strategy: early reward, late punishment.

Hybrid - early reward, late punishment - approach

The right place

User orientation is another important tool. When you're wondering where to go for your validation message, follow this tip: Always place your message in the context of an action. If you want to tell the user about an error in a specific field, show it next to it. It is best to place quick validation to the right of the input field, or below it.

Form errors in real time.

Correct color (intuitive design)

Color is one of the best tools to use when creating validation. Since it works on an intuitive level, red for error, yellow for warning and green to indicate success is particularly powerful. But, make sure the colors are well received by the users. This is a critical aspect of good visual design.

The error text must be understandable and clearly stand out against the background of the application.

Clear message

A typical error message might read “email is invalid”, without explaining to the user why the email is incorrect. (Typography? Email busy by another user?) Straightforward instructions or guidelines can do things differently. You can see in an example how the form informs the user that his email is already taken. Also, several suggestions appear (login or password recovery).

So, now is the time to display the error page in order to show that something went wrong. As an example, let's imagine a situation where the connection is dropped and the user is on the screen, which is the only one available. You should use this opportunity to let people know what's going on and provide a quick help model - your message should be a helping hand for users. Therefore, you should never show the following:

• Fatal error message. Messages that speak of an internal error in the application code or contain text such as “an error type 2 has occurred” are cryptic and scary.

An error message written by the developer for the developer.

• Dead end error. Simply because such messages do not provide any useful information to the user.

The error screen on Spotify reads “An error has occurred” and does not contain any options or steps to resolve the issue.

• An undefined error message. Such a screen (in the example below) gives the user as much information as the previous one. Users have no idea what this means or what to do about it.

The Buffer app contains a nice error message, but it doesn't convey any information to the user.

Don't scare the user with mistakes. Also, don't try to introduce the user to the technical details of the problem. Speak about the error in simple and understandable language. To do this, try not to use technical jargon and express your thoughts in the language of the user.

Make your messages readable and helpful - errors should be polite, clear, and didactic, and include the following information:

• What went wrong and why (possibly).
• What the user should do to fix the error.

The Remote app explains why users can't see anything and suggests a solution.

Include humor and images in error messages

Error reporting is a great opportunity to use icons and illustrations because people are more receptive to visual information than just text. But you can go even further and add images to your application, which will be useful for users. This will personalize your application and soften your message.

Azendoo uses illustration and humor to inspire the user to solve a problem.

Humor prolongs life. A little humor never hurts, and will help allay the confusion of a mistake. You can find tons of examples of funny posts at Littlebigdetails. Here are some of my favorites:

• Basecamp: On form validation error, the hero on the left makes a surprised expression.

• A slightly cheeky error message is displayed when trying to enter too many dots when creating a new Gmail account.

However, be careful with humor because it may not always be appropriate in your bug report; it depends on the severity of the error. For example, humor works well for a simple validation problem like a 404 error (page not found). But when a user spends a certain amount of time looking at a page that says "Oh!" - it looks out of place.

A comprehensive checklist for the perfect error page

Good error pages are a helping hand for users and must meet the following six criteria:

1. The error message appears dynamically, immediately after the error is detected. It should inform the user of the problem.
2. Be safe for the entered data. Your application should not break, delete or cancel what the user entered or downloaded when the error was detected.
3. Talk to the user in the same language. The message should provide a clear understanding of what went wrong and why; what does the user need to do in order to fix the error?
4. Don't shock or confuse users. (The message should not be too provocative).
5. Don't lose control of the system. (If the problem is not critical, the user should be able to with the rest of the application).
6. Use a sense of humor to mitigate the problem.

Solutions for the most common mistakes

404 error (page not found)

The main goal of a 404 page is to redirect your user to the page they were looking for as soon as possible. Your 404 page should offer several key links for the user to go to. The safest option is to have a link to the “home page” of the site on a 404 page. Also, you can place a “report a problem” so that the user will notify you that the page is not working. But make sure that the transition to the home page is a more explicit transition and stands out more visually.

Login problem

The login form screen is often minimalistic and contains a field for entering a username and a field for a password. But minimalism doesn't equal simplicity. There are many reasons why a user might get stuck at the login screen. The main rule of the login page is not to force the user to guess.

Let's take a look at solutions to the most common problems using examples from MailChimp, which does a great job on error reporting.

• The user has forgotten their name on the site. If you find a similar error, you should offer a link where the user can fix it. Tell the user where he can get it (for example: “check your mail, we sent you a letter”) or provide a link to restore the name on the site.

Users make many attempts to log into the site using the wrong password. To prevent such server attacks, user accounts are blocked after too frequent unsuccessful attempts. This is a common security practice, but the user must be warned before their account is locked.

Credit card rejection

A credit card can be declined for several reasons: a data formatting error (typo or missing data), or the card can be declined because it is expired or stolen. Gabriel Tomescu, in his article “Anatomy of a Credit Card Shape,” suggested the following strategy for both errors:

For the first problem, you should follow the standard string validation and visual error indication:

However, when a credit card is rejected by a payment system for some reason, it usually looks like a theft. You need clear data from the user. And even after that, you still need to notify the user of what happened; the error message should be very clear.

Connection problem

Internet connection is not available everywhere and offline support should be a key aspect in the life of any modern application. When the connection drops, you need to think carefully about the offline UX. Users should be able to interact with as much of your application as possible. This means the app must cache content for a good offline UX.

Tags:,,,

There is nothing more tedious than filling out a poorly written lead form on a landing page. Remember how many times you had to re-fill all the fields due to the fact that the password you invented did not fit the system according to certain criteria, no one tried to notify you in advance.

Keep in mind that lead form optimization is a key component of the conversion optimization process, and the focus here should be on field validation.

What is lead form validation?

Lead form validation is a technical process during which the system checks the correctness of the data entered by the user. If a person made a mistake when filling out the form (for example, he indicated the data in the wrong format), then the system will point him to this error (or simply to its presence) and offer to correct it. If the user entered all the data correctly, then no additional messages will appear (or a check mark will appear next to the field), and he will proceed to the next stage of registration.

For example, Twitter will not allow you to proceed to the next registration step if you enter your email address in the wrong format:

When you enter the email address in the format that the system needs, a checkmark will appear next to the field, indicating that the format of the entered data is correct:

The essence of validation is to ensure that users enter data in the format required by the system (for example, the mail address must comply with the standard [email protected], but, for example, the password must contain at least 7 characters).

There are two main types of form validation.

Analysis of site validation errors

Finally, there was some free time between an endless series of orders, and I decided to start my blog. Let's try to improve it in terms of validation. Below in the article I will tell you what validation of a site, html and css code is, why it is needed and how to bring a site to standards using a specific example.

What is site validation?

In simple words, it is a test for compliance with standards. So that any browser can display your site correctly. The validity of the site does not have a big impact on the promotion, but it certainly won't be worse.

A specific example of passing validation for a website page

Let's take the first page we come across on my site - Base64 encoding and decoding in Java 8. Let's fill in the page address into the validator and see the result:

Errors found while checking this document as HTML 4.01 Transitional! Result: 105 Errors, 67 warning (s) Yes, the picture is unpleasant: more than a hundred errors and 67 warnings - how do search engines index my blog and people visit? But let's not be upset, but we will learn to pass validation, to correct mistakes. So the first warning:

Unable to Determine Parse Mode! The validator can process documents either as XML (for document types such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For this document, the information available was not sufficient to determine the parsing mode unambiguously, because: the MIME Media Type (text / html) can be used for XML or SGML document types No known Document Type could be detected No XML declaration (e.g) could be found at the beginning of the document. No XML namespace (e.g ) could be found at the root of the document. As a default, the validator is falling back to SGML mode. Warning No DOCTYPE found! Checking with default HTML 4.01 Transitional Document Type. No DOCTYPE Declaration could be found or recognized in this document. This generally means that the document is not declaring its Document Type at the top. It can also mean that the DOCTYPE declaration contains a spelling error, or that it is not using the correct syntax. The document was checked using a default "fallback" Document Type Definition that closely resembles “HTML 4.01 Transitional”. This is the same. And the fix is ​​simple: at the very beginning of the page, add the tag:

We check that we have succeeded and see that with this one tag we have removed 105 errors and 3 warnings! Now we only have 64 warnings left. We begin to disassemble them one by one.

Warning: The type attribute for the style element is not needed and should be omitted. From line 5, column 1; to line 5, column 23 / x-icon "> ↩