top of page
EXPEDIA.COM

Claim Status

claimstemp 1.png
Background

Travelers who purchased insurance on Expedia can view primary information related to it on their itinerary. To file a claim or know the status of a submitted claim they have to search through the insurer's site. Knowing the status of a submitted claim is of utmost importance to the user. This project is about integrating the insurance claim status and associated processes with the new post-purchase insurance system (Tripcare).

Role

Solo UX Designer, a UX Manager, a PM, and an Engineering Team. My role included: 

PWA Design

Design Swarm

Design Research

UX

UI

Tools

Figma, Trello, Miro

Timeline

1.5 months

Context

Traditionally, the itinerary on Expedia just displayed the name of the insurance product purchased by the user, and the user had to search for all the information on the insurer's site. A new insurance system (Tripcare) was then built and integrated with the existing trips system on Expedia. As a starting point for this system, it was built to provide primary information for the purchased insurance such as the insurance coverage details, how to file a claim, and cancellation policy. Status for a submitted claim still remained on the insurer's site.

Current flow: filing a claim to checking claim status

current flow1.png

Concerns with the current process to check status

  • For a user who has submitted a claim, knowing the claim status is the primary requirement, and currently, we don't provide that in our insurance system

  • It is an overhead for the users to log in to a separate portal to manage their travel insurance claims, while everything else about their trip resides on Expedia

  • It is not properly communicated to the users that all the claim process is managed by the insurer and Expedia doesn’t participate in the review process, leaving the users unsure whom they should reach out to in case of a concern

Claim status on the insurer's site

LANDING PAGE
landing page.png
CLAIM STATUS ON U.S. POINT OF SALE
US%20POS_edited.png
CLAIM STATUS FOR REST OF THE WORLD
ROW.png

Problems with the current experience

Rest of the world except U.S. POS:

  • The only information a user can see on this page is a line about the status of their claim, which can be one of the following:

    • Open and awaiting required documentation

    • Claim Received and Pending Review

    • New Information Received-Pending Review

    • Claim Reviewed and Pending Additional Information

    • Claim Finalized

  • These statuses are ambiguous, for example, "New Information Received-Pending Review", which information are we talking about, is the user supposed to review something or the insurance adjuster is reviewing

  • It doesn't tell the user anything about what the user is supposed to do in this situation

  • Users don't get an idea of the timeline, number of steps, or all the additional documents that may be required before their claim is finally approved

  • There is no support information or contact (expect there is a customer support number in the footer of the website on all pages), making it difficult for the user to access customer support

  • The payment section is only populated when the claim is approved, and there is nowhere mention of the claim amount which can be different from the final amount that gets approved

  • For a lot of other information such as claim submission date or the time since this claim is under process, beneficiary, or the claimant name (particularly important in case of multiple insureds under one policy) the user has to go back to personal notes or find it in the emails that are shared by the insurance company handling the claims

U.S. POS:

  • The next step mentioned along with the status, tells the user that either it is under review or they should check their email if any information is required to be shared by the user, adding to staggered communication

  • The required documents section shows only the documents uploaded by the user, it doesn't tell anything about any additional documents they are supposed to provide, that is just communicated on email

  • The problems relating to missing timelines, additional information, and the payments section remain as on rest of the world

Goal

Goal

Help users clearly understand the status of the insurance claim submitted by them and provide the relevant information in regards to their claim such as:

  • Where they are in the process

  • Next steps to be taken

  • Timelines

  • Payments

  • Whom to contact in case of a concern

Scope

Expedia gets information regarding the traveler's claim status from the insurance partner (not shown on the site). The information that Expedia receives in the API is limited to the primary fields. Considering this, the project was divided into 2 phases.

Phase 1:

  • Propose an MVP that utilizes the available information (and/or a few additional important fields) to provide a better user experience

Phase 2:

  • Add secondary/ancillary information that may enhance the user experience (it requires a legal loop to request any additional insurance information from the insurance partner, and that may push the timeline, hence not a part of phase 1)

  • Provide enhancements such as contextual notifications and alerts.

