Integrity Life

Duration

July - Sept 2022

8 weeks

My Role

Product Designer

Team

1 x Product Designer

1 x Business Analyst

1 x Front-end Developer

Platform & Sector

Web Application

Insurance

Deliverables

Prototyping

Usability Testing

Research & Synthesis

Workshop Facilitation

Presenting Insights

Optimising the experience for Advisers to self-service policy amendments for cover decrease and payment frequency changes

Giving Advisers the ability to self-service policy amendments

Integrity Life is a partner and customer-focused life insurance provider, with a commitment to helping Australians when they need it most. They provide life insurance through retail partners (Financial Advisers) as well as corporate group insurance to businesses and their employees.

Their current platform provides a digital quoting and application tool for onboarded Advisers. This online web portal is known as the Life Platform. Here Advisers can generate quotes for their clients, apply for insurance policies and view and manage their existing clients.

Our goal with the project was to open up the ability for Advisers to self service cover changes through the Life Platform, initially starting off with cover decreases and payment frequency changes then opening up functionality to more complex tasks like cover increases.

THE PROBLEM

The experience for amending in force policies was non-existent through the Life Platform.

Advisers had to call or email Customer Care team to request a change, causing delays and backlog of requests.

What is a cover decrease?

A Cover Decrease is when we amend the Income Protection, Criticall Illness, TPD or Life cover to reduce the sum insured or make a change to a feature or option that results in a decrease in risk.

What is a payment frequency change?

Integrity offers two options for the frequency of payment, either annual or monthly.  A change in payment frequency would result in switching from one option to the other.

There was already a working design of the cover changes flow that was in use by the Customer Care team.

"My job was not to redesign the existing screens but to optimise the experience for performing cover decreases and payment frequency changes, taking into account product and experience rules."

Whilst the functionality was already in use by the Care team, we could not directly release it to Advisers as there were some fundamental limitations with the tool that either required lengthy dev fixes or an intimate understanding of how to use it in a way that prevents errors.

Also due to time and resource constraints of the dev team, we had to prioritise incremental enhancements. Giving Advisers the ability to perform instant cover decreases and simple payment frequency changes was seen as the easiest path to quickly deliver something of value to our users.

THE GOAL

Allow Advisers to self-service cover changes, starting off with cover decreases and payment frequency changes. Optimise the user experience with incremental enhancements to the existing UI.

"Rather than building a Ferrari with missing wheels, we are delivering a skateboard that works!"

In lieu of detailed personas and with limited time and resources for research, proto personas were created that identified three distinct user types under the Financial Advisers bucket.

Financial Advisers

Usually time poor, at times multi-tasking while quoting
Not as familiar with Portal as admin staff
Platform speed and internal forms their biggest pain point

Paraplanners

Prepare paperwork and SOAs
Utilise Risk Researcher
Help run quotes and submit applications

Client Services

More familiar with Portal
Less tech savvy
Follows Adviser’s instruction for running quotes
Low financial planning knowledge

Customer Care

Assist Adviser when help is needed
Run and submit quotes if Adviser is unable to self-service

Understanding cover decreases and how things are done today

My first few chats with the Customer Care team unveiled they were using a feature called 'Change Covers' through the Life Platform Portal to perform cover decreases. This feature was able to perform increases, decreases and payment frequency changes - but with caveats! The system had poor error handling and a lack of adequate controls, requiring the Care team to refer to a massive Confluence page with a long list of manual steps.

Confusing error message

Link to Confluence with long list of manual steps

After user shadowing the Care team, it was clear they were not properly actioning or even reading the manual steps. The documented page was way too overwhelming and filled with complexity. It was much too easy for them to select ‘All steps done’ and submit the changes anyway.

Once submitted, it would flow to IT Support team to put inforce. Any problems or issues would then be discovered by IT, causing longer delays in finalising the request. This created a massive backlog of IT tickets that needed to be resolved, further extending lead times to customers. Any system errors that were encountered (which were usually due to user input error) were also raised as an IT ticket, further adding to the Support queue workload.

Defining the scope and edges

Knowing nothing about what a cover decrease entails, I needed to understand all the possible scenarios and define any items that were out of scope for this project. Speaking with the Business Analyst allowed me to unpack everything shown in this table as a cover change request that falls within a decrease scenario.

