Activity: Prototype the User-Interface

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 activity, these updates are performed by the System Analyst (see activity: Elicit Stakeholder Requests). If it is discovered that refinements to the user interface design is needed as a result of this activity, these updates are performed by the User-Interface Designer (see activity: Design the User Interface).

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 activity: 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 (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 Concepts: Usability Testing.

Rational Unified Process