The confidential information in this case study has been altered.
“ When is the right time to create a whole new component on a platform that develops all components on their own? ”
Background
The concern about business disputes with customers and the complex rules of insurance products made system update or data migration in insurance core platform particularly difficult, which led to hundreds of products accumulated in the database throughout years of operation.
It created pain points to channels when selecting sellable products & plans (usually dozens) was the first and essential step in the distribution. However, in this company’s current core platform, I found out that there were no existing components which could perfectly support this step.
Research
“ Why insurance products were so complex? ”
Insurance products that were strictly regulated by authorities, categories, and types largely affected the selling for companies and needed companies to design compatible products based on different channels’ expertise, which also needed product selection to be PRECISE, such as:
1. The certain licensed categories and types in channels’ sellable regions. 2. The specialty in generating business for specific categories or types.
Beside the restriction of laws, there were different insurance core platforms in the market catering for different STRUCTURE of products because of the needs from different types of insurance products, including:
Fixed Package (Product & Plan) They generally had 2 layers structure in products and plans as products could easily group a certain set of plans and be moved around easier in core platforms. Plus, their plan sets in products rarely change. Flexible Package (Plan) They had so many plans like buffet for customers to chose as needed. Their rider plans (multiple side dishes) could go along with different types or categories of core plan (one main dish) that product layer eventually served no purpose.
Challenges
On the other hand, this company developed all UI components with limited RWD for their platform, which meant any new components should be well-validated before it could be developed. I was searching for existing components to enhance given that the cost of developing a new one tends to be higher. But the most useable components were still unfriendly due to:
Component A It didn’t show selected products under different filtered conditions. Component B It didn’t show enough product information to distinguish similar ones.
“ Developers — We may need to develop B as a new one if you need to support layers in products and plans. ”
Ideation
In the general context, users were required to select dozens products from hundreds in the insurance companies’ database, which was a huge amount of information to go over. So I weighed up my options in the different aspect to decide if a new component was required:
Business During product demo, product selection as the first step would appear in channels, schedules, and goals. The currently unfriendly components would very likely to discourage the potential clients and their end users. User Experience It could create huge confusion to end users when they couldn’t see products’ detailed info such as categories, types, and added time while sometimes different categories of products could share the same name. Development Developers mentioned that structure displayed in selected products & plans may need 2 weeks to develop since the selection logic in different level could be complex. But it won’t necessarily be “a huge cost”.
As many evidence point out the disadvantages of currently existing components and the benefits of a new component that gathered all the perks of existing components. I decided to create a new one and presented its idea to stakeholders and consultants.
Verification
During the verification with consultants, they provide insights into all sizes of insurance companies with different numbers of products, with new component providing best experience for all sizes may appear challenging since some needs were conflicted with one another.
Small companies | 1 - 5 years | 2 - 50 products They appreciated efficiency and simplicity since their products were fewer. The existing simple components were enough to support them. Middle companies | 6-9 years | 100 - 300 products They expected efficiency during dealing with growing product info, which made more info to distinguish products more and more important. Large companies | 10+ years | 500+ products They required strict and clear information structure to identify the right products since their products were generally complex, diverse, and numerous.
Therefore, in my discussion with all stakeholders, we agreed that this new component could support more complex scenarios for middle and potential large clients with mild tradeoff in friendly UX for small clients. After some tweaks of filter, it was approved to proceed.
Delivery
A whole new component that could lay out insurance product structure and display their massive information while balancing developer resources, friendly user experience, and insights from all consultants.
It was able to select a few dozens of products (2 – 50) with displaying massive info from clients’ integrated product database (300 – 500) and be reusable in other similar scenarios across company’s insurance core platform.
Outcome
The final design was well understood by all none-tech background consultants, stakeholders, and clients. The new component could well support selecting products from dozens to hundreds with detailed info displayed.
Reflection
UX Solution When designing a whole new component as business insights rapidly appear, maintain its scalability but don’t try covering all possibilities by the 80/20 rules. Design Process Having more frequent checkpoints with consultants to uncover key contexts and key flows earlier along with potential scenarios during research. Communication Clickable prototypes presented interaction better than flat wireframes, which helped all consultants get a better understanding and reduced confusion.
My value delivered
1. Finding the common denominator from the diverse opinions. 2. Balancing the pros and cons of all solutions.
You can also find me on 💁
- 👨🏻💻 Resume
- 🎨 Behance
- 📱 +61 493704787
- 📧 a870588@gmail.com