Product Designer
Fintech
2023
Onboarding from 30% to 75%+
A Brazilian fintech serving underbanked segments had an account-opening flow that 7 in 10 people never finished. I led the redesign under a hard launch deadline, working around real backend constraints, a demographic that shared devices and had spotty connectivity, and a business losing money on cards nobody ever used.
75%+
Completion rate — up from
30%
+60%
Customer conversion growth
89%
Annual card issuance cost
reduction
4×
Plan sales in first month post-
launch
Product Designer
Fintech
2023
Onboarding from 30% to 75%+
A Brazilian fintech serving underbanked segments had an account-opening flow that 7 in 10 people never finished. I led the redesign under a hard launch deadline, working around real backend constraints, a demographic that shared devices and had spotty connectivity, and a business losing money on cards nobody ever used.
75%+
Completion rate — up from
30%
+60%
Customer conversion growth
89%
Annual card issuance cost
reduction
4×
Plan sales in first month post-
launch
A flow built for the backend, not the person filling it in
The fintech served classes C and D: customers with inconsistent connectivity, shared devices, and limited experience with digital financial products. The existing onboarding was built around what the backend needed to collect, not what someone could realistically do in one sitting on a phone they might be sharing with a partner or parent.
The 30% completion rate meant most people who started never finished. But the real operational problem was worse: the flow automatically issued a physical card to every new account the moment it was opened, before the person even completed registration. 86% of those cards were never activated. At scale, that's an operational cost with nobody on the receiving end.
01
15-screen flow to open an account, with personal information requested redundantly across multiple steps and no logical grouping
02
Authentication token failure placed at the very start of the flow, on a delivery system with known failures. A blocking dependency before the user had done anything.
03
No save-and-resume. Any interruption meant starting over, a critical miss for a demographic on shared devices with unstable connections.
04
No account status feedback. Users had no way to know where they were in the flow or whether their account was actually being created.
05
Automatic card issuance on account creation, not on registration completion, producing 86% waste and a significant annual cost.
06
Fees hidden until after registration. Users only found out about tariffs post-signup, which drove both support tickets and early churn.
07
UI disconnected from the rebrand. The rest of the product had been updated. Onboarding hadn't, and users noticed at the worst possible moment.
What users were actually saying
I started with app store reviews, support ticket categories, and internal NPS verbatims. The patterns were consistent. Users weren't confused about what the app was for. They were hitting specific, fixable failures and getting no help when they did.
"I'm trying to register the token but it never arrives."
App Store · 1-star review
"It still says my account wasn't created. I've tried four times."
App Store · 1-star review
"There's no chat support and the phone line doesn't
work."
App Store · 1-star review
"It charges R$ X per withdrawal and no one tells you that upfront."
Support ticket
Three failure modes appeared across every source: authentication was broken, users had no idea what was happening to their account, and the fee structure only appeared after they had already committed to registering.
I complemented this with competitive benchmarking of six C/D-focused fintechs. The gap was immediate: every competitor had progress indicators, contextual help, and save-and-resume. This product had none of them, not because they were technically impossible, but because they had never been prioritised.
The authentication insight
Token delivery sat at the start of the flow, on a backend system with known reliability issues. Moving it to the end removed it from the critical path entirely: users who dropped out before completing registration never triggered the broken dependency. One token per session, requested at the final step, meant the most fragile part of the system was no longer blocking anyone from starting.
What we couldn't change, and why that shaped everything
This wasn't a blank-canvas redesign. The constraints were real, documented early, and made visible through an impact-effort matrix that became the shared prioritisation framework for design, engineering, and business stakeholders.
⚠
Hard launch deadline, no phased release
⚠
Backend: no major new features at initial launch
⚠
Server-side validation retained, minor latency accepted
⚠
Save-and-resume deferred to post-launch sprint
⚠
Help and contact features deferred post-launch
⚠
Full rebrand alignment required across all new screens
The matrix made the trade-off argument concrete: cutting nine screens was faster to build and higher impact than adding any single new feature. When stakeholders asked why save-and-resume wasn't in scope for launch, the matrix showed the answer rather than leaving it to debate.
Six decisions and the reasoning behind each one
Decision 01
Collapse 15 screens to 6 by grouping related inputs
Personal information was spread across 10 screens with redundant confirmation steps between each. Grouping related fields and removing the confirmation loops was the most contested decision with the backend team. They wanted to keep 10 screens for server-side validation staging. We negotiated to 7 at launch, then removed one more post-launch when validation data confirmed no increase in data error rates.
Before
10 screens for personal information. Around 10 taps to complete. Same data fields repeated across multiple steps.
After
4 screens for personal information. Around 4 taps. Related fields grouped, no repeated requests.
Decision 02
Move token authentication to the end, one request per session
Authentication was the highest drop-off point in the existing flow because it sat at the very beginning, before the user had completed anything, on a delivery system that frequently failed. Moving it to the final step meant users completed the entire registration before hitting the only unreliable dependency. One token per session broke the loop of failed requests that had been driving a significant share of support volume.
Decision 03
Tie card issuance to completed registration, not account creation
This was a business process change, not a UX feature. Cards were being issued when an account was started, not when registration was finished. Changing the trigger required no new engineering: just a logic change in the issuance workflow. The 89% annual cost reduction came entirely from this single decision. I identified it during problem mapping and proposed it as a zero-UI-cost fix with the highest business impact of anything on the table.
Decision 04
Persistent progress bar with field-level validation feedback
Users had no way to know where they were in the flow or whether their inputs were valid until they tried to submit. The progress bar addressed position; green checkmarks on validated fields addressed input confidence. Both are micro-interactions, but users in post-launch feedback consistently described the redesigned flow as feeling faster, even when the step count had only partially decreased.
Decision 05
Bring fee and plan information into the flow, not after it
App store reviews showed a consistent complaint: users felt misled about fees. The information existed on the website but wasn't in the flow. I introduced a dedicated plan selection screen with plain-language descriptions, clear fee structures, and visually differentiated account types with larger tap areas. Plan sales quadrupled in month one. Users who understood what they were signing up for were more likely to choose a paid plan and significantly less likely to abandon post-registration.
Decision 06
Inline error handling with specific recovery guidance per field
Errors had been generic and end-of-form: one message after submission, no indication of which field caused the problem, no guidance on how to fix it. Replacing that with field-level inline errors, each with specific actionable text, cut onboarding support tickets by 43%. Users who understood what went wrong could fix it without calling support.
Six months post-launch
Metric
Before
After
Onboarding completion rate
<30%
75%+
Customer conversion
Baseline
+60%
Annual card issuance cost
86% waste rate
−89%
Plan sales (month 1 post-launch)
Baseline
4×
Onboarding support tickets
Baseline
−43%
Average screens in flow
15
6
Average taps (personal info)
~10
~4
What I specifically did
Ran competitive benchmark across six C/D-focused fintechs, identifying the three capabilities this product was missing that every competitor had
Built and facilitated the impact-effort matrix that became the shared prioritisation framework across design, engineering, and business stakeholders for the duration of the project
Identified the card issuance logic change (a business process fix, not a UX feature) and proposed it as the highest-ROI intervention on the table. It produced the 89% cost reduction.
Designed the full micro-interaction system: progress bar states, field validation feedback, inline error messages with per-field recovery guidance, loading states, and account confirmation
Negotiated screen count with the backend team across three rounds (from 15 to 7 at launch, then 6 post-launch) and documented the rationale and data behind each reduction
Designed the plan selection and fee disclosure screens that drove 4x plan sales in month one
Aligned all new components with the in-progress design system rebrand so onboarding and the rest of the product were visually consistent at launch
Navigating the team
This project had three competing interests in the same room: engineering wanted validation staging preserved across as many screens as possible; product wanted launch speed; business wanted the cost metrics to move. My job was to find the decision that satisfied all three, not just design.
The most consequential organizational decision was screen consolidation, and it was the most contested. Engineering, product, and design had different definitions of acceptable risk. The impact-effort matrix made those trade-offs visible to everyone at the same time, which changed the conversation from negotiation to shared prioritization. The specifics of that decision and its post-launch validation are in the decisions section below.
Save-and-resume, inline help, and contextual tooltips were explicitly moved to the backlog using the same matrix, not as compromises, but as agreed trade-offs with documented rationale. When stakeholders later asked why those features weren't in the initial scope, the matrix answered the question so I didn't have to.
What I'd do differently
Save-and-resume was deferred because of the deadline. Looking at the post-launch data, the remaining drop-off concentrated in longer sessions, almost certainly users interrupted mid-flow on shared devices. That's exactly what save-and-resume addresses. I'd push harder to scope a minimal version into the initial launch rather than framing it as a phase-two feature.
I'd also instrument the authentication step from day one. For the duration of the project, the backend token delivery failure rate was a black box for the design team. Better observability there would have let us make the case for moving authentication earlier, and with harder data, not inference from app store reviews.
What users were actually saying
I started with app store reviews, support ticket categories, and internal NPS verbatims. The patterns were consistent. Users weren't confused about what the app was for. They were hitting specific, fixable failures and getting no help when they did.
"I'm trying to register the token but it never arrives."
App Store · 1-star review
"It still says my account wasn't created. I've tried four times."
App Store · 1-star review
"There's no chat support and the phone line doesn't
work."
App Store · 1-star review
"It charges R$ X per withdrawal and no one tells you that upfront."
Support ticket
Three failure modes appeared across every source: authentication was broken, users had no idea what was happening to their account, and the fee structure only appeared after they had already committed to registering.
I complemented this with competitive benchmarking of six C/D-focused fintechs. The gap was immediate: every competitor had progress indicators, contextual help, and save-and-resume. This product had none of them, not because they were technically impossible, but because they had never been prioritised.
The authentication insight
Token delivery sat at the start of the flow, on a backend system with known reliability issues. Moving it to the end removed it from the critical path entirely: users who dropped out before completing registration never triggered the broken dependency. One token per session, requested at the final step, meant the most fragile part of the system was no longer blocking anyone from starting.
What we couldn't change, and why that shaped everything
This wasn't a blank-canvas redesign. The constraints were real, documented early, and made visible through an impact-effort matrix that became the shared prioritisation framework for design, engineering, and business stakeholders.
⚠
Hard launch deadline, no phased release
⚠
Backend: no major new features at initial launch
⚠
Server-side validation retained, minor latency accepted
⚠
Save-and-resume deferred to post-launch sprint
⚠
Help and contact features deferred post-launch
⚠
Full rebrand alignment required across all new screens
The matrix made the trade-off argument concrete: cutting nine screens was faster to build and higher impact than adding any single new feature. When stakeholders asked why save-and-resume wasn't in scope for launch, the matrix showed the answer rather than leaving it to debate.
Six decisions and the reasoning behind each one
Decision 01
Collapse 15 screens to 6 by grouping related inputs
Personal information was spread across 10 screens with redundant confirmation steps between each. Grouping related fields and removing the confirmation loops was the most contested decision with the backend team. They wanted to keep 10 screens for server-side validation staging. We negotiated to 7 at launch, then removed one more post-launch when validation data confirmed no increase in data error rates.
Before
10 screens for personal information. Around 10 taps to complete. Same data fields repeated across multiple steps.
After
4 screens for personal information. Around 4 taps. Related fields grouped, no repeated requests.
Decision 02
Move token authentication to the end, one request per session
Authentication was the highest drop-off point in the existing flow because it sat at the very beginning, before the user had completed anything, on a delivery system that frequently failed. Moving it to the final step meant users completed the entire registration before hitting the only unreliable dependency. One token per session broke the loop of failed requests that had been driving a significant share of support volume.
Decision 03
Tie card issuance to completed registration, not account creation
This was a business process change, not a UX feature. Cards were being issued when an account was started, not when registration was finished. Changing the trigger required no new engineering: just a logic change in the issuance workflow. The 89% annual cost reduction came entirely from this single decision. I identified it during problem mapping and proposed it as a zero-UI-cost fix with the highest business impact of anything on the table.
Decision 04
Persistent progress bar with field-level validation feedback
Users had no way to know where they were in the flow or whether their inputs were valid until they tried to submit. The progress bar addressed position; green checkmarks on validated fields addressed input confidence. Both are micro-interactions, but users in post-launch feedback consistently described the redesigned flow as feeling faster, even when the step count had only partially decreased.
Decision 05
Bring fee and plan information into the flow, not after it
App store reviews showed a consistent complaint: users felt misled about fees. The information existed on the website but wasn't in the flow. I introduced a dedicated plan selection screen with plain-language descriptions, clear fee structures, and visually differentiated account types with larger tap areas. Plan sales quadrupled in month one. Users who understood what they were signing up for were more likely to choose a paid plan and significantly less likely to abandon post-registration.
Decision 06
Inline error handling with specific recovery guidance per field
Errors had been generic and end-of-form: one message after submission, no indication of which field caused the problem, no guidance on how to fix it. Replacing that with field-level inline errors, each with specific actionable text, cut onboarding support tickets by 43%. Users who understood what went wrong could fix it without calling support.
Six months post-launch
Metric
Before
After
Onboarding completion rate
<30%
75%+
Customer conversion
Baseline
+60%
Annual card issuance cost
86% waste rate
−89%
Plan sales (month 1 post-launch)
Baseline
4×
Onboarding support tickets
Baseline
−43%
Average screens in flow
15
6
Average taps (personal info)
~10
~4
What I specifically did
Ran competitive benchmark across six C/D-focused fintechs, identifying the three capabilities this product was missing that every competitor had
Built and facilitated the impact-effort matrix that became the shared prioritisation framework across design, engineering, and business stakeholders for the duration of the project
Identified the card issuance logic change (a business process fix, not a UX feature) and proposed it as the highest-ROI intervention on the table. It produced the 89% cost reduction.
Designed the full micro-interaction system: progress bar states, field validation feedback, inline error messages with per-field recovery guidance, loading states, and account confirmation
Negotiated screen count with the backend team across three rounds (from 15 to 7 at launch, then 6 post-launch) and documented the rationale and data behind each reduction
Designed the plan selection and fee disclosure screens that drove 4x plan sales in month one
Aligned all new components with the in-progress design system rebrand so onboarding and the rest of the product were visually consistent at launch
Navigating the team
This project had three competing interests in the same room: engineering wanted validation staging preserved across as many screens as possible; product wanted launch speed; business wanted the cost metrics to move. My job was to find the decision that satisfied all three, not just design.
The most consequential organizational decision was screen consolidation, and it was the most contested. Engineering, product, and design had different definitions of acceptable risk. The impact-effort matrix made those trade-offs visible to everyone at the same time, which changed the conversation from negotiation to shared prioritization. The specifics of that decision and its post-launch validation are in the decisions section below.
Save-and-resume, inline help, and contextual tooltips were explicitly moved to the backlog using the same matrix, not as compromises, but as agreed trade-offs with documented rationale. When stakeholders later asked why those features weren't in the initial scope, the matrix answered the question so I didn't have to.
What I'd do differently
Save-and-resume was deferred because of the deadline. Looking at the post-launch data, the remaining drop-off concentrated in longer sessions, almost certainly users interrupted mid-flow on shared devices. That's exactly what save-and-resume addresses. I'd push harder to scope a minimal version into the initial launch rather than framing it as a phase-two feature.
I'd also instrument the authentication step from day one. For the duration of the project, the backend token delivery failure rate was a black box for the design team. Better observability there would have let us make the case for moving authentication earlier, and with harder data, not inference from app store reviews.