CHAPTER - FIVE

Interaction Design and HCI in the Software Process

❖ Interaction design basics:
▪ design:
– what it is, interventions, goals, constraints

▪ the design process

▪ what happens when
▪ users
▪ who they are, what they are like …
▪ scenarios
▪ rich stories of design
▪ navigation
▪ finding your way around a system
▪ iteration and prototypes
▪ never get it right first time!
 Interaction design basics …
❖ Some of HCI is focused on understanding: the academic study of the way
people interact with technology.
❖However, a large part of HCI is about doing things and making things –
design.
❖So, interaction design is not just about the artifact that is produced,
whether a physical device or a computer program, but about understanding
and choosing how that is going to affect the way people work.
❖Furthermore, the artifacts we give to people are not just these devices and
programs, but also manuals, tutorials, online help systems.
 Interaction design basics …
❖ Interaction design is about creating interventions in often complex situations using
technology of many kinds including PC software, the web, and physical devices.

❖Design involves: - achieving goals within constraints and trade-offs between these -
understanding the raw materials: computer and human - accepting limitations of
humans and of design.

❖ The design process has several stages and is iterative and never complete.

❖ Interaction starts with getting to know the users and their context: – finding out who
they are and what they are like . . probably not like you! – talking to them, watching
them.
 Interaction design basics …
❖Scenarios are rich design stories, which can be used and reused throughout design: –
they help us see what users will want to do – they give a step-by-step walkthrough of
users’ interactions: including what they see, do, and are thinking.

❖ Users need to find their way around a system.

❖This involves: – helping users know where they are, where they have been, and what
they can do next – creating overall structures that are easy to understand and fit the
users’ needs – designing comprehensible screens and control panels.
 Interaction design basics …

❖ Complexity of design means we don’t get it right the first time:

– so we need iteration and prototypes to try out and evaluate

– but iteration can get trapped in local maxima, designs that have no simple

improvements, but are not good

– theory and models can help give good starting points.

 Interactions and Interventions
➢Design interactions are not just interfaces.
➢It is not just the immediate interaction
e.g. stapler in office – technology changes interaction style
• manual: write, print, staple, write, praret, staple, …
• electric: write, print, write, print, …, staple

➢Designing interventions are not just artefacts

➢It is not just the system, but also …
• documentation, manuals, tutorials
• what we say and do as well as what we make
 what is design?
❖A simple definition is: achieving goals within constraints
❖This does not capture everything about design, but helps to focus us on certain things:
✓ goals - purpose
• who is it for, why do they want it
✓ constraints
• materials, platforms
✓ trade-offs
 The golden rule of design
❖ This leads us to the golden rule of design: understand your materials
❖ For Human–Computer Interaction the obvious materials are the human and the computer. That is we
must:
❖ understand computers
– limitations, capacities, tools, platforms
❖ understand people
– psychological, social aspects, human error. and their interaction …
 To err is human

❖In fact, the opposite is the case: physical materials are treated better in most designs
than people.
❖The phrase ‘human error’ is taken to mean ‘operator error’, but more often than not the
disaster is inherent in the design or installation of the human interface.
❖Bad interfaces are slow or error-prone to use. Bad interfaces cost money and cost lives.
❖People make mistakes.
❖Often when an aspect of an interface is obscure and unclear, the response is to add
another line in the manual.
 The process of design
❖If you design using a physical material, you need to understand how and where failures
would occur and strengthen the construction, build in safety features or redundancy.
❑The central message – the user
❖We will discuss the information on basic psychology, on particular technologies, on
methods and models.
❖This is the core of interaction design: put the user first, keep the user in the center and
remember the user at the end.
 The process of design…
➢ Requirements – what is wanted
➢ Analysis - These techniques can be used both to represent the situation as it is and also the
desired situation.
➢ Design -Well, this is all about design, but there is a central stage when you move from what
you want, to how to do it.
❖ Iteration and prototyping Humans are complex and we cannot expect to get designs right
first time.
❖We therefore need to evaluate a design to see how well it is working and where there can be
improvements.
➢ Implementation and deployment Finally, when we are happy with our design, we need to
create it and deploy it.
❖This will involve writing code, perhaps making hardware, writing documentation and manuals
– everything that goes into a real system that can be given to others
 The process of design…
what is
wanted
scenarios
task analysis
guidelines
principles precise
analysis
interviews specification
ethnography design
dialogue
implementation
what is there notations and deployment
vs. evaluation
prototype
what is wanted heuristics architectures
documentation
help
 User focus
❖ As we’ve already said, the start of any interaction design
exercise must be the intended user or users.
❖ This is often stated as: know your users.
❖ So, how do you get to know your users?
✓ Who are they?
✓ Probably not like you!
✓ Talk to them.
✓ Watch them.
✓ Use your imagination
 Navigation design
❖ The design would make sense to the user and also that
proposed implementation architectures would work.
❖In addition scenarios can be used to:
➢ Communicate with others – other designers, clients or users.
➢ Validate other models A detailed scenario can be ‘played’
against various more formal
❖representations such as task models or dialog and navigation
models.
➢Express dynamics Individual screen shots and pictures give
you a sense of what a system would look like, but not how it
behaves.
 Navigation design
❖ This linearity has both positive and negative points:

➢ Time is linear: Our lives are linear as we live in time and so we find it easier to understand
simple linear narratives.

➢ But no alternatives: Real interactions have choices, some made by people, some by
systems. A simple scenario does not show these alternative paths.

▪ In particular, it is easy to miss the unintended things a person may do.

▪ Scenarios are a resource that can be used and reused throughout the design process: helping
us see what is wanted, suggesting how users will deal with the potential design, checking that
proposed implementations will work, and generating test cases for final evaluation.
 Navigation design…
