The process of human-centred UX

design
 Overview
• Design is a creative process concerned with bringing about something new.

• It is about conscious change and communication between designers and the

people who will use the system.
• Different design disciplines have different methods and techniques for helping
with this process.
• Approaches to and philosophies of design change over time.
• Different design disciplines have different constraints such as whether the
designed object is ‘stand alone’ or whether it has to fit in and live with legacy
systems or conform to standards.
• UX is increasingly concerned with both the moments of interaction and how
experiences unfold over time.
Objectives
• After studying this chapter, you should be able to:
• Understand the nature of UX design
• Understand the four processes involved in design:
understanding, design, envisionment, evaluation
• Understand the centrality of evaluation in human-
centered design
• Understand the centrality of evaluation to human-
centred UX
• Understand the use of personas in UX
• Understand the use of scenarios in UX
• Be able to use scenarios throughout the UX design
process
Contents

• Introduction
• The process of UX design
• Developing personas
• Developing scenarios
• Using scenarios throughout design
• A scenario-based UX design method
Introduction
• There are many different ways of characterizing the activities involved in
the design process.
• For David Kelley, founder of the product design company IDEO:
– ‘Design has three activities: understand, observe and visualize’.
– ‘Remember, design is messy; designers try to understand this mess.
They observe how their products will be used; design is about users
and use. They visualize which is the act of deciding what it is’.
• Another popular characterization of the UX design process is the ‘double
diamond’ model developed by the Design Council (UK).
• This characterizes the design process in terms of four processes: discover,
define, design and deliver.
PACT and design
• In order to guide the design process, designers need to think about the PACT elements
(introduced in Chapter 2).

• The people who will use the system are represented by personas: profiles of the different
types, or archetypes, of people the designer is designing for.

• Activities and the contexts in which they will occur are envisioned through scenarios of
use.

• Different concrete scenarios can be used to envision how different technologies (hardware
and software) could function to achieve the overall purpose of the system and deliver a
good UX.

• Personas and scenarios are developed early in the design process, using any of a wide
range of methods of understanding and ideation and through undertaking a PACT
analysis.

• Almost inevitably, personas and scenarios evolve together as thinking about people
involves thinking about what they want to do, and thinking about activities involves
thinking about who will be undertaking them!
Figure 3.1
The double diamond model
Our view of UX design
• We characterize the overall design process in terms of the four
activities understanding, envisionment, design and
evaluation:
– Evaluation is central to designing interactive systems.
Everything gets evaluated at every step of the process.
– The process can start at any point – sometimes there is a
conceptual design in place, sometimes we start with a
prototype and sometimes we start with requirements.
– The activities can happen in any order, for example
requirements might be evaluated, a prototype might be built
and evaluated and some aspect of a physical design might
then be identified.
Understanding
• Understanding is concerned with what the system
has to do, what it has to be like and how it has to fit
in with other things, with the requirements of the
product, system or service.
• Designers need to research the range of people,
activities and contexts relevant to the domain they
are investigating so that they can understand the
requirements of the system they are developing.
• They need to understand the opportunities and
constraints provided by technologies.
Requirements
• There are both functional and non-functional requirements to consider.
• Functional requirements are concerned with what the system should be
able to do and with the functional constraints of a system.
• It is important for the designer to think about the whole interaction
experience in an abstract way.
• Deciding who does what, when something should be displayed or the
sequence in which actions are undertaken should come later in the
design process.
• Of course, there are always functional constraints – the realities of what
is technically possible – which render certain ordering, sequencing and
allocation of functions inevitable.
• There are also logical and organizational constraints that may make
particular designs infeasible.
Defining requirements
• Requirements are generated through discussions and
interactions with people who will use or be affected by the
proposed system, the stakeholders.
• Requirements are also generated through observations of
existing systems, research into similar systems, what
people do now and what they would like to do.
• Requirements can be generated through working with
people in focus groups, design workshops and so on,
where different scenarios can be considered.
• The aim is to collect and analyse the stories people
have to tell. Requirements are essentially about
understanding.
Stakeholders
• Stakeholders is a term that refers to all the people who will be affected by
any systems that results from the process of interactive systems design.
• This includes the people who will finish up using the new system
(sometimes called the ‘users’) but it also includes many other people.
• For example, the organization that the system is being designed for will
probably have many people in it that will not be using the system but will be
affected by it as it might change their job.
• There may be stakeholders outside the organization such as government
authorities that need to verify some procedures.
• An important part of the understanding process is to consider all the
different stakeholders and how they might be affected and to decide who
should be involved in discussions about the design.
Conceptual design
• Design activities concern both conceptual design and physical design.
• Conceptual design is about designing a system in the abstract and
physical design is concerned with making things concrete.
• Conceptual design is about considering what information and functions
are needed for the system to achieve its purpose.
• It is about deciding what someone will have to know to use the system.
• It is about finding a clear conceptualization of a design solution and how
that conceptualization will be communicated to people (so that people
will quickly develop a clear mental model).
• The key feature of conceptual design is to keep things abstract – focus
on the ‘what’ rather than the ‘how’ – and to avoid making assumptions
about how functions and information will be distributed.
• There is no clear-cut distinction between conceptual and physical design
but rather there are degrees of conceptuality.
Techniques to help with conceptual
design
• Software engineers prefer modeling possible
solutions with objects, relationships and ‘use cases’
(a semi-formal scenario representation).
• Entity–relationship models are another popular
conceptual modeling tool.
• Flow can be represented using dataflow diagrams
and structure can be shown with structure charts.
• The conceptual design of a website, for example, will
include a site map and a navigation structure.
• Many different conceptual models are used in the
contextual inquiry method.
Rich Pictures (1 of 2)

