Tag Archives: usability

UI Rule #92 – Don’t sacrifice the useful to fit your design

Everybody needs a lego moleskine. Comparison shopping at the UK Book Depository proved troublesome because they decided to cut the product title short, removing the information that actually differentiated the products being chosen:

Hard to tell which one to choose when everything you want to know about the choices is unavailable. Should I get the “Lego Y..” or, mmmmm, the other “Lego Y..”?

Compare to Amazon, who manage to fit the full name in without issue:

If you’re going to allow a certain number of characters for a value, assume all of those characters may be important at some point. And make sure somewhere on your interface you let them all get their moment in the sun.

Shipping is part of the product cost

When shopping online, while comparing product costs is important, often what I need to compare is the total ‘cost-to-the-door’. This is particularly the case when shopping at overseas sites – something those of us in Australia do most of the time.

Different sites/vendors have different rules about shipping. And the variations in shipping options can easily negate any variation in original price.

So as a general request to web store developers and vendors, please allow visitors to determine the shipping cost prior to checkout and/or prior to registration. Don’t make me sign up and complete all my mailing details before I can determine the actual price.

How to do it

Really have two options if wanting to be upfront about shipping costs.

(1) Include shipping in the initial cost

This is the UK Book Depository model. One price is quoted for any item. And that price includes delivery.

Quoted cost = final cost to my door. Simple.

Note technically the site states delivery is free worldwide. But we all know that really means they just include it in the initial price. That’s why they’re not the cheapest on first quote. But the convenience of knowing the final price up front far outweighs any interest in comparing with other stores. I’m not going to search for the same book in Amazon (for example), add to basket, check out, log in, enter shipping details, etc, just to get a price to compare with the first number offered by UK Book Depository.

Another consequence of including delivery in the initial cost is it removes any order friction around postage optimisation and bundling. For example, Amazon postage appears to get cheaper the more books I order, with the consequence that if I want a book I’ll add to my basket but not actually order until a few more items in there to lessen the postage overhead. But then what actually happens is they sit there long enough for me to lose interest and remove them. With UK Book Depository there is no benefit in bundling orders together. Which means all orders get submitted immediately. Before I’ve had time to reconsider.

(2) Provide a mechanism to quickly determine shipping costs

Simple tool to estimate shipping. Close enough is good enough at this stage of the purchasing process.

If shipping cannot be bundled, then allow me to calculate (or at least estimate) the shipping before entering any personal information. How much do you need to estimate shipping? Nothing more than a zip/post code and/or country. And I won’t be upset if I have to enter that twice; once to estimate and once to actually checkout.

For example, look at how Think Geek does it. As soon as I add an item to my basket, I get a simple shipping calculator. This gives me a figure close enough to the final value that I can immediately determine whether to progress with the order or not.

How not to do it

Already stated what not to do: don’t make me complete all my order details before I get a figure for shipping.

Don’t make me sign my life away before quoting postage.

To that essential rule, I’ll add an extension particular to us overseas buyers. Don’t make me complete all my order details before you tell me that you cannot ship the requested item to me. Too often some protectionist racket prevents requested items being sent overseas. Nothing more annoying than completing your forms before being told “sorry, not available in your country”.

Stop this UI Madness: Confirming visible fields

Enough people.    Please stop building forms where I’m asked to confirm a field I can see quite clearly.  Like this example:

Or here’s another example. Which shows right and wrong use of duplicated fields and (horror or horrors) disables cut&paste.

The only requirement for a confirmation field is when entering a value that is not visible, i.e. a password.  For anything else I can see the value I’ve typed and “confirm” it’s correct without retyping.  Don’t make me repeat myself.

If worried about validity, beef up your error-checking.  Don’t delay me with pointless re-typing (or more usually, cut&pasting).

And another thing.  While making me repeat myself is bad enough, making me repeat myself and then disabling cut&paste in the repeated field gets you your own special corner of hell.

Quote of the week (27 September)

From Joel Spolsky, quoted on UX Myths, found via Barbarian Blog:

Usability is not everything. If usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans-serif, and easy-to-find bathrooms. But nobody would be there. They would all be down the street at Coyote Ugly pouring beer on each other.

Bad usability calendar

I’m a firm believer that one of the most effective ways to learn is to study mistakes, yours or other peoples. Which is why I used to live at Web pages that suck when first starting out in developing web content.

Just come across a similar, humoured, approach to usability in the Bad Usability Calendar. Highlights a different usability issue for each month. Which means it’s not much use as an actual calendar but very useful as a quick usability prompt.

Granted a bit late now to pick up the 2009 edition. But watch the space for the 2010 copy.

Usability for the enterprise

In many enterprises, usability, if it exists at all, remains an isolated and inconsistent experience. The amount of importance attached to user interface design or the wider user experience often varies according to the level of epiphany within individual project managers or developers. Indeed in some large development projects I’ve seen usability commitment (and commensurate quality of the output ) vary between developers on the same project.

