3/26/2015
CENG 394
Introduction to
Human-Computer Interaction
CENG 394
HCI
The process of
interaction design
1
2
Overview

What is involved in Interaction Design?





What is involved in Interaction Design?
Importance of involving users
Degrees of user involvement
What is a user-centered approach?
Four basic activities

It is a process:
a goal-directed problem solving activity informed by
intended use, target domain, materials, cost, and
feasibility
 a creative activity
 a decision-making activity to balance trade-offs

Some practical issues




Who are the users?
What are ‘needs’?
Where do alternatives come from?
How do you choose among alternatives?
4
3
Degrees of user involvement
Importance of involving users


Expectation management




Member of the design team



Realistic expectations
No surprises, no disappointments
Communication, but no hype


Newsletters and other dissemination devices

Ownership
Make the users active stakeholders
 More likely to forgive or accept problems
 Can make a big difference to acceptance
success of product


5
Full time: constant input
Part time: patchy input
Short term: inconsistent across project life
Long term: consistent
Reach wider selection of users
Need communication both ways

User involvement after product is released

Combination of these approaches
and
6
1
3/26/2015
What is a user-centered approach?
Four basic activities in Interaction
Design
User-centered approach is based on:

Early focus on users and tasks: directly studying cognitive,
1.
Establishing requirements
2.
Designing alternatives
3.
Prototyping
4.
Evaluating
behavioral, anthropomorphic & attitudinal characteristics

Empirical measurement: users’ reactions and performance to
scenarios, manuals, simulations & prototypes are observed,
recorded and analysed

Iterative design: when problems are found in user testing, fix
them and carry out more tests
7
8
Some practical issues
Who are the users/stakeholders?

Who are the users?

What do we mean by ‘needs’?

How to generate alternatives

How to choose among alternatives

How to integrate interaction design
activities with other models?

Not as obvious as you think:






those who interact directly with the product
those who manage direct users
those who receive output from the product
those who make the purchasing decision
those who use competitor’s products
Three categories of user (Eason, 1987):



primary: frequent hands-on
secondary: occasional or via someone else
tertiary: affected by its introduction, or will influence its purchase
9
10
Who are the stakeholders?
Check-out operators
• Suppliers
• Local shop
owners
What do we mean by ‘needs’?
• Users rarely know what is possible
• Users can’t tell you what they ‘need’ to help them
achieve their goals
• Instead, look at existing tasks:
– their context
– what information do they require?
– who collaborates to achieve the task?
– why is the task achieved the way it is?
• Envisioned tasks:
– can be rooted in existing behaviour
Customers
Managers and owners
11
– can be described as future scenarios
12
2
3/26/2015
How to generate alternatives
IDEO TechBox






Humans stick to what they know works
But considering alternatives is important to ‘break out
of the box’
Designers are trained to consider alternatives,
software people generally are not
How do you generate alternatives?
— ‘Flair and creativity’: research and synthesis
— Seek inspiration: look at similar products or look at
very different products
Library, database, website - all-in-one
Contains physical gizmos for inspiration
From: www.ideo.com/
13
14
How to choose among
alternatives
The TechBox



Evaluation with users or with peers, e.g. prototypes
Technical feasibility: some not possible
Quality thresholds: Usability goals lead to usability
criteria set early on and check regularly
—
—
safety: how safe?
utility: which functions are superfluous?
effectiveness: appropriate support? task coverage,
information available
— efficiency: performance measurements
—
15
Testing prototypes to choose
among alternatives
16
How to integrate interaction
design in other models

Lifecycle models from other disciplines

Agile software development promising
 have
development and design running in separate
tracks
 maintain
a coherent vision of the interface
architecture
17
18
3
3/26/2015
HCI in the software process
HCI in the software
process

Software engineering and the design process for
interactive systems

Usability engineering

Iterative design and prototyping

Design rationale
19
Activities in the life cycle
The waterfall model
Requirements specification
Requirements
specification
designer and customer try to capture what the system is expected to
provide can be expressed in natural language or more precise languages
Validation: satisfies
requirements
Architectural
design
Verification: complete
and internallyconsistent
Detailed
design
Coding and
unit testing
Architectural design
high-level description of how the system will provide the services required
factor system into major components of the system and how they are
interrelated needs to satisfy both functional and non-functional
requirements
Detailed design
refinement of architectural components and interrelations to identify
modules to be implemented separately the refinement is governed by the
non-functional requirements
Integration
and testing
Operation and
maintenance
21
Verification and validation
Real-world
requirements
and constraints
The waterfall model
Why doesn’t it work for UIs?
People are insanely
complicated –
models cannot fully predict
how they will use systems
(especially early).
Requirements
specification
The formality gap
Verification
Architectural
design
Cannot determine all"
requirements from
the start
designing the product right
Validation
Detailed
design
designing the right product
The formality gap
Coding and
unit testing
validation will always rely to some extent on subjective means of proof
Integration
and testing
Management and contractual issues
design in commercial and legal contexts
(which results in 50% designer’s"
time spent on code for UI)!
Operation and
maintenance
24
4
3/26/2015
The life cycle for interactive systems
User-Centered Design
cannot assume a linear
sequence of activities
as in the waterfall model
Requirements
specification
Architectural
design
Detailed
design
Try lots of ideas. See how users respond.
– Involve representative users in all stages of the
development process.
– Minimize the cost of and commitment to prototypes.
– Users often can’t tell you which alternative is “better” –
have to test, measure & observe.
Coding and
unit testing
lots of feedback!
Integration
and testing
Operation and
maintenance
25
Usability engineering
26
Usability engineering
Usability is:
‘……the effectiveness, efficiency and satisfaction with which specified
users can achieve specified goals in particular environments’ (ISO DIS
9241 -part 11)
The ultimate test of usability based on measurement of user experience
Usability engineering demands that specific usability measures be made explicit
as requirements
Usability specification





