UX Design Intern at Bowtie

2019 MAY - JULY, HONG KONG
OVERVIEW
Bowtie Life Insurance Company is the first authorised virtual insurance company in Hong Kong. With Sun Life as its major investor, Bowtie has started selling Voluntary Health Insurance Scheme (VHIS, a product backed by the HKSAR government) since April, 2019.

As a UX design intern there I worked mostly on enhancing some current features, as well as introducing new ones for their online application and underwriting experience.
I also had the chance to participate in a mini design sprint and work with different teams such as engineering, actuarial and customer service throughout the period. And of course, I got to know a lot more about the insurance industry and most importantly, how to balance user experience, compliance requirements and engineering effort.

Tools: Sketch, Invision, Webflow

*Their platform doesn't support English yet so I'll be providing translation below.
01. WHAT I DID
OCCUPATION SEARCH AND SELECTION

It is our goal to design a widget that will allow users to search and select their occupation easily and accurately. However, due to compliance requirements, we have to base our design on a list of job titles that are quite outdated and incomplete.

READ MORE

A. Identifying the problem

One's occupation and its job nature could affect the underwriting result, so it is very important to make sure that the users can find and choose their job accurately and efficiently. However, due to compliance requirements, we can only follow a restricted and outdated list that makes designing the widget a tad more difficult.

Before starting on the design process we had a quick meeting and decided on a few things:
1. we can group jobs according to their names and loading factor
2. there should probably be a search field somewhere
3. we could let them choose their industry first, then search for the job

However, I soon realised that it is not as simple as we thought it was.
  • The list is not complete

    For example, there is no option for 'frontend developer' under the 'Bank / Finance / Insurance Industry' but in reality, such jobs exist. So for someone working as a frontend developer in an insurance company, the person will most probably choose 'Insurance industry', only to find that there's no such option under it. Therefore, putting industry as the first drop down doesn't seem to work.
  • It is quite impossible to group the data for filtering

    Grouping jobs according to e.g. indoor / outdoors, office / non-office is impossible because there're bound to be jobs that doesn't fit in just one category.
  • Manipulating the data takes way too much effort

    Simple manipulation like using Excel to combine jobs with the same loading factor with similar names is possible, but advance manipulation like completing the list ourselves with the data on hand (to solve the problem listed above) is way too complicated. A lot of human power is needed too to make sure that there's no mistake, so this does not sound like a feasible solution.

B. Design Process

Well, it actually took me a few days to identify all of the challenges listed above. Luckily, my colleagues helped a lot via linking me resources and giving me a 'think out of the box' idea. He recommended me to try and forget about how limiting the data is and design something that would work with any set of data. Of course, the widget should be specifically designed to overcome shortcomings of the current list we have, but looking at this problem in another way really helped with coming up with a better solution.

Still, I was struggling to come up draft designs for a long time already so my supervisor came to rescue with the all mighty problem solving process - a mini design sprint. Between me, the graphic design intern and my supervisor, we followed the double diamond design process and started with 'discovering and defining' the goals. They were:

1. To make it easy for users to report their occupation
2. Making sure that the users can report accurately
3. To minimise users calling the customer service from not being able to find their job on the list

Then, for each of the 3 main problem we started brainstorming possible solutions through 'crazy 8s'.

I put in a lot of unrealistic solutions that cannot be achieved with our current technology standards but you know, it's always fun to dream (¬‿¬). But anyway, those with a star are the ones that I've chosen to combine into my draft solution. Naturally the next step for us is to draw up wireframes of our draft final solutions.


How I designed my draft final solution

For my final draft solution I opted for a single search field and a choice of common job titles under it because according to our data, there is in fact common industries / jobs our insurers tend to be in.

When the user type something into the search field, a couple of cases would occur:

a. keyword case
Let's say the user typed in 'worker'. A dropdown will appear with industries and any jobs under it that has the word 'worker'.

b. 100% match case
Let's say the user typed in 'Engineer'. According to the list, there is in fact one option that matches it 100% - 'Engineer' in the printing industry. There are of course other 'engineer's in other industries, but the job title doesn't match perfectly, so I proposed to have a line saying 'is this not what you're looking for? take a look at the others...' and list e.g. 'Civil Engineer' in the construction industry etc under it.

c. no 100% match and not a keyword case
Weirdly enough, there is no 'graphic design' on the list. So if users typed that in the search box, a line saying 'Please choose the closest match' with other design related jobs under it will appear.

