Building the UI Around a Target User

The level of detail that we put in the website, and in particular in the search function, is dependent to a large extent on the types of users at whom the website is being targeted. This is an ideal opportunity to define our first persona!

If we have a marketing department that has readily produced some user demographics, then that information can be used (at a very broad level) to get us started. For example, we might already know that the most common user will be a vacationer in her late twenties to early thirties. Plus, we might have some details about the user’s typical occupation, what her likely goals for using the website are, and so on. That isn’t the whole story, of course—we don’t want to base our persona just on marketing statistics! To get a realistic story of our target user, we also need to interview real-life users and build up a complete picture. We can then boil this mass of real-world information down to a more concise description of our target user. So, here’s the persona for Carol:

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.

It’s vitally important to write the persona before we write the interaction scenarios, because the interaction scenarios will be written in the context of the persona. This is an important point: whereas normally a use case scenario refers to “the user,” our interaction scenarios are going to refer to Carol by name. They’re also going to be driven by Carol’s goals.

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 an interaction scenario can turn out when it’s based around different people with different backgrounds, motives, and levels of ability.

Writing Interaction Scenarios to Validate the Existing System

With the mapplet, because we’re extending what is now an existing system, we’ll start with an interaction scenario that covers the basic functionality from release 1. This serves as a sanity check, proving that what the team has created so far is correct for the users’ needs. It also forms a jumping-off point, a “base camp” for adding new interaction scenarios that describe the new features we want for release 2.

So without further rambling, here’s the basic interaction scenario for probably the most common mapplet activity: finding the nearest hotel to a specific location. As described earlier, interaction scenarios are specific instances of a use case description, so they appear as part of a use case.

Use Case: “Search for a Hotel Using the Mapplet” 

Interaction Scenario: Carol goes to New Orleans for Mardi Gras

Persona: Carol

Carol visits http://smartmaps.vresorts.com. She moves her mouse over the New Orleans icon, sees the map tip displaying the names of the individual destinations in that region, drills down into the Map Destination page for Louisiana, and clicks the Show Map button next to New Orleans. The system displays a map of the French Quarter along with check boxes for price-band filtering, check boxes for amenity filtering, and a pop-up menu showing a list of hotel chains.

Carol deselects the Luxury price band, since she’s on a budget; checks the boxes next to Bar/Lounge, Pool, Fitness Center or Spa, and Room Service; and then clicks the Update Map button. The system queries the hotel database and displays icons for all hotels that match her search criteria, along with a legend below the map, which specifies the active filtering criteria. One of the hotels is on Bourbon Street, which is where Carol wants to stay. She selects the Ramada Plaza Inn on Bourbon Street, and then she clicks the View Hotel Brochure link in the hotel information pop-up window. After viewing the brochure, she clicks the Make Reservation button and books a room.

Alternate Scenario: None of the hotels near Bourbon Street is quite right for Carol’s needs (they’re too expensive), so she zooms out to find some cheaper hotels in a slightly wider search area.

The screenshot in Figure 10-3 shows release 1 of the mapplet in action. This can be used as a form of validation (a visual acceptance test) by comparing it with the prototype screenshot shown back in Figure 7-1.

image from book
Figure 10-3: Carol finds a hotel right on Bourbon Street!

So it looks as if we’re in pretty good shape for the second release. No major changes to the existing system are required. However, there are still several new features that we want to add to the mapplet, so we need to write some scenarios that describe these new features.

Using Interaction Scenarios to Describe New Features

Release 1 covered the common or garden-variety vacationer (booking vacations being the most common usage of the VResorts site). For release 2, we add slightly more esoteric (but still useful) functionality that enables the website to cover a broader range of customers.

Let’s now introduce our second persona, Bob, who represents this new breed of customer:

Bob, who is a frequent traveler, has a Hilton Honors account. He wants to stay at a Hilton hotel whenever possible because he’s saving his Hilton points for a trip to Hawaii. So he wants a “Show Me the Nearest Hilton to My Meeting” capability. Unlike Carol, Bob’s on an expense account, so he’s not concerned about price-band filtering as much as he is about which hotel chain he stays at. He also wants quick access to driving directions to his business-meeting site.

It looks as if Bob’s search requirements are different from Carol’s. Bob already knows the location of the hotel at which he wants to stay, and he’s looking for a hotel from a specific hotel chain (Hilton) near that location, so he’ll go directly to it. Carol, on the other hand, also knows the area in which she wants to stay, but she’s more concerned with specific amenities (spa, bar, etc.) than which chain the hotel belongs to.

