User Interface Flow Diagrams (UI Storyboards): An Agile Introduction

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 Source

Translations

Recommended Reading