<Previous Lesson

Human Computer Interaction

Next Lesson>

Lesson#17

HCI PROCESS AND METHODOLOGIES

As the aim of this lecture is to introduce you the study of Human Computer
Interaction, so that after studying this you will be able to:

. Describe the advantages and disadvantages of different Software Development
Lifecycles

. In our last lecture we ended with the definition of design, today we will look at
different design models used for development of software and we also
consider their flaws. We start from where we left in last lecture, design.
The term design, even used in the context of designing a computer system, can have
different meanings. In a review of general design philosophy, Jones (1981) found a
number of definitions including:
‘Finding the right physical components of a physical structure.’
‘A goal-directed problem-solving activity.’
Simulating what we want to make (or do) before we make (or do) it as many
times as may be necessary to feel confident in the final result.’
‘The imaginative jump from present facts to future possibilities.’
‘A creative activity – it involves bringing into being something new and useful
that has not existed previously.’
These descriptions focus on the process of design in general. On the topic of
engineering design, Jones found this: ‘Engineering design is the use of scientific
principles, technical information and imagination in the definition of a mechanical
structure, machine or system to perform pre-specified functions with the maximum
economy and efficiency.’
Webster, on the other hand, stresses the relationship between design representation
and design process: ‘A design is an information base that describes elaborations of
representations, such as adding more information or even backtracking and exploring
alternatives’ (Webster, 1988).
Thus, ‘design’ refers to both the process of developing a product, artifact or system
and to the various representations (simulations or models) of the product that are
many produced during the design process. There are many representations, which are
more or less appropriate in different circumstances. Designers need not only to be
able to understand user’ requirements, but also to be able to represent this
understanding in different ways at different stages of the design. Selecting suitable
representations is, therefore, important for exploring, testing, recording and
communicating design ideas and decisions, both within the design team and with
users.

151
In order to develop any product, two major activities have to be undertaken: the
designer must understand the requirements of the product, and must develop the
product. Understanding requirements involves looking at similar products, discussing
the needs of the people who will use the product, and analyzing any existing systems
to discover the problems with current designs. Development may include producing a
variety of representations until a suitable artifact is produced.

17.1 Lifecycle models

Understanding what activities are involved in interaction design is the first step to
being able to do it, but it is also important to consider how the activities are related to
one another so that the full development process can be seen. The term lifecycle
model is used to represent a model that captures a set of activities and how they are
related. Sophisticated models also incorporate a description of when and how to move
from one activity to the next and a description of the deliverables for each activity.
The reason such models are popular is that they allow developers, and particularly
managers, to get an overall view of the development effort so that progress can be
tracked, deliverables specified, resources allocated, targets set, and so on.
Existing models have varying levels of sophistication and complexity. For projects
involving only a few experienced developers, a simple process would probably be
adequate. However, for larger systems involving tens or hundreds of developers with
hundreds or thousands of users, a simple process just isn’t enough to provide the
management structure and discipline necessary to engineer a usable product. So
something is needed that will provide more formality and more discipline. Note that
this does not mean that innovation is lost or that creativity is stifled. It just means that
structured process is used to provide a more stable framework for creativity.

The design of software systems

The traditional view of software engineering characterizes the development of
software as consisting of number of processes and representations that are produced in
an essentially linear fashion. This is often called waterfall model, because the output
of each process ‘tumbles down’ neatly to the next activity, as illustrated in Figure.

Requirements
analysis
Design
Code
Test
Maintenance


152
The waterfall lifecycle was the first model generally known in software engineering
and forms the basis of many lifecycle in use today. This is basically a linear model in
which each step must be completed before the next step can be started. For example,
requirements analysis has to be completed before design begin. The name given to
theses steps varies, as does the precise definition of each one, but basically, the
lifecycle starts with some requirements analysis, moves into design, then coding, then
implementation, testing, and finally maintenance.

Flaws of waterfall model

One of the main flaws with this approach is that requirements change over time, as
businesses and the environment in which they operate change rapidly. This means that
it does not make sense to freeze requirements for months, or maybe years. While
design and implementation are completed.
Some feedback to earlier stages was acknowledged as desirable and indeed practical
soon after this lifecycle became widely used as shown in figure below. But the idea of
iteration was not embedded in the waterfall’s philosophy, and review sessions among
developers are commonplace. However, the opportunity to review and evaluation with
users was not built into this model.

The spiral lifecycle model

For many years, the waterfall formed the basis of most software developments, but in
1988 Barry Boehm suggested the spiral model of software development. Two features
of the spiral model are immediately clear from figure: risk analysis and prototyping.

Requirements
analysis
Design
Code
Test
Maintenance


153
The spiral model incorporates them in an iterative framework that allows ideas and
progress to be repeatedly checked and evaluated. Each iteration around the spiral may
be based on a different lifecycle model and may have different activities.
In the spiral’s case, it was not the need for user involvement that insured the
introduction of iteration but the need to identify and control risks. In Boehm’s
approach, development plans and specifications that are focused on the risks involved
in developing the system drive development rather than the intended functionality, as
was the case with the waterfall. Unlike the waterfall, the spiral explicitly encourages
alternatives to be considered, and steps in which problems or potential problems are
encountered to be re-addressed.
The spiral idea has been used by others for interactive devices. A more recent version
of the spiral, called the Win Win spiral model, explicitly incorporates the
identification of key stakeholders and their respective “win” conditions, i.e., what will
be regarded as a satisfactory outcome for each stakeholder group. A period of
stakeholder negotiation to ensure a “win-win” result is included.

