How Persona Analysis Was Used to Drive the Requirements

In this section, we describe briefly how persona analysis (an interaction design technique) was used to help drive release 2 and create a more focused product. Persona analysis (as an extension to ICONIX Process) is described in more detail in Chapter 10.

Using Personas to Identify Requirements

A persona is a description of a “typical” end user that the product is targeting, which focuses on her goals when using the product. The persona is fictional, but the end users’ goals that we identify should be the result of in-depth research, including interviews with actual users.

For release 2 we began by defining two personas, Bob and Carol. We discuss both these personas in more detail in Chapter 10, but for now here’s Carol’s persona:

Carol is single and in her late twenties. She’s heading over to this year’s Mardi Gras in New Orleans. She knows that she’s going to be out partying, and she wants a hotel with a spa (where she can get a massage), an indoor pool, and a Jacuzzi. Because she’s on a budget, she wants to stay at a hotel in the midrange price band, and she wants it located on Bourbon Street. So she’s interested in amenities, price, and location.

We use this persona to write an interaction scenario (a detailed use case scenario that describes what the user is doing externally to the system). Here we define external behavior as being what the user is doing outside the system boundary and internal behavior as being what the system itself is doing. The interaction normally described in a software use case is the external behavior prompting responses from the internal system (as in, “The user clicks this button. The system responds with this list”).

An interaction scenario is different from an ICONIX-style use case (for brevity’s sake, let’s call this type a software use case). An interaction scenario describes an equal or greater amount of external behavior than internal behavior. You’ll find some examples of interaction scenarios and how they relate to software use cases in Chapter 10.

Describing external behavior is useful (from an interaction design standpoint) because it helps to keep us focused on the user’s goals, what the user is trying to achieve and, above all, why the user is trying to achieve those particular goals. It’s surprising how differently the use case can turn out. You may even discover that a completely different use case is needed.

This contrasts greatly with software use cases. Software use cases are much shorter and generally are more generic, and they describe purely the user’s interaction with the system. This, of course, makes them both easier and quicker to write.

Our goal is to create a few of these detailed interaction scenarios and (eventually) to discard them in favor of smaller, more generic software use cases that define the user’s interaction with the system in more precise terms. Once we get to this stage, the external behavior that had been so useful earlier on now becomes excess clutter, so we get rid of it.

So, using this analysis, we identified that Carol would benefit from being able to find the nearest hotel to Bourbon Street. The interaction scenario we created was called exactly that: “Find the Nearest Hotel to Bourbon Street.” That’s pretty specific, so the eventual software use case that we ended up with was a cut-down, more generic version called “Find a Hotel.”

Upon further analysis, we discovered that a “typical” business user would also want to find a specific hotel chain in a city (e.g., a Hilton Hotel in San Diego). So the interaction scenario we created for this was called “Find a Hilton Hotel in San Diego.” This eventually turned into a cut-down software use case called “Filter Hotels.”

Was This the Right Time for Persona Analysis on the Mapplet Project?

Interaction design works best when applied to a project in its very early stages (ideally when the first use cases are being written). However, as the mapplet is a “real-life” project, not everything in it happens exactly by the book. In fact, because it’s an agile project, we’re adapting the process to the project’s needs as we go along.

For example, the persona analysis was not part of the inception planning. It happened later (not until analysis began for the second release, in fact). Would the project have benefited from the persona analysis taking place right at the start? Possibly so. As we maintain in this chapter, the earlier you apply interaction design to your project, the better.

In our case, the functionality written in the first release was limited to the most basic feature set while the developers explored the features available in the (then beta) ESRI Map Server. So release 1 was essentially about grabbing the low-hanging fruit and getting something up and running on the VResorts site.

We got a working mapplet page connected to the mapplet server and hooked it all up to the “live” website. So in this way, the mapplet immediately began to provide business value to the customer. Additionally, we were able to treat this first release like an early prototype, and we used it to get a better idea of how the system should work. The value we gained from this first release was that we can now shape the website however we want in the second release.

HTML proved suitable for this purpose because it’s relatively cheap to change. Other projects (e.g., rich-client GUI applications or enterprise workflow systems) may not have this luxury. The key is to tailor the process to fit the project.

Of course, this first release wasn’t written blind to the user’s requirements. We did some use case analysis and modeled the solution (over a couple of modeling iterations) before coding it up.

In the second release, we’re starting to extend the mapplet’s functionality and embed it further into the website. So before we go any further, we should definitely “put down our tools” for a moment and do some deeper analysis of the ways in which the user will want to interact with the system.

AGILE SCORECARD: GROWING PAINS

The approach we’ve taken on this project highlights the difference between a totally up-front project and an agile project. We don’t have to do all the modeling up-front. We can make midcourse corrections to the model based on feedback from the already built earlier releases. A term for this that we first heard 20 years or so ago (long before “agility” existed) is that we’re “growing” the software.

For example, 20 years ago in his book The Mythical Man-Month, Fred Brooks discussed the evolution of the software development metaphor (a necessity as the size and complexity of software systems increase and the expected time to market decreases), from “writing” a program, through “building” a program, to incrementally “growing” a program:

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach.^[1.]

These days, feature-driven planning (as described in Chapter 9) and all the method constructs surrounding it allow us to “grow” software incrementally, without lapsing into the Constant Refactoring After Programming syndrome.

^[1.]Frederick P. Brooks, Jr., The Mythical Man-Month, Twentieth Anniversary Edition (New York: Addison-Wesley, 1995), p. 201.