HCI in the software

process
ITEC101 – INTRODUCTION TO HUMAN COMPUTER INTERACTION
Second Semester, A.Y. 2022– 2023
Rachel O. Rodriguez
Overview
● Software engineering provides a means of understanding
the structure of the design process, and that process can
be assessed for its effectiveness in interactive system
design.
● Usability engineering promotes the use of explicit criteria
to judge the success of a product in terms of its usability.
● Iterative design practices work to incorporate crucial
customer feedback early in the design process to inform
critical decisions which affect usability.
● Design involves making many decisions among numerous
alternatives. Design rationale provides an explicit means
of recording those design decisions and the context in
which the decisions were made.
Introduction

● Within computer science there is already a large

subdiscipline that addresses the management and
technical issues of the development of software
systems – called software engineering.
● One of the cornerstones of software engineering is the
software life cycle, which describes the activities that
take place from the initial concept formation for a
software system up until its eventual phasing out and
replacement.
Introduction

● The important point that we would like to draw out is

that issues from HCI affecting the usability of
interactive systems are relevant within all the activities
of the software life cycle.
The software life cycle

● One of the claims for software development is that it

should be considered as an engineering discipline, in a
way similar to how electrical engineering is considered
for hardware development.
The software life cycle

● One of the claims for software development is that it

should be considered as an engineering discipline, in a
way similar to how electrical engineering is considered
for hardware development.
● The software life cycle is an attempt to identify the
activities that occur in software development.
● These activities must then be ordered in time in any development
project and appropriate techniques must be adopted to carry them
through.
The software life cycle

● In the development of a software product, we consider

two main parties: the customer who requires the use of
the product and the designer who must provide the
product.
● It is often important to distinguish between the
customer who is the client of the designing company
(customer) and the customer who is the eventual user
of the system (end-user). These two roles of customer
can be played by different people.
Activities in the life cycle

● The graphical representation is reminiscent of a

waterfall, in which each activity naturally leads into the
next. The analogy of the waterfall is not completely
faithful to the real relationship between these activities,
but it provides a good starting point for discussing the
logical flow of activity.
Activities in the life cycle

● The activities in the waterfall model of the software

life cycle
Requirements specification

● In requirements specification, the designer and

customer try to capture a description of what the
eventual system will be expected to provide.
● This is in contrast to determining how the system will
provide the expected services, which is the concern of
later activities.
● Requirements specification begins at the start of
product development.
Architectural design

● The next activities concentrate on how the system

provides the services expected from it.
● The first activity is a high-level decomposition of the
system into components that can either be brought in
from existing software products or be developed from
scratch independently.
● An architectural design performs this decomposition.
● It is not only concerned with the functional
decomposition of the system, determining which
components provide which services.
Detailed design

● The designer must provide a sufficiently detailed

description so that they may be implemented in some
programming language.
● The detailed design is a refinement of the component
description provided by the architectural design.
● The behavior implied by the higher-level description
must be preserved in the more detailed description.
Coding and unit testing

● The detailed design for a component of the system

should be in such a form that it is possible to
implement it in some executable programming
language.
● After coding, the component can be tested to verify
that it performs correctly, according to some test
criteria that were determined in earlier activities.
Integration and testing

● Once enough components have been implemented

and individually tested, they must be integrated as
described in the architectural design.
● Further testing is done to ensure correct behavior and
acceptable use of any shared resources.
● It is also possible at this time to perform some
acceptance testing with the customers to ensure that
the system meets their requirements.
● It is only after acceptance of the integrated system that
the product is finally released to the customer.
Maintenance

● After product release, all work on the system is

considered under the category of maintenance, until
such time as a new version of the product demands a
total redesign or the product is phased out entirely.
Validation and verification

● Throughout the life cycle, the design must be checked

to ensure that it both satisfies the high-level
requirements agreed with the customer and is also
complete and internally consistent.
● These checks are referred to as validation and
verification, respectively.
● Boehm provides a useful distinction between the two,
characterizing validation as designing ‘the right thing’
and verification as designing ‘the thing right’.
Validation and verification

● Feedback from maintenance activity to other design

activities
Management and contractual issues
● The life cycle described above concentrated on the
more technical features of software development.
● In a technical discussion, managerial issues of design,
such as time constraints and economic forces, are not
as important.
● In managing the development process, the temporal
relationship between the various activities is more
important, as are the intermediate deliverables which
represent the technical content, as the designer must
demonstrate to the customer that progress is being
made.
Management and contractual issues

● Another important issue from the management

perspective is as the design activity proceeds, the
customer and the designer must sign off on various
documents, indicating their satisfaction with progress to
date.
● These signed documents can carry a varying degree of
contractual obligation between customer and designer.
● A signed requirements specification indicates both that the
customer agrees to limit demands of the eventual product
to those listed in the specification and also that the
designer agrees to meet all of the requirements listed.
Management and contractual issues

● Having to fix on some requirements too early will result

either in general requirements that are very little guide
for the designer or in specific requirements that
compromise the flexibility of design without
guaranteeing any benefits.
Interactive systems and the software life cycle

● The traditional software engineering life cycles arose

out of a need in the 1960s and 1970s to provide
structure to the development of large software
systems.
● majority of large systems produced were concerned with data-
processing applications in business.
● These systems were not highly interactive; rather, they were batch-
processing systems.
Interactive systems and the software life cycle

● The traditional software engineering life cycles arose

out of a need in the 1960s and 1970s to provide
structure to the development of large software
systems.
● majority of large systems produced were concerned with data-
processing applications in business.
● These systems were not highly interactive; rather, they were batch-
processing systems.
Interactive systems and the software life cycle

