DESIGNING INTERACTION

Module – II
Lecture 1- 3
 Inside..
• Overview of Interaction Design Models,
• Interaction Design Process
• Discovery Framework, Collection - Observation,
Elicitation, Interpretation
• Task Analysis,
• Storyboarding,
• Use Cases,
• Primary Stakeholder Profiles,
• Project Management Document
 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
Four Basic Activities and Three Key Characteristics
Basic activities in Interaction Design:
• Identifying needs and establishing requirements
• Developing alternative designs
• Building interactive versions of the designs
• Evaluating designs
• Three Characteristics
• User Focus
• Specific Usability Criteria
• Iteration
 Issues?
•Who are the users?
•What are their ‘needs’?
•Where do alternatives come from?
•How do you choose among alternatives?
 users?
•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:
• Primary: frequent hands-on
• Secondary: occasional or via someone else;
• Tertiary: affected by its introduction, or will influence its
purchase.
Wider term: Stakeholders
 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 child’s toy requires little strength to operate, but
greater strength to change batteries
— disabilities(e.g. sight, hearing, dexterity)
 ‘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
Generating Alternate Designs
• Creativity
• Start….Anywhere!
 Choose alternate design – How?
• Designs are external or internal
• External design
• Two ways to choose alternate design
– Test the prototype, let the users choose
– Choose what has the best “Quality”

• Technical feasibility: some not possible

• Quality thresholds: Usability goals lead to usability criteria (set early and
checked regularly)
—safety: how safe?
—utility: which functions are superfluous?
—effectiveness: appropriate support? task coverage, information available
—efficiency: performance measurements
 Interaction Design Process
• Iterative Design
• User-Centered Design
• Interaction Design Models
• Overview of Interaction Design Models
 Iterative Design
• Interaction design is an iterative process
– One step forward, two steps back
• The knowledge path is constantly moving
forward
 User-Centered Design (UCD)
• The objective of UCD is to develop a design framework that
enables interaction designers to build more usable systems.
• Design should emerge from the user’s
– Tasks ; - Goals ;- Environment
• Focuses on human-centric issues
– cognition
– perception
– physical attributes and conditions
• user
• environment
 Life Cycle Models
• Show how the activities are related
• Lifecycle models are:
– Management tools
– Simplified version of reality
• Many lifecycle models exist, for example:
– From software engineering: waterfall, spiral,
JAD/RAD, Microsoft
– From HCI: Star, usability engineering
A simple interaction design model

Identify needs/
establish
requirements

(Re)Design
Evaluate

Build an
interactive
version

Final product
The waterfall lifecycle model
Requirements
analysis

Design

Code

Test

Maintenance
 The spiral lifecycle model
• Important features:
– Risk analysis
– Prototyping
– Iterative framework allows ideas to be checked
and evaluated
– Explicitly encourages alternatives to be considered
The Spiral Lifecycle Model
(Rapid Applications Development)
Project set-up

JAD workshops

Iterative design
and build

Engineer and
test final prototype

Implementation
review
 The Star Lifecycle Model
• Important features:
– Derived from some empirical work of interface
designers
– No particular ordering of activities
– Evaluation is central to this model
 The Star Model

task/functional
Implementation
analysis

Requirements
Prototyping Evaluation specification

Conceptual/
formal design
 The Usability Engineering
Lifecycle Model
• Important features:
– Holistic view of usability engineering
– Provides links to software engineering approaches,
e.g.OOSE
– Three essential tasks: requirements analysis,
design/testing/development, and installation
– Stages of identifying requirements, designing, evaluating,
building prototypes
– Uses a style guide to capture a set of usability goals
– Can be scaled down for small projects
 Other Process Models
• The Unified Process
– A widely-adopted process model in industry
– Originally developed by Rational (now part of IBM)
– More complicated model

• Many light-weight or Agile Process Models

– Best known example: Extreme Programming
 Agile Process Models
• Many developers and organization feel existing process
models have been too “heavy weight”
– Too many rules and documents. Inflexible. Not fun.