Cover decrease scenarios

What about CPI?

After a few discussions with the Head Underwriter, it was determined clients can add CPI without underwriting for up to 3 years in a row - let’s bring in scope and allow option

Shadowing the user

(Customer Care)

Competitor Analysis

Form design best practise

(Desktop research)

Usability Testing

(Internal & Advisers)

5 x Advisers
2 x Customer Care

1 x BDM

Working within the rules

In order to provide for an experience that only allows for cover decreases, we had to lock down and disable any functionality that would constitute to an increase. Doing this was easy enough for the switches and checkboxes, but how could we implement adequate controls for the input boxes that needed to be cognisant of complex product rules?

Proactive prompts to inform cover amount parameters

Error handling for when user deviates from the parameters or encounter other constraints such as product rules for linked covers

Warning message for when the input is not a show stopper but awareness to be raised around the impacts of proceeding

Proactive prompts

When it comes to the sum insured, there are minimum and maximum limits for any given cover. This is further complicated when covers are combined, such that the rider cover cannot exceed the Life cover amount. We wanted to provide proactive messaging to inform the cover amount parameters, minimising the chances of error and having a negative experience.

We decided this proactive messaging would only be necessary for IP cover due to the many variables that impact min max limits, and we could control the experience for lump sum covers through error messaging (without overwhelming the user with too many product rules).

Initial design

Iteration 1

(from internal testing)

Iteration 2

(from internal testing)

Error handling

Because we could only allow for decreases, any user input that was a higher value would return an error. The messaging had to be clear that this is due to a limitation in functionality and not a restriction on the insurance product itself. Increases could still be done but had to go through a different channel, our Customer Care team.

It is also very likely when decreasing Life cover the linked TPD or CI may exceed the new Life cover amount, causing an error. To fix this, the user must reduce the TPD or CI cover. Inline validation will check against product rules and display error messages. However to allow full flexibility, navigation between tabs is not restricted. Therefore, a global visual affordance was needed to call out active errors. I added an error badge to the tabs, and an error banner that is triggered when the user attempts to submit the quote (containing quick links to fix the error).

Consideration for an error state was also needed for the premium 'shopping' cart, as it would not reprice correctly if there were any active errors. The cart would typically auto-refresh as errors are fixed, but a 'Refresh' button was included for added reassurance.

Inline error

Error badge, error state and banner

Warning message

In addition to tooltips, proactive help text, and error handling, we also needed to consider warning messages for when a client's annual income drops and their cover limits also change.

After discussions with the Product team, I learned that we cannot force a client to reduce their sum insured below what they currently have even if the maximum allowed under the product rules is now lower. There needed to be a way to communicate this and inform the user they would only be entitled to claim to the maximum allowed, should they wish to keep the current level of cover. A soft yellow warning message with inline warning icon was designed for this scenario.

Rethinking patterns and hidden options

If the client had Critical Illness Relapse as an optional extra on their policy, they could select the reduced risk option of Reset Critical Illness - which would be a decrease. However these two options are mutually exclusive, you can only have one or the other; but with the current design pattern of multi-select checkboxes, this proved to be confusing for Advisers. It was not immediately apparent that de-selecting CI relapse would enable the checkbox for Reset CI.

Task success rate from usability testing was 0%

All Advisers struggled with uncovering the hidden pattern!

As an MVP solution, I designed a static tooltip that informed the user of the hidden selection behaviour - this would require the least amount of dev effort. However for a longer term solution, the current UI pattern had to be changed.

To show a mutually exclusive relationship between the two options, I decided they needed to be grouped together and use radio buttons which would be a more appropriate pattern to allow selecting one option from a set. But at the same time we still needed to allow the user to multi-select any number of optional extras from the entire list. Grouping Critical Illness Reset and Relapse together allowed the user to either opt-in or out of this group, then make the single selection of reset or relapse.

Quick fix - MVP

(minimal dev effort)

Longer term solution

Solution yet to be user tested as the project got re-prioritised

The client consent..

Our original assumption (based on current work processes) was that we needed to obtain explicit consent from the client any time a change in cover were to happen, so I designed an experience around requesting the client’s approval via email or SMS.

