Back Projects
Insurance Product Library
IXT is a modern core system designed to empower insurance companies with efficient speed, security, and flexibility to integrate with third-party applications. It helps the insurance industry create an ecosystem with the latest technology. Essentially, IXT serves as a B2B SaaS that caters to insurance professionals, but ultimately benefits insurance consumers in the market. In today's competitive market, insurance companies need to launch their products quickly to reach the market effectively.
As one of the modules, product module serves as the most important one because it is responsible for the setting up all the details and rules for an insurance product. The rest of insurance business is based on this core module.
However, one of the biggest challenges that the product module faces is its complexity. Considering the complexity of an insurance product, the product module must be designed with superb flexibility to accommodate all necessary features. For just a part of an insurance product, in order to fulfill the need to do the underwriting, users have to setup a lot of fields and elements to accomplish the rules.
Setting up a complex insurance product makes the system complex. Not only complex but way too many fields to control / fill in.
As the UX designer, I identified this long existing problem and proposed the solution to PMs & stakeholders when conducting a related project request.
Product pain points > Structure > flows > wireframes > behavior specs
First of all, in IXT, when a user wants to setup an underwriting rule that "insured needs to be over 18". She has to create an attribute, assign the data detail and name it "age". Then create a rule when setting up rule using all the created attribute. As you can see the example below, an attribute is the basic block unit for the flexibility. And user would have to setup quite many number of fields for even the simplest type of the attribute.
But, for the most if not all of the attributes, there are representing the same thing in the real world. For instance again, the insured's age, it' always a integer type of data that index that how many years that an insured has lived. Therefore, it would be reasonable to manage the attribute centralized instead of building the attributes in each product repeatedly.
Therefore, When the user could add, edit, or even delete the attribute when its necessary all at once, does not have to do it over again for another similar product using the same concept.
Introduce the library, help users manage it with much more efficiency and less human error.
I have planned this design a library system that could apply to more than an attribute level. It aims to improve all the efficiency and lower the human error rate for all the elements shared the same traits. It could be rules, plans, that can actually speed up the operation of insurance with the same level of flexibility.
Scalable and flexible would help your product in the long run.
Although the product team all agreed with the library concept, we have only built the attribute part. Looking forward that the rest part of library could be implemented
