When prototyping the user-interface, keep in mind the user-interface design, the Storyboards created during requirements elicitation, and the user
interface guidelines in the project-specific guidelines. If it is discovered that refinements to the Storyboards are
needed as a result of this task, these updates are performed by the System Analyst (see Task: Elicit Stakeholder Requests). If it is discovered that
refinements to the user interface design is needed as a result of this task, these updates are performed by the User-Interface Designer (see Task: Design the User Interface).

Steps

Design the User-Interface Prototype

The design of the User-Interface Prototype is the design of the user-interface itself.
The only difference is the level of detail and rigor of that design. A "complete" user-interface design is usually not
performed prior to prototyping that design. In fact, it is often appropriate to defer detailed user-interface design
until after several iterations of a prototype have been built and reviewed. For more information on
user-interface design, see Task: Design the User Interface.

Implement the User-Interface Prototype

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.

Get Feedback on the User-Interface Prototype

It is important to work closely with users and potential users of the system when prototyping the user-interface.
This may be used address usability of the system, to help uncover any previously undiscovered requirements and to
further refine the requirements definition.

Feedback on the User-Interface Prototype can be obtained through focused reviews, and testing. For information on
usability testing, refer to Concept: Usability Testing.