The Finished Use Case

Let’s see how our overall finished use case looks. As you can see in Figures 10-7, the finished product follows the steps described in the interaction scenarios to the letter. Not bad!

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.

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.

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 automatically zooms out until both the meeting address and the nearest Hilton hotel are visible on 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 window.

As you can see, the use case is quite wordy. For a large system, we definitely wouldn’t want to write 500 or so of these. It’s useful to take this approach for a fairly small cross-section of the use cases. Choose the use cases with care, though—you need to select the ones that will have the most influence on the product design.

Contrast this with the “Generate Hotel Map for AOI” software use case that we wrote in Chapter 6. The software use case was roughly equally balanced in terms of user/system actions. However, our new use case shown here was written as an exercise in interaction design, therefore it focuses more on the user’s actions than on the system’s responses.