This article was original posted on our blog.
So the other day I had a meeting with this guy. Well, I say a meeting. It was more like a weird office-based torture exercise, designed to test the very limits of my patience.
Every time I wanted to say something he just talked over me, trying to show off his knowledge. I would open my mouth and before the words came out, he was splurging some random comment to put me in my place. It felt like we were playing whack-a-mole, only I was the mole.
We get a similar feeling when our phone or tablet flashes up an unhelpful message. It’s a mixture of frustration and helplessness, made even worse when the message is triggered by some random defect in the app itself. It pops up over and over, like a car alarm going off, and there’s no way to silence it.
If you wanted to see the anger this can cause, you should have seen my uncle’s face while filling in a form on his mobile phone recently. Each time he started typing his email, the field would turn red and shout at him to “please type a valid email address”. Had I not been there he might have hurled the device out of the window. But when I looked at the message, I realized my uncle was doing everything right. It was the form that was wrong.
By default, the form kept reporting an error every time a value was entered in the address field. The validation process - the checking function which confirms that an email address is legitimate - should only kick in when the user hits ‘return’ to move to the next field, or the ‘send’ button, but here it was being triggered while they were still typing. It was a completely cyclical, unwinnable loop. If it was going to validate the field's value on every key press, it should at least display a cautionary color until the user has finished typing.
I wonder if that form was designed by the same guy who hijacked my meeting. Instead of listening and responding to the user, it simply shouted ‘YOU’RE WRONG’ over and over again. The form gave my uncle no chance to do things right, and he could learn absolutely nothing.
I know it's not a valid email, let me finish typing.
That message may be frustrating, but it’s no worse than plenty of others. From the pop-ups which scream “INTERNAL SERVER ERROR” without giving any solutions, to the jumbled jargon-fests which sap our will to live with their ‘value states’ and ‘unregistered protocols’, we’ve all been on the wrong end of one of these messages at some point.
Yet my personal favorite is what’s known in some circles as a ‘dead end message’: the classic “sorry something went wrong” which pops up after you’ve spent five minutes filling in the form and doesn’t actually tell you anything. Ok, I get it. Something is wrong. But what? Did I spell a word incorrectly? Did I leave a field empty? Do I need to use a different username? Do I need to remember that ‘85th July 2134’ doesn’t exist in the Gregorian calendar?
This example is particularly grating because it’s so lazy, so inconsiderate. The designer or developer could make life so much easier for their users with just a bit of effort; by choosing to keep them in the dark and insulting their intelligence, they’re telling the users to go and find a different product.
As designers and developers, we need to remember that our users are human beings and make sure we treat them with respect. Error forms are like conversations and, when something goes wrong, we need to imagine we were talking to someone in the flesh. If someone came to you in person to report a problem with your product, you couldn’t brush them off by shrugging your shoulders and saying ‘something went wrong.’ So why should you get away with it in electronic communication?
Handling Routine Errors
Thankfully some errors are mercifully easy to predict. We’ve already covered two particularly common examples: users entering an email address incorrectly or getting a date wrong. Others include mistakes in the URL, a dodgy internet connection or an incorrect password. Developers should have routine strategies for each of these occurrences.
For any UX designers reading this article, here are five fundamental points to bear in mind:
Display the information at the right time. Error messages should only be triggered when absolutely necessary. Don’t inflict my uncle’s ordeal on your own users: give them the chance to make the error - and fix it - before punishing them for it.
Display the information in the right place. Users don’t want to be scrolling up and down the page to find the reason their page has frozen. The error message needs to be accessible, quickly available, and unobtrusive.
Give as much as advice as possible. Users don’t need forensic detail - most of them won’t be designers or programmers - but they will always appreciate basic tips on how to redress the error, or at least try again.
Use the right colors. Even if the error message disrupts your precious color scheme, don’t worry. Design is important, but a clear, effective user experience is essential. Without a good user experience, pretty color palettes are meaningless.
Use language for human people. Us tech folk might known what “EXCEPTION: NULL OBJECT” means, but the average person probably won’t. If you think the problem is difficult to convey in human words, try explaining it out loud to someone. Maybe you’ll find your users understand what you’re saying after all.
Handling Exceptional Errors
Ok, so we’ve covered the simple part of the error handling process. We’ve picked off the low-hanging fruit, the stuff that’s easy to fix.But what about the inexplicable stuff? How do we prepare for unique events - or, in other reports, how do we give an ordered response when chaos strikes?
As a UX/UI designer specialising in web and mobile applications, I’m always trying to consider different ‘corner cases’ - engineering-speak for an error which occurs when weird stuff happens. But with the proliferation of different smartphone devices, the ever-increasing complexity of our everyday applications and the growing number of ways users access content online, there are more potential problems than ever.
To give you an idea of what I mean by unforeseen eventualities, here are some common types of error I’ve seen recently:
URL exceptions. Users can access an app or website by a number of different doors. They may be organic users (directed from Google), referrals (steered via email campaigns or social media) or product users (pushed from a product they are using). This can causes problems with certain URLs: for example, a referral user might click on a URL via an email, only to find the product is only available to organic and product users.
VPN clashes. Millions of people use VPN filters to connect to servers in different countries, often to stream TV from overseas. The technology is legal almost everywhere in the world but it can cause problems, notably by corrupting URLs. Another common problem is that users try to click thru a landing page which is blocked by their VPN server.
Cloud Servers. The Cloud has enormous potential for saving on data storage and facilitating shared working, but it can also be extremely complex. If you enter your Cloud storage area via a browser and delete a document manually, your product won’t be able to reach the document again. Trust me, this has caused all kinds of confusion.
Product Upgrades. If a developer builds a product for the tenth generation of a particular device, what do they do about the users who are still on the first iteration because they never wanted to upgrade? This can lead to serious issues as older devices reject newer applications.
Server failure. If a server-hosting company experiences an outage, there’s nothing a software developer can do about it. Their product will inevitably crash and they’re the ones who’ll have to explain it to the user. The developer may also need to update their product in accordance with a new server, and this can also lead to down-time.
Whatever the nature of the problem, the user is expecting an explanation, along with guidance on how to get over the bump. So developers need to ensure they give the error information quickly, clearly and truthfully.
People appreciate honesty, particularly speedy honesty, and most are reasonable enough to understand that every product has problems from time to time. Also, don’t be afraid to use humor - some of the best error messages I’ve seen have made light of the problem with wit and originality.
Zapier use amusing messages when waiting for other services.
Adapted to the Audience
But, if you’re building an error message, make sure it’s tailored to the situation. If the app or website is crucial to the user’s daily life, or it performs a particularly serious function (like a healthcare app, for instance), the user probably won’t be laughing when it goes down, so humor might not go down well so well. Likewise, you need to consider the audience: if the product is aimed at teenagers, the design might be fresh and colorful. But if it’s a product designed for older people, a more mature design might be in order.
Then you’ve also got to consider how your users are accessing the product. If they’re coming via mobile, it might be best to send the error message via a push notification. If users are coming via the web - a modal or toast-style notification may be more appropriate.
So the more info a designer can glean about their user base, the better. A couple of years ago I worked for a well-known anti-virus company and we divided the user base into different types: some users had the mobile version, others desktop. Some were using the free version, others the paid one. My colleagues and I devised a different approach to each group, creating a bespoke error handling protocol for each one.
Most importantly of all, designers and developers need to be thinking constantly about possible exceptions to the rules they create, glitches in the product they’re moulding. These thought experiments will ensure they’re already a step ahead when the error arrives. No application is perfect and there will always be random errors, but a good designer always knows to expect the unexpected.
For more on this subject, check out this recent blog post from the CTO of our sister company Bugfender, apologizing for some downtime issues on their platform. Jordi clearly explains what the problem was and how they went about solving it, even offering open access to the dashboard activity monitor. The article actually inspired me to write this piece; hopefully it will prove equally illuminating for you.
Because acknowledging and saying sorry for your errors is also a way to Handle Errors.
This article was original posted on our blog.
Top comments (0)