Category Archives: service

Why waste such a valuable space?

I hate complaining.

Wait, that’s a lie; in fact I actually like complaining. I like looking at a problem or some sort of sub-optimal condition and say, if you just changed that bit, if you just dropped that thingummy, it would be so much easier for the people who come into contact with it. I make a living from telling people what is’t optimal in their product, service, website and then offer suggestions based on research, information from users, and solutions other people have come up with. I’m a bit like an iron, smoothing out the wrinkles of experience. *groan*

So, you might say, complaining is my job. Yes, I like complaining. I spent 15 minutes on the phone with Apple yesterday whinging about how even though it let me type spaces in my password, didn’t flag it was an issue in the error checking, and accepted my entry; it still failed my login attempts because my pass had spaces which they didn’t record. I’ve never met a coder who hadn’t read the XKCD Password Strength comic so there’s no excuse for not testing predictable use cases. Really.

But this post isn’t about Apple, it’s about a different music service.

Continue reading

Service delivery by bus

It is always a treat to be proved wrong and to have your preconceptions challenged. I had a common problem earlier this week and the company resolved it in a very commendable manner. All it takes is one employee going a little out of their way, sometimes breaching policy, to make a customer forget the inconvenience that required attention in the first place.

I am afraid that as a user experience consultant I often have to discover fault with sites or services, and from that, recommend improvements. That discovery phase occurred yesterday morning when my bus ticket got stuck in the machine that validates fares on the bus. No amount of repeated thumps on my part or presses on the eject button by the driver managed to dislodge the reluctant ticket.

the green ticket machine in a Sydney Bus

Apparently, the only way to reboot the machine is to reboot the bus itself, something he tried several times while waiting at a traffic light, with no luck. When I asked why he did not have a key to the machine, in order to dislodge stuck tickets, he good naturedly replied, “Good question, Mate!”

He asked for my mobile number to contact me later as he might have a chance to dislodge the ticket at Central Station. I handed him my business card, since that was easier than writing my number on the back of a receipt on a moving bus. I tweeted about it, received a few comments from followers, and thought no more about it as I settled into my latest report.

I assumed I would never see that ticket again, or, at best, would receive it in the post several months later.

Imagine my surprise when a fluoro-vested dude showed up at the office asking for me by name. Handing me my travel card not two hours after the machine ate it, he politely, and very diplomatically, offered advice on how to avoid it getting stuck again in future.


I would therefore like to thank both the bus driver and the representative who hand-delivered the ticket for supplying a great service to me. It really was jaw-droppingly wonderful to have that level of service, even if I do work close to the Central Station depot, they didn’t need to hand deliver it.

Many thanks Sydney Busses for hiring such great people! I’m not sure if this was policy (doubt it) as much as it was sheer enthusiasm (most likely) by the driver and supervisor (?) who went out of their way to deliver a great service.

test for failure, not success

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.

Availability request form

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.

Lack of availability at the Gladstone Hotel

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?