Usability Principles
Originally from www.arch.carleton.ca/grad/usability.html
Heuristics I
Defined as "usability principles" (Bias and Mayhew, 1994). These principles (as compared to other sets of usability principles) were developed by Molich and Nielsen (1990) and are discussed further in Chapter 5 of Nielsen (1993):
1. Simple and natural dialogue:
Dialogues should not contain information that is irrelevant or rarely needed,
Every extra unit of information in a dialogue competes with the relevant units
of information and diminishes their relative visibility. All information
would appear in a natural and logical order.
2. Speak the user's language. The dialogue should be
expressed clearly in words, phrases, and concepts familiar to the user, rather
than in system-oriented terms.
3. Minimize the users' memory load: The user should not
have to remember information from one [part of the dialogue to another,
Instructions for use of the system should be visible or easily retrievable
whenever appropriate.
4. Consistency: Users should not have to wonder whether
different words, situations, or actions mean the same thing.
5. Provide feedback: The system should always keep users
informed about what is going on through appropriate feedback within reasonable
time.
6. Provide clearly marked exits: Users often choose systems
functions by mistake and will need a clearly marked "emergency unit"
to leave the unwanted state without having to go through an extended dialogue.
7. Provide shortcuts: Accelerators -- unseen by the novice
user -- may often speed up the interaction for the expert user such that the
system caters to both inexperienced and experienced users.
8. Good error messages: They should be expressed in plain
language (no codes), precisely indicate the problem, and constructively
suggest a solution.
9. Prevent errors: Even better than good error messages is
a careful design that prevents a problem from occurring in the first place.
10. Help and documentation: Even though it is better if the
system can be sued without documentation, it may be necessary to provide help
and documentation. Any such information should be easy to search,
focused on the users' task, list concrete steps to be carried out, and not be
too large.
Heuristics 2
Nielsen's original principles revised and reorganized by and presented in a recent paper
1. Visibility of system status.
The system should always keep users informed about what is going on, through
appropriate feedback within reasonable time.
2. Match between system and real world. The system should
speak the users' language, with words, phrases and concepts familiar to the
user , rather than system oriented terms. Follow real-world conventions,
making information appear in a natural and logical order.
3. User control and freedom. Users often choose system
functions by mistake and will need a clearly marked "emergency exit"
to leave the unwanted state without having to go through an extended dialogue.
Support undo and redo.
4. Consistency and standards. Users should not have to
wonder whether different words, situations, or actions mean the same thing.
Follow platform conventions.
5. Error prevention. Even better than good error messages
is a careful design which prevents a problem from occurring in the first
place.
6. Recognition rather than recall. Make objects, actions,
and options visible. The user should not have to remember information
from one part of the dialogue to another, Instructions for use of the
system should be visible or easily retrievable whenever appropriate.
7. Flexibility and efficiency of use. Accelerators
unseen by the novice user may often speed up the interaction for the
expert user such that the system can cater to both inexperienced and
experienced users. Allow users to tailor frequent actions.
8. Aesthetic and minimalist design. Dialogues should not
contain information which is irrelevant or rarely needed. Every extra
unit of information in a dialogue competes with the relevant units of
information and diminishes their relative visibility.
9. Help users recognize, diagnose, and recover from errors.
Error messages should be expressed in plain language (no code), precisely
indicate the problem and constructively suggest a solution.
10. Help and documentation. Even though it is better if the
system can be used without documentation, it may be necessary to provide help
and documentation, Any such information should be easy to search,
focused on the user's task, list concrete steps to be carried out and not be
too large.
Usability Heuristics for the Web
by Keith Instone
Jakob Nielsen's ten usabilty heuristics appear below, each followed with Instone's Web-specific comment following. The overriding theme for applying these heuristics to the Web is to use links effectively.
1. Visibility of system status
The system should always keep users informed about what is going on,
through appropriate feedback within reasonable time.
Probably the two most important things that users need to know at your site
are "Where am I?" and "Where can I go next?"
Make sure each page is branded and that you indicate which section it belongs
to. Links to other pages should be clearly marked. Since users could be
jumping to any part of your site from somewhere else, you need to include this
status on every page.
My Site Stress Test is an evaluation focused on this heuristic because it is
so important on the Web.
2. Match between system and the real world
The system should speak the users' language, with words, phrases and
concepts familiar to the user, rather than system-oriented terms. Follow
real-world conventions, making information appear in a natural and logical
order.
On the Web, you have to be aware that users will probably be coming from
diverse backgrounds, so figuring out their "language" can be a
challenge.
3. User control and freedom
Users often choose system functions by mistake and will need a clearly
marked "emergency exit" to leave the unwanted state without having
to go through an extended dialogue. Support undo and redo.
Many of the "emergency exits" are provided by the browser, but there
is still plenty of room on your site to support user control and freedom. Or,
there are many ways authors can take away user control that is built into the
Web. A "home" button on every page is a simple way to let users feel
in control of your site.
Be careful when forcing users into certain fonts, colors, screen widths or
browser versions. And watch out for some of those "advanced
technologies": usually user control is not added until the technology has
matured. One example is animated GIFs. Until browsers let users stop and
restart the animations, they can do more harm than good.
4. Consistency and standards
Users should not have to wonder whether different words, situations, or
actions mean the same thing. Follow platform conventions.
Within your site, use wording in your content and buttons consistently. One of
the most common cases of inconsistent wording I see deals with links, page
titles and page headers. Check the titles and headers for your pages against
the links that point to them. Inconsistent wording here can confuse users who
think they ended up in the wrong spot because the destination page had a title
that differed vastly from the link that took them there.
"Platform conventions" on the Web means realizing your site is not
an island. Users will be jumping onto (and off of) your site from others, so
you need to fit in with the rest of the Web to some degree. Custom link colors
is just one example where it may work well for your site but since it could
conflict with the rest of the Web, it may make your site hard to use.
And "standards" on the Web means following HTML and other
specifications. Deviations form the standards will be opportunities for
unusable features to creep into your site.
5. Error prevention
Even better than good error messages is a careful design which prevents a
problem from occurring in the first place.
Because of the limitations of HTML forms, inputting information on the Web is
a common source of errors for users. Full-featured, GUI-style widgets are on
their way; in the meanwhile you can use JavaScript to prevent some errors
before users submit, but you still have to double-check after submission.
6. Recognition rather than recall
Make objects, actions, and options visible. The user should not have to
remember information from one part of the dialogue to another. Instructions
for use of the system should be visible or easily retrievable whenever
appropriate.
For the Web, this heuristic is closely related to system status. If users can
recognize where they are by looking at the current page, without having to
recall their path from the home page, they are less likely to get lost.
Certainly the most invisible objects created on the Web are server-side image
maps. Client-side image maps are a lot better, but it still takes very
well-crafted images to help users recognize them as links.
Good labels and descriptive links are also crucial for recognition.
7. Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the
interaction for the expert user such that the system can cater to both
inexperienced and experienced users. Allow users to tailor frequent actions.
Some of the best accelerators are provided by the browser. Like bookmarks.
Make pages at your your site easy to bookmark. If a user is only interested in
one corner of your site, make it easy for him to get there. Better that than
have him get frustrated trying to get from your home page to what he is
looking for.
Do not use frames in a way that prevent users from bookmarking effectively.
Support bookmarking by not generating temporary URLs that have a short
lifespan. If every week you come out with a new feature article for your site,
make sure your URL lives on, even after the content is taken down. Web Review
uses long-term locations by putting date information into the URLs. Or, you
could re-use your URLs for the newer content.
Consider using GET instead of POST on your forms. GET attaches the paramters
to the URL, so users can bookmark the results of a search. When they come
back, they get their query re-evaluated without having to type anything in
again.
All of these rules for "design to be bookmarked" also help you
design to be linked to. If the contents of your site can easily be linked to,
others can create specialized views of your site for specific users and tasks.
Amazon.com's associates program is just one example of the value of being easy
to link to.
8. Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely
needed. Every extra unit of information in a dialogue competes with the
relevant units of information and diminishes their relative visibility.
Extraneous information on a page is a distraction and a slow-down. Make rarely
needed information accessible via a link so that the details are there when
needed but do not interfere much with the more relevant content.
The best way to help make sure you are not providing too much (or too little)
information at once is to use progressive levels of detail. Put the more
general information higher up in your hierarchy and let users drill down
deeper if they want the details. Likewise, make sure there is a way to go
"up" to get the bigger picture, in case users jump into the middle
of your site.
Make sure your content is written for the Web and not just a repackaged
brochure. Break information into chunks and use links to connect the relevant
chunks so that you can support different uses of your content.
9. Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely
indicate the problem, and constructively suggest a solution.
Errors will happen, despite all your efforts to prevent them. Every error
message should offer a solution (or a link to a solution) on the error page.
For example, if a user's search yields no hits, do not just tell him to
broaden his search. Provide him with a link that will broaden his search for
him.
10. Help and documentation
Even though it is better if the system can be used without documentation,
it may be necessary to provide help and documentation. Any such information
should be easy to search, focused on the user's task, list concrete steps to
be carried out, and not be too large.
Some of the more basic sites will not need much documentation, if any. But as
soon as you try any complicated tasks, you will need some help for those
tasks.
For the Web, the key is to not just slap up some help pages, but to integrate
the documentation into your site. There should be links from your main
sections into specific help and vice versa. Help could even be fully
integrated into each page so that users never feel like assistance is too far
away.
pjb associates Home t-learning Study Home
Last updated 30 April 2004