❖ But now we are focusing on the computer system itself. You interact at several levels:

➢ Widgets The appropriate choice of widgets and wording in menus and buttons will help

you know how to use them for a particular selection or action.

➢ Screens or windows: You need to find things on the screen, and understand the logical
grouping of buttons.

➢ Navigation within the application: You need to be able to understand what will happen

when a button is pressed, to understand where you are in the interaction.

➢ Environment The word processor has to read documents from disk, perhaps some are on
remote networks. You swap between applications, perhaps cut and paste.
 Navigation design…
❖ The structure of an application is to think about actual use:
➢ Who is going to use the application?
➢ How do they think about it?
➢ What will they do with it?
❖This can then drive the second task – thinking about structure.
❖Here we will consider two main kinds of issue :
➢ Local structure
– looking from one screen or page out
➢ Global structure
– structure of site, movement between screens.
 Navigation design…
❖ Local structure
➢ Much of interaction involves goal-seeking behavior.
➢ Users have some idea of what they are after and a partial model of the system.
➢ However, in a world of partial knowledge users meander through the system.
❑The Levels of interaction
▪ PC application
➢Widgets
➢Screen design
➢Navigation design
➢Other apps and operating system
 Navigation design…
❑ The Levels of interaction
▪ Physical device
➢ Buttons, dials, lights, displays
➢ Physical layout
➢ Main modes of device
▪ The real world!
➢ Website
➢ Form elements, tags and links
➢ Page design
▪ Site structure
➢ The web, browser, external links
 Navigation design…
❑Here are four things to look for when looking at a single web page, screen or state of
a device.
➢ Knowing where you are
➢ Knowing what you can do
➢ Knowing where you are going – or what will happen
➢ Knowing where you’ve been – or what you’ve done.
 Navigation design…
▪ The screen, web page or device displays should make clear where you are in terms of
the interaction or state of the system.
▪ It is also important to know what you can do – what can be pressed or clicked to go
somewhere or do something.
▪ Some web pages are particularly bad in that it is unclear which images are pure
decoration and which are links to take you somewhere.
▪ You then need to know where you are going when you click a button or what will
happen.
▪ Of course you can try clicking the button to see.
▪ In the case of a website or information system, this may mean you then have to use
some sort of ‘back’ mechanism to return, but that is all; however, in an application or
device, the action of clicking the button may already have caused some effect.
 Global structure – hierarchical organization

▪ We will now look at the overall structure of an application.

▪ This is the way the various screens, pages or device states link to one another. One
way to organize a system is in some form of hierarchy.

▪ This is typically organized along functional boundaries (that is, different kinds of
things), but may be organized by roles, user type, or some more esoteric breakdown
such as modules in an educational system.

▪ The hierarchy links screens, pages, or states in logical groupings.

 Global structure – dialog
▪ In a pure information system or static website it may be sufficient to have a fully hierarchical
structure, perhaps with next/previous links between items in the same group.
▪ However, for any system that involves doing things, constantly drilling down from one part of the
hierarchy to another is very frustrating.
▪ Usually there are ways of getting more quickly from place to place.
▪ In HCI the word ‘dialog’ is used to refer to this pattern of interactions between the user and a system.
▪ Human–computer dialog is just the same; there are overall patterns of movement between the main
states of a device or windows in a PC application, but the details differ each time it is run.
▪ A simple way is to use a network diagram showing the principal states or screens linked together with
arrows.
 Global structure – dialog
▪ This can:
➢ show what leads to what
➢ show what happens when
➢ include branches and loops
➢ be more task-oriented than a hierarchy.
▪ Wider still
➢ Each sits amongst other devices and applications and this in turn has to be reflected within our
design.
➢ This has several implications:
➢ Style issues We should normally conform to platform standards, such as positions for
➢ menus on a PC application, to ensure consistency between applications.
➢ Functional issues On a PC application we need to be able to interact with files, read standard
formats and be able to handle cut and paste.
 Global structure – dialog
➢ Navigation issues We may need to support linkages between applications, for
example

➢ Allowing the embedding of data from one application in another, or, in the mail
system,

➢ being able to double-click an attachment icon and have the right application
launched for the attachment.
 Screen Design and Layout
➢ A single-screen image often has to present information clearly and also act as the
locus for interacting with the system. The basic principles at the screen level reflect
those in other areas of interaction design:
➢ Ask What is the user doing?

➢ Think What information is required?

➢ What comparisons may the user need to make? In what order are things likely to be needed?

➢ Design Form follows function: let the required interactions drive the layout.
 HCI in the Software Process
➢ 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 that affect usability.
 HCI in the Software Process…
➢ 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.

➢ Within computer science there is already a large sub-discipline 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.
 The Software Life Cycle …
➢ One of the distinguishing characteristics of any engineering discipline is that it entails the

➢ structured application of scientific techniques to the development of some product.

➢ A fundamental feature of software engineering, therefore, is that it provides the structure for

applying techniques to develop software systems.

➢ 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 waterfall model
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
 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.

➢ We describe the activities of this waterfall model of the software life cycle next.
 Activities in the life cycle
▪ Requirements specification
➢ The designer and customer try to 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
➢ A 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 non-functional
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
Verification requirements
designing the product right and constraints The formality gap

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
specification
cannot assume a linear
Architectural
sequence of activities
design as in the waterfall model

Detailed
design

Coding and
unit testing

Integration
lots of feedback! and testing

Operation and
maintenance
 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
Storyboards
Techniques for prototyping
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

• Two examples:
• Issue-based information system (IBIS)
• Design space analysis
 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
Criterion
Option

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