Building trust through transparency in the verification process
I led the product design process to introduce identity verification in a way that prioritized user trust and clarity around sensitive data. By staging friction intentionally rather than removing it, the redesigned flow achieved an 80% verification completion post-launch.
Role
Timeline
3 Months
Team
Product Managers x 2
Engineers x 3
Context
Fanspark is a social subscription content platform for athletes and sports creators. When business requirements changed, the platform needed to shift from social authentication to identity verification to improve creator authenticity and platform trust.
Challenge: Introduce identity verification in a way that prioritizes transparency and trust
Identity verification introduced significantly more friction than social authentication, requiring creators to submit a government ID and take a selfie at a moment when trust in the platform was still forming.
Constraints
Technical: Stripe Identity integration dictated the verification UI and flow, limiting design changes to the entry point
Scope: Work was limited to the verification step, though testing suggested trust issues existed across the broader onboarding experience
Business: Identity verification was required to meet compliance and fraud prevention requirements
Timeline: A compressed timeline prioritized shipping an improved flow first, with measurement and iteration planned post-launch
The current verification process
Creator verification is a 4-step process that requires creators to complete before posting on the platform.
Creators are asked to verify after sign-up and onboarding when trust is still being formed
This timing plays a big role in the level of trust users have in the platform. Creators are brand new, trust is being formed, and now they're about to be asked for a higher level of sensitive information than social authentication.
At this stage, creators would be cautious about sharing sensitive identity information, making drop-off the biggest risk leading to two design questions:
[01]
[02]
Risk assessment: Where creators might hesitate or drop off
Because this was a new high-friction, trust-sensitive step, I proactively identified potential risks in the experience and focused on mitigating them through design.
Early drop-off due to increased friction
Requests for government IDs and sensitive information could discourage users from completing verification
Reduced trust from sensitive data requests
Creators may hesitate if they don't understand why information is required or how it will be used
Loss of momentum from forced completion
Requiring creators to complete verification in a defined order could increase abandonment
Key Design Decisions
The risks identified informed 3 key design decisions aimed at building trust and reducing friction.
KEY DESIGN DECISION #1
Re-ordering verification steps by risk level
I strategically restructured requirements to start with low-commitment, less sensitive actions and then introduce high-stakes identity and banking requirements.
Impact: Reduces early exposure to high-stakes asks, easing creators into the process
KEY DESIGN DECISION #2
Increased transparency by explaining what we need and why
Because uncertainty adds friction, explaining what we need and why is crucial.
Impact: Increased clarity and perceived legitimacy
KEY DESIGN DECISION #3
Increased sense of control
Creators can now preview and complete requirements in the order they feel most comfortable with.
Impact: Adds transparency, reducing anxiety and unknown effort
Validation
To evaluate the effectiveness of the redesigned verification experience, we conducted 2 rounds of testing pre and post launch.
Beta Testing Results
4/5 participants successfully completed verification
Post-Launch Results
80% verification completion rate
Positive feedback from creators that it was "easy to use" and "simple"
Next Steps
The 80% completion rate was a strong outcome, but post-launch data revealed that drop-off was permanent. Creators who didn't complete verification weren't returning to the platform.
I defined a more flexible verification flow that allows creators to complete requirements progressively, reducing the upfront ask before they've experienced platform value. The updated flow is planned to be validated through A/B testing