Interaction design

Natnael Gonfa
 Interaction design

Designing interactive products to support

the way people communicate and interact
in their everyday and working lives
Sharp, Rogers and Preece (2011)

The design of spaces for human

communication and interaction
Winograd (1997)
 Goals of interaction design
Develop usable products
Usability means easy to learn, effective
to use and provide an enjoyable
experience
Involve users in the design process
 Importance of Interaction
Design
Poor design can:
reduce user productivity
increase learning times
increase errors
induce frustration
lead to system rejection by the user
Poor design is easy, good design is
hard
 Which kind of design?
Number of other terms used emphasizing
what is being designed, e.g.
user interface design, software design, user-centered
design, product design, web design, experience design
(UX)

Interaction design is the umbrella term

covering all of these aspects
fundamental to all disciplines, fields, and approaches
concerned with researching and designing computer-
based systems for people
HCI and interaction design
 What do professionals do in the ID
business?
interaction designers - people involved in the design of all
the interactive aspects of a product

usability engineers - people who focus on evaluating

products, using usability methods and principles

web designers - people who develop and create the visual

design of websites, such as layouts

information architects - people who come up with ideas of

how to plan and structure interactive products

user experience designers (UX) - people who do all the

above but who may also carry out field studies to inform the
design of products
 Good design
Takes into account:
Who the users are People
What activities are being carried
out - Activities
Where the interaction is taking
place - Context
What technologies are used -
Technologies
User-centric View of Design
Problems: PACT
 PACT Analysis
User-centric framework for thinking about a design
problem
Take each category ---People-Activities- Context and
Technology --- and work through it
Use the analysis to help focus/orient early design
thinking
Important: revisit the analysis
As you get deeper into the problem the analysis
should change and/or get richer
 People: Who are the
users/stakeholders?
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 competitors 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
 People: variability
Consider range of characteristics of
people
Physiologically
Age differences, physical abilities
Psychologically
Attention, perception, memory
Forming the right mental model
Socially and Culturally
People: 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 kiosk
strength - a childs toy requires little strength to
operate, but greater strength to change batteries
different abilities (e.g. sight, hearing, dexterity)
 Activities
What is the overall purpose of the activity?
What has to be satisfied
Hedonic vs. Pragmatic
Temporal aspect
Regular or infrequent
Time pressure
Continuous or interruptions
Processing time
Cooperation
One or more actors
Complexity
Well defined or vague?
Safety critical
Impact of error (how much?)
The nature of the content
Type of data to be processed
Type of media
 Context
Where does the interaction occur?
Physical context
Noise, light, time
In the office, on the move
Social context
Individual activity, group activity
Computer-mediated social activity
Social norms
Psychological context
Motivation, attitudes
Cognitive demands
Level of arousal
 Technology
Input
Getting data in; getting commands; security
Output
video vs. photographs; speech vs. screen
Communication
Between people, between devices, speed,
Content
What data in the system: a web site is all
about content
 Key characteristics
Focus on users early in the design
and evaluation of the artifact
Identify, document and agree specific
usability and user experience goals
at the beginning of the project
Iteration is inevitable. Designers
never get it right first time
 Understanding user needs
ASK-WATCH-ANALYSE
Users rarely know what is possible they cant tell you
what they need to help them achieve their goals
Take into account peoples capabilities
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
 Develop alternative design
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
 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 checked regularly
safety: how safe?
utility: which functions are superfluous?
effectiveness: appropriate support? task coverage,
information available
efficiency: performance measurements
Easy to learn
Easy to remember how to use
 User requirements
What is done?
Identifying needs
Understand as much as possible about
the
user, their work and the context of use
See PACT analysis (unit 1)
Establish a set of stable requirements
Requirements MUST be justified and
related
to data
Set up clear success metrics, usability,
user
experience requirements
 How is it done?
Data gathering activities
Data analysis activities
Expression as requirements
All of this is iterative
 Requirements type
Functional
Fundamental or essential
characteristics of
the product
Describe what the product has to do
or what
processing actions it is to take
Historically the main focus of
requirements
 Example
For a multifunction PDA
Phones function must be accessible
while
connected to the internet
For a nuclear power control system
The system will be able to monitor
the
temperature of the reactors
 Requirements type (2)
Non functional
Properties that the functions must have
Describe the constraints that there are on
the system and its development
Covers a number of aspects of design:
image,
usability, performance, maintainability, security,
cultural acceptability, etc.
As important as functional requirements for
the
product's success.
 Example
For a multifunction PDA Look and feel
The system must present an up-
market,
business like image
For a nuclear power control system -
Usability
Warnings signals MUST be clear and
unambiguous
 User requirements
