usability

Do not click Stop or Reload

On the Fedex Shipment web application, in fine-print at the bottom of the page:

Please note: Click the Ship button only once. Expect some delay due to transmission time. Do not click Stop or Reload; it may cause a duplicate shipment transaction to occur.

This is frankly inexcusable.  If the form doesn’t appear to work, the user will inevitably click on the button more than once.  The code should accommodate this behaviour, not weasel out of it with small print. In developing the form there was an important acceptance or test case left out, that for monkey behaviour.

Where’s the call to action?

On logging in to your HSBC Hong Kong personal bank account the customer gets a brochureware spashpage promoting HSBC products (why no account summary?).  To access their accounts (the reason the customer has gone to the trouble of logging in) the primary call to action is in a box on the right hand side of the screen.  It’s the <Show> button next to gray-on-gray text “My Accounts”.   The strongest call to action is to the ‘new trading site’ Stock Xpress.  It’s a small point, but a call to action as important as account access should more prominent and be the focal point, not an easily missed button.

A new page

This blog was getting tired in its design so I’ve given it an overhaul, including introducing some widgets.  (What an awesome piece of software WordPress is).  I’ve also added a new page with a bunch of published papers.  some classics in there (if I do say so myself) such as “Heat stress in night clubs” and “Occupational disorders in Ghanaian Subsistence farmers” !!.  The rest of the dancingmango site was not built using wordpress, so to update it all in one go would be time consuming and of little value.  OK, so there is inconsistency across the site and as a UI guy that hurts, but it is one of the trade-offs that needs to be made.

Users is a dirty word

Language matters.  How you describe something frames your reference.  One of the problems with so much software is that it is designed for generic “users” (typically UML stickmen) who may also have roles, but don’t have lives.  Why this obsession with users?  Everybody “uses” things.  Surely the important thing is to understand the nuances of that usage, and that means thinking about real people.  Josh Bernoff wrote a while ago,

Nobody talks about users of dishwashers, or users of retail stores, or users of telephones. So why are we talking about “users” of computers, browsers, and software?

Try, just for a day, to stop using this word. You’ll be amazed at how differently you think about the world.

Stop thinking about “users” and start thinking about people.  Personas are a good way to start doing this.  Get all your stakeholders thinking about the people whose lives will be touched by the product that is being developed.

Jeremiah Owyang updated his model of what web strategy is. It’s a cool model and worth a look. One of the things he has done is changed the word “users” to “community”.

One of the comments from Connie Bensen reads:

“I recently had a discussion about verbiage on our corporate website & heard the phrase ‘those words are industry standards’. Well, customers don’t know them. An analogy from the library world is that I took down the sign saying ‘periodicals’. It now reads magazines. (a shift towards making things customer friendly)”

I like that.  It is a subtle change, and when I’ve argued with colleagues in the past about the difference between users and customers and consumers they just don’t see the point.  What is wrong with users, after all it is the language of the industry.  Yes, that maybe, but it is not the language outside our industry and they are the people that we build applications for.

Where are the missing floors?

Lift panel with numbers missing

It is fairly standard practice in Hong Kong for buildings to have no thirteenth or fourteenth floors. They are considered unlucky numbers. Not sure what happened to the first, second and fifth floor here. And back-to-front button numbering that is neither in the telephone format nor the phone format. There’s a couple of lessons to learn here; when designing human-technology interactions consider cultural norms and existing design stereotypes. (Sorry, its the Human Factors conditioning in me that notices such things).

Cross cultural considerations at the Sandwich bar

In their paper Content preparation for cross-cultural e-commerce: a review and a model, Liao et al. conclude that (1) Westerners pay more attention to information about product components or contents than East Asians and (2) East Asians pay more attention to information about price… than westerners. This is in the context of eCommerce in “present[ing] appropriate information content to facilitate consumers’ decision making”.

A practical example of this in the bricks and morter world can be seen at this Sandwich bar in Hong Kong.

Sandwich bar counter

Clearly modeled on the western way of buying sandwiches, the counter layout supports the customer selecting the product (sandwiches and fillings on display) moving on to the cashier at the end of the counter to pay.

This isn’t the way things are done in Hong Kong where money comes first before the product. “Please place your order at the cashier”… before dwelling in front of the display cabinet. This results is congestion around the cashier counter and poor workflow and a slow and tedious customer experience.

