As a company, we aim to give online businesses greater visibility into what their customers actually see and experience online.

And time and time again we see companies shocked by the fact that, often, their websites just aren’t designed with their customer in mind!

Some of the best examples of this are site error messages. Here are some of the more bizarre error messages I’ve seen over the years:

  • [Exception in:/refund/spage/mainconfirmrefund.jsp] null
  • Service Unavailable - Zero size object reference #15.36a21645.125511894.ffeab82
  • A system fault has occurred. Mutliple attempts have been made to access the same process
  • We're has not properly responded to your request.
  • You can use your browser's back button and resubmit your request now. In many cases, this second attempt will be executed fully. Or, you can try again in a few minutes.
  • If the problem persists, please contact XXXX and provide PROBLEM CODE < 305 > Reference No : null-24-16072007-41297 
  •  Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
  • Exception Details: System.Data.Odbc.OdbcException: ERROR [HYT00] [Microsoft][ODBC SQL Server Driver]Timeout expired

If you don’t have a techy background, these will all read like total gobbledygook, but they crop up over and over again. How many websites still generate error pages with ‘404 ERROR’ emblazoned at the top? What does this mean to a customer? What message does it send?

Based our experience over the years, when website visitors see unintelligible error messages like this, they simply abandon and, to be honest, I don’t blame them!

Understanding and aiding the customer experience

There is a fundamental customer experience issue here. Giving visitors clear and easy to understand instructions is surely usability 101.

If, for example, you want customers to fill in a form, you have to make it very clear. This means identifying which fields are mandatory and which are not. And if you need customers to go back and add information they forgot to fill in, you must make it clear where they went wrong and the steps they can take to rectify the situation.

One specific example comes to mind: the customer had neglected to fill in their first name and surname in separate fields so the website displayed the following message: “Invalid Operator in Field”. How confusing is that?

Write your sites (and error messages) for human beings

The problem is that many of these error messages are coded by IT into underlying ecommerce platforms and content management systems. Marketing never sees them. And they just never get changed.

So, have a think about how your site serves up error messages and ask yourself whether they were written by the IT department or by marketing.

If a customer is served up an error message, whether it was their fault or not, it is worth helping them if possible. Otherwise they’ll just go elsewhere and may never come back!

Geoff Galat

Published 11 April, 2011 by Geoff Galat

Geoff Galat is Worldwide VP of Marketing at IBM Tealeaf and a contributor to Econsultancy. 

25 more posts from this author

You might be interested in

Comments (12)

Save or Cancel

Oliver Lawrence

Of course, these messages ought to have been clearly specified as part of the design process, and then the user interface should have been thoroughly tested before release. Rocket science it ain't.

over 7 years ago


Jason Wright

That's good advice but startlingly obvious.

over 7 years ago


Martin Belam

I agree with you up to a point, but there is also a case for providing more technical descriptions of error states. If your user phones up a helpdesk, and says "I'm getting an error on your website", and you ask them what error, and they say "It is a picture of a fluffy sheep with a sad face saying, wow, we are really sorry we let you down" its quite hard to help them solve the problem unless it also says something that allows you to help them with next steps for that specific case.

over 7 years ago


Nick Stamoulis

Content should always be written for humans, but who really thinks about applying that rule to error messages? Martin has a point though. There has to be enough information that technical support could determine what the problem is, yet the user also needs some idea of what is going on.

over 7 years ago


Seb Tucknott

A properly built error system should log and notify support anyway so you don't need to inform the user of any fault codes. Even say on the error page that you have been notified.

It is true error messages get overlooked. I find the most frustrating the ones which say your input is not formatted correctly. When it would take 2 secs to take into account that formatting in the system.
For example entering price, it's not hard to remove £ signs and comas rather than asking the user to do it.


over 7 years ago


Michael Batey

Sometimes you can see that people have tried to write human-friendly error messages, but not quite 'got' it: I recently encountered a login error that said "The credentials you provided cannot be determined to be authentic."

over 7 years ago



