User interface design

Designing effective interfaces
for software systems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 1
The user interface




System users often judge a system by its
interface rather than its functionality
A poorly designed interface can cause a user to
make catastrophic errors
Poor user interface design is the reason why so
many software systems are never used
Software engineers generally must do interface
design
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 4
Importance of User Interface


“Most important part of any computer system”
•
“Interface is the system for most users”
Increasingly important
•
•
•


GUIs a big improvement over previous approaches
Platforms (e.g. Mac/ Microsoft) have style guides
50% of code devoted to interface
Interface should “disappear” – users can focus on their task, not
the interface
Biggest enemy of good interface design is time
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 5
Benefits of Good Design

Small improvements can be worth big $$$
• Book e.g. if users work 1 sec slower on each of 4.8 million screens per year, need almost
an extra person
• Book e.g.s Redesigns have improved productivity 20%, 25%, 40%, 50% …
• IBM - $1 invested in usability returns $10-$100

Interface problems are treated as bugs
• Pressman - $1 fix during design, $10 fix during development, $100 fix after release

Big Improvements can establish new products, companies, markets …
• the browser was a UI idea – before it, search using gopher etc was tedious.
• AOL was successful because it was more user friendly than early leader CompuServe.
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 6
Graphical user interfaces

Most users of business systems interact with these
systems through graphical interfaces although, in
some cases, legacy text-based interfaces are still
used
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 7
GUI characteristics
•Windows
•Icons
•Menus
•Pointing
•Graphics
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 8
GUI advantages



They are easy to learn and use.
The user may switch quickly from one task to
another and can interact with several different
applications.
Fast, full-screen interaction is possible with
immediate access to anywhere on the screen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 9
User-centred design



The aim of this chapter is to sensitise software
engineers to key issues underlying the design rather
than the implementation of user interfaces
User-centred design is an approach to UI design
where the needs of the user are paramount and where
the user is involved in the design process
UI design always involves the development of
prototype interfaces
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 10
User interface design process
An aly se and
u nd ers tan d us er
acti vi ti es
P ro du ce pap erb as ed des ig n
p ro to ty pe
Des ig n
p ro to ty pe
Ev al uate d esig n
wi th en d-us ers
P rodu ce
dy nami c desig n
pro tot ype
Ex ecut abl e
p ro to ty pe
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Ev al uate d esig n
wi th en d-us ers
Im pl em ent
fin al us er
i nt erface
Slide 11
15.1 UI design principles



UI design must take account of the needs,
experience and capabilities of the system users
Designers should be aware of people’s physical
and mental limitations (e.g. limited short-term
memory) and should recognise that people make
mistakes
UI design principles underlie interface designs
although not all principles are applicable to all
designs
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 12
User interface design principles
Principle
Description
User Familiarity
Interface should use terms familiar to users
Consistency
Minimal Surprise
Comparable operations should be started the
same way
Users should never be surprised
Recoverability
Users should be able to recover from their errors
User Guidance
Meaningful feedback, context-sensitive help
User Diversity
Should provide for different types of user
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 13
Nielsen’s Ten Usability Heuristics










Visibility of system status
Match between system and the real world
User control and freedom
Consistency and standards
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
Help users recognize, diagnose, and recover from errors
Help and documentation
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 16
Galitz’s Heuristics (Table 14.2)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Automate unwanted workload
Reduce uncertainty
Fuse data
Present new info with meaningful aid to interpretation
Use names that are conceptually related to functions
Group data in consistently meaningful ways to reduce
search time
Limit data-driven tasks
Include in displays only info needed by user at a given
time
Provide multiple coding of data where appropriate
Practice judicious redundancy
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Galitz
Slide 17
Galitz’s WWW Heuristics
1.
2.
3.
4.
5.
6.
7.
8.
9.
Speak the user’s language
Be consistent
Minimize the user’s memory load
Build flexible and efficient systems
Design aesthetic and minimalist systems
Use chunking
Provide progressive levels of detail
Give navigational feedback
Don’t lie to the user
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 18
15.2 User-system interaction

Two problems must be addressed in interactive
systems design
•
•

How should information from the user be provided to the
computer system?
How should information from the computer system be
presented to the user?
User interaction and information presentation
may be integrated through a coherent
framework such as a user interface metaphor
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 19
Interaction styles





