Redesigning an Insurance Admin System
Redesigning an Insurance Admin System
Redesigning an Insurance Admin System
Role
Product Designer
Team
Danny Huang, Fei, Shixin, Charles Copoloff
Tools
Cursor, Codex, Github
Timeline
2026 - Present
Context
A B2B insurance platform built without a designer
InsurFact was a B2B platform used by in-house insurance advisors to manage insurance products and sales leads.
I joined as the sole product designer to redesign the Admin configuration system — a system built by engineers, with no prior design involvement.
InsurFact was a B2B platform used by in-house insurance advisors to manage insurance products and sales leads.
I joined as the sole product designer to redesign the Admin configuration system — a system built by engineers, with no prior design involvement.
The system I inherited
Every insurance product type lived on the same flat form.
The Problem
Misconfiguration was invisible until it was too late
For Admins
There was no feedback mechanism. No way to know which fields were required, which were optional, or whether the configuration was even correct. Getting it right depended entirely on institutional knowledge.
There was no feedback mechanism. No way to know which fields were required, which were optional, or whether the configuration was even correct. Getting it right depended entirely on institutional knowledge.
For the business
Misconfigured products accumulated silently. Errors only surfaced when a claim exposed them, by then, the damage was already done.
Misconfigured products accumulated silently. Errors only surfaced when a claim exposed them, by then, the damage was already done.
Solution
From a flat list of forms to a structured, navigable system
Information architecture
The original system had no list view. Every product type was a fully expanded form, stacked one after another with no way to scan or manage. I restructured the page into a table with category tabs, search, and pagination
The original system had no list view. Every product type was a fully expanded form, stacked one after another with no way to scan or manage. I restructured the page into a table with category tabs, search, and pagination
Field grouping
Regrouped and relabeled every field based on product type and business logic. I discussed and validated with the product owner field by field.
Regrouped and relabeled every field based on product type and business logic. I discussed and validated with the product owner field by field.
Conditional visibility
Fields now appear or hide based on prior selections. Admins only see what's relevant to the product they're configuring.
Fields now appear or hide based on prior selections. Admins only see what's relevant to the product they're configuring.
States
Every possible state is accounted for — required, optional, disabled, error, and conditional. The form responds to input rather than accepting anything silently.
Every possible state is accounted for — required, optional, disabled, error, and conditional. The form responds to input rather than accepting anything silently.
Design Decision
Every decision had a reason
Each choice, from layout structure to interaction pattern, was grounded in business logic, user behavior, or technical constraint. Below are the decisions that shaped the design.
Each choice, from layout structure to interaction pattern, was grounded in business logic, user behavior, or technical constraint. Below are the decisions that shaped the design.
Drawer over modal for Add / Edit
The initial design used a modal for adding and editing product types.
The initial design used a modal for adding and editing product types.
The Problem
A modal blocks the entire list, forcing Admins to lose reference every time they open a form. And It doesn't aligns with the established design pattern across the product.
A modal blocks the entire list, forcing Admins to lose reference every time they open a form. And It doesn't aligns with the established design pattern across the product.
Solution
A side drawer keeps the list visible in the background. Admins can reference existing entries while filling out a new one.
A side drawer keeps the list visible in the background. Admins can reference existing entries while filling out a new one.
Type filters on top, not a single "All" view
The initial design had an "All" filter that displayed all product types together on a single page.
The initial design had an "All" filter that displayed all product types together on a single page.
The Problem
Mixing hundreds of types from different insurance categories made it difficult to manage products while certain product types are accessed far more frequently than others.
Mixing hundreds of types from different insurance categories made it difficult to manage products while certain product types are accessed far more frequently than others.
Solution
Tabs follow the same category structure Admins already use in their daily workflow. Outdated product types that were no longer in use were also removed.
Tabs follow the same category structure Admins already use in their daily workflow. Outdated product types that were no longer in use were also removed.
Understand before design: field grouping grounded in business logic
Instead of redesigning right away, I first understood how Admins actually work based on their configuration process, their terminology, and their mental model.
Instead of redesigning right away, I first understood how Admins actually work based on their configuration process, their terminology, and their mental model.
Why
All fields used internal shorthand. Grouping them without understanding the business context would produce a structure that made sense visually but not operationally.
All fields used internal shorthand. Grouping them without understanding the business context would produce a structure that made sense visually but not operationally.
How
Researched terms → walked through the process with the product owner → used AI to propose grouping → validated before finalizing.
Researched terms → walked through the process with the product owner → used AI to propose grouping → validated before finalizing.