You can tell that this article was written by a marketing person and not a developer. 6 of those error messages are almost certainly not written by your IT team or in fact by anyone in your company. They are errors thrown up by the programming language or the server itself and they will happen. Those messages are often symptomatic of a larger underlying problem that needs to be addressed

There are steps you can take to try and avoid or hide these messages, but the truth is they will occur in unexpected places for unexpected reasons and as a result will sometimes appear on your website. It isn't neglect or incompetence and it certainly isn't IT trying to be deliberately obtuse. The best thing you can do is make sure you have good procedures in place to fix the bug and ensure it doesn't happen again.

Now if this was an article criticising people who throw out error messages like "Invalid Form Values" without indicating which form field is wrong and why it is wrong then I could get behind it :)

over 7 years ago


Tim Leighton-Boyce

I couldn't agree more with the main theme of this post, although I think that Leigh makes a valid point.

One thing I would add is that it's very valuable to track the number of times your error messages are seen. Even when you have improved the content, it's illuminating to see what's causing problems for visitors. You also need to keep a 'first-thing-in-the-morning' eye out for 404s caused by people posting external links containing typos etc.

In the days when analytics tools used server logs this was easy to do. These days many tools may require a bit of custom tracking code.

If you'll forgive the link dropping, I've written more about doing this with Google Analytics, where the Reverse Goal Path report really comes into its own for analysing "how on earth did they get there?" issues. The comments thread also contains some relevant discussion of pageviews vs events and how to structure URLs so that the Content Drill Down report works best for getting summarised numbers.


over 7 years ago


Cheryl Crichton

Error messages, confirmation screens and automatic email responses often get forgotten. I love great design and functionality, but 'what happens next' from the customer's point of view so often gets forgotten. I constantly annoy people when these types of messages are high on my list to get right. Just as important as a clearly sign-posted home page/navigation.

about 7 years ago

Geoff Galat

Geoff Galat, Vice President, Worldwide Marketing at IBM Tealeaf

Spirited discussion all, which is great. I appreciate the feedback from all of you and the discourse is compelling.

A few comments in response, if I may:

The key thought is to think of error "messages". The point is to inform someone of something relevant, and to a user there is no relevance to something written in jargon, technical or otherwise. To say that often you need to expose this information, or that the it is not the content provider but the platform itself that is producing the message is missing the point.

The real question is "are obtuse error messages or codes interfering with customer success (however you measure that - conversion, adoption, engagement, etc)"

From the user perspective, there is little if any value in me seeing a technical error, and as Seb points out, these messages or conditions can (and should) be logged other places. And, Leigh, these "platform" messages can easily be hidden and replaced by informational messages with meaning.

At end of the day, we should not put the customer in the position of becoming our diagnostic tool. And, frankly, even armed with messages like I posted, they are really not very good at that role anyways.

The idea that these messages are at times needed in order to diagnose makes a very large fundamental assumption - that customers tell you the message even existed or was displayed.

Our experience has been the opposite, that most customers not only don't tell you of the issue, they abandon your site (maybe permanently) or they share the experience via a social media outlet. Think of the ramifications of that...:-)

Check out the resources here from a Harris Interactive Survey Tealeaf commisioned to get a sense of the extent of issues and actions users take.

eConsultancy is conducting a survey right now on a similar topic, expected results soon.

about 7 years ago


Daniel Simms

I Agree with this article but this is something that any decent developer should already be doing and I think that Leigh makes a very valid point. Saying this I agree with Geoff that their is pretty much no point in displaying error detail to a customer if you can avoid it.

Putting expected errors to one side as this is pretty simple stuff, The solution we go for is to provide a generic catch all user friendly error message for unexpected errors then send the full logging details to our suppoort email box and store them on the server, this way we get all the detail we need and the customer is disturbed as little as possible.

As a final note, Good error handling is sign of a quality developer and you get what you pay for, if your paying peanuts for your complex website you cant expect this level of quality.

about 7 years ago


saiffuddin marchant


almost 7 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.