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.

I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.

Just one more correct answer and I may have got my average up to 94.52631578947369%!!

To be fair, at least they did not need 14 decimal places to tell me how long the course took.

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.

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.

If you’re getting feedback, realize that the person must care a lot to have sent it.

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.

The bottom line is that a lot of the time it’s OK to create a solution that solves 80% of the problem. Always remember that shipping is a feature.

Quote from an article: Duct Tape Programmers and the Culture of Complexity in Software Projects

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.

“There is a tremendous amount of spit and polish that goes into making a major website highly usable. A developer, asked how hard something will be to clone, simply does not think about the polish, because the polish is incidental to the implementation. ”

The quote was part of a response to a suggestion to duplicate Stack Overflow, and thus save subscription fees to the original. You can read Benjamin’s entire rebuttal, or Jeff Attwood’s succint commentary for more details. Jeff’s article in particular does a good job in summarising what “polish” entails, and by doing so makes it clear how such polish is integral, not incidental, to eventual success.