The User-Interface Prototype should be created as soon as you need to
expose the user-interface design to people other than User-Interface Designers. The prototype should approximate the
look-and-feel and behavior of the primary and secondary windows. Through these initial User-Interface Prototypes, you
begin to establish a mental model of the system's user interface.
Note that the focus should not be on achieving a good structure and modularization of the source code for the
executable prototype; instead, the focus should be on creating a throw-away prototype that visualizes the significant
aspects of the user interface and that provides some of its significant user actions/behaviors. Moreover, a prototype
is likely to change several times when it is designed and exposed to others, and these changes are often made as cheap
patches. As a result, the source code of the prototype is often of very limited value, and not "evolutionary," when the
real user interface is to be implemented.
In general, a prototype is cheaper to implement than an implementation of the real user interface. The following are
some differences between the prototype and the real implementation of the user interface:
The prototype need not support all requirements scenarios (e.g. Use Cases). Instead, only a small number of
scenarios may be prioritized and supported by the prototype. In subsequent iterations, the prototype may be
expanded, gradually adding broader coverage of the scenarios and deeper exercise of the architecture.
The primary windows are often the most complicated to implement; if you make an advanced user interface that really
takes advantage of the visualization potential, then it may be difficult to find ready-made components. Rather than
implementing new components, you can normally use primitive components, such as push-, toggle- or option buttons,
as an approximation of how the user interface will look for a certain set of data. If possible, make several
prototypes showing different sets of data that cover the average values and object volumes.
Simulate, or ignore, all user actions on windows that are non-trivial to implement.
Simulate, or ignore, the internals of the system, such as business logic, secondary storage, multiple processes,
and interaction with other systems.