● In reality, even for batch-processing systems, the

actual design process is iterative, work in one design
activity affecting work in any other activity both before
or after it in the life cycle.
Usability Engineering

● One approach to user-centered design has been the

introduction of explicit usability engineering goals
into the design process.
● The ultimate test of a product’s usability is based on
measurements of users’ experience with it.
● Therefore, since a user’s direct experience with an interactive system
is at the physical interface, focus on the actual user interface is
understandable.
Usability Engineering

● One of the important features of usability engineering

is the inclusion of a usability specification, forming part
of the requirements specification, that concentrates on
features of the user–system interaction which
contribute to the usability of the product.
Usability Engineering

● Sample usability specification for undo with a VCR

(video cassette recorder)
Usability Engineering

● The backward recoverability attribute is defined in

terms of a measuring concept, which makes the
abstract attribute more concrete by describing it in
terms of the actual product.
● The measuring method states how the attribute will
be measured, in this case by the number of explicit
user actions required to perform the undo, regardless
of where the user is in the programming sequence.
Usability Engineering

● The now level indicates the value for the

measurement with the existing system, whether it is
computer based or not.
● The worst case value is the lowest acceptable
measurement for the task, providing a clear distinction
between what will be acceptable and what will be
unacceptable in the final product.
● The planned level is the target for the design and the
best case is the level which is agreed to be the best
possible measurement given the current state of
development tools and technology.
Usability Engineering

● The problem with usability metrics is that they rely on

measurements of very specific user actions in very
specific situations.
Iterative Design and Prototyping

● A point we raised earlier is that requirements for an

interactive system cannot be completely specified
from the beginning of the life cycle. The only way to
be sure about some features of the potential design is
to build them and test them out on real users.
● Solution is an iterative design, a purposeful design
process which tries to overcome the inherent problems
of incomplete requirements specification by cycling
through several designs, incrementally improving upon
the final product with each pass
Iterative Design and Prototyping

● On the technical side, iterative design is described by

the use of prototypes, artifacts that simulate or
animate some but not all features of the intended
system.
Three main approaches to prototyping

● Throw-away The prototype is built and tested.

Three main approaches to prototyping

● Incremental The final product is built as separate

components, one at a time.
Three main approaches to prototyping

● Evolutionary Here the prototype is not discarded and

serves as the basis for the next iteration of design. In
this case, the actual system is seen as evolving from a
very limited initial version to its final release.
Prototyping Problems on the Management Side

● Time Building prototypes takes time and, if it is a

throw-away prototype, it can be seen as precious time
taken away from the real design task.
● Planning Most project managers do not have the
experience necessary for adequately planning and
costing a design process which involves prototyping.
Prototyping Problems on the Management Side

● Non-functional features Often the most important

features of a system will be non-functional ones, such as
safety and reliability, and these are precisely the kinds of
features which are sacrificed in developing a prototype.
For evaluating usability features of a prototype, response
time – yet another feature often compromised in a
prototype – could be critical to product acceptance. This
problem is similar to the technical issue of prototype
realism.
● Contracts The design process is often governed by
contractual agreements between customer and designer
which are affected by many of these managerial and
technical issues.
Techniques for Prototyping

● Storyboards
● Probably the simplest notion of a prototype is the storyboard, which is
a graphical depiction of the outward appearance of the intended
system, without any accompanying system functionality.
● Also, it is possible to provide crude but effective animation by
automated sequencing through a series of snapshots.
Techniques for Prototyping

● Limited functionality simulations

● Storyboards and animation techniques are not sufficient for this
purpose, as they cannot portray adequately the interactive aspects of
the system.
● To do this, some portion of the functionality must be simulated by the
design team.
● Programming support for simulations means a designer can rapidly
build graphical and textual interaction objects and attach some
behavior to those objects, which mimics the system’s functionality.
Design Rationale

● In designing any computer system, many decisions

are made as the product goes from a set of vague
customer requirements to a deliverable entity.
● Often it is difficult to recreate the reasons, or rationale,
behind various design decisions.
● Design rationale is the information that explains why
a computer system is the way it is, including its
structural or architectural description and its functional
or behavioral description.
Process-oriented design rationale

● Much of the work on design rationale is based on Rittel’s

issue-based information system, or IBIS, a style for
representing design and planning dialog developed in the
1970’s.
● In IBIS (pronounced ‘ibbiss’), a hierarchical structure to a
design rationale is created.
● A root issue is identified which represents the main
problem or question that the argument is addressing.
● Various positions are put forth as potential resolutions for
the root issue, and these are depicted as descendants in
the IBIS hierarchy directly connected to the root issue.
● Each position is then supported or refuted by arguments,
which modify the relationship between issue and position.
Process-oriented design rationale
Design space analysis

● MacLean and colleagues approach, embodied in the

Questions, Options and Criteria (QOC) notation, is
characterized as design space analysis
● The design space is initially structured by a set of
questions representing the major issues of the design.
● Since design space analysis is structure oriented, it is not so
important that the questions recorded are the actual questions asked
during design meetings.
Design space analysis
Psychological design rationale

● The final category of design rationale tries to make

explicit the psychological claims of usability inherent in
any interactive system in order better to suit a product
for the tasks users have.
● Psychological design rationale aims to make explicit
the consequences of a design for the user, given an
understanding of what tasks he intends to perform.
● A psychological design rationale proceeds by having
the designers of the system record what they believe
are the tasks that the system should support and then
building the system to support the tasks.