This project is limited to work done in phase 1 and planning for phase 2.

Design Process

Our approach

Understanding existing flow and data from the insurance partner

We made a booking in our test environment and filed a claim. We went through each scenario such as filing a single claim, multiple claims, single insureds, multiple insureds, collected screenshots, and compiled a flow to look at each step in detail. This process was done in collaboration with our insurance partner company where we compiled questions and answers and had further detailed discussions on complex scenarios. By the end of this, we had developed a fair understanding of how the current flow and screens look like. We also made a detailed analysis report which contains confidential information and can't be shared.

Competitor analysis

We looked at how the claim status is shown on the insurance sites. We were able to find these primary sections of information:

comp2_edited.png

 1 

comp3_edited.png

 3 

comp1_edited.png

 2 

comp4_edited.png

 4 

Claim ID

Time information/ timeline

Next step/ action required

Contact details

Payment information

Gaining the user perspective

We looked at the customer feedback from our opinion lab data and found out that the major challenges are:​

  • The process is unclear

  • Users don't know whom to contact (Expedia, Insurer, or which number or email exactly)

This project was started during the COVID-19 lockdown phase and is in progress. Due to this, we were not able to do extensive user research but we were still able to conduct user interviews on-call internally to understand the users' perspective.

Goal:

  • Understand how users' check their claim status

Participants:

  • Identify the process and where we can intervene to help users

  • Travelers/users who had recently filed a claim and were in the process

Key findings:
check.png

  • Users don't have an idea of what all documents might be required during processing and it may take time to get a specific document which delays the process

  • Users with settled claim

  • After submitting the claim users feel their task is done, and uncertainty about additional steps in processing leads to frustration

  • Time-related information is important

Benefits and claims as per trip phases

benefits and claims.png

Click on the image to see complete list of benefits

Possible user Scenarios

Claimants
Benefits 
Claims
Example
people.png

1

benefit.png

1

claim.png

1

Frank Funston had booked a flight with the Flight cancellation protection plan, and due to sudden health issues, he had to cancel his flight. He filed a claim for trip cancellation. 

people.png

1

benefit.png
benefit.png

> 1

claim.png
claim.png

= No. of benefits

Frank Funston is on a business round trip from Settle to London. He purchased a Flight protection plan along with his flight booking. He fell sick while in London and wasn’t able to make his return flight. He filed two separate claims:  Medical benefits & trip interruption

So, he is tracking at 2 separate claims for 2 benefits covered under one plan/one product (flight).

people.png
people.png

>1

benefit.png

1

claim.png

1

Frank Funston is on a family trip to Universal studio. 2 days before the trip their destination was hit by a natural disaster and they could not travel. Frank Funstun filed a claim for his entire family.

people.png
people.png

>1

benefit.png

1

claim.png
claim.png

= No. of claimants

Frank Funston is traveling with his friends John and Sheldon to Universal studio. 2 days before the trip their destination was hit by a natural disaster and they could not travel. Frank Funstun filed a claim for himself and shared the itinerary number with John and Sheldon so that they can individually file their claims and track it directly at their end.

people.png
people.png

>1

benefit.png
benefit.png

> 1

claim.png
claim.png

= No. of benefits

Frank Funston and his wife Jane are on a round trip from Settle to London. He purchased a Flight protection plan along with his flight booking. Jane felt sick while in London and they weren’t able to take their return flight. Frank filed two separate claims:

  • Medial benefits – for Jane

  • Trip interruption – for himself and Jane

Post-trip traveler journey map with respect to claim status

Mapping the users' activities, thoughts, and feelings after the user has filed the claim. 

Pain-points

  • Uncertain timelines and next steps

  • The channel of communication is staggered

  • Difficult to manage multiple claims

  • Lack of clarity about additional documents, too many iterations

  • Difficult to discover support contact. Not clearly communicated that Expedia can’t help with the claim processing

journeymap.png

Click on the image to see the complete journey map

Analyzing claims information