Speaking with Care team unveiled that their current process was to directly action a decrease as long as the Adviser had requested it (which raised some compliance concerns). Other times they would already receive the consent upfront in the email trail, so there needed to be an option to upload consent as well as request consent.

Further discussion with Risk & Compliance raised some important questions:

Does consent need to specify what they are consenting to or can it be broad?
What is the validity period of a consent?
Will uploaded consent need to be checked for legitimacy?
i.e. not a random cat picture

Since we are allowing the Adviser to self service, any uploaded consent will need to be verified by the Care team. This extra step was not ideal as it would add to the Care team's workload and leadtime of executing a Decrease.

After a few more sessions with Legal, Risk and Compliance, it was determined that:

1. Client consent could be effected by the Adviser via a declaration that they are acting on the client’s behalf.

2. The declaration would need to be provided each time a cover change was made.

3. No client consent = no checking of uploads needed (yay!)

.. to Adviser Declaration experience

The beauty of this is we could build the declaration into the Review tab so each time a cover change were to be actioned, a simple checkbox would allow the Adviser to declare they are acting on the client's behalf.

With this much easier solution, I was glad we could scrap the entire client consent experience and implement a simple checkbox declaration on the Portal.

No more chasing the client for consent and waiting days for a reply!

The Review tab

➡️ Summary of changes

It was determined that the 'Review' tab needed to show a summary of the changes made. This tab served as a final confirmation before submitting. From a very basic display of the changed covers and their effective dates evolved into a table format that showed the ownership, the covers, payment frequency and the effective date.

Existing design

Iteration 1

However, usability testing with Advisers uncovered that the information in the table didn’t really tell them what exactly was changed. Advisers mentioned that..

"90% of the time, a Decrease results in reduction to cover amount"

The billing date was also important information as it could be different to the effective date and clients wanted to know when they would next be charged. Additionally, the existing panel width could only fit 4 columns within the current table, severely limiting the amount of information we could include.

After discussions with the front-end developer, I was able to expand the panel width to allow for 5 columns. I also combined the information in the Ownership and Covers column to maximise space for other crucial content like the Cover Amount and Billing date.

Iteration 2

(after Adviser testing)

This table was still just a summary. In order to see everything that was changed including features and optional extras, we needed to direct the user to open the Compare feature. This would open up a modal that showed a side by side comparison of what was changed against the current in force policy.

The Review tab

➡️ Compare & Export

What is the ideal placement of the Compare & Export feature?

The placement of the Compare feature along with the Export Quote feature was initially below the Refunds and premium increases. However usability testing showed that Advisers were completely missing this section as it was so far down the page that their focus was being directed to the tables above it.

Given this feature is one of the key goals of the 'Review' tab (so they can check all the changes had been made correctly), I moved this section to the top of the page. Eventually due to the length of the page and the amount of content, the Summary table and Premium refunds/increases were placed within accordions to reduce cognitive load.

It was deemed that the mental model of digesting information on this page should start with the Summary of changes, then direct the Adviser to review the detailed changes using the Compare tool. Given this, the Compare & Export links were subsequently moved below the Summary table within the accordion, and this section would remain expanded as default.

Initial design

Iteration 2

Iteration 1

The Review tab

➡️ Premium refunds and increase

In a cover decrease scenario it’s very likely a refund may be issued to the client if they are on an annual policy that is typically paid for in advance.

The very first design only included a one liner to explain refunds may be applicable, however we quickly realised there needed to be more detail. There could also be edge cases where a decrease may actually result in a premium increase, such as discounts dropping off or a change in payment frequency. Additionally, we needed to future proof the design for when we eventually release cover increases, where generally will be a premium increase situation.

A table format was adopted to itemise each cover and their respective refund or increase portion. A dynamic label for the Total would specify either refund or premium increase.

Iteration 1

Usability testing showed some Advisers were confused why there would be a premium payable in a decrease scenario. In order to ease any concerns, an info icon with tooltip was added to provide an explanation.

Since building out a separate comms process for communicating refunds or increases was not currently in scope, the Review tab was the only place where the Adviser could capture this information to inform their client. So a line was added to the table to prompt the user to take a screenshot if they wanted to retain a record. This was a temporary fix until we could build out an automated email comms process.

Iteration 2

Designing for all scenarios

Covert features and the shopping cart