Users: Who are they?
Characteristics: ability, background, attitude to
computers
System use: novice, expert, casual, frequent
Novice: step-by-step (prompted), constrained,
clear
information, e.g., wizard prompting
Expert: flexibility, access power
Frequent: short cuts
Casual/infrequent: clear instructions, e.g., menu
paths
 Data-gathering
Studying documentations
Researching similar products
Interviews
Questionnaires
Observation
 Studying documentation
Procedures and rules are often written down in
Manuals
Good source of data about the steps involved in
an activity and any regulations governing a task
Good for understanding legislation, and getting
background information
Not to be used in isolation
Advantage: No stakeholders time
 Observation
Naturalistic observation:
Spend time with stakeholders in their day-to-
day
tasks, observing their activities
Gain insights into stakeholders tasks
Good for understanding the nature and context
of the tasks
It requires time and commitment from a member
of the design team, and can result in a huge
amount of data
 Questionnaires
A series of questions designed to elicit specific
Information
Questions may require different kinds of answers:
simple YES/NO; choice between pre-set answers;
Comment
Often used in conjunction with other techniques
Can give quantitative or qualitative data
Good for answering specific questions from a
large, dispersed group of people
 Interviews & Focus Group
Structured, unstructured or semi-structured
Good for exploring issues
Time consuming and may be infeasible to visit
everyone
Focus group
Group interviews
Good at gaining a consensus view and/or
highlighting
areas of conflict
Props e.g. sample scenarios of use, prototypes,
can be used in interviews
 Which techniques to gather
req?
Depends on:
Amount of time, level of detail and risk
associated with the findings
Knowledge of the analyst
Kind of task to be studied:
Sequential steps or overlapping series of
subtasks
High or low, complex or simple information?
Task for a layman or a skilled practitioner?
 Problems with data gathering -
stakeholders
Identifying and involving the right people:
users, managers, developers, customer
reps?, union reps?, shareholders?
Involving stakeholders
workshops, interviews, workplace studies,
participatory design
Real users, not managers
traditionally a problem in software
engineering, but better now
Availability of key people
 Problems with data
gathering (2)
Requirements management: control, ownership
Communication between parties:
within development team
with customer/user
between users: different parts of an
organization use different terminology
Domain knowledge distributed and implicit:
difficult to dig up and understand
knowledge articulation
 Guidelines
Involve all the stakeholder groups
Involve more than one representative from
each
stakeholder group
Use a combination of data gathering
techniques
Support the process with props such as
prototypes and task descriptions
Run a pilot session
Consider carefully how to record the data
 Personas
A persona is a fictional user, with a
made-up life
Capture user characteristics
Not real people, but synthesized from real
user characteristics
Should not be idealized
Bring them to life with a name,
characteristics, goals, personal background
Develop multiple personas
Sarah Red is 24 years old and works as a web-designer at Zurich
Insurance.
Sarah has a BA in three dimensional design from Middlesex University and
an
M.A. in computer related design from the Royal College of Art in London.
She
has worked for Zurich for the past two years and quite openly dislikes it.

Sarah is a talented designer who likes to experience the latest technology

and
has won several prises for her design. Yet, in her job she has to be very
conservative. She prepares forms for on-line quotes and provides general
information about the company to their web-customer.

Sarah dreams of joining a designer studio in London where she could fulfil
her
talent. The current position, although boring, offers a good salary and the
possibility of living in London where . she can search for her dream job.

Sarah works in the web-development team. Her new boss is Elisabeth, a

software engineer who does not understand the user experience and is
more concerned with technical details than with design. Sarah is reasonably
free in her job, as nobody seems to care.

Sarahs been told that the company has adopted edgeConnect and that her
 Scenarios
Key technique in interaction system design
(Rosson and Carroll 2002)
Iterative tools to be used throughout the
design
Process
User stories = informal narrative description
which reports about user tasks and activities.
Short snippets which tend to focus on the
user needs and motivations to perform a task
rather than on the use of a technology.
The summer term has just started and Fritz, a computerscience
student at the Technische Universitt Dresden, has decided to attend
a course on "User Interface generation for Web Services. He logs in
the University portal and accesses an overview of all lectures, sport
and language courses. He tries to subscribe to the UI course but the
system indicates a timetabling conflict with the course on Service-
oriented Architecture he previously registered to. Fritz sign in an
Italian course, which is automatically displayed in his personal weekly
calendar.

Fritz wonders whether he should change his study plan to

accommodate for the UI course. Thus he decides to ask other
students opinion. He joins a chat room, but nobody is there. Fritz
waits for other students while working on an assignment
using the library service.

Looking at the watch on the portal, he realizes that he has only 30

minutes before a date with a girl met at the University online social
network. Fritz switches on his PDA and logs into the university portal
while boarding the tram. A beep indicates that some students have
joined the chat room and after a short negotiation he manages
to swap his place from the Service-oriented Architecture course
with a place in the User Interface course with another student. The