Concepts:
Usability Testing
Usability Testing evaluates the system from the perspective of the end
user. Usability testing includes the following types of tests:
Usability testing is not a substitute for good design - it is most effective
when combined with User-Centered Design (see: Concepts:
User-Centered Design).
Usability Testing should start early. Early
user testing means early prototyping, typically drawings and mockups described
as low-fidelity prototypes. Hi-fidelity prototypes will follow later in the
process (see: Activity: Prototype the
User Interface).
Testing User-Interfaces
It is immensely important to expose the user-interface to others. As the design
and implementation of the interface progresses, you expose the design to increasing
numbers of reviewers, including:
- other project members
- external usability experts
- users
To get valuable feedback, you don't always have to go through full-blown use
tests where real users perform real tasks. An important class of user-interface
defects are caused by the "home blindness" of the user-interface designer:
anyone who wasn't involved in the user-interface design should be able to most
identify these defects.
Exposing the Design to Other Project Members
This is an underestimated way of exposing the design. It has a very fast turnaround
time: project members are already familiar with the application, and they are
usually available for a spontaneous usability session with tremendous ceremony
or formality. User-interface designers should do this continuously during the
design activity, to cure their own "home blindness."
Exposing the Design to External Usability Experts
A good usability expert can help to reduce development effort by pointing out
common usability flaws, and will usually offer other perspectives on the user
interface based on experience. It can thus be of value to involve external usability
experts earlier in the user-interface design work so that you have sufficient
time to refactor the design to incorporate their recommendations.
Exposing the Design to Users
Exposing prototypes to users is generally good use of your time. Because access
to users is often limited, it is worth getting feedback on prototypes when the
opportunity arises. Do this as often as necessary to gain the stakeholders'
approval and to correct any misinterpretation of the stockholders' needs. This
can occur either during requirements capture or user-interface design. Where
possible, avoid exposing the same user to the interface more than once; the
second time, the user will be tainted by your earlier design ideas (similar
to "home blindness"), and as such the value of the activity is diminished.
Also, when exposing a software prototype to end users, be careful to set the
expectations right. If you don't, users may have expectations that they will
experience the full behavior of the functioning system behind the user interface.
How to Expose the Design
One way of exposing a user-interface design is to have a business or system
analyst sit together with the end-user, either in front of a screen or other
medium showing the interface. Walk through a common scenario, for example, a
use case's basic flow with typical values, as described in a use-case storyboard.
Encourage the person to ask questions and give comments.
The challenge with this approach is to ensure the information you obtain is
as unbiased as possible. To do this, you need to make sure the questions you
ask are context-free. Take as many notes as you can: if at all possible, have
someone else do this so as not to interrupt the users natural flow. (For other
useful guidelines on conducting user interviews and workshops, see: Work Guidelines:
interviews and requirements
workshops).
Another way of exposing the user-interface design is to perform use tests,
often conducted as a lab or workshop with representatives from the end-user
community. In a use test, real users perform real tasks with the interface,
with software development staff typically taking a passive observational role.
There is a lot of value that can be gained from this type of usability testing,
however there are a number of challenges that must be faced and tradeoffs made
to get reliable, economic results:
- As a general rule, this approach has the most value where the end-user
community is large, varied and has a great degree of control over their
selection of software system. In the presence of these factors, the risk of
not performing use tests increases. Often the greater the value in
performing these tests, the harder it is to gain access to, coordinate and
manage this activity with the end-user.
- It is important to identify the most common usage patterns, discounting
outlier and exceptional results, to ensure that the user-interface
design decisions are based on the needs of the majority. To do this, you will need sample
data that are both broad and deep. This will usually require a large amount of effort to gather and
collate.
- Where end-users are to migrate from an existing legacy system to a new system, they are often concerned that the new system will provide less functionality
than that provided by the old. Unfortunately, this issue is seldom raised directly, and is
often concealed by comments such as "I want the new system to look and
feel exactly the way the existing system does".
- Where a significant change in technology is being proposed to an
end-user community, it may be necessary to provide training in the basic use
of the technology before significant value will be gained out of use
testing. For example, legacy system users may have had no previous
experience using a mouse or working with a GUI.
Each project team needs to consider these challenges against the unique
project environment they are working within, and arrive at the appropriate
timing, method and approach to usability testing.
Further Reading:
See [CON99] and [GOU88]
for information on designing for usability.
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|
Disciplines >
Test >
Concepts >
