Interfaces: how to tell the user if “Oops, something went wrong”
Here you will not see a single line of code. We will talk about ordinary people - about our users, more precisely, how to tell them if some unforeseen situation has arisen in the system.
The article is based on the report by Antonina Hisametdinova with Heisenbug 2017 Moscow, which is engaged in designing user interfaces in Pavlov Dog .
In addition, Medium has a series of articles on the Error Design Guide . The cycle has not yet been completed, but it gives a more complete and coherent picture on the topic of the article.
Time after time we design the main scenarios for a wide variety of services. In the case of an online store, the main one will be:
')
A person visits the site, selects a product, orders its delivery; pays and receives an order.
We are so focused on the main scenarios that we forget one very important thing: there are alternative scenarios and thousands of ways how the main scenario can be interrupted.
All these are erroneous scenarios that arise when something goes wrong.
Food teams often do not pay enough attention to such scenarios. For example, a very typical story: “Something went wrong. We have problems, so just close this message. ”
Another example: “We have a mistake. Please try again later:
And another category of errors - my favorite: unknown errors.
It is very difficult to justify the need for business to work out erroneous scenarios. Why do we have to go back and fix something when we have new features ahead? But I have four iron arguments that will help demonstrate to your product owner or business the need for such work.
The slide shows some numbers from one of our clients. This is the number of user calls to tech support per month. Calls are related to problems of a certain kind:
Please note that 400 people a month call simply because they cannot enter or correctly enter the login / password in the appropriate form on the site.
If the error message is compiled correctly, it returns it to the main scenario, even if a session break occurred.
You may not even need to create onboarding or some educational videos, the development of which, by the way, is also worth a lot of money.
This is the last but not least argument.
In general, the topic of human-technology trust has been explored for quite some time. Now we trust enough technology. For example, we will never double-check whether the messenger sent a message to the addressee, or how the calculator added or multiplied three-digit numbers (unfortunately, however, not all services can boast such a level of trust as calculators).
We trust our lives to dozens of different types of software, flying in airplanes. But this trust is very easy to destroy. Even the smallest mistake can make it. And such mistakes happen in both small and very large companies.
I mentioned a “good error message” several times. It is time to talk about what it means. And for a start we will understand, because of what errors arise in principle.
But that's not all. There is also:
This is not a classification attempt. In fact, the types of errors are far from six, there may be hundreds or even more. But in the context of interface design, these errors are the most significant.
Let's start with the situation when your service is completely unavailable.
Unfortunately, such errors can occur in any services, from online games to complex stock professional tools.
Good question: what to do in such a situation?
While the developers are quickly fixing some tools, the unfortunate users receive strange error messages and get your technical support, write unpleasant posts on Twitter:
Let's look at the messages that are displayed at this point:
They are quite simple and some of them even honestly apologize. But users still feel uncomfortable and try to understand what is the matter; repeat the entrance is not in 15 minutes; poke anywhere.
How to help them?
If you do not know what the consequences of a global failure are, just go to tech support. Because at this moment the guys there are cracking in full. And they will be happy to share this pain with you.
Many in such situations are limited to the message: yes, we have a problem and we will fix it soon:
But “soon” is when?
The user does not need to know when you will correct everything, up to a minute. But they need to understand some significant time points, for example, 15 minutes, one hour, five hours or even a day. This will help them navigate in space and plan the management of their money.
Another reasonable question (in terms of financial services): do the cards work?
And a good error message will be able to respond to it. Even if the cards do not work, it's better to say this anyway, because this is very important information.
Another story - there must be a salary or transfer; and when will the money come?
It seems to be nothing critical, but when a person can not check the balance, he starts to panic. Therefore, offer to check the balance of alternative methods, if it is, of course, possible.
And the last, a very serious situation, when a person really needs his money urgently. If possible, let us know how to withdraw money or find the nearest office, if you have such a service:
It is important to understand that global failure is your problem, not the user. No need to shift thought processes to it. Offer at once ready-made options.
Not all users are ready to enter their personal account right now, and not all users, in principle, will log in and notice the error. But if you warn them in advance (for example, by posting on Twitter, SMS, or e-mail), then when they encounter an error message, they will be ready.
Separately, it should be said about professional services, on which the work of users depends daily. For example, the Antiplagiat service sometimes displays the following technical maintenance report:
Please note that the exact date and exact time range is indicated - this will help the user to plan their work in your service.
The subject of error warnings is indirectly related to maintaining trust. It may seem that another error warning will cause some users to doubt the reliability of the service (perhaps they would not have used the service at this moment, that is, in principle they would not have known about the error). But the perception of a warning as a concern or as an extra stone in the garden of a service depends also on how often you say that you have problems. Plus there are completely different services. Internet banking is one thing. But, for example, if you have an online store, you do not need to write to the user every time about problems, because he doesn’t visit you often.
However, if we are talking about professional tools, on which the user really depends every day from morning to evening, it is very strange not to warn about the problem (and the frequency with which it is permissible to report the problem to the user strongly depends on the industry).
Testers and product teams in general catch in time and do not allow output to the user of a very large proportion of bugs. But, unfortunately, mistakes happen everywhere, and it is not always possible to avoid them.
For us, bugs are a familiar story. We clearly classify them according to different parameters: the degree of danger, the need for correction, etc.
But when users notice a bug, in principle, they do not understand what they are facing. Many do not even know the term. For them, the bugs actually look like this:
We assume that if a user suddenly noticed something strange, he of course will inform us about it. He has five or even more ways to do this:
We assume that the user will sometime scroll the page down to the basement, will find the “Contacts” tab there. In the contacts section you will find among the cards, departments, sales offices and other small button "Feedback", click on it, select the topic of treatment. Will write a detailed letter about how to reproduce this error, attach screenshots and send.
Yes, indeed, such letters come. But if the error is very bad, a person can immediately leave a review with a low rating on the App Store, where he will also write in detail what he does not like about your service.
All of the above channels of calls have one very big problem: they take the user out of context, force him to be distracted to, in fact, help you. Therefore, most users prefer to wait until the problem disappears by itself (until you yourself notice it):
Or they may stop using your service altogether as idle.
Therefore, in the VK bugtracker there is such a ticket, which is called “no button“ Report a bug ””:
Indeed, this is a problem of so many services.
But there are positive examples, for example, Semrush. Almost throughout the service there are special windows that are aimed at taking feedback from a person.
In this situation, the user is worth less effort to write you about some kind of error or feedback. This is especially true for beta testing.
Unfortunately, there are situations where you can not fix a bug quickly. You can simply warn the user about it - as in the previous part of the report.
As an example, here is a screenshot when, using completely ordinary windows, the developers of the icon design font material design warn users that there is a compatibility problem and apologize:
Please note that they provide a link for those who have these problems. According to the link instruction how to fix it.
The most important thing to remember about specific bugs is the need for high-quality feedback. Therefore, create special windows in order to receive this information from users as quickly as possible. Well, and the second - of course, be warned if you know a bug, but you cannot fix it.
Unfortunately, many developers believe that user error is the user's business. But in fact, the more users make mistakes at a certain point in the product, the more the service itself is to blame. In the context of error design, I can offer five chips that can help you improve your user experience in such places.
The first example of the bottleneck of many services is, of course, login / registration:
For example, the entry field in InVision. The little red stripe is, in principle, the entire error message. Probably, when the designer drew it, I thought that the user would read the message without any difficulty: “Oops, the combination of email and password is not correct.” Check the email first, then the password, and again press the button to enter. But statistics suggest that the user makes several attempts to enter and enter a password, before he realizes that the problem is in the email address.
This happens because the user's attention at the time of entry is concentrated in one very narrow area - it is called the focus of attention:
As you can see, the error message is quite high and the user may simply not notice it when refreshing the page. In addition, InVision clears the password (you need to help the user ...). And the wiggling in the password field further focuses the user's attention; he thinks the mistake is there.
The same guys from InVision in another part of the product provided information about the error a little differently. First, they highlighted both fields. Secondly, they do not erase the password, because it can be correct (they assume that the user will notice exactly where the error is and decide for himself):
Highlighting both fields - this is the second chip.
But this does not always help.
For example, Adobe designers believe that users really read all this:
Another classic example offers Xiaomi:
Or, for example, the website of the State Service (like many others) simply duplicates the title field name in error:
In the examples above, the whole problem is in letters. Therefore, you need to think about how to make the wording shorter and clearer. We can easily read this message when we see it on a huge screen and focus on reading:
But in the environment of the interface and current tasks for users, it looks like this:
And they do not read to the end. When the user reads a line, it focuses on the beginning of the line. And to read further, he needs to make an effort:
He is reluctant to read your texts, he wants to continue to solve his tasks.
Therefore, reducing the wording and placing the message in the focus area, we can quickly convey the meaning.
Who faced with self-checkout?
Modern self-checkout, of course, built differently. But the very first of them were built according to this scenario: I put the basket on one side, take the goods in turn, scan the barcode and put them on the other side so that the system knows that I really scanned the entire basket (by weight). At that moment, when I put the goods on the left side, the system understands that I scanned it, and adds it to the check. Cass developers noticed a very interesting problem: people take a small product (for example, a bottle of water), scan it, then immediately take a second product and try to carry it out. At the same time, the system does not react at all, the scanner does not work, and users are looking for helpers through their eyes and are straining the retailer’s staff.
What was the problem? Users forget to put small items on the other side. Therefore, the developers have added a sound signal, after which buyers began to do without an assistant in 90% of such situations. The signal made the person raise his eyes to the cash register screen and go out of state when he was scanning his huge shopping basket: "Exactly, I did not put water on it."
This error message has two of the listed "chips": it tells you exactly where the error is, and it teaches how to work with the service.
Last but most interesting.
Let's take an example right away. This is a piece of the registration path (once again I remind you that registration is quite a weak point in so many services):
In order to start using the Revolut financial service in general, I must first confirm my phone number. Notice that they have already automatically determined and substituted the country code. Thank you guys.
Next I have to enter my first and last name. Well, once they have defined my country, then I start typing automatically in Russian, and when I click “Next”, filling out the entire form, the service says to me: “Please use Latin letters.” Automatic validation has long been known to everyone, and it must be applied! But this is not the end. I need to fill in the address information, and note that the country is already automatically substituted and written in Cyrillic.
But I won’t be fooled - I enter the address in Latin letters, click Continue. And, what do you think is happening?
In such moments, I really want to throw the phone somewhere. But this, of course, is an exceptional case. However, this example also shows that unnecessary and any repeated actions greatly strain the user, make him nervous and negatively affect the image of your product.
Therefore, do not force the user to re-enter any fields, use as much automation as possible.
The other day I came across an interesting report on the APIFortress site. There was a story about a company that supplied stock images to its partners. One of them was an agency that dealt with souvenirs with pugs.
One day, this pug partner called the stock company and complained about the breakdown of the service.
It turned out that the stock company that day released a minor API update in the morning, which did not affect most customers, but hit the pug company very hard. Their website was built in such a way that the update caused some kind of critical failure of the search. End users saw that nothing was found or some unknown error. Therefore, the connected services need to pay close attention.
Sometimes it's not enough just to know that you have a problem somewhere, because users will see strange windows that will not help them:
And the interface does not solve this problem.
Therefore, it is very important to spend efforts to teach your service to distinguish the causes of problems with the API.
A very good example is the ifthisthenthat automator service. With the help of API bundles of various services (for example, smart home or social networks), they force third-party services to do certain things. For example, if I published a post on Instagram, it automatically goes to my Facebook. Or, if I left the house, the service determines from my location that I am in the office and checks if I have turned off all my smart irons. And if not turned off, it turns off.
These guys have done a lot of work, and not only in the interface.
First, they allocate a separate tab for errors. All failed operations are collected in this log.
They define different types of errors:
In the first case, the Instagram service is offline, and we understand what the problem is. We may be temporarily out of range.
In the event that the user cannot contribute to the solution of the problem in any way, a simple notification is displayed.
What are external problems in my user understanding?
All software is tied to hardware, sensors, etc. All this is also created by people and may not work. Therefore, it is very important to report this to the user. Good service can report such errors as your own.
A good example is the lack of an Internet connection in the Slack communicator. If, during work, the Internet fell off, I see the following message from above:
As we remember about user error messages, at the moment of entering some text, the user is concentrated in this area:
Slack does not forget about this and highlights the field of yellow.
However, he does not block me a set of messages. I can continue to write it further, but when I try to send a Slack bot sends me this message:
And in principle, it is very accessible explains what exactly the problem. I will notice such a mistake rather quickly.
The big problem with external errors, which came to us from “ancient” times, when products were created by engineers for engineers, is the content of error texts:
They are written in such a language as if we now still mean that the user knows what a firewall is, ftp, dll, kernel, kernel, and so on.
We show one information to a technician and another to the user.
Probably worth mentioning separately about how people, in principle, communicate with technical support.
For many, this is really a lot of stress. Most of the error messages do not imply that they should be understood. A person who does not even know English is trying to somehow explain: something broke in there. He is experiencing very strong discomfort. And all this affects in general his experience in communicating with your service. Therefore, try to create such messages that the user will be able to understand and pass on to his own technical support.
For example, this is a photo of a 3D printer that clearly and clearly (with the help of a small screen) says that the temperature sensor has deteriorated - an error has occurred, so it stopped. Contact technical support. The user can easily understand what is the matter, and it is not difficult for him to describe this problem in his own words without technical terms:
What does it mean?
Consider this example: most machines already have small screens, where we can display text (not like before).But it feels as if the developers copy the text of the description of the errors from the old instructions, which are completely incomprehensible and require a long reading:
In this situation, the user does not understand what to do. Some novice drivers, instead of reading the instructions, just keep driving, thinking that everything is in order. And others, on the contrary, begin to panic - they are trying to call a tow truck.
And there is still such a category: “I have a week there before my salary ... nothing will happen?”
Therefore, it is very important to enable the user to assess the danger of this problem. The user at this moment does not want to go into some complicated instructions. If something terrible really happened, it is important to point out one thing - the seriousness of the problem. Sometimes "the operation cannot continue", and sometimes you can really wait until the salary.
There is a situation like on the chart. What caused such a sharp jump? For example, is the temperature in the engine increased? Or is it just some kind of humbug sensor?
In such situations, it is best for the user to give the opportunity to decide for himself what it was.
As an example, a good long story. In September of this year, the PewDiePie video blogger, during a stream of several hundred thousand people, called his black opponent a word that in the English-speaking world should not be called in principle. He, of course, later apologized, but still there was a scandal. Manufacturers of various games, including Sean Vanaman, filed a complaint with YouTube asking them to remove all the videos of how PewDiePie played their games.
But behind PewDiePie there was also a large army of support. And on the games of Sean Vanaman on Steam (the service that sells these games) showered hundreds of negative reviews. These reviews did not reflect the quality of the game, but could adversely affect its sales. And Steam did a terrific job: they noticed the user, what happened, that an unusual amount of negative feedback was noticed since September 11:
At the same time, they let the user decide for himself whether to exclude these reviews or take them into account. The user can decide for himself how important these reviews are for him in the context of the purchase of the game. Such work on bugs impresses me both as a usabilist and as a user of this service.
Not all errors are just bugs. Many have hidden potential. Let's talk about this a little bit.
First, as I said earlier, errors can and should be trained.
For example, the Skyeng service is an online English school that works only through the Google Chrome browser. This browser automatically (by default) sometimes blocks incoming video calls or audio recordings. And in this situation, Skyeng hangs up a button that leads to quite detailed instructions:
This solution also has some problems. If there are a lot of such buttons in your service, all these instructions will be simply unbearable, expensive and difficult to keep up to date. And the user doesn’t really like to read any instructions.
Another example is SEMrush. This is the service login window:
It is displayed if I follow the link that requires authorization from me. Most services in this situation give an error 404, the user leaves and does not return on this link. But in SEMrush they are not limited to just the entry form. They show additional pictures and a description of the work in that part of the service where this link leads. Thus, the user enters the context. He understands where he will go if the service is familiar to him. And if the service is not familiar, get a cursory idea of what awaits him after the entrance.
Another potential for error reporting is to break the deadlock.
Often errors are absolutely dead-end scenarios. The user needs to remember the context and return by the script above.
For example, take the Avito service. There is a “Saved Searches” tab:
If there is nothing there, the user is forced to go back to the search bar. In accordance with the instruction presented here, which he must somehow remember, he must save the search somewhere on the page.
And it was possible to do this:
We know (save) the story and display it here so that the user, without looking up from the context, presses an asterisk and saves some search that he needs. In this way, we turn a dead-end scenario into a return to the main path.
There is another important topic that I wanted to discuss, the availability of interfaces.
I am very pleased that lately they have begun to talk a lot about this, and have begun to do a lot in this direction. For example, recently UsabilityLab has been testing the availability of Internet banks for people with visual and hearing impairments.
But in the context of mistakes, we sometimes forget about the difference in perception and do some things that cannot be done.
For example, many people use only the color indication of the error. So you should not do it, because there are color blindness:
Many designers will say: "I checked everything in a special service that shows how a blind-eyed person sees it." But in fact, these services will never show an accurate picture, because all color-blind people see differently. And even if you pick up the brightness / contrast, there is still a risk that the color blind user does not recognize this error.
For example, the registration field in Wrike contains just such an error:
They have a pure color differentiation implemented - in case of an error, the stroke and the text inside the field are highlighted in red. It is best to add some kind of text message or symbol.
Another problem is gray or too small lettering. If you see a small gray cursive font in your interface on a gray background, you can safely go to the designer and force him to redo it, because there are different monitors and on cheap things such things are not visible:
A person will simply break his eyes when trying to read such text.
When I showed this report to my colleague manager, he said: “I was not convinced.” Because it is long, expensive and not at all profitable for a business to do so much work on mistakes. In the context of interface design, I would like to say that I do not urge you to work on all erroneous situations in general.
What do we have to do?My colleague built the work in his team as follows. All errors that occur are first collected in a single large bag (log). Only errors that are repeated are extracted from there.
Repetitive errors already have business value. These are the mistakes worth spending time on.
But it is not always necessary to rush and immediately sculpt an error on the interface, because very often the occurrence of such errors can be prevented by rewriting a little code, going to the front end and correcting something. And only if it is impossible to avoid getting the error to the user, is it really worth thinking about some kind of interface messages.
I understand that the interface is not always part of your work. And even not all product owners are eager to build work with mistakes in their team, because it is not always beneficial (the benefits, if any, are sometimes not immediately visible). But my goal is to expand your way of thinking a bit and ask the question: are you only doing your job or are you doing a great product?
Because a cool product can report bugs. He cares about the user, even when something goes wrong.
Here are some links:
In conclusion, I want to say, probably, only one thing: mistakes are also experience. Design it.
If the topic of testing and error handling is as close to you as it is to us, you will certainly be interested in these reports at our May conference Heisenbug 2018 Piter :
The article is based on the report by Antonina Hisametdinova with Heisenbug 2017 Moscow, which is engaged in designing user interfaces in Pavlov Dog .
In addition, Medium has a series of articles on the Error Design Guide . The cycle has not yet been completed, but it gives a more complete and coherent picture on the topic of the article.
Wrong script
Time after time we design the main scenarios for a wide variety of services. In the case of an online store, the main one will be:
')
A person visits the site, selects a product, orders its delivery; pays and receives an order.
We are so focused on the main scenarios that we forget one very important thing: there are alternative scenarios and thousands of ways how the main scenario can be interrupted.
All these are erroneous scenarios that arise when something goes wrong.
Food teams often do not pay enough attention to such scenarios. For example, a very typical story: “Something went wrong. We have problems, so just close this message. ”
Another example: “We have a mistake. Please try again later:
And another category of errors - my favorite: unknown errors.
Why work on erroneous scenarios?
It is very difficult to justify the need for business to work out erroneous scenarios. Why do we have to go back and fix something when we have new features ahead? But I have four iron arguments that will help demonstrate to your product owner or business the need for such work.
A good error message reduces the burden on technical support and staff
The slide shows some numbers from one of our clients. This is the number of user calls to tech support per month. Calls are related to problems of a certain kind:
Please note that 400 people a month call simply because they cannot enter or correctly enter the login / password in the appropriate form on the site.
A good error message helps the user not to get lost in the conversion funnel.
If the error message is compiled correctly, it returns it to the main scenario, even if a session break occurred.
A good error message teaches you how to work with the service.
You may not even need to create onboarding or some educational videos, the development of which, by the way, is also worth a lot of money.
A good error message allows you to maintain confidence in the service in a difficult moment.
This is the last but not least argument.
In general, the topic of human-technology trust has been explored for quite some time. Now we trust enough technology. For example, we will never double-check whether the messenger sent a message to the addressee, or how the calculator added or multiplied three-digit numbers (unfortunately, however, not all services can boast such a level of trust as calculators).
We trust our lives to dozens of different types of software, flying in airplanes. But this trust is very easy to destroy. Even the smallest mistake can make it. And such mistakes happen in both small and very large companies.
What causes errors
I mentioned a “good error message” several times. It is time to talk about what it means. And for a start we will understand, because of what errors arise in principle.
- the first thing that comes to mind is some kind of global malfunctions or technical work on the service ;
- specific bugs ;
- user error .
But that's not all. There is also:
- problems on the side of connected services ;
- external problems ;
- extremely unusual user or service behavior .
This is not a classification attempt. In fact, the types of errors are far from six, there may be hundreds or even more. But in the context of interface design, these errors are the most significant.
Global crashes
Let's start with the situation when your service is completely unavailable.
Unfortunately, such errors can occur in any services, from online games to complex stock professional tools.
Good question: what to do in such a situation?
While the developers are quickly fixing some tools, the unfortunate users receive strange error messages and get your technical support, write unpleasant posts on Twitter:
Let's look at the messages that are displayed at this point:
They are quite simple and some of them even honestly apologize. But users still feel uncomfortable and try to understand what is the matter; repeat the entrance is not in 15 minutes; poke anywhere.
How to help them?
Think about the consequences
If you do not know what the consequences of a global failure are, just go to tech support. Because at this moment the guys there are cracking in full. And they will be happy to share this pain with you.
Many in such situations are limited to the message: yes, we have a problem and we will fix it soon:
But “soon” is when?
The user does not need to know when you will correct everything, up to a minute. But they need to understand some significant time points, for example, 15 minutes, one hour, five hours or even a day. This will help them navigate in space and plan the management of their money.
Another reasonable question (in terms of financial services): do the cards work?
And a good error message will be able to respond to it. Even if the cards do not work, it's better to say this anyway, because this is very important information.
Another story - there must be a salary or transfer; and when will the money come?
It seems to be nothing critical, but when a person can not check the balance, he starts to panic. Therefore, offer to check the balance of alternative methods, if it is, of course, possible.
And the last, a very serious situation, when a person really needs his money urgently. If possible, let us know how to withdraw money or find the nearest office, if you have such a service:
It is important to understand that global failure is your problem, not the user. No need to shift thought processes to it. Offer at once ready-made options.
Notify in advance
Not all users are ready to enter their personal account right now, and not all users, in principle, will log in and notice the error. But if you warn them in advance (for example, by posting on Twitter, SMS, or e-mail), then when they encounter an error message, they will be ready.
Separately, it should be said about professional services, on which the work of users depends daily. For example, the Antiplagiat service sometimes displays the following technical maintenance report:
Please note that the exact date and exact time range is indicated - this will help the user to plan their work in your service.
The subject of error warnings is indirectly related to maintaining trust. It may seem that another error warning will cause some users to doubt the reliability of the service (perhaps they would not have used the service at this moment, that is, in principle they would not have known about the error). But the perception of a warning as a concern or as an extra stone in the garden of a service depends also on how often you say that you have problems. Plus there are completely different services. Internet banking is one thing. But, for example, if you have an online store, you do not need to write to the user every time about problems, because he doesn’t visit you often.
However, if we are talking about professional tools, on which the user really depends every day from morning to evening, it is very strange not to warn about the problem (and the frequency with which it is permissible to report the problem to the user strongly depends on the industry).
Specific bugs
Testers and product teams in general catch in time and do not allow output to the user of a very large proportion of bugs. But, unfortunately, mistakes happen everywhere, and it is not always possible to avoid them.
For us, bugs are a familiar story. We clearly classify them according to different parameters: the degree of danger, the need for correction, etc.
But when users notice a bug, in principle, they do not understand what they are facing. Many do not even know the term. For them, the bugs actually look like this:
We assume that if a user suddenly noticed something strange, he of course will inform us about it. He has five or even more ways to do this:
- section "Contacts" and feedback ;
- online consultant and technical support call;
- social networks and company chat rooms;
- reviews (App Store and Play Market) !!!
- blogs and forums.
We assume that the user will sometime scroll the page down to the basement, will find the “Contacts” tab there. In the contacts section you will find among the cards, departments, sales offices and other small button "Feedback", click on it, select the topic of treatment. Will write a detailed letter about how to reproduce this error, attach screenshots and send.
Yes, indeed, such letters come. But if the error is very bad, a person can immediately leave a review with a low rating on the App Store, where he will also write in detail what he does not like about your service.
All of the above channels of calls have one very big problem: they take the user out of context, force him to be distracted to, in fact, help you. Therefore, most users prefer to wait until the problem disappears by itself (until you yourself notice it):
Or they may stop using your service altogether as idle.
Therefore, in the VK bugtracker there is such a ticket, which is called “no button“ Report a bug ””:
Indeed, this is a problem of so many services.
Create custom feedback collection windows.
But there are positive examples, for example, Semrush. Almost throughout the service there are special windows that are aimed at taking feedback from a person.
In this situation, the user is worth less effort to write you about some kind of error or feedback. This is especially true for beta testing.
If you cannot fix the bug quickly, warn about it.
Unfortunately, there are situations where you can not fix a bug quickly. You can simply warn the user about it - as in the previous part of the report.
As an example, here is a screenshot when, using completely ordinary windows, the developers of the icon design font material design warn users that there is a compatibility problem and apologize:
Please note that they provide a link for those who have these problems. According to the link instruction how to fix it.
The most important thing to remember about specific bugs is the need for high-quality feedback. Therefore, create special windows in order to receive this information from users as quickly as possible. Well, and the second - of course, be warned if you know a bug, but you cannot fix it.
User errors
Unfortunately, many developers believe that user error is the user's business. But in fact, the more users make mistakes at a certain point in the product, the more the service itself is to blame. In the context of error design, I can offer five chips that can help you improve your user experience in such places.
The first example of the bottleneck of many services is, of course, login / registration:
For example, the entry field in InVision. The little red stripe is, in principle, the entire error message. Probably, when the designer drew it, I thought that the user would read the message without any difficulty: “Oops, the combination of email and password is not correct.” Check the email first, then the password, and again press the button to enter. But statistics suggest that the user makes several attempts to enter and enter a password, before he realizes that the problem is in the email address.
This happens because the user's attention at the time of entry is concentrated in one very narrow area - it is called the focus of attention:
As you can see, the error message is quite high and the user may simply not notice it when refreshing the page. In addition, InVision clears the password (you need to help the user ...). And the wiggling in the password field further focuses the user's attention; he thinks the mistake is there.
Chip 1. Put the message in focus
The same guys from InVision in another part of the product provided information about the error a little differently. First, they highlighted both fields. Secondly, they do not erase the password, because it can be correct (they assume that the user will notice exactly where the error is and decide for himself):
Chip 2. Show exactly where the error
Highlighting both fields - this is the second chip.
But this does not always help.
For example, Adobe designers believe that users really read all this:
Another classic example offers Xiaomi:
Or, for example, the website of the State Service (like many others) simply duplicates the title field name in error:
Feature 3. Use clear and short wording.
In the examples above, the whole problem is in letters. Therefore, you need to think about how to make the wording shorter and clearer. We can easily read this message when we see it on a huge screen and focus on reading:
But in the environment of the interface and current tasks for users, it looks like this:
And they do not read to the end. When the user reads a line, it focuses on the beginning of the line. And to read further, he needs to make an effort:
He is reluctant to read your texts, he wants to continue to solve his tasks.
Therefore, reducing the wording and placing the message in the focus area, we can quickly convey the meaning.
Feature 4. Tell me how to fix the error
Who faced with self-checkout?
Modern self-checkout, of course, built differently. But the very first of them were built according to this scenario: I put the basket on one side, take the goods in turn, scan the barcode and put them on the other side so that the system knows that I really scanned the entire basket (by weight). At that moment, when I put the goods on the left side, the system understands that I scanned it, and adds it to the check. Cass developers noticed a very interesting problem: people take a small product (for example, a bottle of water), scan it, then immediately take a second product and try to carry it out. At the same time, the system does not react at all, the scanner does not work, and users are looking for helpers through their eyes and are straining the retailer’s staff.
What was the problem? Users forget to put small items on the other side. Therefore, the developers have added a sound signal, after which buyers began to do without an assistant in 90% of such situations. The signal made the person raise his eyes to the cash register screen and go out of state when he was scanning his huge shopping basket: "Exactly, I did not put water on it."
This error message has two of the listed "chips": it tells you exactly where the error is, and it teaches how to work with the service.
Chip 5. Save user work
Last but most interesting.
Let's take an example right away. This is a piece of the registration path (once again I remind you that registration is quite a weak point in so many services):
In order to start using the Revolut financial service in general, I must first confirm my phone number. Notice that they have already automatically determined and substituted the country code. Thank you guys.
Next I have to enter my first and last name. Well, once they have defined my country, then I start typing automatically in Russian, and when I click “Next”, filling out the entire form, the service says to me: “Please use Latin letters.” Automatic validation has long been known to everyone, and it must be applied! But this is not the end. I need to fill in the address information, and note that the country is already automatically substituted and written in Cyrillic.
But I won’t be fooled - I enter the address in Latin letters, click Continue. And, what do you think is happening?
In such moments, I really want to throw the phone somewhere. But this, of course, is an exceptional case. However, this example also shows that unnecessary and any repeated actions greatly strain the user, make him nervous and negatively affect the image of your product.
Therefore, do not force the user to re-enter any fields, use as much automation as possible.
Connected service issues
Test the Connected Services API
The other day I came across an interesting report on the APIFortress site. There was a story about a company that supplied stock images to its partners. One of them was an agency that dealt with souvenirs with pugs.
One day, this pug partner called the stock company and complained about the breakdown of the service.
It turned out that the stock company that day released a minor API update in the morning, which did not affect most customers, but hit the pug company very hard. Their website was built in such a way that the update caused some kind of critical failure of the search. End users saw that nothing was found or some unknown error. Therefore, the connected services need to pay close attention.
Teach them to distinguish problems.
Sometimes it's not enough just to know that you have a problem somewhere, because users will see strange windows that will not help them:
And the interface does not solve this problem.
Therefore, it is very important to spend efforts to teach your service to distinguish the causes of problems with the API.
Provide a problem notification interface.
A very good example is the ifthisthenthat automator service. With the help of API bundles of various services (for example, smart home or social networks), they force third-party services to do certain things. For example, if I published a post on Instagram, it automatically goes to my Facebook. Or, if I left the house, the service determines from my location that I am in the office and checks if I have turned off all my smart irons. And if not turned off, it turns off.
These guys have done a lot of work, and not only in the interface.
First, they allocate a separate tab for errors. All failed operations are collected in this log.
They define different types of errors:
In the first case, the Instagram service is offline, and we understand what the problem is. We may be temporarily out of range.
In the event that the user cannot contribute to the solution of the problem in any way, a simple notification is displayed.
External problems
What are external problems in my user understanding?
All software is tied to hardware, sensors, etc. All this is also created by people and may not work. Therefore, it is very important to report this to the user. Good service can report such errors as your own.
Make it clear what actions in your service are not available due to external problems.
A good example is the lack of an Internet connection in the Slack communicator. If, during work, the Internet fell off, I see the following message from above:
As we remember about user error messages, at the moment of entering some text, the user is concentrated in this area:
Slack does not forget about this and highlights the field of yellow.
However, he does not block me a set of messages. I can continue to write it further, but when I try to send a Slack bot sends me this message:
And in principle, it is very accessible explains what exactly the problem. I will notice such a mistake rather quickly.
The big problem with external errors, which came to us from “ancient” times, when products were created by engineers for engineers, is the content of error texts:
They are written in such a language as if we now still mean that the user knows what a firewall is, ftp, dll, kernel, kernel, and so on.
Clearly separate competency levels
We show one information to a technician and another to the user.
Probably worth mentioning separately about how people, in principle, communicate with technical support.
For many, this is really a lot of stress. Most of the error messages do not imply that they should be understood. A person who does not even know English is trying to somehow explain: something broke in there. He is experiencing very strong discomfort. And all this affects in general his experience in communicating with your service. Therefore, try to create such messages that the user will be able to understand and pass on to his own technical support.
For example, this is a photo of a 3D printer that clearly and clearly (with the help of a small screen) says that the temperature sensor has deteriorated - an error has occurred, so it stopped. Contact technical support. The user can easily understand what is the matter, and it is not difficult for him to describe this problem in his own words without technical terms:
Help the user to prioritize the problem.
What does it mean?
Consider this example: most machines already have small screens, where we can display text (not like before).But it feels as if the developers copy the text of the description of the errors from the old instructions, which are completely incomprehensible and require a long reading:
In this situation, the user does not understand what to do. Some novice drivers, instead of reading the instructions, just keep driving, thinking that everything is in order. And others, on the contrary, begin to panic - they are trying to call a tow truck.
And there is still such a category: “I have a week there before my salary ... nothing will happen?”
Therefore, it is very important to enable the user to assess the danger of this problem. The user at this moment does not want to go into some complicated instructions. If something terrible really happened, it is important to point out one thing - the seriousness of the problem. Sometimes "the operation cannot continue", and sometimes you can really wait until the salary.
Extremely unusual user or service behavior.
There is a situation like on the chart. What caused such a sharp jump? For example, is the temperature in the engine increased? Or is it just some kind of humbug sensor?
In such situations, it is best for the user to give the opportunity to decide for himself what it was.
As an example, a good long story. In September of this year, the PewDiePie video blogger, during a stream of several hundred thousand people, called his black opponent a word that in the English-speaking world should not be called in principle. He, of course, later apologized, but still there was a scandal. Manufacturers of various games, including Sean Vanaman, filed a complaint with YouTube asking them to remove all the videos of how PewDiePie played their games.
But behind PewDiePie there was also a large army of support. And on the games of Sean Vanaman on Steam (the service that sells these games) showered hundreds of negative reviews. These reviews did not reflect the quality of the game, but could adversely affect its sales. And Steam did a terrific job: they noticed the user, what happened, that an unusual amount of negative feedback was noticed since September 11:
At the same time, they let the user decide for himself whether to exclude these reviews or take them into account. The user can decide for himself how important these reviews are for him in the context of the purchase of the game. Such work on bugs impresses me both as a usabilist and as a user of this service.
Additional features - hidden potential
Not all errors are just bugs. Many have hidden potential. Let's talk about this a little bit.
Train through mistakes
First, as I said earlier, errors can and should be trained.
For example, the Skyeng service is an online English school that works only through the Google Chrome browser. This browser automatically (by default) sometimes blocks incoming video calls or audio recordings. And in this situation, Skyeng hangs up a button that leads to quite detailed instructions:
This solution also has some problems. If there are a lot of such buttons in your service, all these instructions will be simply unbearable, expensive and difficult to keep up to date. And the user doesn’t really like to read any instructions.
Another example is SEMrush. This is the service login window:
It is displayed if I follow the link that requires authorization from me. Most services in this situation give an error 404, the user leaves and does not return on this link. But in SEMrush they are not limited to just the entry form. They show additional pictures and a description of the work in that part of the service where this link leads. Thus, the user enters the context. He understands where he will go if the service is familiar to him. And if the service is not familiar, get a cursory idea of what awaits him after the entrance.
Break the deadlock
Another potential for error reporting is to break the deadlock.
Often errors are absolutely dead-end scenarios. The user needs to remember the context and return by the script above.
For example, take the Avito service. There is a “Saved Searches” tab:
If there is nothing there, the user is forced to go back to the search bar. In accordance with the instruction presented here, which he must somehow remember, he must save the search somewhere on the page.
And it was possible to do this:
We know (save) the story and display it here so that the user, without looking up from the context, presses an asterisk and saves some search that he needs. In this way, we turn a dead-end scenario into a return to the main path.
Availability
There is another important topic that I wanted to discuss, the availability of interfaces.
I am very pleased that lately they have begun to talk a lot about this, and have begun to do a lot in this direction. For example, recently UsabilityLab has been testing the availability of Internet banks for people with visual and hearing impairments.
But in the context of mistakes, we sometimes forget about the difference in perception and do some things that cannot be done.
For example, many people use only the color indication of the error. So you should not do it, because there are color blindness:
Many designers will say: "I checked everything in a special service that shows how a blind-eyed person sees it." But in fact, these services will never show an accurate picture, because all color-blind people see differently. And even if you pick up the brightness / contrast, there is still a risk that the color blind user does not recognize this error.
For example, the registration field in Wrike contains just such an error:
They have a pure color differentiation implemented - in case of an error, the stroke and the text inside the field are highlighted in red. It is best to add some kind of text message or symbol.
Another problem is gray or too small lettering. If you see a small gray cursive font in your interface on a gray background, you can safely go to the designer and force him to redo it, because there are different monitors and on cheap things such things are not visible:
A person will simply break his eyes when trying to read such text.
Perform Accessibility testing for scripts with errors
Business value
When I showed this report to my colleague manager, he said: “I was not convinced.” Because it is long, expensive and not at all profitable for a business to do so much work on mistakes. In the context of interface design, I would like to say that I do not urge you to work on all erroneous situations in general.
What do we have to do?My colleague built the work in his team as follows. All errors that occur are first collected in a single large bag (log). Only errors that are repeated are extracted from there.
Repetitive errors already have business value. These are the mistakes worth spending time on.
But it is not always necessary to rush and immediately sculpt an error on the interface, because very often the occurrence of such errors can be prevented by rewriting a little code, going to the front end and correcting something. And only if it is impossible to avoid getting the error to the user, is it really worth thinking about some kind of interface messages.
I understand that the interface is not always part of your work. And even not all product owners are eager to build work with mistakes in their team, because it is not always beneficial (the benefits, if any, are sometimes not immediately visible). But my goal is to expand your way of thinking a bit and ask the question: are you only doing your job or are you doing a great product?
Because a cool product can report bugs. He cares about the user, even when something goes wrong.
Summary
What do I suggest you do with all this information?
- When you come to work, discuss the report with the team and the owner of the product. Especially useful to go to UX'erov or designers.
- Check how helpful your error messages are to users.
- After that, you will be able to comprehensively look at your product, find its weak points, which you may not have noticed before, and improve erroneous scenarios.
- And one more very important point in the context of testing - erroneous scenarios also need to be tested and often on equal terms with the rest.
What to read?
Here are some links:
- "Release It !: Design and Deploy Production-Ready Software", Michael T. Nygard
- "How to write a great error message", Thomas Fuchs, https://goo.gl/4L8YWo
- Architect, Your Nick Harley, https://goo.gl/7em6cQ
In conclusion, I want to say, probably, only one thing: mistakes are also experience. Design it.
If the topic of testing and error handling is as close to you as it is to us, you will certainly be interested in these reports at our May conference Heisenbug 2018 Piter :
- We write UI tests for Web, iOS and Android simultaneously # python (Igor Balagurov, Uptick)
- Web Security Testing Starter Kit (Andrey Leonov, SEMrush)
- Beta testing of VKontakte (Anastasia Semenyuk, VKontakte)
Source: https://habr.com/ru/post/353668/
All Articles