HUMAN COMPUTER INTERACTION

Lecture 08

1
The process of interaction
design
 Overview
• What is involved in Interaction Design?
– Importance of involving users
– Degrees of user involvement
– What is a user-centered approach?
– Four basic activities

• Some practical issues

– Who are the users?
– What are ‘needs’?
– Where do alternatives come from?
– How do you choose among alternatives?

• A simple lifecycle model for Interaction Design

• Lifecycle models from software engineering

• Lifecycle models from HCI

 What is involved in Interaction
Design?
• 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

• It is a representation:
– a plan for development
– a set of alternatives
and successive
elaborations
What is interaction design
about?
• In interaction design, we investigate
the artifact's use and target domain by
a
taking user-centered approach to
development. This means that users'
concerns direct the development rather
than technical concerns.
• Design is also about trade-offs,
about
balancing conflicting requirements.
 Activity
• Imagine that you want to design an electronic
calendar or diary for yourself. You might use this
system to plan your time, record meetings and
appointments, mark down people's birthdays, and so
on, basically the kinds of things you might do with a
paper-based calendar.

• Draw a sketch of the system outlining its functionality

and its general look and feel. Spend about five
minutes on this.
 Activity
• In this activity, you may have started by thinking about
what you'd like such a system to do for you, or you may
have been thinking about an existing paper calendar.
• You may have mixed together features of different
systems or other record-keeping support. Having got or
arrived at an idea of what you wanted, maybe you then
imagined what it might look like, either through sketching
with paper and pencil or in your mind.
 Importance of involving users
• Expectation management
– Realistic expectations
– No surprises, no disappointments
– Timely training
– Communication, but no hype
• Ownership
– Make the users active stakeholders
– More likely to forgive or accept problems
– Can make a big difference to
acceptance and success of product
Degrees of user involvement
• Member of the design team
– Full time: constant input, but lose touch with
users
– Part time: inconsistent input, and very stressful
– Short term: inconsistent across project life
– Long term: consistent, but lose touch with users

• Newsletters and other dissemination

devices
– Reach wider selection of users
– Need communication both ways

• Combination of these approaches

 What is a user-centered
approach?
User-centered approach is based on:
– Early focus on users and tasks: directly studying
cognitive, behavioural, 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
 Four basic activities
There are four basic activities in Interaction Design:

– 1. Identifying needs and establishing requirements

– 2. Developing alternative designs

– 3. Building interactive versions of the designs

– 4. Evaluating designs
 Identifying needs and
establishing requirements
• In order to design something to support
people, we must know who our target
users are and what kind of support an
interactive product could usefully provide.

• These needs form the basis of the product's

requirements and strengthen
subsequent design and development
Developing alternative designs
• This the core activity of designing: actually
suggesting
is ideas for meeting the requirements.
• This activity can be broken up into two sub-
activities: conceptual design and physical design.
• design involves producing the conceptual model for the
product and conceptual model describes what the
product should do, behave and look like.
• Physical design considers the detail of the product
including the colors, sounds, and images to use, menu
design, and icon design. Alternatives are considered at
every point.
 Building interactive
versions of the designs
• Interaction design involves designing interactive products.
The most sensible way for users to evaluate such designs,
then, is to interact with them.
• This requires an interactive version of the designs to be
built, but that does not mean that a software version is
required. There are different techniques for achieving
"interaction," not all of which require a working piece of
software.
• For example, paper-based prototypes are very quick
and cheap to build and are very effective for
identifying problems in the early stages of design, and
through role-playing users can get a real sense of what it
will be like to interact with the product.
 Evaluating designs
• Evaluation is the process of determining the usability
and acceptability of the product or design that is
measured in terms of a variety of criteria including the
number of errors users make using it, how appealing it
is, how well it matches the requirements, and so on.
Interaction design requires a high level of user involvement
throughout development, and this enhances the chances of
an acceptable product being delivered.
• In most design situations you will find a number of activities
concerned with quality assurance and testing to make sure
that the final product is "fit-for-purpose."
• Evaluation does not replace these activities, but
complements and enhances them.
Three key characteristics of the
interaction design process

