Context

Problem

Solution

Design Decisions

Final Deliverables

Outcome

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.

Zoomable image

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.

Outcome

Faster to fill. Harder to get wrong

Configuration time

↓ 40%

Incomplete submissions

↓ 67%

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.

Zoomable image

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.

Zoomable image

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.

Final deliverables

Documentation & Handoff

Figma handoff

system logic

System logic documentation

system logic

Decision tree

Outcome

Configuration that guides, not just accepts.

Configuration time

↓ 40%

Incomplete submissions

↓ 67%

Validated through an HTML prototype tested with 5 admins across 2 rounds.

In round 1, admins brought their old mental model to the new form: 3 out of 5 were flagged post-submission for missing required fields, averaging 3 fields each. By round 2, only 1 admin was flagged, with 1 missing field.

Configuration time also dropped from ~5 minutes to under 3: roughly 40% faster with admins reporting they could tell whether they'd done it right, something the old system never provided.