Airbnb current UX

Airbnb user flow

The Airbnb is minimal and contained two screens to complete a reservation. Airbnb appears to target simplicity and reduced clicks to reduce user friction and time to complete the transaction to increase the completion rate

Airbnb current user patterns and design library

The design system is simplified:

• Typography is one sans-serif font, “Circular”
• Color is gradients of black and one primary color, #EB2260 (Dark pink)
• CTAs are:
  • Primary button in pink
  • Secondary button as black outline/white background
  • Inline hyperlinks underlined
  • Modal overlays for more information links

Mobile

A couple of items are unique to the mobile experience

• The right-side action area with the primary CTA appears as a sticky footer with reduced content
• The overlay modal is presented either as a:
  • Overlay modal
  • Side-load modal

Competitor exemplar studies

Airbnb’s proposal for a car rental product is an add-on service to its core business of home rentals. I did an analysis of various companies’ UX to understand how its competitors, along with retail and car rental exemplars, offer best-in-class UX for add-on services.

Competitor UX patterns I examined included:

• Tripadvisor
• Vrbo
• Booking
• Expedia

All four had poor UX. Tripadvisor didn’t natively have a clear offering to add a car or other add-on to a hotel rental. Of the remaining there, the issues are noted below.

Vrbo

The only example of an add-on service was this text hyperlink that triggered an odd pop-op to learn about a payment plan service that felt tacked onto the UX

Booking

The only car rental option was buried in the reservation flow. Car rental information would only be given after you booked a room

Expedia

The user must select a checkbox on the home page when they search for a room. If a user fails to select this checkbox, the option to rent a car isn’t presented again

Retail exemplar mobile studies

I also conducted a competitive analysis of mobile UX in the retail and car rental sectors to understand how exemplars in other sectors have presented add-on products to customers. Noteworthy is that all four exemplars below include variants of multiple opportunities to opt for its add-on services, either as overlays, in the cart, or as itemized line items. The pattern seems to be a more pronounced graphics initial presentation of the add-on, followed by an itemized line item presentation of the add-on in the cart and/or checkout

The best examples of mobile and mobile responsive are explored below:

Apple

Apple’s mobile responsive website replicated the desktop experience and used modal overlays to show supplemental information. The ability to include add-ons was present as a separate screen

Product view before add to bag/cart

Add-on shown after “Add(ed) to Bag”

Line item for add-on shown again in “bag (cart)”

Overlay is triggered from cart hyperlink

Lowes

Lowes presents an overlay when a product is added to the cart where the user is presented with add-on products. Lowes also has two other ways to explore and include more add-ons. This includes checkboxes to add haul away or insurance services. A secondary button is shown below the “Add in Cart: a button that lets users explore related appliance products for their kitchen. Add-ons are presented as line items at the final checkout screen.

The product screen has add-ons in an accordion along with a “Complete your kitchen” CTA below the “add to cart” CTA

The pre-cart overlay again presents the add-ons as line items in addition to a quick pay option

A secondary button is shown below the “Add in Cart: a button that lets users explore related appliance products for their kitchen

Add-ons are again presented as line items when the user is in the cart

Amazon

Amazon utilizes a familiar UX pattern for add-ons. Add-on products appear as links that open a side-load overlay. Once a product is added to the cart, a footer overlay slides up and includes an option to add additional products. Once at the checkout, Amazon doesn’t present these add-ons but instead shows financing options as add-ons.

The footer overlay prompting the same add-ons may feel “pushy” to some users instead of taking them directly to the cart.

The product screen has add-on line items that trigger a side-load overlay

The side-load overlay has more information for add-on and include with product purchase

When a product is added to the cart, a footer overlay slides up to present add-ons before proceeding to the cart

Enterprise

The Enterprise mobile responsive and mobile app has a delightful experience with a combination of enhanced mobile-specific interactions such as date/time selection, animations, and side modals to add driver information and save time at the counter. The UI has a clean layout with minimal speedbumps to complete the transaction.

Airbnb could use the pattern from the car selection screen and integrate it into its checkout process. It should be noted that Enterprise offers add-ons during the flow, such Sirius XM, but does not present insurance options. Checkout messaging under “rental policies” says that this will be handled at the car rental location.

This removes checkout friction and likely increases the completion rate. Airbnb could also benefit from already having the driver’s license and age for its users, increasing hand-off when taking the car on location.

Airbnb could use this pattern to inform its car UI

