On Use Cases, Storyboarding, and User Interface Design

On Use Cases, Storyboarding, and User Interface Design

Use Cases and User Interfaces

Remember our formal definition of a use case.

A use case describes sequences of events between an actor and a system that yield a result of value to the actor.

While it's a bit abstract, this definition handles the generic situation quite well. It allows us to express behaviors between systems of systems, between systems and devices, and so on. However, for those development teams implementing systems that directly support human users via Web browsers, client-side graphical user interfaces (GUIs) and the like, development of the use cases may be done in parallel with the design and implementation of a series of user interfaces that users can use to accomplish their larger objectives. Use cases such as "Edit and Approve Machine Translations" and "Establish Material Replenishment Signals to External Suppliers" imply a whole series of interactions (use-case steps) between a user and the system, which are accomplished via a variety of user interfaces that the designers construct for these purposes.

When this is the situation, the world of user interface design and the world of use-case specification tend to lead parallel lives. For example, inside the context of a specific use case, the team must decide

what choices the user makes given the screens, dialog boxes, and so on that we have presented to the user, what the system does based on those selections, and what screens, choices, and so on the system presents to the user.

In other words, each step in a use case is achieved via the presentation of a GUI of some kind, followed by a user selection of some kind, followed by a presentation of a new GUI that moves the user to the next system context, and so on. While it's easy to see how these things relate, teams inevitably come to the following conundrum .

How can I express a use case if I haven't designed all the GUIs yet?

How can I possibly design a set of GUIs to implement a use case that is not yet elaborated?

Fair questions, indeed. Let's see if we've learned any new constructs that can help us address this apparent conundrum.

Use Cases and Storyboarding

In Chapter 13, we described storyboarding as basically any technique a team can use to express system behavior, design, or implementation intent to a prospective user. A storyboard defines

• Who the players are

• What happens to them

• How it happens

If the player is a specific user and the interaction is between that user and the user interface, then storyboarding can help us describe how we are approaching the interaction, and we can use iterative and incremental techniques to converge on the GUI and the use case at the same time . In order to address our conundrum, let's apply the use-case technique, the storyboarding concept, and our GUI design tools together with a presentation technique that will allow us to express ourselves to a user or other stakeholder.

A Use Case Storyboard Example

Suppose you want to elaborate a section of a use case that would describe how a user inserts graphic clip art from an online source into a document. Perhaps the sequence of events appears as follows .

You can use Microsoft PowerPoint as your storyboard presentation tool to build one PowerPoint slide for each of the steps in the use case to show the user how you intend the system to work. For example, Figures 14-3 through 14-6 show a series of storyboard slides for the first four steps of the Inserting Online Clip Art use case.

Figure 14-3. Storyboard slide for step 1 of a use case

Figure 14-6. Storyboard slide for step 4 of a use case

In this fashion, you can develop the use case and the GUIs in parallel while involving the user in the concept review process at the same time.