Human Computer Interaction

BSc Applied Computing

12. User-Centred Design

Contents

INTRODUCTION................................................................................................................................... 2

REPRESENTATIONS FOR DESIGN...................................................................................................................... 2

MODELS FOR THE DESIGN OF SOFTWARE.................................................................................................... 3

USER-CENTRED DESIGN....................................................................................................................................... 6

JP 11/11/2004
BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

Introduction
In previous chapters we have looked at the cognitive aspects of HCI and at interaction design.
We now deal with design methods for the design of interactive systems. We take a look at the
traditional waterfall model of system development and also at some more user-oriented
principles

Representations for design

In order to develop a system, two major activities are required. The designer must understand the
requirements of the product and must develop the product. Development may include producing
a variety of representations, or models, of the system.

Representations can be used for a variety of purposes, including:

• Exploring the problem space – sketches, storyboards, paper prototypes

• Communication – models which express ideas to the customer or to the programmers
who will implement the system
• Making predictions – estimation of user performance, project effort and cost

A good representation is accurate enough to reflect the features of the system, but simple enough
to avoid confusion.

Representations of software are equivalent to the various representations used in the design of a
car. What do you think the purposes of the following would be?

• Doodles and sketches

• Blueprints
• Scale models
• Computer model

Car stylist’s sketches (www.cardesignnews.com)

Page 2
BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

Models for the design of software

The following models describe three different methods for the development of a software system.
Each model makes use of a range of representations and processes.

Waterfall model
The waterfall model is a software life-cycle model, described by W. W. Royce in 1970, in which
development is supposed to proceed linearly through the phases of requirements analysis,
design, implementation, testing (validation), integration and maintenance.

There have been a number of criticisms of the standard waterfall model, including

• There is a ‘contract’ relationship between client and developers – the user is not involved
beyond the initial phase.
• Problems are not discovered until system testing
• Requirements must be fixed before the system is designed, whereas in reality it is often
impossible to understand requirements fully until a fair amount of design has been
undertaken.
• System performance cannot be tested until the system is almost coded

The standard waterfal model is associated with the failure or cancellation of a number of large
systems. It can also be very expensive. As a result, the software development community has
experimented with a number of alternative approaches, including the spiral model and the star
model.

The waterfall model. The boxes are representations of the system and the arrows are
processes or activities

Page 3
BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

Spiral model
The spiral model (Boehm, 1988) uses incremental development, with the aim of managing risk. In
the spiral model, developers define and implement features in order of decreasing priority. An
initial version of the system is developed, and then repetitively modified based on input received
from customer evaluations. The development of each version of the system is carefully designed
using the steps involved in the waterfall model. With each iteration around the spiral (beginning at
the centre and working outward), progressively more complete versions of the system are built.

The Spiral Model is made up of the following steps:

• Project Objectives. Similar to the system conception phase of the Waterfall Model.
Objectives are determined, possible obstacles are identified and alternative approaches
are weighed.
• Risk Assessment. Possible alternatives are examined by the developer, and associated
risks/problems are identified. Resolutions of the risks are evaluated and weighed in the
consideration of project continuation. Sometimes prototyping is used to clarify needs.
• Engineering & Production. Detailed requirements are determined and the software piece
is developed.
• Planning and Management. The customer is given an opportunity to analyze the results
of the version created in the Engineering step and to offer feedback to the developer.

The Spiral model relies heavily on prototyping. When using prototyping, the developer builds a
simplified version of the proposed system and presents it to the customer for consideration as
part of the development process. The customer in turn provides feedback to the developer, who
goes back to refine the system requirements to incorporate the additional information. Often, the
prototype code is thrown away and entirely new programs are developed once requirements are
identified. We will look at prototyping methods in a later chapter.

The spiral model

Page 4
BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

The Star Model

The star model (Hartson & Hix, 1989) emphasises that the design of interactive systems typically
does not follow a specific order of steps. Evaluation represents the central phase in the
development cycle. Development can start from any point in the star (as shown by the entry
arrows) and any stage can be followed by any other stage. Evaluation is always done before
moving to a new stage. The requirements, design and product gradually evolve, becoming
increasingly well-defined.

The star model can give the user a significant role throughout the project since evaluation is
central to the cycle. It is particularly oriented towards the development of interactive systems that
will be usable by people.

