Better help and support

Qantas

Product Design

Lead UI Design

Native app

Web

Role

Solving for and reducing pressure on call volumes and times between customers and service agents. While giving customers a new, faster and more convenient support method in the Qantas app and website.

The basic concept was to mirror the telephone “IVR” support call process - inside the app. While using usage analytics to track and measure performance. This product is also foundation for other features that are currently being developed and plugged into this system.

Responsibilities

Working closely with lead UX and product owner in identifying key goals and objectives.
Creating user flows, based off user research and synthesised key insights.
Mapping intents to new and existing pathways in the customer support channel.
Creating wireframes, interactive prototypes.
Contributing and working closely with design systems teams and other squads.
Obtaining feedback from product owners and design management.
Refining designs based off user testing results.
Leading technical feasibility and developer handover.

Problem statement

Consultants are being overwhelmed or spending longer times on calls with customers who are seeking support.

Customers are also frustrated with long wait times, ambiguity around how long support calls or being on hold may take. While customers can call direct for support, the app is missing this vital piece of functionality.

Solution

Designing a digitised version inside the Qantas app, for the help and support feature - Where users can simply click to call. This was achieved by users simply navigating via options and intents, which is then collated and automatically sent to consultants and displayed to users at the end point.

Empowering users and consultants with more contextual information, faster processing times, less call volume and clarity on call wait times or self service options.

The process

Mapping and planning the experience

Our aim was to delivery the product in a phased approach.The main architecture for the navigation experience was gathered from the existing support call flowchart. From here we had a visual diagram to map out the key touch points and processes.

Flowchart that gives a preview of a telephone call to support

Snippet preview of the telephone IVR flow

From there we built out the key flows and experience. Establishing the key components and touch points. Conducted user testing and research sessions and synthesised the results into key insights.

Intelligent updates, collaboration and design systems

Atomic design systems, editability and variants were factored in when designing all components and screens.

Assets such as the support summary card, had multiple configurations that could toggle user scenarios.

A screen design showing a key component, as well as it's related overrides

Design considerations

What does the booking reference entry look like for both logged in and logged out users? 
Considerable time and attention was spent on designing for how any flights, no flights or multiple flights were displayed where booking references needed to be surfaced.

As well as the ability to enter more or other details if bookings weren’t listed, or if users did not have a booking reference.

Screens showing how users select or add their booking reference and alternative fallback options

A user needing to change their flight date or time - But selecting an existing booking, or adding another booking (left) or if there are no booking details to enter (middle and right screen).

How do custom accessibility settings affect text size and appearance for complex components?

Two components that demonstrate the "selected" and "unselected" state

Designed with scalable text in mind

Support summary screen - Options for users to achieve their goals

A screen design of the support summary screen

Support summary screen, featuring click to call feature.

What is the initial stylistic direction?
‍With a newly refreshed style and appearance on the horizon, we had to decide whether to adopt that approach, or design to what was existing already.

What does the entire end to end experience look and feel like for users?

The end to end user experience of a "happy path" for users inside a "manage my booking" intent

Example of ‘happy path’ for users - From entry point to the final support screen featuring click to call or self servicing examples

Testing scope

The scope of this research was to understand the patterns we have developed from Phase 1 & 2 and validate their application in the Qantas App.

Boundaries
We weren't testing all user pathways, but rather could users access a booking and use ‘Manage my booking’ to self serve as a key behaviour for specific support intents? For example: Change the date or time of a flight.

Testing approach

4‍concept testing

5 minute surveyquestions and SUS/NPS

12 x 1 hourin person sessions

Who we spoke to

50/50male and female

6‍QFF members /
Non QFF members

100%participants flown within 12 months

12 hoursof conversation

26-70age range

Learning goals

Do QFF tiered customers authenticate as a standard behaviour? If not, do they use the log in prompt notification on the Visual IVR landing page?

Do customers use the ‘Help’ entry point icon to access support? Did they use the icon on ‘Home’ VS other contextual options such as entry via contact in settings

Do our PNR (passenger name record) capture patterns work in app? Do they easily take the happy path with the presentation of existing and previous bookings for authenticated customers?

Do our un-authenticated customers identify with the non personalised PNR capture patterns?
For example - Capturing user booking information in the happy and fallback flows

Did our support content drive the behaviour for customers who indicate they ‘always’ prefer to use self-service?

What we tested

Do customers log in on first contact?
You want to seek help and support but are logged out. How would you proceed to log in?

Key insight
All customers who are QFF members automatically log in if they see that they are in an un-authenticated state as they assume authenticating will provide a more tailored experience.

Do customers use the ‘Help’ icon to access support?You want to get some assistance with changing the date for a booking you have to Honolulu in April. How would you go about doing this from the home screen?

Key insight
Customers could easily use ‘Trips’ as the primary way to get self-service for our task, but didn’t identify with the help icon as mechanism to start a support journey. How could we make the original ‘Help’ entry icon more visible and meaningful for customers on landing?

