For example, if we are designing a wireless personal

movie player, we may think about young affluent

users wanting to watch the latest movies while on the
move and download free copies, and perhaps
wanting to share the experience with a few friends.

What materials must we use? What standards must

we adopt? How much can it cost? How much time do
we have to develop it? Are there health and safety
issues? In the case of the personal movie player: does
it have to withstand rain? Must we use existing video
standards to download movies? Do we need to build
in copyright protection?

Choosing which goals or constraints can be relaxed so that

others can be met. For example, we might find that an eye-
mounted video display, a bit like those used in virtual
reality, would give the most stable image whilst walking
along. However, this would not allow you to show friends,
and might be dangerous if you were watching a gripping
part of the movie as you crossed the road
Part of the understanding we need is about the circumstances
and context of the particular design problem. However, there
are also more generic concepts to understand. The designs we
produce may be different, but often the raw materials are the
same.
This is the core of interaction design: put the user first, keep
the user in the center and remember the user at the end.
Often HCI professionals complain that they are called in too late. A
system has been designed and built, and only when it proves unusable
do they think to ask how to do it right! In other companies usability is
seen as equivalent to testing – checking whether people can use it and
fixing problems, rather than making sure they can from the beginning.
In the best companies, however, usability is designed in from the start.
Of course, the answer is you can’t. Your time is limited
– there is a trade-off between the length of the design
period and the quality of the final design. This means
one sometimes has to accept a design as final even if
it is not perfect: it is often better to have a product
that is acceptable but on time and to cost than it is to
have one that has perfect interaction but is late and
over budget.

As you experience real designs, however, you soon

find that the real problem is not to find faults – that is
easy; nor to work out how to fix them – that may not
be too difficult; instead the issue is: which usability
problems is it worth fixing?

If you ever come across a system that seems to be

perfect it is a badly designed system – badly designed
not because the design is bad, but because too much
effort will have been spent in the design process itself.
Just as with all tradeoffs, it may be possible to find
radically different solutions that have a major effect
but are cheap to implement.
Are they young or old, experienced computer users or novices? As we
saw with the stock control system, it may not be obvious who the users
are, so you may need to ask this question again as you find out more
about the system and its context. This question becomes harder to
answer if you are designing generic software, such as a word processor,
as there are many different users with different purposes and
characteristics. A similar problem arises with many websites where the
potential visitors are far from homogenous. It may be tempting to try
to think of a generic user with generic skills and generic goals;
however, it is probably better, either instead or in addition, to think of
several specific users.
When designing a system it is easy to design it as if you were the main
user: you assume your own interests and abilities. So often you hear a
designer say ‘but it’s obvious what to do’. It may be obvious for her! This is
not helped by the fact that many software houses are primarily filled with
male developers. Although individuals differ a lot there is a tendency for
women to have better empathetic skills.
This can take many forms: structured interviews about their job or life, open-
ended discussions, or bringing the potential users fully into the design
process. The last of these is called participatory. By involving users
throughout the design process it is possible to get a deep knowledge of their
work context and needs. Recall that a system must be not only useful and
usable, but also used.
Although what people tell you is of the utmost importance, it is not the
whole story. Because of this it is important to watch what people do as well
as hear what they say. This may involve sitting and taking notes of how they
spend a day, watching particular activities, using a video camera or tape
recorder. Another way to find out what people are doing is to look at the
artifacts they are using and creating. Look at a typical desk in an office. There
are papers, letters, files, perhaps a stapler, a computer, sticky notes... Some
of these carry information, but if they were only important for the
information in them they could equally well be in the filing cabinet and just
taken out when needed.
Even if you would like to involve many users throughout your design
exercise this will not always be possible. It may be too costly, it may be hard
to get time with them, it may be that there are just too many (e.g. the
web). However, even if you cannot involve actual users you can at least try
to imagine their experiences.
Cultural probes are small packs of items designed to provoke and record comments in various ways.
They are given to people to take away and to open and use in their own environment. For example,
one probe pack for the domestic environment includes a glass with a paper sleeve. You use the glass
to listen to things and then write down what you hear. The same probe pack contains a repackaged
disposable camera and a small solid-state voice recorder. When the packs are returned, the notes,
recordings, photos, etc., are used as a means of understanding what is significant and important for
the people in the environment and as a means of enculturing designers.
 Scenarios are stories for design: rich stories of interaction. They are perhaps