Source: After Monk, A. and Howard, S. (1998) Methods & Tools: the rich picture: a tool for reasoning about work context, Interactions , 5(2), pp. 21–30. © 1998 ACM, Inc. Reprinted by
permission
Rich Pictures (2 of 2)
• A rich picture captures the main conceptual relationships amongst the
main conceptual entities in a system – a model of the structure of a
situation. Peter Checkland, who originated the soft systems approach,
also emphasizes focusing on the key transformation of a system.
• The principal stakeholders – customers, actors and system owners –
should be identified.
• The designer should also consider the perspective from which an activity
is being viewed as a system (the Weltanschauung) and the environment
in which the activities take place.
• Checkland proposes the acronym CATWOE – customers, actors,
transformation, Weltanschauung, owners, environment – for these
elements of a rich picture.
• Most importantly, the rich picture identifies the issues or concerns of the
stakeholders, thus helping to focus attention on problems or potential
design solutions.
Physical design
• Physical design is concerned with how things are going to work and with
detailing the look and feel of the product.
• Physical design is about structuring interactions into logical sequences and
about clarifying and presenting the allocation of functions and knowledge
between people and devices.
• The conceptual design relates to the overall purpose of the whole interactive
system.
• Between the people and the technologies, there has to be enough knowledge
and ability to achieve the purpose.
• Physical design is concerned with taking this abstract representation and
translating it into concrete designs.
• On one side this means requirements for hardware and software and on the
other side it defines the knowledge, tasks and activities that people will be
required to do.
• The three components are operational design, representational design and
design of interactions.
Operational design
• Operational design is concerned with specifying how
everything works and how content is structured and
stored.
• Taking a functional view of an activity means focusing on
processes and on the movement, or flow, of things
through a system.
• Events are occurrences that cause, or trigger, some other
functions to be undertaken.
• For example, some activity might be triggered on a
particular day or at a particular time.
• Another might be triggered by the arrival of a person or
document.
Representational design
• Representational design is concerned with fixing on
colours, shapes, sizes and information layout.
• It is concerned with style and aesthetics and is
particularly important for issues such as the attitudes
and feelings of people but also for the efficient
retrieval of information.
• Style concerns the overall ‘look and feel’ of the
system.
• For example, most Microsoft products engender an
‘office’ and ‘work’ mood, serious rather than playful.
Interaction design
• Interaction design, in this context, is concerned with the allocation of
functions to human agency or to technology and with the structuring and
sequencing of the interactions.
• Allocation of functions has a significant impact on how easy and enjoyable a
system is to use.
• Designers create tasks for people by the way they allocate functions.
• For example, consider the activity of making a phone call. Conceptually
speaking, certain functions are necessary: indicate a desire to make a phone
call, connect to the network, enter the phone number and make connection.
• Years ago a telephone exchange was staffed by people and it was these
people who made connections by physically putting wires into connectors.
• Nowadays a person just has to press the connect button on a cellular phone,
choose someone’s name from the phone’s address book and the technology
does the rest.
• The allocation of knowledge and activities between people and technologies
is a significant part of how experiences change over time.
Envisionment
• Designs need to be visualized both to help designers clarify their
own ideas and to enable people to evaluate them.
• Envisionment is concerned with finding appropriate media to render
design ideas.
• The medium needs to be appropriate for the stage of the process,
the audience, the resources available and the questions that the
designer is trying to answer.
• There are many techniques for envisionment but they include any
way in which abstract ideas can be brought to life.
• Sketches ‘on the back of an envelope’, fully functioning prototypes
and cardboard mock-ups are just some of the methods used.
• Scenarios, sometimes represented in pictorial form as storyboards,
are an essential part of prototyping and envisionment.
Evaluation
• Evaluation is tightly coupled with envisionment because the
nature of the representation used will affect what can be
evaluated.
• The evaluation criteria will also depend on who is able to use the
representation.
• Sometimes, this is simply the designer checking through to make
sure something is complete and correct.
• It could be a list of requirements or a high-level design brief that
is sent to a client, an abstract conceptual model that is discussed
with a colleague or a formal evaluation of a functional prototype
by the future system users.
• Techniques for evaluation are many and various depending once
again on the circumstances.
Implementation
• Ultimately, things have to be engineered and software has
to be written and tested.
• Databases have to be designed and populated and
programs have to be validated.
• The whole system needs to be checked to ensure that it
meets the requirements until finally the system can be
formally ‘launched’ and signed off as finished.
• Clients will often want extra features when they see a
system nearing completion but these will have to be costed
and paid for.
• On the other hand, the developers need to ensure that their
system really does meet the specification and does not
contain any ‘bugs’.
 UX and formal methods