Direct manipulation
Menu selection
Form fill-in
Command language
Natural language
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 20
Direct manipulation advantages




Users feel in control of the computer and are less
likely to be intimidated by it
Fast and intuitive interaction
User learning time is relatively short
Users get immediate feedback on their actions
so mistakes can be quickly detected and
corrected
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 21
Direct manipulation problems



The creation of an appropriate information
space model (metaphor) for real world tasks and
objects can be very difficult
Given that users have a large information
space, what facilities for navigating around that
space should be provided?
Direct manipulation interfaces can be complex to
program and make heavy demands on the
computer system
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 22
Direct Manipulation Applications



Games
CAD systems
Files and Folders
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 23
Menu systems



Users make a selection from a list of
possibilities presented to them by the system
The selection may be made by pointing and
clicking with a mouse, using cursor keys or by
typing the name of the selection
May make use of simple-to-use terminals such as
touchscreens
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 25
Advantages of menu systems




Users need not remember command names as
they are always presented with a list of valid
commands
Typing effort is minimal
User errors are trapped by the interface
Context-dependent help can be provided. The
user’s context is indicated by the current menu
selection
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 26
Problems with menu systems



Actions which involve logical conjunction (and)
or disjunction (or) are awkward to represent
Menu systems are best suited to presenting a
small number of choices. If there are many
choices, some menu structuring facility must be
used
Experienced users find menus slower than
command language
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 27
Menu System Applications

Most general purpose systems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 28
Form-based interface
NE W B O O K
Ti tl e
IS B N
Au th or
P ri ce
P ub li sh er
P u bl icat io n
d at e
Ed it io n
Nu m ber o f
cop ies
C l as s ifi cat io n
Dat e of
p urchas e
©Ian Sommerville 2000
Lo an
s tat us
Ord er
s tat us
Software Engineering, 6th edition. Chapter 15
Slide 29
Forms-based Systems Advantages


Simple data entry
Easy to learn
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 30
Forms-based Systems Disadvantages

Takes up a lot of screen space
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 31
Forms-based Systems Applications

Most systems involving significant data entry
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 32
Command interfaces


User types commands to give instructions to the
system e.g. UNIX, DOS
Advantages:
•
•
•
•
Powerful and flexible – good for experts
Easy to process using compiler techniques
Commands of arbitrary complexity can be
created by command combination
Concise interfaces requiring minimal typing can
be created
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 33
Problems with command interfaces



Users have to learn and remember a command
language. Command interfaces are therefore
unsuitable for occasional users
Users make errors in command. An error
detection and recovery system is required
System interaction is through a keyboard so
typing ability is required
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 34
Command languages



Often preferred by experienced users because
they allow for faster interaction with the system
Not suitable for casual or inexperienced users
May be provided as an alternative to menu
commands (keyboard shortcuts). In some cases, a
command language interface and a menu-based
interface are supported at the same time
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 35
Natural language interfaces


The user types a command in a natural language.
Generally, the vocabulary is limited and these
systems are confined to specific application
domains (e.g. timetable enquiries)
NL processing technology is now good enough to
make these interfaces effective for casual users
but experienced users find that they require too
much typing
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 36
15.3 Information presentation



Information presentation is concerned with
presenting system information to system users
The information may be presented directly (e.g.
text in a word processor) or may be transformed
in some way for presentation (e.g. in some
graphical form)
The Model-View-Controller approach is a way of
supporting multiple presentations of data
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 38
Information presentation
Info rm at io n t o
b e di sp lay ed
P resen tati on
s oft ware
Di s pl ay
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 39
Information presentation

Static information
•
•

Initialised at the beginning of a session. It does not
change during the session
May be either numeric or textual
Dynamic information
•
•
Changes during a session and the changes must be
communicated to the system user
May be either numeric or textual
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 41
Information display factors





Is the user interested in precise information or
data relationships?
How quickly do information values change?
Must the change be indicated immediately?
Must the user take some action in response to
a change?
Does the user need to interact with the displayed info via a
direct manipulation interface?
Is the information textual or numeric? Are relative values
important?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 42
Alternative information presentations
Jan
2 84 2
F eb
2 85 1
M ar
3 16 4
Jan
F eb
M ar
Ap ri l
2 78 9
M ay
1 27 3
Ju ne
2 83 5
M ay
Ju ne
4 00 0
3 00 0
2 00 0
1 00 0
0
©Ian Sommerville 2000
Ap ri l
Software Engineering, 6th edition. Chapter 15
Slide 43
Analogue vs. digital presentation

