Human Computer Interaction

Chapter 7
Design rules
Design Rules
 We require design rules, which are rules a designer
can follow in order to increase the usability of the
eventual software product.
 We can classify these rules along two dimensions,
based on the rule’s authority and generality.
 By authority, we mean an indication of whether or not
the rule must be followed in design or whether it is
only suggested.
 By generality, we mean whether the rule can be
applied to many design situations or whether it is
focused on a more limited application situation.
types of design rules
 principles
 abstract design rules
 low authority
 high generality
 standards Guidelines

increasing generality
increasing generality
 specific design rules
 high authority
 limited application
Standards
 guidelines
 lower authority
 more general application increasing authority
increasing authority
Design Rules
Designing for maximum usability
– the goal of interaction design

 Principles of usability
 general understanding

 Standards and guidelines

 direction for design

 Design patterns
 capture and reuse design knowledge
Using design rules

Design rules
Guidelines

increasing generality
increasing generality
 suggest how to increase usability
 differ in generality and authority

Standards

increasing
increasingauthority
authority
Standards
 Set by national or international bodies to ensure
compliance by a large community of designers
standards require sound underlying theory and slowly
changing technology
-Underlying Theories (physiology or
ergonomics/human factors, etc)
-Change: Less change in H/W as compare to Software.

 Hardware standards more common than software high

authority and more detail than software.

 ISO 9241 defines usability as effectiveness, efficiency

and satisfaction with which users accomplish tasks
Standards (Cont..)
 One component of the ISO standard 9241, pertaining to
usability specification, applies equally to both hardware
and software design. In the beginning of that document,
the following definition of usability is given:
 Usability The effectiveness, efficiency and satisfaction
with which specified users achieve specified goals in
particular environments.

 Effectiveness, Efficiency and Satisfaction?

Standards (Cont..)
 Effectiveness The accuracy and completeness with
which specified users can achieve specified goals in
particular environments.
 Efficiency The resources expended in relation to the
accuracy and completeness of goals achieved.
 Satisfaction The comfort and acceptability of the work
system to its users and other people affected by its use.
Guidelines
 Incompleteness of theories underlying the design of
interactive software makes it difficult to produce
authoritative and specific standards. As a result, the
majority of design rules for interactive systems are
suggestive and more general guidelines.
 Many textbooks and reports full of guidelines
 Abstract guidelines (principles) applicable during early
life cycle activities
 Detailed guidelines (style guides) applicable during
later life cycle activities
 Understanding justification for guidelines aids in
resolving conflicts
7.5 Golden Rules and Heuristics
 “Broad brush” design rules (Not applicable to every
specific situation but) a Useful check list for good
design
 Better design using these than using nothing!
 Different collections e.g.
 Shneiderman’s 8 Golden Rules
 Norman’s 7 Principles

 Nielsen’s 10 Heuristics (Chapter 9)

7.5.1 Shneiderman’s 8 Golden Rules

1. Strive for consistency in action sequences, layout,

terminology, command use and so on.
2. Enable frequent users to use shortcuts, such as
abbreviations, special key sequences and macros, to
perform regular, familiar actions more quickly.
3. Offer informative feedback for every user action, at a
level appropriate to the magnitude of the action.
4. Design dialogs to yield closure so that the user
knows when they have completed a task.
7.5.1 Shneiderman’s 8 Golden Rules
5. Offer error prevention and simple error handling so
that, ideally, users are prevented from making mistakes
and, if they do, they are offered clear and informative
instructions to enable them to recover.
6. Permit easy reversal of actions in order to relieve
anxiety and encourage exploration, since the user knows
that he can always return to the previous state.
7. Support internal locus of control so that the user is
in control of the system, which responds to his actions.
8. Reduce short-term memory load by keeping
displays simple, consolidating multiple page displays and
providing time for learning action sequences.
7.5.2. Norman’s 7 Principles
1. Use both knowledge in the world and knowledge
in the head. People work better when the knowledge
they need to do a task is available externally – either
explicitly or through the constraints imposed by the
environment. But experts also need to be able to
internalize regular tasks to increase their efficiency.
2. Simplify the structure of tasks. Tasks need to be
simple in order to avoid complex problem solving and
excessive memory load. Example: Breakdown into
simpler structure or automate.
7.5.2. Norman’s 7 Principles
3. Make things visible: bridge the gulfs of Execution
and Evaluation. The interface should make clear what
the system can do and how this is achieved, and should
enable the user to see clearly the effect of their actions
on the system.
4. Get the mappings right. User intentions should map
clearly onto system controls. User actions should map
clearly onto system events. So it should be clear what
does what and by how much. Controls, sliders and dials
should reflect the task – so a small movement has a
small effect and a large movement a large effect.
7.5.2. Norman’s 7 Principles
5. Exploit the power of constraints, both natural and
artificial. Provide the options that are valid only.
6. Design for error. To err is human, so anticipate the
errors the user could make and design recovery into the
system.
7. When all else fails, standardize. Key controls are
standardized. Example of Controls of a Car.
9.3.2 Nielsen’s Ten Heuristics
1. Visibility of System Status: Always keep users informed
about what is going on, through appropriate feedback
within reasonable time. For example, if a system operation
will take some time, give an indication of how long and how
much is complete.
2. Match Between System and the real world: The
system should speak (Use) the user’s language, with words,
phrases and concepts familiar to the user, rather than
system-oriented terms. NOT Error 404.
3. User Control and Freedom: Users often choose system
functions by mistake and need a clearly marked ‘emergency
exit’ to leave the unwanted state without having to go
through an extended dialog. Support undo and redo.
Muhammad Imran Saeed,
IIUI
9.3.2 Nielsen’s Ten Heuristics
4. Consistency and Standards: Users should not have to wonder
whether words, situations or actions mean the same thing in
different contexts. Follow platform conventions and accepted
standards.
5. Error Prevention: Make it difficult to make errors. Even better
than good error messages is a careful design that 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 dialog to another.

Muhammad Imran Saeed,

IIUI
9.3.2 Nielsen’s Ten Heuristics
7. Flexibility and Efficiency of Use: Allow users to tailor
frequent actions. Accelerators – unseen by the novice user –
may often speed up the interaction for the expert user to
such an extent that the system can cater to both
inexperienced and experienced users.
8. Aesthetic and minimalist design: Dialogs should not contain
information that is irrelevant or rarely needed. Every extra
unit of information in a dialog competes with the relevant
units of information and diminishes their relative visibility.

1. Help users recognize, diagnose and recover from errors

2. Help and documentation

Muhammad Imran Saeed,

IIUI
9.3.2 Nielsen’s Ten Heuristics
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: Few systems can be used with no
instructions so 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

Muhammad Imran Saeed,

IIUI