• If UX designers were architects, they would have well-understood
methods and conventions for specifying the results of the design
process.
• They would produce various blueprints from different elevations
and engineering specifications for particular aspects of the design.
• In UX, there are a variety of formal, semi-formal and informal
methods of specification.
• The best known of the formal methods is the Unified Modeling
Language (UML) (Pender, 2003).
• Over the past few years, there has been a move away from large
software engineering approaches to the development of
interactive systems towards ‘agile’ development methods.
Agile development
• There are a number of competing methods for agile
development.
• Probably the best known comes from Dynamic Systems
Development Method (DSDM), a not-for-profit
consortium of software development companies.
• Their system, called Atern, is fully documented, showing
how software can be developed in small teams.
• Another is eXtreme programming (XP, Beck and Andres,
2004).
• However, in reality, most organizations develop their own
version of agile development.
 An agile approach
• The approach is aimed at design teams developing interactive services or products.

• A project will be divided into manageable periods of work (typically 2 weeks long)
known as ‘sprints’.

• Meetings of the design team are held at the beginning of each week in order to agree what
should be produced during the sprint and to measure progress. These ‘scrums’ or ‘huddles’
are intended to develop a good team spirit and to ensure that everyone knows what they
should be doing and what other members of the team are doing.

• The aim is to quickly produce a minimum viable product (MVP). This is a version of the
product or service that does just enough to meet its purpose.

• It can then be evaluated and tested by users. This may result in further development or it
becomes version 1 of the product or service.

• Additional features can be added through further developments and subsequent versions can
be developed and deployed.

• Indeed, it is quite common in interaction design for regular updates of an app or web service to
be produced over time.