Existing design

The new and improved dropdown was well received 😊

After making the change, users were able to find the 'Effective from' dropdown more easily, which saved them time and frustration.

Advisers couldn't find the 'Effective from' dropdown

One major insight from usability testing revealed that Advisers were having trouble finding the "Effective from" dropdown, which allowed them to select when changes should take effect. The dropdown was located within the premium calculations (internally known as the shopping cart). This was an existing component taken directly from the New Business flow.

I solved the problem by moving the dropdown to the top of the cart and making it more visually prominent

We wanted to keep the dropdown on the right side of the screen for Advisers who were familiar with the Portal, but we also needed to make it more visible for those who were not. I experimented with placing the dropdown at the top of the shopping cart and increasing the contrast using colour. The team preferred the purple option, which was our primary CTA colour.

Iteration 1

(colour variant A)

Iteration 1

(colour variant B)

Just when I thought I was done with the shopping cart..

There was another problem with the current UI.

Iteration 2

(variant A)

'Compare' and 'Export' were being overlooked

Usability testing showed two other features were also being missed - the 'Compare' and 'Export' (buried at the bottom of the shopping cart).

Labelling too vague, not descriptive enough

What are they 'comparing' and what are they 'exporting'?

Features need to remain globally accessible

Whilst the Compare and Export features could be accessed from the Review tab, we decided it should also remain on the shopping cart. This made it accessible no matter which tab the user was currently on. If the Adviser wanted to quickly compare and export after making a change, they could do so without needing to navigate to the Review tab.

While the obvious solution was to create a static tooltip to highlight the feature, I explored another option of moving these two features from the bottom of the cart where they were easily missed and shifting them to the top, grouped with the 'Effective from' dropdown as a separate component.

This made more sense as all actions were together and the cart was purely for view and display. It also meant that the 'Export quote' option was in a consistent place as the New Business flow for user familiarity, whilst the extra space allowed for more descriptive labelling.

A fresh take on a classic issue

Final design did not get a chance to be tested with Advisers as the project got re-prioritised due to focus on stabilising processes. However testing with internal teams and BDMs (some who used to be Advisers themselves) showed positive feedback on the redesign.

Iteration 2

(variant B)

From status banner to quote handling

So we need a Status Banner?

After submitting a decrease, a status bar was thought to be required which would show the status of active quotes and client consent. Several designs were explored, including list format and progress timeline, with action links to resume, edit, discard a quote, resend client consent or cancel cover change. Meanwhile there was a separate piece of work ongoing for an 'Application Hub' that would house all applications. This was also considered as a place to display and manage the decrease application.

Variant A

Variant B

Variant C

No client consent = instant decrease

Eventually all options for a status display were discarded as we no longer required client consent and a submitted decrease would become inforce instantly. We did however still need a way to resume or discard a quote.

Keeping the quote accessible from the client overview screen meant exploring the option of a quote banner, making it clear and visible there was an in-flight quote. This banner would need to work for all user groups, and Care team would need to be able to pick up and manage quotes that were started by Advisers.

Quote handling between user groups

I facilitated a co-design workshop with Business Analysts and Engineers to brainstorm solutions and identify tech limitations.

Some key questions surfaced:

We want to encourage Advisers to self-service, but Care needs to be able to take over if they have technical problems. How do we allow Care to resume a quote the Adviser started? Should we also allow the Adviser access to complete a quote Care has started?
What would happen if it turns out the decrease request is actually an increase?
What would be the process if the request is a combination of decrease and increase?

With some clear answers:

Both Care and Advisers should be able to access the same Decrease quote banner and have ability to resume, discard, submit.
If Care team members start a decrease quote but need to change it to an increase quote, they should be able to easily copy the changes over to the unrestricted 'Change covers' flow.
Combination changes would need to be performed via the 'Change covers' flow, so keep access open to both flows for Care team.

A solution is born

As shown above, inflight quote banner would appear like so for Adviser and Care user groups when the other party had started a quote. Main difference being the extra option for Care team to copy the quote over to the Change covers flow. The engineers informed this functionality would take a bit of work so it was deemed as a ‘nice to have’ and the short term workaround would be to discard the decrease quote and manually re-enter under the Change covers flow.

Payment frequency MVP

