Human-Computer Interaction

Interaction Design Basics

Shermeen Adnan
 Interaction Design Basics
• design:
– what it is, interventions, goals, constraints
• the design process
– what happens when
• users
– who they are, what they are like …
• scenarios
– rich stories of design
• navigation
– finding your way around a system
• iteration and prototypes
– never get it right first time!
 Interactions and Interventions
• design interactions not just interfaces
– not just the immediate interaction
• e.g. stapler in office – technology changes interaction
style
– manual: write, print, staple, write, print, staple, …
– electric: write, print, write, print, …, staple

• designing interventions not just artefacts

– not just the system, but also …
• documentation, manuals, tutorials
• what we say and do as well as what we make
what is design?
 What is Design?
achieving goals within constraints
• goals – purpose
– What is the purpose of the design we are intending to produce?
– Who is it for?
– Why do they want it?
• constraints
– What materials must we use?
– What standards must we adopt?
– How much can it cost?
– How much time do we have to develop it?
– Are there health and safety issues?
Of course, we cannot always achieve all our goals within the
constraints
• trade-offs
– Choosing which goals or constraints can be relaxed so that others can be met.
 Golden Rule of Design
• The designs we produce may be different, but
often the raw materials are the same. This
leads us to the golden rule of design:

understand your materials

 Golden Rule of Design
• for Human–Computer Interaction
– understand your materials
– understand computers
• limitations, capacities, tools, platforms
– understand people
• psychological, social aspects
• human error
– and their interaction …
 To err is human
• accident reports ..
– aircrash, industrial accident, hospital mistake
– enquiry … blames … ‘human error’
• but …
– concrete lintel breaks because too much weight
– blame ‘lintel error’ ?
… no – design error
we know how concrete behaves under stress
• human ‘error’ is normal
– we know how users behave under stress
– so design for it!
• treat the user at least as well as physical materials!
Central message …

the user
The Process of Design
The waterfall model – Activities
Requirements
Requirements
specification
specification

Architectural
Architectural
design
design

Detailed
Detailed
design
design

Coding
Coding and
and
unit
unit testing
testing

Integration
Integration
and
and testing
testing

Operation
Operation and
and
maintenance
maintenance
 The life cycle for interactive systems
cannot assume a linear
Requirements
Requirements
sequence of activities
specification
specification
as in the waterfall model
Architectural
Architectural
design
design

Detailed
Detailed
design
design

Coding
Coding and
and
unit
unit testing
testing

lots of feedback!
Integration
Integration
and
and testing
testing

Operation
Operation and
and
maintenance
maintenance
 The Process of Design
• Often HCI professionals complain that they are
called in too late.
– A system has been designed and built, and only
when it proves unusable do they think to ask how
to do it right!
– In other companies usability is seen as equivalent
to testing called checking
 The Process of Design
• Many design processes, we use the Universal Methods of Design one
• Planning, scoping, and definition
– What do we want to do?
• Exploration, synthesis, and design implications
– Would it work? Would it solve the problem?
• Concept Generation
– Create a prototype and try it out
• Evaluation, refinement, and production
– Build it, test it, fix it
• Launch and monitor
– See if it works in the real world and perform ongoing review
 The design process of interactive systems
• Requirements
– What the system should do, what properties it should have.
• Envisionment
– “Making ideas visible”: software prototypes, cardboard models, scenarios, sketches…
• Conceptual Design
– Designing the system in the abstract: identify PACT elements. ‘who’ and‘what’, rather
than ‘how’
• Physical Design
– How things will work; look and feel

Prototyping
and Envisionment Requirements

Scenarios Evaluation
user
testing
Physical Design Conceptual Design
 Scenarios
• stories for design
– communicate with others
– validate other models
– understand dynamics
• linearity
– time is linear - our lives are linear
– but don’t show alternatives
 scenarios …
• what will users want to do?

• step-by-step walkthrough
– what can they see (sketches, screen shots)
– what do they do (keyboard, mouse etc.)
– what are they thinking?

• use and reuse throughout design

 Use scenarios to ..
• communicate with others
– designers, clients, users

• validate other models

– ‘play’ it against other models

• express dynamics
– screenshots – appearance
– scenario – behaviour
 linearity
Scenarios – one linear path through system

Pros:
– life and time are linear
– easy to understand (stories and narrative are natural)
– concrete (errors less likely)
Cons:
– no choice, no branches, no special conditions
– miss the unintended

• So:
– use several scenarios
– use several methods
 The design process of interactive systems
• Scenario
– A set of stories about (P)eople carrying out (A)ctivities, in
(C)ontext, using (T)echnology.
– Provide the ability to move back and forth between:
• The specific and the general technology and human needs
– Helps to make the reasons behind design decisions
explicit:(eg. “Difficult to find a time to meet” “Interface
should highlight overlapping free periods of time”)
• Four kinds of scenarios:
Use Cases Concrete Scenarios Conceptual Scenarios User Stories
The design process of interactive systems
 The design process of interactive systems

