Overview

The EPC app’s most used feature: rates and availability

Expedia Partner Central (EPC) is the portal for hotels to manage their listing on Expedia. It is available on the web and in apps for iOS and Android. One of the most-used features of the app is the ability to update the rates and availability of rooms.

Problem statement

Big functionality on a little screen

On desktop, the rates and availability feature was a complex page with lots of data and functionality displayed in a table so multiple dates could be viewed at once. The original app used webviews from the responsive website.

Using webviews was a good way to create the app quickly with as little development work as possible, but it restricted us from making big changes to the layout in the app.

To make the table work on mobile, the website limited the view to one day at a time. While this did work, it led to a cluttered and cumbersome UI. 

We knew from analytics that rates and availability was the most used feature in the app so it made sense to create a native mobile version that would be easier to use.

Users and audience

All types of hotel use the app

Hotels that use the EPC app 

• Smaller hotels that manually manage rates and availability.

• Larger hotels that want to quickly check rates and availability.

Role and responsibilities

My role: UX and UI designer

I created wireframes, user flows, visual designs, and prototypes with team members from:

• UX design

• Content strategy

• Product management

• User research

• Engineering

Scope and constraints

Same functionality but optimized for mobile

• The app needed to include the same data and functionality as the desktop.

• No changes to the backend services were in scope.

• No changes to the business rules were in scope.

• The initial designs and prototypes would be created for iOS as we had more users on iPhone. After user testing, we would adapt the designs to Android.

Process

A complete redesign of rates and availability for the app

The full table showing all rooms and rate plans across multiple days was impossible to fit into a mobile design. We needed to completely rethink rates and availability for mobile.

For every day, all room types have displayed:

• Number of rooms available.

• An open or closed status.

• 2 - 10 rate plans, which each has:

  • A price.

  • An open or closed status.

  • Booking restrictions. 

    • Minimum nights stay.

    • Maximum nights stay.

    • Closed to arrival.

    • Closed to departure.

On desktop, the data was in a big table which was too big to fit on a phone screen.

Previous user research had revealed that users also wanted to see the number of rooms sold, which wasn’t available on the web yet so we added that. 

The best mobile apps focus on one task at a time and only show the things essential to completing that task. The main things we did to achieve this are:

• Use a list view instead of a table.

• Divide the feature into separate views for availability and rates.

• Prioritize data so that important things are easily scannable and less important things are hidden.

• Remove anything we can.

• Only show a slice of the data on-screen at once. This lead to a question, which slice of data would users benefit from most? 

There were two main ways we came up with to slice the data:

• Model A: One rate plan shown across many dates (a row of the table).

• Model B: One day listing every room and rate plan (a column of the table).

There were pros and cons to each model so we decided to test them both with users.

Valuable insights from user testing

We built prototypes of both versions in InVision to test with 5 hotels of different sizes. The users were invited into Expedia’s innovation lab in Bellevue and asked to complete a few tasks.

The prototype generally worked well, users were able to complete most tasks without trouble:

• Lookup and change rates for a particular room type.

• Lookup specific information on rate types for different room types on different days.

• Lookup and change availability information for a particular room type.

• Lookup specific information on the availability of different room types on different days.

There were a few obvious points of confusion that most users had trouble with:

• The navigation label ‘Inventory’ wasn’t what users expected to tap to change rates and availability.

• Users didn’t find restrictions under the ‘more’ button.

• It wasn’t obvious that the room name in the top bar could be tapped. All participants changed rooms with the arrow buttons instead.

Unfortunately, the biggest question we had didn’t get conclusive results. Users were evenly split over which slice of data they preferred (model A or B). Interestingly, their preference correlated to the hotel’s size:

• The two “medium” hoteliers and one “large” hotelier said they were more comfortable with Model A (multiple dates for one room type at a time). 

  • They said a common task was forecasting for a 2-4 week period, which is easier when multiple dates are listed.  

• The two “small” hoteliers stated they were more comfortable with Model B (multiple room types for one day). 

  • They said that they “only have a few room types at my hotel” and it was much easier for them to process their information in this format. 

  • They were more concerned with providing good rates for each day and the focus was on one day at a time.

Updates based on user testing

We made updates to solve the issues that came up in user testing:

• ‘Inventory’ changed to ‘Rooms/Rates’ in the bottom navigation.

• ‘More’ changed to ‘Restrictions’ for the button to expand restrictions.

• Changed the room selector to appear more tappable.

Given that both models A and B had merits for different users, the ideal solution would be to build both versions and have a way to switch between them in the app. It could even be automatic based on the hotel’s size. However, that would nearly double engineering time so the product manager made the decision to develop model A first. 

In addition to the user testing changes, we thought of a few other improvements:

• Adding the hotel name so that users that manage more than one hotel know which one they are currently editing.

• Updated the ‘switch view’ control to tabs. In the original design, it was a dropdown because we were planning ahead for when there could be more options. However, since there were only two for the MVP, tabs would be better as they show both options upfront and require one less tap. 

• Added a ‘see more days’ button to the bottom of the list. We realized a common use case would be to scroll through the list for one set of dates and then move on to the next set of dates. In the old design, that would require opening the date picker, figuring out which date to open next and selecting it. It would be much easier if the user could just keep scrolling and more days would keep loading automatically. The engineers had concerns about performance so we compromised with a ‘see more days’ button.

Outcomes and lessons

Outcomes

• Shipped the app’s first native feature.

• Significant improvements to user experience.

• Improved time to interactive (TTI) of rates and availability in the app.

• Resolved terminology confusion.

What I learned

• Hotels have very different needs based on their size. Whether or not we need different UX for different hotels should be considered upfront and included in the scope.

• Working with teams across multiple time zones can be challenging. A design sprint with all stakeholders would have helped us understand all functionality, business rules, and edge cases from the start.

Demonstrated skills

• UX and UI design for mobile apps.

• Working within a complex system of business rules and edge cases. 

• Prototyping.