Overview

With GoTroo, policy holders can now:

View Their Policy

Accessible information about the basics of life insurance policy contracts.

Make Change Requests

Updating personal information made convenient.

File Claims

Easily submit and sign documents online for hassle-free processing of claim requests.

Problem

Confidence

Prior to my onboarding, a beta version was released to a select few priority banking clients. Here's the initial look of the GoTroo portal:

The main goal for the MVP was to digitize the paper-heavy process: something that's definitely taking a while for insurance companies to completely undertake. At that point, it was necessary to use low-cost methods (I used cognitive walkthroughs) to pinpoint some usability issues as the pressure to launch soon was inevitable.

To list some issues:

  1. methods to login are hidden inside a dropdown, while there are only 2 options

  2. policy information is structured for swiping through 4 pages with no way to skip some pages

  3. a visible logout button within finger's reach and no additional prompt

  4. policy status lacks context and calls to action: active policies show a check mark, lapsed policies show an x mark

  5. non-industry standard and technical jargon

  6. responsive behaviour uses stretching instead of stacking

  7. too playful and lacking any sense of seriousness for a contract-based portal: policies are displayed as circles

  8. information architecture for form-based pages are treated as completely separate from a policy contract; having multiple policies prompts users to select which policy to apply the changes for

  9. using a mobile native app approach for a web-based app: the bottom toolbar is something common with native apps but rarely used with web apps in larger screens due to a difference in eye movement

Lack of Clarity

There is a lot of unrealized vision for the portal, which is also why it took a while to get signed off for launch. Here's a list of high-level goals that inspired GoTroo's reason for being.

1

The ability to view policy packs for the 15-day free-look period.

This would require logging in using the portal. And since an e-mail and a mobile number were both required for policy application, users don't have to register an account.

2

Viewing investment funds.

Majority of Troo policy holders have investment-linked policies who are keen on monitoring the growth of their funds. This is also a commonly requested information from the advisors.

3

Modifying details.

Written forms are not always free from errors as (things gets lost in transmission with manual input involved) therefore we should at least give them the ability to modify personal information.

4

Claims Process

The whole point of being a life insurer is to guarantee peace of mind for the insured. Naturally, a handy guide for the documentary requirements should always be available should the inevitable happen.

Process

And some inevitable trade-offs

Knowing the above issues, I started with educating myself on the industry basics. Working on a portal requires a general understanding of insurance. As a newcomer, it took me a while and tons of questions.

I then went on to do a series of guerrilla testing among colleagues every time I finish designing a feature. My biggest constraint is the lack of budget and support for research; I was limited to small scale usability testing, done internally. The least I could do was to get  participants with the least knowledge of the internal insurance operation technicalities. I had the subjects accomplish goals on-the-spot to test the relative ease-of-use of the portal on a mobile phone.*

These testing sessions also gave us an idea of the kind of features we should be working on for the next few sprints. Another particular challenge is having non-standardized terms for some concepts. We defaulted to using what makes the most sense while still being understandable; this can still be tested further down the line.

* Web analytics show majority (about 3/4) of portal access is made through a mobile device

Solutions

A Breakdown of Design Decisions

Methods to login are hidden inside a dropdown, while there are only 2 options.

As a brand, Troo is really a colorful one: however that can easily make people think they're visiting something that isn't related to insurance. When transitioning to mobile, the text changes in color to pink to accomodate how the background scales down. We want to avoid this unnecessary code. Additionally, we want to show only what's necessary to guide people to successfully log in. To solve this issue in the portal, we opted to for a single a primary color for buttons: pink. Fun is reflected using fully rounded corners for the buttons.

Then

Now

Error prevention: what if an e-mail is unregistered?

Access is given with whatever the policy holder used upon application. If the situation calls for a change in email, it is still limited to contacting Troo directly. As much as we'd like to avoid this, it was a constraint we had to work with. We just displayed contact information as visible as possible. This includes displaying verbal cues instead of just relying on visual icons and understanding that not everyone prefers to click buttons when sending e-mails or calling.

Then

Now

Policy information is structured for swiping through 4 pages with no way to skip some of them.

Having a lot of unstructured information can be overwhelming. While this is important to policy contracts, we can at least lump together all the related information.

Then

Now

Dissecting the structure, we divided a policy contract into three primary sections: (1) the policy data, (2) investments for investment-linked products, and (3) documents.
Once payment-related features are available, an additional (4) billing tab will be added.

A visible logout button within finger's reach, with no additional prompt.

The logout button is a located at the top left. Once clicked, users are signed out automatically with no additional prompt. As a user, I should not be able to log myself out accidentally.
For security reasons, sessions are limited to 15 minutes of inactivity.

Then

Now

Form pages are treated separately from a policy contract.

A user having multiple policies prompts them to select which policy to apply the changes for and what kind of change they're requesting; apart from being inefficient, this is also prone to errors and introduces a lot of cognitive load by having a lot of options. By using categories, we were able to put better context for the requests: personal information goes to profile, updating the frequency goes to the payments section, and so on.

Then

Now

IMPACT

Life planning made easy with GoTroo.

By 2020, GoTroo gets a steady stream of daily visitors and has been instrumental in the transition from bulky paper-based policy packs to web-based summaries of policy contracts. Upon approval, policy holders get notified via SMS and get instant access to their policy pack through GoTroo. Beyond the accessibility impact to almost 30,000 existing policy holders, Troo Advisors also reported a slight increase in the amount of time they get to save once their clients' no longer had to go through them for policy-related inquiries: an indirect benefit of having a customer portal.*

* Based on data gathered from in-depth interviews for another digital asset of Troo involving sales agents.

Future

What's Next for GoTroo?

Post-launch, I worked on a few more research work exploring a counterpart web app for Troo Advisors, mapping out a day in their life both in and out of a bank branch using the contextual inqury research method. Based on the data gathered from 15 Troo Advisors, GoTroo's user journey begins at the end of the policy application.

Some research topics and areas for exploration

  1. Build a vision going beyond just "digitization"

  2. Validating a set of features concerning payments through concept testing methods via survey

  3. A mobile version: further studies to identify if the uproar for a native app is a user need or just a nice-to-have

  4. Merging the portal and the website to provide a single, cohesive experience.

Links and References

  1. Work done in sprints and as part of a scrum team with Edric Caranto handling majority of front-end development. (Scrum Team composition: Interim Product Owners, UX Designer, Business Analyst, 2 Full-stack Engineers, QA Engineer, Scrum Master)

  2. Logo by Andre Cui and video by Em Barriga

  3. Copywriting by Larosh Amara Reyes

  4. Visit GoTroo

  5. Visit Troo

More of My Work