BTG Pactual · São Paulo · 2020

Modular card insurance in a banking app

Customers of BTG+, the bank's app, could only buy card insurance as a fixed bundle at one price. I designed a modular version: the customer chooses a level of cover for card theft and misuse, and adds an assistance, a service such as pet care or home repairs. My usability test then showed that selling it during the card request put card sign-ups at risk, so the whole flow moved to the card's settings.

Card insurance in BTG+ was a fixed bundle at one price. I designed a modular version, and my usability test moved it out of the card request into the card's settings, to protect card sign-ups.

Role: Senior Product Designer.
Team: PM, tech lead, developers, and Too Seguros as insurer.
Context: BTG+, the bank's digital product. October 2020.
Contribution: survey · benchmark · user flows · prototyping · usability testing · flow strategy

01 — Context & my role

BTG Pactual, one of Latin America's largest investment banks, was expanding into retail banking. Card insurance was one of the new products.

I designed it end to end: I ran the customer survey and a benchmark of other insurers, designed the flows and the prototype, and ran the usability test that moved insurance out of the card request.

Note · BTG Pactual

Two and a half years at BTG Pactual: I joined as a consultant on BTG+ and left as Product Design Lead on the advisors platform.

Also the context for An advisors platform for four business verticals.

02 — The problem

Almost every customer surveyed already had card insurance, and most were unhappy with part of it. The survey also showed that they wanted to choose the parts themselves.

A survey of 30 BTG Pactual customers:

already have card insurance on at least one card

are unhappy with at least one assistance (a service such as home repairs) in their package

would like to modularise their package

Card insurance is usually sold as a fixed bundle, with no visible cost for each part. We wanted customers to build their package from modules: a level of cover plus assistances. Each module would show its limit and how it changes the price, and customers would follow a claim in the app.

Fixed bundle

One packageOne price

In a fixed bundle, the limits of each part are buried in the policy's clauses, so customers can't compare the parts or drop the ones they don't want.

Modules, priced at the point of choice

Module · limit stated+ R$

Not taken—

PremiumMoves as you choose

Fixed bundle against modules. A fixed bundle sells every part at one price. Modules let the customer see what each part covers and costs, and choose the ones they want.

03 — Constraints

Part of the product belonged to someone else: the insurer set its rules. These are the limits every screen was designed within.

Coverage, pricing and claim rules belonged to Too Seguros. Some claims had to finish outside the app.

Insurance terms are regulated and can't be reworded. So the product had to become clear through layout, by showing each limit next to the price where the customer decides.

Each plan (a level of cover) included one free assistance, so a single checkout had to mix a free product with paid ones.

Card conversion, the share of customers who finish requesting a card, was the retail business's key metric, and anything added to the card request put it at risk.

04 — Process & key decisions

The work had four stages: design principles, a benchmark of other insurers, the user flows, and the decisions that came out of testing.

Design principles

Agreed in a workshop with the PM, tech lead and developers. Later disagreements were settled by checking them against these three principles.

Buying insurance takes a few clear steps, and the customer is never shown a long list of products.

The customer gets coverage that fits their life, at a monthly price they are willing to pay.

Nothing is hidden in the clauses: each condition is explained on the screen where the customer makes the related choice.

Benchmark

I reviewed seven insurers for how customers buy, customise and claim. Three of them shaped the plan-and-assistance structure described below.

Hedvig Hedvig lowers the monthly price when a customer invites a friend, and the new price shows at once.

Wrisk Wrisk builds each policy from plain-language questions asked one at a time, so the cover fits the customer without a long form.

Shaped the structure

Pulse Pulse sells a base module with paid extensions, and the customer can share the cover with their household.

Lemonade Lemonade writes its contract in plain, friendly language, so the customer can read what they are buying.

Shaped the structure

DeadHappy DeadHappy underwrites through a short conversation that ends with the payout and the price stated plainly.

Cuvva Cuvva lets the customer raise cover item by item with sliders, and the price updates as they move.

Shaped the structure

Santander Santander has the customer choose their cover before buying, and the instalment updates as they choose.

User flows

The three flows: buying the insurance, making a claim and cancelling.

Contracting

HomeCredit cardThe card is active?

YesCredit card menuInsurance PageSelect the packageSelect the assistanceSuccess

NoRequest a credit cardActivate the cardInsurance offerrejoins “Select the package”

