Usability Guidelines
Usability Guidelines
Usability Guidelines
A common definition for the word guideline is “ a rule or principle that provides guidance to
appropriate behaviour. Usability guidelines are sets of rules and principles that give designers
resources for developing interactive systems to ensure high usability. The most commonly
used usability guidelines represent the relevant information in a short form, so that they can
be easily used by designers as well as by non-experts of usability.
The usability guidelines presented here are mostly from the field of computer science, not
from ergonomics science. Ergonomics guidelines give guidance on general office
ergonomics, for example, computer workstation checklists. These guidelines may also give
suggestions for room temperature levels, but are not useful in improving the usability of
temperature controls.
In computer science, there are many usability guidelines (for example, Polson and Lewis
1990; Shneiderman and Plaisant 2005; Nielsen 2006; ISO 9241-10 1996).
Usability guidelines from various sources are shown below. Most of the usability guidelines
are primarily targeted for designers of software.
• Make it easy to determine what actions are possible at any moment (make use of
constraints).
• Make things visible, including the conceptual model of the system, the alternative actions,
and the results of actions.
• Follow natural mappings between intentions and the required actions; between actions and
the resulting effect; and between the information that is visible and the interpretation of the
system state.
In the same book, Norman presents “ Seven principles for transforming difficult
1. Use both knowledge in the world and knowledge in the head. The user acquires all
knowledge of the system from the system image. The designer should develop a conceptual
model that is appropriate for the user, that captures the important parts of the device, and that
is understandable by the user.
2. Simplify the structure of tasks. Tasks should be simple in structure, minimising the amount
of problem solving they require.
3. Make mapping visible: bridge the gulfs of execution and evaluation. Make things visible
on the execution side of an action so that people know what is possible and how actions
should be done. Make things visible on the evaluation side so that people can tell the effects
of their actions. The system should provide actions that match intentions and make the
outcomes of an action obvious.
4. Get the mappings right. Exploit natural mappings: between intentions and possible actions,
between actions and their effects on the system, between actual system state and what is
perceivable, between the perceived system state and the needs, intentions, and expectations of
the user. The easiest way to make things understandable is to use graphics or pictures.
5. Exploit the power of constraints, both natural and artificial. Use constraints so the user
feels there is only one possible thing to do the right thing.
6. Design for error. Assume that any error that can be made will be made. Make it easy to
reverse actions. Make it hard to perform irreversible actions.
7. When all fails, standardise. Standardised actions, outcomes, layout and displays only have
to be learned once. Standardisation is essential only when all the necessary information
cannot be placed in the world or when natural mappings cannot be exploited. When we have
standardisation of our keyboard layouts, our operating systems, our text editors and word
processors, and the basic means of operating any program, then suddenly we will see a major
breakthrough in usability
1. Make the repertoire of available actions salient. For example, all menu choices should be
visible.
2. Use identity cues between actions and user goals as much as possible. For example, if a
chart utility requires users to select colours by numbers, not by name or choosing among
colour patches, users will have problems.
3. Use identity cues between system responses and user goals as much as possible. Users
must be able to gauge whether an action moved toward a goal or not.
4. Provide an obvious way to undo actions. If an action is seen to be a mistake, users must
have a way to undo the action.
5. Make available actions easy to discriminate. For example, if there are many ways to delete
that differ in the size of the unit deleted (e.g. character, worksheet, document), it will be
difficult to determine which action best approached the goal.
6. Offer few alternatives. The chance of guessing the correct alternative goes down with the
number of possibilities.
8. Require as few choices as possible. A longer series of choices has less chance of being
completed successfully.
2. Cater for universal usability. The needs of diverse users (novice vs.experts, age ranges,
disabilities) should be recognised. For example,novices may need explanations while experts
may need shortcuts.
3. Offer informative feedback. There should be system feedback for every user action. The
response should be more substantial for infrequent andmajor actions than for frequent and
minor actions.
4. Design dialogue to yield closure. Sequences of action should be organized into groups with
a beginning, middle, and end.
5. Prevent errors. Users should not be able to make serious errors. In case of an error, the
interface should detect the error and offer simple instructions for recovery.
6. Permit easy reversal of actions. Actions should be reversible. This relieves anxiety, since
users know that errors can be undone.
7. Support internal locus of control. Make users the initiators of actions rather than the
responders to actions.
8. Reduce short-term memory load. The limitation of human information processing in short-
term memory requires that displays be kept simple, multiple page displays be consolidated,
window-motion frequency be reduced, and sufficient training time be allotted for codes,
mnemonics, and sequences of actions.
1. Visibility of system status. Appropriate feedback should always keep users informed about
what is going on.
2. Match between system and the real world. The system should speak the users’ language
rather than system-oriented terms and make information appear in a natural and logical order.
3. User control and freedom. Users need a clearly marked emergency exit” to leave the
unwanted state. Undo and redo should be supported.
4. Consistency and standards. Users should not have to wonder whether different words,
situations, or actions mean the same thing. Platform conventions should be followed.
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.
7. Flexibility and efficiency of use. Systems should 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.
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.
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.
1. Suitability for the task. A dialogue is suitable for a task when it supports the user in the
effective and efficient completion of the task.
3. Controllability. A dialogue is controllable when the user is able to initiate and control the
direction and pace of the interaction until a point at which the goal has been met.
4. Conformity with user expectations. A dialogue conforms with user expectations when it is
consistent and corresponds to the user characteristics, such as task knowledge, education and
experience, and to commonly accepted conventions.
5. Error tolerance. A dialogue is error-tolerant if, despite evident errors in input, the intended
result may be achieved with either minimal or no corrective action by the user.
7. Suitability for learning. A dialogue is suitable for learning when it supports and guides the
user in learning to use the system.