SK

Loading Sudhanshu Kadu's portfolio
Skip to content
All work

Insurance is a promise. The screen has to keep it.

Rebuilding how Shriram Life Insurance customers pay their premiums and prove who they are, plus the design system underneath both.

Role
Product Designer
Client
Schbang, for Shriram Life Insurance
Timeline
March to June 2026
Platform
Responsive web, mobile first

01Problem

The traffic was never the problem

Shriram Life Insurance gets over 450,000 visits a month, and 86 out of every 100 are on a phone. Getting people to the site was never the issue.

Quick Pay is how existing customers pay their premium. More people used it every month than went through the entire buy a new policy journey. And it lost the most people on its very first screen, a form asking for a policy number and date of birth.

450,000+
visits a month
86 / 100
on mobile
83%
of Google traffic from blogs

When that many people leave on the first screen, it is not a problem spread across the journey. It is one field.

02Confirming the problem

They were not confused. They did not have the number.

This did not start with someone asking for a redesign. Schbang's own CRO team had been working the funnel data next to us, so the brief came from what people actually did.

My read of the biggest leak was simple. The people leaving at the policy number field were not confused. They just did not have the number with them.

A policy number sits in a document in a drawer. A mobile number sits in the pocket of the person trying to pay.

That also explained the losses further down, at identity checks and at payment, where nothing was mechanically broken. People were not only struggling. They were hesitating. You cannot inspect insurance before you buy it, so the screen is the only proof a customer has that the promise is real.

Two designers worked the account. I owned the design system, Quick Pay, the KYC and Bank Update flows, the blog template and eight calculators.

03Process and iteration

Three buttons that all meant proceed

The old payment flow was three screens with three separate buttons that all meant proceed, plus a browser popup that jumped in halfway if the user said yes to WhatsApp. Three chances to change your mind, one interruption, and a wide table built for a desktop most users did not have.

I argued with the client to cut steps out of that flow, because every extra step is a place where someone can leave. The drop off data made the argument, not my opinion. They agreed and the flow was shortened.

Before any of the flows, I built the design system, because four months of payment, verification, blog and calculator work is only possible on a base and there was none.

Design system: tokens, layers and the text scale, through the file

04The design

Four decisions, and the paths that fail

Take out the blocking field. Mobile number and OTP became the main way in. Policy number stayed as a second option for people who have it.

This goes straight at the biggest leak. I could have polished everything else on that page and the blocker would still be sitting there.

Quick Pay's mobile login: a mobile number field and Get OTP
Mobile
The same login at desktop width
Desktop

One decision, not three. The number of screens actually went up, so the honest claim is not fewer steps. Three proceed buttons became one, at the end, with the amount written on it. The popup is gone.

Steps are cheap when each one does a single clear thing. Decisions are expensive. Every extra proceed button is another chance to change your mind about a payment you had already decided to make.

Make the money easy to read. Each installment opens up, is tagged Overdue, Due or Upcoming, and shows the premium, the late fee with GST and the final amount separately. A late fee is the most common reason an amount surprises someone, and hiding it inside a total is how a payment turns into a support call.

The policy summary with each installment tagged Overdue, Due or Upcoming
Policy summary
An installment opened up, showing the premium, the late fee with GST and the final amount on separate lines
The breakdown

The rider step. Nobody asked for this. I suggested it, because riders bring in real money and the payment screen is the one moment a customer is already thinking about their cover. I placed it after the details are confirmed, before the final button, with the cost written plainly and a Skip that is always there.

A cross sell that puts the payment at risk is a bad trade. Put it late and make it skippable and it costs nothing.

The rider step: each rider with its cost written out, and a Skip control
The rider step, priced plainly and always skippable

Design the paths that fail

KYC is three steps when it works. The real work is what happens when it does not.

What failedWhat the user gets
OTP expired or wrongA clear message and Retry Verification
Too many attemptsA cool down message, and no retry button that would not work
Name does not matchDocument upload, Aadhaar front and back, each tracked on its own, ending in Under Review

An expired OTP, a locked account and a name mismatch are three different problems. Putting them behind one something went wrong screen is the most common mistake in flows like this, because what the user should do next is different every time.

The Aadhaar OTP, the attempt limit and the two day review are rules from the regulator. I could not remove any of them, so the job was making fixed rules feel clear instead of random. Say what to keep ready before starting. Show attempts left instead of hiding them. Give the waiting state an honest timeline.

The OTP step with the code expired: the timer at 00:00, Click to Resend offered, and 0 of 2 attempts left stated under the disabled Verify button
OTP expired
The attempt limit: a message saying the maximum OTP attempts have been reached and to try again later, with Back to Dashboard and no retry button
Attempts used up

05Scale

Built once, used twice

The design system is what made the volume possible. Five layers, tokens through templates, with every shade built from Shriram's own logo colour rather than a ready made palette, because they guard their identity closely.

Built once, used twice. KYC and Bank Update have the same shape, so I designed the branching as one pattern for both instead of two separate ones.

The same base carried the blog template, the page type that receives 83% of the site's Google traffic. The old one was plain text with a single call back form. The new one leads with trust, who wrote it and who checked it, then replaces that one form with asks that grow as you read. A calculator early, which costs nothing and shows who is serious. A plan card with Buy Now near the end, once someone has actually read the article.

The new blog page, top to bottom

06Outcome

Where each stream stands

StreamWhere it stands
Blog template and eight calculatorsLive, and now the conversion page for most of the site's Google traffic
Design systemIn use, and the single source of truth for designers and developers
Quick Pay, KYC and Bank UpdateIn development when the project ended

The numbers above are what our analysts measured before the redesign, not after. The one I would check first is how many people still leave on the first Quick Pay screen, because that is the single number this work was built to move.

07Conclusion

I found the limit mid delivery, not at the start

The front end skill on the team shaped the work more than I wanted. They needed flat image exports instead of reading colour values from Figma, and struggled with harder layouts, so I simplified to keep delivery on track.

The useful version of that lesson is not that I wanted a better team. It is that I found that limit in the middle of delivery instead of at the start.

Next time I check it in week one. What can the team build, how do they read designs, what does handoff actually mean to them. Then I design against that limit on purpose instead of discovering it screen by screen.

What I would carry forward

  1. Find the field that blocks people, not the page that looks bad

    The biggest drop off had one cause. Polishing around it would have changed nothing.

  2. Count decisions, not screens

    Shorter is not better. Fewer chances to change your mind is.

  3. The failure screens are the product

    Most people who hit one are ordinary users with an unusual name or an expired code. They deserve a path, not an apology.

Making something interesting or weird?

Let’s connect