Carnival Assure launched as Bangladesh's first digital insurance aggregator — covering life, health, auto, and travel in one platform. The technology worked. The problem was that insurance as a category carries enormous cognitive weight: unfamiliar terminology, multi-step processes, documents users aren't sure they have, and a general anxiety that choosing the wrong thing will matter later. Users were starting policy purchases and abandoning them. Claims felt like navigating something adversarial. EMI payment options existed but almost nobody used them — not because they didn't want them, but because the experience of getting to them was opaque. The platform was technically capable of doing everything users needed. The design wasn't letting them get there.
Seven years on the same platform means you stop guessing about where users struggle and start knowing. I've led every major iteration since 2017 — which means I've seen what each redesign fixed and what it didn't. The consistent finding across all that time is that jargon and missing guidance were the primary abandonment drivers, not feature gaps. Users didn't need more options — they needed the options they already had explained in language that didn't require an insurance background to understand. Every design decision across the platform's evolution has been oriented around one question: does this make the next step obvious, or does it create a moment where the user has to figure something out on their own?
We reduced the policy purchase flow from twenty steps to a guided visual experience with comparison, customisation, and purchase in a single coherent journey. The twenty-step version wasn't twenty steps because anyone designed it that way — it had accumulated over time as features were added. Collapsing it required deciding what information was actually necessary at each stage versus what had been asked historically out of habit.
The claims process was rebuilt as three explicit steps with document requirements shown upfront rather than revealed progressively. The previous version surfaced document requests mid-process — which felt like the system moving the goalposts. Showing users exactly what they needed before they started reduced abandonment because people could prepare rather than being surprised. Transparent process design is different from simplified process design.
We built an EMI calculator that shows the monthly cost instantly before any commitment is made. EMI options had low adoption not because users didn't want them but because the calculation happened too late in the flow — after users had already made a mental commitment to a different payment structure. Moving the preview earlier changed the adoption behaviour significantly.
The design system was built around insurance categories rather than generic UI patterns — colour-coded by product type, with components that could accommodate new insurance products without starting from scratch. A platform that launched with four product types in 2017 now handles significantly more. The system scaling without redesign is a direct result of that early architectural decision.
increase in EMI adoption after the calculator was surfaced earlier in the purchase flow
EMI adoption grew over 40% following the redesign of when and how the payment preview appeared in the purchase journey. Claim abandonment dropped significantly after the three-step rebuild with upfront document requirements — users who knew what they needed before starting were far more likely to complete the process. Comparison pages became the highest-engagement feature on the platform post-redesign, which validated the hypothesis that users wanted to make informed choices, not be guided to a pre-selected option. The platform has continuously absorbed new insurance products since 2017 without requiring structural redesign — the component system has scaled with the business rather than against it.
Seven years is a long time to be the design lead on one product. The advantage is deep context — I know exactly why every decision was made and what it replaced. The risk is that familiarity becomes a bias. There have been moments where I've defended existing patterns longer than I should have because I understood the reasoning behind them. I'd build in more structured external review at each major iteration — someone who doesn't carry the history is sometimes the most useful person in the room.