Modular card insurance in a banking app
Customisable insurance and assistance for a credit card — contracting, claims and cancellation inside the bank's app, priced so customers could build a package they were willing to pay for.
Senior Product Designer, sole designer on the product.
PM, tech lead, developers, and Too Seguros as the insurance partner.
BTG+, the bank's digital product. October 2020.
survey · benchmark · user flows · prototyping · usability testing · flow strategy
Note — BTG Pactual
Two and a half years at BTG Pactual, joining as a consultant on BTG+ and leaving as Product Design Lead on the advisors platform. BTG+ is now one of the largest businesses in the group.
Context for this case and for An advisors platform for four business verticals, both from that period.
01 — Context & my role
BTG Pactual is one of Latin America's largest investment banks, and at the time it was expanding into retail banking — credit cards, accounts, and the products attached to them. Card insurance was one of those.
I was the designer on it end to end: the survey that framed the opportunity, the benchmark, the flows, the prototype, and the usability test that changed where the product lived.
02 — The problem
Almost everyone already had card insurance. Almost nobody was happy with it.
A survey of 30 BTG Pactual customers set the shape of the opportunity:
The category sells fixed bundles at a single price, with no way to tell what any part of it costs. The goal was the opposite: modules a customer picks for their own life, each with its coverage limit and its effect on the premium visible at the point of choice, plus a claim they can open and follow inside the app.
Coverage limits sit in the clauses. No part has a visible cost, so nothing can be compared or dropped.
03 — Constraints
A third-party insurer. Coverage, pricing and claim rules belonged to Too Seguros. Some steps — completing certain claims — had to leave the app by design.
Regulated language. Insurance terms can't be paraphrased freely. Transparency had to be achieved through structure and hierarchy, not rewriting the clauses.
Free and paid products in one checkout. One assistance came free with the plan, which made the purchase flow structurally awkward.
Card conversion is sacred. Anything added to the card request flow risked the metric the whole retail business was measured on.
04 — Process & key decisions
There was no method set out in advance. Looking back, the work moved through four stages: the principles we agreed on, the benchmark, the flows, and the decisions that came out of testing.
Three principles came out of a workshop with the PM, tech lead and developers. They resolved most of the later arguments on their own.
Seven insurers reviewed for contracting, customisation and claims. Three of them shaped the structure we chose.
Contracting, claim and cancellation mapped together before any screen was designed.
The user needs to finish the process calling for the Too Seguros.
Three plans, then one free assistance to choose
Rather than a fully open configurator, the customer picks one of three coverage plans and then chooses an assistance module — pet, home, repairs, emergency services, bike. Personalisation where it's meaningful; a decision with three options where it isn't. The benchmark shaped this: Cuvva's sliders, Wrisk's custom policies, Lemonade's contracting journey.
Modularity customers asked for, without the paralysis of pricing every component themselves.
True à-la-carte pricing. The 80% who wanted to modularise get structured choice, not a blank slate.
Design all three flows, not just the sale
Contracting, claim and cancellation were mapped together. Cancellation being easy to find is part of transparency, and the claim flow is where the product either earns trust or loses it.
A product that holds up after purchase, and clear boundaries for where the insurer takes over.
Scope. Claims and cancellation cost design and build time that the business would rather have spent on conversion.
Take the insurance out of card signup — because the test said so
We tested both entry points with 10 active bank customers: from the card request, and from the insurance page in card settings. The card request journey carried a risk of lowering card conversion, forced a checkout mixing free and paid products, and piled too many tasks into one flow alongside benefits, Invest+ and the virtual card.
Insurance became a pending task after card success, plus a permanent home in card settings — managed like any other card configuration.
The highest-intent moment in the funnel. We accepted lower attach at signup to protect card conversion.
05 — The solution
An insurance page inside card settings: three plans side by side with coverage limits stated in the comparison, assistance modules with their own detail sheets, a confirmation screen that restates plan, price, payment method, billing date and policy end before the terms, and a success state that offers to extend cover to the customer's other cards.
The card's main screen, where insurance is reachable from settings rather than from the request flow.
Why — the usability test showed the signup journey was already carrying too many tasks, and adding insurance there put card conversion at risk.
“Seguro do cartão” listed alongside every other card configuration.
Why — treating insurance as a card setting gives it a permanent home, so contracting, claiming and cancelling are all found in the same place.
Simples, Pleno and Superior side by side, with coverage limits stated in the comparison itself.
Why — three plans keep personalisation without the paralysis of pricing each component, and putting the limits next to the price is how transparency happens when the clauses can't be rewritten.
Five assistance modules to choose from — pet, repairs and installation, home, emergency services, bike — with Too Seguros named directly below as the insurer behind them.
Why — the module is where the package becomes the customer's own, and naming Too Seguros before the commitment keeps the free-plus-paid checkout honest.
06 — Impact
Ten active bank customers went through the prototype from both entry points. The test produced two findings.
Offering insurance inside the card request put three things at risk: card conversion, the metric the whole retail business was measured on; a checkout that mixed the free assistance with paid plans; and a journey already carrying benefits, Invest+ and the virtual card. Contracting moved to the insurance page in card settings, with a pending task after card success, before a line of it was built.
One journey carrying five tasks, ending in the metric the retail business was measured on.
Conversion completes first. Insurance keeps a permanent home, so the paid checkout never sits beside the free assistance.
Card conversion — the metric the whole retail business was measured on
A checkout mixing the free assistance with paid plans
A journey already carrying benefits, Invest+ and the virtual card
Customers understood the difference between the three plans, but not fast enough at the price line. A micro-interaction on the price and coverage values went into the build so the change registers in place, at the moment of comparison.
Switch plan to see it: the price and the three coverage limits stay in the same position and roll up in place, so the difference is read without leaving the comparison.
07 — What I learned
Test the entry point, not just the screens
The interface was fine in both journeys. The placement was the decision, and only testing the full flow from two starting points surfaced it.
In regulated products, transparency is a layout problem
You can't rewrite the clause, but you can decide what the customer reads before the price.
Principles agreed early are cheaper than arguments later
Writing them with engineering in the room, before the first screen, meant that when we proposed moving the whole flow the argument was already framed in terms everyone had agreed to. I still open projects this way, and it shortens the path to a decision.
A small test beats a long debate
Ten sessions on a prototype settled a question about conversion risk that would otherwise have been argued from opinion, or found after launch. Sizing research to the decision, not to the ideal, is what makes it fit a delivery timeline.
08 — What this case doesn't cover
The work here runs from the survey to the handover for build. Four things are deliberately outside it.
Post-launch numbers. Attach rate, claim volume and cancellation rate are not reported here. I left the bank before they were measurable, so any figure would be a guess.
The claim and cancellation screens. Both flows were mapped and designed, but only the contracting screens are shown. The claim in particular hands off to Too Seguros partway, and that seam was never tested with customers.
Pricing. Premiums and coverage limits were the insurer's to set. Willingness to pay was asked about in the survey, never tested against real prices, and the Pleno and Superior figures in the demo above are illustrative placeholders.
Research depth. Thirty survey responses and ten moderated sessions on a prototype. Enough to settle where the flow lives; not enough to claim anything statistical, and no accessibility review was run.