Describe the characteristics of the (human) users that will interact with the system to perform the requirements being considered in the current iteration. Focus on describing the primary users since the major part of the interactions involve these users. This information is important for the subsequent steps below.

Collaborate with the System Analyst to determine if any changes to the Actor description are needed to reflect the characteristic descriptions. Refer to Work Product Guideline: Actor, Characteristics for details.

Looking at the requirements being considered in the current iteration (especially any  Use Cases and/or Storyboards), identify the primary windows of the system's user interface. By "primary" we mean those windows that the user will interact with the most (those user-interface elements that are central to the user's mental model of the system). Primary windows contain menus and may contain sub-windows or forms. Primary windows are the windows the user navigates between. Non-primary windows may end up as part of a primary window.

The main primary window should be the window that is opened when the user launches the application. It is normally always open as long as the application is running, and is the place where the user spends a considerable part of his "use time." Since it is always open and since it constitutes the user's first contact with the system, it is the foremost vehicle for enforcing the user's mental model of the system. The main primary window is commonly referred to as the "home page".

Attempt to group user-interface elements together into the same primary window if they need to be shown together or in spatial relation to other user-interface elements. However, this is not always possible due to limitations in screen area. Note that the average object volumes is an important input to this step, since they state how many objects that potentially need to be shown at once. Too many objects may imply that they cannot all appear on the same window; instead, a primary window may contain a compact representation of the objects and then separate primary windows may be defined for each of the objects (or a set of objects).

The following are some recommendations for primary windows:

• windows that are central to the user's mental model of the system
• windows that the user will spend most use time in
• windows that provide the initiation of use cases

Keep in mind that the goal is to minimize the number of primary windows and the number of navigation paths between them.

Based on the identified set of primary windows, and the Storyboards, define the system's Navigation Map.

The Navigation Map should include the primary user-interface elements and their navigation paths. It does not need to contain all of the possible paths through the user-interface elements, just the main pathways. The goal is for the Navigation Map to serve as a road map of the system's user interface.

An most obvious candidate for "top" user-interface element in the Navigation Map is the main primary window (the window where the user spends the majority of his/her use time).

The Navigation Map should make it clear "how many clicks" a user needs to make to get to a specific screen or piece of functionality. Generally, you want to have the most important areas of the application only "one click away" from the primary window. In addition to adding needless interaction overhead, window navigation paths that are too long make it more likely that the user will "get lost" in the system. Ideally, all windows should be opened from a main primary window, resulting in a maximum window navigation length of two. Try to avoid window navigation lengths greater than three.

The Navigation Map should also adhere to and reflect the usage metaphor for the system's user interface, as documented in the project-specific guidelines.

A variety of representations may be used for the Navigation Map. Some examples include:

• a hierarchical "tree" diagram, where each level of the diagram shows the number of clicks it takes to get to a specific user-interface element
• free-form graphics with custom icons
• UML class diagram where classes are used for user interface elements and associations are used for navigation paths

The selection of which representation to use is specified in the project-specific guidelines.

At this point, the high-level user-interface design is complete:

• The primary windows have been identified.
• The user-interface elements and their navigation paths have been defined (the Navigation Map).

The detailed design of the user-interface elements can now be performed. The following are different aspects of designing the user-interface elements. Each of these are described below:

• Design the Visualization of the Primary Windows
• Design the User Actions of the Primary Windows
• Design Miscellaneous Features

Design the Visualization of the Primary Windows

The visualization of the primary windows, and the main primary window in particular, will have a significant impact on the usability of the system. Designing this visualization is about determining which parts (properties) of the contained user-interface elements should be visualized. The Storyboard flows of events can be used to help prioritize which properties to show. If the user needs to see many different properties of the user-interface elements, you may implement several views of a primary window, each view visualizing a different set of properties. Designing this visualization also means that you have to look at how the properties of the contained user-interface elements should be visualized, by using all visual dimensions. For details, refer to section "Visual Dimensions" in Guideline: User Interface (General).

Where possible, attempt to identify "common denominators" across the elements to be displayed in the primary windows. By visualizing common denominators in some dimension, the user can relate the elements with each other and start to see patterns. This greatly increases the "bandwidth" of the user interface.

Example:

Assume you have a customer service system, where you want to show aspects like:

• the customer's complaints and questions over time
• what products the customer has purchased over time
• how much the customer has been invoiced over time

Here, a common denominator is "time." Thus, displaying complaints/questions, purchases and invoices beside each other on the same horizontal time axis will enable the user to see patterns of how these are related (if they are).

Design the User Actions of the Primary Windows

This is where you decide how to "implement" the user actions that can be invoked for the primary windows. It is common that the user actions of the primary windows are provided as menu items in a menu bar, and are provided as an alternative and complement via pop-up menus and toolbars.

For each primary window, define the menu(s) and menu options. For example, in a document editor, there is an Edit menu, grouping cohesive operations such as Cut, Copy, etc.

Some user actions may require a complex interaction with the user, thereby justifying a secondary window of their own. For example, in a document editor, there is a Print operation on a Document that, due to its complex interaction, justifies a separate dialog window.

If a large number of objects are to be visualized in a window, it may be necessary to design user actions involving these objects. The following are some examples of such user actions:

• searching among multiple objects
• sorting multiple objects
• browsing hierarchies of multiple objects
• selecting multiple objects

Refer to Guideline: User Interface (General) for more detail.

Design Miscellaneous Features

Add the necessary dynamic behavior to the user interface. Most dynamics are given by the target platform, like the select-operate paradigm, open by double-clicking, pop-up menus on right mouse button, etc. There are, however, some decisions you need to make, including:

• how to support window management
• what session information, like input cursor position, scroll bar position, opened windows, window sizes, relative window positions, etc., to store between sessions
• whether to support single or multiple document interfaces (SDI or MDI) for your primary windows

Also evaluate other common features that can enhance usability, including the following:

• whether "on-line help," including "wizards," should be provided
• desirability of an "undo" operation, to make the system safe for exploration
• whether "agents" should be provided, to monitor user events and actively suggest actions
• whether "dynamic highlighting" should be provided, to visualize associations
• whether user-defined "macros" should be supported
• whether there are specific areas that should be user configurable

Refer to Guideline: User Interface (General) for more detail.