The outline below requires Netscape/Microsoft browsers, version 3.x or later, for correct viewing.
Revised March 15, 1997
PICTURE
DEFINITION OF PROTOTYPE
An easily modified and extensible model (representation, simulation or demonstration) of a planned software system, likely including its interface and input/output functionality
CHARACTERISTICS OF A PROTOTYPE
TYPES OF PROTOTYPE
LOW-FIDELITY versus HIGH-FIDELITY
LOW-FIDELITY
A set of drawings (e.g., storyboard) that provide a static,
non-computerized, non-working mock-up of user interface for
the planned system
HIGH-FIDELITY
A set of screens that provide a dynamic, computerized,
working model of the planned system
EXPLORATORY versus EXPERIMENTAL versus OPERATIONAL
EXPLORATORY
A throw-away prototype used to clarify project goals, to
identify requirements, to examine alternative designs, or to
investigate a large and complex system
EXPERIMENTAL
A prototype used to validate system specifications
OPERATIONAL
An iterative prototype that is progressively refined until
it becomes the final system
HORIZONTAL versus VERTICAL
HORIZONTAL
A prototype that models many features but with little detail
a horizontal slice of a system's structure chart from the
top down to a specific depth
most useful in the early stages of design
purpose is to test the overall interaction metaphor, so
includes common functions that the user is expected to
perform frequently
VERTICAL
A prototype that models few features but with much detail
a vertical slice of a system's structure chart from top
to bottom
most useful in the later stages of design
purpose is to test details of the design
DIAGONAL
A prototype that is horizontal down to a particular level,
then vertical below that point
GLOBAL versus LOCAL
GLOBAL
A prototype of the entire system
an expanded horizontal prototype that models a greater
number of features and covers multiple levels of the
system's structure chart
useful throughout the design process
LOCAL
A prototype of a single usability-critical system component
a vertical prototype that is focused on one feature
useful at some specific stage of the design process
DIMENSIONS OF PROTOTYPING
EXECUTABILITY Will the prototype be runnable and, if so, what does that mean?
CHAUFFEURED PROTOTYPE
"runnable" in the VERY LOOSE SENSE that the prototype allows
a walkthrough to be performed
ANIMATION PROTOTYPE
runnable in the LOOSE SENSE that it is executes frame by
frame in "slide show" mode on a computer
TURING PROTOTYPE
"runnable" in the sense that it executes in "slide show"
mode BUT allows a third party, hidden from view, to pick the
next slide based on user input (also called "Wizard of Oz"
prototyping)
INTERACTIVE PROTOTYPE
runnable in the STRICT SENSE that it executes on the
computer AND responds to user input in real time
FUNCTIONAL PROTOTYPE
runnable in the VERY STRICT SENSE that it executes on the
computer, responds to live input, and performs some of the
expected computations
MATURATION Will the prototype be improved by stages and, if so, will it eventually grow into the final product?
REPRESENTATION What level of fidelity will the prototype achieve?
SCOPE Will the prototype be limited to specific areas of functionality?
CHARACTERISTICS OF A GOOD NON-DISPOSABLE PROTOTYPE
EXECUTABILITY Works sufficiently well with live user input to permit usability testing
MATURATION Can evolve, given sufficient refinement, into the final product
REPRESENTATION Has the "look and feel" and performance characteristics of the planned system
SCOPE As a minimum, simulates the 20% of the functions that customers will use 80% of the time
THE PROTOTYPING PROCESS Many variations
Perform customer needs analysis in a JAD session but leave requirements incomplete.
Build a low-fidelity prototype to clarify initial requirements.
Iterate (re-specify, re-design, re-evaluate) until the team, both users and developers, agree that the fidelity and completeness of the evolving prototype are sufficiently high.
Freeze these specifications.
Finish building the product exactly as prototyped.
NOTE: The prototyping process experiences a series of birthdays while traditional software development experiences a series of deadlines.
WHEN DO YOU PROTOTYPE?
BEFORE THE BEGINNING to show proof of concept to senior management
IN THE BEGINNING to gather initial user requirements
AFTER THE BEGINNING to validate evolving user requirements
IN THE MIDDLE STAGES to validate system specifications
IN MIDDLE AND LATER STAGES to pre-train users or to create a marketing demo
IN THE LATER STAGES to explore solutions to specific usability or design problems
WHAT TO CONSIDER UP-FRONT BEFORE BUILDING A PROTOTYPE
Breadth of functionality needed in the prototype at first, later on
Choice of prototyping tool and its limitations
Completion criteria for the iteration cycle
Composition of the team (users, developers, other stakeholders)
Level of fidelity needed in the prototype at first, later on
Maximum length of an iteration cycle
Purpose of the prototype at first, later on
Ways to manage conflict between team members, build consensus
PROBLEMS CAUSED AND CURED BY PROTOTYPING
PROTOTYPING MAY ADDRESS THE PROBLEM OF ...
communication between developers and customers
customer acceptance
delivering early proof of concept
fuzziness in early stages of design
gathering valid requirements
increasing constructive user participation
managing change requests
product invisibility
quality assurance
PROTOTYPING MAY INTRODUCE THE PROBLEM OF ...
deciding how much iteration is enough
gauging progress without traditional milestones
managing conflict between developers and customers
managing the schedule for a development cycle that is essentially open-ended
processing excess change requests from customers
runaway customer expectations
DEALING WITH PARTICULAR PROBLEMS
HOW DO YOU PREVENT RUNAWAY EXPECTATIONS DURING PROTOTYPING?
Build the expected performance into the prototype, using
delays (timing loops) if necessary.
Develop realistic specifications.
Distinguish between primary and secondary requirements.
Give customers a crash course in software development.
HOW DO YOU KNOW WHEN YOU ARE DONE PROTOTYPING?
When you run out of time or money (default criterion)
When the prototype meets all the requirements of the final
system
When the prototype has a limited purpose (e.g., gathering
initial requirements) and that purpose has been achieved
When, in horizontal prototyping, you reach the target level
(depth) in the system structure chart
When developers and users jointly agree to move on to the
next stage
PROTOTYPING TOOLS
FEATURES NEEDED IN A RAPID PROTOTYPING TOOL
MOST IMPORTANT FEATURES
Should create a working prototype with which users can
interact
Should make it easy to create, develop and modify screens
Should simulate the look and feel of the planned interface
OTHER DESIRABLE FEATURES
Should allow calls of external procedures and programs
Should allow playback of user trials
Should allow scientific collection and review of user
interaction data
Should be able to simulate the expected performance
characteristics of the planned system (e.g., by using
timers)
Should exhibit the look and feel of the target operating
system
Should generate much of the code needed to implement the
interface design
Should import reusable software components of various kinds
Should import text, graphics, sound and other media
Should leverage industry-standard APIs and standard
libraries
Should make it easy to change task order
Should make it easy to change window order
Should make it easy to create simple animations
Should make it easy to modify tasks
Should make it easy to sequence and re-sequence windows
Should provide a seamless transition from design to
implementation
TYPES OF PROTOTYPING TOOLS From less formal to more formal
Pencil and paper
Drawing software
Demo makers (e.g., Demo-It)
Animation and slide-show software
Perl + Motif + Tcl/Tk (UNIX)
"Visual" RAD tools such as Visual Basic, Optima++ and Borland Delphi
4GLs
UIMSs (User Interface Management Systems)
Executable specification languages (VDM variants)
EVALUATION OF PROTOTYPING
BENEFITS AND RISKS OF PROTOTYPING
ADVANTAGES (BENEFITS)
NUMBER 1 BENEFIT
Prototypes may be easily changed or even discarded.
NUMBER 2 BENEFIT
Prototyping may improve communication between and among
developers and customers
NUMBER 3 BENEFIT
Users may be more satisfied with systems developed using
prototyping.
A prototype may provide the proof of concept necessary to
attract funding.
A prototype may serve as a marketing tool.
A prototype may serve as the basis for operational
specifications.
Early visibility of the prototype may help management assess
progress.
Exploratory prototyping allows productive work to proceed
despite initial uncertainties.
Prototypes may demonstrate progress at an early stage of
development.
Prototypes may provide early training for future users of
the system.
Prototyping may prevent unpleasant surprises by calling
attention to incomplete or inconsistent requirements, or to
missing functionality.
Prototyping may produce some useful deliverables even if the
project runs out of time or money.
Prototyping may reduce misunderstandings between and among
developers and customers.
Prototyping may reduce redesign costs if problems are
detected early when they are cheap to fix.
Prototyping may reduce the time required for testing if
problems are detected early when they are cheap to fix.
Prototyping may require less effort (43% less, according to
Boehm, Gray & Seewaldt, 1984) than conventional development.
Prototyping may result in a 50-50 partnership between users
and developers where both experience "ownership".
Prototyping may result in a product that is a better fit for
the customer's requirements.
Prototyping may save on initial maintenance costs because,
in effect, customers are doing "acceptance testing" all
along the way.
Prototyping may strengthen requirements specifications.
Systems produced through prototyping may be judged easier to
learn and easier to use.
The horizontal prototyping method works nicely as a
complement to structured analysis.
The prototyping environment less vested in a particular
design, hence more open to change and innovation.
Use of prototypes may flush out change requests earlier,
when they are cheaper to process.
Users may understand prototypes better than paper
specifications.
Using prototyping during development may reduce the amount
of code that is finally written (by 60%, according to Boehm,
Gray & Seewaldt, 1984).
PITFALLS (RISKS)
NUMBER 1 RISK
Prototpying may encourage an excess of change requests.
NUMBER 2 RISK
Working prototypes may lead management and customers to
believe that the final product is almost ready for delivery.
NUMBER 3 RISK
The excellent (or disappointing) performance characteristics
of prototypes may mislead the customer.
Customers may not be prepared to provide the level or
frequency of feedback required for iterative prototyping.
Customers may not be willing to participate in the iteration
cycle over the long haul
Developers may have difficulty writing the back-end code
needed to support the slick front-end interface designed
with the prototyping tool.
Due to time and market constraints, system specifications
may be frozen before the prototyping process has reached a
definitive stage.
During prototyping, the only "design specification" is the
prototype itself, which may allow uncontrolled change.
Early prototypes may be of low fidelity, dismissed as toys.
Hi-fidelity prototypes may be mistaken for a real product.
Important system characteristics (e.g., performance,
security, robustness and reliability) may have been ignored
during prototype development.
It may be impossible to prototype mission- or
safety-critical system functions.
Iterative prototyping may be difficult for management to
plan and schedule.
Prototypes may become over-evolved, straining to incorporate
secondary functionality even though that will take
disproportionately more development time.
Prototypes may embody simplifications and other
inaccuracies.
Prototypes may oversell the product.
Prototypes of complex systems may themselves be rather
complex.
Prototyping is an adaptive process that may not exhibit
well-defined phases.
Prototyping may continue too long because there may be no
well-defined completion criterion.
Prototyping may force developers to change design
philosophies (e.g., switch to a bottom-up or an event-driven
model).
Prototyping may provide little room for testing
NON-functional system requirements.
Prototyping may stall if members of the team do not have
enough decision-making authority.
Prototyping, because it may be less controlled than
conventional development methods, may lead to a reduction in
programmer discipline.
Specifications that emerge during later prototyping may
reduce the structural integrity of the partially designed
system (e.g., increase coupling between modules).
The context of use for a prototype may be very different
from the context of use for the final system.
There is no guarantee that the positions of developers and
customers will converge during the iteration cycle.
WHEN PROTOTYPING WORKS AND WHEN IT DOESN'T
PROTOTYPING IS MORE LIKELY TO SUCCEED WHEN ...
used as a means to achieve early usability testing
used to compare alternative designs (the "dueling
prototypes" technique)
used to create a "living" specification
used to escape from the rigid serial pattern imposed by the
traditional software development life cycle
used to evaluate a proposed interface
used to explore the effect of change requests
used to expose new or unexpected requirements
used to identify market requirements
used to involve users in the design process
used to model a system that has a significant user interface
component
used to model a system that is relatively large and complex
used to provide a common basis for good communication
between developers and customers
used to stimulate customer input during requirements
gathering
used within a rapid prototyping tool
PROTOTYPING IS MORE LIKELY TO FAIL WHEN ...
no clear terminating criterion has been established to end
the iterative development cycle
the expectations of customers are allowed go grow beyond
reasonable bounds
the functionality of an operational prototype does not scale
up to the functionality required of the final system
the opinions of developers and customers diverge during the
iterative phase
the project is too small to justify prototyping
the prototype is mistaken for the promised product
used to model systems that present no external interface
(e.g., embedded systems)
used to gauge the future performance of the planned system