Rupesh S. Ghadi
Back to work
Product · InsurTech (Employee Benefits)

My Policy Portal - Self-Serve Group Health Insurance

Making an employer's group medical cover something an employee can actually understand, manage, and claim on - without calling HR.

My Policy Portal hero - the sign-in screen and My Policy dashboard composed over an Aditya Birla Capital branded backdrop.
Role
UI/UX Designer (end-to-end)
Client
Group Health
Type
Product · InsurTech (Employee Benefits)
Platform
Web portal (desktop-first)
2
Audiences: employee + HR
11
Policy clauses decoded
4
Claim states made legible
3-party
HR · broker · TPA seams

TL;DR

Almost every salaried employee in India has a group medical cover - and almost none understand it. What's my sum insured? Are my parents covered? What's a "room rent limit"? How do I file a claim, and where is it stuck? The answers are buried in a policy document, mediated by three parties the employee never talks to - HR, the broker, and the TPA - and usually surfaced only in a panicked moment at a hospital counter. The problem: take a confusing, jargon-heavy, multi-party benefit and turn it into a portal a non-expert employee can self-serve - understand their cover, manage their family, top it up, and file and track claims - while also giving HR the tools to run enrolment for hundreds of people.

The core challenges

  • 01Comprehension over data-dump - a policy has dozens of clauses; the cover had to be decoded, not just displayed.
  • 02Two audiences, one platform - employee self-service and HR bulk administration are almost different products sharing one system.
  • 03Time-boxed, high-stakes decisions - enrolment and top-up happen in windows, involve real money and family, and can't be redone casually.
  • 04Family is complicated - coverage depends on a family definition with real rules (spouse, children, up to 2 parents, max 6, with swap rules).
  • 05The opaque claim - claims pass to a TPA and return Paid / Pending / Repudiated; the black box had to be made legible with a next action.
  • 06Trust and reassurance - health and money for someone's family; the tone had to be calm and confidence-building, especially in the un-pretty states.

Design solutions

A "My Policy" dashboard that states the essentials in plain language

The employee lands on a single card that answers the questions they actually have: who's covered (name, employer, dependents, e-card), what they've got (policy type, sum insured, balance, period), and who to call (broker and TPA, each with a direct contact link).

Below it, the benefit breaks into scannable groups - Coverages, Services, and a Claims summary (Intimated / Pending / Paid / Repudiated) with a prominent Intimate Claim action, plus a persistent Download Forms panel. The screen is engineered so an employee knows, in seconds, what they have and what to do next - not to make them read a policy.

Everything an employee needs to know, above the fold: who's covered, what they have, and who to call - with broker and TPA contacts sitting right in the summary card.
One employee can hold several covers - the switcher keeps them in one place instead of one portal each.
The detail record sits one click down, so the landing screen stays an answer rather than a document.

Coverages that decode the fine print - the comprehension centrepiece

This is where the portal earns its keep. Instead of a wall of policy text, Coverages presents the plan as a grid of plain-language tiles - Family Definition, Sum Insured, Pre-Existing Disease, Waiting Period, Room Rent Limits, Maternity, Co-payment, Disease-wise Limits - each expandable into a human explanation.

The Family Definition tile spells out the real rule (Employee + Spouse + Children/Siblings + 2 Parents/Parents-in-law, max 6, with swap rules). The principle: the employee shouldn't have to translate insurance jargon - the interface does it for them, turning the most confusing artifact into something browsable.

The fine print, re-cut as tiles. Every tile is a question an employee actually asks - not a clause number they'd have to look up.
Expanding a tile gives a human explanation. The translation is the product.
Network hospitals resolve to a searchable list, because "am I covered here?" is a location question.

Dependent management that encodes real family rules

Adding family is designed around the messy reality of who counts as a dependent. Add Member captures relationship and relation type with the fields insurers actually need, and the flow supports the full lifecycle - modify, mid-year additions, and corrections for when data is wrong or life changes.

Mid-year handling matters especially: a new baby or marriage can't wait for the annual window, so the portal treats that as a first-class path rather than an exception.