Evaluation can be based on any representation of the system. A variety of representations may
be used during the development, including sketches, scenarios, prototypes and formal models.

The star model

Page 5
BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

User-centred design
User centred design is an approach to software development user-centred design focuses
specifically on making products usable. The approach typically entails involving users in the
design and testing of the system so that their feedback can be obtained. Prototypes are usually
employed to do this and designs are modified in light of the user feedback.

Initially it may seem that the user-centred approach complicates the software development task,
due to the need to make iterative refinements to the software in light of user feedback. However
the benefits to be gained are considerable. The process promotes communication between
users, managers and those developing the software and identifies problematic issues early on in
the development schedule when it is much cheaper to implement changes.

The 1984 OMS – the original user-centred design

The first major user-centred design project was the Olympic Messaging System (OMS) used at
the 1984 Olympics in Los Angeles. OMS was developed in order to provide a message service
(voice mail) and other support for the 10,000 athletes who attended the 1984 games. Kiosks were
placed around the Olympic village

An OMS kiosk

After some initial analysis of the requirements for the system, printed scenarios of the user
interface were prepared. These were commented on by designers, management and prospective
users. As a result of this early evaluation, a number of the system functions were altered and
others were dropped completely

The design team also produced brief user guides aimed at explaining what the system did and
how it worked These were tested on the main user groups (Olympians, their families and friends)
and were developed iteratively (over 200 slightly modified versions were produced) before the
final form was decided.

Page 6
 BSc Applied Computing Human Computer Interaction: 12. User-Centred Design

Early simulations of the messaging system were also constructed and evaluated for the purpose
of designing help messages. These simulations were tested with users. One thing that these tests
revealed, for example, was that an ‘undo’ or ‘backup’ key was required so that users could
retrieve a previous position if they made a mistake.

Many other methods were used to collect information about what was needed, including tours of
the Olympic village sites, early demonstrations of the system, interviews with the different people
involved in the Olympics and discussions with an experienced ex-Olympian who was part of the
design team.

A prototype was then developed which was tested with different user groups. This resulted in
many more iterations and retesting.

Principles of user-centred design

The key principles of user-centred design were developed from the design of the OMS (Gould,
1987):

• Focus early in the design process on users and their tasks

• Measure users’ reactions and performance to scenarios, manuals, simulations, and
prototype are observed, recorded and analysed
• Design iteratively: when problems are found in user testing, fix them and carry out more
tests
• All usability factors must emerge together and be under the responsibility of one
control group.

Gould commented that of 450 system designers and developers who were asked to write down
the steps they recommend in the design of an office system, 26 percent of them mentioned none
of the principles, and another 35 percent mentioned only one of the principles. Clearly, the
principles of user-centred design were far from being obvious to designers at that time.

Read more on usage centered design

Power of Models in Usage-Centered Design

May 6, 2007 by inspiredart
Usable software is one that helps users perform their task efficiently, easily. When designing software the focus must
always be on the users….basically it means the design process must be user centric. Now this statement will
automatically throw the following questions at us:
 Who are the users?
 How are they related to the software we are designing?
 what do they require from the software to perform their tasks?
 How should the content in the software be presented and how should the user interface behave when they
perform a particular task?
How do we answer these questions?A model based approach will solve the above problems easily.
The 3 simple models is what one needs to apply to find solution for User Interface design problems
1. Role Model – Gather all information about the users, what is their background, their relationship with the
software system etc,.
2. Task Model – A list of all the tasks and use cases that the user will perform when interacting with the system
3. Content Model – This model deals with the basic presentation of the user Interface. Where, how and what tools
will the user need to perform a particular task.
4. The Task Model and Content model will help us in getting to the behavior model, which in a way reflects the
face of the end product that we will design.
A Visual representation of the above topic:

Software for Use by Larry Constantine and Lucy Lockwood is an excellent read to get the basics right for inculcating
the habit of usage centered design approach. They stress on a Model based approach while designing a system which
would yield the best returns in the form of user experience and efficiency of the software. More details on this can be
accessed on their website

Every software development methodology framework acts as a basis for applying specific approaches to develop and
maintain software. Several software development approaches have been used since the origin of information
technology. These are:[2]
 Waterfall: a linear framework
 Prototyping: an iterative framework
 Incremental: a combined linear-iterative framework
 Spiral: a combined linear-iterative framework
 Rapid application development (RAD): an iterative framework
 Extreme Programming
