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.



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.

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 :


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.


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 ( ... I'm sorry)

Still, unless the percentage of users who finds it difficult to use has become significant, it seems like we'll still be using this design, at least for now.

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.


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.

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.


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:

due to NDA there are other features that I am not allow to talk about it yet. please check back later for more!