The Three Pieces of the Jigsaw Puzzle

Use cases have been around for a long time and have pretty much become the de facto method for specifying behavioral requirements. And yet despite this, people still struggle with use cases because they find them too abstract. Use cases have a lot of value to add, but we need to get better at writing them. One way to do this is to make the use case writing process more concrete through the use of personas and scenarios.

The result of combining personas with use case scenarios is a practice that is surprisingly well-geared toward getting the product design right, by identifying the user’s goals and designing the product UI around those goals.

Before we launch back into the mapplet example, it’s worth briefly defining the three items with which we’re extending ICONIX Process: interaction design, personas, and interaction scenarios.

Interaction Design

Interaction design is the art and science of designing a product around the user’s needs. The goals of interaction design are pragmatic and incredibly relevant in today’s software industry: to design a product that is easy to use, learnable, and eminently suited to the person using it. (If you’re interested in interaction design, the book Interaction Design: Beyond Human-Computer Interaction[1.] is as good a place to start as any other.)

The effect of interaction design is most obvious with the design of physical devices (e.g., a portable MP3 player). If it’s designed for, say, Neo (a techno-geek), it will be covered in tiny buttons, LCD displays, and connectors. It will probably also be highly programmable. If it’s designed for Arthur (an arthritic late-adopter who listens to Gershwin and not much else), it will consist mostly of a big Start/Stop button.

A key stage of interaction design is to define a small set of target users: personas.

Personas

Personas, as an interaction design tool, were first introduced by Alan Cooper in his book The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.[2.] He also describes them in more detail in About Face 2.0: The Essentials of Interaction Design.[3.] Also see Karl Wiegers’ book 4.]

As described earlier, a persona is a description of a fictional person. The persona is a “typical” end user at whom the software is being targeted. In UML terms, a persona can be thought of as an instance of an actor.

Matt describes combining persona analysis with use cases in his article titled “Interaction Design: Persona Power.”[5.] The approach proposed by Matt involves using personas to drive the UI. The approach described in this chapter, though similar to Matt’s, has more to do with using personas to identify specific features.

Interaction Scenarios

In ICONIX Process, use case scenarios are normally written in a very minimal format (which is especially useful when you have 500 use cases to write!). In this chapter, we introduce slightly “fatter” versions of use case scenarios that are intended to explore in more detail the goals that the user is trying to achieve. We call these fatter scenarios interaction scenarios, because they explore the reasons driving the user’s interaction with the system. As such, interaction scenarios are heavily biased toward the user’s actions.

A use case typically describes the user interacting with the system and therefore consists of “user action/system response” in roughly equal measure. An interaction scenario, however, consists of much more detail about the user’s actions. We’ll explore interaction scenarios with some examples later in this chapter.

Interaction scenarios aren’t the end product, though. (And you probably wouldn’t want to write 500 of them, as they tend to be quite detailed.) They are, instead, a means to an end: transitory artifacts intended to get us to our first goal: the much leaner software use case from which we can derive our sequence diagrams. This process is shown in Figure 10-1.

image from book
Figure 10-1: Personas feed into interaction scenarios, which feed into use case scenarios.

The names of the interaction scenarios are individual instances of the use case. For example, a use case called “Find Nearest Hotel to Specific Location” could include an interaction scenario called “Find Nearest Hilton to My Meeting.” However, we wouldn’t also go on to write “Find Nearest Hyatt to My Meeting,” “Find Nearest Sheraton to My Meeting,” and so on (all the instances). We would just write one or two representative interaction scenarios.

Personas are also used to identify the more abstract actors, which we can then put to use in our use cases (see Figure 10-2). Note that in interaction design, sometimes the opposite approach is preached: using abstract actors to identify concrete personas. Either approach works well given the right circumstances. It’s generally better to look at your own project and use the approach that’s easier for you.

image from book
Figure 10-2: Personas identify actors.

For the remainder of this chapter, we’ll walk through some examples to illustrate how the combined persona analysis/use case process works.

[1.]Jennifer Preece, Yvonne Rogers, and Helen Sharp, Interaction Design: Beyond Human-Computer Interaction (Hoboken, NJ: John Wiley & Sons, 2002).

[2.]Alan Cooper, The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (Indianapolis, IN: Sams Publishing, 1999).

[3.]Alan Cooper and Robert Reimann, About Face 2.0: The Essentials of Interaction Design (Hoboken, NJ: John Wiley & Sons, 2003).

[4.]Karl E. Wiegers, Software Requirements, Second Edition (Redmond, WA: Microsoft Press, 2003).

[5.]Matt Stephens, “Interaction Design: Persona Power,” Software Development Magazine, March 2004.



Agile Development with ICONIX Process. People, Process, and Pragmatism
Agile Development with ICONIX Process: People, Process, and Pragmatism
ISBN: 1590594649
EAN: 2147483647
Year: 2005
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net