Whilst perfecting the decrease flow, we discovered that we could release the ability to perform a standalone payment frequency change as a quick win, giving Advisers something they could service right away.

I extracted the payment frequency tab from the Decrease flow and made it a standalone option in the client overview navigation panel, with a link to updating payment details. We still kept the payment frequency tab within the Decrease flow as well, since Advisers told us they appreciated being able to make frequency changes while actioning a decrease.

Payment frequency access from Client Overview

Option 1

standalone payment frequency flow

Insights from usability testing

Billing date a key concern for payment frequency changes

Advisers liked the fast link to update payment details, but some would prefer to have it on the same screen as the payment frequency change, since these two actions are often done together.

The Care team can't tell if a frequency change was made to a policy by looking at the current quote report. Also not relevant for frequency changes as they just want to see the difference in premium.

The future of payment frequency

Based on these insights, I explored a more robust solution to the payment frequency dilemma.

How might we allow the ability to change payment frequency within the payment details feature that users are already familiar with?

Updating payment details was a feature already available to Advisers. It was structured in a way where each payment detail and method was separated by ownership. Adding a pencil icon next to the Payment frequency label allowed for a simple intuitive way to indicate affordance for editing. Clicking this would open a modal to allow change of frequency for that ownership.

Re-using components or re-design?

I utilised the same component from the payment frequency flow, so our developers didn’t have to create new components if there were time and resource constraints. However a cleaner and more user friendly design would be to implement the option on the right which uses a segmented button and dynamically displays premium, billing date and effective date according to the frequency and 'effective from' selected. Ability to export a 'Premium comparison report' could also be downloaded, addressing users need for seeing premium differences.

Modal

(use existing components)

Modal

(redesign)

Unfortunately I did not get the chance to test this redesign before the project pivoted away from digital enhancements to process improvements.

"That was fast, that was really good. It’s like the existing portal so felt very confident using it."

- Financial Adviser

ADVISER USABILITY TESTING

With a high SUS score, the results indicated that overall usability for decreases and frequency changes was excellent. Only minor iterations needed based on the qualitative feedback from Advisers.

User testing session with Financial Adviser

SUS Score.

Decrease covers

Edit payment frequency

Pivot to 'Decrease' Process Optimisation

Next steps: Re-test all iterations and redesigns whilst engineers developed payment frequency MVP and other quick fixes

However..

Due to the massive backlog of IT tickets, remediation incidents and loose internal processes, the business decided to pivot all resources to stabilising business processes. Digital enhancements were paused and a focus on process improvement ensued.

I was re-directed to optimising the cover decrease process, working closely with Customer Care and other business stakeholders to unpack process inefficiencies and design process solutions, enabling our frontline teams to better serve our partners and clients. Self serve Adviser decreases was shelved for the backlog.

Outcomes & Reflections

As a result of the process optimisation work..

I was able to reduce time to quote from 5 days to 2 hours attributed to the following:

Documented clear and concise process steps for the Care team which helped eliminate redundant and incorrectly raised tickets to IT Support
Created template for IT tickets so crucial information was provided upfront which reduced the amount of back and forth between teams
Improved Portal risk control environment by introducing QA steps and peer review buddy system
Identified process gaps and plugged those gaps with clearly defined steps so greater efficiency and clarity was achieved
Eliminated the need for quoting decreases altogether if request came from or had written confirmation from policy owner
Played an active role in the release of new pricing engine designed to eliminate the need for manual repricing, significantly reducing time to generate a quote
IT Support queue tickets reduced by 70%

Key Takeaways

Designing around complex product rules and a system ridden with defects was challenging
Time and resource constraints meant not designing new components, so at times forgoing my idea of an ideal solution to work lean and deliver something quickly
Ensuring consistency with other features that are also being built simultaneously
A/B testing could have provided more quantifiable feedback on the designs that had multiple options
Being comfortable with constant re-prioritisation and changing roadmaps
Asking the right questions to unpack a problem, especially with stakeholders who dont speak design and being able to frame and direct that conversation down a path that gets me the answers I'm seeking. This was harder than I thought, especially when dealing with complex products while getting down to the nitty gritty details. Being able to navigate tangents and bring the focus back to the topic/task at hand is truly a skill I've come to appreciate!

View Next Project