Add-ons are presented after selecting a car, but doesn’t include insurance, which is handled at pick-up

Airbnb could use this pattern to inform its car UI at checkout

Option to enter driver ID. Airbnb often has this info on file from users. With proper opting into sharing PII with disclosures, Airbnb could use this information to friction when picking up the car

Typical exemplar user flow for add-ons

The typical exemplar user flow for add-ons was to introduce the add-on:

• Show add-on as in secondary CTA on main product page
• Show add-on as a separate screen

Once in the cart with the main product, an add-on was presented again as an optional line item

Typical exemplar UX patterns for add-ons

Add-ons were initially surfaced in two different ways:

• New screen for add-ons
  • Apple and Enterprise
• Secondary add-on CTAs on the product page was used when there was a sticky cart preview on the product page
  • Amazon and Lowes

Airbnb current UX

Airbnb user flow

With the above context, let’s revisit the Airbnb user flow. Airbnb currently only uses two screens to complete the flow. This simplified flow is likely intended to focus on minimizing the risk of dropping out of the flow and increasing the completion rate. The car rental solution will focus on maintaining this minimal approach to surface the add-on service.

Airbnb UX patterns

Airbnb uses overlays, either slide-left or footer slide-up, to present add-ons as overlays on the product page. This UX pattern aligns well with two exemplars, Lowes and Amazon, and will be referenced as a pattern to use to add car rentals.

CTAs such buttons and inline hyperlinks open a side-load overlay. The footer CTA hyperlink pulls up a footer overlay and includes a third button style to save changes.

Product page with inline CTA button that triggers an overlay

The overlay scrolls and contains more information. This UX pattern can be used to present car rental options

If a user taps the sticky footer CTA, it triggers an overlay that slides up for additional content and options. This UX pattern could be used to intercept and present a car rental option like Lowes and Amazon does when users add a product to the cart

Airbnb proposed solution

Airbnb proposed UX patterns

Airbnb has minimized its user flow to two screens, so exploring options to add a car with a modal will be prioritized over adding a third screen. Options to explore:

• CTA on-screen triggers slide-left overlay
  • Pro: This allows users to avoid an extra click being introduced into the existing flow if they have no interest in a car rental. The CTA hierarchy will have to be strategic and ensure it is not taking priority over information desired by users when making a decision about renting this home
  • Con: Users may not see it and would have the last chance to add it to the cart
• Cart add triggers footer slide-up overlay
  • Pro: Users will have clear visibility of this add-on and it will not take up real estate on the main product screen
  • Con: It may force users into an extra step that they otherwise are not interested in. It may also come across as outside of the Airbnb VOC and feel “pushy”

Placement for add-on CTA

As mentioned above, the CTA hierarchy will have to be strategic and ensure it is not taking priority over information desired by users when making a decision about renting this home. Reviewing how current CTAs and other informational sections on mobile and desktop can inform the screen location candidates for the CTA.

The five screens below include a study of the relationship of content between desktop and mobile on the existing screen. This is followed by four studies of CTA placement on desktop and mobile

Current content relationship

1. The side cart has removed content for the mobile view and focuses only on price, dates, and the “Reserve” CTA. The “scarcity” callout tactic is placed high in the mobile hierarchy in an effort to increase motivation for users to lock in the reservation

CTA button under scarcity callout

1. CTA feels orphaned on desktop
2. CTA feels overvalued in its placement within the hierarchy of the mobile screen. The Host information is likely of higher interest to users

CTA button over scarcity callout

1. CTA feels orphaned on desktop
2. CTA feels overvalued in its placement within the hierarchy of the mobile screen. The Host information is likely of higher interest to users

CTA button in sticky footer

1. CTA is strongly integrated into the side cart for the desktop. Amazon and Lowes exemplars use similar placement
2. CTA on mobile uses design language not used in the current design system. Plus, this pattern is not found in exemplars

CTA button inline with body content

1. CTA has a more subtle placement on the desktop. This seems to properly focus on Airbnb’s core business, the user’s experience with the host and their home
2. CTA on mobile is placed below host info and feels better prioritized. Not visible on the first screen load and must scroll to see, but likely will be seen as users scroll for more info on the home

CTA placement conclusion

The strongest fit for desktop and mobile that aligns with Airbnb’s core business seems to be by placing the CTA button inline with the body content. It prioritizes the host, their home, and the experience the user will have with the host. It also avoids introducing new design language patterns.

Airbnb mobile solution