usability attribute/principle
measuring concept
measuring method
now level/ worst case/ planned level/ best case
Example attributes (measures?)
– Learnability
– Efficiency
– Memorability
– Low error rate
– Subjectively pleasing
Problems


usability specification requires level of detail that may not be possible
early in design satisfying a usability specification
does not necessarily satisfy usability
27
ISO usability standard 9241
some metrics from ISO 9241
adopts traditional usability categories:

effectiveness



can you achieve what you want to?
efficiency

Usability
objective
Effectiveness
measures
Efficiency
measures
Satisfaction
measures
Suitability
for the task
Percentage of
goals achieved
Time to
complete a task
Rating scale
for satisfaction
Appropriate for
trained users
Number of power
features used
Relative efficiency
compared with
an expert user
Rating scale for
satisfaction with
power features
Learnability
Percentage of
functions learned
Time to learn
criterion
Rating scale for
ease of learning
Error tolerance
Percentage of
errors corrected
successfully
Time spent on
correcting errors
Rating scale for
error handling
can you do it without wasting effort?
satisfaction

28
do you enjoy the process?
29
30
5
3/26/2015
Iterative design and prototyping
Iterative design and prototyping

Iterative design overcomes inherent problems of incomplete requirements
Evolutionary Prototype

Prototypes



simulate or animate some features of intended system
different types of prototypes




throw-away
Incremental
Evolutionary

Management issues




time
planning
non-functional features
contracts

The evolutionary approach aims to develop a mature system through a
series of prototype iterations. The prototype will undergo a series of
refinements, and should eventually become the solution. This can be
likened to the first draft, second draft, third draft ... final version.
This approach is particularly useful when the exact requirements of the
solution cannot be set out in advance, or are considered to be vague. The
client and/or end-users can become closely involved in the development,
playing a key role as each iteration moves further from prototype and closer
to a useable solution that does what it is needed to do, and does it well.
The problem with a vague specification is that it can be difficult to verify and
control. Uncertainty can cause frustration through lack of direction and
wasted time, effort and money.
31
32
Iterative design and prototyping
Techniques for prototyping
Incremental Prototype
Storyboards


The incremental approach can be likened to 'building blocks'; incrementing
each time a new component is added or integrated, based on an overall
design solution. When all of the components are in place, the solution is
complete.
An advantage of this method is that the client and/or end-users have the
opportunity to test the developed components and their functionality. They
also have opportunities to provide feedback while other components are still
in development, and can thus influence the outcome of further development.
need not be computer-based
can be animated
Limited functionality simulations
some part of system functionality provided by designers
tools like HyperCard are common for these
Wizard of Oz technique
Warning about iterative design
design inertia – early bad decisions stay bad
diagnosing real usability problems in prototypes….
…. and not just the symptoms
Example: in a new word processing application a user may be able to work with the
interface to open and save documents, but may not be able to print those documents or
make changes fonts or styles because these components have yet to be delivered. The
client and/or end-users are able to provide feedback on the components developed so
far. This may influence also how further components are implemented.
33
34
Design rationale
Design space analysis
Design rationale is information that explains why a
computer system is the way it is.

structure-oriented

QOC – hierarchical structure:
questions (and sub-questions)
Benefits of design rationale






– represent major issues of a design
communication throughout life cycle
reuse of design knowledge across products
enforces design discipline
presents arguments for design trade-offs
organizes potentially large design space
capturing contextual information
options
– provide alternative solutions to the question
criteria
– the means to assess the options in order to make a choice

DRL – similar to QOC with a larger language and more
formal semantics
35
6
3/26/2015
the QOC notation
Option
Summary
Criterion
The software engineering life cycle

Question
Option
Criterion
Usability engineering

Option
distinct activities and the consequences for interactive system
design
making usability measurements explicit as requirements
Iterative design and prototyping
Criterion

limited functionality simulations and animations
Design rationale

Question
…
Consequent
Question
…

recording design knowledge
process vs. structure
38
7