The challenge for the enterprise therefore is establishing some consistent approach to usability across the organisation that

  • Recognises the varying usability needs of the project (the steps appropriate for a command-line interface used by 3 senior administrators must be different to those for a GUI used in front of customers across 2,000 bank branches)
  • Recognises the varying skill and exposure levels of the involved parties
  • Works with the above two constraints to maximise the cost-benefit of usability activity.

In brief, this post explains an approach that we implemented for one organisation that works very well in engendering usability with minimal up-front upheaval.  In essence only three steps:

  1. Make usability assessment a mandatory step within the project planning process
  2. Simplify and distribute the fundamental usability activities
  3. Standardise and centralise the advanced usability activities

Make usability assessment mandatory

The trick in this step is to make the assessment of usability needs mandatory, but not the conducting of any activity. The purpose of the assessment is solely to determine what activities are appropriate for the project.

This assessment can be easily quantified via some form of checklist or score sheet, tailored to the particular needs of your organisation. Have your project managers review their project against your checklist and output a score and/or recommended level of usability activity.

In developing your score sheet, here are some attributes to consider:

  • Audience: internal or external users? Education/experience levels? Prior exposure to tool/concepts? Number?
  • Platform: web-based vs. native app?  GUI vs. mainframe/terminal?  Availability of support resources (online help, tooltips,..)?
  • Timeliness:  How time pressured are users?  Is it critical to complete fast?  Are customers watching?
  • Location: for use in a quiet office or on a noisy factory floor? To be used outdoors? Underwater?
  • Risk: what are the implications if the customer gets it wrong? To them? To us? What’s an acceptable error rate?
  • Alternatives: availability of training developers? or classrooms?

In its simplest form, have your project manager score their project on a 1-5 scale for each chosen attribute. Then get them to compare their total with your own guidelines (a la most personality quizzes in the Women’s glossies):

  • If you scored < 5, your project has low usability requirements. We recommend (a).., (b)…
  • If you scored between 6 and 10, your project has medium usability requirements. You must complete (a..). We recommend (b)…, (c)…,  etc

The checklist provides the project manager with a list of required activities, and a list of recommended activities.   Give some flexibility since human nature (and most project managers are human) welcomes a semblance of control and personal decision-making. It also accommodates differing levels of commitment to usability within your organisation and encourages those who are ahead of the curve and recognise the value of completing more, rather than less.

In outlining the required and recommended activities, also provide some estimates of the work effort, scheduling and resourcing needs. This gives the project manager all the information needed to produce a project plan that correctly integrates the new activities in the tasks to follow.

Note: These implementation guidelines need to reflect your organisation’s own development methodology: waterfall, agile, etc.  The aim is to make it easier for the project manager to add these activities (and mitigate risk/fallback to them once project is implemented) than to ignore them.

Simplify and distribute the fundamental usability activities

Within your list of required or recommended usability activities there will several that are so fundamental you’d be recommending them on most projects. They’d also be activities that most project managers would say they do already (to some extent). These are activities like:

  • Contextual inquiry
  • Paper prototyping
  • Design walkthroughs
  • Usability walkthroughs, etc

Such activities can be defined to such a level that project teams can take responsibility directly for their completion. The role of the central usability team is to support them in that regard by:

  • Providing clear instructions on how to most effectively conduct the activity
  • Developing and issuing related resources or tools (for example, interview checklists, prototyping templates, etc)
  • Offering in-house training or support

Where the line is drawn between the fundamental and the advanced activities will vary from organisation to organisation. And will vary with time. However initially focus on those activities project managers would expect (or believe) their project team is already completing themselves. Even getting to a standard definition and implementation of a usability walkthrough would be a great improvement for some organisations we’ve worked with.

Standardise and centralise the advanced usability activities

When the usability needs for your development become significant it is time to call in the big guns:

  • Interactive prototyping
  • Heuristic evaluation
  • Formal evaluation
  • User survey, etc

These are the skills your project managers/teams are not yet skilled enough to conduct themselves (heuristic evaluation), or that it is easier to always manage from a centralised location (user survey).

These may also be skills that you would want to always retain central control over. This is particularly the case if working with external developers/vendor companies. As part of the contract you’d be happy/expect them to conduct the fundamental activities but would manage the advanced activities in-house to (a) ensure they are completed satisfactorily, and (b) to make the outcomes a guaranteed part of the development obligations.

Note: Longer term the organisational goal should be to inculcate usability so deeply into standard project management practice that you are able to push activities “down” from this centralised/managed position to the fundamental. There is no reason why your usability lab cannot become another resource (like an OHP) to be booked for project meetings.

Alternatively, investigate replacing some of the complexity with technology. For example a tool like allows anyone with a Mac to conduct an in-depth usability evaluation complete with recordings of on-screen behaviour and user reactions/responses. No need to buy that two-way mirror!

Conclusion

Usability is far too important to leave to personal preference. Make identification of the need (and risk) standard for all projects and you’ll be in a position to use that identified need to drive adoption and the subsequent performance benefits.