As much as web design is about big things – getting your site structure right, creating a compelling visual design, ensuring your code doesn't cause browsers to copiously vomit error messages on an absurdly regular basis shortly before committing seppuku – it's also about little things.
A good site is polished and finely tuned, taking care to include and refine content that many users won't ever see, because the savvy designer knows full well that some of them will.
A case in point: the humble 404 error, an HTTP standard response code that's shoved in your face when a browser communicates with a server and promptly discovers that what it was looking for isn't there.
There are a whole bunch of reasons why a user might happen across such an error message, but they usually arrive because of one of two reasons: user error or webmaster error – unintended or otherwise.
Spulling mistokes
Probably the most common reason for a 404 is that someone with sausage fingers (or, indeed, perfectly normal fingers, but that's a much less funny image) hammered away at the keyboard, hit Enter, and failed to realise that the URL they wanted doesn't actually exist due to, for example, cunningly spelling 'contact-details.html' with some exciting extra characters that really shouldn't be there.
Net result: the server unintelligently goes "We're all out of cpntact-details.html, I'm afraid" and spews out a 404. The other issue is your fault (assuming you're a designer, developer or general website-making person), if you've linked to something that doesn't exist (due to some amazing sausage-finger handiwork of your own) or if a once perfectly valid URL is now a dead link, due to you moving content about.
Depending on your hosting environment, the 404 can take on all manner of guises, most of which are somewhat unhelpful. On IIS, you often get an error message that makes perfect sense to web designers, but that will make the typical user squeal in horror at its barrage of technical information.
Apache is rather more blunt, uttering 'Not Found' and scant other information, doing the rough digital equivalent of slamming the door in your face and grumpily muttering about "when it was much quieter around these parts and you didn't keep getting interrupted". And if you're using Internet Explorer, there's a good chance it'll hijack whatever it should be showing to instead display Microsoft's 'friendly' error message anyway. (To be fair to Microsoft, its message is friendlier than the standard one, but hijacking default behaviour is always reprehensible and makes us angry.)
Creating custom error messages
With a little thought, most of this nastiness can be avoided, since it's simple enough to create custom error messages for the vast majority of hosting environments. This means that instead of seeing whatever garbage a server spews out, or whatever branded message your host has decided to apply (several hosts now cunningly hijack 404s to present an equivalent page with a URL back to their homepage, rather than yours), you get to decide exactly what appears on the error page. The important thing is to ensure that whatever you present is a lot better than what exists by default.
Jakob Nielsen more or less suggests that because default error messages are so appallingly bad, the very act of changing them at all is an improvement. However, he cites as a starting point taking into account three basic guidelines.
First, the error message must be written in a language that can be fully understood by everyone, including non-technical users, and in a way that doesn't imply what's happened is the user's fault. Secondly, the message needs to detail precisely what's gone wrong. Finally, suggestions need to be made regarding how the user can deal with the problem at hand.
A quick scoot around dozens of 404 pages shows that the majority of sites don't in fact take a great deal of notice of such advice. Some actually go as far as to call the user a ham-fisted idiot, which might just about be OK for a cartoon site for teens, but it's not going to win much praise for a shopping portal.
Too many sites also have a seriously geeky love-in, peppering their 404 pages with imagery and in-jokes that'd even make the typical B3ta aficionado wince and then request a claw hammer for uncurling their toes. (As a quick sidenote, the characters '404' are particularly overused as a design device, despite meaning nothing at all to non-technical people.) Most importantly, many of the pages simply aren't usable: they don't provide any indication of what's happened to get the user there, nor do they offer any means of helping them figure out what to do next.
Amazon's 404 page is brutally simple but surprisingly effective, and covers most of Nielsen's points in just a few lines of text. The user is told that the address entered is not a functioning page on the website, and a clear link is provided back to Amazon's homepage (along with a logo, which does the same).
Yes, the company could do more to help, but as a minimum Amazon's is a good model to follow. Play.com, by comparison, commits one of the worst sins in 404 world, by just redirecting you to its homepage instead of displaying any kind of error message.
The problem there is that a user might assume that the site itself is defective (rather than their typing or a search-engine listing) and go elsewhere. At the very least, it'll take a second attempt to get to relevant content, which psychologically makes people think negatively of the site that's being used.
If no-frills 404 doesn't appeal, others have taken their pages a bit further, with varying degrees of success. BBC News offers simple branding on a white background, and displays "404 - Page Not Found" in red.
Underneath, there's a clear explanation of why this page may have been arrived at, including a brief explanation of link conventions, stating that spaces and capital letters don't exist in BBC URLs. It also explains that the user can click the back button, and gives links to homepages and the BBC's full list of sites and services.
Note that the BBC provides a link to its sites and services, rather than nailing a site map to its error page. The latter was once considered good practice, but it can be overwhelming on an error page for lost users; nowadays, a diminishing number of sites use site maps in this way.
