How we test expandability

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:

  1. expanding the number of objects to which a feature is applied
  2. integrating with other system or environment facilities
  3. 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










You are here::

Technology Review
What's Out There
Executive View
Developer View
At This Site
Who We Are
Consulting Services

Other Stuff
How We Test
Copyright © 1999-2012 eWyzard Inc.
Comments? Questions? Contact us.

Page Last Updated: 05/23/99