Activity:
| ||||||||||||||||
Purpose
| |
| 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
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:
| Resulting Artifacts:
|
| Tool Mentors: | |
| More Information:
See [CON99] for a very complete coverage of creating designs which focus specifically on usability. | |
| Workflow Details:
|
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).
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.
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:
- 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.
Detail the Design of the
User-Interface Elements
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 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:
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 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:
- searching among multiple objects
- sorting multiple objects
- browsing hierarchies of multiple objects
- selecting multiple objects
Refer to Guidelines: 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:
- whether "on-line help," including "wizards," should be provided
- whether an "undo" operation should be provided, 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 Guidelines: User Interface (General) for more detail.
|
Rational Unified Process
|
