Importance of improving usability
Introduction
The
Impetus for Change
The
Undesirable Effects of Poor Design
Conclusion
Introduction
Taken to the extreme, one example
to stress the importance of effective usability is that of the
fire extinguisher. In this scenario, the element of guessability
is cited. Jordan et al [1991] highlight that the guessability
to perform a task, such as using a fire extinguisher, "...is
particularly important [and that the user must perform it] correctly
at the first attempt without any previous knowledge of [it]".
It can be seen, therefore, that in this safety critical system
effective usability is paramount as it may actually save lives.
Not every system's usability goal
can be seen to be as important as this. I would suggest that designers
are now aware that usability should be higher on the list of priorities
rather than lower. Indeed, usability is a core feature of human
engineering which in turn Shneiderman [1992] comments "...was
seen as the paint put on at the end of a project, [but which]
is now understood to be the steel frame on which the structure
is built".
Usability must therefore, become
a significant player in the development of interactive systems.
The impetus behind this sea change is quite diverse. I will now
document some of the reasons for the designers' apparent change
of heart and will detail what happens if these necessities for
improving usability are not heeded.
The Impetus for Change
The IT Revolution
The motivation to involve humans
in the development of the "man-machine" interface [Grandjean
1988] has only just, relatively speaking, been acknowledged. The
massive strides the computer industry has undertaken over the
last 15 years or so have been based on generating more powerful
and intelligent machines. The first IBM PC, for example, was marketed
in 1981 for £2080 with 16KB (not MB!) of RAM, a mono screen and
a compact cassette storage unit [Personal Computer World 1996].
Compare this against the standard of today: Pentium 200Mhz processor,
32MB of RAM, 3D 4MB video card, soundcard, fax/modem and 12 speed
CD ROM. The standard also includes life time help desk advice
[Personal Computer World 1997] which is indicative of the shift
in emphasis from machine to human.
I would argue that the biggest single
factor to affect this swing towards the user is that Information
Technology (IT) now permeates into virtually every aspect of life,
from banking (debit cards) and shopping (bar code labels are now
common place) to playing squash (computer designed racquets) or
crossing the road (computer controlled traffic lights).
Initially computers were beasts
of mathematics and the first generation languages "were used
primarily for scientific and engineering applications" [Booch
1994]. Because of the way in which IT pervades society, it is
no longer the sole possession of a select few boffins but is at
the mercy of the population generally (or perhaps vice versa).
Holcomb & Tharp [1991] recognised this issue and consider
that for computers to "fulfil their potential, it is the
millions of potential users in primarily non-technical areas who
must be empowered to use them effectively".
The ultimate goal, I would put forward,
is to allow the design of interfaces and the understanding of
the user to catch up to the advances made in hardware and software,
otherwise the "excessive functionality" as noted by
Shneiderman [1992] would become "a danger... [making]...
usage more difficult"
The challenge can thus easily be
seen; how can such a diversity of tasks to be undertaken by such
a diversity of users be built into effective interactive designs?
As Shneiderman [1992] remarks "A clever design for one community
of users may be inappropriate for another". He continues
by suggesting that "an effective design for one class of
tasks may be ineffective for another class".
I suggest that the impetus for improving
the usability of systems is, therefore, driven by two main concerns.
Firstly, the massive and unprecedented expansion of new technology
into the automation of tasks that had previously been done manually.
The second is the growth of the ever increasing population of
naive users who have to do those tasks.
Economics Pressures
There are potential cost-benefits
from usability work. Baker cited in Booth [1992] estimates that
"people costs exceed machine costs in human computer interaction
for 95% of the time". This may seem a high figure but there
has been much research into this area to warrant serious consideration.
For example one project that was given a high profile was the
DTI sponsored programme 'usability now!' in which the benefits
of investing into usability issues were raised to the business
community [NPL 1997a and Shaw 1997] .
Health and Safety Regulations
With the increase in the general
awareness of usability issues over the last decade some usability
designs are even obliged to meet certain legal standards before
they can be employed. In the UK, for instance, the HSE's Display
Screen Equipment (DSE) regulations of 1992 [HMSO 1992] fulfil
the European Directive pertaining to the use of display screen
equipment. As a result computer user workstations and interfaces
have to meet certain conditions before they can be used in the
work place. From 1st January 1997 the regulations require that:
"software must be suitable
for the task, software must be easy to use, systems must display
information in a format and at a pace which are adapted to users
[and that] the principles of software ergonomics must be applied".
The first two items give a good hint that for software to meet
the criteria set, the task and the user must be modelled in some
way. Secondly, as well as the third requirement again implying
the importance of the user, it also alludes to the elements of
guessability, learnability and experienced user performance endorsing
the theories of Jordan et al [1991] (as previously discussed
in Guessability-Experienced User Performance (EUP) ). The last
requirement however, as with the other usability definitions I
have reported, seems to be quite unprescriptive. Whose principles
are to be applied? I suggest that prosecution under this legislation
may prove difficult and could lead to complacency in interface
design considering the possible loophole.
Ergonomic Standards and Quality
Before judgement can be passed on
these legislative rulings (DSE regs. [HMSO 1992]), there is a
prerequisite to define usability standards. Due to the regulations,
vague guidelines have become redundant as measurable standards
for interface designs, software and systems, generally, have become
necessary. A significant amount of research has been undertaken
in the search for standards setting; the ISO measurement for usability
has already been discussed. At present, the products themselves
can also be tested to the ISO 9000 [BSI 1996] (which superseded
the British Standard of BS5750) to confirm "quality systems".
The ISO 9000 family of standards
are required to be assessed by an ISO technical committee (TC176)
every five years and it is projected that the current review will
be at the Final Draft International Standard stage by 1999 [Lane
1997]. The impact is that designers of systems must keep pace
with, and be aware of, this continuous review, otherwise their
products may not reach acceptable (and thus marketable) standards.
If people, generally, don't have a target to aim for they may
not reach it or be aware of the fact when they have.
To aid these sentiments, the DTI
in 1995 contracted National Physical Laboratories management Ltd
(subsidiary of Serco Group PLC) to provide research on and development
of physical quantities. Incidentally parliament had initially
set up this laboratory back in 1900 and more recently NPL has
been instrumental in contributing to ISO standards setting [NPL
1997b]. As part of NPL's remit they provide calibration on Information
Technologies including giving advice to customers on "whether
software meets DSE regulations" [NPL 1997a].
It is relevant to note too that
in an HSE survey of 34 incidents, in safety critical systems,
15 (44.1% of total) were primarily caused by inadequate specification
[HSE 1995]. The need for an effective design goal cannot be disregarded
if effective and safe systems are to result.
The
Undesirable Effects of Poor Design
Actual Injury
Thankfully the majority of interactive
systems do not control life and death decisions. Errors made will
not cause loss of life and safety is not a factor. However in
certain systems, deemed to be safety critical, such as a control
system for a hazardous chemical plant or nuclear power station,
I would suggest the most important facet in the development and
design of these systems is the aspect of safety. Usability has
to be extremely effective and thoroughly developed; the slightest
slip in control (either by the system or the user) may ultimately
result in loss of life. Therefore "man-machine systems need
to be ergonomically sound" [Grandjean 1988].
There have been many disasters attributed to poor design. Handles/Levers details some
examples.
Awareness of chronic illnesses such
as Repetitive Strain Injury (RSI), that has only recently been
acknowledged, must now be considered when developing systems.
RSI had gone unnoticed and even misdiagnosed for a long time causing
great pain and stigma for its sufferers. Back in 1983, HSE, in
their working with VDU's guidance leaflet, refers to "muscle
tiredness" [HSE 1983] confirming that awareness of RSI type
problems from using equipment was known even then.
Reductions in Efficiency
Poor matching of the system's design
with the needs of the user can lead to a loss of efficiency. Booth
[1992] develops this idea and provides scenarios where this can
be witnessed. Firstly, he suggests that systems may not "provide
functions that are required but do provide others that the user
doesn't need". Secondly, he suggests some systems are developed
in a way "that don't provide the right information or in
a way that is not wanted". If systems like these are imposed
on its users they will create many problems.
One result is that a user will persevere
with a system under the delusion that a function (which is so
obviously a need for him) will be available until he eventually
realises that it is not, which in turn causes him stress. This
may result in the reliance on manual files, even surreptitiously,
leading to the problem of a duplicate system. A subsequent introduction
of another system may become affected by the reticence of the
IT weary users in accepting yet another system that potentially
may be as useless as the first, even though it may well solve
the problems of the first.
Also the purchaser of the system may not need, now or in the
future, the extra features that have been included. Unfortunately
he still has to pay for them. However, considering not all customers
may be able to afford tailored, bespoke systems anyway the price
for the over-featured systems, packages in particular, may be
excused. Indeed to try to alleviate the problem, and by acknowledging
the variety of tasks and differences in user types, customisation
(see Reducing Stressful
Feedback & Menus
Generally ) for the individual user is now often offered to
a greater or lesser degree, depending on the system.
Low User Esteem
Invariably people make mistakes
at some time or another; it is human nature. By using the rules
of simple chance, the more complicated the task the more chance
of a mistake being made with it. Therefore when people makes mistakes
with, assumed, simple tasks, such as the opening of a door (where
is that handle?), they tend to feel guilty or stupid or both.
Norman [1988] pursues this point
and argues that the error maker will even "either try to
hide the error or blame themselves for stupidity or clumsiness".
In the example of the opening door, the opener will hope that
nobody would have seen their pathetic attempt at such a simple
task in order to save their embarrassment, especially if the door
was signed to specify whether a push or pull was needed. As a
result the opener will put the blame onto himself rather than
onto the door's designer who had created such an ambiguous design
in the first place. Norman [1988] would suggest that if an item
needs a label then the mapping (which is discussed in depth in
User Models & Mapping) is imperfect, highlighting
poor design. In other words "If a door handle needs a sign,
then its design is probably faulty" [Norman 1988].
Considering that users tend to blame
themselves, if problems or faults do occur, when faced with apparently
simple tasks and systems, they are less likely to comment upon
or complain about the design of the system. As Norman [1988] points
out if somebody "perceives the fault to be his ...[then he
won't]... want to admit to having trouble", and that this
will create a "conspiracy of silence, maintaining the feelings
of guilt and helplessness among users". In addition this
will add not only resentment towards the system but will hinder
any attempts to rectify problems because the users will not admit,
even to themselves, that there are any.
Technophobes Born of Marketing
Constraints
Consider Thimbleby cited in Nuttall
[1995], who also highlights a similar theme by raising concerns
about the poor design of video recorders:
"Many people become technophobic,
literally fearful of dealing with a gadget or an electronic
device ever again. They blame themselves for not being able
to make the machine work when they should be blaming the manufacturers".
In turn, he suggests that "the
Makers think all people want are more and more buttons and features
so they can impress their next door neighbours every year,".
Considering the cost of a new video could be up to £1000 a couple
of buttons and a simple display wouldn't impress anyone so unfortunately
they may be right. Barfield [1993] suggests "Featuritis"
as the name for this phenomenon. An easy to use product, with
a simple design, may not be so popular as the 'all bells and all
whistles' version and therefore it would be unprofitable.
Nuttall [1995] continued his interview
with the somewhat cynical Thimbleby who continues his litany by
describing a fax machine:
" "It is atrociously
designed and the manual is difficult to understand... The machine
also has features on it which are not in the manual and the
manual describes features the machine does not have," it
is made by Sagem, a French company that also makes Exocet missiles.
"Either they are making a nasty piece of technology because
it is cheap and can get away with it or the other view would
be they do not know how to make Exocets either," says the
scientist.".
Thimbleby's anger can be clearly
appreciated; at the point of delivery, to the user, the total
package is quite frustrating because of the contradictions between
product and manual. Due to commercial pressures when packaging
goods, many products come with multi function manuals covering
all the models in a range and quite often in numerous languages,
removing the expense to employ a system to identify individual
models and/or market country. My CD player instructions, for instance,
cover 6 models [The Sony Corporation 1994] and the instructions
for my extractor fan includes 9 languages [Vent-Axia 1988].
It can only be hoped that the Exocets
have a decent operators manual!
Norman [1988] is also aware that
design is not solely based on usability considerations. He also
suggests "aesthetics... [and] cost or ease of manufacture"
must play their part. He notes that "trouble occurs when
one dominates all others" for example if design "...was
ruled by usability, it may be more comfortable but uglier",
which in turn wouldn't sell as well. There is commercial pressure,
therefore, to convince a market that a product is 'state of the
art', 'the ultimate in design' etc. etc. . Correspondingly there
is a business need for an undercurrent of continuous design so
that in say another six months a prospective purchaser will be
sold the same story and what he bought six months ago will bring
exclamations of 'well it does the job but... look at this new
model, sir, it's 'state of the art', 'the ultimate in design'
etc. etc.
I even wonder how far the design
of a razor can go. Firstly, we had a razor with a single blade;
then a razor with two blades (if the second shaves closer still
why bother with the first one?!); then a razor with two blades
and a glide strip; then a razor with two blades, a glide strip
and protection wires; then a razor with two blades, a glide strip,
protection wires and a floating blade mounting; then a razor with
two blades, a glide strip, protection wires, a floating blade
mounting and sensitive skin protection etc. etc.
I still use a single safety razor
myself; it is a lot cheaper and does the same job. Norman [1988]
suggests "an important lesson in design... [and that is]...
you have to know when to stop". Unfortunately, as demonstrated,
this lesson is overcome with commercial goals and can lead to
design overkill resulting in changes, sometimes to the detriment
of usability, where none are required.
Conclusion
In this chapter I have described
why there is a need for improving usability in systems. I have
detailed the reasons why usability has become the basis for design
rather than a cosmetic treatment at the end of an implementation.
I have discussed the effects of poor design and suggest that ultimately
inefficient usability will result in the task not being done or
being done with more effort than should be needed.
Interactive systems can be seen
as tools that mankind use to undertake tasks. Generally the more
appropriate the system to the tasks the greater the efficiency.
For example you can knock a nail into a piece of wood with a glass
bottle (if you're careful) but why bother when you can use a specific
tool (a hammer). It can be seen that the only difference between
the hammer and the bottle, in relation to completion of the task,
is in the usability of each tool. Efficiency is the goal to aim
for. Barfield [1993] remarks that "everybody knows that if
you do a job using well-designed and appropriate tools ...[it
is done] more effectively". She continues by stating that
the "efficiency depends on a well-designed user interface".
Usability at the interface therefore
plays an important role in whether the whole tool is effective
or not.
|