Digital presentation
•
•

Compact - takes up little screen space
Precise values can be communicated
Analogue presentation
•
•
•
Easier to get an 'at a glance' impression of a value
Possible to show relative values
Easier to see exceptional data values
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 44
Dynamic information display
1
4
0
2
10
20
3
Di al wi th need le
©Ian Sommerville 2000
P i e chart
Th erm o m et er
Software Engineering, 6th edition. Chapter 15
Ho rizo nt al bar
Slide 45
Displaying relative values
Press u re
0
1 00
©Ian Sommerville 2000
2 00
Temp er a tu re
3 00
4 00
0
25
Software Engineering, 6th edition. Chapter 15
50
75
1 00
Slide 46
Textual highlighting
!
T h e fi len a me y o u h ave ch o sen h as b een
u s ed . P lea se ch o os e an oth er n a me
C h . 1 6 U ser i nt erface d esi gn
OK
©Ian Sommerville 2000
Ca n cel
Software Engineering, 6th edition. Chapter 15
Slide 47
Data visualisation


Concerned with techniques for displaying large
amounts of information
Visualisation can reveal relationships between entities
and trends in the data
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 48
15.3.1 Colour displays



Colour adds an extra dimension to an interface
and can help the user understand complex
information structures
Can be used to highlight exceptional events
Common mistakes in the use of colour in
interface design include over-use of colour in the
display
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 49
Colour use guidelines








Don't use too many colours
Use colour coding to support user tasks
Allow users to control colour coding
Design for monochrome then add colour
Use colour coding consistently
Avoid colour pairings which clash
Use colour change to show status change
Be aware that colour displays are usually lower
resolution
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 50
15.4 User support



User guidance covers all system facilities to
support users including on-line help, error
messages, manuals etc.
The user guidance system should be integrated
with the user interface to help users when they
need information about the system or when they
make some kind of error
The help and message system should, if possible,
be integrated
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 51
Error messages



Error message design is critically important.
Poor error messages can mean that a user
rejects rather than accepts a system
Messages should be polite, concise, consistent
and constructive
The background and experience of users
should be the determining factor in message
design
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 53
Design factors in message wording
Context
Experience
Skill level
Style
Culture
©Ian Sommerville 2000
The user guidance system should be aware of what the
user is
doing and should adjust the output message to
the current
context.
As users become familiar with a system
they become irritated
by long, ‘meaningful’ messages.
However, beginners find it
difficult to understand short terse statements of
the problem.
The user guidance system should provide both
types of message
and allow the user to control message conciseness.
Messages should be tailored to
the user’s skills as well as their
experience. Messages for the different classes
of user may be
expressed in different ways depending on
the terminology which
is familiar to the reader.
Messages should be positive rather than negative. They should
use the active rather than the passive mode of address.
They
should never be insulting or try to be funny.
Wherever possible, the
designer of messages should be familiar
with the culture of the
country where the system is sold. There
are distinct cultural differences
between Europe, Asia and
America. A suitable message for one culture
might be
unacceptable in another.
Software Engineering, 6th edition. Chapter 15
Slide 54
Design factors in message wording





Context
Experience
Skill Level
Style
Culture
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 55
System and user-oriented error messages
System-oriented error message
Error #27
?
Invalid patient id entered
OK
©Ian Sommerville 2000
Cancel
Software Engineering, 6th edition. Chapter 15
Slide 57
user-oriented error messages
User-oriented error message
Patient J . Bates is not registered
Click on Patients for a list of registered patients
Click on Retry to re-input a patient name
Click on Help for more information
Patients
©Ian Sommerville 2000
Help
Retry
Cancel
Software Engineering, 6th edition. Chapter 15
Slide 58
Help system design




Help? means ‘help I want information”
Help! means “HELP. I'm in trouble”
Both of these requirements have to be taken
into account in help system design
Different facilities in the help system may be
required
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 59
Help information