There are three characteristics that we

believe should form a key part of the
interaction design process. These are:
• a user focus,
• specific usability criteria,
• iteration
 Some practical issues
• Who are the users?

• What are ‘needs’?

• Where do alternatives come from?

• How do you choose among

alternatives?
 Who are the users?
• Identifying the users may seem like a
straightforward activity, but in fact there are
many interpretations of "user."
• The most obvious definition is those people
who interact directly with the product to
achieve a task. Most people would agree with
this definition; however, there are others who
can also be thought of as users.
 Who are the users?
• The trouble is that there is a surprisingly wide
collection of people who all have a stake in the
development of a successful product. These
people are called stakeholders.
• Stakeholders are "people or organizations
who will be affected by the system and
who have a direct or indirect influence on the
system requirements"
 Who are the
users/stakeholders?
• 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
 Activity
• Who do you are the
think
stakeholders for the check-
out system of a large
supermarket?
 Who are the stakeholders?
Check-out operators

• Suppliers
• Local shop
owners

Customers
Managers and owners
What are the users’ capabilities?
Humans vary in many dimensions:
—size of hands may affect the size and positioning of input
buttons
—motor abilities may affect the suitability of certain input
and output devices
— height if designing a physical booth
— strength - a child’s toy requires little strength to
operate,
but greater strength to change batteries
— disabilities(e.g. sight, hearing, deftness)
 What are ‘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
– can be described as future scenarios
 Where do alternatives
come from?
• 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
 IDEO TechBox
• The Box, which is a combination parts
materials
Tech library,
and database and website, and
organizational memory. It allows IDEO to archive its
wide array of experience gained from work across many
industries and share it across all studios in our
worldwide network.
• All major IDEO offices maintain a duplicate Tech Box,
each with its own supervisor who oversees the addition
of new materials, and most IDEO employees are
constantly on the lookout for likely candidates for
addition.
• Additionally, IDEO offers the Tech Box as part of its
innovation services, as its clients become increasingly
aware of the value of knowledge management
 IDEO TechBox
• Each Tech Box has several drawers holding hundreds of
objects, from smart fabrics to elegant mechanisms to clever
toys, each of which are tagged and numbered.
• Designers and engineers can search through the
compartments, play with the items, and apply materials used
by other designers and engineers within the company to their
current project.
• The entire contents of the Tech Box are available on IDEO’s
intranet through a searchable website, with each item listing
its specifications, including manufacturer and price, and an
additional IDEO anecdote with designer and project info if
applicable. The Tech Box is a valuable resource that designers
and engineers use to gain inspiration, break out of a holding
pattern.
 IDEO TechBox
• Library, database, website - all-in-one
• Contains physical gizmos for inspiration

From: www.ideo.com/
The TechBox
 How do you choose
among
alternatives?
• 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
Testing prototypes to choose
among alternatives
 Life Cycle Models
“You’ve got to be very careful if you don’t
know where you’re going, because you might
not get there.”

Yogi Berra

HCI – Umber Shamim

 Lifecycle models
• Show how activities are related to each other
• Lifecycle models are:
— management tools
— simplified versions of reality

• Many lifecycle models exist, for example:

— from software engineering: spiral,
waterfall, Microsoft, agile
— from HCI: Star, usability engineering
 The process of design

scenarios
what is
task analysis
wanted guidelines

interviews analysis principles

precise
ethnography specification
what is there design
vs. dialogue
what is notations
wanted implement
and
deploy
evaluation
prototype
heuristics architectures
documentation
help
 Steps …
• requirements
– what is there and what is wanted …
• analysis
– ordering and understanding
• design
– what to do and how to decide
• iteration and prototyping
– getting it right … and finding what is really needed!
• implementation and deployment
– making it and getting it out there
A simple interaction design
model

Exemplifies a user-centered design approach

