Keywords
Prototyping, low-fidelity prototyping, process management,
product development, contextual inquiry, modeling, practi-
cal techniques, group dynamics
MISSION
User Interface Engineering is a seven-year old company
researching and consulting on what makes products usable.
Our mission is to encourage and foster creative product
development teams that build applications users will use and
value. We do this not only by demonstrating the technology
used in building better product interfaces, but also through
the processes which produce that technology.
We accomplish this through research, training, consulting,
and publication. Training, consulting and publication serve
to transfer the techniques and technologies developed in our
research. Our work emphasizes innovative applications of
usability to the challenges facing today's product developers.
OUR CLIENT'S ENVIRONMENT
Our clients work in the world of production software devel-
opment for products and in-house systems. This world is
characterized by rapidly evolving applications. Technical
requirements for applications are constantly changing as is
the hardware on which they are based. New production
techniques are required to deliver usable applications.
Our goal is to provide these organizations with the capabil-
ity to deliver better applications faster - to do this we:
- Serve as a source of in-depth knowledge necessary for
creative application development.
- Improve (and train others to improve) application de-
velopment by applying practical, easy-to-implement
techniques to existing processes.
- Prepare multi-disciplinary teams to build applications
that people can use (and preparing people to work in
them).
Our courses and consulting work are done interactively. All
participants are included and get "hands-on" experience.
Nielsen et al [1] have documented the learning from a short
course what we intuitively believe, that learning reinforced
by participatory exercises are usually retained far better than
material entrusted to lecture or demonstration.
A large part of the task is helping groups and teams work
together. We have found that this capability is often an
essential ingredient of our work.
Application development work for clients is always based
on the workshop model. Part of the deal is that the client
learns the technique so that the new methods begin to be
integrated into their development work. If we don't transfer
the technology then the client will be back where they
started minus their investment in us.
Our belief and experience indicate that these objectives can
be combined so that they support one another and together
make up a viable way to do business and give good service.
HOW IT ALL FITS TOGETHER
Our model of development and change for practices and
techniques is evolutionary. Changes are made in small steps
and increments, and each change is tested on a real-world
scale before final adoption. Our research shows us how
development processes can be improved and builds the
supporting knowledge base. Our workshops give us a
framework for testing improvements in technique on real-
world problems with real world constraints.
Techniques are packaged and taught so that acceptance and
change in the organization can also be evolutionary. These
techniques remain effective even if only one person accepts
them, or if only one department implements them. Enhancing the ability to
work cooperatively is fundamental to
all of our training.
RESEARCH AND FIELD WORK
We normally think of research as a process which separates
problems into parts and studies the parts in isolation. We
carry out this type of study ourselves and also for and in
support of our clients.
In our workshops we cannot isolate or even scale down
problems. We address them as a whole because we are
developing actual products and no factor can be ignored.
Historically we have become more successful as our ap-
proach broadens. For example, the ability to facilitate group
decision making is as important in the timely production of
effective products as any other technique.
Our "field experiments" are short because of the nature of
the business - in a rapidly evolving market new products
must be produced quickly. We are usually hired to increase
that pace. So our research loses relevance to what we do if
its results are not constantly checked against the business
environment.
RESEARCH PROJECTS
Productivity analysis, in which users perform the same
tasks with two or three different software packages, allows
testing whether packages which have competed with one
another in the marketplace for a substantial time have the
differences that support their marketing claims. The sur-
prising results of a series of these studies in which the
charting capability in three spreadsheet packages was com-
pared led us to question the productivity - in fact the overall
effectiveness - of wizards.
A recent project involved a simulation for testing the
integration of speech recognition with word processing
software. The goal was to discover "natural" uses for
the voice mode alongside mouse and keyboard with word
processing software. With "Wizard of Oz" techniques, very
high level voice commands were accepted and carried out
by a commercial word processing package. By varying the
rules governing the acceptance and ability of the simulation
to process commands, we explored and began to define the
boundaries of what users would value and/or tolerate in such
a system. A key service was facilitation of the design team's
decision-making process. Putting together the simulation
involved reaching consensus (for the purpose of testing in
order to get data) on semantic questions over which science
has been divided for decades.
We have recently completed a test series on the
productivity and effectiveness of software wizards.
Wizards appear in applications more and more
frequently, their effective use is a matter of concern to our
clients, and there is little in the literature for guidance. We
began by developing a taxonomy of wizard components and
functions and an appropriate user model. Then we designed
and conducted usability and productivity tests on 12 wizards
found in several commercially successful software packages.
The result of this testing is data indicating in detail which
design strategies used by the developers of wizards were
effective and which were not.
WORKSHOPS/TRAINING
Paper prototyping was used to specify a system for
new account processing. The application was
the client's first move from mainframe to GUI, and was
conceived, modeled, and tested with real account reps within
a week. The project was a key step in overall re-engineering
of the client's business.
Usability testing was conducted using the most recent build
of molecular modeling software. Users were
PhD's modeling molecules on workstations.
Paper prototyping was used to test a new release of a
multi-media authoring system for re-use of
published multi-media objects. This mocked-up interface
was evaluated with developers of interactive television
prototyping.
Contextual inquiry was used to create accurate models of
both the users of an application development
environment and the range of typical tasks
addressed by the package for a developer entering the
market.
WHAT'S NEXT?
User Interface Engineering will continue to research what it
takes to build usable products. We will be disseminating
this information through our courses, training and publica-
tions to those people who need to develop effective applica-
tions.
References
1. Nielsen, J, Bush, R M, Dayton, T, Mond, N E., Muller, M
J., Root, R W. Teaching Experienced Developers to Design
Graphical User Interfaces. Human Factors in Computer
Systems. CHI '92 Conference Proceedings, May 1992, pp.
557-564
