Persona Power

Software Development

Use cases have become the de facto method for specifying behavioral requirements. Despite this, people still struggle with use cases because they find them too abstract. They’re undoubtedly valuable, but we need to get better at writing them—and one way to do this is through personas and scenarios.

Personas combined with use case scenarios produce a practice that’s surprisingly effective at getting the product design right. How? By identifying the user’s goals and designing the interface around them. I’m going to discuss a very specific technique: developing use cases in the context of personas. This is distinct from writing use cases with other interaction design artifacts, such as screen prototypes or UI walkthroughs.

In a moment, I’ll connect the three elements—interaction design, personas and use cases—with an example project. But first, a brief definition of each of these three elements.

Interaction design is the art and science of designing a product to accommodate the user’s needs. The goals of interaction design are pragmatic and relevant in today’s software industry: to create a product that’s easy to use, learnable and eminently suited to the person using it. (If you’re interested in interaction design, Jenny Preece, Yvonne Rogers and Helen Sharp’s Interaction Design [Wiley, 2002] is a good place to start.) A key stage of interaction design is to define a small set of target users: personas.

Personas, as an interaction design tool, were first introduced by Alan Cooper in The Inmates Are Running the Asylum (Sams Publishing, 1999), and described in more detail in his book About Face 2.0 (Wiley, 2003). A persona is a description of a fictional user, including his name and brief sketches of his goals, aspirations, job, ability level—anything that might be relevant to how he uses and perceives the product you’re designing. A persona is to an actor as a usage scenario is to a use case.

Use cases are a well-known method of defining a product’s behavioral requirements. They’re easy to write, as long as you follow a coherent set of guidelines (in particular, keep them brief and write them in active voice in present tense). A set of use cases should also be written with an accompanying domain model, and some “mock-up” screenshots to get a feel for the UI. A good introduction to writing effective use cases (and how to get from use cases to code) can be found in Doug Rosenberg and Kendall Scott’s Use Case Driven Object Modeling With UML (Addison-Wesley, 1999).

Example Project

Let’s say we’re writing a website for doing house searches. A potential buyer enters her search criteria (location, price range, number of bedrooms and so on) and then is presented with a list of houses matching those criteria.

To a large extent, the website’s level of detail is dependent on the types of users whom the website targets—an ideal opportunity to write some personas!

If we have a marketing department that has readily produced some demographics, we’re off to a flying start. For example, we might already know that the most common user is a woman in her mid-thirties. We might also have some details about her typical occupation and so on. Let’s tie this into a single persona to get an idea of our target user:

Maria, age 35, lives in Southwest London. She currently owns a 1-bedroom flat but is looking to find a 3-bedroom house for herself, her husband Jim and their potential children. Although Jim is also interested in the house search, it’s primarily Maria who is doing the actual hunting. Maria works full-time as an office administrator, so she’s computer literate in the sense that she uses applications such as Excel on a daily basis and regularly browses websites.

It’s vitally important to write the persona before we write the use cases, because the use cases are written in the context of the persona. Whereas a use case normally refers to “the user,” we’ll refer to Maria by name.

This approach helps to keep the use cases focused because we’re writing them with a specific user in mind. You’d be surprised how differently the use case can turn out when it’s based on different people with different backgrounds, motives and levels of ability. (Later on, you’ll see an example of how changing the persona can radically affect a use case.)

[click for larger image] House Search Including the actual persona (Maria) on the use case diagram is optional. The important part is that the use case text is written in the context of the persona, not the actor.

We could also create a use case called “Add a house for sale,” reserved for real-estate agents—in which case we’d need a whole separate area of the site for registered real-estate agents. We’d also need to define a separate persona, because the real-estate agent is a different class of user (a different actor), with different privileges and a different set of use cases.

The rule of thumb is that each user class (a.k.a. role or actor) should normally have at least one persona defined. However, one persona might belong to several roles if those roles are fulfilled by the same person. “Single Persona/Multiple Roles” shows how this should be represented.

In “Single Persona/Multiple Roles,” Bill is shown as an instance of two different actor types (Foreman and Shelf Stocker), indicating that in his day-to-day work, he fulfills both roles.