The family, as the policy sees it - with the max-6 rule and swap logic enforced by the list itself.
Add Member asks only what insurers genuinely need, in the order a person would answer it.
A new baby can't wait for the annual window - so mid-year addition is a designed path, not an exception.
Corrections assume the data will be wrong sometimes, which it is.

A claims module that makes the TPA black box legible

Claims are the highest-anxiety moment, so the design's job is transparency. The Claims screen leads with a status summary - Intimated / Pending / Paid / Repudiated, each with count and amount - then a claim-by-claim report showing Claim Amount vs Settled Amount and Status as per TPA, colour-coded.

The honest touch is surfacing Repudiated as a clear, legible state rather than hiding a rejection - the employee sees exactly where each claim stands as the TPA sees it, which is the whole point of removing the black box.

Status first, claim-by-claim second. Repudiated gets the same visual weight as Paid - hiding a rejection is what makes a black box.
Claim amount against settled amount, labelled as per the TPA - the employee sees what the TPA sees.
Each claim opens into its own history, so "pending" has a shape instead of being a dead end.
Intimate Claim stays reachable from the summary - the anxious moment shouldn't require navigation.

Top-up that turns "increase my cover" into a slider with live pricing

Raising your sum insured is normally a form-and-wait ordeal. Here it's a decision you can feel: a Top-up Premium modal offers tiers (Gold / Platinum), a slider across sum-insured ranges (₹6L → ₹25L) that shows the additional premium recalculating live, and an honest incentive (a co-payment waiver on the base premium).

Complexity - actuarial pricing - is computed by the system; the employee experiences a simple "drag to the cover you want, see what it costs."

Drag to the cover you want. The actuarial maths runs underneath; the employee just feels the trade-off.
Premium recalculates as the slider moves - the price is part of the decision, not a surprise after it.
A confirm step, because this one costs real money and can't be casually redone.

Enrolment as a guided, windowed lifecycle - for both audiences

Enrolment is time-boxed and consequential, so it's designed as an explicit journey. For the employee, Select Campaign frames the active window - base sum-insured, Enroll Now / Opt-out, top-up choice, terms - with reassurance built in.

For HR, Enrollment is a full member-lifecycle console: a stepper (Members → Assign → Confirmation → Mid-year Dependent → Corrections → Enrolled), bulk actions (templates, upload, add joiners), and per-member actions (Joiner / Leaver / Suspended / Reject) across a paginated population. Same platform, two very different jobs, each given a fit-for-purpose flow.

HR's console: a stepper across the member lifecycle, bulk upload, and per-member joiner/leaver actions over a whole population.
The same feature for the employee is a single decision - enroll or opt out - framed by the window it has to happen in.
Two audiences, one platform, two fit-for-purpose flows - this pair is the argument.

Flex benefits - a wallet that makes the "extra" tangible

Beyond core hospitalization, employees get flexible benefits, and the design makes that budget concrete: a Flexi Wallet Balance up top, and a catalogue of redeemable services (Health Checkup, Order Medicine, Doctor Consultation, Home Health Care, Dental).

Framing it as a wallet with a balance to spend turns an abstract "flex benefit" into something an employee actually uses before it lapses.

A balance up top turns an abstract entitlement into money you can feel yourself not spending - which is what gets it spent.
The catalogue reads like a shop, not a benefits schedule.

Reflection

  • The strongest design work was translation, not layout. Turning an insurer's policy into human-readable tiles is what makes this portal worth opening - I'd usability-test comprehension of the Coverages decode first; it's the load-bearing wall.
  • Two audiences deserved sharper separation - I'd make the role split louder, pushing role-aware navigation and entry points further so neither audience wades through the other's tools.
  • The un-pretty claim state was the right thing to design for. Showing Repudiated plainly, with a next action, is what builds trust in the whole system - I'd extend that honesty into real-time TPA status comms.
  • Deadlines needed to be felt, not just shown. Enrolment and mid-year windows are consequential, so I'd design stronger, kinder deadline and consequence cues so no one misses a window by accident.

Visuals are recreated / sanitised representations for portfolio use and contain no real client data. The portal is configured per corporate policy; any brand, broker, or TPA names shown are placeholder.

Want to see more?

More case studies are on the way - or reach out directly.

All workContact me
Hire Rupesh