Where to from here??

Chapter 11
Designing the User
Interface layer

Overview
User interfaces handle inputs and outputs that
involve the system user directly
Design the inputs and outputs involved for each use case

Interactions with the user and computer

p
((termed
Human-Computer interactions or HCI) can be
modeled with dialog designs
Use metaphors, standard guidelines, and UML diagrams
to design user interfaces

User-interface design occurs in each iteration

We should address onlyy a few use cases at a time

Topic Overview
This topic will:
examine differences between user interfaces and system
y
interfaces
to a user the user interface is the system

Describe:
the three principles of user-centered design
the
h three
h metaphors
h off HCI

Discuss how visibility and affordance affect usability

Examine
E
i the
th application
li ti off eight
i h golden
ld rules
l off dialog
di l
design when designing the user interface
List some key principles used in Web design

Identifying and Classifying

Inputs and Outputs
Inputs
p and Outputs
p are defined earlyy in order to:

Document key inputs/outputs in business cases

Identifyy actors
Define triggers and responses in an event table
Identify the system boundary in use case diagrams
Design use case descriptions and system sequence
diagrams
Design
D i the
th user-interface
i t f
layer
l
Define messages in a use case realisation

User Versus System Interfaces

System interface
Involves inputs and outputs that require minimal human
intervention

User interface
Requires
q
user interaction to pproduce inputs
p and outputs
p

Most analysts separate the design of system interfaces

from user interfaces as each requires different
expertise and technologies

Understanding the User Interface

To the end user, the user interface is the system
Physical devices, parts, or documents
Perceptual
P
t l aspects
t including
i l di seeing,
i hearing,
h i andd
touching
Conceptual details about how to use the system
Referred to as the users model

Perceived by
user senses
(seen, heard etc)

Physical
y
Artifacts
manipulated by
user

Conceptual
(abstract concepts
and actions)

Figure 11-1
Ph i l perceptual,
Physical,
t l andd conceptual
t l aspects
t off the
th user interface
i t f

Poor Interface Design

Psychological Responses of Users

Confusion
e.g., too
t muchh detail
d t il on screens

Panic
e.g.,
g long
g delays/response
y
p
times
Unless messages inform users (LoadingPlease
Wait) users are unsure of what is happening or if
the system
y
is OK?

Boredom
e.g., too much help detail for experienced users
slow
l progress through
h
h screen

Frustration
Users cannot undo a change
g or quit
q
the system
y
no system acknowledgment for a users change

Poor Interface Design

Physical Responses of Users

Abandonment
use of the old system or other sources by managers

Incomplete Use of the System

use the easiest or most beneficial operations only

Indirect Use of the System

Intended users have an intermediary perform system activities

Misuse of the System

Bend the rules of the system
Users require some knowledge & may affect system integrity

Poor Interface Design

Physical Responses of Users
Task Modification
Fit organisation tasks to suit the system
Stems from a rigid system design

Compensatory Activity
Add tasks to suit the system inadequacies
e.g., manual reformatting or sorting by clerical staff

Direct Reprogramming
directly adapt system to suit specific needs

Good vs. Bad Design

UI design is humbling
Your attempt may work right, look great
But users may not be able to use it
Dont take it personally! Thats why we iterate!

It is often easy to detect a bad design just try it

with a few users
Interface Hall of Shame
http://www.baddesigns.com/examples.html
http://www.masternewmedia.org/news/2005/04/17/bad_user_int
erface design can htm
erface_design_can.htm

HCI as a Field of Study

HCI (human-computer interaction) studies the
systemss end users and their interactions with
system
computers
HCI evolved from human factor engineering
(ergonomics)
HCI is
i dependent
d
d t on severall disciplines
di i li
Art, Psychology, Sociology, Design, IT, .etc

HIC is important, as we need to understand the

behavior of the end users

Figure 11-2
The fields contributing to the study of HCI

Cognitive Considerations
From Don Normans book, The Psychology
(Design) of Everyday Things
Affordances, Constraints, and Mappings
Mental Models

Affordances
are the perceived properties of an object that
determine how it can be used.
Knobs
b are for
f turning
i andd buttons
b
are for
f pushing
hi etc.

Some affordances are obvious,, some are learned.

Glass can be seen through.
Glass breaks easily.

Sometimes visual plus physical feedback

e.g.,
e g a Floppy disk
Is Rectangular so we cant insert it sideways
Has Tabs on the disk to prevent the drive from letting it be
f ll inserted
fully
i
d backwards
b k d

Affordances of a Teapot?

S
Something
h
wrong hhere?
?

Real vs. Perceived Affordances

In product design, where one deals
with real,
real physical objects,
objects there can
be both real and perceived
affordances,
ff d
andd the
th two
t needd nott be
b
the same

Affordances in Screen-Based
I t f
Interfaces
In ggraphical,
p
screen-based interfaces, all that the designer
g
has available is control over perceived affordances
Display screen, pointing device, selection buttons, keyboard
These afford touching,
touching pointing,
pointing looking,
looking clicking on every pixel of
the display.

There might be a gap between the real affordance and the

user perceived affordances
does the user p
perceive this affordance? does the user recognise
g
that
clicking on the icon is a meaningful, useful action?

Transfer Effects
People transfer their expectations from
f ili objects
familiar
bj t to
t similar
i il new ones
positive transfer: previous experience applies to
new situation
negative
g
transfer: pprevious experience
p
conflicts
with new situation

Cultural Associations
red = danger, green = go
But these differ in different places, for example:
Cars
C
America: drive on the left
Britain: drive on the right

Faucets
America: counter-clockwise
co nter clock ise is on
Britain: counter-clockwise is off

Mental Models
People have mental models of how things
work:
how does an ATM work?
how does your computer boot?

This allows people to make predictions

g will work
about how things

Mental Models
Mental models are built from

affordances
constraints
mappings
positive transfer
cultural associations/standards
instructions
interactions

Mental models are often wrong!

We have mental models of how bicycles work

We can simulate
simulate this to know it won
wontt work

A user feels comfortable when the mental

model matches the real model!

Metaphors for HCI

Desktop (Direct Manipulation)
Interaction with a display
p y screen that includes objects
j
commonly found on a desk (trash, folders, calculator)

Document
Involves browsing and entering data on electronic
documents using hypertext and hypermedia
Note: the WWW is based on this metaphor

Dialog
C
Carrying
i on a conversation
i with
i h the
h computer by
b
sending and receiving messages

Figure 11-3
The desktop metaphor is based on direct manipulation
manipulation,
shown on a display screen

Figure 11-4
The document metaphor example with
h
hypermedia
di in
i a Web
W b browser
b

Figure 11-5: The dialog metaphor expresses the concept that the
user and the computer system interact by sending messages

Figure 11-6
The users language
g g
and the computers
language used to
i l
implement
t an e-mail
il
application based on the
natural dialogg between
a manager and an
assistant

The Desktop Metaphor of

Direct Manipulation
Direct Engagement
the feeling of working directly on the task

Direct Manipulation
An interface that behaves as though the interaction was with a realreal
world object rather than with an abstract system

Central ideas

visibility of the objects of interest

rapid, reversible, incremental actions
manipulation
i l i by
b pointing
i ti andd moving
i
immediate and continuous display of results

Direct Manipulation
Consequences
Items can be represented as icons
Items can be picked
picked up
up and moved
moved on
a surface
Items can be thrown
thrown out
out into a trash can
Items can be copied

Identify the mis-matched metaphors

(from the Interface Hall of Shame)
The classic (from the mac desktop)
To
T eject
j t a disk
di k you drag
d
it to
t the
th trashcan
t h

Dialog Designs
Inputs and outputs are obtained from use cases and scenarios
Menus
M
should
h ld reflect
fl the
h overall
ll system structure from
f
the
h
point of view of the user
Each subsystem might be represented as a menu,
menu with each menu option
representing a use case
Menus should also include options that are not based on use cases (such
as system controls, user help)
Menus might employ hotkeys (such as Control and C to Copy) to reflect
different user
userss expertise
Some Menu options might also be available from controls on the
form/screen, for example F1, a Help Office Assistant, etc

Figure
g
11-8
One overall menu hierarchy
design for the RMO customer
support system (not all users
will have all of these options
available)

Dialogs and Storyboards

There are several options for documenting dialogs.
S
Some
generall options
i
are:
List the key steps for each dialog, including descriptions of
what
h the
h user andd the
h computer do
d at each
h step
Write out a human and computer conversation
Used for complicated or uncertain requests

Use storyboarding to show a sequence of sketches of a

display screen during a dialog
Initial design can be a general framework

Figure 11-9
Example of a
Storyboard for the
DownTown Videos
rent videos dialog

Dialog Documentation provided by

UML Diagrams
Use case descriptions show a list of steps followed as
a user and computer interact
Activity diagrams document a user-computer
user computer dialog
for each use case
SSDs
SSD describe
d
ib sequential
ti l actor-computer
t
t messages
Class diagrams add user-interface classes for forms
Detailed sequence diagrams show users interacting
with specific
p
objects
j
in forms

Figure 11-10: An example of a sequence diagram for the RMO Look up

item availability dialog with the ProductQueryForm added

Figure 11-11
A class diagram showing interface classes
making up the ProductQueryForm

Figure 11-12: An example of a sequence diagram showing specific interface objects making up the
ProductQueryForm for the Look up item availability dialog (not all problem domain objects are shown)

Input Design Questions

Will the input data be:
Accurate?
Can it be completed correctly by a novice?

Effective?
Does the data serve an effective purpose?
is it really information?

Consistent?
Is the data grouping the same from
application to application?

Input Design
Will the input screen be:
Simple?
Are the screens uncluttered?
ttoo many menu choices
h i
too many control options

Is the language clear?

Are the directions concise?
Are there clear Error Messages? Help
Messages?

Input Design
Will the input screen be:
Easy to use?
Is there sufficient explanation or direction?
Help, Error Messages

Are
A there
h
any assumptions
i
off Specialised
S i li d Knowledge?
K
l d ?
Help, Error Messages

Are there consistent controls?

Exit, Main Menu, Help

Are there consistent areas?

Is there consistency of purpose?
Is there a focus line or flow for the user to follow?

Guidelines for Design

Metaphors
use our knowledge of the familiar and concrete to represent
abstract concepts
need not be literal
have limitations that must be understood

Provide
ov de a good co
conceptual
ceptua model
ode
allows users to predict consequences of actions
communicated through the image of the system

Guidelines for Design

Make things visible
relations between user
userss intentions
intentions, required
actions, and results should be
sensible
consistent
meaningful (non
(non-arbitrary)
arbitrary)

make use of visible affordances, mappings, and

constraints
remind the user of what can be done and how to
do it

Design Guidelines
Good Representations
capture essential elements of the event / world
deliberately leave out / mute the irrelevant
appropriate for the user, their task, and their interpretation

There are LOTS of them

Based on common sense and experience
Not necessarily proven

Often conflict with one another

Often dont say HOW to implement them

Two Key Principles

Two key principles (from HCI researcher Donald Norman)
Vi
Visibility
ibilit
All controls should be visible and provide immediate feedback
to the user
Corollary:
A control should not be visible if it is intended to be unavailable
to the user or
it should be indicated as unavailable, e.g., by greying out a data
input textbox

Affordance
The appearance of any control should suggest its functionality

Figure 11-7
The eight golden rules for designing interactive interfaces
These need to be known and applied

Rule 1: Be Consistent
Consistency of effects
same words
words, commands
commands, actions will always have
the same effect in equivalent situations

Consistency of language and graphics

same information/controls in same location on all
screens / dialog boxes
same visual appearance across the system

Consistencyy of input
p
consistent syntax across complete system

Rule 1: Be Consistent
These are labels with a
raised
a sed appearance.
appea a ce
Is it any surprise that
people try and click on
them?

Rule 2: Provide shortcuts

Experienced users should be able to perform frequently
used operations quickly
Strategies:
keyboard and mouse accelerators

abbreviations
command completion
menu shortcuts
function keys
double clicking vs menu selection

type-ahead
yp
((entering
g input
p before the system
y
is readyy for it))
navigation jumps
e.g., going to location directly, and avoiding intermediate nodes

Rule 3: Provide feedback

Continuously inform the user about
what
h t it is
i doing
d i
how it is interpreting the users input
user should
h ld always
l
be
b aware off what
h is
i going
i on
Whats
it
doing?

> Doit

> Doit
This will take
5 minutes...

Time
for
coffee
.

Rule 3: Provide feedback

User feedback should be as specific as
possible, based on users input
Feedback is best when it is within the users
user s
context of the action

Rule 3: Provide feedback

Response time
Affects how users perceive delays:
<0.1 second ((max):
) pperceived as instantaneous
0.1 to 1 seconds (max): the users flow of thought
stays uninterrupted, but a delay is noticed
1 to 10 seconds: approaching the limit for keeping a
users attention focused on the dialog
>10 seconds: user will want to perform other tasks
while waiting

Rule 4: Provide clearlyy marked exits

Users dont like to feel trapped by the computer!
should
h ld offer
ff an easy way outt off as many situations
it ti
as
possible

Strategies:

Cancel button ((for dialogs

g waiting
g for user input)
p )
Universal Undo (can get back to previous state)
Interrupt (especially for lengthy operations)
Quit (for leaving the program at any time)
Defaults (for restoring a property sheet)

Rule 8: Minimise users

user s memory load
Computers good at remembering things,
people arent!
Promote recognition
i i over recall
ll
menus, icons, choice dialogg boxes versus
command lines, field formats
relies on visibility of objects to the user (but
less is more!)

Rule 8: Minimise users memory load

Describe required input format, use
examples,
l provide
id default
d f lt values
l
Small number of rules applied universally
ggeneric commands
same command can be applied to all interface
objects
copy, cut, paste, drag n drop, ... for characters,
words paragraphs,
words,
paragraphs circles,
circles files

Rule 8: Minimize users memoryy load

Describe required input format, use
examples,
l provide
d default
d f l values
l

User-Centered Design
Technique that places the user as the central focus
for the development
p
process.
p
It:
Focuses early on users and their work
Understand user styles and preferences

Uses iterative development

Continually return to the user requirements and evaluate the
system
Evaluates designs iteratively to ensure usability
Ease of learning and use is dependent on the type of user

User-centered Design
Standard Approaches:
N
Needs
d assessment
Task analysis
Initial design
N d assessmentt techniques:
Needs
t h i
Observation
Interviews
Study existing successful designs

User-Centered Design
g Overview
Needs assessment
Find out
who the users are
what their goals are
what tasks theyy need to pperform

Task Analysis
Characterise what steps users need to take
Create
C t scenarios
i off actual
t l use
Decide which users and tasks to support

Then Design
g based on this
Evaluation
Test the interface by walking through tasks
Obvious but do this before implementation

Needs Assessment Questions

Q

Who is going to use the system?

What tasks do they now perform?
What tasks are desired?
How are the tasks learned?
Where are the tasks performed?
What is the relationship between the
user and the data?

Needs Assessment Questions

Q
What other tools does the user have?
How do users communicate with each
other?
How often are the tasks performed?
What are the (time) constraints on the
task?
What happens when things go wrong?

User-Centered Design
Interview
Prepare a list of questions about how people do their tasks
currently and what extras they would like to have.
Interview at least three people
Ask them what, if anything, must be in the system in order
for them to prefer it over the current system
Examine existing interfaces for their goal and see how they
handle the necessary tasks.

Task Analysis
Characterise what happens when users
perform
f
typical
i l tasks
k
Tools:
Prepare a table of user communities
versus user tasks
Who versus What

table of task sequences

flowchart or transition diagram
videotape
id
depicting
d i i scenario
i

How Often Do Users Perform the

Tasks?
Frequent users remember more details
Infrequent users may need more prompting
Which function is performed
most frequently?
by which users?

Optimize the system for tasks that will

improve the users perception of its
performance

Think Outside-in
versus Inside-out
I id
Do not expect others to think or behave
as you do
as you would like them to

Assess the meaning of the displays and

controls
t l based
b d on what
h t a user can be
b
assumed to know, not based on what you
know
Prevent the designer
g
/ programmer
p g
from
imagining they are the user

Next Step-Rapid
p
p Prototyping
yp g
Build a mock-up
p of the design
g
Use low-fidelity techniques
paper sketches
k t h
cut, copy, paste
video segments

Use Interactive prototyping tools

Visual Basic, HyperCard, Director, Flash, etc.

Why Do We Prototype?
To get feedback on our design faster
saves money

To experiment with alternative designs

To fix problems before code is written
To keep the design centered on the user
(user centric)
(user-centric)

Why Use Prototypes?

Traditional methods take too long
sketches
k h -> prototype -> evaluate
l
-> iterate
i

Can simulate the prototype

sketches -> evaluate -> iterate
sketches act as prototypes
designer plays computer
other design team members observe & record

Low implementation
i l
i skills
kill
allows non-programmers to participate

Summary
To the user, the user interface is the system
Design the interaction between the user and
the computer
p
(HCI)
(
)
Define an overall user-interface concept for
the system early in the project
Focus on users and their work
Ensure
E
usability
bilit
Apply iterative development

Summary (continued)
Metaphors are used to describe the user interface
Dialog
Emphasizes the interaction between the user and computer

Document
Desktop

Interface design guidelines and standards

Normans visibility and affordance guidelines
Shneidermans eight golden rules

Dialog design
Identify
Id tif dialogs
di l
based
b d on use cases