Rapid Application Development (RAD)

During the 1990s the drive to focus upon users became stronger and resulted in a
number of new approaches to development. The Rapid Application Development
(RAD) approach attempts to take a user-centered view and to minimize the risk
caused by requirements changing during the course of the project. The ideas behind
RAD began to emerge in the early 1990s, also in response to the inappropriate nature
of the linear lifecycle models based on the waterfall. Two key features of a RAD
project are:

. Time-limited cycles of approximately six months, at the end of which a
system or partial system must be delivered. This is called time-boxing. In
effect, this breaks down a large project into many smaller projects that can
deliver product incrementally, and enhance flexibility in terms of the
development techniques used and the maintainability of the final system.

. JAD (Joint Application Development) workshops in which users and
developers come together to thrash out the requirements of the system. These
are intensive requirements-gathering sessions in which difficult issues are

154
faced and decisions are made. Representatives from each identified
stakeholder group should be involved in each workshop so that all the relevant
views can be heard.
A basic RAD lifecycle has five phases (as shown in figure): project set-up, JAD
workshops, iterative design and build, engineer and test final prototype,
implementation review. The popularity of RAD has led to the emergence of an
industry-standard RAD-based method called DSDM (Dynamic Systems Development
Method). This was developed by a non-profit-making DSDM consortium made up of
a group of companies that recognized the need for some standardization in the field.
The first of nine principles stated as underlying DSDM is that “active user
involvement is imperative.” The DSDM lifecycle is more complicated than the one
which shown here. It involves five phases: feasibility study, business study, functional
model iteration, design and build iteration, and implementation. This is only a generic
process and must be tailored for a particular organization.

17.2 Lifecycle models in HCI

Another of the traditions from which interaction design has emerged is the field of
HCI. Fewer lifecycle models have arisen from this field than from software
engineering and, as you would expect, they have a stronger tradition of user focus.
We will discuss two of them in our lecture. The first one, the Star, was derived from
empirical work on understanding how designers tackled HCI design problems. This
represents a very flexible process with evaluation at its core. In contrast, the second
one, the usability engineering lifecycle, shows a more structured approach and hails
from the usability engineering tradition.

JAD workshops
Project set-up
Iterative design and build
Engineer and test final prototype
Implementation review


155

The Star Lifecycle model

About the same time that those involved in software engineering were looking for
alternatives to the waterfall lifecycle, so too were people involved in HCI looking for
alternative ways to support the design of interfaces. In 1989, the Star lifecycle model
was proposed by Hartson and Hix as shown in figure.
This emerged from some empirical work they did looking at how interface designers
went about their work. They identified two different modes of activity: analytic mode
and synthetic mode. The former is characterized by such notions as top-down,
organizing, judicial, and formal, working from the systems view towards the user’s
view; the latter is characterized by such notions as bottom-up, free-thinking, creative
and adhoc, working from the user’s view towards the systems view. Interface
designers served in software designers.
Unlike the lifecycle models introduced above, the Star lifecycle does not specify any
ordering of activities. In fact, the activities are highly interconnected: you can move
from any activity to any other, provided you first go through the evaluation activity.
This reflects the findings of the empirical studies. Evaluation is central to this model,
and whenever an activity is completed, its result(s) must be evaluated. So a project
may start with requirements gathering, or it may start with evaluating an existing
situation, or by analyzing existing tasks, and so on.

The Usability Engineering lifecycle

The Usability Engineering lifecycle was proposed by Deborah Mayhew in 1999.
Many people have written about usability engineering, and as Mayhew herself says, “I
did not invent the concept of a Usability Engineering Lifecycle. Nor did I invent any
of the Usability Engineering tasks included in lifecycle….”.

Evaluation
Conceptual/
formal design
Requirements
Prototyping specification
Task/functional
analysis
Implementation


156

Enhancements

Function/Data Modeling
OOSE: Requirements Model
Unit/System Testing
OOSE: Test Model

Requirement Analysis

User
Profile
Platform
Capabilities/
Constraints
Task
Analysis
Usability
Goals
Style
Guide
General
Design
Principles

Design/Testing/Developmen

Work Reengineering
Screen Design
Standards
(SDS)
Iterative CM
Evaluation
Conceptual
Model (CM)
Design
CM
Mockups

Level 1

Level

Level 3

Eliminated
Major Flaws?

Screen Design
Standards
(SDS)
Screen Design
Standards
(SDS)

Met Usability
Goals?

Detailed User
Interface
Design (DUID)
Iterative
DUID
Evaluation

Met

Yes
Yes
Yes

No Yes

All Functionality
Addressed?
No
No
No

Style
Guide
Style
Guide
Style
Guide

