Diagnosing Drop-Off in a Credit Card Feature

Why research mattered

Experian launched Wallet Genius to help users get more from the credit cards they already carry. It shows the cards in a user's wallet and suggests cards that fit the way they spend.

A product manager shared concerning funnel data: of more than 25,000 users who clicked into Wallet Genius entry points, nearly 70% left before reaching the dashboard. The team had one hypothesis, that cards from a single issuer were being classified as a different card. It was a reasonable guess about data, but nobody had watched a user go through the flow. The abandonment was costing the team every day, and the open question was whether this was a data problem, a design problem, or a problem with the idea.

Research approach

I ran moderated usability testing on the live product, focused on first-time onboarding. A prototype can't show how actual data factors into a product experience, and I wanted users' first impressions in their own words.

• Participants. Five Experian users with very good or excellent credit, the only audience shown Wallet Genius, and three or more credit cards, since they were most likely to want a card-tracking tool. I recruited from Experian's user panel.
• Scope. Five users is a common balance of insight, time, and cost. The first few uncover most problems and later ones mostly repeat them. The tradeoff is that five users show what breaks, not how often.
• Task. Each session began with a scenario about finding a way to track existing credit cards and maximize rewards, then I watched for friction anywhere in the flow.
• Verification. With each participant's permission, development and engineering looked at their accounts to confirm whether the cards were wrong.

Key findings

1. The wrong cards were the problem, and they felt like a threat

As soon as users reached the card confirmation page, they saw that the cards listed weren't theirs, and some questioned the accuracy and value of the whole feature. For a few it went further: fear and panic, and a wish to check their credit reports or call their banks about possible fraud.

A wrong card isn't a small error on a financial product. For some users it suggested that something might be wrong with their identity or credit, and leaving felt like the safest response.

2. Users couldn't fix it, and the available actions provided little help

Users couldn't tell “Identify” and “Manage” apart. “Manage” suggested editing cards or exploring benefits but only offered removal, and a removed card sometimes appeared again.

3. Recommendations lost credibility

Because of the data problem, one participant was shown an optimized offer for a card they already had.

4. The idea appealed, but discovery and value were thin

Users looked for Wallet Genius under credit cards, credit information, and their credit reports. The actual entry point within their Experian profile felt hidden. They wanted clear rewards, earning potential, and guidance on which card to use. They generally liked the introductory content and setting a Wallet Goal, which points to real interest.

Influence and outcomes

Having evidence from real accounts meant there was no debate about whose problem it was, and the team could go straight to fixing it. I cut participant feedback into video clips for the readout with product and design stakeholders, so they could hear reactions firsthand, and posted a card-by-card table of inconsistencies for each participant with the broader team.

• What I delivered: video clips, the card-by-card table, and the full set of findings.
• What was implemented: engineering fixed the data problem, and the UX designer created new designs that gave users more editing control over the cards pulled into onboarding. The “Identify” and “Manage” labels were also corrected.
• What was measured: drop-off improved after testing was complete, but I don't know by how much.

Reflection

What I learned. When the cause is technical, evidence from real accounts is what moves a team. Asking engineers to look at participants' accounts turned a research finding into a confirmed bug.

What I'd do differently. I didn't have much of a relationship with the engineering team, so I never invited them to the readout and relied on the product manager to connect everyone afterward. Watching users react to wrong cards would have been powerful for the people fixing the problem. Next time, I'd build that relationship before the research begins and bring the engineers into the room for them to witness, as well.

What remained unresolved. The hidden entry point I reported had not been corrected.

Appendix: methods and supporting detail

The full method notes and the rest of the findings, for a deeper read.