• XP and many other agile methods try to be alternatives

• XP says it’s: “a deliberate and disciplined approach to
software development.” (So it is a process model.)
– Claims to be good for risky projects with dynamic requirements,
and when continuous customer involvement is crucial (and possible)
– Emphasizes
• Team development: pair-programming
• Write tests before code (unit testing)
 Agile Methodologies

• XP • FDD
• Scrum • Agile RUP
• DSDM • Open Source
• Crystal Family • Agile Modeling
• ASD • Pragmatic Programming
 Discovery Phase Framework
• Discovery  Formally identify:
– The people who are involved with the work
– The things they use to do the work
– The processes that are involved in the work
– The information required to do the work
– The constraints imposed on the work
– The inputs required by the work
– The outputs created by the work
 Discovery Phase Framework
• Interpret the information
• Creating descriptions of the people who do the
work
• Describing the different goals involved in the work
• Documenting the work step by step
• Creating different stories about how the various
aspects of the work are done
• Creating charts and diagrams of the work flow
• Tracing the different stories identified with the
various people through the charts and diagrams
 Discovery Phase Framework
• During the discovery phase find out the work that
people do
– understand what data is needed to create the design
– create the proper tools to gather and interpret that data
 Exploring the Work Domain
• Design projects are diverse
– Incorporating new designs into existing
workflows
– Improving designs already in place
– Designing innovative devices
• Work domains are diverse
– Tracking inventory
– Order Processing
– Banking
– Websites
 Exploring the Work Domain
• Identify all stakeholders
– The people that are involved either directly or
indirectly in the work flow
• The people who do the work
• The people who manage the people who do the work
• The people who are affected by the output of the work
• The people who will benefit in some way from the work
• Primary—The person who uses the design directly
• Secondary—The person who either supplies input or receives
output from the design
• Facilitator—The person who maintains or develops the design
• Indirect -- The person who is affected by the use of the design but has no
contact with it
 Exploring the Work Domain
• Understand the competition
– Learn from other design solutions
– Assess both the positive and negative aspects
– Respect copyrighted material and intellectual
property
 Organizing the Discovery Process

• Data collection and data interpretation must be

viewed as an integrated whole
• The 5W+H heuristic can provide focus for
data collection activities
– What/How—What activities are involved and how
are they accomplished?
– Where/When—We need to understand the impact
of physical location on the work flow.
– Who/Why
 Organizing the Discovery Process
• Filters
– Physical—describe the physical aspects of the activity.
• Where is it done?
• What objects are involved?
– Cultural— look at the activity in terms of the
relationships among the people involved.
• Are some people in a position to orchestrate and evaluate the
performance of other people?
– Functional— look at these activities in terms of what
actually happens.
• Do some people create things?
• Do other people document procedures and communications?
 Organizing the Discovery Process
• Informational—look at these activities in
terms of the information that is involved.
– What information is necessary to perform a task?
– How does the information flow from one person to
another?
– How is the information generated?
– How is the information consumed?
 Organizing the Discovery Process
• Discovery Process Organization
– What/How
1. Functional
2. Physical
3. Informational
– Where/When
1. Physical
2. Functional
– Who/Why
1. Cultural
2. Functional
3. Informational

• The data collected must be organized and transformed into information

• The tools we will explore include the following:

– Task analysis
– Storyboarding
– Use cases
– Primary stakeholder profiles
Collection - Methods of Collection
• Methods of Collection
– Observation: Valuable information can be obtained
by watching people perform their activities in the
context of the work environment.
– Observations can be made directly during the work
day or indirectly using video and auditory
recordings.
– Elicitation: Elicitation methods also involve direct
and indirect methods of investigation, such as
interviews, focus groups, and questionnaires.
Collection - Methods of Collection
 Observation
• Direct
– Ethnographic methods : going to the work site and observing the
people and the infrastructure that supports the work flow
– Concerns about Ethnographic Observations
• Presence will affect the people you observe (positive and negative)
• Presence can become annoying
• Indirect
– Indirect methods of observation by setting up recording devices in the
work place (may require a significant degree of transparency)