Waterfall development
The Waterfall model is a sequential development approach, in which development is seen as flowing steadily
downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation),
integration, and maintenance. The first formal description of the method is often cited as an article published by
Winston W. Royce[3] in 1970 although Royce did not use the term "waterfall" in this article.
The basic principles are:[2]
 Project is divided into sequential phases, with some overlap and splashback acceptable between phases.
 Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one
time.
 Tight control is maintained over the life of the project via extensive written documentation, formal reviews,
and approval/signoff by the user and information technology management occurring at the end of most phases
before beginning the next phase.

Prototyping
Software prototyping, is the development approach of activities during software development, the creation of
prototypes, i.e., incomplete versions of the software program being developed.
The basic principles are:[2]
 Not a standalone, complete development methodology, but rather an approach to handling selected parts of a
larger, more traditional development methodology (i.e. incremental, spiral, or rapid application development
(RAD)).
 Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-
of-change during the development process.
 User is involved throughout the development process, which increases the likelihood of user acceptance of the
final implementation.
 Small-scale mock-ups of the system are developed following an iterative modification process until the
prototype evolves to meet the users’ requirements.
 While most prototypes are developed with the expectation that they will be discarded, it is possible in some
cases to evolve from prototype to working system.
 A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.

Incremental development
Various methods are acceptable for combining linear and iterative systems development methodologies, with the
primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
The basic principles are:[2]
 A series of mini-Waterfalls are performed, where all phases of the Waterfall are completed for a small part of a
system, before proceeding to the next increment, or
 Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual
increments of a system, or
  The initial software concept, requirements analysis, and design of architecture and system core are defined via
Waterfall, followed by iterative Prototyping, which culminates in installing the final prototype, a working
system.

Spiral development

The spiral model.

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in
an effort to combine advantages of top-down and bottom-up concepts.
The basic principles are:[2]

Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process, as well as providing the opportunity to
evaluate risks and weigh consideration of project continuation throughout the life cycle.

"Each cycle involves a progression through the same sequence of steps, for each part of the product and for
each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each
individual program."[4]

Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints
of the iteration; (2) evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from
the iteration; and (4) plan the next iteration.[4][5]

Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with
review and commitment.[6]

Rapid application development

Rapid application development (RAD) is a software development methodology, which involves iterative development
and the construction of prototypes. Rapid application development is a term originally used to describe a software
development process introduced by James Martin in 1991.
The basic principles are:[2]
 Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
 Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-
of-change during the development process.
 Aims to produce high quality systems quickly, primarily via iterative Prototyping (at any stage of
development), active user involvement, and computerized development tools. These tools may include
Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database
 Management Systems (DBMS), fourth-generation programming languages, code generators, and object-
oriented techniques.
 Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser
importance.
 Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project
starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
 Generally includes joint application design (JAD), where users are intensely involved in system design, via
consensus building in either structured workshops, or electronically facilitated interaction.
 Active user involvement is imperative.
 Iteratively produces production software, as opposed to a throwaway prototype.
 Produces documentation necessary to facilitate future development and maintenance.
 Standard systems analysis and design methods can be fitted into this framework.

Other practices
Other methodology practices include:

Object-oriented development methodologies, such as Grady Booch's object-oriented design (OOD), also
known as object-oriented analysis and design (OOAD). The Booch model includes six diagrams: class, object,
state transition, interaction, module, and process.[7]

Top-down programming: evolved in the 1970s by IBM researcher Harlan Mills (and Niklaus Wirth) in
developed structured programming.

Unified Process (UP) is an iterative software development methodology framework, based on Unified
Modeling Language (UML). UP organizes the development of software into four phases, each consisting of
one or more executable iterations of the software at that stage of development: inception, elaboration,
construction, and guidelines. Many tools and products exist to facilitate UP implementation. One of the more
popular versions of UP is the Rational Unified Process (RUP).

Agile software development refers to a group of software development methodologies based on iterative
development, where requirements and solutions evolve via collaboration between self-organizing cross-
functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Integrated software development refers to a deliverable based software development framework using the three
primary IT (project management, software development, software testing) life cycles that can be leveraged
using multiple (iterative, waterfall, spiral, agile) software development approaches, where requirements and
solutions evolve via collaboration between self-organizing cross-functional teams.

Page 7