Designing Trust at First Sight
Designing Trust at First Sight
Client
PYA
Role
Product designer
Platform
Web app
Timeline
4 weeks
Date
June, 2025
Introduction
Introduction
Pya is a premium dating platform built around a simple guarantee: verified people and confirmed dates, with no guesswork in between.
Traditional dating apps fail at the moment that matters most: the transition from match to real-world meeting. Profiles are unverified, intent is unclear, and commitment is optional. Pya was designed to remove that uncertainty entirely by structuring intent from the start.
Men create date invites with a set amount, location, and time. Women browse and accept on their own terms. Once a match is made, the date is locked in.
The platform was designed to serve two users with fundamentally different motivations, and to make both feel safe enough to follow through.
Pya is a premium dating platform built around a simple guarantee: verified people and confirmed dates, with no guesswork in between.
Traditional dating apps fail at the moment that matters most: the transition from match to real-world meeting. Profiles are unverified, intent is unclear, and commitment is optional. Pya was designed to remove that uncertainty entirely by structuring intent from the start.
Men create date invites with a set amount, location, and time. Women browse and accept on their own terms. Once a match is made, the date is locked in.
The platform was designed to serve two users with fundamentally different motivations, and to make both feel safe enough to follow through.
Introduction
Pya is a premium dating platform built around a simple guarantee: verified people and confirmed dates, with no guesswork in between.
Traditional dating apps fail at the moment that matters most: the transition from match to real-world meeting. Profiles are unverified, intent is unclear, and commitment is optional. Pya was designed to remove that uncertainty entirely by structuring intent from the start.
Men create date invites with a set amount, location, and time. Women browse and accept on their own terms. Once a match is made, the date is locked in.
The platform was designed to serve two users with fundamentally different motivations, and to make both feel safe enough to follow through.
The Challenge
The Challenge
Dating apps have a trust problem. Profiles are unverified, matches go nowhere, and the person who shows up rarely matches the one who was promised. For most users, that's an inconvenience. For a platform where dates are paid and confirmed in advance, the stakes are completely different.
The first thing Pya had to sell wasn't a date. It was trust.
Pya needed to solve for trust before anything else could work. Without it, wealthy men wouldn't commit to paying. Without it, women wouldn't feel safe enough to show up. The entire product depended on both user groups believing the platform had done the vetting work so they didn't have to.
The harder problem was that Pya's two users arrive with opposing incentives and opposing anxieties. Men want efficiency and certainty, a guaranteed date with a real, verified person, no wasted effort. Women want safety and control, the ability to evaluate, accept on their own terms, and never feel like a passive option in someone else's decision. Designing a single platform that served both without either experience feeling like an afterthought was the central design challenge.
Dating apps have a trust problem. Profiles are unverified, matches go nowhere, and the person who shows up rarely matches the one who was promised. For most users, that's an inconvenience. For a platform where dates are paid and confirmed in advance, the stakes are completely different.
The first thing Pya had to sell wasn't a date. It was trust.
Pya needed to solve for trust before anything else could work. Without it, wealthy men wouldn't commit to paying. Without it, women wouldn't feel safe enough to show up. The entire product depended on both user groups believing the platform had done the vetting work so they didn't have to.
The harder problem was that Pya's two users arrive with opposing incentives and opposing anxieties. Men want efficiency and certainty, a guaranteed date with a real, verified person, no wasted effort. Women want safety and control, the ability to evaluate, accept on their own terms, and never feel like a passive option in someone else's decision. Designing a single platform that served both without either experience feeling like an afterthought was the central design challenge.
The Challenge
Dating apps have a trust problem. Profiles are unverified, matches go nowhere, and the person who shows up rarely matches the one who was promised. For most users, that's an inconvenience. For a platform where dates are paid and confirmed in advance, the stakes are completely different.
The first thing Pya had to sell wasn't a date. It was trust.
Pya needed to solve for trust before anything else could work. Without it, wealthy men wouldn't commit to paying. Without it, women wouldn't feel safe enough to show up. The entire product depended on both user groups believing the platform had done the vetting work so they didn't have to.
The harder problem was that Pya's two users arrive with opposing incentives and opposing anxieties. Men want efficiency and certainty, a guaranteed date with a real, verified person, no wasted effort. Women want safety and control, the ability to evaluate, accept on their own terms, and never feel like a passive option in someone else's decision. Designing a single platform that served both without either experience feeling like an afterthought was the central design challenge.
Verification by Design
Verification by Design
Before anyone can create a date or browse the platform, both have to pass a manual verification process covering identity, photos, and video. For men, finances too.
The onboarding splits into two flows based on gender, each tailored to what that user needs to prove. The male flow runs across three stages: personal details, identity verification, and financial declaration. The female flow covers the first two. The three-step structure for men wasn't arbitrary. Framing income declaration as a natural third stage, rather than an upfront ask, made a sensitive requirement feel like a logical progression rather than an interrogation.
Before anyone can create a date or browse the platform, both have to pass a manual verification process covering identity, photos, and video. For men, finances too.
The onboarding splits into two flows based on gender, each tailored to what that user needs to prove. The male flow runs across three stages: personal details, identity verification, and financial declaration. The female flow covers the first two. The three-step structure for men wasn't arbitrary. Framing income declaration as a natural third stage, rather than an upfront ask, made a sensitive requirement feel like a logical progression rather than an interrogation.
Verification by Design
Before anyone can create a date or browse the platform, both have to pass a manual verification process covering identity, photos, and video. For men, finances too.
The onboarding splits into two flows based on gender, each tailored to what that user needs to prove. The male flow runs across three stages: personal details, identity verification, and financial declaration. The female flow covers the first two. The three-step structure for men wasn't arbitrary. Framing income declaration as a natural third stage, rather than an upfront ask, made a sensitive requirement feel like a logical progression rather than an interrogation.
Video verification screen
After submission, users land on an application status screen that shows the review state of each verification item individually. Not a single "pending" label, but a clear breakdown of what's been approved, what's still under review, and what needs attention. The distinction matters. Users know exactly where they stand without having to contact support.
After submission, users land on an application status screen that shows the review state of each verification item individually. Not a single "pending" label, but a clear breakdown of what's been approved, what's still under review, and what needs attention. The distinction matters. Users know exactly where they stand without having to contact support.
After submission, users land on an application status screen that shows the review state of each verification item individually. Not a single "pending" label, but a clear breakdown of what's been approved, what's still under review, and what needs attention. The distinction matters. Users know exactly where they stand without having to contact support.
Application submitted screen
Action required screen
On the admin side, every application is reviewed manually. Rejecting required a more considered solution than a simple decline. Admins select from a structured list of specific failure reasons, and that selection is surfaced directly to the user alongside a prompt to reupload. A rejected applicant should never have to guess why or what to fix.
On the admin side, every application is reviewed manually. Rejecting required a more considered solution than a simple decline. Admins select from a structured list of specific failure reasons, and that selection is surfaced directly to the user alongside a prompt to reupload. A rejected applicant should never have to guess why or what to fix.
On the admin side, every application is reviewed manually. Rejecting required a more considered solution than a simple decline. Admins select from a structured list of specific failure reasons, and that selection is surfaced directly to the user alongside a prompt to reupload. A rejected applicant should never have to guess why or what to fix.
Designing for Opposing Mental Models
Designing for Opposing Mental Models
Pya serves two users who approach the same goal from very different perspectives. Men arrive with a selection mindset; they're choosing. Women arrive with an evaluation mindset; they're deciding whether something is worth their time and safe enough to pursue. Designing for both without either experience feeling secondary was the central tension of the product.
The flows reflect that difference at every level. Men create date invites with an amount, location, date, time, and age preference. Women browse a feed of those invites, open the ones that interest them, and accept on their own terms. The information each side sees is calibrated to their decision. Women see the man's photos, amount, occupation, bio, and the actual venue with photos and a map link before committing to anything. The date details come after the person, because that's the order the decision is actually made in.
Pya serves two users who approach the same goal from very different perspectives. Men arrive with a selection mindset; they're choosing. Women arrive with an evaluation mindset; they're deciding whether something is worth their time and safe enough to pursue. Designing for both without either experience feeling secondary was the central tension of the product.
The flows reflect that difference at every level. Men create date invites with an amount, location, date, time, and age preference. Women browse a feed of those invites, open the ones that interest them, and accept on their own terms. The information each side sees is calibrated to their decision. Women see the man's photos, amount, occupation, bio, and the actual venue with photos and a map link before committing to anything. The date details come after the person, because that's the order the decision is actually made in.
Designing for Opposing Mental Models
Pya serves two users who approach the same goal from very different perspectives. Men arrive with a selection mindset; they're choosing. Women arrive with an evaluation mindset; they're deciding whether something is worth their time and safe enough to pursue. Designing for both without either experience feeling secondary was the central tension of the product.
The flows reflect that difference at every level. Men create date invites with an amount, location, date, time, and age preference. Women browse a feed of those invites, open the ones that interest them, and accept on their own terms. The information each side sees is calibrated to their decision. Women see the man's photos, amount, occupation, bio, and the actual venue with photos and a map link before committing to anything. The date details come after the person, because that's the order the decision is actually made in.
On the male side, the harder problem was the selection moment. When multiple women express interest in a date invite, a man has to choose one. Selecting too early, before seeing everyone who responded, risked premature decisions and reduced meaningful engagement with other interested matches. The favorites system was designed to solve that. Rather than forcing an immediate decision, men can shortlist profiles and return to make a final choice when they're ready.
Both sides of the platform share the same confirmation language but in different registers. When a man locks in a date, it feels decisive. When a woman is selected, it feels like a win. The same moment, designed twice.
On the male side, the harder problem was the selection moment. When multiple women express interest in a date invite, a man has to choose one. Selecting too early, before seeing everyone who responded, risked premature decisions and reduced meaningful engagement with other interested matches. The favorites system was designed to solve that. Rather than forcing an immediate decision, men can shortlist profiles and return to make a final choice when they're ready.
Both sides of the platform share the same confirmation language but in different registers. When a man locks in a date, it feels decisive. When a woman is selected, it feels like a win. The same moment, designed twice.
On the male side, the harder problem was the selection moment. When multiple women express interest in a date invite, a man has to choose one. Selecting too early, before seeing everyone who responded, risked premature decisions and reduced meaningful engagement with other interested matches. The favorites system was designed to solve that. Rather than forcing an immediate decision, men can shortlist profiles and return to make a final choice when they're ready.
Both sides of the platform share the same confirmation language but in different registers. When a man locks in a date, it feels decisive. When a woman is selected, it feels like a win. The same moment, designed twice.
Add to favorites flow
Select date flow
Selected for date modal
Reducing Friction at High-Stakes Moments
Reducing Friction at High-Stakes Moments
Several moments in Pya carry real consequences. A date gets locked in and can't be changed. A payment is processed. A woman's profile disappears from the platform for 24 hours. These aren't moments you can design casually. Anxiety at any one of them is enough to kill the action entirely.
The payment step sits between invite creation and the date going live. The copy does specific work here: you'll only be charged once your date is confirmed, never before. That single line reframes the payment detail screen from a commitment into a preparation. Men are adding a method, not spending money. It removes the hesitation that would otherwise live in that step.
Several moments in Pya carry real consequences. A date gets locked in and can't be changed. A payment is processed. A woman's profile disappears from the platform for 24 hours. These aren't moments you can design casually. Anxiety at any one of them is enough to kill the action entirely.
The payment step sits between invite creation and the date going live. The copy does specific work here: you'll only be charged once your date is confirmed, never before. That single line reframes the payment detail screen from a commitment into a preparation. Men are adding a method, not spending money. It removes the hesitation that would otherwise live in that step.
Reducing Friction at High-Stakes Moments
Several moments in Pya carry real consequences. A date gets locked in and can't be changed. A payment is processed. A woman's profile disappears from the platform for 24 hours. These aren't moments you can design casually. Anxiety at any one of them is enough to kill the action entirely.
The payment step sits between invite creation and the date going live. The copy does specific work here: you'll only be charged once your date is confirmed, never before. That single line reframes the payment detail screen from a commitment into a preparation. Men are adding a method, not spending money. It removes the hesitation that would otherwise live in that step.
Add payment details screen
The cooldown system presented a different problem. Women can accept as many invites as they like, but once selected for two dates, their profile is hidden from the platform for 24 hours. That's a significant consequence to absorb mid-flow. The solution was to surface it before it happened. The acceptance confirmation modal explains the cooldown clearly before the second confirmation is made, not after. Women know the trade-off before they commit to it.
The cooldown system presented a different problem. Women can accept as many invites as they like, but once selected for two dates, their profile is hidden from the platform for 24 hours. That's a significant consequence to absorb mid-flow. The solution was to surface it before it happened. The acceptance confirmation modal explains the cooldown clearly before the second confirmation is made, not after. Women know the trade-off before they commit to it.
The cooldown system presented a different problem. Women can accept as many invites as they like, but once selected for two dates, their profile is hidden from the platform for 24 hours. That's a significant consequence to absorb mid-flow. The solution was to surface it before it happened. The acceptance confirmation modal explains the cooldown clearly before the second confirmation is made, not after. Women know the trade-off before they commit to it.
Cool down timer screen
Not all friction came from irreversible decisions. Some came from uncertainty. New users arriving on an unfamiliar platform needed to understand only what mattered now, not every capability the system would eventually provide. The navigation reflects that. Tabs appear as users progress and take actions, keeping the experience focused at every stage.
Not all friction came from irreversible decisions. Some came from uncertainty. New users arriving on an unfamiliar platform needed to understand only what mattered now, not every capability the system would eventually provide. The navigation reflects that. Tabs appear as users progress and take actions, keeping the experience focused at every stage.
Not all friction came from irreversible decisions. Some came from uncertainty. New users arriving on an unfamiliar platform needed to understand only what mattered now, not every capability the system would eventually provide. The navigation reflects that. Tabs appear as users progress and take actions, keeping the experience focused at every stage.
The hardest moment to design for was one that happens off-platform entirely: whether the date actually occurred. Because the outcome can't be observed directly, neither side can be treated as the sole source of truth. The dispute process was designed around evidence rather than assumptions, giving administrators the context needed to make a defensible decision. It's not a perfect system, and it wasn't designed to be. It's designed to be fair.
The hardest moment to design for was one that happens off-platform entirely: whether the date actually occurred. Because the outcome can't be observed directly, neither side can be treated as the sole source of truth. The dispute process was designed around evidence rather than assumptions, giving administrators the context needed to make a defensible decision. It's not a perfect system, and it wasn't designed to be. It's designed to be fair.
The hardest moment to design for was one that happens off-platform entirely: whether the date actually occurred. Because the outcome can't be observed directly, neither side can be treated as the sole source of truth. The dispute process was designed around evidence rather than assumptions, giving administrators the context needed to make a defensible decision. It's not a perfect system, and it wasn't designed to be. It's designed to be fair.
Post date - went as planned
Post date - didn't go as planned
The Result
The Result
Pya launched in 2025. The design was completed in four weeks, with development following over the next two months. A platform that started as a PRD was live, verified, and ready for its first users. Not a prototype. A product with real users, real payments, and real dates being scheduled through it.
With the core experience in place, the focus shifted from building the product to bringing users into it. Ad creatives were developed to support the first acquisition efforts, marking the transition from product development to market launch.
The biggest lesson from Pya became clearer with every design decision: trust can't be added later. Verification, matching, payments, and disputes were all trust problems in disguise. The challenge was never simply building a dating platform. It was creating enough confidence for strangers to meet in the real world and transact through a product they'd never used before. Every design decision traced back to that goal.
One problem remains genuinely open. The post-date confirmation flow currently relies on both parties independently confirming whether a date occurred, with conflicts escalating to admin review. While functional, it still depends on user initiation. A future iteration could infer likely completion from conversation context and trigger confirmation prompts automatically, reducing friction and narrowing the window for disputes.
Pya launched in 2025. The design was completed in four weeks, with development following over the next two months. A platform that started as a PRD was live, verified, and ready for its first users. Not a prototype. A product with real users, real payments, and real dates being scheduled through it.
With the core experience in place, the focus shifted from building the product to bringing users into it. Ad creatives were developed to support the first acquisition efforts, marking the transition from product development to market launch.
The biggest lesson from Pya became clearer with every design decision: trust can't be added later. Verification, matching, payments, and disputes were all trust problems in disguise. The challenge was never simply building a dating platform. It was creating enough confidence for strangers to meet in the real world and transact through a product they'd never used before. Every design decision traced back to that goal.
One problem remains genuinely open. The post-date confirmation flow currently relies on both parties independently confirming whether a date occurred, with conflicts escalating to admin review. While functional, it still depends on user initiation. A future iteration could infer likely completion from conversation context and trigger confirmation prompts automatically, reducing friction and narrowing the window for disputes.
The Result
Pya launched in 2025. The design was completed in four weeks, with development following over the next two months. A platform that started as a PRD was live, verified, and ready for its first users. Not a prototype. A product with real users, real payments, and real dates being scheduled through it.
With the core experience in place, the focus shifted from building the product to bringing users into it. Ad creatives were developed to support the first acquisition efforts, marking the transition from product development to market launch.
The biggest lesson from Pya became clearer with every design decision: trust can't be added later. Verification, matching, payments, and disputes were all trust problems in disguise. The challenge was never simply building a dating platform. It was creating enough confidence for strangers to meet in the real world and transact through a product they'd never used before. Every design decision traced back to that goal.
One problem remains genuinely open. The post-date confirmation flow currently relies on both parties independently confirming whether a date occurred, with conflicts escalating to admin review. While functional, it still depends on user initiation. A future iteration could infer likely completion from conversation context and trigger confirmation prompts automatically, reducing friction and narrowing the window for disputes.
Next project Next Project
Next Project Next Project
JAMIE FROST
JAMIE FROST
JAMIE FROST
JAMIE FROST
©2026 JAMIE FROST
GO BACK TO TOP
©2026 JAMIE FROST
GO BACK TO TOP