This task explains how to conduct GUI design with emphasis on usability.
Purpose
To produce a design of the user interface that supports the reasoning about, and the enhancement of, its usability
Relationships
RolesMain:
User-Interface Designer
Additional: Assisting:
InputsMandatory:
Software Requirement
Optional:
Actor
Stakeholder Requests
Storyboard
Supplementary Specifications
Use Case
Vision
External:
None
Outputs
Navigation Map
Main Description
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 task, these updates are performed by the System Analyst (see Task: Elicit Stakeholder Requests).
Steps
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 Work
Product Guideline: 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 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.