HCI in the software

process
Lifecycle models
• Show how activities are related to each other
• Lifecycle models are:
— management tools
— simplified versions of reality
• Many lifecycle models exist, for example:
— from software engineering: waterfall, spiral, JAD/RAD,
Microsoft
— from HCI: Star, usability engineering
HCI in the software
process
• Software engineering and the design process
for interactive systems

• Usability engineering

• Iterative design and prototyping

• Design rationale
the software lifecycle

• Software engineering is the discipline for

understanding the software design process, or
life cycle
• Designing for usability occurs at all stages of
the life cycle, not as a single isolated activity
1. Activities in life cycle
2. Validation and verification
3. Management and contractual issues
4. Interactive system and the software life cycle
The waterfall model
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
Activities in the life cycle
Requirements specification
designer and customer try capture what the system is
expected to provide can be expressed in natural language or
more precise languages, such as a task analysis would
provide

Architectural design
high-level description of how the system will provide the
services required factor system into major components of the
system and how they are interrelated needs to satisfy both
functional and nonfunctional requirements

Detailed design
refinement of architectural components and interrelations to
identify modules to be implemented separately the
refinement is governed by the nonfunctional requirements
 Verification and validation

Real-world
requirements
and constraints The formality gap

Verification
designing the product right
Validation
designing the right product

The formality gap

validation will always rely to some extent on subjective means
of proof
Management and contractual issues
design in commercial and legal contexts
The life cycle for interactive
systems
Requirements cannot assume a linear
specification
sequence of activities
Architectural as in the waterfall model
design

Detailed
design

Coding and
unit testing

Integration
lots of feedback! and testing

Operation and
maintenance
HCI life cycle model

• Star
• usability engineering
 The Star lifecycle
modelby Hartson and Hix
•Suggested

•Important features:
—Evaluation at the center of activities
—No particular ordering of activities.
—Development may start in any one
—Derived from empirical studies of
interface designers
Star Lifecycle “model”
Usability engineering
The ultimate test of usability based on measurement of user
experience

Usability engineering demands that specific usability measures

be made explicit as requirements

Usability specification
– usability attribute/principle
– measuring concept
– measuring method
– now level/ worst case/ planned level/ best case

Problems
– usability specification requires level of detail that may not be
– possible early in design satisfying a usability specification
– does not necessarily satisfy usability
part of a usability
specification for a VCR

Attribute: Backward recoverability

Measuring concept: Undo an erroneous programming
sequence
Measuring method: Number of explicit user actions
to undo current program
Now level: No current product allows such an undo
Worst case: As many actions as it takes to
program-in mistake
Planned level: A maximum of two explicit user actions
Best case: One explicit cancel action
ISO usability standard 9241

adopts traditional usability categories:

• effectiveness
– can you achieve what you want to?
• efficiency
– can you do it without wasting effort?
• satisfaction
– do you enjoy the process?
some metrics from ISO 9241
Usability Effectiveness Efficiency Satisfaction
objective measures measures measures

Suitability Percentage of Time to Rating scale

for the task goals achieved complete a task for satisfaction

Appropriate for Number of power Relative efficiency Rating scale for

trained users features used compared with satisfaction with

an expert user power features

Learnability Percentage of Time to learn Rating scale for

functions learned criterion ease of learning

Error tolerance Percentage of Time spent on Rating scale for

errors corrected correcting errors error handling
successfully
Iterative design and
prototyping
• Iterative design overcomes inherent problems of incomplete
requirements

• Prototypes
– simulate or animate some features of intended system
– different types of prototypes
• throw-away
• incremental
• evolutionary

• Management issues
– time
– planning
– non-functional features
– contracts
Prototyping Defined

Prototyping is the process of quickly putting together

a working model (a prototype) in order to test
various aspects of a design, illustrate ideas or
features and gather early user feedback.

IEEE defines prototyping as “ A type of

development in which emphasis is placed on
developing prototypes early in the development
process to permit early feedback and analysis in
support of the development process.”
Need for prototyping

• Enables us to explore the problem space with the

stakeholders.
• As a requirements artifact to initially envision the
system.
• As a design artifact that enables us to explore the
solution space of your system.
• A vehicle for you to communicate the possible UI
design(s) of your system.
• A potential foundation from which to continue
developing the system
 Advantages & Disadvantages
of Prototyping
Advantages Disadvantages

Users can try the system and provide Each iteration builds on the previous
constructive feedback during iteration and further refines the solution.
development This makes it difficult to reject the initial
solution as inappropriate and start over.

An operational prototype can be produced Formal end-of-phase reviews do not

in weeks occur. Thus, its is very difficult to contain
the scope of the prototype.
Users become more positive about System documentation is often absent or
implementing the system as they see a incomplete, since the primary focus is on
solution emerging that will meet their development of the prototype.
needs
Prototyping enables early detection of System backup and recovery,
errors performance, and security issues can be
overlooked.