Using the approach described in this article, actors and use cases are clearly like roles and classes—abstract concepts—while personas and scenarios are more like instances of a role or a class, so it wouldn’t make sense, for example, to draw a persona pointing to a use case. Instead, personas should point to scenarios, and actors should point to use cases.

Back to our house search example. Here’s the basic use case scenario for what is probably the most common activity: Search for a house.

Maria visits the home page of the website, which has a basic search form. She then enters her search criteria: 3-bedroom house, Wimbledon, > £350,000. She clicks the Perform Search button, and the system returns a list of matching houses (about 30 houses in this case), divided into separate pages, 10 houses per page, listed in increasing order of value. There’s nothing to interest her on the first page, so Maria clicks “Next page.” The next 10 houses appear. She sees a house that interests her, so she clicks the thumbnail to get more details and a bigger set of photos. The details load in a separate pop-up window, so her main search isn’t disrupted.

[click for larger image] Single Persona/Multiple Roles Bill is shown as an instance of two different actor types (Foreman and Shelf Stocker), indicating that in his day-to-day work, he fulfills both roles.

We should also write some alternative scenarios so that we get the exceptions and fringe cases—all the possible ways that the basic search might be used. For example:

Alternative scenario 1. No houses match Maria’s search criteria. The results page should include the basic search form with Maria’s previous details, so that she can adjust her search. The cursor should automatically be in the Price field, as this is the most likely field that she’ll adjust.

Alternative scenario 2. Some houses match Maria’s search, but none of them really catches her interest. She clicks the “Search again” button. The search form is displayed, still containing her previous details.

Normally, we’d also include all the possible failure modes in the list of alternative scenarios. The failure scenarios describe how the system should react when things go wrong (for example, when a search fails because the database connection has been lost).

When do we have enough alternative scenarios? When you and your team can’t think of any more. They’re quick to write, yet they’re a very effective way of exploring all the different ways that the system might be used.

Combining personas with use cases provides an additional way of discovering alternative scenarios. These alternatives prove invaluable later on when we get to the design, because the design accounts for the alternative cases.

Defining Different Users

Changing the persona can dramatically affect your use cases. For example, let’s say that Maria isn’t our target user after all. Instead, meet Fergus.

Fergus is a non-computer-literate long-haul truck driver. He’s looking for a house to buy, but doesn’t have his own PC, so Internet access is limited to Internet cafés and the local library.

In Fergus’s case, we’d design the website differently. One approach might be to cut down the amount of information presented to Fergus in one go, instead prompting him with a series of questions to find out the sort of property he’s looking for. However, people can find it quite affronting when a computer prompts them with questions. It puts the user in a subordinate position, reversing the perceived “master-servant” roles so that the user feels as if he’s running errands for the mighty computer. Putting poor Fergus through a series of questions without giving him anything in return until the very end could be quite off-putting—in fact, he’d probably give up and return to the local newspaper’s property listings.

Instead, let’s take a radically different approach. Our Search for a house use case could be as follows:

Fergus visits the home page of the website. It’s almost empty apart from some brief explanatory text. Fergus clicks the Begin Search button, and a small collection of properties is displayed (10–20 properties—see Footnote 1). Next to each property is a series of options (see Footnote 2). Fergus uses these options one at a time to narrow his search to a more specific set of properties. As he proceeds, the result set becomes more relevant to what he’s seeking.

Alternative Scenario 1. Fergus clicks the Restart Search button, which returns to the initial search results page with no search parameters set.

Footnote 1. The collection of properties is always restricted to a single page, but represents a broad variety made via an algorithm intended to return as wide a range of selections in as few actual properties as possible.

Footnote 2. The options available next to each property are as follows: More Like This, Not This Type of Property, Not This Area, More Expensive, Less Expensive.

Notice that, rather than cowing Fergus into answering a series of questions, this approach actually empowers him because he’s always in control. He gets results straightaway with little initial effort, and he gets to tell the computer what to do next rather than the other way around.

Of course, the same search process would be quite inefficient and frustrating for a computer-savvy user like Maria, who’s used to filling out search forms and wants to get an exact result set as quickly as possible. So designing the UI is fundamentally about identifying a target user, or persona, and designing it around that user.

Identifying Actors and Use Cases

