Chapter 5

Interaction Design
and
HCI in the Software Process
1
 Interaction Design Basic
 Interaction design is creating intermediation
using technology including software, web and
physical devices
 we are not thinking about the design of
interactive systems, but about the interaction
itself.
 Interaction starts to know users and their
background: finding out who they are and what
they are like.

2
 Cont’d...
Design involves:-
Achieving goals within constraints and trade-off
 Accepting limitations of humans and of design
Understanding the raw materials
Design process has several stages and its
iterative and never complete.
Goals:-Purpose of design that proposed to be
produced
Constraints:- materials, some standards, cost/
time limitations
Trade-off:- Choosing which goals/ constraints
can be comfortable or more importance
3
 Golden Rule of Design
 Understand your materials (for HCI)
Understand computers
limitations, capacities, tools, platforms
Understand people
 Interaction starts with getting to know the
users and their context: finding out who they
are and what they are like

4
 The process of design
Four main phases plus an iteration loop, absorbed
on the design of interaction
scenarios
what is
task analysis guidelines
wanted
Analysis principles precise
interviews
ethnography specification
Design
what is there dialogue Implement
vs. notations and Deploy
what is wanted prototype
architectures
evaluation documentation
heuristics help
5
 Steps …
Requirements:- what is there and what is
wanted(interviewing people… )
Analysis:-ordering and understanding
Design:-there is a central stage when you move
from what you want, to how to do it.
Iteration and Prototyping:-we cannot expect to
get designs right first time. need to evaluate
design to see how it is working and there can be
improvements.
Implementation and Deployment:-Finally, when
we are happy with our design, we need to create
it and deploy it. 6
 Few Types of Interaction Designs

1. User- centered design

2. Screen Design and Layout
3. Iteration and Prototyping
4. Navigation Design
5. Scenario Based design

7
 1. User Centered Design
Know your users.
So, how do you get to know your users?
Who are they?
Talk to them
Watch them
Use your imagination
Developers working with target users
Think of the world in users’ terms
Identify usability and user experience goals
 Understanding work process
8
 2. Screen Design and Layout
The way we have to follow to design Screen and
layout:
Tools for layout
Number of visual tools to submit the user to read
and interact with a screen or device.
 grouping of items
 order of items
 decoration - fonts, boxes etc.
 alignment of items
 white space between items x

9
 Grouping and structure
Things logically belong together, then we should
physically group them together.

logically together  physically together

Billing details: Delivery details:
Name Name
Address: … Address: …
Credit card no Delivery time

Order details:
item quantity cost/item cost
Book 7 3.71 25.9
Pen 12 2 24
Figure Grouping related items in an order screen
 Order of groups and items
 In general natural order should match screen
order!
 use task analysis groupings
 top-bottom, left-right (depending on values)
 set tab order for keyboard entry
Decoration
uses boxes and a separating line to make the
grouping clear.
 Other decorative features like font style, and
text or background colors can be used to
highlight groupings.
Don’t use bad color 11
 Alignment
 Text items normally be aligned to the left.
 Numbers, normally aligned to the right (for
integers) or at the decimal point

12
 User action and control
Entering information
 places for the user to enter
Name: Alan Dix
information or select options. Address: Lancaster
 Alignment is important. It is
especially common to see the Name: Alan Dix
text entry boxes aligned in a 
Address: Lancaster

pointed fashion because the

field names are of different ?
Name: Alan Dix
Address: Lancaster

lengths. N.B. see extra slides for widget choice

 For both presenting and

entering information a clear
logical layout is important. 13
 Appropriate Appearance
Presenting information
 The way of presenting information on screen
depends on the kind of information.
 An interactive system is easy to the user to choose
among several representations, this makes easy to
achieve goals. name size
purpose matters chap10 12
 sort order (which column, chap5 16
chap1 17
numeric alphabetic) chap14 22
 text vs. diagram chap20 27
chap8 32
 scatter graph vs. histogram … …
 relaxes design choices
e.g. re-ordering columns 14
 visibility and Utility
 visually pleasing designs
 increase user satisfaction and productivity
 beauty and utility may conflict
 mixed up visual styles
 easy to distinguish

15
 Color and 3D
Color:-worst features in many interfaces use of
color.
 color blind, mean that text are literally invisible
to some users.
 color should be used carefully
 older monitors limited color
3D effects
 problems for text and numerical information.
 good for physical information and some graphs
 but if over used …
e.g. text in perspective!! 3D pie charts
16
 bad use of color
• over use - without very good reason (e.g. kids’ site)
• colour blindness
• poor use of contrast
• do adjust your set!
– adjust your monitor to greys only
– can you still read your screen?

17
 Localization / Internationalization
 If you are working in a different country, you
might see a document being word processed
where the text of the document and the file
names are in the local language, but all the
menus and instructions are still in English.
 The process of making software suitable for