• Agile development methods are quite compatible with the four activities in our design
process and with the approach based on developing scenarios and personas.
Developing personas
• Personas are concrete representations of the different
types of people that the system or service is being
designed for.
• Alan Cooper introduced the idea of personas in the late
1990s (Cooper, 1999) and they have gained rapid
acceptance as a way of capturing knowledge about the
people the system or service is targeted at.
• Personas want to be able to do things using your system.
• They want to achieve their aims.
• They want to undertake meaningful activities using the
system or service that the designer will produce.
Using personas (1 of 2)
• In the development of personas, it is important to include the
aspirations of potential users as well as looking at more functional
aspects.
• Personas should help shape the whole UX and people will have an
emotional response to a product or service as well as a response
based on pragmatic qualities.
• Thus, designing for pleasure is important and the UX designer needs
to consider the hedonic qualities of products and services.
• Designers also need to recognize that they are not designing for
themselves.
• Designers create personas so that they can envisage whom they are
designing for.
Using personas (2 of 2)
• As any new system is likely to be used by different types of
people, it is important to develop several different personas.
• For example, in designing a website for people interested in
the author Robert Louis Stevenson (described in more detail in
Chapter 14), we developed personas for a school teacher in
Germany, a university lecturer from the United Kingdom, a
child in Africa and a Stevenson enthusiast from the United
States of America.
• Such a diverse group of people have very different goals and
aspirations and differ in all the ways we discussed when
discussing PACT – physically, psychologically and in terms of
the usage they would make of the site (see Chapter 2).
Defining personas
• There is no agreed standard for defining and documenting personas.
• Cooper et al. (2007) emphasize the different types of goals that
people have — experience goals, end goals and life goals — that
should be represented in the personas that are developed.
• By looking at the variety of these (as we suggest looking at the
variety through PACT analysis), designers can identify the various
behavior patterns that different personas may demonstrate.
• There is a very good in-depth treatment of personas by Pruitt and
Aldrin (2006) and some excellent advice and useful templates from a
number of practitioners.
• There are many templates promoted by UX design agencies freely
available on the internet. The one shown in Figure 3.4 is taken from
Mattias Arvola.
Example persona template
Critiquing personas
• Of course, the use of personas is not without its critics
and it is important that designers do not fall foul of simply
creating stereotyped personalities or create personas that
are just like themselves or their ideal partner!
• Persona development should be agile and subject to
change and should focus on the UX aspects of
interaction, rather than other aspects such as marketing.
• In our examples here, the personas include snippets of
the main scenarios (see section 3.3).
• As we said earlier, it is difficult to think about personas
without thinking about what activities they might want to
do and why they want to do them.
Developing scenarios
• Scenarios are stories about people undertaking
activities in contexts using technologies.
• They appear in a variety of forms throughout
interactive systems design and are a key
component of many approaches to design.
• Scenarios have been used in software
engineering, interactive systems design and
human–computer interaction work for many
years.
• More recently, scenario-based design has
emerged as an important approach to the design
of interactive systems in the twenty-first century.
Five key problems of design (from
Carroll)
• The external factors that constrain design are time constraints, lack of
resources, having to fit in with existing designs and so on.
• Design moves have many effects and create many possibilities, that
is, a single design decision can have an impact in many areas and these
need to be explored and evaluated.
• How scientific knowledge and generic solutions lag behind specific
situations? This point concerns generalities. In other design disciplines,
general design solutions to general design problems have evolved over
the years. In interactive systems design, this does not happen because
the technology changes as soon as, or even before, general solutions
have been discovered.
• The importance of reflection and action in design is also a concern.
• The slippery nature of design problems needs to be considered.
Figure 3.7
Challenges and approaches in scenario-based design

Source: After John M. Carroll. Making Use: Scenario-based Design of Human-Computer Interactions. Fig. 3.2, p. 69 © 2000 Massachusetts Institute
of Technology, by permission of The MIT Press
Motivations
• One central theme of the explorations concerned the motivational
approaches that would be suitable for different scenarios and
personas.
• The Sandy persona would need more encouragement and
persuasion to exercise than the Mari persona perhaps by preventing
a recorded television program from being shown until training is
completed.
• Another aspect, concerning social networking, was explored through
the Bjorn persona.
• Thus the personas were developed to reflect particular design issues
and values.
• The whole issue of persuasion technologies is a difficult one for
interaction design.
Captology
• The basic aim of captology is to persuade people to do things they otherwise would not
do.

• Who are we, as designers, to persuade people to do something they don’t want to do.

• However, we can see examples, such as the Sandy persona, where persuading him to
exercise is for his own good.

• We also need to persuade people to take precautions if things are dangerous.

• I am quite happy that a software system persuaded me to save my work before the
system crashes (on the other hand why did the system not just save it for me?).

• Persuasion is ‘a non-coercive attempt to change attitudes or behaviors of people’