In his book Writing Effective Use Cases (Addison-Wesley, 2000), Alistair Cockburn states, “Write down what the system detects, not just what happened. Don’t write ‘Customer forgets PIN.’ The system can’t detect that they forgot their PIN. Perhaps they walked away, had a heart attack, or are busy quieting a crying baby. What does the system detect in this case? Inaction, which really means it detects that a time limit was exceeded. Write, ‘Time limit exceeded waiting for PIN to be entered,’ or ‘PIN entry time-out.’”

This is absolutely correct when we’re writing the use case as a description of the system behavior, but how do we determine the necessity of a PIN entry time-out in the first place? This is a prime example of the way interaction design can be used as a means of identifying use case scenarios and failure conditions.

We want to end up with a use case scenario that describes what the system detects (“PIN entry time-out”), not what’s happening externally (“user quieting a crying baby”). However, to get there, we can use personas, various UI diagrams and interaction scenarios. The interaction scenarios would include information like “user quieting a crying baby,” because we’re interested in describing the user’s world and what’s going on around him while he’s using the system. This gives us a helpful perspective on how a user will really interact with our product, and it’s also a good way of identifying alternative scenarios and failure modes that we might otherwise have missed.

So we’d start by writing lots of interaction scenarios for our target persona (possibly identifying new personas in the process). Once we have a decent set of scenarios, we can begin to extract the more abstract use cases from them. The purpose now is to lose all the “external” descriptions that have been so useful up until this moment for driving the UI design, but which would only clutter the finished use case text.

This approach is the reverse of what you’d normally expect—we’d conventionally start by identifying the use cases, and then break these down into more concrete scenarios. Instead, we’re starting by identifying the concrete (personas and scenarios) and using them to identify the abstract (actors and use cases).

In practice, it’s beneficial to combine both approaches. A brainstorming session—in which the team identifies both scenarios and use cases (having first settled on one or two personas)—can produce a thorough analysis of the application. Product design at these early stages of development is an organic process, and you don’t strictly complete one activity before moving on to the next. Instead, one activity feeds incrementally into the other, and vice versa.

Reining in Complexity

As we identify more personas, scenarios, actors and use cases, the product inevitably becomes more complex. It’s easy to lose track of our original “clear and simple” product design. We can manage this design entropy, to an extent, by grouping and rearranging the various artifacts and expanding individual scenarios into additional use cases where necessary.

But how do we know when to split personas, or roll up scenarios into new use cases? From an interaction design standpoint, the process is all about discovering how different the UI must be for each target user.

In fact, having identified our first-pass set of personas, we can take four possible approaches depending on the personas’ differences, as follows (listed here in order, from most similar to most disparate; not by coincidence, this list is also in order of complexity, from simplest to most complex):

1. Create just a single unified persona, an instance of one or more actors.
2. Create separate personas but define them as instances of the same actor; for example, we can call the roles “maria : House Buyer” and “fergus : House Buyer.” These names would be given to the actors in the sequence diagrams, for example.
3. Create a separate actor for each persona. We’d do this if the personas are different enough to warrant writing separate use cases for each actor, not just additional scenarios.
4. Create separate user interfaces for each persona (essentially, different products).

The first approach is always the holy grail. We want to make the product as focused and simple as possible, and the best way to do this is to design the product around a single target user. Of course, this isn’t always possible. As the product becomes more complex, we identify more target users. This complexity is managed by moving gradually (or is that grudgingly?) to the next approach in the previous list, and the next, and so on. As we do this, we end up with a more complex application. By actively controlling these steps as we design the product UI, we keep the product as focused as possible, and just complex enough for what its target users are trying to achieve.

It’s About Interaction

Interaction design isn’t just about designing the UI’s “look”—it’s also about determining how the UI will behave and respond to user inputs. This is why interaction design and use cases work so well together, especially when combined with personas.

The effect of interaction design is most obvious with the design of physical devices (for example, a Walkman-style MP3 player). If it’s designed for, say, Neo (a techno-geek), it’ll be covered in tiny buttons and LCD displays. If it’s designed for Arthur (an arthritic late adopter who listens to Gershwin), it’ll have a big start/stop button and not much else.

Interaction design on its own gets you to a certain stage in the design process, but it doesn’t take you all the way to source code. When it’s combined with something like Doug Rosenberg’s ICONIX Process, you’ll have a software development lifecycle that encourages both focus and completeness all the way from user interface design to code.