the simplest design representation, but one of the most flexible and
powerful. Some scenarios are quite short: ‘the user intends to press the
“save” button, but accidentally presses the “quit” button so loses his work’.
Others are focused more on describing the situation or context.
In addition scenarios can be used to:
• Communicate with others – other designers, clients or users. It is easy to
misunderstand each other whilst discussing abstract ideas. Concrete
examples of use are far easier to share.
• 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..
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. We are natural storytellers
and story listeners.
• 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.
interact at several levels
Much of interaction involves goal-seeking
behavior. Users have some idea of what they are
after and a partial model of the system.
In an ideal world if users had perfect knowledge of what
they wanted and how the system worked they could simply
take the shortest path to what they want, pressing all the
right buttons and links. However, in a world of partial
knowledge users meander through the system.
The important thing is not so
much that they take the most
efficient route, but that at each
point in the interaction they can
make some assessment of
whether they are getting closer to
their goal.
Here are four things to look for when looking at a
single web page, screen or state of a device.

in terms of the interaction or state of the system

what can be pressed or clicked to go

somewhere or do something

Sort of confirmation of what you’ve done. If you

are faultless and have perfect knowledge, of
course you will be sure that you have hit the
right key and know exactly what will happen.
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.
Any sort of information structuring is difficult, but
there is evidence that people find hierarchies simpler
than most. One of the difficulties with organizing
information or system functionality is that different
people have different internal structures for their
knowledge, and may use different vocabulary.

Many guidelines suggest that menu breadth, that is the

number of choices available at each level in the menu,
should be around seven. However, Miller’s result
applies only to working memory, not visual search.
In HCI the word ‘dialog’ is used to refer to this pattern of interactions between
the user and a system. Consider the following fragment from a marriage service:
A simple way is to use a network diagram showing the principal states or screens
linked together with arrows. This can show:

and loops
 This has several implications:

We should normally conform to platform standards, such as positions for menus on a PC

application, to ensure consistency between applications. For example, on our proposed
personal movie player we should make use of standard fast-forward, play and pause
icons.

On a PC application we need to be able to interact with files, read standard formats

and be able to handle cut and paste.

We may need to support linkages between applications, for example allowing the
embedding of data from one application in another, or, in a mail system, being able to
double click an attachment icon and have the right application launched for the
attachment.
The basic principles at the screen level reflect those in
other areas of interaction design:

-- What information is required? What comparisons may the

user need to make? In what order are things likely to be
needed?

-- Form follows function: let the required interactions drive

the layout.
If things logically belong together,
then we should normally physically
group them together. This may
involve multiple levels of structure.
For example, in the figure, we can
see a potential design for an
ordering screen. Notice how the
details for billing and delivery are
grouped together spatially; also
note how they are separated from
the list of items actually ordered by
a line as well as spatially.
If we look at the figure again we
can see that the screen seems to
naturally suggest reading or filling
in the billing details first, followed
by the delivery details, followed
by the individual order items. Is
this the right order? In general we
need to think: what is the natural
order for the user? This should
normally match the order on
screen. For data entry forms or
dialog boxes we should also set
up the order in which the tab key
moves between fields.
Occasionally we may also want to
force a particular order; for
example, we may want to be sure
that we do not forget the credit
card details!
Again, looking at the figure, we can
see how the design uses boxes and a
separating line to make the grouping
clear. Other decorative features like
font style, and text or background
colors can be used to emphasize
groupings.
Alignment of lists is also very
important. For users who read
text from left to right, lists of
text items should normally be
aligned to the left. Numbers,
however, should normally be
aligned to the right (for
integers) or at the decimal
point. This is because the
shape of the column then gives
an indication of magnitude – a
sort of mini histogram.
Consider list (i) in the figure. It
is clearly hard to look someone
up if you only know their
surname. To make it easy, such
lists should be laid out in
columns as in (ii), or have
forename and surname
reversed as in (iii).
lines of dots linking the
columns
using soft tone grays or colors
behind rows or columns

This last alternative might be a good

solution if you were frequently
scanning the numbers and only
occasionally scanning the names of
items, but not if you needed
frequently to look up names (which
anyway are not sorted in this figure!).
In typography the space between the letters is called the counter. In painting this is also
important and artists may focus as much on the space between the foreground elements
such as figures and buildings as on the elements themselves. Often the shape of the counter
is the most important part of the composition of a painting and in calligraphy and
typography the balance of a word is determined by giving an even weight to the counters. If
one ignores the ‘content’ of a screen and instead concentrates on the counter – the space
between the elements – one can get an overall feel for the layout. If elements that are
supposed to be related look separate when you focus on the counter, then something is
wrong. Screwing up your eyes so that the screen becomes slightly blurred is another good
technique for taking your attention away from the content and looking instead at the broad
structure.
 Space can be used in several ways. Some of