(Fogg, Cuellar and Danielson, 2008).

• However, if this is persuading me to buy something that I cannot afford, then it is not
good at all, whether it is non-coercive or not.

• This is an area of HCI where ethics and values must be taken seriously.
Environment
• In another scenario, we were looking at
environmental influence on the interaction.
• Small displays (e.g. digital photo frames) have a
more limited touch capability than a larger
display.
• Using a display that is simply too far from the
person to be touched.
 Using scenarios throughout design
• Scenarios (and their associated personas) are a core technique for
interactive systems design.
• They are useful in understanding, envisioning, evaluation and both
conceptual and physical design: the four key stages of interactive
system design.
• We distinguish four different types of scenario: stories, conceptual
scenarios, concrete scenarios and use cases.
• Stories are the real-world experiences of people.
• Conceptual scenarios are more abstract descriptions in which some details have
been stripped away.
• Concrete scenarios are generated from abstract scenarios by adding specific design
decisions and technologies and once completed these can be represented as use
cases.
• Use cases are formal descriptions that can be given to programmers.
Scenarios throughout design
Scenarios at different stages
• At different stages of the design process, scenarios are helpful in
understanding current practice and any problems or difficulties that
people may be having, in generating and testing ideas, in
documenting and communicating ideas to others and in evaluating
designs.
• Many stories will be represented by a few conceptual scenarios.
However, each conceptual scenario may generate many concrete
scenarios.
• Several concrete scenarios will be represented by a single use case.
• Designers abstract from the details of stories to arrive at conceptual
scenarios.
• They specify design constraints on conceptual scenarios to arrive at
concrete scenarios.
• Finally, they formalize the design ideas as use cases.
Stories
• Stories are the real-world experiences, ideas, anecdotes
and knowledge of people.
• These may be captured in any form and comprise small
snippets of activities and the contexts in which they occur.
• This could include videos of people engaged in an
activity, diary entries, photographs, documents, the
results of observations and interviews and so on.
• People’s stories are rich in context.
• Stories also capture many seemingly trivial details that
are usually left out if people are asked to provide more
formal representations of what they do.
Conceptual scenarios
• Conceptual scenarios are more abstract than stories.
• Much of the context is stripped away during the process
of abstraction and similar stories are combined together.
• Conceptual scenarios are particularly useful for
generating design ideas and for understanding the
requirements of the system.
• Once the designer has accumulated a collection of
stories, common elements will start to emerge.
• In this case, a number of stories such as the one above
result in the conceptual scenario below describing some
requirements for a computerized appointments system.
Abstraction
• The process of abstraction is one of the classifications and aggregations: moving
from the details of specific people undertaking specific activities in a specific
context using a particular piece of technology to a more general description that
still manages to catch the essence of the activity.
• Aggregation is the process of treating a whole thing as a single entity rather than
looking at the components of something.

