← WorkUX2020—2021

FNOL Portal — Claims UX

First notice of loss dashboard

A research-led modernization of First Notice of Loss, unifying claim intake across roles, lines of business, and county offices in one accessible, responsive platform.

The engagement combined contextual inquiry, service design, a BPM-guided workflow, a durable microservice boundary, and a reusable enterprise design system.

WCAG AAAccessible interaction foundation
4+Enterprise applications reused the system
92County offices supported
5+Intake tools unified

Project overview

Client
Regional Midwest P&C Insurer
Sector
Insurance technology
Scope
FNOL platform — design system + BPM-guided wizard + microservice rebuild
Role
Technical lead & UX architect
Team
6–15 cross-functional (eng, UX, claims SMEs, BPM, QA)
Dates
2020–2021 · Enterprise priority
By the numbers

The numbers behind the rebuild

  • 5+Intake tools unified
  • 3Lines of business unified
  • 92County offices on one workflow
  • 4+Programs inherited the design system
01 — Chapter One

Discovery

I mapped the real claims workflow before touching the interface.

The operating context

A coordinated intake experience across five tools, three lines of business, and 92 county offices.

In 2020, modernizing First Notice of Loss (FNOL) became an enterprise priority. FNOL is often someone’s first contact with their insurer after something goes wrong — clear guidance and dependable service matter here more than almost anywhere else in the relationship.

The existing workflow was stitched together from Exceed, Point, phone scripts, paper diary notes, mainframe lookups, and manual re-entry between systems. I built one shared intake experience that still respected the different needs of auto, home, and farm claims — treating this as much a service-design problem as a platform-engineering one, since it touches the habits, compliance rules, and working conditions of everyone in the claims chain.

  • ExceedEstablished claim-of-record platform
  • PointSpecialty-line workflow
  • Phone GuidanceClaim-type intake prompts
  • Diary NotesField and adjuster observations
  • Data TransferCross-system information flow
  • Mainframe LookupsPolicy-data access
  • Email AttachmentsPhoto and document exchange
  • Physical RecordsSupporting claim documentation

People and contexts

One platform, five different roles — each got the guidance and information density suited to their context, without breaking a single consistent interaction model.

  • Claim processor — High-volume specialists handling more than 30 claims each day, with a strong need for speed, keyboard efficiency, and clear status cues.
  • Field adjuster — On-site professionals working from tablets, supported by touch-friendly interactions and resilient field workflows.
  • County agent — Participants across 92 county offices, supported by guided flows and contextual help for occasional claim intake.
  • Policyholder — Infrequent users receiving timely, reassuring guidance through an unfamiliar and important process.
  • Claims manager — Operational leaders using real-time status visibility to coordinate open claims and team capacity.

Design considerations

  • audienceArchitecture, claims operations, and line-of-business specialists compared single-screen vs. guided-step designs across 5–6 revision cycles. Usability testing settled the direction.
  • technicalOld Exceed and Point notes fed a parallel data-quality effort, so reliable pre-fill was ready by the time the UX and platform work caught up.
  • regulatoryState-level claims-handling rules shaped the event logging and retention controls built into the service layer.
  • otherThe team built Spring Boot, React, and Angular Material skills through pairing, right inside the delivery sprints — not in a separate training track.
  • otherAdoption planning grew to include training, executive sponsorship, and feedback channels to help people move off decades-old claims habits.
The best design input wasn’t a requirements document — it was watching how the day-to-day claims work differed from what was written down.
02 — Chapter Two

The Approach

Five research methods, six revision cycles, one durable service boundary — connecting the research to what actually got built.

Research and delivery

A research-led process

Discovery came first: the workflow, the audience needs, and the service boundaries, before any interface decisions.

  1. Phase 01 · DiscoveryWeeks 1–6

    Contextual inquiry & claim-rep shadowing

  2. Phase 02 · SynthesisWeeks 4–8

    Journey mapping & service blueprinting

  3. Phase 03 · DiagnosticWeeks 6–10

    Heuristic evaluation of established systems

  4. Phase 04 · IterationMonths 3–7

    Prototype feedback sessions

  5. Phase 05 · ValidationMonths 6–8

    Usability testing with real users

Established tools → unified experience

Five tools, one shell

One coherent intake experience replaced five separate tools and practices.

0105
Tool 01

Exceed

The claim-of-record capability connected directly with intake through a dedicated service boundary.

Connected service of record
Tool 02

Point

Specialty-line workflows were brought into the shared interaction model for consistent cross-line intake.

Unified interaction model
Tool 03

Phone-call scripts on paper

Claim-type guidance was translated into a governed BPM workflow with contextual prompts.

Guided BPM workflow
Tool 04

Physical diary notebooks

Field observations moved into searchable, structured event history available across the claim team.

Structured event history
Tool 05

Manual re-entry

Common claim information moved across the workflow through explicit integrations and shared data contracts.

Automated data continuity

Design decisions