We looked at all the information that we receive from our insurance partner, tried to understand the working, capabilities, and limitations of the current API. We had developed an understanding of what our users are looking for from the above steps. We matched what we believe is important for our users to the information we receive in the API, so as to identify the missing bits. We ranked the missing information in order of importance (in collaboration with the content strategist) so that we know what all we want in the system that is non-negotiable.

UX Swarm

This project was done during the lockdown period because of COVID-19, so we had a virtual swarm. The participants included one product manager, one content strategist, one design manager, and one UX designer. We set aside 2 hours daily, for 4 days in a row. The goal was to identify the solution to the problems identified.

On the first day, we revisited the user scenarios and traveler claims journey map. The purpose of this was to have a diverse perspective, discover more opportunity areas (if any), and bring everyone on the same page before we head to the solutions. The outcomes of the swarm included:

  • A more detailed user journey map

  • Content mapping and hierarchy

  • The job of the page

  • System entry point

  • New system map

Content mapping and hierarchy

We took a content-first approach. Based on the journey map we looked at what information is important at which phase (done in collaboration with the content strategist). We then arranged the identified information in a logical order to form the content hierarchy at each step.

content.png

Post-purchase trips + insurance system

Since, insurance claims are primarily part of the post-purchase, looking at the post-purchase trip + insurance system. Identifying the job of each page in the trip system, and the job of claim status, so as to map where claim status fits in the system and how.

trips+benefits.png
Trip Folder
Trip Overview
Itinerary

Primary: Show list of upcoming travel, trips should be distinguishable from each other, and users should be able to know products in each folder.

Secondary: Past and cancelled trips.

Primary: High-level product core data.
Secondary: Access to planning tools.
Tertiary: Access to inspirational content and relevant cross-sell to help users plan/build out their trip.

Primary: Core product details that help users get on/to their reservation.

Secondary: Access to secondary itinerary details categorized intuitively.

Benefit Overview
Benefit Detail
File a Claim

Primary: Show all the benefits purchased along with coverage status and claims (if filed).

Secondary: Highlight the benefits that cover the current event/situation.

Primary: Benefit status and coverage details.
Secondary: Access to managing the insurance (cancellation), filing a claim, checking claim status, support.

Primary: Details of the claim filing process and enabling users to file a claim.

Secondary: Access to assistance.

Job of claim status

  • Help users understand the status of their claim and the next steps (if any)

  • Help users understand the final outcome of their claim

Entry point and system mapping

We explored 5 variants based on whether we want to introduce a separate page for claims, one page for each claim, or just show the claims information upfront. A major challenge was we don't receive the information from our insurance partner that the claim belongs to which benefit. We weighed the pros and cons of each to arrive at the preferred solution.

Pros:

  • Everything is on one page contextual to user intent

  • Predictable navigation and discovery of this page

  • All claim in a single view


  • Common info will be centralized

  • Scalable, as this page can be linked from benefit details, emails, or push notifications

Cons: 

  • Claims are not tied to benefits

  • Each claim may have too much info and hence multiple claims on one page will be complex to comprehend

  • It might be difficult to point out the status changes for multiple claims status changes

But currently, we don't receive benefit-claim relationship info from our insurance partner. Also, multiple claims under one itinerary are less than 1%.

entry point.png

The selected version from the explorations

Designs

Where we landed

We came up with a first draft that had some extra content than what's provided by our insurance partner. We had some iteration based on the legal constraints and arrived at the system and page-level designs which were then populated with real content for user testing. We tested it internally as again extensive research was not possible due to lockdown.

benefit overview.png
claim details.png

Design library and UI design

At Expedia, we follow an internal design library. Designers working on different LOBs, teams, and time-zones use this library to make sure our designs are consistent and we provide our users with a coherent experience. It also reduces the need for any custom code. The designs for the new post-purchase system were built using standard components from the library and handed off for implementation.

View this site on desktop for more details on this project.

I'd love to hear from you

Email me at tanyaswami1@gmail.com  •  Connect on LinkedIn

bottom of page