different languages and cultures is called
localization or internationalization
 meanings of symbols
e.g tick and cross … +ve and -ve in some
cultures but … mean the same thing (mark this)
in others
  18
 3. Interaction and Prototyping
 In simple Prototype is figure of the system.
 Its very simple version of actual system,
showing limited functional, low reliability, and
inefficient performance as compared to the
actual software
 limited representation of design that allows users
to interact with it and to explore its suitability
 client has general view of what is to be expected
from the software product.
 Aim is to save time and money

19
 Steps of Prototyping Model
i. Requirements and gathering analysis:
 User is interviewed to gather information
about requirement of the software.
ii. Quick Design:
 Initial design or quick design involving only the
important aspects is created.
iii. Build Prototype:
 Information from the quick design is modified
to form a prototype.

20
 iv. Assessment:
 Proposed system is now presented to the user
for evaluation.
v. Prototype Refinement:
 After user evaluates prototype the required
changes are made and final prototype designed.
vi. Engineer Product:
 The final carefully tested and undergoes routine
maintenance in order to avoid any future system
failures.

21
 Interaction and Prototyping
you never get it right first time
if at first you don’t succeed …
need a good start point
need to understand what is wrong
OK?
design prototype evaluate done!

re-design

22
 Iterative design and prototyping…
 The design can be modified to correct any false
assumptions that were naked in the testing
 This is the spirit of iterative design, which tries to
overcome the inherent problems
 On technical side, iterative design is described by
the use of prototypes
 Prototypes is simulate or animate some features of
intended system
Different types of prototypes
throw-away
incremental
evolutionary
23
23
 Throw-away prototype
 Used at early in requirements gathering
 Are built, tested and thrown away (useful in
early stages)
 Knowledge gained contributes to final system /
next prototype
 Does not form part of the final solution

24
24
 Incremental Prototypes
 final product is built as separate prototypes
 At the end the separate prototypes are merged in
an overall design.
 prototype is designed, implemented and tested
incrementally until the product is finished.

25
 Evolutionary Prototypes
 This prototype is presented to the user.
 They provide feedback and suggestions for
improvements.
 So at each stage the prototype 'evolves' towards
the final system

26
26
 Advantages of prototype model:
 The resulting system is easier to use
 User needs are better accommodated
 Problems are detected earlier
 The design is of higher quality
 The resulting system is easier to maintain
 The development experiences less effort
 Provides better communication
between the user and the engineer .

27
 Techniques for prototyping
Storyboards
 Graphical representation of the
appearance of the future system,
without system functionality. .
 snapshots of interface at particular
points in the interaction.
Limited functionality simulations
 More functionality must be built into prototype to
demonstrate work that application will accomplish.
 functionality must be simulated by the design team.

28
28
 4. Navigation based design
You need to be able to understand what will happen
when a button is pressed on web page, screen or a
device.
Structures:-
Local Structure
– looking from one screen or page out
Global Structure
– structure of site, movement between screens

29
 Local structure
Much of interaction involves goal-seeking. To do
this, each screen is displayed on single page.
 Four things to look for when looking at a single web
page, screen or state of a device.
 knowing Where you are (should make clear where you
are, i.e. bread crumbs in terms of website.)
 knowing What you can do now:-what can be pressed or
clicked to go somewhere or do something.
 knowing Where you’re going (you click a button then
what will happen. Back or confirmation message is
needed )
 knowing Where you’ve been (or what has been done)
30
 Example shows path through web site hierarchy

top level category sub-category

web site this page

live links
to higher
levels

31
Global structure – hierarchical organization
This is the way the various screens, pages or
device states link to one another
Different levels of structure, according to domain:
 App: widgets; screens; application; environment
 Web: HTML; page layout; site; browser+www
 Device: controls; physical layout; modes; real
world Fig:- messaging system
The system

Info and help Management Messages

add user remove user 32

 5. Scenario Based Design
Scenario is stories for design interaction. one
linear path through system
what will users want to do? step-by-step
walkthrough
what can they see (sketches, screen shots)
what do they do (keyboard, mouse etc.)
Stories for design
 communicate with others(designers, clients,
users )
 validate other models(compare it against
other models)
 understand dynamics(screenshots) 33
 HCI in the software lifecycle
 HCI is used in software process to interact
product with user and give simple and easy
interface.
 Software developers check environment that is
simple and interactive for users
 Software engineering is discipline for accepting
software design process, or life cycle .
 Software life cycle is the activities that occur in
software development
 Activities be ordered in time in project and
proper techniques is accepted to carryout.
34
 HCI in the software lifecycle…
 Studying or designing HCI is that user interface
technology changes rapidly.
 there are two main parties the customer who
use the product and designer who provide
product.
 Customer and the designer are groups of people
and some people can be both customer and
designer.
 HCI in the software lifecycle…
