oops! Something went wrong! (2023)

Why is it so important to design for what went wrong? Could this be an untapped opportunity?

DDespite our well thought out plans, sometimes things just don't go as expected. So it helps to have an alternative. When a perfect black prom dress exceeds our monthly budget, we save up or opt for red. We even have a backup plan for daily activities. So should we build products regardless of failure?

Too often, product teams spend all their time and effort designing a perfect product and tend to overlook flaws. As product developers, we need to understand that failure is an inevitable aspect of any product. They may seem trivial, but the user experience of a product is severely compromised if we don't consider and design for bugs.

Imagine that you are stuck in a situation and you don't know how to get out of it!

How many times have you encountered an error when filling out a visa application form or submitting a research paper on the last day of the deadline?

You are about to win a game and the product fails! Now you need to figure out what went wrong, and also find a solution. Very frustrating, isn't it?

This is exactly how users feel when the UI throws an unexpected cryptic error.

The perception of a product depends on the emotion it evokes. Each product interaction is associated with an emotional quotient.Our brains are wired to remember emotionally charged situations.That is why it is rightly said

"You can do 99 things right and they'll only remember what went wrong."

We all know that mistakes are inevitable. But if teams and product designers were aware of this and used it responsibly, they would be less destructive.

Designing bugs can be difficult. Errors must be handled with care. Here are the key indicators to consider when designing:

• The copy must adapt to the real error. Don't be general or vague when communicating about bugs.
• We need to make sure that the tone of the message is neutral. Don't assume the user is at fault.
• Don't get stuck on the problem. Instead, be constructive and suggest steps to correct the mishap.

These are some of the general considerations most of us are familiar with. However, the logic behind creating an error depends on its type. The procedure, structure, positioning, messages, appearance, and behavior are largely based on the type of error. Depending on the nature of the bug, we can create a guide/formula to help when incorporating a new bug. The designer does not have to start from scratch. He can identify the nature of the error and easily follow the guide.

At a high level, an error can be classified into two types:

• error manual
• automated error

A manual error is triggered by the user, while an automatic error is not under your control. In short, it is a manual error when the user makes a mistake, while it is an automatic error when the product makes a mistake. Let's understand the design guidelines associated with these errors.

A manual error is simply a response to user interaction. It is the mismatch between the user input and the expected input. Wrong password, invalid username, wrong date are some examples of manual errors. In most cases aManual errors can be quickly handled and corrected by the user.Therefore, the level of anxiety or frustration is low.

Positioning:

Posting an error message is crucial. Showing a popup with a list of errors is not only frustrating, but also makes it extremely difficult for the user to locate and fix this error. Popover or modal is intrusive and should be used when the product requires 100% attention. Since the manual error is contextual, it remains in the corresponding field. Showing an error in the input field makes it easy to compare the actual input with the expected input and fix an error.

However, a long form with sensitive fields is more prone to errors. Highlighting errors in multiple fields alerts the user. Condensing the errors to the top of the app and navigating to a specific error would be the way to go. Online validation must be integrated to complete this long form. This will catch an error on the fly as if you clicked submit or save and knew about it.

News:

It's confusing when an error doesn't provide clarity on what exactly is wrong. The goal is to remove ambiguity and be specific to the user's task.Focus on suggesting a solution instead of pressing on the bug.Don't make the user feel guilty.Try to avoid words like incorrect, incorrect, invalid, and instead stay constructive and positive.

(Video) Google pay Oops! Something went wrong

Exception: It's true that an error message should be error-specific, but here are some exceptions. That logic doesn't work when it comes to sensitive information. One of the most common examples is the login error. We often come across the invalid username or password error which requires the user to find out if they entered the wrong username or password or both. In these cases, being vague is imperative for privacy and security reasons.

Kor:

Choose the color that provides a strong contrast to the background. A bug should be easily discernible among the other distractions. Red is the traditional default color used for error messages. However, red should be used sparingly. We must convey the seriousness of the situation without alerting the user. In some situations, orange is also used because the color red can be stressful. Be careful not to stray too far from the styles the user is familiar with.

People with color vision problems or low vision may have trouble distinguishing colors with insufficient contrast. We should use icons along with colors so that errors are easily recognizable.

Finally, understand that an error should only be displayed when an action has been triggered.

We must not introduce an error without user input or when the user types. An error is the result of an incomplete or inaccurate entry.

(Video) Oops Something Went Wrong On YouTube Studio

The automated error is a system generated error. We've all been helpless and come across these bugs at some point. Some of the most common examples would be an abrupt system crash, technical problem, network connection failure, etc. Usually, a user has no control over these errors and they may not be fixed immediately. Because the user's task is compromised through no fault of his own, anxiety and frustration are high compared to manual. Therefore, we need to be more vigilant when designing for automatic errors.

Positioning:

The automated error requires the full attention of the user. Since there is little or nothing a user can do when receiving this error, it usually appears in a modal. A modal removes unnecessary distractions and limits user interaction with the underlying content. A separate page can also be used to report errors like page not found, offline, etc.

Messages:

It's important to focus on both the user's mood and the context of the error. It's important to pinpoint what went wrong, but make sure you don't hit the panic button for the user.

The error message should read:

• What happened?
• Why is that?
• What is the consequence?
• What should the user do next? Does the user have to do anything?

Kor:

Do all bugs have to be red? No it's not true. Red is an ideal color to highlight a bug, especially an online bug. However, a modal or error page is interruptive and gets the attention it deserves. Therefore, it is better to limit the use of red and not overwhelm the user. The user is already stressed and red will make it worse. A neutral color (black or gray) can be used with an error symbol, a combination of red with another.

While it is true that a bug is disappointing and frustrating for the user, we can not only help you fix it, but we see it as a potential opportunity.

Can we think of any other error that is not error or failure? Can we use the bug to educate about the product? Can we encourage the user to try a new feature?

Here's a great example from Facebook. If there is an error during login, Facebook just notifies the user correctly, but also prompts the user to sign up for a new account.

Also, Google informs its users about Google Drive if they cannot find a document. Showing relevant contextual information on an error page is a great way to tell more about the product.

Let's be fair, mistakes are inevitable. They are an inevitable part of a product. However, we can avoid a mistake by making a suggestion or notice. We can inform a user from the beginning about a complex task. Anything they need to know to complete a task should be shared in advance. For example, if a form has certain required fields, these must be specified explicitly. We must include descriptions and tips that will help the user and avoid errors.

Designing for mistakes can give us an advantage over others. First, think about all the interactions in your product that need support or could go wrong. Once you identify these error scenarios, start designing and writing messages. Be sure to test your posts with real users. Measurement and analysis settings help us discover new concerns and continually improve the user experience of a product.