Sandwich bar or internet offering, consider cultural differences before transferring the concept and content.

Let common sense prevail

Me: “Hello, I’d like to book a flight back to London on Thursday please”.

BA: “Certainly. BA 28. Midnight Thirty Five.”

And that was it. No friendly warning, so close to doing this again.

If I ask for a flight on Thursday, common sense suggests that the fact that the plane is scheduled to depart 35 minutes into Thursday, and I need to be at the airport at 10pm on Wednesday, then it really isn’t a Thursday flight. Not being explicit and clear with this is rude business.

CAPTCHA: a barrier to entry

When a customer starts completing an application or registration form it demonstrates they are committed. It therefore makes sense to pay attention to the usability of that form. But how often is the content of the form considered? Are there content barriers in the form that prevent customers from completing it?

Marcelo Calbucci (Via Luke Wroblewski) describes a barrier that everyone assumes just has to be there so it is not tested: The CAPTCHA. When the team removed the CAPTCHA from the Sampa.com registration form they recorded a 10% increase in conversion rates. Marcelo writes “we created a set of tests and rules that will make us not display a CAPTCHA about 99% of the time” (interestingly when I looked at the page I got the CAPTCHA). A 10% increase in conversion is not insignificant, and probably more than outweighs the additional effort to implement an alternative solution.

What the customer wants

I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.

Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.

I want an intranet portal“.

No, you don’t. You want a place where your employees can share files and documents.

I want a google search appliance“.

No you don’t. You want to be able to find documents quickly and efficiently.

Worse is when vendors try and force products onto the customer…

You want an integrated BI toolset“.

No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.

OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.

I’ll write more about this in the future…

Will corporate websites remain spotty teenagers or will they grow up to be beautiful?

In the corporate webspace most design is little more than mediocre. Interaction design has changed little since coporations first realised that this is a channel thery should exploit. Web 2.0 is slowly making in-roads with basic use of Ajax functionality, but there is nothing that is really breaking the mould. Despite its infancy (for most organisations ‘e’ is barely 10 years old, Amazon, the granddaddy of eBuisiness is only 13, born in 1995), conservatism rules; the corporate web is just not growing up. It would be easy to blame the technologists for being risk adverse- for having invested in architectures and frameworks that do not allow innovation. REST and all that declarative goodness may be great, but of little interst if you have invested in a propiertary framework that does not support it. But the business is also responsible for tardy innovation.

It doesn’t know what is possible. A miss-understanding of accesibility clobbers rich interactions; “no javascript” becomes the mantra, despite the guidance being “provide alternatives” and progressive enhancements making basic and rich interactions possible with the same code. And maybe as usability testing becomes the norm, and testing concepts with consumers throughout the product lifecycle is baked into the process, this is acutally the final nail in the creative coffin. Let me explain.

When you are developing new features or propositions it is only right that you should conduct market research, talk to your customers and get feedback to refine your ideas. But sometimes you need to ignore what you are being told and challenge the perceived wisdom. Imagine the scenario; you are developing a social networking site. You recruit a bunch of consumers to participate in user testing sessions. They match the socio-demographic profile of your target audience, they use the internet more than five hours a week. You let them loose on your concept boards and prototype. They like what they see, they like the blogs… but commenting? The feedback is that none of them would leave comments. So what do you do? Kill the commenting on the basis that the users who matched your “average” profile would not use this feature.

I’m not saying that if you are building a conventional, transactional experience; a retail shop, a financial services provider, you should not test the proposition with users that match the target profile. But beware that they will steer your thinking into the realm of the ordinary, the expected and the average. Try testing it with trend setters, gamers, teens, mybe even anti-personas to push the boundries and harvest real innovation insights.

And maybe testing the proposition is not needed at all. But don’t leave the design to the comittee or the accountants. Sometimes it is more important to have a real visionary driving the product development. Apple is a great example of this, no more so than with the iPhone bounce. When you scroll down a list, when you come to the end, the last item “bounces”. Where’s the “business value” in this? Isn’t this gold plating in the extreme? The development of this bounce will not have been for free, it will have come at a cost. This could have been a financial (more development effort) it could have been at the expense of another feature, or it could have been time. In most organisations this would not get get through the design by commitee. Apple can do such great things with their UI because they’ve got a visionary at the helm who understands the importance of good design and is passionate about it, and their customers become to expect it.

3 of 4
1234