Should not simply be an on-line manual
Screens or windows don't map well onto paper
pages.
The dynamic characteristics of the display can
improve information presentation.
People are not as good at reading screen as
they are paper text.
Content should be prepared with help of application
specialists
Content should not be too large – don’t overwhelm user
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 60
Help system use




Multiple entry points should be provided so that
the user can get into the help system from
different places.
Some indication of where the user is positioned
in the help system is valuable.
Facilities should be provided to allow the user
to navigate and traverse the help system.
Index, TOC, and Search should be provided
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 61
Entry points to a help system
To p-lev el
ent ry
En try fro m
ap pl icat io n
En try fro m erro r
m ess ag e sy st em
Hel p fram e n etwo rk
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 62
Help system windows
Hel p fram e m ap
M ail redi recti on
M ail m ay be redi rected t o an ot her
n et wo rk us er b y press i ng th e
redi rect bu tt on in t he co nt ro l
p an el. Th e s ys tem as ks fo r th e
n am e of t he us er or us ers t o
wh om th e m ail h as b een sen t
Yo u are h ere
m o re
n ext
top ics
Hel p hi st ory
1.
2.
3.
4.
M ai l
S en d m ai l
Read m ail
Redi recti on
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 63
Help on WWW



Easy to implement
Easy for users to use
Difficult to link to applications themselves
• users may need to make extra effort to get to help
• Help doesn’t know context where you needed help
– cannot provide context sensitive help
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 64
5.4.3 User documentation



As well as on-line information, paper
documentation should be supplied with a system
Documentation should be designed for a range of
users from inexperienced to experienced
As well as manuals, other easy-to-use
documentation such as a quick reference card
may be provided
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 65
User document types
S y st em
evalu at ors
S y st em
adm i ni st rat ors
No vice
u sers
Ex peri en ced
u sers
S y st em
adm i ni st rat ors
Ins t al lat io n
d ocum en t
Int ro duct ory
m anu al
R eference
m anu al
Ad m i ni st rat or’s
g ui de
Ho w to i ns tall
t he s ys tem
Get ti ng
s tarted
Facil it y
d es crip ti on
Op erat io n an d
m ain ten ance
F u nct io nal
d es crip ti on
Des crip ti on o f
s erv ices
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 66
15.5 User interface evaluation



Some evaluation of a user interface design
should be carried out to assess its suitability
Full scale evaluation is very expensive and
impractical for most systems
Ideally, an interface should be evaluated against a
usability specification. However, it is rare for
such specifications to be produced
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 68
Usability attributes
Attribute
Learnability
Speed of operation
Robustness
Recoverability
Adaptability
©Ian Sommerville 2000
Description
How long does it take a new user
to
become productive with the system?
How well does the system
response match
the user’s work practice?
How tolerant is the system of user error?
How good is the
system at recovering from
user errors?
How closely is the system tied to a
single
model of work?
Software Engineering, 6th edition. Chapter 15
Slide 69
Things to Test









Conformance with a requirement
Conformance with guidelines for good design
Identification of design problems
Ease of system learning
Retention of learning over time
Speed of task completion
Speed of need fulfillment
Error rates
Galitz
Subjective user satisfaction
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 70
…System - User Interface Design Goals

5 human factors central to community evaluation:
1.
2.
3.
4.
5.


Time to learn
Speed of performance
Rate of errors by users
Retention over time
Subjective satisfaction
Trade-offs sometimes necessary
Test all design alternatives using mock-ups
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 71
Objective Measures of Usability

Effectiveness
• Speed of performance, # errors (against some standard)
• Tasks completeable by required pct of target users

Learnable
• Time to learn, amount of training and tech support needed (against some
standard)
• Relearning time for intermittent users


Flexible
Subjective satisfaction
• Tiredness, discomfort, frustration, effort required, willingness/eagerness to use
system
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 72
Simple evaluation techniques





Questionnaires for user feedback
Video recording of system use and subsequent
tape evaluation.
Observation of users at work with system and “thinking
aloud” about how they are trying to use system
Instrumentation of code to collect information
about facility use and user errors.
The provision of a gripe button for on-line user
feedback.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 73
Kinds of Tests







