ANALYZING THE CURRENT
NOMINAL TASKS of a person using a product is one
way to decide what a product should do. Such a limited approach,
satisfies the base needs of the user and gets the product out
the door. However, this approach leaves unanswered the question:
what will a user want to do with the system once he gets it and has become comfortable with the base features? Our
testers carefully consider this last question when evaluating
a product and rate the product accordingly. Why? Products
which elegantly anticipate user's future needs sell better because they
satisfy better.
We believe there are 16 typical ways a user may want to expand
any feature of a product. These ways group into three major categories:
- expanding the number of objects to which a feature is applied
- integrating with other system or environment facilities
- modifying the way the product carries out instructions
Below are the categories with their respective subparts. Illustrative
examples, using the notion of a "macro" are also given.
1) Expanding the number of objects
- using more than one instance of a feature - e.g. giving voice or keystroke commands
into more than one program at a time alternating back and forth
between them all, developing and compiling more than one application at a time
- reusing a facility - e.g. being able to cut and paste a section/snippet
of a voice/code/word macro into a new macro
- inclusion in a larger goal - e.g. using macros to edit
a database
2.) Integrating with other system facilities
- interleaving with other goals - e.g. the macros which
are recognized change as appropriate to whichever window has
focus
- taking advantage of other goals - e.g. a set of macros
which determines that optional facilities are currently available
because a prior special set of macros has been loaded by a previous
context
- stop or postpone - e.g. stop input to the product from an external source (mobile
recorder, data stream) that is clearly going awry or postpone completion of
such input in order to switch another task
- get result - e.g. get a result from one macro in order
to determine the next activity to be done
- external activation - e.g. allow another separate program or product to activate
the capabilities of the product under test in order to get the product under test output for its own
use
3. Modifying the way the product carries out instructions
- progress monitoring - e.g. user may wish to know or change whether the product (voice interface, keyboard) is treating the current input or utterance as
a command, a macro, text, noise, or is idling and if the product
changes its mind about that evaluation
- result detection - e.g. the user may wish to optionally know
whether the last series of rapidly entered or uttered commands were
actually heard as intended
- rolling back to a previous state - e.g. the user may wish
to undo the window context switch implied by a macro or other input (to
any depth)
- recording and retrieving - e.g. the user may wish to retrieve
the last few commands for use in a new macro thus also
implying some recording mechanism for those commands and a companion
searching mechanism for those selected commands
- modifying outcomes - e.g. a user might wish to modify an otherwise
successful series of previous input commands in order to get
a new result
- modifying for multiple similar outcomes - e.g. a way to target
multiple contexts with the same macro each context being
differentiated by one or more additional keystrokes or phrases which select
the context; a companion enumeration facility to display various
instances of the more general macro
The examples above given for each of the general expandability
principles are not contained in entirety in any current product
although some are features contained in some products. They are
in no way whatsoever the full range of reasonable expandability
possibilities. Nor should the examples above be taken as our complete
prescription for the perfect product. They are examples
given to illustrate how a tester (or designer, for that matter)
may use the principles to anticipate user attempts to search for
increased productivity.
It's crucial to distinguish between simply adding product features
and our goal. Casual adding of new product features often results
in bloatware. Our expandability analysis is designed to increase
the utility within the work environment of existing product features
by careful polishing of those features in limited ways which align
with the above principles.
If you have applications under development and wish to
have an analysis performed along these lines please contact
us.
More on bug testing...
More on usability...
Reference: Goal
Composition by Jakob Nielsen
