HUMAN

COMPUTER
INTERACTION
(HCI)
Computers Versus Humans [1]
Computers do not work like humans.
■ One part of software, the inside, must clearly be written in harmony
with the demands of silicon.
■ Equally, the other side of software, the outside, must be written in
harmony with the demands of human nature.
Programmers are Different [1]

■ Programmers (“homo logicus”) think and behave differently

from normal humans (homo sapiens) and most users.
■ Programmers are good at designing the inside of software,
interaction designers should design the outside.
Goal-Oriented Interaction
Design [1]
Designing software based on an understanding of human goals.
■ What is a goal?
- A goal is a final purpose or aim, an objective.
- Tasks are particular ways of accomplishing a goal.
- There may be multiple ways of achieving a goal.
Tasks are not Goals
■ Goal: Get something to eat.
■ Task: Go to the restaurant around the corner. Or
■ Task: Call the pizza delivery service. Or
■ Task: Go to the supermarket, buy ingredients, and cook for myself.
■ Too often, software designers focus on simplifying a task, rather than
accomplishing a goal. Tasks are a means to an end, not an end in themselves.
Goal-Oriented Interaction
Design [1]
The Interaction Design Process
1. Interview users
2. Create personas
3. Define their goals
4. Create concrete scenarios
5. Move to a design solution
Personas [2]
The persona is the voice of the user.
■ After understanding your users’ lives, motivations, and environment, a big
question arises: How do you use this research data to come up with a design
that will result in a successful product?
■ The answer is to develop users models or personas
■ Personas provide us with a precise way of thinking and communicating about
how users behave, how they think, what they wish to accomplish, and why.
■ A persona is used to role-play through an interface design and check if the
design would meet the needs of such a user
■ Personas are not real people. They are hypothetical but are based on the
behaviors and motivations of real people we have observed and represent
them throughout the design process
■ There are also other methods such as: workflow models and physical models,
but according to Alan Cooper personas are the strongest, and it is possible to
incorporate the best from other modeling techniques into a persona
 Bad design approach [2]
■ To create a product that must satisfy a diverse audience of users, logic
might tell you to make it as broad in its functionality as possible to
accommodate the most people.
■ This logic, is flawed
■ The best way to successfully accommodate a variety of users is to design
for specific types of individuals with specific needs
■ The key to this approach is first to choose the right individuals to design
for— those users whose needs best represent the needs of a larger set of
key constituents
■ Then prioritize these individuals so that the needs of the most important
users (primary users) are met without compromising our ability to meet
the needs of secondary users
Example of bad design [2]
If you try to design an automobile that pleases every possible
driver, you end up with a car with every possible feature, but
that pleases nobody. Software today is too often designed to
please too many users, resulting in low user satisfaction.
Example of good designs [2]
■ By designing different cars for different people with different specific
goals, we are able to create designs that other people with similar needs to
our target drivers also find satisfying.
Issues Addresses by Personas [2]

Elastic User:
■ Every person on a product team has his own
conceptions of who the user is and what the
user needs
■ When it comes time to make Product
decisions, this “user” becomes elastic,
conveniently bending and stretching to fit the
opinions and presuppositions of whoever’s
talking
■ Real users — and the personas representing
them — are not elastic, but rather have specific
requirements based on their goals, capabilities,
and contexts
Issue Addresses by Personas
(Cont.) [2]
Self-referential design: Personas help in avoiding them
Edge cases: Persona help prevent the primarily design for edge
cases.
■ Typically, edge cases must be designed and programmed for, but
they should never be the design focus.
Constructing Personas [2]

1. Identify behavioral variables.

