Product Designer
Fintech
2023
Onboarding: from 30% to 75%+ completion
A Brazilian fintech served people with limited access to financial services. Seven in ten did not complete registration, and 86% of issued cards remained inactive. I led the onboarding redesign, negotiating simplification with engineering and business teams within a tight launch timeline.
Product Design · Onboarding · UX Research · Fintech
Product Designer
Fintech
2023
Onboarding: from 30% to 75%+ completion
A Brazilian fintech served people with limited access to financial services. Seven in ten did not complete registration, and 86% of issued cards remained inactive. I led the onboarding redesign, negotiating simplification with engineering and business teams within a tight launch timeline.
Product Design · Onboarding · UX Research · Fintech
Product Designer
Fintech
2023
Onboarding: from 30% to 75%+ completion
A Brazilian fintech served people with limited access to financial services. Seven in ten did not complete registration, and 86% of issued cards remained inactive. I led the onboarding redesign, negotiating simplification with engineering and business teams within a tight launch timeline.
Product Design · Onboarding · UX Research · Fintech
Context and problem
The product served customers in socioeconomic classes C and D, with unstable connectivity, shared devices, and varying levels of digital familiarity. Registration followed the data collection and validation sequence required by the backend, spread across 15 screens. There was no clear progress indicator, contextual guidance, or option to save and resume later.
Token-based authentication appeared at the start and depended on an unreliable delivery system. Error messages appeared after form submission, without identifying the field or explaining how to recover. Fees and plans only became clear after registration, generating complaints. The onboarding flow was also visually disconnected from the product’s rebranding.
Card issuance was triggered when account creation began, before registration was complete. With 86% remaining inactive, the problem extended beyond the interface and affected operating costs.
Evidence
I analyzed app store reviews, support ticket categories, and comments from internal NPS feedback. Three patterns recurred: authentication failures, limited visibility into account status, and unexpected fees.
Benchmarking six fintechs serving socioeconomic classes C and D identified progress indicators, contextual help, and resume features that the product did not yet offer. I used these findings to discuss priorities with the team, without treating complaints as a precise measure of the backend failure rate.
Constraints and trade-offs
The launch deadline, staged backend validation, and ongoing rebranding limited the solution space. I built an impact and effort matrix and facilitated its use to make choices visible across design, engineering, and business teams.
Reducing the number of screens was a feasible, high-impact intervention. Save and resume, inline help, and contextual tooltips went into the backlog with a documented rationale. The final scope decision was shared.
Decisions and solution
1. Consolidate related fields
Personal details were spread across ten screens, with redundant confirmations. Engineering needed to preserve validation steps. We agreed on seven screens for the full flow at launch and six after post-launch validation, with no observed increase in data errors. The personal details stage went from ten screens and around ten taps to four screens and around four taps.
2. Reposition authentication
The token step moved to the end, with one request per session. This kept the first registration action from depending on the unstable delivery mechanism. The design team did not have access to the service’s exact failure rate.
3. Change the card issuance trigger
I identified and proposed linking issuance to completed registration. The team implemented the change to the operational logic, which is associated with the 89% reduction in annual issuance costs reported in the case study.
4. Make progress and validation explicit
A persistent progress bar showed the user’s position in the flow. Validated fields provided visual feedback, and inline errors explained the specific recovery action. Post-launch feedback described the experience as faster.
5. Present fees and plans during registration
I designed a selection step with clear descriptions, explicit fees, and larger touch targets. Plan sales reached four times the previous baseline in the first month after launch. This is a product result; it was not isolated through a controlled experiment.
6. Provide field-specific recovery guidance
Generic messages at the end of the form were replaced by specific errors at the point of interaction. Post-launch monitoring recorded 43% fewer onboarding-related support tickets.
Documented impact
Onboarding completion: 30% before; 75%+ after launch.
Customer conversion: reported growth of 60% over the previous baseline.
Annual card issuance costs: 89% reduction.
Plan sales: 4× in the first month after launch.
Onboarding support tickets: 43% reduction.
Full flow: 15 screens before, 7 at launch, and 6 after the update.
The case study documents six months of post-launch monitoring, with a specific one-month window for plan sales. The results reflect combined changes across design, engineering, and operations, rather than isolated causal attribution to design.
My role and collaboration
I led benchmarking, problem synthesis, the prioritization matrix, and interaction design: progress, validation, errors, loading, account confirmation, and plan selection. I proposed revising the card issuance trigger, negotiated consolidation with the backend team, and aligned components with the evolving design system.
Engineering handled validation and implementation; product and business teams participated in decisions about timelines, risk, and operations. The matrix helped these teams share prioritization criteria and document deferred items.
Reflection
The remaining drop-off was concentrated in longer sessions. Interruptions on shared devices were a plausible hypothesis, without direct confirmation in the available material. Today, I would advocate for a minimal save-and-resume feature in the initial scope.
I would also instrument authentication from the start. Knowing the token delivery failure rate would make it possible to prioritize that technical dependency with more precise data.
Evidence
I analyzed app store reviews, support ticket categories, and comments from internal NPS feedback. Three patterns recurred: authentication failures, limited visibility into account status, and unexpected fees.
Benchmarking six fintechs serving socioeconomic classes C and D identified progress indicators, contextual help, and resume features that the product did not yet offer. I used these findings to discuss priorities with the team, without treating complaints as a precise measure of the backend failure rate.
Constraints and trade-offs
The launch deadline, staged backend validation, and ongoing rebranding limited the solution space. I built an impact and effort matrix and facilitated its use to make choices visible across design, engineering, and business teams.
Reducing the number of screens was a feasible, high-impact intervention. Save and resume, inline help, and contextual tooltips went into the backlog with a documented rationale. The final scope decision was shared.
Decisions and solution
1. Consolidate related fields
Personal details were spread across ten screens, with redundant confirmations. Engineering needed to preserve validation steps. We agreed on seven screens for the full flow at launch and six after post-launch validation, with no observed increase in data errors. The personal details stage went from ten screens and around ten taps to four screens and around four taps.
2. Reposition authentication
The token step moved to the end, with one request per session. This kept the first registration action from depending on the unstable delivery mechanism. The design team did not have access to the service’s exact failure rate.
3. Change the card issuance trigger
I identified and proposed linking issuance to completed registration. The team implemented the change to the operational logic, which is associated with the 89% reduction in annual issuance costs reported in the case study.
4. Make progress and validation explicit
A persistent progress bar showed the user’s position in the flow. Validated fields provided visual feedback, and inline errors explained the specific recovery action. Post-launch feedback described the experience as faster.
5. Present fees and plans during registration
I designed a selection step with clear descriptions, explicit fees, and larger touch targets. Plan sales reached four times the previous baseline in the first month after launch. This is a product result; it was not isolated through a controlled experiment.
6. Provide field-specific recovery guidance
Generic messages at the end of the form were replaced by specific errors at the point of interaction. Post-launch monitoring recorded 43% fewer onboarding-related support tickets.
Documented impact
Onboarding completion: 30% before; 75%+ after launch.
Customer conversion: reported growth of 60% over the previous baseline.
Annual card issuance costs: 89% reduction.
Plan sales: 4× in the first month after launch.
Onboarding support tickets: 43% reduction.
Full flow: 15 screens before, 7 at launch, and 6 after the update.
The case study documents six months of post-launch monitoring, with a specific one-month window for plan sales. The results reflect combined changes across design, engineering, and operations, rather than isolated causal attribution to design.
My role and collaboration
I led benchmarking, problem synthesis, the prioritization matrix, and interaction design: progress, validation, errors, loading, account confirmation, and plan selection. I proposed revising the card issuance trigger, negotiated consolidation with the backend team, and aligned components with the evolving design system.
Engineering handled validation and implementation; product and business teams participated in decisions about timelines, risk, and operations. The matrix helped these teams share prioritization criteria and document deferred items.
Reflection
The remaining drop-off was concentrated in longer sessions. Interruptions on shared devices were a plausible hypothesis, without direct confirmation in the available material. Today, I would advocate for a minimal save-and-resume feature in the initial scope.
I would also instrument authentication from the start. Knowing the token delivery failure rate would make it possible to prioritize that technical dependency with more precise data.