Reference: http://facpub.stjohns.edu/~wolfem
Types of prototyping

• Throw-away Prototyping
• Evolutionary Prototyping
• Low Fidelity Prototyping
• High Fidelity Prototyping
Throw Away Prototype
• Throw Away Prototype is developed from the initial
requirements but is not used for the final project.

• Written specifications of the requirements

• Some developers believe that this type is a waste of

time because you don’t use it.

• Regardless if prototype is discarded or kept for

production, you must use a easy to use language.
Advantages &
Disadvantages
Advantages Disadvantages

Significantly reduce project The prototype actually does

risk nothing, its just
presentational.

Has a short project timeline Only for a limited purpose

Starting become a thing of

the past. Not getting used
as much now.
Evolutionary Prototype
• Evolutionary prototyping is consider the most
fundamental form of prototyping.

• Evolutionary prototyping main concept is to build a

robust prototype and constantly improve it.

• Objective to deliver a working system to the end user.

• According to Steve McConnell, "evolutionary delivery is

a lifecycle model that straddles the ground between
evolutionary prototyping and staged delivery."
Evolutionary Delivery

Rapid Development, Taming Wild Software Schedules, by Steven McConnell, Press 1996
Evolutionary Prototyping
phases
Advantages
• You are always looking for new ways to
improve the system.

• This model increases the chance of having the

client satisfied with the working system.

• The model can be used even when the

requirements are not defined.

• Quicker delivery of the system

Disadvantages
• This method can be used to avoid documenting the
requirements of the system.

• Management is required

• Long term maintenance can be expensive

• Uncertain design idea’s

• Information can be lost through so many improvement

changes
 Low-fidelity
Prototyping
 Low-fidelity prototyping is generally limited function, limited
interaction prototyping effort.

 They are constructed to depict concepts, design

alternatives and screen layouts. They are intended to
demonstrate general look and feel of the interface.

 They are created to educate , communicate and inform, but

not to train, test or serve as a basis for which to code.

 Low fidelity prototyping is used early in the design cycle to

show general conceptual approaches without much
investment in development.

Low vs. High Fidelity Prototyping Debate, Rudd J., Stern K.,Isensee S., ACM Interactions, Jan. 1996
 High-Fidelity
Prototyping
• High-fidelity prototypes represent the core functionality of the
products user interface.

• High fidelity prototypes are fully interactive systems. Users

can enter data in entry fields, respond to messages, select
icon to open windows and interact with user interface as if it
were a real system.

• They trade-off speed for accuracy.

• Building high fidelity prototypes consume resources and

have high cost.

Low vs. High Fidelity Prototyping Debate, Rudd J., Stern K.,Isensee S., ACM Interactions, Jan. 1996
 Comparison of two
prototyping efforts

Low vs. High Fidelity Prototyping Debate, Rudd J., Stern K.,Isensee S., ACM Interactions, Jan. 1996
Techniques for prototyping
Storyboards
need not be computer-based
can be animated

Limited functionality simulations

some part of system functionality provided by designers
tools like HyperCard are common for these
Wizard of Oz technique

Warning about iterative design

design inertia – early bad decisions stay bad
diagnosing real usability problems in prototypes….
…. and not just the symptoms
Design rationale

Design rationale is information that explains why

a computer system is the way it is.

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
Design rationale (cont’d)

Types of DR:
• Process-oriented
– preserves order of deliberation and decision-making
• Structure-oriented
– emphasizes post hoc structuring of considered
design alternatives

• examples:
– Issue-based information system (IBIS)
– Design space analysis
– Psychological design rationale
Issue-based information
system (IBIS)
• basis for much of design rationale research
• process-oriented
• main elements:
issues
– hierarchical structure with one ‘root’ issue
positions
– potential resolutions of an issue
arguments
– modify the relationship between positions and issues
• gIBIS is a graphical version
 structure of gIBIS
supports
Position Argument
responds to
Issue
responds to
objects to
Position Argument
specializes

Sub-issue generalizes

questions

Sub-issue

Sub-issue
Design space analysis

• structure-oriented

• QOC – hierarchical structure:

questions (and sub-questions)
– represent major issues of a design
options
– provide alternative solutions to the question
criteria
– the means to assess the options in order to make a choice

• DRL – similar to QOC with a larger language

and more formal semantics
the QOC notation

Option Criterion

Question Option Criterion

Option Criterion

… Consequent …
Question
Question
Psychological design
rationale
• to support task-artefact cycle in which user tasks are
affected by the systems they use
• aims to make explicit consequences of design for users
• Methods
• designers identify tasks system will support
• scenarios are suggested to test task
• users are observed on system
• psychological claims of system made explicit
• negative aspects of design can be used to improve next
iteration of design
Summary

The software engineering life cycle

– distinct activities and the consequences for
interactive system design
Usability engineering
– making usability measurements explicit as
requirements
Iterative design and prototyping
– limited functionality simulations and animations
Design rationale
– recording design knowledge
– process vs. structure