Introducing User-Centered Systems Design - Foundations for Designing User-Centered Systems - page 14

in general) that should be able to demonstrate a worthwhile return on investment.
Nielsen ( 1993 ), for example, argues that many usability-related design problem
issues can be identified by studying a small numbers of users (about five to eight).
The caveats are that the results of this approach are highly dependent on the types
of users involved and the particular interface. As yet there are no hard and fast
rules that can be applied to all systems which will tell you when to stop the user
analysis and start building.
The traditional approach to systems deployment largely focused on making the
users fit the system. In other words, companies employed the right people (selected
using psychometric testing, qualifications, and so on) and, where necessary,
trained them as a way to bridge any remaining gaps between the system and the
users. This approach has become increasingly unacceptable as people have
become better informed about technology and now expect to use it out of the box,
In addition, there have been recent political changes which require that systems are
accessible to more people (e.g., the Americans with Disabilities Act), rendering the
idea of fitting the user to the system less unacceptable.
It is now generally the case that you should design (or re-design) your system to
make it fit your users. We would strongly argue that you need to think right from
the very start of the project about your users, the tasks they will perform using your
system, and the context in which your system will be used. In other words, when
you are defining the system's functional requirements, you should also be defining
the usability requirements.
The level of detail required here should be guided by the associated risks
involved. If you only talk to developers as proxy users to determine usability
requirements, for example, there is a large risk that the delivered system will not
be acceptable to the real end users because the proxy users will not understand
how the real users will carry out their work using the system in a work context
that may constrain how the system can be used. If your system will be used in
extreme or safety critical environments (e.g., in space or aviation), for example,
your users will be highly skilled practitioners making decisions and performing
actions in a limited time frame, where the results may have life or death
importance. These risks are increased if the designers are unlike the users (Casper
and Murphy 2003 provides a nice case study). In these cases we recommend that
you do some background work in the domain, looking at existing systems similar
to the one you are designing and consulting appropriate resources such as topics,
as well meeting the users and seeing their context and tasks and running some
studies to test out your ideas and develop your understanding of the system's
context.
For simple, straightforward systems developed for your own purposes (like
many systems that are used in research, for example), you may not need to worry
too much about the design of the user interface. Even for very small numbers of
expert users it may not be worthwhile spending large amounts of time and effort on
developing the user interface because the costs may well exceed the benefits.