Abstract away Add in design Choose, formalize

differences and constraints, and integrate
irrelevancies generate options concrete scenarios
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

“I wish I could “user will be able “user will be able

do x…” to do x…” to do x using Actor a
component y…” Task x
Actor c
Device y

Service z

Actor b
 Abstract away
differences and
irrelevancies
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

“I’m a female atmospheric scientist, and I troll journals X, Y and Z

for atmospheric data from the Amazon rainforest. I then type in the
data, and place colored pins into a map of the rainforest on my wall. The
color of the pin indicates when the data was collected, and what data it
represents (humidity, temperature, etc.). I’m frustrated by the lack of
real-time data.”

“I’m a male high school teacher, and I try to impress upon my students
the effects of deforestation. I tell them the statistics about how much
rainforest is disappearing per day, and what effect that’s having on the
region, and the world. The students don’t seem to respond much to
numbers and words, but they do to images and video.”

Q: What differences and irrelevancies exist? (Abstract them away)

Q: What commonalities exist? (Abstract into a conceptual scenario)
 Add in design constraints,
generate options
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

“Users will be able to log into a website that provides distributed,

real-time data from the Amazon rainforest. The data will be collected
automatically from different sources, and integrated into a common
format. The data will then be presented in a variety of ways. Several
of the visualizations will include animations, as well as photographs of
situations “on the ground”.

Conceptual scenarios clarify the requirements of the system:

what must the interactive system allow users to do?

Conceptual scenarios point the way toward multiple design possibilities:

what are the different ways the requirements could be instantiated?

Q: Enumerate some concrete scenarios for this example:

What subtasks are done by technology? Which by people?
 Choose, formalize and integrate
concrete scenarios
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

Data collected automatically

“A user logs into the rainforest website, and calls up a map of an area of
interest. Data requests are sent to wireless sensor networks that are
embedded within that area, and data is sent back. The data is integrated, and is
displayed on the map.”
Data collected manually
“A user logs into the rainforest website, and is presented with an overview map
of the Amazon rainforest. The image is animated: each frame corresponds to a
single month. Each frame presents data collected by government officials in
small towns who manually key in weather data from the region.”

Q: Assume we go with option 2.

Who are the actors (who interacts with the system)?
What tasks, services and devices are there?
 Choose, formalize and integrate
concrete scenarios
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

Can move backward and forward Researcher

along scenario continuum: Export data
to Matlab
Q: What might warrant a move backward Government
to collect more user stories? Visualize official
data

Collect
data

Q: What might warrant a move forward Educator Data

toward use cases?
 Choose, formalize and integrate
concrete scenarios
User Stories Conceptual Scenarios Concrete Scenarios Use Cases

Can move backward and forward Researcher

along scenario continuum: Export data
to Matlab
Q: What might warrant a move backward Government
to collect more user stories? Visualize official
data
Is a perceived difference(i.e.
research/education), an important detail Collect
or an irrelevancy data

Q: What might warrant a move forward Educator Data

toward use cases?

A decision is made regarding design

possibilities
User Focus
 User focus
• know your user
• persona
• cultural probes
User Focus: Know Your User

• who are they?

• probably not like you!
• talk to them
• watch them
• use your imagination
 Design for a Single User
• If you try to please everyone, you will please
no one
• If you try to build a car that satisfy the
following three sets of people
– Mothers with young children
– Carpenters
– Young executives
 Design for a Single User
• Then you will get something like this!!!!
 Design for a Single User
• What is the solution?
You need different cars for the three different sets of
people described in the previous slide
 Design for a Single User
• Unlike cars, in terms of software the same
product can behave as three different ones
– But in that case you have to ensure it doesn’t over
complicate things
 Design for a Single User
• Robert Lutz, the chairman of Chrysler, says
that 80% of people in focus groups hated the
new Dodge Ram pickup.
• He went ahead with production and made it
into a best-seller because the other 20% loved
it. Having people love your product, even if it
is only a minority, is how you succeed.
 Design for a Single User
• The broader a target you aim for, the more
certainty you have of missing the bull's-eye.
• If you want to achieve a product-satisfaction
level of 50%, you cannot do it by making a
large population 50% happy with your product
• You can only accomplish it by singling out 50%
of the people and striving to make them 100%
happy
 The Elastic User
• our goal is to design software that will bend and
stretch and adapt to the user's needs not the
other way around
• Designing for the elastic user gives the developer
license to code as he pleases while paying lip
service to "the user." Real users are not elastic.
• Elastic user is some one whose needs change
• To understand users use personas
 User focus: Persona
• Personas are fictional characters, designers
use to reflect user types, pinpointing who they
are and what they do with products in
relevant contexts.
• Designers create personas from user data,
to understand user characteristics, needs,
goals, etc. and gain valuable insights into user
journeys, and later, test prototypes.
 User focus: Persona
