Handling error codes right: a how-to for Product managers
Why it’s important
Product- and requirements managers are supposed to care about product-market fit, backlog prioritizing and design, right? Why the heck should I care about http errors?
The answer is simple: you care about user experience and interaction with the system, and giving users right understanding what’s happening in application lies exactly in this area. If you’re working on a web application (as the majority of us do), this may be a useful guide.
HTTP Error codes overview
- 100–199: informational status. These are used internally and users rarely see any of them
- 200–299: success status. When everything runs as expected, results are shown to the user in the application interface. Thus, we won’t dive deeper into this type of errors.
- 300–399: redirection status. Normally, redirect works under the hood and users see only the final destination page.
- 400–499: client errors. These are errors which we’re interested in the most, as they’re connected to the application issues: connectivity, pages, authorization etc.
- 500–599: server errors. Despite server is the root cause of these issues and users can do little to fix it, some of them errors should be handled by the application.
- Network connection error. I’ve included this item here, as it’s also an important part of user experience. In the majority of cases, none changes are saved locally, so connection indication is crucial here.
As you can see, the errors which actually should be handled are not numerous.
Basically, your task is to communicate if something is wrong, the reason and what the user can do about it.
404 Error: Not Found
This is the most frequently seen error page on the Web. This may happen when:
- User follows the link to the page which was removed or its address was changed. I’ll add that in case of page URL been changed, admin should set up a redirect for it.
- User manually enters incorrect URL (typo).
- User via direct link tries to enter the entity not eligible for him. For example, the user follows the link to advertising campaign/ appointment/ media, not accessible from his account.
In all cases, the domain part of the URL is correct, but some part of the path is not, and application responds with “Not found” page.
Add some funny text and advise user to go to the main/ other relevant page or use the search.
You easily can recall numerous outstanding examples of 404 pages design, like these:
400, 500 and 503 Errors
When users see 500 Internal server error, there are no issues with your application code or requests, but with the server itself. 503 Service unavailable error indicates that server cannot process the request due to some outage (too many requests, issues with performance etc.)
400 Bad request error indicates that application sent the request with the wrong syntax.
In fact, users can do little to fix it. So just display the error text with code (this can be useful for troubleshooting) and allow users to try a bit later.
401 Unauthorized Error
This error code is shown in cases when then the application uses invalid or expired credentials, as well as may be shown for a logged out user, who tries to enter the page with protected content.
The best option here would be to redirect user to the login page.
502 Bad Gateway Error
This kind of error happens when there are network problems between server and application. In some cases, it is connected to router configuration and user can try to fix it by checking firewall or router settings. Sometimes, it happens from time to time (due to some glitches on a server), so you may ask user try again later.
One the best variants for the copytext:
Please check your connection settings, or try again a bit later. Issues may be connected to your network firewall, router, or other network gateway device.
Network connection issue
You should put special attention to inform your application users of the internet connection lost if you use real-time communication (chats, video calls), display real-time statistics or saving user’s content instantly.
The good practice is to display a status bar (like in Slack or Google Drive/ Docks) with relevant notification
Recap
To enhance the user experience, product managers should handle how errors are processed within the application.
First of all, discuss with the team which error cases you’re already handling and how. Then, try to list those most likely to happen in your app.
There are few errors worth paying attention, and probably you’ll consider redirecting user inside the application as the best option for the majority of them.
My lean approach is following: I design separately 404 error page, connection issues and “generic” page for other possible issues.
Hope you’ve found something useful in this article.
If you liked it, spread the word to your fellow colleagues :)