Guidelines review
Heuristic evaluation (will be covered last due to
extensive coverage)
Cognitive walkthrough
Think aloud evaluations
Usability test
Classic experiments
Focus groups
Galitz
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 74
Elements of Discount Usability
Engineering



Scenarios
Simplified Thinking Aloud
Heuristic Evaluation
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 75
Scenarios




Take prototyping to extreme – reduce functionality AND number
of features
Small, can afford to change frequently
Get quick and frequent feedback from users
Compatible with interface design methods
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 76
Simplified Thinking Aloud


Bring in some users, give them tasks, have them
think out loud
Fewer users in user testing
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 77
Heuristic Evaluation




Context – part of iterative design
Goal – find usability problems
Who – small set of evaluators
How – study interface in detail, compare to small set of
principles
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 78
How to Conduct a Heuristic
Evaluation








More than one evaluator to be effective.
Each evaluator inspects the interface by themselves
General heuristics may be supplemented
Results can be oral or written
Evaluator spends 1-2 hours with interface
Evaluator goes through interface > 1 time
Evaluators may follow typical usage scenarios
Interface can be paper
Nielsen
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 79
Norman’s Four Principles of
Good Design




State and the action alternatives should be visible
Should be a good conceptual model with a
consistent system image
Interface should include good mappings that reveal
the relationships between stages
User should receive continuous feedback
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 82
Galitz’s Principles of User Interface
Design

To follow … alphabetically (following book)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 83
Aesthetically Pleasing





Meaningful contrast between screen elements
Create groupings
Align screen elements and groups
Provide 3 dimensional representation
Use color and graphics effectively and simply
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 84
Clarity




Visual elements
Functions
Metaphors
Words and text
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 85
Compatible



With the user
With the task and job
With the product (past systems)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 86
Comprehensibility

User should easily be able to determine:
•
•
•
•
•
•
What to look at
What to do
When to do it
Where to do it
Why to do it
How to do it
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 87
Configurability


Users should be able to set preferences
Good Default Settings should be provided for
non-tinkerers
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 88
Consistency


One of Shneiderman’s 8 golden rules for interface
design
Similar components should
• Have similar look
• Operate similarly





Same action should always produce the same result
Function of elements should not change
Position of standard elements should not change
Same terminology used for same thing throughout
Standards and Guidelines increase the odds of
consistency
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 89
Control

User should control the interaction
•
•
•




Actions initiated by user
Actions performed quickly
Actions can be interrupted or stopped, and reversed
Context maintained is from the user’s perspective
More than one way to do things
Avoid modes
Configurable
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 90
Directness

Provide Direct Manipulation
•
•
•
user selects an object, then directly performs an action on it
The effect of action on an object should be immediately visible
Available alternatives reduces memory load
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 91
Efficiency

Minimize eye and hand movements
•
•

Make user actions flow from one to another
Don’t switch users frequently from keyboard to mouse
Anticipate users wants and needs whenever
possible
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 92
Familiarity



Use language and concepts familiar to the user
Keep the interface natural
Use real world metaphors
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 93
Flexibility


compatible with the user’s “skills, experience,
habits, and preferences, and current conditions”
Danger: more flexibility increases complexity of
system
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 94
Forgiveness




Prevent errors from occurring when possible
Tolerate and forgive common and unavoidable
human errors
When an error occurs, provide constructive error
messages
Protect against catastrophic errors
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 95
Predictability


User should be able to anticipate the flow of the
task
Expectations should be fulfilled
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 96
Recovery

System should permit:
•
•

Commands or actions to be abolished or reversed
Immediate return to a certain point if difficulties arise
Users should never lose work due to:
•
•
An error on their part
Hardware, software, or communication problems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 97
Responsiveness



Respond rapidly to user requests
Provide acknowledgement of user actions
Beginners need more / more informative feedback
than experts do
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 98
Simplicity

Provide as simple an interface as possible
•
•
•
•
•
Progressive disclosure
Defaults
Minimize screen alignment points
Make common actions simple
Provide consistency
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 99
Transparency

Allow user to focus on the task, not the interface
•
•
•
Basic principle of direct manipulation
Use user’s task vocabulary
Design interface based on task analysis
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 100
Trade-offs


Final Design will always represent a series of
trade-offs
People’s requirements always take precedence
over technical requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 15
Slide 101
Descargar

User interface design