• Distributed Cognition
– The tendency to off-load cognitive tasks to objects in the environment
or to distribute them among team members or co-workers
 Elicitation
• Direct (Face to Face Communication)
– Interviews
– Focus groups
• Physical aspects
• Cultural aspects
• Neutral linguistic approach
• Individual communication styles
• Tangents
• Indirect
– Corporate documentation
– Logs and notes
– Questionnaires
 Elicitation – Direct - Interviews

• Interviews
– On-site interviews: may help people remember aspects of the
job
– Away from job site interviews: not interrupted by normal
work related events
– Open-ended questions: can be used to explore issues and elicit rich
information about complex topics
– Closed-ended questions: can generally be answered with a polar yes/no
response or a simple description.
– Unstructured Interviews: Early in the design process interviews
are generally loosely structured.
– Structured Interviews: As the design process proceeds, interviews
can become more structured and focused on specific details and areas
of the design.
 Collection - Elicitation
Direct – Focus Groups
• Focus Groups
– Require a moderator/facilitator to keep discussion on track
– Maintain spontaneity
– Have clearly defined outcomes
– Provide participants with a context for the project

• The advantages of focus groups:

– They are relatively inexpensive and easy to set up.
– They can be used early in the design process to help to identify and prioritize features.
– They help you to gain insight into people’s attitudes and motivations.

• The disadvantages of focus groups:

– They only represent the views of one particular group.

– They are not statistically significant.

– They do not provide information about usability.

 Collection - Elicitation – Indirect
• Corporate Documentation—Information can be
collected indirectly through corporate documents
that reference policies and procedures.
• Logs and Notes—Indirect methods can also
include user participation;
– Ask people to keep a log of specific activities
– Collect the notes people make to remind them of
procedures and policies
• sticky notes tacked onto a computer
• reminders stuck on a corkboard
 Collection - Elicitation
Indirect - Questionnaires
• Questionnaires are familiar
• Questionnaires can contain open and closed questions
• Questionnaires can include the following:
– Mutually exclusive choices (radio buttons)
– Non–mutually exclusive choices (checkboxes)
– Ranges (overlapping, open-ended)
– Scales (Likert scales, Semantic differential scales)
– Short-answer fill-ins
– Comments
 Collection - Elicitation
Indirect - Questionnaires

• The following are guidelines for defining scales:

– Identify the scale and the significance of the units

– Use the most intuitive order

– You can use positive or negative scales or a combination of the two

– Use odd numbers when you want to allow neutral responses.

– Use even numbers when you want to force a choice of positive or negative.

– Provide a not applicable (NA) response when appropriate.

– Do not use too many degrees within the scale; seven is considered a general

limit.
Advantage and Disadvantage of Questionnaire
• Advantages of questionnaires • Disadvantages of questionnaires
– No face-to-face contact – Vague questions will return
and can be
administered remotely. ambiguous responses that will
– used to supply
information for primary serve no useful purpose or the
stakeholder profiles. design.
– used to ascertain whether
proposed solutions will – People do not like to fill out long
meet with acceptance as
well as to elicit new ideas. questionnaires.
– used to double-check
the feedback obtained – Closed-ended questions can
from one-on-one restrict responses.
interviews.
– can reach a large – Open-ended questions can be hard
audience with relatively
little expense to quantify.
 Guidelines for Questionnaires
• Be consistent.

• Phrase instructions clearly.

• Speak the user’s language.

• Avoid jargon or technical terms.

• Order the questions beginning with the easy or less controversial ones.

• Use logical grouping.

• Avoid compound questions.

• Use appropriate form elements, for example, radio buttons, checkboxes, and so on.

• Use an appropriate scales for questions with discrete responses.

• Avoid overlapping ranges.

• Include a “None of the above” when appropriate.

• Be sensitive to the balance of positive and negative questions

 Interpretation

