|
|
|
|
|
|
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. |
|
|
|
|