• description of an ‘example’ user
– not necessarily a real person
• use as surrogate user
– what would Betty think
• details matter
– makes her ‘real’
 Example Persona
Betty is 37 years old, She has been Warehouse Manager for five years and
worked for Simpkins Brothers Engineering for twelve years. She didn’t go to
university, but has studied in her evenings for a business diploma. She has
two children aged 15 and 7 and does not like to work late. She did part of an
introductory in-house computer course some years ago, but it was
interrupted when she was promoted and could no longer afford to take the
time. Her vision is perfect, but her right-hand movement is slightly restricted
following an industrial accident 3 years ago. She is enthusiastic about her
work and is happy to delegate responsibility and take suggestions from her
staff. However, she does feel threatened by the introduction of yet another
new computer system (the third in her time at SBE).
 Main Points about Personas
• Personas are ‘fictional’ characters. Even so, they are created
based on real data and research around a problem domain,
or a focus target.
• A product should have the minimum number of personas,
so we focus design and this may guarantee better success.
• Personas must answers three basic questions: 
– what are the user needs,
– wants
– limitations.
• In User Personas, it is more important to be precise than
accurate.
 User Focus: Persona
• Personas Are More Than “People”
• Personas are distilled essences of real users.
– With personas, we build
– empathy with target users
– focus on their world
– share insights/knowledge with other stakeholders to
gain consensuses
– make defensible decisions reflecting the persona’s/user
group’s exact needs
– gauge our designs’ effectiveness through their eyes.
 Steps for Creating Effective Personas
• The basic steps for designing personas are:
1. Find the users
– Collect extensive data on target users.
– Study lots of users to start getting a sense of who they are
2. Develop a hypothesis
– What is the context that matters?
– from the research, determining the qualities of and
differences between users.
3. Verification
– Ensure stakeholders agree on the hypothesis about the
users.
– Find data to support the initial patterns you identified
 Steps for Creating Effective Personas
• The basic steps for designing personas are:
4. Finding Patterns
– List the patterns/categories you found
– Determine a number of personas – more than one per project,
but focus especially on one.
5. Construct Personas
– Name and describe each persona in 1-2 pages, including:
• A picture.
• User’s values, interests, education, lifestyle, needs, attitudes, desires,
limitations, goals and behavior patterns.
• Extra details about the persona (e.g., interests) – anything to make
him/her more real and relevant and help build empathy. A written story
is better than bullet points.
– Avoid stereotypes
 Steps for Creating Effective Personas
• The basic steps to use personas
6. Define Situations
– Describe several situations/scenarios prompting the persona to use your product –
put him/her in contexts with problems to overcome.
7. Validate and Buy In
– Include everyone involved in the project so they’ll accept the persona (or advise
revisions).
– Make sure the team agrees
8. Dissemination of Knowledge
– Send and Share the persona with new team members / participants to use in their
work.
9. Creating Scenarios
– Ensure everyone develops scenarios – exposing the persona optimally to potential
use cases.
– Create real-world scenarios where the personas will use the technology
10.Ongoing Development
– Make continuous adjustments – revisit the persona, adding new features; add
required new personas; discard outdated personas.
 What does Personas Include?
• A real name
• Age
• A photo
• Demographics
• Personal info, including family and home life
• Work environment (not a job description!)
• Computer proficiency and comfort with the Web
• Info-seeking habits
• Behaviors & Tasks
• Attitudes, including pet peeves
• Personal and professional goals
• Motivation: why would this person use your high-tech product?
 Types of Persona
• Primary persona (The one person we are designing for )
– A persona whose needs must be satisfied
– Multiple primary personas require separate interfaces
• Secondary, tertiary, etc. personas
– Personas whose needs should be considered after
those of the primary persona(s)
– A persona is made secondary because their needs can
be mostly met if the design is focused on the primary
persona
 Quotable
• “Personas, like all powerful tools, can be
grasped in an instant but can take months or
years to master.”
– Alan Cooper, 2003,
 User Focus: Cultural Probes
• direct observation
– sometimes hard
• in the home
• psychiatric patients, …

• probe packs
– items to prompt responses
• e.g. glass to listen at wall, camera, postcard
– given to people to open in their own environment
they record what is meaningful to them

• used to …
– inform interviews, prompt ideas, enculture designers
 Navigation design
local structure – single screen the systems
global structure – whole site
info and help management messages

rt
sta

main remove add user remove user

confirm
screen user

add user
 levels
• widget choice
– menus, buttons etc.
• screen design
• application navigation design
• environment
– other apps, O/S
 The web …

• widget choice • elements and tags

– <a href=“...”>
• page design
• screen design
• site structure
• navigation design • the web, browser,
• environment external links
 Physical devices

• widget choice • controls

– buttons, knobs, dials
• physical layout
• screen design
• modes of device
• navigation design • the real world
• environment
 Four golden rules
• knowing where you are
• knowing what you can do
• knowing where you are going
– or what will happen
• knowing where you’ve been
– or what you’ve done