Usability heuristics for web development teams

Often when clients have a relatively low budget for usability testing, or a short amount of time in which to conduct it, an ‘expert’ or an ‘heuristic’ review will be run by an experienced usability practitioner. There are slight differences between the two, with the expert review entailing a less formal evaluation process than the heuristic review. But all things considered, they’re pretty much in the same ballpark time wise… So I suppose that means cost wise too.

There are a number of advantages in conducting either type of review. As I mentioned above, where resources are limited, they can be an effective and efficient method of assessing a site; the time and cost associated with recruiting, interviewing and paying test participants is negated. These evaluation methods can also be conducted very easily and consistently throughout the life of a site, providing a benchmark as well as a periodical health-check.

In conducting an heuristic review, a series of guidelines or checkpoints is used by the usability expert to assess a site (or application). In conducting an expert review however, these specific guidelines may not be utilised, with the practitioner relying on their expertise of general usability principles to review the site at hand.

Arguably, the most well known usability heuristics are those developed by Jakob Nielsen, who outlines ten rules of thumb. There are numerous variations of Nielsen’s ‘standard ten’ including an extremely detailed checklist developed by Deniese Pierotti for Xerox. Pierotti’s heuristics use Nielsen’s ten rules as a foundation, but then goes further by providing individual checkpoints specific to each rule. It’s definitely an extensive list of usability checkpoints, and one which I expect was developed for a particular environment.

The thing is…

I believe there are a whole lot of things that haven’t been considered in these lists. If we’re going to take a best practice, user centred, holistic, may the force be with you approach to web development, surely there should be a broader focus; and one that incorporates as many areas of front end development into an heuristic review as possible.

If we consider the Information Architect (IA), the ‘JavaScripter’ and the web standards developer, each of these roles has a great deal they can contribute to creating a better, more holistic set of usability heuristics.

The IA…

In 2004, Louis Rosenfeld published a list of heuristics for the IA where he said:

Every information architect should always have a set of favourite questions in their back pocket; they really do come in handy.
I categorize mine into groups that correspond to the five areas that a user is most likely to interact with a site’s information architecture:

  1. Main page
  2. Search interface
  3. Search results
  4. Site-wide navigation
  5. Contextual navigation

A couple of weeks later, he expanded on these by developing a series of heuristics specific to Search Systems . These are very specific, and don’t necessarily apply to every site or application. But what they do offer is an opportunity to build a more tailored and well rounded set of web usability heuristics. In summary, the search system heuristics focus on the review of:

  1. Locating search
  2. Scoping search
  3. Query entry
  4. Retrieval results
  5. Query refinement?
  6. Interaction with other IA components
  7. Finishing search

Both articles offer far more detail defining each heuristic with a series of related questions. They are essential in understanding how IA heuristics can build on the standard ten that have been churned about for long enough.

The JavaScripter…

I’ve yet to find any real list of ‘JavaScript Heuristics’ related to the use of JavaScript in a site. However, there are methods of implementing JavaScript in ways that improve both the overall user experience as well as general site accessibility, and so I think developing a couple of rules specific to that would be useful. A set of JavaScript heuristics I created for a recent usability review included:

  1. Does the site navigation work with JavaScript disabled?
  2. Does key site functionality fail when JavaScript is disabled?
  3. Does the site use (script based) pop-ups?
  4. Does the site use device independent scripts?

No doubt there are others that could be included here, but I think it’s a good start… Can you add to this?


The Web Standards Developer…

The quality of front end coding (CSS and HTML) also has a significant impact on site usability and should certainly be a consideration when developing a set of usability heuristics. ‘Coding Heuristics’ might include questions such as:

  1. Does the site incorporate a favicon?
  2. What is the naming convention used in title tags?
  3. Is the site coded semantically?

Each of these heuristics improves the general usability of a site for all users, but there are other, more specific coding techniques that will improve site usability and accessibility.

Quite a few of the accessibility guidelines outlined in WAI WCAG 1.0 also improve site usability for users who are not disabled. In addition to those above, I will typically include these as coding heuristics:

  1. Does the site implement fieldset and legend?
  2. Does the site use frames?
  3. Is colour contrast adequate?
  4. Are visited links obvious?
  5. Are link destinations clear?
  6. Is the file type of downloads obvious e.g. pdf’s?
  7. Have relative font sizes been incorporated?
  8. Can the site be read with style sheets disabled?
  9. Does the site validate?

