Human-in-the-Loop AI Insurtech UX Transformation

Designing trust between AI that suggests and a human who judges

A ground-up redesign of Digit Insurance's motor claims assessor workflow — replacing fragmented, tab-heavy screens with a Human-in-the-Loop AI experience that made assessors faster without taking away their judgment.

Impact
8 → 11
Claims per assessor per day
Platform
Digit Insurance
Motor Claims
My role
UX/UI Lead
End-to-end design
5 min scan · 16 min read
Human-in-the-Loop AI illustration — assessor and AI working together on motor claims
Scroll to explore
↓
01

Context

1.1
Business Context

A market leader in insurtech — with a legacy claims floor

Digit Insurance is one of India's largest general insurers. Motor is its flagship line — and the team chosen to pilot the company's first end‑to‑end AI workflow.

Policies sold
1L+/mo
Motor is Digit's top-selling product across agency and retail channels.
Claims received
40k+/mo
Up from ~25k in 2023 — a 76% volume rise against a flat operational budget.
Assessors
300+
Processing claims daily — any change had to work for all of them, live.
1.2
User Context

The assessor: speed vs. accuracy under pressure

Before redesigning the workflow, I needed to understand who carries it — their goals, incentives, and the invisible pressure that shapes every decision they make.

Claims Assessor
End-to-end claim processing specialist
"Most of my time goes in chasing information, instead of taking decisions"
Who are assessors?
Employees who handle claim processing end-to-end — from FNOL (First Notice of Loss) to VRO (Vehicle Release Order). They manage every aspect of the claims lifecycle with precision and efficiency.
Primary goals
1
Process claims accurately, fast
Speed and quality both feed into their rank and reputation — they can't trade one for the other.
2
Minimise cost of settlement
Their judgement directly impacts Digit's loss ratio — good assessors are measured on this.
What drives them
Daily pressure
The queue never stops — unprocessed claims carry over, and assessors cover for colleagues on leave
Performance rank
Assessors are ranked against peers — rank is visible to managers
Incentive beyond target
Every claim processed above the monthly target earns a bonus
Design insight
Assessors were paid for their judgement — but were spending most of their day on data-fetching and pattern-matching. The system asked them to be the system.

From claim verification to cost assessment

Every claim follows this sequence. Understanding each step — and the friction within it — was the foundation for every design decision that followed.

Motor Claims: Assessor Journey storyboard showing 11 steps from claim verification to repair cost assessment

Step-wise goals and evaluation parameters

Each step in the claim process has distinct goals and performance criteria — these became the design requirements for every screen.

Step
Goal
Performance Parameters
Current Way of Operation
Validation Check
Step 2
Validity check of filed claim
Time Accuracy Early escalation
Information cross-checking and manual filling by assessors on Digit Care (internal portal)
Verification Call
Step 3
Details confirmation from customer
Time Detail-oriented Accuracy Authenticity
Detail filling while on a mandatory call between assessor and customer
Survey
Step 4
Survey of damages
Time Accuracy Detailing Info mapping
Virtual survey via video call with garage / self-inspection by customer / physical survey for critical cases
Assessment
Step 5
Cost assessment of damages
Cost-effectiveness Cost optimisation
On call / video between the garage and the assessor
1.3
New Capabilities

New capabilities, understood before designed.

Understanding what these capabilities could — and couldn't — do was what allowed the design to work with the system, not around it. What the technology made possible shaped how the interface represented it to the people using it every day.

AI agents
Accident recreation
Generates targeted follow-up questions as the customer narrates the accident on call
Smart fraud alerts
Cross-maps data points from FNOL to survey; surfaces anomalies in real time
NLP + LLM parts mapping
Transcribes the survey call and maps discussed parts to ABS with repair costs
System integrations
Vahan + policy match
Backend cross-check with OCR; exact character mismatches surfaced in the UI
Auto-fill on call
Pre-populates known fields so assessors handle only the mismatches manually
Vehicle parts rate card
Enabled access to parts listing as per vehicle model, along with new part cost in case of replacement
Constraints we designed around

NLP picks up background noise, affecting transcription quality  ·  OCR misreads and incorrect parts tagging meant fallback mechanisms were essential at each step

02

Design Process

2.1
Understanding Constraints

Understanding constraints to arrive at a shared vision

Every project has boundaries. Mapping them early — across business, technology, and user — was what made the design decisions defensible, not just desirable.

Business

Process immovable

Claim steps from FNOL to settlement couldn't be altered

Productivity target

35% improvement within 6 months of deployment

Bi-weekly cadence

Measurable UI progress expected at every update cycle

Deconstructing legacy flows

Broken existing flows mapped from scratch at atom level

Technology

Agent accuracy limits

Designed for 100% accuracy agents; reality required iterating around gaps