Claim

HomeCredit cardCredit card menuInsuranceClaimContact info · insured info and document needed

The customer finishes the claim by phone with Too Seguros, the insurer, so the flow shows clearly the point where the app hands over.

Cancel

HomeCredit cardCredit card menuInsuranceCancelReasonSuccess

Key decisions

The customer picks one of three plans, then chooses one assistance module, which is free. They don't build a package from scratch. They tailor the part that depends on their life, the assistance, and the level of cover is kept to three clear options. The structure drew on Cuvva (the price updates as coverage changes), Wrisk (a policy built one question at a time) and Lemonade (plain language).

Being able to cancel easily is part of being transparent. And the claim is when customers find out whether the insurance works for them, so it had to be designed as carefully as the sale.

I tested both entry points, inside the card request and in card settings, with 10 active customers. Inside the card request, insurance made an already crowded signup longer and mixed free and paid products in one checkout, which put card conversion at risk.

05 — The solution

The customer finds card insurance in their card settings. There they compare three plans with their limits side by side, open each assistance module to read its details. Before accepting the terms, they see a confirmation that restates the plan, the price and the dates.

Card home. A customer who already has the card reaches insurance from the card's settings, outside the card request.

Why: Keeping insurance out of the card request keeps that request short, so more customers finish it.

Card settings menu. “Seguro do cartão” (card insurance) sits with every other card setting.

Why: The customer buys, claims and cancels in the same place, so they always know where to find their insurance.

Plan comparison. When the customer chooses a plan, Simples, Pleno and Superior sit side by side, each with its limits stated.

Why: The customer sees what each plan covers next to its price before choosing, because the policy's wording can't be changed to make it clearer.

Assistance selection. The customer picks from five assistance modules (pet, repairs, home, emergency services, bike), with Too Seguros named below as the insurer.

Why: Here the customer fits the package to their own life, and knows before paying which company provides the insurance.

06 — Impact

The usability test produced two findings: where insurance should sit in the app, and how customers read price changes.

Flow placement

Selling insurance inside the card request put card conversion at risk, along with the two other problems listed after the diagrams. So buying insurance moved to card settings, offered as a pending task once the card is approved.

Considered · too risky for conversionInside the card request

01Request the card
02Benefits
03Invest+
04Virtual card
05Insurance plans + paid checkout
06Card conversion

Before: the card request carried five tasks in one journey, with the insurance plans and a paid checkout just before the customer submits the card request.

ChosenInsurance page in card settings

01Request the card
02Card conversion
03Pending taskCard insurance
04Card settings
05Seguro do cartãoContract · claim · cancel, one place

After: the customer finishes the card request first. Insurance has a permanent place in card settings, and paid plans are never sold in the same checkout as the free assistance.

Inside the card request, insurance put three things at risk:

Card conversion, the retail business's key metric
A checkout mixing the free assistance with paid plans
A journey already carrying benefits, Invest+ and the virtual card

Price display

Customers understood the three plans, but were slow to notice how the price changed between them. So a short animation went into the build: when the customer switches plan, the price and limits update in place.

Planos

Mensalidade

{{ planPrice }} por cartão

Coberturas

Switch plan in the figure to see the price and limits update.

07 — What I learned

Four lessons: two about the product, on placement and transparency, and two about the practice, on agreeing principles early and testing early.

The screens worked in both journeys. Placement was the decision, and only testing the full flow from both entry points showed it.

The wording of a clause can't be changed, so clarity has to come from what the customer reads before and beside the price.

Because the principles were written with engineering at the start, I could argue for moving the flow using principles everyone had already agreed to, such as keeping the process simple. I still start projects this way.

Ten sessions settled a conversion question that would otherwise have been argued from opinion, or found after launch.

08 — What this case doesn't cover

The case runs from the survey to handover for build. What came after that is not covered:

How many card customers bought the insurance, and how often they claimed or cancelled. I left before they were measurable.

Designed, but not shown. The handoff to Too Seguros mid-claim was never tested with customers.

Set by the insurer. Willingness to pay was surveyed, never tested against real prices; the Pleno and Superior prices in the figures are placeholders.

Thirty survey responses and ten moderated sessions: enough to settle placement, not to claim anything statistical. No accessibility review was run.

Next case study

Where AI lives in an institutional investment platform

AI platform