• In most domains, for example, one would aggregate a screen, processor, disc
drive, keyboard and mouse and treat this as a single thing – a computer – rather
than focusing on the components.
• Classification is the process of recognizing that things can be collected together
so that dealing with the class of things is simpler (more abstract) than dealing
with the individual things.
• There are no set ways to classify things, so the analyst has to work with the
stories that have been gathered and with the users themselves to decide which
things belong together and why.
• Between them aggregation and classification produce abstractions.
Degrees of abstraction
• there are different degrees of abstraction and it is one of the skills of
a designer to settle upon an appropriate level.
• Example: Booking an appointment: People with any degree of basic
computer skills will be able to contact the doctors’ surgery at any time
via the internet and see the times which are free for each doctor.
They can book a time and receive confirmation of the appointment.
• As you can see, at this stage, there is little or no specification of
precise technologies or how the functions will be provided.
• The scenario could be made more abstract by not specifying that the
internet should be used or more concrete (that is less abstract) by
specifying that the booking should be made from a computer rather
than a mobile phone.
• Finding an appropriate level of abstraction at which to describe things
for a given purpose is a key skill of the designer.
Concrete scenarios
• Each conceptual scenario may generate lots of concrete scenarios.
• When designers are working on a particular problem or issue, they will often
identify some feature that applies only under certain circumstances.
• At this point, they may develop a more specific elaboration of the scenario
and link it to the original.
• Thus, one reasonably abstract scenario may spawn several more concrete
elaborations which are useful for exploring particular issues.
• Concrete scenarios also begin to dictate a particular interface design and a
particular allocation of functions between people and devices.
• Concrete scenarios are particularly useful for prototyping and envisioning
design ideas and for evaluation because they are more prescriptive about
some aspects of the technology.
• However, there is not a clean break between conceptual and concrete
scenarios.
• The more specific the scenario is about some aspects, the more concrete it
is.
Concrete scenarios: Example
• In the example below, decisions have now been taken concerning drop-down menus,
the fact that the next two weeks’ details are to be shown and so on. However, the
notes following the scenario show that there are many design decisions still to be
taken.
• Booking an appointment/01:
– Andy Dalreach needs a doctor’s appointment for his young daughter Kirsty in the
next week or so. The appointment needs to be outside school time and Andy’s
core working hours, and ideally with Dr Fox, who is the children’s specialist. Andy
uses a PC and the internet at work so has no difficulty in running up the
appointments booking system. He logs in [1] and from a series of drop-down
boxes chooses to have free times for Dr Fox [2] displayed for the next two weeks
[the scenario would continue to describe how Andy books the appointment and
receives confirmation].
• Notes to booking an appointment/01:
– Is logging in necessary? Probably, to discourage bogus access to the system but
check with the surgery, logging is necessary.
– Free times can be organized by doctor, by time of day or by the next available
time. Drop-down boxes will save screen space but may present problems for less
experienced users or those with poor eyesight.
Use cases
• A use case describes the interaction between people (or other ‘actors’) and
devices.
• It is a case of how the system is used and hence needs to describe what
people do and what the system does.
• Each use case covers many slight variations in circumstances – many
concrete scenarios.
• Before use cases can be specified, tasks and functions have to be allocated
to humans or to the device.
• The specification of use cases both informs and is informed by the
task/function allocation process.
• A set of use cases can be produced which specify the complete functionality
of the system and the interactions that will occur.
• There are a number of different ways of representing use cases – from very
abstract diagrams to detailed ‘pseudo code’.
Use cases
A scenario-based design method
• The use of the different types of scenarios throughout
design can be formalized into a scenario-based design
method.
• Besides the four different types of scenario, four other
artefacts are produced during the design process:
– Requirements/Problems
– Scenario corpus
– Object model
– Design language.
• The specification of a system is the combination of all the
different products produced during the development
process.
A scenario-based design method

Clouds are processes

Boxes are things produced
Scenarios through design
• An important thing to notice is the relationship between specifying
design constraints and the use of scenarios.
• For envisionment and most evaluation, the scenarios have to be
made more concrete.
• This means imposing design constraints.
• However, this does not mean that the designer needs to design a
new physical, concrete scenario each time he or she wants to
envision a possible design.
• It may be that designers imagine a scenario with particular design
constraints imposed and this helps them evaluate the design.
• This sort of ‘what if?’ generation and evaluation of concrete scenarios
is a common and key aspect of design.
Requirements and problems
• In the gathering of people’s stories and during the analysis and
abstraction process, various issues and difficulties will come to light.
• These help the analyst/designer to establish a list of requirements –
qualities or functions that any new product or system should have.
• For example, in the HIC example, the device has to be used by the
elderly and short-sighted.
• Another requirement was that it should look good in a living room and
should not look or behave like a personal computer running Microsoft
Windows.
• The format of the requirements and problems is a prioritized list of
issues, or a more formalized format.
Scenario corpus
• In our approach, we seek to develop a representative and
carefully thought-through set, or corpus, of scenarios.
• Having undertaken some analysis activities, designers will have
gathered a wide range of user stories.
• Some of these will be very general and some will be quite specific.
• Some will be fairly simple, straightforward tasks; others will be
more vague.
• It is important at some point for the designer to pull these
disparate experiences together in order to get a high-level,
abstract view of the main activities that the product is to support.
• These conceptual scenarios will often still be grounded in a real
example; the trick is to find an example that shares characteristics
with a number of other activities.
 Domain characteristics