Legacy architecture overhaul

Old platform needed significant API changes to accommodate the new system

Phased deployment

Changes deployed in phases without breaking the platform for 300+ daily users

User

Entrenched mental models

Assessors were accustomed to old flows and couldn't articulate the problems within them

Resistance to change

Unlearning old patterns while maintaining daily targets created real cognitive pressure

Low trust in AI

Fear of replacement and lack of familiarity with new capabilities created adoption friction

Business Technology User Elevated UX
2.2
Research & Findings

What we observed shaped what we built

Research surfaced where the workflow broke down. These findings — mapped against usability friction and framed as design questions — became the foundation for every solution that followed.

Method

Stakeholder interviews + alignment workshops

Aligned on business goals, technical constraints, and what the AI could realistically deliver within the project timeline

Method

User shadowing + recorded OB call review

Observed assessors processing live claims; listened to customer verification calls to understand what got captured, what got missed, and how accidents were described naturally

Claim step — findings, friction and design questions

Each step mapped against what assessors struggled with and the design question it surfaced.

Claim step Research findings UX friction How might we
Validation Check
  • —3 separate tabs — Policy, Vahan, FNOL — no unified view
  • —26 flat, equally-weighted checks with no grouping
  • —No mismatch overview; results scattered across screens
 Fragmented IA
High scan load
Recognition over recall
  • —Assist the assessor to spend time only on actions, not on reading and filling information?
  • —Cut down manual information filling without losing accuracy?
  • —Convert big verification actions into bite-sized decisions?
Verification Call
  • —Manual data entry while simultaneously listening on call
  • —Cross-checking with existing details happened after the call
  • —Generic questions for all accident types — inaccurate info collection
 System & real world mismatch
Divided attention
Inaccurate data collection
  • —Free up the assessor's focus so they can verify details and ask the right questions?
  • —Match the speed of the customer speaking to the assessor responding?
  • —Add structure to accident recreation without restricting natural conversation flow?
Accident Recreation
within Verification Call
  • —Generic questions for all accident types — same flow regardless of event
  • —Questions not in correct hierarchy; interlinked questions spread across multiple pages
  • —No time or space for assessor to analyse details and ask follow-up questions
 System & real world mismatch
Inaccurate data collection
Recognition over recall
  • —Create the closest, most holistic picture of the accident for the assessor to analyse authenticity?
  • —Assist the assessor in asking directed follow-up questions based on the type of accident?
  • —Add structure to accident recreation without restricting the natural flow of conversation?
Survey
  • —Started without cause-of-loss context; no claim handoff visibility
  • —Poor image documentation — restricted pose order, no quality check, no retake, no notes or highlights on captures
 Visibility of system status
Error prevention
User control & freedom
  • —Connect the survey to important insights captured in previous steps?
  • —Shift assessor focus from capturing photos correctly to analysing if damages match the cause of loss?
  • —Provide a live flagging system while the survey is happening?
Assessment
  • —Survey and cost discussion happen together at workshop — system treated them as sequential
  • —Parts looked up and added manually from ABS
  • —No single overview — cost, damage, and fraud decision spread across screens
 System & real world mismatch
Cognitive overload
High manual effort
  • —Capture the conversation between workshop and assessor and convert it into usable data?
  • —Use ABS information to decrease the time spent creating the repair order?
  • —Place AI-led actions where the assessor retains the power to accept or reject them?

From findings to frameworks

Affinity mapping — Validation checks

Why it was made — 26 checks existed as a flat ungrouped list. Mapping them by what they were actually checking revealed a natural grouping: Policy, Vehicle, and Loss.

What it informed — The grouped structure became the IA logic for the redesigned validation check view.

Design Question
26 checks with no hierarchy — how do we group them so an assessor can scan, not search?
Policy 14 checks
Insurable Interest
Policy Coverage Period
Close Proximity
64VB Status
Policy Break-in
NCB & Previous Claims
Add-ons & Special Coverages
Policy Deductibles
+ 6 more
Vehicle 7 checks
Registration Number
Chassis Number
Engine Number
Vehicle Model & Variant
Vehicle Fitness Status
Vehicle Permit Status
RC Details
Loss 5 checks
Driver Details
Delay in Intimation
Third Party Losses
Police Intimation Status
Vehicle Status at Accident
Decision unlocked → became the 3 accordion sections in the final screen. Policy / Vehicle / Loss grouping directly maps to the UI structure.

Accident scenario IA — Verification Call

Why it was made — Customers describe accidents in their own natural flow. We needed to map every possible scenario exhaustively so the assessor could follow along quietly and only ask follow-up questions for the gaps — without interrupting the conversation.

What it informed — The full scenario tree defined the scope of what the interface needed to capture before a single screen was designed.

