|
|
|
|
<== Site map | Selected Menu path: ErgoLight >> Company >> ArticlesArticles | ||
|
UPA 1999 - Phoenix, Arizona Position Paper for Workshop W5 Crossing the ChasmErgoLight
Ltd., Experience in promoting usability
Between the years 1975 and
1991 I worked for Rafael, the main R&D institute of the Israeli Ministry of
Defense. Between the years 1980-1983 I was the project manager for a major
project in the Electronic Division. The main user tasks included data entry and
data manipulation. Primary design concerns were raising the user performance
and prevent accidents caused by user errors. My first exposure to
usability was between the years 1984-1985, during a sabbatical leave of absence
from Rafael, I worked for the DI department of BNR (now Nortel) on the design
of a prototype of a touch sensitive telephone set. On returning to Rafael, I
decided to promote usability in Rafael. Our department manager agreed
to assign me a job of usability designer. In 1986 I was the first person in the
Electronic Division whose job was usability evaluation. Between the years
1986-1989 I was assigned for part time studied at the Technion of Haifa,
Israel, towards a Ph.D. in Behavior and Management Sciences (which unfortunately,
I was prevented from completing). However, in few months I realized that they
were not willing to offer me enough projects at which I could contribute. Between the years 1987-1991 I
worked for the Human Factors department of Rafael, where I participated in
several projects that dealt with the usability of video recording. Between the years 1992-1993 I
worked for IBM and for ISG, trying to raise usability through jobs of software
designer and technical writer. My manager in IBM was in charge of the
development of UI design tools. He thought that usability should not dealt with in his department, because decisions are based on
subjective experience and one cannot measure it. Between the years 1994-1996 I
was a freelance consultant. I intended to offer usability consulting services
to software developers. However, I had to admit that I failed. There was little
interest in the Israeli industry in usability at all. I realized that the main
barrier to consulting was that people had different background in computer
operation, which made them disregard my advice, which was based on design
rules. My conclusion was that people in the software industry would appreciate
tools that provide hard evidence. In 1996 I founded ErgoLight
Ltd., which I continue to manage. ErgoLight develops tools that
provide hard evidence about the usability of Windows applications. We use these
tools to conduct informal usability tests at beta sites. In addition, we offer
integration of these tools in usability labs, as a means to provide hard data
and objective measures of usability. The role of testing tools in promoting usabilityThe need for tools
Software developers incline
to spend much on technical issues and not enough on human factors. Thus, GUI
design is typically based the developers intuition, rather than on the user
needs, and GUI validation is typically conducted against the product
specification, rather than against the users expectation and performance. Typically, product managers
consider usability as merely conforming to a style guide. Other topics, such as
user work flow, are considered to be a matter of taste, depending on the
designers intuition. Only few developers agree that expertise is required for
designing and evaluating user interfaces. The industry appreciates
tools such as that reported by Lecerof and Paterno (1998). Members of the UTEST mailing list often ask
how to get hard evidence to product managers. My position is that hard evidence
is obtained by tools, because tools are considered objective. I do not propose
that tools will substitute for the usability experts. What I propose is that
usability professionals can integrate tools in their consulting, to support
their consulting by hard data. A review of tools for automatic testing was
provided by Hilbert and Redmiles (1998). Objective measures of usability
Product managers are confused
by the variability of available design options and design rules. Often, it is
difficult to convince them that consulting based on human factors is applicable
to their specific project. For almost every design rule, there is another
design rule that contradicts the first rule. It is difficult to convince
product managers to consider human factors because usability professionals
often propose a selection of design options. However, they do not offer
effective and efficient tools for deciding that a particular design option is
better than its alternatives. Tools may provide statistics
of the utility of the product features. Product managers already appreciate
this capability. In addition, tools may provide objective measures of the costs
of design flaws, by measuring the time that users waste because of these flaws. Shorten beta cycles
User acceptance is typically
verified in beta sites. Developers expect the users to report on all design
flaws and bugs that they encounter, including usability issues. However, it is
well known that users do not report on many of the problems that they
encounter, for different reasons. For example, if they cannot repeat the
sequence of actions that resulted in a difficulty or if they did not follow the
user documents, that support the implementation, even
if it is wrong (more in http://www.ergolight-sw.com/www/CheckTheUser.html (link)). Tools can be used to
encourage users to report on difficulties that they experience either
automatically (e.g. Kaasgaard et al., 1999) or as an
extension of laboratory testing (Chen et al. 1999). By matching the user
intention with the user actions, a usability professional can identify user
errors that resulted in unexpected system behavior. This kind of data is absent
using current practices. Save debugging costs
Many of the users reports
about operational difficulties are because of their own errors, of which the
users were not aware. Typically, such reports are wrongly classified as
software bugs. During debugging, programmers spend much of their efforts trying
to track bugs that do not exist, because the problem was reported as a bug
instead of as a design flaw. Examples may be found in
http://www.ergolight-sw.com/www/Examples.html (link). Enhancing the product quality
UI designers find it
difficult to anticipate all aspects of user errors. The costs of user errors
are (e.g., http://www.cba.hawaii.edu/panko/HumanErr/ (link))
Users
waste a great deal of time recovering the data accumulated before the error
Some
errors are never detected
User
errors may result in accidents. Errors made by experienced
users are important for two types of systems:
Performance
critical systems, for which
the marketing goal is to increase the user performance. User errors degrade
user performance in two ways: by introducing wrong data into the product
database and by slowing down the product operation. The degradation in
operation speed of experienced user due to their own errors may be as high as
50%. An example of the costs of user error is presented by Bailey (1996, p.
192);
Safety
critical systems, for which
the main marketing concern is to prevent accidents caused by user errors. There
are indications that for each actual accident there are about 100 situations of
almost accident (e.g. Hannaman, 1984). ReferencesBailey,
R.W., (1996) Human Performance
Engineering. Prentice-Hall
Inc. Chen B., Mitsock M., Hannaman, G.W. (1984). SHARP: Systematic Human Action
Reliability Procedure, EPRI NP-3583, Harel, A. (1999). Automatic operation logging and usability validation. Submitted for HCI
International 99. Hilbert, D.M. and Redmiles, D.F. (1998) Extracting usability information from
user interface events, Dept of
Information and Computer Science, Kaasgaard, K., Myhlendorph, T., Snitker,
T. and Sorensen, H.E. (1999) Remote usability testing of a Web site information
architecture: testing for a dollar a day. Submitted for Interact 99. Landauer, T. (1995), The trouble with
computers. MIT Press. Lecerof, A. and Paterno, F. (1998) Automatic support
for usability evaluation. IEEE Transactions on Software Engineering
24/10 Reason,
J.T., (1990), Human Error. |
||||
|
ErgoLight: system design by human factors
For more information - send your RFP message to:
sales.1@ergolight-sw.com:
Request for Proposal
Alpha Sites: This particular link is for getting visibility of hosted sites by search engines |
||||
To
get a free usage statistics report -
To order a full usage report -
Did you not find the information you need?
Do you want to comment on the website content? Please, send your question or comment to
Did you experience any problems with this
website? obsolete or broken links? inconvenient design? design mistakes? We would appreciate your comments. Please, send
them to