• Task Analysis
– A way of documenting how people perform
tasks
– It includes all aspects of the work flow
– It is used to explore the requirements of the
proposed system and structure the results of the
data collection phase
• Storyboarding
• Use Cases
• Primary Stakeholder Profiles
 Task Analysis
• Task decomposition
– A linear description of a process that captures the
elements involved as well as the prevailing
environmental factors.
• Hierarchical task analysis (HTA)
– HTA provides a top-down, structured approach to
documenting processes.
 Task Analysis Vs
• Engineering requirements analysis defines
performance required of hardware.
• Programming specs define performance of
software.
• Task analysis defines performance of humans
with respect to the system.
 Task Decomposition
• Identify the process
• Describe the steps
– Include the following:
• The reasons for the actions
• The people who perform the actions
• The objects or information required to complete the actions
• Task decompositions captures the following:
• The flow of information
• Use of artifacts
• Sequence of actions and dependences
• Environmental conditions
• Cultural constraints
 Task Decomposition
• Goal: This defines the top-level goal for the analysis
• Information: This includes all of the information you need to
perform the task
• Objects: These include all of the physical objects you will use to
find the information
• Methods: These are the various ways you can proceed.
• Objectives: These are the subgoals
• Procedures: These are the triggers that may initiate contingency
activities
• Contingencies: These will describe what you need to do if one
of your methods does not work
 Task Analysis - HTA
• Hierarchical task analysis (HTA)
– Start with a specific goal and then add the tasks or
subgoals required to achieve that goal.
• An HTA is read as follows:
– A box on top of another box describes what we want
to do (subgoal).
– The box below another box describes how it is done.
– Plans control the flow between subgoals.
 Textual HTA description

• Hierarchy description ...

0. in order to clean the house
1. get the vacuum cleaner out
2. fix the appropriate attachment
3. clean the rooms
3.1. clean the hall
3.2. clean the living rooms
3.3. clean the bedrooms
4. empty the dust bag
5. put vacuum cleaner and attachments away
 Plans

• ... and plans

– Plan 0: do 1 - 2 - 3 - 5 in that order. when the dust bag gets full do 4.
– Plan 3: do any of 3.1, 3.2 or 3.3 in any order depending on which rooms
need cleaning

• Note: only the plans denote order

 Generating the hierarchy
– get flat list of tasks
– group tasks into higher level tasks
– decompose lowest level tasks further

Stopping rules How do we know when to stop?

Is “empty the dust bag" simple enough?
Purpose: expand only relevant tasks.
Error cost: stop when P x C is small
– Probability of making an error X cost of the error
Motor actions: lowest sensible level
 Diagrammatic HT A

• Line under box means no 0.

further expansion. make a

cup of tea

• Plans shown on diagram or plan 0.

do 1
written elsewhere. at the same time, if the pot is full 2
then 3 - 4
after four or five minutes do 5

1. 2. 3. 4. 5. 6.
put tea leaves pour in wait 4 or 5
boil water empty pot pour tea
in pot boiling water minutes

plan 1.
1.1 - 1.2 - 1.3
when kettle boils 1.4

1.1. 1.2. 1.3. 1.4.

put kettle wait for kettle
fill kettle turn off gas
on stove to boil
 Refining the description
