"Reaction [beta]"

Seeing the signs 5 May 2006

"Danger! Beware! No entry!" ... Well I thought it was obvious. Still, it's surprising to see how many people either fail to heed these warnings or decide to chance it!

Here at Etre Towers our lift has just been reinstated after three weeks of servicing (and countless breathless dashes up three flights of stairs). Throughout the renovation a sign has been placed over the lift control panel at each floor, informing would-be ascenders and descenders that the lift is "Out of order". Nonetheless, on a near-daily basis I witness people lifting the sign and attempting to the call the lift. Sensibly the engineers have taken the added precaution of disabling the lift control panels - I guess to help stem the flow of occupants who could otherwise plummet to their deaths.

On the interweb we frequently come across a need to add seatbelts to a design (rather than just putting up more signs telling people that they shouldn't drive fast). One of our clients recently came to us with an online proposition they intended to launch that nicely demonstrated this...

In an effort to get their solution online quickly, our client concealed their offline processes behind a slick online interface, where customers could redeem their "Loyalty Bucks" on a variety of goods and services. As convincing as the front-end may have been, it was little more than a mask for the manual processes completed by our client's customer service agents back at base.

One of the nifty elements in the design was a JavaScript "bucks calculator" that advised users whether or not they had sufficient loyalty bucks to order a given product or service. The calculator was simple, informative and nicely unobtrusive - rendering a pleasant message above the submit button when users selected goods that they couldn't afford: "Unfortunately you are three Loyalty Bucks short of Kelly Clarkson's latest album. Please select another reward."

The problem was, our client didn't take any steps (on their server) to prevent users from continuing with or without sufficient Loyalty Bucks. In an effort to keep things simple they only implemented client-side validation of each user's order - reasoning that the odd-user who "tried it on" would be spotted when the order was manually processed back at their base. We, on the other hand, reasoned that unless users were actually prevented from continuing, a fairly significant number would almost certainly pass through the ordering process unobstructed, increasing the amount of manual intervention required to validate each user's order during processing. And, during our ensuing user testing study, it seems we were right.

Eye tracking analysis revealed that almost 20% of users didn't see the warning that they had insufficient bucks, in their haste to get their hands on Kelly's latest hits. While a further 15% seemed to see the warning but progressed nonetheless. Pretty worrying stuff when faced with a few hundred "Loyalty Bucks" orders to process every month.

Presented with this data our client realised that for the sake of a little extra development effort (and a little more time), they could tackle the 35% of orders that would require unnecessary processing by adding server-side validation to the site as well. Net result? Many (loyalty) bucks saved.

I'm unsure whether the same stats apply to the residents of Etre Towers, though if we did lose 35% of the team in a freakish elevator accident, the queue for the printer would be a lot shorter!

Next article: Five days / five heatmaps
Previous article: Ribbons and galleries

Bookmark this page

Add this page to your list of social bookmarks.

Trackbacks

To create a TrackBack to this entry simply append ping/ to the permalink URL for this page.

Send page to a friend

Enter your email address to subscribe to our free newsletter.
Your email address will never be sold or given out to anybody.