Independent fintech product case study
Finwise Investment Onboarding for First-Time Users
A mobile-first onboarding case study exploring how first-time investors can move through identity verification, risk profiling, and first-investment readiness with more trust and less ambiguity.
Case summary
Finwise is an independent product case study exploring how first-time investors can be guided through financial onboarding without losing trust, feeling overwhelmed, or misunderstanding risk.
The project focuses on a common fintech problem: users are often interested in investing, but they hesitate when the product asks for personal information, identity verification, risk profile questions, or financial commitments too early.
The goal was to design an onboarding experience that feels transparent, safe, and actionable while still respecting the realities of financial products: compliance, KYC, risk disclosure, and user responsibility.
Why this problem matters
At first glance, onboarding looks like a form-design problem. But in fintech, onboarding is not just about completing fields faster.
The real problem is trust.
A user may stop not because the flow is long, but because they do not understand why identity verification is required, whether they will be asked to deposit money immediately, what financial risk they are accepting, how personal data will be used, or whether they can pause and continue later.
How might we help first-time users complete investment onboarding without hiding complexity, risk, or legal requirements?
Product context
Finwise is a concept for a beginner-friendly investment platform focused on people who want to start investing but do not yet feel confident.
- Account creation
- Identity verification
- Basic risk profiling
- First investment readiness
- Transparent fee and risk explanation
- Guided first action
The target user is not an experienced trader. The target user is someone who is financially curious but cautious.
Users do not need the product to make investing look effortless. They need the product to make each step understandable, reversible, and transparent.
Constraints
Compliance constraints
The product must explain risk and identity verification clearly. It cannot make investing feel risk-free or hide important information behind friendly UI.
Trust constraints
The interface must not ask for sensitive data before explaining why it is needed.
Business constraints
The company wants users to reach the first meaningful action: completing onboarding and understanding what they can do next.
UX constraints
The flow must work on mobile, support interruption, and allow users to continue later.
Content constraints
Financial language must be clear without becoming misleading or oversimplified.
Questions that shaped the work
| Question | Why it mattered | Design implication |
|---|---|---|
| Do users understand why KYC is required? | If not, identity verification feels invasive. | Explain verification before asking for documents. |
| Do users know when money is required? | Fear of hidden payment creates hesitation. | Add reassurance that no deposit is required yet. |
| Which financial terms create anxiety? | Abstract terms can block progress. | Use plain-language explanations and examples. |
| Can users pause safely? | Users may not have documents ready. | Add save-and-continue behavior. |
| What happens when verification fails? | Edge cases affect trust. | Design recovery states, not just success states. |
User situations
Exploring without commitment
A user wants to see how the platform works but is not ready to deposit money.
Hesitating before ID verification
A user starts onboarding but stops when asked to upload an ID because the reason is unclear.
Returning later
A user begins onboarding on mobile but needs to continue later when documents are available.
Risk confusion
A user completes the risk questionnaire but does not understand what their result means.
Verification problem
A user uploads a document, but the verification fails or requires manual review.
Design principles
Explain before asking
Before asking for sensitive data, the product explains why the information is needed and how it helps protect the user.
No surprise money moments
Users should always know when money is not required yet and when a financial commitment begins.
Make risk visible, not scary
Risk should not be hidden, but it should be explained in plain language with examples.
Let users pause safely
Users should be able to stop, return later, and clearly understand where they left off.
Solution directions considered
| Direction | Strength | Risk | Decision |
|---|---|---|---|
| One-page onboarding | Feels fast and compact. | Too heavy for sensitive fintech steps. | Rejected |
| Chat-style onboarding | Friendly and conversational. | Harder for compliance review and scanning. | Rejected |
| Step-by-step guided flow | Clear progress and easier recovery. | Slightly longer experience. | Chosen |
The step-by-step model was selected because it made progress visible, gave users more control, and allowed sensitive steps to be introduced with context.
Flow logic
The final flow was structured around moments of hesitation, not just company-required steps.
- Welcome and expectation setting
- Account creation
- No deposit required yet reassurance
- Identity verification explanation
- KYC document upload
- Risk profile questionnaire
- Risk result explanation
- Investment readiness checklist
- First action options
- Save-and-continue states
Key screen decisions
01Welcome
The welcome screen avoids generic marketing language. It explains what the user will complete and what will not happen yet.
Key decision: show “No deposit required to set up your account” before users begin.
02Progress overview
Instead of showing only step numbers, the progress overview uses task labels: create account, verify identity, understand risk profile, and get ready to invest.
03Identity verification explanation
Before asking for ID, the interface explains why verification is required and reassures users that they can continue without making a deposit.
04Document upload
The upload screen includes accepted documents, photo quality tips, and estimated review time to prevent avoidable failure before upload.
05Risk profile questionnaire
The questionnaire uses behavior-based questions instead of abstract financial terminology, because users understand situations better than risk labels.
06Risk result
The result explains what the risk profile means and what it does not mean, avoiding language that makes the result feel like financial advice.
07Investment readiness checklist
After onboarding, users see a checklist instead of being pushed directly into deposit. Deposit remains optional.
08Continue later state
If the user leaves onboarding, the product saves progress and explains what remains. Interruption becomes part of the designed experience.
Edge cases
KYC failed
The user gets a clear reason and practical next step, such as retaking a blurry photo in better lighting.
Manual review
The product explains that verification is pending and what the user can do meanwhile.
User is not ready to invest
The product allows users to explore educational content without depositing money.
High-risk mismatch
If a user selects high-risk products but has a cautious profile, the interface adds a warning and explanation.
Design system layer
Because fintech products rely heavily on repeated patterns, I created a small UI system for the case.
- Buttons
- Inputs
- Progress steps
- Verification cards
- Alert banners
- Risk explanation cards
- Checklists
- Document upload module
- Status badges
- Empty and error states
The token structure covered background, surface, text, border, success, warning, and error colors, plus typography, spacing, radius, and elevation tokens for form-heavy layouts.
Accessibility considerations included clear contrast for warning and error messages, visible form labels, field-level guidance, progress that does not rely on color alone, and touch-friendly controls on mobile.
Decision log
| Decision | Why it mattered | Trade-off |
|---|---|---|
| Split onboarding into smaller steps | Reduces cognitive load. | Adds more screens. |
| Explain KYC before document upload | Builds trust before sensitive action. | Slows the flow slightly. |
| Show “no deposit required yet” early | Reduces fear of hidden commitment. | Adds extra copy. |
| Use behavior-based risk questions | Easier for beginners to answer. | Less compact than standard forms. |
| Add save-and-continue states | Supports real-life interruption. | Requires additional system states. |
| Show fees before funding | Builds transparency. | Adds complexity before conversion. |
| Use checklist after onboarding | Gives user control. | Less aggressive conversion push. |
Prototype
I created a clickable prototype to test the main onboarding path and hesitation points.
- Welcome flow
- Account setup
- KYC explanation
- Document upload
- Risk questionnaire
- Risk result
- Readiness checklist
- Continue-later state
Validation plan
Because this is an independent case study, I did not claim business results. Instead, I defined a lightweight validation plan.
- Do users understand that no deposit is required yet?
- Do users understand why identity verification is needed?
- Can users complete the risk profile without confusion?
- Do users know what to do after onboarding?
- Do users feel they can pause and return later?
The suggested format is a mobile prototype test with 5 participants, task-based sessions, and a 20-25 minute focus on hesitation, comprehension, and trust.
Example usability findings
| Finding | Evidence | Design change |
|---|---|---|
| Users hesitated before KYC | 3 of 5 participants asked why ID was needed. | Added explanation before upload. |
| Deposit timing was unclear | 2 participants expected payment during setup. | Added “No deposit required yet” message. |
| Risk result felt too abstract | Users wanted examples. | Added plain-language explanation. |
| Continue-later option was missed | Users did not notice save behavior. | Added persistent save-and-continue indicator. |
What I would measure after launch
Product metrics
Onboarding completion rate, KYC completion rate, drop-off per step, time to complete onboarding, return-to-onboarding rate, first deposit conversion, and first investment conversion.
Trust and comprehension metrics
Support tickets about KYC and fees, user understanding of risk profile, hesitation before document upload, and confidence after onboarding.
Design system metrics
Component reuse, form error reduction, development handoff clarity, and consistency across onboarding screens.
Final outcome
The final solution is a mobile-first fintech onboarding flow designed around trust, clarity, and responsible activation.
Instead of pushing users quickly toward financial action, the flow helps them understand what is happening, why it matters, and what they can safely do next.
- Product problem framing
- Fintech-specific UX constraints
- Onboarding flow design
- Trust-building interface patterns
- Risk communication
- Edge case design
- Design system thinking
- Validation planning
- Launch metric definition
Reflection
The most important insight from this project is that fintech onboarding is not only about reducing steps. In sensitive products, speed is not always the best measure of quality.
A better onboarding experience helps users move forward with clarity.
For this case, the strongest design decisions were structural: explaining before asking, making risk understandable, showing that deposit is not required yet, designing recovery states, and letting users pause and continue later.
If this were developed further, I would test the prototype with beginner investors, compare different KYC explanation formats, and explore how educational content could support users before their first investment decision.