Accident scenario IA — Verification Call

AI agents mapping — Damage Survey + Cost Assessment

Why it was made — To understand exactly where each AI agent operated in the flow, what it handed off to the assessor, and where human judgement remained non-negotiable.

What it informed — Defined which actions were automated and which required explicit assessor input in the redesign.

AI agents mapping — Damage Survey + Cost Assessment
2.3
The Redesigned Experience

Decisions on screen

Each claim step redesigned from the ground up. Final annotated screens show the outcome; iterations and previous screens show the journey to get there.

Validation Check

Finding → Design

Assessors were spending more time reading and cross-checking than deciding — so the redesign moved all information retrieval to the backend and surfaced only what needed action.

Design solutions

Mismatches-only view — matched details collapsed by default, surfaced on intent
Checks grouped into Policy / Vehicle / Loss — replacing 3-tab switching
OCR-surfaced exact character mismatches with possible actions alongside each one
Visual hierarchy fixed using colour to distinguish mismatch severity and action taken

Final design

Validation Check — final design
Final Design

Screen annotations

1Claim identifiers strip — only the details needed to confirm the assessor is on the right claim. No full policy details, just the essentials.
2Category-wise mismatch overview — a quick-glance callout showing mismatches grouped by Policy, Vehicle and Loss. Built for speed, not depth.
3Total mismatch count across all categories — helps assessors gauge severity at a glance before diving into details.
4Mismatch detail rows — each listing the sub-category, policy data, Vahan data and possible actions. Collapsed by default, opened on intent.
5Collapsed matched category — if all checks pass in a category, it collapses entirely. Assessor only sees what needs attention.
6Four-column mismatch container — each mismatch row shows the sub-category, policy data, Vahan data and available actions in a consistent column structure for fast scanning.

Iterations

Iteration 2 Iteration 2
Iteration 1 Iteration 1

Previous screens

Previous 1 Previous 1
Previous 2 Previous 2

Verification Call

Finding → Design

The assessor's attention was split between listening and typing — removing real-time data entry was the single most impactful change to this step.

Design solutions

Fields auto-filled from policy + FNOL; assessor confirms or corrects only mismatches
All questions unified on one screen — saving click time between questions

Final design

Verification Call — final design
Final Design

Screen annotations

1Claim details strip — available in both collapsed and expanded states so the assessor can reference key details without losing focus on the call.
2Progress indicator — mirrors the same sub-categories checked in validation, showing live system status as the assessor moves through the call.
3Sub-detail block — three columns: data as per policy, data as per Vahan, and an auto-fill entry field that populates when the assessor selects a source of truth.
4Additional details block — supplementary claim information available on demand without leaving the call screen, reducing the need to switch tabs mid-conversation.

Iterations

Iteration 2 Iteration 2
Iteration 1 Iteration 1

Previous screens

Previous 1 Previous 1
Previous 2 Previous 2
Previous 3 Previous 3

Accident Recreation

A sub-flow within the Verification Call — how the assessor captures the accident narrative from the customer.

Finding → Design

Generic questions produced generic answers — structuring accident recreation around event type gave assessors a focused, directed way to build the fullest picture of the accident.

Design solutions

Chip-based accident recreation driven by IA logic tree — no typing during call
LLM surfaces follow-up prompts based on chips selected
All accident details grouped together — one focused view for the assessor to analyse authenticity

Final design

Accident Recreation — final design
Final Design

Screen annotations

1First chip — prompts the vehicle state at the time of the accident. The starting point of the scenario tree.
2Selected chips — each selection adds to a growing scenario. All chips combine at the end to generate a complete accident narrative.
3Default chips — remain visible throughout the interaction to capture any details the customer mentions later in the conversation.
4Dynamic chips — generated contextually based on earlier selections, narrowing the scenario as the assessor progresses.
5Generate CTA — appears only once enough chips are selected to reconstruct the scenario, preventing premature generation and keeping the assessor in control of the output.

Iterations

Iteration 3 Iteration 3
Iteration 2 Iteration 2
Iteration 1 Iteration 1

Previous screens

Previous 1 Previous 1
Previous 2 Previous 2
Previous 3 Previous 3
Previous 4 Previous 4

Survey

Finding → Design

The survey was being done blind — assessors had no context from earlier steps. Surfacing that context before the survey began shifted their focus from documentation to analysis.

Design solutions

Cause of loss, fraud flags, add-ons, and assessor rank surface before survey starts
Real-time fraud alerts surfacing during survey call
Comprehensive camera and documentation features — save/discard, retake, notes, image highlights

Final design

Damage Survey — final design
Final Design

Screen annotations

