4.

Interaction Design

4.1 What is Interaction Design?

"design is a plan or scheme conceived in the mind and intended for subsequent execution"

The ultimate goal of design is to develop a product that helps its users achieve their goals.
Developing a product must begin with gaining understanding of what is required of it.

In Interaction Design, we investigate the artifact's use and target domain by taking a user-
centered approach to development. The users' concerns direct the development rather than
technical concerns.

Design is also about trade-offs and about balancing conflicting requirements. Generating
alternatives is a key principle and one that should be encouraged in interaction.

Four Basic Activities:

i. Identify needs and establish requirements

 Who is the target user?
 What kind of support will the interactive product provide?
ii. Develop alternative designs that meet those requirements
 suggest ideas to meet the requirements
 Conceptual design: produce the conceptual model for the product
 Physical design: consider the details of the product (colors, sounds, images, menu
design, icons, etc.) Alternatives are considered at every point.
iii. Build interactive versions (so that they can be communicated and assessed)
 a software version is not required- paper based prototypes are quick and cheap to
build
 through role-playing, users can get a real sense of what it is like to interact with the
product
iv. Evaluate the designs (measure their acceptability)
 Determine the usability of the product or design. Criteria are: how appealing is it?
how well does it match the requirements? Is the product fit for the purpose?
 Evaluation results are fed back into further design (FEEDBACK / ITERATIVE DESIGN
PROCESS)

1
Three Characteristics of Interaction Design:

 Focus on the USERS - involve users in the interactive design process, provide
opportunities for evaluation and user feedback
 Specific usability and user experience goals - - identify and clearly document these at
the beginning of the project. They help designers to choose between different
alternative designs
 Iteration - allows for designs to be refined. It is always necessary to revise ideas in light
of feedback, several times. Innovation rarely emerges whole and ready to go. Iteration
is inevitable because designers never get the solution right the first time

4.2 The process of design

scenarios
what is task analysis
wanted guidelines
principles
interviews analysis precise
ethnography specification
design
what is there
vs. dialogue implement
what is wanted notations and deploy
evaluation
prototype
heuristics architectures
documentation
help

Steps

• requirements
– what is there and what is wanted …
• analysis
– ordering and understanding
• design
– what to do and how to decide
• iteration and prototyping
– getting it right … and finding what is really needed!
• implementation and deployment
– making it and getting it out there

4.3 User-centered design

2
User centered design is an approach to software development. User-centered 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-centered 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.

Principles of user-centered design

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

4.3 Lifecycle Models: Showing how the activities are related

Lifecycle models represent a set of activities and how they are used; management tools;
simplified versions of reality

- some models from software engineering include waterfall, spiral, RAD, etc

4.3.1 Waterfall model

The waterfall model is a software life-cycle model, 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

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

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

4.3.3 Rapid Application Development

RAD (Rapid Applications Development): takes a user centered view and tries to minimize the
risk of changing requirements through the project. A system or partial system must be
delivered on a set of intervals.

The RAD method has a task list and a work breakdown structure that is designed for speed.
However the major difference in RAD is a set of management techniques that are optimized for
speed. Among the most important are:

 Prototyping - an approach based on creating a demonstrable result as early as possible

and refining that result. The refinement is based on feedback from the business, the
eventual users of the system. Prototyping requires an open approach to development, it
also requires an emphasis on relationship management and change management. There
are dangers involved in starting prototype development too early and in starting it too
late.

 Iteration - is a commitment to incremental development based on refinement.

Prototyping and iteration go hand in hand.

 Time-boxing - is a management technique that focuses attention on delivery above all

else. Under a time-box, scope can change but delivery cannot.

4
Some models from HCI include: Star, usability engineering

4.3.4 The Star Model

The star model emphasizes 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 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

4.3.5 The Usability Engineering lifecycle

5
Usability engineering (UE) is a systematic approach to making software easier to use for the
individuals who actually use it to get their work done. It is an approach to the development of
software and systems which involves user participation from the outset and guarantees the
usefulness of the product through the use of a usability specification and metrics. UE thus
refers to the entire process of producing usable software products from requirements gathering
to installation. UE is based on a User-Centered Design (UCD) approach to analysis and design.

The Usability Engineering life cycle

Stage Information Produced
 Know the user User characteristics, User background
 Know the task User’s current task, Task analysis
 User requirements capture User requirements
 Setting usability goals Usability specification
 Design process Design

 Apply guidelines, heuristics Feedback for design

 Prototyping Prototype for user testing
 Evaluation with users Feedback for design
 Redesign and evaluate with users Finished product
 Evaluate with users and report Feedback on product for future systems

4.4 Prototyping

Prototypes are experimental and incomplete designs which are cheaply and fast developed.
Prototyping is an integral part of user-centred design and the usability engineering lifecycle
because it enables designers to try out their ideas with users and to gather feedback.