Airbnb has limited its user flow to two screens, so exploring options to add a car rental with minimal introduction of new screens will be prioritized. The two exemplars that will be referred to will be Lowes and Amazon to review two options for mobile solutions that allow users to rent a car with Airbnb.

The Lowes example uses an overlay triggered by an inline body CTA button and aligns with existing Airbnb UX patterns. The Amazon example also uses an overlay triggered by an inline body CTA which is relevant to this exercise.

An additional example will be explored that both Lowes and Amazon demonstrate, a footer expansion triggered by a product added to the cart.

Solution 01: New car rental section

This flow introduces two new opportunities for users to add a car rental to the home rental reservation:

1. New section on a home description landing page that includes a button to view a side-load screen to add a car rental
2. A line item presented as a text hyperlink to add a car rental

View this prototype

Solution 02: Cart add prompt

This flow introduces a cart triggered footer overlay in addition to the two opportunities in the “New car rental section:”

1. When the user taps “Reserve” CTA in the sticky footer, an intercept is triggered that fires off a cart overlay presenting the opportunity to add a car rental. This overlay is triggered only if the user has not already added a car rental to their home reservation.

View this prototype

Recommended testing and implementation

The launch of the new product would be done in the following phases:

1. Feedback from broader UX team and stakeholders
2. Refine from feedback and present to leadership for additional input and buy-in to proceed to testing
3. User testing with Invision prototypes to gain feedback on the two designs
4. Presentation of testing to stakeholders, including leadership and development of testing results and gain the buy-in for a launch strategy and timeline
5. If both versions test relatively well, or if there are strong opposing opinions from stakeholders, then the push to production would start with a limited-scale pilot launch of the new service with an A/B test of the two versions
6. Otherwise, a limited scale pilot launch of the new service to ensure stability and validation of KPI data before proceeding to full production launch

Focus Group

As part of the Customer Journey team, we ran multiple live focus groups in the Discovery phase to understand why we were observing reduced enterprise NPS and CSAT scores, among other key metrics.

One theme that surfaced was that existing customers didn’t like having to call in for tasks that should be self-serve, or for problems that DISH likely knew existed but failed to be proactive in addressing. These existing customers also shared that they felt like they were taken for granted by DISH because newer customers received better equipment and deals.

Customer Journey

We took the feedback from the focus group and mapped out customer journeys. We then storyboarded these friction points with proposed solutions and presented them to executive leadership.

Mocks

I took an existing pilot app for sales and leveraged it in our new design system. It displayed side-by-side comparisons for customers with their current equipment compared to a suggested upgrade option. The pilot was run with the expectation that an agent would guide customers over a call, so this language was added at the beginning of the flow.

Low fidelity mockups

These mockups are a great way to start off a project conversation. A designer can quickly mockup layout options without investing a lot of time. This can be done either before a meeting or at the meeting and helps to get immediate feedback.

Low fidelity mockups also have the added benefit of presenting information in an informal way that subconsciously gives stakeholders permission to critique. The more polished an early presentation appears, the less likely a stakeholder will feel that they can offer critique. Or worse yet, stakeholders give feedback, not on the layout or content, but on the style, which is too early to do at this stage.

Here I created various layout options based on the precedents we studied for use in our team meeting. Cutting out elements into separate modules allowed us to explore options as a group that I did not think to explore on my own and helped inform an unexpected but exciting direction in the wireframe phase.

Wireframes

The sidebar navigation option seemed too much like a retail site such as Amazon and failed to give the students an exploratory experience. The team wanted something that reflected the values of Boston College.

Boston College is a Jesuit Institution and a series of questions that is posed to the incoming Freshman class is:

1. What brings you joy?
2. What are you good at?
3. What does the world need you to be?

The spirit of this personal exploration is captured in the quote:

User feedback and test sessions

As much as the team was pleased with the wireframe layout, further discussions showed that there was a potential political battle within departments if we started to tie abstract student interests to degrees in such a literal manner.

So we moved forward using degree categories that are already being used to organize degrees on the school websites as the tag filters.

I also sat down with three current Boston College students for user testing sessions. The design was well received and was viewed as a major improvement.

High fidelity mockups

The revisions incorporated from user feedback was the hierarchy arrangement of the search bar in relation to the tags. It was not clear that a user could conduct a search and then filter the search results with tags. Any new search will clear out the results because the search bar was higher on the page and more important.

The search tool now returns results from a query that is run on the degree abstract and expanded detail explanation, a subtle way for us to allow students to still search based on their interest.