1Step navigation entry point — allows the assessor to jump to any step in the claim process, connecting completed steps to the current one.
2Assessor rank — works as a motivator and a constant reminder of primary KPIs throughout the workflow.
3Workshop severity indicator — reflects the workshop's performance based on previous claims data, surfaced before the assessor begins.
4Smart alerts — AI-led flags raised after the system processes data from previous steps. Surfaces anomalies before the survey begins.
5Vehicle pose thumbnail strip — mandatory poses shown with thumbnails and acronyms for quick recognition. Flexible upload order; low-quality images trigger a retake state automatically.
6Hero damage view — the damaged vehicle takes up 80% of the screen, giving the assessor enough visual detail to map damage accurately.
7AI-led parts mapping — surfaces parts and suggested fix types drawn from the assessor-workshop conversation. Assessor accepts or rejects each item independently.
8Conversation transcription — a live transcript of the Verification Call that assessors can reference during survey, reducing recall errors and eliminating the need to replay recordings.

Iterations

Iteration 2 Iteration 2
Iteration 1 Iteration 1
Iteration 3 Iteration 3

Previous screens

Previous 1 Previous 1
Previous 2 Previous 2
Previous 3 Previous 3

Assessment

Finding → Design

The workshop conversation and cost assessment were always one step — the system just hadn't caught up. Reuniting them in a single view eliminated most of the manual work.

Design solutions

Parts discussed in survey transcript surfaced and mapped to ABS list automatically
Rate card costs pre-filled per part; job type selectable per item
Not-allowed parts flagged automatically with restore option
Single unified summary — cost, severity, and fraud decision in one view

Final design

Cost Assessment — final design
Final Design

Screen annotations

1Vehicle pose thumbnails — persist from the survey step so the assessor can reference damage photos while finalising the repair order.
2LLM-generated parts summary — includes parent-child part mapping, type of fix, part cost and fix cost. Each item is editable.
3Auto-saved versions — timestamped history of summary drafts. Assessors can refer to previous versions if negotiation revisits earlier figures.
4Finalise or delete per item — a fallback for incorrectly fetched parts, giving the assessor control over every line item.
5Manual add option — allows the assessor to add any parts the LLM missed or couldn't extract from the conversation.
6Assessment cost breakdown — generated after parts are finalised. Accounts for policy benefits, consumables, discounts and applicable deductions.
7Assessor's review — a final confirmation step before the assessment is submitted, giving the assessor explicit ownership of the AI-generated output.

Iterations

Iteration 2 Iteration 2
Iteration 1 Iteration 1

Previous screens

Previous 1 Previous 1
Previous 2 Previous 2
2.4
Impact

The numbers that moved

Primary outcome
8 → 11
Claims processed per assessor per day — a ~38% productivity gain unlocking ~2.7 lakh extra claims annually.
Design levers
Decision-assistance UI IA restructure Context-surfacing AI-chip interface
Accuracy
95%
First-attempt accuracy on AI-driven accident recreation via progressive chip interface.
Cognitive load
~67% drop
Validation Check collapsed from 3 screens to 1 overview via decision-assistance interface.
Recognition over recall
25 → 100%
Context-surfacing survey UI with real-time alerts and in-step guidance for assessors.
03

Learnings

What designing for AI-assisted workflows taught me

01

Designing with AI requires trust design first

The biggest adoption barrier wasn't the interface — it was the assessor's trust in what the AI surfaced. Every AI-led feature needed a fallback that kept the assessor in control, or it simply wouldn't be used. Building that fallback wasn't an edge case — it was the core design problem.

02

What the system can't do shapes the design as much as what users need

OCR misreads and incomplete parts tagging forced design decisions no usability test would have surfaced. The most impactful design work happened when I worked backwards from system limitations, not forward from ideal flows. Constraints buried in the data pipeline shaped the final design as much as anything a user said.

03

Structure imposed on a conversation breaks the conversation

The accident recreation step taught me that forcing structure on a natural conversation creates friction. Designing for the conversation first — and letting structure emerge from it — produced a more accurate and more trusted output. The best input mechanism is the one that doesn't feel like one.

04

Recognition

The work recognised publicly

Express Computer The Rise of Real-Time Insurance: Inside Digit's Seven-Minute Claims Revolution ↗ ScanX / Earnings Go Digit Insurance Reports Significant Improvements in Claims Processing ↗ Go Digit — Transparency Report Transparency Report 13 — Digit Insurance ↗ Economic Times CIO How Technology Helps Digit Simplify Insurance for Its Customers ↗ LinkedIn Pulse How Digit Insurance's AI-Powered Insurtech Is Shaping Indian Insurance ↗
Next case study
02
Reimagining Insurance Verification

A conversational AI agent that replaces human executives on regulated verification calls — multilingual, multimodal, and built trust-first for the Indian market.

Read case study