Long-form single-page intake vs BPM-guided step wizard?
Options: A single screen minimized clicks; a guided step-by-step flow matched how claim conversations actually happen.
Chosen: BPM-guided horizontal step wizard with conditional logic — claim-type-adaptive fields under a shared shell.
Usability testing showed guided steps with progress-save handled interruptions better, cut repeated questions, and reduced cognitive load on longer calls.
Extend Exceed with a modern UI layer vs build a standalone FNOL microservice?
Options: Extending Exceed was the faster path to ship; a standalone service was the more durable one.
Chosen: Standalone microservice on Java + Spring Boot, with React/Angular front end on cloud infrastructure.
A separate service matched Exceed’s own retirement roadmap, so FNOL could carry over in one migration instead of being rebuilt twice.
Wait for external hires vs upskill the existing team into the target stack?
Options: Hiring externally would have been faster to start; training the existing team built capability that stayed.
Chosen: Embedded upskilling: pairing + knowledge transfer inside sprint cadences.
Pairing gave the team direct ownership of the platform, its support model, and the stack, long after I moved on.
Durable foundations

Three foundations that sustained the platform

Three things outlasted the original delivery: the architecture, the design system, and the shared evidence base.

  1. A durable microservice boundary

    The clean service boundary aligned with the retirement roadmap and carried FNOL capability through the later platform transition with a single migration.

  2. Design system as a first-class deliverable

    Tokens, components, and accessibility patterns were adopted by four downstream programs, giving subsequent teams a tested interaction foundation.

  3. Shared usability evidence

    Usability data gave architecture, operations, and specialist teams a common decision framework that continued after launch.

Once everyone was looking at the same usability evidence, the direction stopped being a debate.
03 — Chapter Three

What Shipped

The program delivered a claims platform, reusable design system, durable service boundary, and an enabled product team.

What shipped

The platform shipped with a documented Angular Material design system built for enterprise claims work. Shared tokens covered primary, alert, success, warning, text, and surface roles, and eight core components handled the step wizard, smart form fields, document upload, progress-save, validation, claim summary, policy lookup, and the manager dashboard. Semantic HTML, ARIA patterns, responsive layout, and WCAG AA contrast were built into the foundation from day one — and other programs adopted the same system later.

Tokens · components · accessibility patterns — adopted as org-wide UI standard for subsequent digital programs

Outcomes

  • 5+Intake tools unified through one system of record
  • 3Lines of business on a single unified intake architecture
  • 5–6UX revision cycles before design lock
  • SingleFNOL migration through platform retirement
  • 40+Heuristic violations fixed in the new design
  • 4+Subsequent apps inherited the design system

There was no formal measurement baseline in place when this program started, so the outcomes below are the operational changes and platform adoption that actually happened, not a before/after metric.

The intake workflow pulled more than five tools into one coordinated platform. Structured capture, pre-fill, guided steps, and progress-save meant more claims got fully captured in a single session — across auto, home, and farm.

Digital document and photo upload attached supporting materials straight to the claim record. Structured event history covered audit and retention, and the real-time dashboard gave managers filters by claim type, status, date, and assigned adjuster.

The design system became the UI foundation other digital programs built on next. And because FNOL sat on its own service boundary, it carried through the later Exceed and Point retirement in a single migration instead of two.

This was the organization’s first shared design system. Every digital program that came after inherited its component library, accessibility standards, and interaction patterns — the value went well beyond the original claims platform.
Ashish Verma — Looking back on it
04 — Chapter Four

Principles

The practices that continue to guide complex workflow modernization and platform delivery.

Principles carried forward

Three things I’d repeat, three things I’d change earlier next time.

  • Carry forward

    Five research methods before the first wireframe

    Contextual inquiry, journey mapping, service blueprinting, heuristic review, and usability testing gave every later decision a shared evidence base and reduced downstream iteration.

  • Carry forward

    Treat the design system as product infrastructure

    Tokens, component documentation, and accessibility guidelines allowed design work to compound in value as subsequent programs adopted the same tested foundation.

  • Carry forward

    Use shared evidence to create alignment

    Making usability findings visible to architecture, claims operations, and specialist teams established a transparent decision framework for the program.

  • Refine next

    Establish baseline measures at kickoff

    Average intake time, callback rate, completion rate, and accuracy measures strengthen outcome reporting when they are defined as discovery deliverables.

  • Refine next

    Bring compliance into discovery

    A structured kickoff with legal and regulatory partners makes audit logging, retention, and jurisdictional requirements visible as early design inputs.

  • Refine next

    Treat adoption as a named workstream

    Training, sponsorship, transition support, and feedback channels belong in the product plan from the beginning when a platform changes daily operational practice.

The lasting value wasn’t the technology. It was removing manual reconciliation so people had a clearer way to actually help customers.

Want to build something together?

Emailashishvrm86@gmail.com
Based inIndianapolis, IN
Calendlycal.com/ashishvrm
Replywithin 24 hrs
Begin a project