Accessible information about the basics of life insurance policy contracts.
Updating personal information made convenient.
Easily submit and sign documents online for hassle-free processing of claim requests.
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.
methods to login are hidden inside a dropdown, while there are only 2 options
policy information is structured for swiping through 4 pages with no way to skip some pages
a visible logout button within finger's reach and no additional prompt
policy status lacks context and calls to action: active policies show a check mark, lapsed policies show an x mark
non-industry standard and technical jargon
responsive behaviour uses stretching instead of stacking
too playful and lacking any sense of seriousness for a contract-based portal: policies are displayed as circles
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
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
Build a vision going beyond just "digitization"
Validating a set of features concerning payments through concept testing methods via survey
A mobile version: further studies to identify if the uproar for a native app is a user need or just a nice-to-have
Merging the portal and the website to provide a single, cohesive experience.
Links and References
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)
Logo by Andre Cui and video by Em Barriga
Copywriting by Larosh Amara Reyes