Designing for usability occurs at all stages of the
life cycle, not as a single isolated activity
Requirements
specification
Defining the
requirements
Detailed
design

Development and
Waterfall model unit testing

Integration
and testing

Operation and
maintenance
36
 Activities in the life cycle
1. Requirement specification
Designer and user (customer) try capture what
the system is expected to provide
It can be expressed in natural language
The requirements are collected using a number of
practices as given
 Studying existing system and software,
 Conducting interviews of users and developers,
 Referring to the database or
 Collecting answers from the questionnaires.

37
 2. Defining the requirements
Next step is clearly define and document the
product requirements
This is done through Software Requirement
Specification document
3. Architectural design
Design of how system will provide the services
How it satisfy both functional and non
functional requirements
SRS is the reference for product architects to
come out with the best architecture for the
product to be developed. 38
 4. Development and testing
The programming code is generated as per
design during this stage.
If the design is performed in a detailed and
organized manner, code generation can be
accomplished
5. Integration and testing
stage of SDLC is involved in integration of
software with outer world entities.
Software may need to be integrated with the
libraries, databases and other program(s).

39
 6. Operation and maintenance
This phase confirms the software operation in
terms of more efficiency and less errors.
users are trained or supported with the
documentation on how to operate the software
and how to keep the software operational.

40
 Verification and validation
Each step contains verification and validation
Verification:
 Correct representation of previous stage
 It should produce correct results for correct
inputs
 Designing the right product
Validation:
 Check product to ensure results are follow
requirements
 It should produce error for incorrect inputs
 Designing the product right
41
 Verification and Validation…
The formality gap:-Validation will always trust to
some extent on subjective means of proof
Management and contractual issues
Design in commercial and legal contexts

Real-world
requirements
and constraints The formality gap

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

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
lots of feedback!
43
 S/W Engineering vs HCI
S/W Engineering HCI
 Identifies issues of  Identifies issues of
meaning to system practical effectiveness
 Functionally oriented,  Usability oriented, user
data driven driven
 Design notation: to be  Design notation: to be
understood by system understood by users
analysts  Task Analysis (diagrams)
 Dataflow diagrams  Scenarios
 Entity Relationship  Screen sketch like
Diagrams Prototype
 S/W Engineering and HCI…
Both are keepers of different views .
HCI Engineering SW (keepers of
(keepers of user views) technology views)
user task analysis SW requirement analysis
usability Software design
specification Interface SW coding
interactive design Interaction SW coding
software support Application program
identification coding
usability evaluation Software verification/
validation
45
 Usability engineering
Usability is measurement of how system is ease
to do something
Easy to understand, learn and operate. E.g. user
friendly
The ultimate test of usability based on
measurement of user experience
ISO Usability Standard 9241
Adopts traditional usability categories:
Effectiveness:-achieve what you want to.
 efficiency:-achieving goals without wasting
effort and time.
 satisfaction:-enjoy the process 46
 Some Metrics From ISO 9241
Usability Effectiveness Efficiency Satisfaction
objective percentage measurement measurement
Suitability Percentage of Time to Rating for
for task goal achieved complete task satisfaction
Appropriat Number of Relative Rating for
e for power efficiency satisfaction
trained features used compared with
users with expert power features
users
Learnabilit Percentage of Time spent on Rating scale
y errors correcting for errors
corrected error handling
successfully
47
 Design Rationale
Design rationale is information that explains
why computer system includes its structural or
architectural description and its functional or
behavioral description
design rationale relates an activity of both image
and documentation that occurs throughout the
entire life cycle
Rationale has logical explanations and reasons
Discussions, debates, negotiations
Reasons for features

48
 Types of Design rationale:
Process-oriented
Issue-based Information System, or IBIS
Hierarchical structure to a design rationale
Root Issue is represents the main problem or
question that the argument is addressing.
Positions :-as solution for root issue, and
descendants in the IBIS hierarchy directly
connected to the root issue.
Arguments, which modify the relationship
between issue and position.
The hierarchy grows as secondary issues are
raised which modify the root issue in some way.
49
 50
Figure:-Process-oriented diagram
 Design space analysis
QOC – hierarchical structure:
Questions (and sub-questions)
– represent major issues of a design
Options
– provide alternative solutions to the question
Criteria
– means to evaluate the options in order to make a
choice
 most favorable option must be solid line and
other in dotted line.

51
QOC – hierarchical structure

Figure:-QOC – hierarchical structure

52
 Psychological design rationale
 aims to make clear consequences of design for
users
 designers identify tasks system will support
 scenarios are suggested to test task
 users are observed on system
 psychological rights of system made obvious
 negative aspects of design can be used to
improve next iteration of design

53
 Benefits of design rationale
Communication throughout life cycle
Reuse of design knowledge across products
Enforces design discipline
Presents arguments for design trade-offs
Organizes potentially large design space
Capturing contextual information

54
The end
Question?

55