I’m visiting Toronto at the moment and had an experience with a boutique hotel and their website.
As you can see, their room request form is wonderfully simple and usable in design.
It was easy to use, clear and offered just the right amount of options to get the request in. Very pleasing. I’m willing to forgive the copy being sub-standard since the form is so straightforward and is exactly what I need from a booking request.
Unfortunately the message that followed was less than useful.
in text:
You requested:
1 () room for a 3 night stay, arriving on Thursday, October 14, 2010, departing on Sunday, October 17, 2010, to accommodate 1 adult per room.
Room Availability
.. Requested daily number of rooms is greater than maximum.
Click ‘Change Request’ to revise your selections.
I’m not sure what they think I might conceivably derive from this response, but what I actually did was book a room in another hotel down the road, where I could get the sort of room I wanted and the booking was straightforward, and more importantly, successful. I contacted the hotel to let them know of the error, trying to be helpful and the response I received was that the site was not “broken”. I was told the error arose because there were no vacancies on Oct 14. They did not explain why the error message did not say this. They did not try to discover where I experienced a problem, but to their credit, asked several questions to attempt to find me a room, albeit 2 days later.
.. Requested daily number of rooms is greater than maximum.
This clearly is a statement that was never tested with users, for I cannot imagine a test user understanding what went wrong here. Not only was the information supplied unhelpful, clicking either button (Change Request or Continue) produced an application error (Error:500) and stopped me in my tracks. There was no further progress possible. You should attempt to never deliver an application error to your customers and this article from Smashing Magazine might help give you inspiration on what types of response you can give. It shows 404 errors (page not found) but with some clever coding, you could also use it for application errors, like Twitter does when their servers are feeling a bit stressed, causing them to deliver the Fail Whale page. In fact, the Fail Whale is so popular it has it’s own fan club. You should be so lucky with an error page!
This to me was an obvious example of where user testing would come in handy, in particular, testing what happens in the system when someone tries information that produces an error or is outside of expected inputs. If I had changed my dates (not possible in this example) I may have received a better response from the site, perhaps.
It appears to me they spent little if any time working out what would happen if something went wrong and the system needed to deliver an error message. They also didn’t spend any time testing what messages would be delivered to users under different, normal circumstances, like when a room is not available for a desired date.
A valuable lesson is that when planning, building and testing, you need to make sure your communications are succinct and clear, and to test that your error messages make sense to they types of users who come to your site. In addition, you need to prepare for when things go wrong, when people break the bounds of expected or calculated behaviour, and not just when they make choices you are prepared for.
How much business or attention are you losing by not having thought of the errors deeply enough?