2. Map interview subjects to behavioral variables.
3. Identify significant behavior patterns.
4. Synthesize characteristics and relevant goals.
5. Check for redundancy and completeness.
6. Expand description of attributes and behaviors.
7. Designate persona types.
Constructing Personas (cont.)
[2]
1. Identify behavioral variables: Generally following
types of variables are important
– Activities — What the user does; frequency and
volume
– Attitudes— How the user thinks about the product
domain and technology
– Aptitudes— What education and training the user
has; capability to learn
– Motivations — Why the user is engaged in the
product domain
– Skills — User capabilities related to the product
domain and technology
Constructing Personas (cont.)
[2]
Map interview subjects to behavioral variables:
Constructing Personas (cont.)
[2]
Identify significant
behavior patterns:
■ Look for clusters of
subjects that occur
across multiple
ranges or variables
■ A set of subjects
who cluster in six to
eight different
variables will likely
represent a
significant behavior
pattern that will
form the basis of a
persona
Constructing Personas (cont.)
[2]
Synthesize characteristics and relevant goals:
■ For each significant behavior pattern you identify, you must
synthesize details from your data.
■ Describe the potential use environment, typical workday (or other
relevant context), current solutions and frustrations
■ At this point, brief bullet points describing characteristics of the
behavior are sufficient
■ Give the personas’ first and last names
■ You can also, at this time, add in some demographic information such
as age, geographic location, relative income (if appropriate), and job
title
■ Identify personas’ goal from interviews and observations
Constructing Personas (cont.)
[2]
Check for completeness and redundancy
Expand description of attributes and behaviors:
■ A typical persona description should be a synthesis of the most
important details observed during research, relevant to this persona
■ The best narrative quickly introduces the persona in terms of his job
or lifestyle, and briefly sketches a day in his life, including irritations,
concerns, and interests that have direct bearing on the product
■ Choose photographs of your personas
Design for the primary –
Accommodate the secondary
Designate persona types:
■ Identify primary and secondary personas
■ The goal is to find a single persona from the set whose needs and goals can be
completely and happily satisfied by a single interface without
disenfranchising any of the other personas
■ Primary personas represent the primary target for the design of an interface
■ A primary persona will not be satisfied by a design targeted at any other
persona in the set
■ However, if the primary persona is the target, all other personas will not, at
least, be dissatisfied
■ A secondary persona is mostly satisfied with the primary persona’s interface
but has specific additional needs that can be accommodated without upsetting
the product’s ability to serve the primary persona
Case Study: In-Flight Entertainment System
[1]

■ Fictional example, an inflight entertainment system called In-Flight

for Zoom Airways.
■ At each seat a touch-screen video console
■ 36 films in five categories, 36 music channels, news, children shows,
games, shopping.
■ Computers + large hard disks in front of the plane.
■ True video on demand – each passenger can start, pause, and rewind
programs independently.
Case Study: In-Flight
Entertainment System (cont.) [1]
Case Study: In-Flight
Entertainment System (cont.) [1]
Case Study: In-Flight
Entertainment System (cont.) [1]
Case Study: In-Flight
Entertainment System (Cont.) [1]
Case Study: In-Flight
Entertainment System (Cont.) [1]
Case Study: In-Flight Entertainment
System (Cont.) [1]

Two different interfaces

■ One for the passengers in the seat console.
■ A different one for employees in the attendant’s station.
Case Study: In-Flight
Entertainment System (Cont.) [1]
Who are the Primary Passenger Personas?
■ The seat console interface has to satisfy Chuck, Erin, Marie, and Clevis, while
at the same time not making any of them unhappy.
■ Erin knows wanting to play games is something special, so she does not mind
pressing a few extra buttons to get them.
■ Chuck knows his vast flying experience has earned him some shortcuts, but he
does not mind investing a little effort into remembering those special
commands.
■ Marie is similar to Chuck, and both would be annoyed by time-consuming
training screens for new users.
■ Clevis is the golden nugget, the primary persona. A menu bar or dialogue box
would instantly lose Clevis. With arthritis, any complex manipulation is out of
the question. An interface designed for Clevis will be acceptable to all the
others, as long as their special needs are accommodated somewhere in the
interface.
Case Study: In-Flight
Entertainment System (Cont.) [1]
Designing for Clevis
■ Clevis can not and will not “navigate”, so there can be only one screen
■ Horizontal scrolling displays film posters and album covers.
■ A large rotating knob (a “data wheel”) physically below the screen,
which can be spun like a radio wheel.
■ Clevis views the posters as if walking past, no need to even think in
terms of film categories.
■ Navigation bar across bottom of screen, feedback where we are and
with jump scrolling for Chuck.
Case Study: In-Flight
Entertainment System (Cont.) [1]
References

[1] Lecture Notes of Prof. Keith Andrews, Available at:

www.iicm.tugraz.at/hci
[2] “About Face 3.0, the Essentials of Interaction Design”, by Alan
Cooper, Robert Reimann, and David Cronin, Third Edition