Activity: Design the User Interface

Purpose To produce a design of the user interface that supports the reasoning about, and the enhancement of, its usability
Role: User-Interface Designer
Frequency: In practice, the design of the user interface is usually performed in conjunction with the prototyping of the user interface (see activity: Prototype the User Interface). While you design the user-interface, you should continuously prototype your design and expose it to others, taking into consideration any project-specific guidelines. That being said, a "complete" user-interface design is usually not performed prior to prototyping that design. It is often appropriate to defer detailed user-interface design until after several iterations of a User-Interface Prototype have been built and reviewed
Steps Describe the Characteristics of Related Users Identify the Primary User-Interface Elements Define the Navigation Map Detail the Design of the User-Interface Elements These steps are presented in a logical order, but you may have to alternate between them, or perform some of them in parallel. Also, some steps may be optional, depending on the complexity of the specific user interface under consideration.
Input Artifacts: Actor Project Specific Guidelines Software Requirement Stakeholder Requests Storyboard Supplementary Specifications Use Case Vision	Resulting Artifacts: Navigation Map
Tool Mentors:
More Information: Guideline: Representing Graphical User-Interfaces Guideline: User Interface (General) See [CON99] for a very complete coverage of creating designs which focus specifically on usability.

Workflow Details:

Analysis & Design
- Analyze Behavior

When designing the user-interface, keep in mind any Storyboards created during requirements elicitation, the user interface guidelines in the project-specific guidelines, as well as any existing User-Interface Prototypes. 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).

Describe the Characteristics of Related Users

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 Guidelines: Actor, Characteristics for details.

Identify the Primary User-Interface Elements

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).

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

Define the Navigation Map

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:

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

Detail the Design of the User-Interface Elements

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

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 Guidelines: 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:

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 shortcut 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:

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: