Home
 
Title Page
List of Figures
List of Abbreviations
Introduction
What is usability anyway?
Importance of improving usability
Feedback
Guessability
User centred design
Case Study
Conclusion

Appendix 1

Appendix 2

Bibliography

Importance of improving usability

Introduction
The Impetus for Change
The Undesirable Effects of Poor Design
Conclusion

Introduction Next Section

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 Previous SectionNext Section

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 Previous SectionNext Section

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 Previous Section

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.