The main purpose of prototyping is to involve the users in testing design ideas and get their
feedback in the early stage of development, thus to reduce the time and cost. It provides an
efficient and effective way to refine and optimise interfaces through discussion, exploration,
testing and iterative revision. Early evaluation can be based on faster and cheaper prototypes
before the start of a full-scale implementation.

The prototypes can be changed many times until a better understanding of the user interface
design has been achieved with the joint efforts of both the designers and the users. Prototyping
can be divided into low-fidelity prototyping and high-fidelity prototyping.

Low-fidelity prototypes are quickly constructed to depict concepts, design alternatives, and
screen layouts, rather than to model the user interaction with a system. Low-fidelity prototypes
6
provide limited or no functionality. They are intended to demonstrate the general look and the
feel of the interface, but not the detail how the application operates.

High-fidelity prototypes are fully interactive, simulating much of the functionality in the final
product. Users can operate on the prototype, or even perform some real tasks with it.

Prototyping in the software process

Evolutionary prototyping
This is an approach to system development where an initial prototype is produced and refined
through a number of stages to the final system. It is used for systems where the specification
cannot be developed in advance and is based on techniques which allow rapid system
iterations. Advantages include accelerated delivery of the system and user engagement with
the system.

Throw-away prototyping
A prototype which is usually a practical implementation of the system is produced to help
discover requirements problems and then discarded. The techniques of Rapid Prototyping can
be used. The system is then developed using some other development process. Customers and
end-users should resist the temptation to turn the throw-away prototyping into a delivered
system that is put into use.
There is an important difference between the objectives of evolutionary and throw-away
programming:
• The objective of evolutionary prototyping is to deliver a working system to end-users.
• The objective of throw-away prototyping is to validate or derive the system requirements.

Incremental development

7
The system is developed and delivered in increments after establishing an overall architecture.
The requirements and specifications for each increment may be developed. Users may
experiment with delivered increments while others are being developed and so these can serve
as a form of prototype system

4.5.1 Contextual Design

Contextual Design is a structured, well-defined user-centered design process that provides

methods to collect data about users in the field, interpret and consolidate that data in a
structured way, use the data to create and prototype product and service concepts, and
iteratively test and refine those concepts with users. This is the core of the Contextual Design
philosophy - understand users in order to find out their fundamental intents, desires, and
drivers. But these are invisible to the users - so the only way to glean them is to go out in the
field and talk with people

Why involve users

• Expectation Management
– Ensure realistic expectations on the part of the user
– Ensures there are no surprises when the software is delivered
– Important when a new system is being introduced that changes existing work
practices
• Ownership
– Feel they have a stake in the product which may help with acceptance.
–
The Role of the Contextual Designer

• To make sense of real life situations

– Identify stakeholders and their attributes
– Model the usage environments
• To uncover Implicit knowledge
– Identify activities and critical success factors
• To design a system that matches its users’ needs

8
Description of the Contextual Design Process

Contextual Inquiry

Contextual inquiry is an explicit step for understanding who the customers really are and how
they work on a day-to-day basis. The design team conducts one-on-one field interviews with
users in their workplace to discover what matters in the work. These are not traditional
question and answer interviews. Instead, a contextual interviewer observes users as they work
and inquires into the users' actions as they unfold to understand their motivations and strategy.
The interviewer and user, through discussion, develop a shared interpretation of the work.

Work Modeling

Five different models provide five perspectives on how work is done:

 The flow model captures communication and coordination between people to
accomplish work. It reveals the formal and informal workgroups and communication
patterns critical to doing the work. It shows how work is divided into formal and
informal roles and responsibilities.
 The cultural model captures culture and policy that constrain how work is done. It shows
how people are constrained and how they work around those constraints to make sure
the work is done.

9
  The sequence model shows the detailed steps performed to accomplish each task
important to the work. It shows the different strategies people use, the intents or goals
that their task steps are trying to accomplish, and the problems getting in their way.
 The physical model shows the physical environment as it supports or gets in the way of
the work. It shows how people organize their environments to make their work easier.
 The artifact model shows the artifacts that are created and used in doing the work.
Artifacts reveal how people think about their work - the concepts they use and how they
organize them to get the work done.

Consolidation

Consolidation brings data from individual customer interviews together so the team can see
common pattern and structure without losing individual variation. The affinity diagram brings
together issues and insights across all customers into a wall-sized, hierarchical diagram to
reveal the scope of the problem.

Consolidated work models bring together each different type of work model separately, to
reveal common strategies and intents while retaining and organizing individual differences.
Together, the affinity diagram and consolidated work models produce a single picture of the
customer population a design will address. They give the team a focus for the design
conversation, showing how the work hangs together rather than breaking it up in lists.

The Design Response: Visioning

The vision captures a story of how customers will do their work in the new world the team
invents. A vision includes the system, its delivery, and support structures to make the new work
practice successful. It is intentionally rough and high-level - a vision sets a possible design
direction, without fleshing out every detail. This enables the team to see the overall structure of
the solution and ensure its coherence.

10