Traditional ‘waterfall’ lifecycle
 Spiral model (Barry Boehm)
Important features:
 Risk analysis
 Prototyping
 Iterative framework so ideas can be checked and
evaluated
 Explicitly encourages considering alternatives
 Each cycle involves the same sequence of steps as
the waterfall process model

Good for large and complex projects but not

simple ones
Spiral Lifecycle model
A Lifecycle for RAD
(Rapid Applications Development)
Dynamic System Development Method
(DSDM) lifecycle model
HCI: Models

HCI – Umber Shamim

The Star lifecycle model
• Suggested by Hartson and Hix (1989)

• Important features:
—Evaluation at the centre of activities
—No particular ordering of activities; development
may start in any one
—Derived from empirical studies of
interface designers
The Star Model (Hartson and Hix, 1989)
The Star Model (Hartson and Hix, 1989)
• The one here is taken fromHartson and Hix
• Model came about by analysing how design takes
place in practice
• Evaluation is central: results of each activity are
evaluated before going onto next one
• both bottom-up and top -down required in
wavesvsoftware designers are familiar with this in
their work and call it ‘yo-yoing’
• it is important to do both structure and detail at
the same time
• in practice this is what is done - ?
 The Star Model (Hartson and Hix,
1989)

• The Star lifecycle does not specify any ordering of

activities. In fact, the activities are highly you can
move from any activity to any other, provided you first
go through the evaluation activity. This reflects the
findings of the empirical studies.
• Evaluation is central to this model, and whenever an
activity is completed, its result(s) must be evaluated.
So a project may start with requirements gathering, or
it may start with evaluating an existing situation, or
by analyzing existing tasks, and so on.
 Usability engineering
lifecycle model
• Reported by Deborah Mayhew
• Important features:
– Overview of usability engineering
– Provides links to software engineering approaches, e.g.
OOSE
– Stages of identifying requirements, designing,
evaluating, prototyping
– Can be scaled down for small projects
– Uses a style guide to capture a set of
usability goals
 Usability engineering
lifecycle model
• The lifecycle itself has essentially three
requirements
tasks: analysis, design /testing/development, and
installation, with the middle stage being the largest and
involving many subtasks (see Figure).
• Note the production of a set of usability goals in the first
task. Mayhew suggests that these goals be captured in a
style guide that is then used throughout the project to
help ensure that the usability goals are stick to.
• This follows a similar thread to our
interaction
lifecycle design model but includes considerably
more detail. It includes stages of identifying requirements,
designing, evaluating, and building prototypes
Standards:
ISO 13407

HCI – Umber Shamim

 ISO 13407
• The standard applies to software products, hardware/software
systems, websites, and services.
• The goal of the standard is to ensure that the development and
use of interactive systems take account of the needs of the user as
well as the needs of the developer and owner... to name but a few
stakeholders.
• ISO 13407 is a description of best practice in user centered
design.
• It provides guidance on design activities that take place
throughout the life cycle of interactive systems.
• It describes an iterative development cycle where product
requirements specifications correctly account for user and
organizational requirements as well as specifying the context in
which the product is to be used.
• Design solutions are then produced which can be evaluated by
representative users, against these requirements.
 ISO 13407
The Standard describes:
Four Principles of Human-Centre Design:
 active involvement of users
 appropriate allocation of function to system and
to user
 iteration of design solutions
 multi-disciplinary design
 ISO 13407
Four Human-Centered Design
Activities:
• understand and specify the context
of use
• specify user and organizational
requirements
• produce more than one candidate
design
solution
• evaluate designs against
requirements
ISO 13407
 Summary
Four basic activities in the design process
1. Identify needs and establish requirements
2. Design potential solutions ((re)-design)
3. Choose between alternatives (evaluate)
4. Build the artifact
User-centered design rests on three
principles
5. Early focus on users and tasks
6. Empirical measurement using quantifiable &
measurable usability criteria
3. Iterative design

Lifecycle models show how these are related

THANK YOU

57