• Given initial HTA (textual or diagram)
How to check/improve it?
• Some heuristics:
– paired actions
e.g., where is `turn on gas'
– restructure
e.g., generate task `make pot'
– balance
e.g., is `pour tea' simpler than making pot?
– generalize
e.g., make one cup or two ... or more
 Redefined HTA For Making Tea
0.
make cups
of tea

plan 0.
do 1
at the sametime, if the pot is full 2
then 3 - 4
after 4/5 minutesdo 5

1. 2. 3. 4. 5.
wait 4 or 5
boil water empty pot makepot pour tea
minutes

plan 5.
empty NO for each
5.1 5.2 cups ? guest 5.3
YES

plan 1.
1.1 - 1.2 - 1.3 - 1.4
when kettle boils 1.5 5.1. 5.2. 5.3.
put milk fill cup do sugar
in cup with tea

plan 3. plan 5.3.

3.1 - 3.2 - 3.3 5.3.1 - if wanted 5.3.2

5.3.1. 5.3.2.
3.1. 3.2. 3.3. ask guest add sugar
put tea leaves pour in about sugar to taste
warm pot
in pot boiling water

1.1. 1.2. 1.3. 1.4. 1.5.

fill kettle put kettle turn on and wait for kettle turn off gas
on stove light gas to boil
HTA Structure Chart Notation
HTA Structure Chart Notation
 Stages of a HTA
• Starting the analysis
– Specify the main task.
– Break down main task into 4-8 subtask, and
specify in terms of objectives. Cover the whole
area of interest.
– Draw out as layered plans, logically &
technically correct. None should be missing.

66
• Progressing the analysis
– Decide on level of detail and stop
decomposition. Should be consistent between
tasks. Can range from detailed to high level
description.
– Decide if a depth first or breadth first
decomposition should be done. Can alternate
between the two.
– Label and number the HTA.
• Finalizing the analysis.
– Check that decomposition and numbering is
consistent. May produce a written account of
the processes.

– Have a second person look it over. They should

know the tasks but not be involved in the
analysis.
 Storyboarding

• Storyboarding involves using a series of pictures

that describes a particular process or work flow
– Can be used to study existing work flows or generate
requirements.
– Can facilitate the process of task decomposition
– Used to brainstorm alternative ways of completing tasks.
 Storyboard of A Computer Telephone

Computer Telephone Help Screen Computer Telephone

You can enter either the
Last Name: person's name or their Call by Last Name: Greenberg Establishing
Help-> name->
First Name: number. Then hit the First Name: connection->
Phone: place button to call them Phone:

Place Call Help Return Place Call Help

Computer Telephone Computer Telephone

Call Call
Dialling....
Last Name: Greenberg connected... Connected
Last Name: Greenberg completed...
First Name: First Name:
Phone:Cancel Phone:Hang up

Place Call Help Place Call Help

 Computer Telephone
Computer Telephone Computer Telephone
Last Name: Connected
Last Name: Greenberg Last Name:
First Name:
First Name: First Name:
Phone: Hang up
Phone: Phone:
Place Call Help
Place Call Help Place Call Help

Computer Telephone
Computer Telephone
Computer Telephone Last Name:
First Name:
Last Name: Greenberg
Dialling....
Last Name: Greenberg Phone:
First Name:
First Name: Phone:
Phone:Cancel Place Call Help
Place Call Help
Place Call Help

Help Screen
You can enter either the
person's name or their
number. Then hit the
place button to call them

Return
Help-

Type name and place call

 Use cases
• The two main components of use cases are the actors and the
use cases that represent their goals and tasks.
– Actors: similar to stakeholders, but can also include other

systems, networks, or software that interacts with the

proposed system.
– Use Cases: Each actor has a unique use case, which

involves a task or goal the actor is engaged in.

• Describe discrete goals that are accomplished in a short time period
• Describe the various ways the system will be used and cover all of the potential
functionality being built into the design
Use case diagram of “schedule a meeting” process.

• Scenarios: Each unique path through the use case is called a

scenario.
• Scenarios represent discrete instances that combine to create
the complete use case.
• They are the lowest level of the use case and should cover all
conceivable paths and alternatives.
 Primary Stakeholder Profiles
• Primary Stakeholder Profiles are used to
define the target user
• The constructs covered include:
– Context of use
– Cognitive ability
– Physical ability
– Individual profile
 Documentation
• Mission Statement
– Project goals:

• What is the value proposition?

• What needs will the new system address?

• How will it address these needs?

– Project scope

• What does the proposed design include or exclude?

• What are the external constraints such as time and finances?

• How will you decide when it satisfies the design proposal?

• Requirements Document

– Requirements : Functional / Information / Physical

– Inputs/outputs

– Constraints
 Project Management Document
• Definition of the tasks involved in the project
• Risk
• Evaluation criteria and methods
• Implementation
• Training
• Maintenance
• Future needs