d. no match at all
If anyone decided to search with slangs, no result will show up. In this case, there will be a guide teaching them how to search for their job titles accurately.

Once the user clicked on a job title, it will be chosen and a short description will appear below the field so that the user can double check that it is in fact what his or her job is about.

Voting
Now that each of us have our final solution ready, my supervisor asked a couple of co-workers from different apartment (actuarial, underwriting, engineering, and management) for a short presentation and voting session. Each of them put stars on whatever features that they like, and from that, we can decided on the final solution.

User journey mapping and prototyping
I then created a user journey map and matched the screens with stars on it (I didn't show other screens designed by my colleagues here.). After that, we started using Sketch to draw up the screens and prototyped it with Invision.

Final design
My internship came to an end at that point so I couldn't join the user testing round. Anyway, a few weeks later they made the final version public :





A SWITCH FOR KG / LB
Although the majority of people in Hong Kong tend to use kg instead of lb when declaring their weight, it is still important to cater those who are more comfortable with using lb. But of course, the design should not affect the user journey of those in the kg category at all.

READ MORE

A. Identifying the problem

There is a small amount of applicants who are used to declaring their weight in lb rather than kg, so a switch between the two units have to be designed to cater that group of users.

B. Design process & final result

Finding users to test was quite difficult though, since out of 11 of my colleagues, only 2 of them said they would use lb. Anyhow, I designed a few options for them to choose from, and both of them have decided on having a button like this:

As you can see the switch button has 'Pound' on the left and 'Kilogram' on the right. The unit is set to 'kg' initially because that's what most people use, so once the user input a value into it, the unit 'kg' will appear. If they chose 'Pound' from the switch button, the unit will change to 'lb' while the value will remain constant to remind users that they have changed their weight unit.

REDESIGNING THE DATE OF BIRTH FIELD
The previous date of birth widget was not user friendly at all so I was given the task to redesign it. This was a seemingly simple task given to me early on in my internship, but soon enough I realised that form designs are not as straightforward as I thought it'd be.

READ MORE

A. Identifying the problem


They were using a date picker that asks you for your year of birth in a dropdown kind of format (as you can imagine it'd be a pain in the ass to scroll until you find it), and then a calendar will appear to let you choose your month and date of birth. This is definitely not an easy way to declare your DOB so I was given the mission to redesign it.


B. Design process & final result

From research I found out that a lot of forms asks for e.g. DD/MM/YYYY or MM/DD/YYYY, but of course, the risk of filling in the month in the DD area or vice versa is very high. In order to prevent this from happening, I've finally opted for having 3 separate fields i.e. year, month and day:





REDESIGNING THE ADDRESS FIELD
The previous date of birth widget was not user friendly at all so I was given the task to redesign it. This was a seemingly simple task given to me early on in my internship, but soon enough I realised that form designs are not as straightforward as I thought it'd be.

READ MORE

A. Identifying the problem


The old version of the address field under the 'Personal Information' section is structured this way, where each of the fields ‘Flat, Floor, Block, Estate, Street, Area' has its own input box. This has led to a lot of confusions since such a generalised address format doesn't work for every users in Hong Kong.


B. Design Process
To solve this problem, I started with researching online, sketching possible solutions, and then combining & narrowing them down into 3 choices. Then I asked around for people to vote, and have reached a conclusion that having 2 fields would be the best.

C. Final results and feedback

The application was updated and now the form looks like this. There's improvement - less users are making mistakes or having trouble filling in their address, but new problems have surfaced as well. I was told that a few applicants do not understand why the '/' is there, and some are still filling in their address wrong. So a memorable lesson I learnt was: do not overestimate users' ability (I'm sorry.) I made a mistake assuming everyone will understand the purpose of the design. Anyway, the good news is that it's still an improvement from the old address form, so it will probably remain in this state until there are a significant amount of applicants finding it difficult to use.
due to NDA there are other features that I am not allow to talk about it yet. please check back later for more!
TABLE OF CONTENT
05. Secret
06. Secret
07. Secret
08. Secret
09. Secret
10. Final takeaway
*Due to NDA I can only disclose work that have gone public
*Check out the online underwriting app here (warning: traditional chinese version available only)
01.  Occupation search & selection
A. Identifying the problem

One's occupation and its job nature could affect the underwriting result, so it is very important to make sure that the users can find and choose their job accurately and efficiently. However, due to compliance requirements, we can only follow a restricted and outdated list that makes designing the widget a tad more difficult.

Before starting on the design process we had a quick meeting and decided on a few things: 
1. we can group jobs according to their names and loading factor
2. there should probably be a search field somewhere for users
3. we could let them choose their industry first, then search for the job

However, I soon realised that it is not as simple as we thought it was.
  • The list is not complete

    For example, there is no option for 'frontend developer' under the 'Bank / Finance / Insurance Industry' but in reality, such jobs exist. So for someone working as a frontend developer in an insurance company, the person will most probably choose 'Insurance industry', only to find that there's no such option under it. Therefore, putting industry as the first drop down doesn't seem to work.

  • It is quite impossible to group the data for filtering

    Grouping jobs according to e.g. indoor / outdoors, office / non-office is impossible because there're bound to be jobs that doesn't fit in just one category.

  • Manipulating the data takes way too much effort

    Simple manipulation like using Excel to combine jobs with the same loading factor with similar names is possible, but advance manipulation like completing the list ourselves with the data on hand (to solve the problem listed above) is way too complicated. A lot of human power is needed too to make sure that there's no mistake, so this does not sound like a feasible solution.

B. Design Process

After exploring different options and hitting dead-ends in every one of them, my supervisor came to rescue with the all mighty problem solving process - a mini design sprint.

Between me, the graphic design intern and my supervisor, we followed the double diamond design process and started with 'discovering and defining' the goals. They were:

1. To make it easy for users to report their occupation
2. Making sure that the users can report accurately
3. To minimise users calling the customer service from not being able to find their job on the list

Then, for each of the 3 main problem we started brainstorming possible solutions through 'crazy 8s'.
I put in a lot of unrealistic solutions that cannot be achieved with our current technology standards but you know, it's always fun to dream (¬‿¬). But anyway, those with a star are the ones that I've chosen to combine into my draft solution.

Naturally the next step for us is to draw up wireframes of our draft final solutions.


How I designed my draft final solution

For my final draft solution I opted for a single search field and a choice of common job titles under it because according to our data, there is in fact common industries / jobs our insurers tend to be in.



NEXT ------>
01.  REDESIGNING THE ADDRESS FIELD
A. Identifying the problem

The old version of the address field under the 'Personal Information' section is structured this way, where each of the fields ‘Flat, Floor, Block, Estate, Street, Area' has its own input box. This has led to a lot of confusions since such a generalised address format doesn't work for every users in Hong Kong.
B. Design Process

To solve this problem, I started with researching online, sketching possible solutions, and then combining & narrowing them down into 3 choices. Then I asked around for people to vote, and have reached a conclusion that having 2 fields would be the best.
C. Final results and feedback

The application was updated and now the form looks like this. There's improvement - less users are making mistakes or having trouble filling in their address, but new problems have surfaced as well. I was told that a few applicants do not understand why the '/' is there, and some are still filling in their address wrong. So a memorable lesson I learnt was: do not overestimate users' ability D: (I'm sorry.) I made a mistake assuming everyone will understand the purpose of the design.

Anyway, the good news is that it's still an improvement from the old address form, so it will probably remain in this state until there are a significant amount of applicants finding it difficult to use.
02.   REDESIGNING THE DATE OF BIRTH FIELD
A. Identifying the problem

They were using a date picker that asks you for your year of birth in a dropdown kind of format (as you can imagine it'd be a pain in the ass to scroll until you find it), and then a calendar will appear to let you choose your month and date of birth. This is definitely not an easy way to declare your DOB so I was given the mission to redesign it.


B. Design process & final result

From research I found out that a lot of forms asks for e.g. DD/MM/YYYY or MM/DD/YYYY, but of course, the risk of filling in the month in the DD area or vice versa is very high. In order to prevent this from happening, I've finally opted for having 3 separate fields i.e. year, month and day:
And because in the Chinese format, all of 'year, month, and date' has its own unit so when the user type in their DOB, respective units will pop up to remind them that they are filling in e.g. the month field, not the day field.

From the gif below you can see that the units appear:

1999 'year'
1 'month'
1 'day'
03.   A SWITCH FOR KG/LB
A. Identifying the problem

There is a small amount of applicants who are used to declaring their weight in lb rather than kg, so a switch between the two units have to be designed to cater that group of users.


B. Design process & final result

Finding users to test was quite difficult though, since out of 11 of my colleagues, only 2 of them said they would use lb. Anyhow, I designed a few options for them to choose from, and both of them have decided on having a button like this:
As you can see the switch button has 'Pound' on the left and 'Kilogram' on the right. The unit is set to 'kg' initially because that's what most people use, so once the user input a value into it, the unit 'kg' will appear. If they chose 'Pound' from the switch button, the unit will change to 'lb' while the value will remain constant to remind users that they have changed their weight unit.
10.   FINAL TAKEAWAY
UX design is not simple, and when it's mixed with insurance, it's extra difficult. ¯\_(ツ)_/¯ But still, I'm so glad that I had the chance to help (even for just a little) with making insurance more user friendly. Here are the some stuff I learnt and skills I gained after my internship at Bowtie:


  • What looks easy is actually not that easy.

    When I was given a task the first thought I had was - hm, seems quite straightforward. However, the more I dive into it, the more problem I'd discover.
    I want to talk more about it but it's still under NDA...

  • It is about balancing users and feasibility.

    When I first got introduced to UX I thought it's only about finding and designing what's best for the users. I was very wrong - it is in fact more about balancing the users need and resources available on our hands. What engineers can achieve now will limit what we can design, as well as whatever compliance requirements they have in different companies. Especially in the Insurance industry where some stuff are still quite old-fashioned and traditional, working around it takes extra effort. And that is exactly what UX designers have to do.
02. FINAL THOUGHTS
Prior to this internship, my only 'insurance related' moments were buying travel insurance online and reading my university's international student health insurance info pdf when I'm sick. And the first thing that comes to my mind when I think of them? A very, very thick booklet of what it covers and a pile of application documents. Insurance is a very tedious chore that we have to deal with in our daily life (#sadadultmoments), and I'm glad to know that a lot of startups, even traditional companies, are slowly trying to make it more user friendly.

As cheesy as it sounds, I really did learn a lot. Not only was I given advice on how to choose the best deal by their actuarial analysts, I also got to understand how UX design work in the real life:

1. It is about balancing usability and feasibility.

'Doing what's best for users' is not our job, 'doing what's best for users given the resources' is. I was naive enough to think that whatever solution backed with a title of 'most user friendly' will make the cut, but no, as UX designers we have to consider what's feasible for the engineering team, as well as any compliance requirements they have in different companies. Especially in the Insurance industry where some stuff are still quite old-fashioned and traditional, working around it takes extra effort.

  • What looks easy is probably not that easy.

    When I was given a task the first thought I had was - hm, seems quite straightforward. However, the more I dive into it, the more problem I'd discover. I want to talk more about it but it's still under NDA...

  • It is about balancing users and feasibility.

    When I first got introduced to UX I thought it's only about finding and designing what's best for the users. I was very wrong - it is in fact more about balancing the users need and resources available on our hands. What engineers can achieve now will limit what we can design, as well as whatever compliance requirements they have in different companies. Especially in the Insurance industry where some stuff are still quite old-fashioned and traditional, working around it takes extra effort. And that is exactly what UX designers have to do.
  • UX is actually pretty similar to engineering.

    Although I did touch on some UI and graphic design during my internship, most of my work is not that 'visual'.
2. UX design is actually pretty similar to engineering.

I love how 'non-visual' UX design can be. Of course, I still enjoy the UI or occasional graphic design work I had, but I find myself gearing towards UX more than the visual part. It is very much like engineering because it's basically research, problem solving, documenting, and testing, so the only difference would be designing through a creative medium vs a technical one. I still really enjoy the problem solving part of engineering, so it's great to know that with UX I can work on apps and websites, design cool experiences and continue with solving real life problems.


3. User behaviour can sometimes be surprisingly unpredictable.

Even after doing user testings within the company, there are bound to be some odd / unpredictable results appearing after the feature goes online. And although I know it's impossible to cater everyone, it can be eye opening to see how certain people would interact with the design in ways I've never consider.


GET IN TOUCH

Contact me through my social media or via email! I'm open to internship opportunities, freelancing projects and more!
CONTACT ME VIA EMAIL
DESIGNED FROM SCRATCH WITH WEBFLOW.
COPYRIGHT @ 2019 NEROLI KO. ALL RIGHTS RESERVED.
COPYRIGHT @ 2019 NEROLI KO. ALL RIGHTS RESERVED. DESIGNED FROM SCRATCH WITH WEBFLOW.