these are shown in the following figures. The
colored areas represent continuous areas of
text or graphics.

We can see space used to separate blocks as There are clearly four main areas: ABC,
you often see in gaps between paragraphs or D, E and F. Within one of these are three
space between sections in a report. Space can further areas, A, B and C, which
also be used to create more complex themselves are grouped as A on its own,
structures. followed by B and C together.
Space can be used in several ways. Some of
these are shown in the following figures. The
colored areas represent continuous areas of
text or graphics.

We can see space used to highlight. This is

a technique used frequently in magazines
to highlight a quote or graphic.
Some of the most complicated and difficult screen layouts are found in forms-based interfaces
and dialog boxes. In each case the screen consists not only of information presented to the
user, but also of places for the user to enter information or select options. Actually, many of the
same layout issues for data presentation also apply to fields for data entry. Alignment is still
important. It is especially common to see the text entry boxes aligned in a jagged fashion
because the field names are of different lengths. This is an occasion where right-justified text
for the field labels may be best or, alternatively, in a graphical interface a smaller font can be
used for field labels and the labels placed just above and to the left of the field they refer to.
Some elements of a screen are passive, simply giving you information; others are active,
expecting you to fill them in, or do something to them. It is often not even clear which
elements are active, let alone what the effect is likely to be when you interact with them!
This is one of the reasons for platform and company style guides. If everyone designs
buttons to look the same and menus to look the same, then users will be able to recognize
them when they see them. However, this is not sufficient in itself. It is important that the
labels and icons on menus are also clear.
How are users supposed to know where to click? The psychological idea of affordance says
that things may suggest by their shape and other attributes what you can do to them: a
handle affords pulling or lifting; a button affords pushing. These affordances can be used
when designing novel interaction elements. One can either mimic real-world objects
directly, or try to emulate the critical aspects of those objects. What you must not do is
depict a real-world object in a context where its normal affordances do not work! Note also
that affordances are not intrinsic, but depend on the background and culture of users.
The way of presenting information on screen depends on the kind of information: text,
numbers, maps, tables; on the technology available to present it: character display, line
drawing, graphics, virtual reality; and, most important of all, on the purpose for which it is
being used.
Remember that a pretty interface is not necessarily a good interface. Ideally, as with any
well-designed item, an interface should be aesthetically pleasing. Indeed, good graphic
design and attractive displays can increase users’ satisfaction and thus improve
productivity.
One of the worst features in many interfaces is their appalling use of color. This is partly
because many monitors only support a limited range of primary colors and partly because,
as with the overuse of different fonts in word processors, the designer got carried away.
Aside from issues of good taste, an overuse of color can be distracting and, remembering
that a significant proportion of the population is color blind, may mean that parts of the
text are literally invisible to some users. In general, color should be used sparingly and not
relied upon to give information, but rather to reinforce other attributes.
If you are working in a different country, you might see a document being word processed
where the text of the document and the file names are in the local language, but all the
menus and instructions are still in English. The process of making software suitable for
different languages and cultures is called localization or internationalization.
Prototyping is an example of what is known as a hill-climbing approach. Imagine you are
standing somewhere in the open countryside. You walk uphill and keep going uphill as
steeply as possible. Eventually you will find yourself at a hill top. This is exactly how
iterative prototyping works: you start somewhere, evaluate it to see how to make it better,
change it to make it better and then keep on doing this until it can’t get any better.
Hill climbing methods always have the potential to leave you somewhere that is the best in the
immediate area, but very poor compared with more distant places. The figure shows this
schematically: if you start at A you get trapped at the local maximum at B, but if you start at C you
move up through D to the global maximum at E. This problem of getting trapped at local maxima is
also possible with interfaces. If you start with a bad design concept you may end at something that
is simply a tidied up version of that bad idea!
From this we can see that there are two things you need in order for prototyping methods to work:
1. To understand what is wrong and how to improve.
2. 2. A good start point.
The first is obvious; you cannot iterate the design unless you know what must be done to improve
it. The second, however, is needed to avoid local maxima.
A really good designer might guess a good initial design based on experience and judgment.
However, the complexity of interaction design problems means that this insight is hard. Another
approach, very common in graphical design, is to have several initial design ideas and drop them
one by one as they are developed further.
We have seen that design in HCI is not just about creating
devices or software, but instead is about the whole
interaction between people, software and their
environment. Because of this it is good to see the product of
design not just as the obvious artifacts but as the whole
intervention that changes the existing situation to a new one.