The Approach:

I decided to design for mobile. I hypothesized that given observed patterns, selecting a link from an email would most likely land you there in some form. Also that users in this scenario would be more inclined to check their email and enter this flow using their mobile device.

REQUIREMENTS:

• Users may select meals, hotels, or both.

• There should be a way to decline the offer.

• Determine an appropriate number of hotel options (maximum of 10).

• Display address, distance, and hotel shuttle availability

• Choose the preferred number of rooms

• A confirmation number will be provided upon the hotel selection

• Meal vouchers offer $12 for food and drinks per person and this excludes alcoholic beverages.

• A QR code should be used for redemption.

Assumptions:

1. Assume that the process of choosing amenities is part of a larger “rebooking" experience. Selecting amenities may or may not occur during rebooking.

2. Assume that these users would be technologically savvy and familiar with existing patterns of popular travel booking apps; in this case AA. Conduct an audit of AA selection patterns.

3. Assume that the airline loses money with every confirmed selection of amenities. Design should make it easy to make selections, but make doing so optional.

User Research:

Turns out, I have recently experienced a flight cancellation and was able to clearly recall the experience. However, I learned my use case is a bit rare. I fly regularly, I’m an Advantage member, so I’m pretty familiar with the site, and am perfectly comfortable doing things on my phone.

But most people aren’t.

For example, when my flight was canceled, most people went straight to customer service to rebook flights, while I rebooked my next flight myself through the AA app.

With this considered, I decided to design for the person who would actually use it. I used my rare use case as a lens to see things through.

Competitive Review:

Before brainstorming designs, I did a pretty extensive audit of existing selection patterns on AA.com. I also looked through my own personal email for emails from my canceled flight.

The Brainstorm:

Keeping the scope fairly narrow, I took the list of requirements and rules and started working through a task flow based on user needs.

• Idea 1: Notifications in Trip View. Users need to be made aware of what’s available to them, regardless of where their journey begins. The Your Trip view offers an overview of your trip. It also allows you to make selections and updates, making it an ideal location for such a notification.

• Idea 2: Tabs in Selection View. Users have the option to select meals, hotels, or both. While most users will most likely select both, there should also be a seamless transition between the two options.

Initial Wireframes:

To start, I created a flow based on my sketches.

This flow allows users to navigate from their email, and choose a hotel and meal voucher for each individual passenger (or not), review and confirm selections.

Accessing the Amenity Selection:

In order to begin choosing amenities, the user must select the “Choose Your Amenities” CTA button in their Amenity Email. This interaction takes them to the Your Trip screen, where they are automatically “anchored” to the “Select Your Amenities” section. The user is re-presented with information on the amenities they’re able to select, and finally the “Select Amenities” link button.

Amenity Selection Flow:

The flow begins with choosing a hotel, then shifts to selecting meal vouchers. By default, nothing is pre-selected to allow users to review available options before making a choice or not. In the default states, users can tap “Continue” and click through the flow without making any selections at all.

Final Wireframes:

I later made iterations based on feedback from friends, and things that just didn't feel right. For example, in my sketches, there were two alerts at the top of the “Your Trip” screen, one for each amenity. I ultimately narrowed it down to one. I felt it was a bit redundant considering that both a hotel and a meal voucher can be selected in the same flow.

Amenity Selection:

In the previous wireframe flow, users needed to manually select both their hotel and meal vouchers or not for each passenger. After some feedback and a general critique of the flow, I felt it caused unnecessary friction. The final flow favors the most common use case, so users only need to “Select” once to confirm their choices, or deselect options they aren’t interested in.

Accessing Confirmed Amenities:

Users can access all information regarding their trip, including their amenities, on the “Your Trip” screen. This placement is consistent with existing patterns.

Next Steps:

MORE feedback, testing, iterations! Next steps for me would be to test these ideas and see how they do in the hands of more users.

My test criteria would include testing for efficiency, and users ability to successfully select and confirm amenities.

I would also like to work through some edge cases as well. For example:

1. A room for passenger two. What if the friend you’re traveling with wants their own room? Currently, it’s possible to do so, but this isn’t a common use case, as research shows that most people opt to share. Is there an alert that verifies that you want to select a second room?

2. No email access. This whole scenario is contingent on a user having access to their email. What if they don’t have access to their email?

Final Thoughts:

I had a blast working on this, especially being able to test my ideas with friends. I actually discovered that a few of my friends didn’t fully understand the kind of work I did until I put a prototype in their hands. Their reactions were priceless, and think it’s safe to say they think I’m even more awesome now lol.

I was most excited about working on something that solves a problem I’ve actually experienced.

Thanks for reading!