I’m not suggesting that this would negate the need for a complete accessibility audit. Clearly that is a stand alone event. But in conducting an heuristic review of sites usability, these are elements that directly affect all users.

This list is by no means exhaustive and in some cases it might be appropriate to refine these usability heuristics so that they’re more in tune with your own approach. But in conducting an expert or heuristic review, we need to think a lot deeper than the GUI. We need to move forward from the ‘standard ten’ and incorporate heuristics that address holistic development and user centred design. Beauty is, after all, only skin deep!

[1]
Primary Source
Making Computers-People Literate. © Copyright 1993. By Elaine Weiss ISBN: 0-471-01877-5
Secondary Source
Usability Inspection Methods. © Copyright 1994.By Jakob Nielsen and Robert Mack ISBN: 1-55542-622-0

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.realityedge.com.au mrsmiley

    Considering there is a whole industry devoted to HCI, it’s a wonder there isn’t a definitive set of rules for web development. Although, if you look at every area that “web development” covers, said list would be around 1 km long once it came out the printer.

    The joys of working in an industry and almost requires you to be an expert in everything. Well, at least the ones that can be abbreviated to an acronym that is pronounced nothing like its spelt :)

  • http://www.saumendra.com saumendra

    The Ten Usability Heuristics by Jacob Nielson , is a basic design rule for everyone out there, who need to have his/her website in a world wide standard. Now the Design Rules can be utilised smartly with the client side coding i.e javascript. But one can’t force the same as such.In a wider perspective the web needs more of global and unique usability components, which can be accessible by any form of data/content and yet be simple.

    Even the Usabilit week 2007 Confrence does make that passion alive. And the results it had shown makes us to think and wait for the comming standards

    There is allways more to explore……. Saum

  • http://www.xraysierra.com XraySierra

    I don’t understand what a favicon would have to do with site accessibility?

  • http://www.sitepoint.com Simon Mackie

    XraySierra- it doesn’t, it’s a usability feature.

  • http://www.realityedge.com.au mrsmiley

    I’m with XraySierra, I dont get why its a usability feature. It has absolutely nothing to do with the way people use your site, but everything to do with how they locate it in your bookmarks/favourites lists. Arguably its a browser usability as it makes the tool (aka the browser) easier to use to find your site.

    Implementing a favicon (or not implementing one) doesn’t have any impact on how usable a site is when you are actually using it. Only in discovering the site.

    That does bring up an interesting point, why don’t search engines put the favicon next to the search results? If implementing one is such a big deal, it would encourage more sites to do so if they knew their sites would stand out from ones that didn’t have one.

  • http://www.sitepoint.com Matthew Magain

    Why draw the line at browser usability and say “that’s not my area”? Whether it’s relating to the user finding your site amongst their 17 tabs, or using your site – what’s the difference? If it improves the user experience, whether inside your direct area of responsibility or outside of it, and it takes a few seconds to implement, it seems worthwhile listing as a heuristic so that it doesn’t get left out, don’t you think?

  • stevebaty

    This discussion (in the comments) falls broadly into my category of ‘where to draw the line between usability and user experience’. Keeping in mind that these are usability heuristics, I think this becomes an important distinguishing factor when deciding whether additional dimensions might be added to the list. Is information findability a usability consideration? Certainly within a site it is, but less so when you’re considering how easy the site is to locate on the Web.

    Around the boundaries of usability there are a great deal of ambiquities as to whether a particular issue is related to usability or something else. I would not expend too much energy attempting to determine a definitive list of attributes that are/are not usability concerns. The scope of your heuristic checklist would (and should) be adjusted to meet the terms of enquiry for the evaluation. As Lisa has pointed out, there are considerations below the surface of the presentation layer which affect usability and are available to us for evaluation, and this is a valuable starting point for creating an extended heuristic checklist. Similarly, there are considerations beyond the bounds of the target web site which affect the user’s experience with that site, and might also be included in an heuristic review.

  • http://www.moojmedia.co.uk/ mooj

    I would have never considered incorporating a favicon as part usability of a website! Some good points here and arguments aside, I will now be making much more use of this 16×16 space.. and pixel by pixel editing! :)