• The rationale for the development of a corpus of scenarios is to uncover the
‘dimensions’ of the design situation and to demonstrate different aspects of
those dimensions.
• Dimensions include characteristics of the various domains within which the
product will operate (e.g. large and small domains, volatile or static domains
and so on), the various media and data types that need to be accommodated
and the characteristics of the people who will be using the system.
• The corpus of scenarios needs to cover all the main functions of the system
and the events that trigger the functions.
• The dimensions include different types of content and how that can be
structured, issues of style and aesthetics.

• The aim is to specify the scenarios at a level of abstraction that captures an

appropriate level of generality that will be useful across the range of
characteristics that is demonstrated within a domain.
Conceptual model
• An object or data model results from the process of conceptual modeling,
including developing the scenarios and undertaking an object/action
analysis of the scenario corpus.
• The conceptual model shows the main objects in the system, their
attributes and the relationships that exist between them.
• Conceptual modeling is a very important part of interactive systems
design that is often overlooked.
• Having a clear, well-designed conceptual model will make it easier to
design so that people can develop a good, accurate mental model of the
system.
• The conceptual model will also form the basis of the information
architecture of a system and for any metaphor that is used in the design.
• Two famous conceptual models are the concept of the spreadsheet and
the various objects such as printers, folders, documents, etc. that make
up the ‘desktop’ metaphor of the Windows and Mac OS operating
systems.
Design language
• The design language produced consists of a set of standard
patterns of interaction and all the physical attributes of a
design – the colours, shapes, icons and so on.
• These are brought together with the conceptual actions and
objects and the ‘look and feel’ of the design is completed.
• A ‘design language’ defines the key elements of the design
(such as the use of colour, style and types of buttons, sliders
and other widgets and so on) and some principles and rules
for putting them together.
• A consistent design language means that users need to
learn only a limited number of design elements and then they
can cope with a large variety of different situations.
 Documenting scenarios
• Scenarios can become messy, so in order to control the scenarios, a structure is
needed.
• We use the PACT framework (people, activities, contexts, technologies) to
critique scenarios and to encourage designers to get a good description of the
scenario.
• For each scenario, the designer lists the different people who are involved, the
activities they are undertaking, the contexts of those activities and the
technologies that are being used.
• We also structure scenario descriptions. Each scenario should be given an
introduction.
• The history and authorship can be recorded, along with a description of how the
scenario generalizes (across which domains) and the rationale for the scenario.
• Each paragraph of each scenario should be numbered for ease of reference and
endnotes included where particular design issues are raised.
• Endnotes are particularly useful in documenting issues raised during the
development of the scenario. They are a way of capturing the claims being
made about the scenarios.
• Examples of relevant data and media should be collected.
Trade-offs
• Rosson and Carroll (2002) describe an approach to scenario-based design in
which scenarios are used throughout the design process and how they help
designers to justify the claims that they make about design issues.
• Design is characterized by trade-offs.
• There is rarely a simple solution to a problem that solves all the issues.
• Usually the adoption of one design will mean that something else cannot be
achieved.
• Designers need to document their design decisions so that the trade-offs can
be evaluated.
• Scenarios help by making the rationale for the design explicit.
• Designers can record the claims that they make about their designs.
Claims analysis
• Claims analysis is an important part of scenario-based
design and is used in identifying problems or in thinking
through possible future designs (Rosson and Carroll, 2002).
• The process is simply to identify key features of a scenario
and to list good and bad aspects of the design.
• Rosson and Carroll use a technique of putting a ‘+’ beside
good features and a ‘−’ beside bad features.
• Claims analysis makes the rationale behind a design
explicit.
• A similar method is to list the design Questions, design
Options and Criteria used to make choices, the QOC
method.
Claims analysis
Summary
• The design of interactive systems is concerned with people, the activities
they are undertaking, the contexts of those activities and the technologies
that are used.
• This presentation has introduced the main elements of design –
understanding, envisionment, design and evaluation and how scenario-
based design and the development of personas can be used to guide the
designer.
• Scenarios and their different uses in this process have been explored.
• Scenarios are stories about the interactions amongst people, activities,
contexts and technologies.
• Scenarios offer an effective way of exploring and representing activities,
enabling the designer to generate ideas, consider solutions and
communicate with others.
• Scenarios are used throughout the design process and, as use cases, form
part of the formal specification of the system.
Question & Answers