Do our PNR capture patterns work in the app?
‍You want to speak with a Qantas consultant about an upgrade to a flight you have coming up. The reference for the booking is: GK9H8Q. How would you go about doing this from the ‘Select a booking’ page?

Key insight
Participants had no issues adding a PNR to their support request using the flight cards. For the task where they couldn’t see the PNR listed, they were also able to easily find the ‘Add you booking details’ and add the booking to the flow.

Can un-authenticated users find the fallback PNR capture pattern?
‍You receive a notification that your flight to Melbourne has been cancelled. You don’t have your booking details with you and would like to call and speak to with a consultant about getting a refund for the flight.

Key insight
The primary learning from the fallback was that it wasn’t immediately apparent that these ‘steps’ were routing the customer to a queue for support. The lack of personalisation also contributes to this.

Did our support content drive self-service behaviours?
‍What can you tell me about the ‘Fastest support’ on this page? Do you usually prefer to use self-service or talk to a consultant?

Key insight
90% of participants read through the text in the ‘Support screen’ The guided nature of the text was easy for them to follow and many indicated that the length of the text was the right amount for self-service.

Concept evaluation

Did they prefer ‘native’ patterns versus the system components?

Could customers access ‘Past bookings’ to retrieve a PNR for a refund?

Were customers able to navigate back to ‘edit’ a PNR selection if they changed their mind?

How did the customers navigate back to the start of the Visual IVR?

Did customers understand that the ‘Support summary’ was handed over the consultant once they were connected?

What we tested

Did they prefer ‘native’ patterns versus system components?
‍For this evaluation we utilised two existing iOS patterns to see which options customers naturally used in our tasks.

Key insight
There was no failures for our tasks where customers were required to use ‘Add’ in the head and shoulders or an ‘Add’ button’ on page. Participants were so used to both patterns that they didn’t even notice the difference.

Could users access ‘Past bookings’ to retrieve a PNR for a refund?
‍You want to get a refund on a past booking you have recently taken for business. Your fare type allows for you to do this yourself. How would you go about doing this from the current Upcoming bookings page?

Key insight
Although 50% of participants missed the ‘Past’ booking TAB, once they found the TAB they were easily able to generate a PNR to move forward in the flow to get support.

Were customers able to navigate back to ‘edit’ a PNR selection if they changed their mind?
‍If you need to change another booking that you also wanted to upgrade and that wasn’t listed in your bookings, how would you do that?

Key insight
The white change button was not obvious to many customers, only after navigating for a while and exhausting all options or coming back for the second time did they recognise the change button.

How did the customers navigate back to the start of the Visual IVR?
‍When users completed a task, we observed how they would naturally navigate back to the homepage to start another support request.

Key insight
The ‘Done’ button was utilised by 60% of participants. The residual of participants used ‘back’ chevron as it mimicked back behaviours they were familiar with in browsers and other apps.

Did customers understand the ‘Support summary’ was handed over to the consultant once they were connected?
‍From the support summary page, what do you expect the experience will be like if you make a call to a support consultant?

Key insight
Many customers didn’t see the ‘Support summary’ as something that was handed over to consultants, most just assumed it was a summary of their interaction but were very supportive of the feature once they understood it. Which will significantly improve their overall support experience.

scores

System Usability Scale results

Customer Effort Score results

Net Promoter Score results

Iterations

We updated the support summary card on the last page to show booking reference and customer care case numbers upfront, without the user having to expand the view. 

Optimised language and text, especially in the menu intents.

A validation summary was included at the top of the screen if there were any form entry errors, that includes a full list of what needs to be corrected and where. This also scored higher accessibility ratings.

Screen design demonstrating form validation and error handling

- Form validation showing summary, validation error states and validation messages.
- Continue button remained present and decided not to show it in disabled state.
- Validation would show on “Continue” if users hadn’t satisfied the validation criteria.
- Validation will dynamically update according to user input.

Technical and design challenges

App developers had to build new components, which would take longer to produce. This created the need to pivot and improvise quickly. For example - instead of tappable radio buttons, we swapped with using inset rows, where users could tap the option to proceed.

Documentation

Each key screen was dissected into the main components, where we could articulate screen reader script, such as invisible headings, component variants, specific tokens used to identify colour values, spacing etc.

Basic documentation preview.
- Android text and radio select fields, with validation and summary.
- Using a tokenised design system, with contextual tokens for font and colour.

PROJECT key takeaways

How to avoid last minute and ‘waterfall’ changes from developers
‍This was the first project undertaken, where we did embrace technical feasibility sessions. However, they could have been earlier and involved more potency in terms of time spent and technical analysis from development teams.

In learning this, we committed to updating our design process to have technical feasibility sessions even earlier. Where developers have plenty of time for technical analysis, identifying and solving for any issues.

Adopting a phased delivery
Our initial timeframe window of the MVP product, didn’t meet initial expectations. So we decided to split out specific features into incremental releases, where we could still deliver to market, but faster and easier. Items were flagged to toggle on at specific timelines and were built in the background.

This memorable quote -
"MVP’s are for learning. Not building on top of the same design.”