User interface prototypes are an excellent means of exploring your user interface, but unfortunately it is
easy to quickly become bogged down in the details of the user interface and not see the bigger picture.
Consequently, you often miss high-level relationships and interactions within your system's UI. User
interface-flow diagrams - also called storyboards, interface-flow diagrams, windows navigation diagrams, and
context-navigation maps - enable you to model the high-level relationships between major user interface elements
and thereby ask fundamental
usability questions.
In Figure 1
you see the start at a user interface-flow diagram, called a Navigation diagram in RUP, for the university
system. The boxes represent major user interface elements, modeled as you would instances/objects, and the
arrows represent the possible flow between them, modeled as you would transitions in activity diagrams. For
example, when you are on the
Desktop screen, you can use the Students Icon
to take you to the Search for Students screen. Once you are there, you can either go back to the desktop
(going back is always assumed) or go to the
Student Profile screen.
Figure 1. A UI flow diagram.
|
User interface-flow diagrams are typically used for one of two purposes. First, they are used to model
the interactions that users have with your software, as defined in a single use case. For example, a
use case can refer to several screens and provides insight into how they are used. Based on this
information, you can develop a user interface-flow diagram that reflects the behavioral view of the single
use case. Second, as you see in
Figure 1 they enable you to gain a high-level overview of the user interface for your application. This
overview is effectively the combination of all the behavioral views derived from your use cases, the result
being called the architectural view of your user interface (Constantine and Lockwood 1999).
I prefer to take the high-level overview approach, also referred to as the
architectural approach,
because it enables me to understand the complete user interface for a system.
Because user interface-flow diagrams offer a high-level view of the interface of a system, you can
quickly gain an understanding of how the system is expected to work. It puts you in a position where you can
validate the overall flow of your application's user interface. For example, does the flow make sense? I am
not so sure. Why can't I get from
Seminar Details to Professor Information? When you are viewing the information for a seminar,
isn't it possible you might want to view the information for the instructor of that seminar? Furthermore,
user interface-flow diagrams can be used to determine if the user interface will be
usable. If there are many boxes and many
connections, it may be a signal to you that your system is too large for people to learn and understand. |
 |
Unfortunately the UML does not yet support this sort of diagram. In the past I have used a modified version
of a UML collaboration/communication diagram whereas others have suggested modified UML activity diagrams or
even UML state machine diagrams for this. Our solutions all look something like what you see in Figure 1, albeit using slightly different notations. Because the UML is not yet complete
we find ourselves in exactly the situation that the UML is meant to avoid - people using different notations to
model the software that they're building. My hope is that the Object Management Group (OMG) will eventually
define a profile for UI flow modeling. In fact, I'd really appreciate it if you could send them an
email to that effect.
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
Translations