We can describe Bob’s interaction either as alternate scenarios in the same use case as Carol’s or as an entirely separate use case. It really depends how different their behavior is. The main thing, however, is to not spend ages deciding which way to go. Pick a method and go with it. As you start to flesh out the scenarios, it will quickly become obvious whether or not they belong in the same use case.

Modeling Tip 

In true agile tradition, nothing is ever set in stone. You evolve the model as you go along, iterating back and forth, and moving pieces around until it all makes sense.

For our example, both Bob and Carol are searching for a hotel, so that suggests that they need to share the same use case. In fact, there’s another similarity: they’re both looking for a hotel near some location or other. Carol is searching for a hotel near Bourbon Street for Mardi Gras, and Bob is searching for a hotel near his San Diego business-meeting location (as we’ll see in the following interaction scenario). So for now, let’s add Bob’s search as another interaction scenario to the same use case that we added Carol’s interaction scenario to (the “Search for a Hotel Using the Mapplet” use case).

Use Case: “Search for a Hotel Using the Mapplet” 

Interaction Scenario: Bob books a business trip to San Diego

Persona: Bob

Bob travels a lot on business and has a meeting in San Diego. He wants to stay at a Hilton hotel because he’s earning frequent traveler points and is close to getting a free weekend in Hawaii. He visits the VResorts San Diego Map Destination page and clicks Show Map. Then he types San Diego in the City field, chooses Hilton from the pop-up menu of hotel chains, and clicks the Update Map button. The system searches the hotel database and displays a citywide map showing all Hilton hotels, along with a legend showing the active filter criteria underneath the map. Bob browses over the Hilton hotels, clicks the View Brochure link on the one he wants, and books his reservation.

Alternate Scenario: Bob knows his client’s zip code, so after generating the citywide display as just described, he types it into the Zip box and clicks the Zoom To button. The system displays a map showing all Hilton hotels in the target zip code. If no Hilton hotels are found, Bob clicks the Zoom Out icon until the nearest one shows up. After he finds a Hilton hotel, he clicks the View Brochure link on the hotel pop-up and books his reservation.

While adding this scenario for Bob, we also thought of some additional alternate scenarios. Let’s add those in (associated with Bob rather than Carol for now, because we’re still in a Bob frame of mind):

  • Alternate Scenario: Incomplete address. Bob knows his client’s zip code but doesn’t have the complete meeting address.

  • Alternate Scenario: No Hiltons found within default AOI. The system displays the map with no hotel icons. Bob enlarges the AOI by clicking the Zoom Out button. The system requeries and displays some hotels on the map. Bob also has the option to pan (scroll) the map.

  • Alternate Scenario: Bob wants driving directions. He clicks the Get Driving Directions link. The system remembers the meeting address that Bob entered on the Query Filter screen and displays the Driving Directions screen, with the hotel address and the meeting address prepopulated, and Get Directions to This Address buttons underneath each address. Bob clicks one of the Get Directions to This Address buttons, and step-by-step directions are displayed in the Driving Directions screen.

This new scenario extends the existing map tip feature from release 1: the ability to display a rollover map tip (pop-up note) with hotel links. The map tip is extended with a new hyperlink to get driving directions. For planning purposes, these features could be listed as follows:

  1. Display a rollover map tip (pop-up note) with hotel links.

  2. Get driving directions to a hotel.

When the new feature is implemented (check the release plan to find out in which release), the only code that needs to change from release 1 should be the map tip display code, which simply gets another link added to it. Extensive refactoring of the release 1 code should be avoidable.

Although the Get Driving Directions feature is a built-in feature of the ArcGIS Server software and initially looked like low-hanging fruit, this feature was ultimately deferred due to schedule constraints imposed by publishing the mapplet design in the book you’re reading.

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

When do you have enough alternate scenarios? The rule of thumb is simply this: when you and your team can’t think of any more. That is to say, wring the towel dry, and brainstorm as many rainy-day scenarios as you can think of (without the scenarios getting too contrived, of course). A more concrete technique is to look at each step in the main scenario and see if it can fail, or make the next steps fail.

Alternate scenarios are quick to write, and 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 means of discovering alternate scenarios. These will prove invaluable later on when we get to the design, because the design is produced with the alternate cases accounted for.



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