Start Application
Design/Development
OOSE: Design Model/
Implementation Model

Start Application
Architecture OOSE:

User
Feedback

All Issues Yes

No

Installation Done

Installation


157
However, what her lifecycle does provide is a holistic view of usability engineering
and a detailed description of how to perform usability tasks, and it specifies how
usability tasks can be integrated into traditional software development lifecycle. It is
therefore particularly helpful for those with little or no expertise in usability to see
how the tasks may be performed alongside more traditional software engineering
activities. For example, Mayhew has linked the stages with an oriented software
engineering that have arisen from software engineering. The lifecycle itself has
essentially three tasks: requirements analysis, design/testing/development, and
installation, with the middle stage being the largest and involving many subtasks as
shown in figure. Note the production of a set of usability goals in the first task.
Mayhew suggests that these goals be captured in a style guide that is then used
throughout the project to help ensure that the usability goals are adhered to.
This lifecycle follows a similar thread to our interaction design models but includes
considerably more detail. It includes stages of identifying requirements, designing,
evaluating, and building prototypes. It also explicitly includes the style guide as a
mechanism for capturing and disseminating the usability goals of the project.
Recognizing that some projects will not require the level of structure presented in the
full lifecycle, Mayhew suggests that some sub steps can be skipped if they are
unnecessarily complex for the system being developed.

The Goal-Directed Design Process

Most technology-focused companies don’t have an adequate process or user-centered
design, if they have a process at all. But even the more enlightened organizations,
ones that can boast of an established process, come up against some critical issues that
result from traditional ways of approaching the problems of research and design.
In recent years, the business community has come to recognize that user research is
necessary to create good products, but the proper nature of that research is still in
question in many organizations. Quantitative market research and market
segmentation is quite useful for selling products, but falls short of providing critical
information about how people actually use products—especially products with
complex behaviors. A second problem occurs after the results have been analyzed:
most traditional methods don’t provide a means of translating research results into
design solutions. A hundred pages of user survey data don’t easily translate into a set
of product requirements, and they say even less about how those requirements should
be expressed in terms of a logical and appropriate interface structure. Design remains
a black box: “a miracle happens here.” This gap between research results and the
ultimate design solution is the result of a process that doesn’t connect the dots from
user to final product.

Bridging the gap

As it is already discussed that the role of design in the development process needs to
be change. We need to start thinking about design in new ways, and start thinking
differently about how product decisions are made.

Design as product definition

Design has, unfortunately, become a limiting term in the technology industry. Design,
when properly deployed identifies user requirements and defines a detailed plan for

158
the behavior and appearance of products. In other words, design provides true product
definition, based on goals of users, needs of business, and constraints of technology.

Designers as researchers

If design is to become product definition, designers need to take on broader roles than
that assumed in traditional design, particularly when the object of this design is
complex, interactive systems. One of the problems with the current development
process is that roles in the process are overspecialized: Researchers perform research,
and designers perform design. The results of user and market research are analyzed by
the usability and market researchers and then thrown over the transom to designers or
programmers. What is missing in this model is a systematic means of translating and
synthesizing the research into design solutions. One of the ways to address this
problem is for designers to learn to be researchers.
There is a compelling reason for involving designers in the research process. One of
the most powerful tools designers bring to the table is empathy: the ability to feel
what others are feeling. The direct and extensive exposure to users that proper user
research entails immerses designers in he users’ world, and gets them thinking about
users long before they propose solutions. One of the most dangerous practices in
product development is isolating designers from the users because doing so eliminates
empathic knowledge. Additionally, it is often difficult for pure researchers to know
what user information is really important from a design perspective. Involving
designers directly in research addresses both. Although research practiced by
designers takes us part of the way to Goal-Directed Design solutions, there is still a
translation gap between research results and design details.

Between research and design: models, requirements, and
frameworks

Few design method in common use today incorporate a means of effectively and
systematically translating the knowledge gathered during research into a detailed
design specification. Part of the reason for this has already been identified. Designers
have historically been out of the research loop and have had to rely on third-person
accounts of user behaviors and desires.
The other reason, however, is that few methods capture user behaviors in a manner
that appropriately directs the definition of a product. Rather than providing
information about user goals, most methods provide information at the task level. This
type of information is useful for defining layout, workflow, and translation of
functions into interface controls, but less useful for defining the basic framework of
what a product is, what it does, and how it should meet the broad needs of the user.
Instead we need explicit, systematic processes for defining user models, establishing
design requirements, and translating those into a high level interaction framework.

Research

User and the
domain

Modeling

Users and use
context

Requirements

Definition of user,
business& technical needs

Framework

Definition of design
structure & flow

Refinement

Of behavior, form&
content

*(images not available in online version)

Goal-Directed Design seeks to bridge the gap that currently exists in the digital
product development process, the gap between user research and design, through a
combination of new techniques and known methods brought together in more
effective ways.

<Previous Lesson

Human Computer Interaction

Next Lesson>

Home

Lesson Plan

Topics

Go to Top

Next Lesson
Previous Lesson
Lesson Plan
Topics
Home
Go to Top