Case Study| Product Design
Marzi
A social network built for older adults, modernising a familiar product without leaving its 65+ community behind.
Role
Product Designer
Timeline
2026
Team
03
Platform
iOS & Android
Industry
Community Building
01 Overview
Modernising a product people already love.
Marzi is a premium social community for Indians aged 50+, conversation, events, and paid travel. The business depends on who's inside it. Let the wrong people in and conversation quality drops, nobody pays for experiences, and the brand doesn't recover.
So the product needed a gate. The problem was that everyone who meets a gate finds out they've been measured.
My role: Product Designer II on onboarding and gating. Owned the questionnaire experience, scoring interaction, outcome states, and post-gating onboarding.
The challenge: How do you filter a community without making anyone feel judged?
02 The Approach
Two approaches we rejected first.
Location-based gating
Gate by residential address, a proxy for affluence that needs no questions and no user effort.
Why we dropped it: too many false positives. Plenty of 50+ Indians are staying at their children's addresses in Bangalore's better complexes. They live somewhere else entirely. We'd have been reading the wrong signal confidently, which is worse than reading no signal at all.
Token payment in exchange for a gift
Charge a small amount, send a welcome kit. One move gives you three things: proof of intent, proof of payment capability, and a verified address.
Why we dropped it: two constraints, both real. The product didn't yet have enough pull to justify asking for money at the door. And ops couldn't fulfil physical deliveries at any volume.
What this left us with: questions. Which is the approach with the highest experiential cost because now the user knows they're being assessed.
03 Research & Evidence
The rule that shaped every question
If we were going to ask, every question had to earn its place. So we set one constraint:
Every question must give the user something back, stated at the point of asking.
Not a privacy notice. A reason they'd actually want to answer.
we ask
What the User gets
Where did you study?
"We'll help you find your batchmates and alumni on Marzi."
How often do you travel?
"This helps us connect you with travel companions."
How do you pay for experiences?
"Helps us unlock perks and offers that matter to you."
When were you born?
"We'd love to wish you on your special day."
The second constraint was neutrality. No answer a reasonable person might give could be penalised for the wrong reason. A homemaker isn't a low-affluence signal but a career-framed question makes her one. So we moved the affluence proxy to education, where the same trap doesn't exist, and wrote a "No, I learned through life and work" option that reads as legitimate rather than as a shortfall.
Five questions, one per screen, roughly four minutes.
04 The system
The scoring decision
This is the part I'd defend hardest, because it's the least intuitive.
We could have built a model that ranked users finely by affluence. We deliberately didn't.
What we scored for:
Not to identify the top of the community. Not to bucket users by affluence. Only to keep out people we were certain didn't belong.
Four binary signals: education, social frequency, device tier, digital payment comfort. Sixteen possible combinations. Score 2 or above and you're in.
Why equal weighting: we had no evidence yet that any one signal correlates more strongly with fit than another. Weighting them differently would have been a guess wearing the costume of a model. Equal weights are honest about what we didn't know, and the plan is to adjust them from observed behaviour rather than assumption.
The trade-off: this model lets in more marginal users than a stricter one would. We took that deliberately. A false negative is a 60-year-old who was right for this community and got told no. A false positive is a slightly-off member who the community itself will sort out. The costs aren't symmetrical, so the threshold shouldn't be either.
05 Decision Making
Four decisions worth naming
Waitlisted, never rejected
There is no rejection state. Users who don't pass are waitlisted, shown live community activity, a referral path, and an Instagram link.
The waitlist isn't a queue. It's a word. Anyone on it can get in immediately with a referral from a member.
Why: rejection from a community lands differently than rejection from a product. This user is 50+, was curious enough to complete five questions, and is being told they don't belong somewhere. The design job was to make an outcome true without making it feel like a verdict.
Referral overrides the score entirely
A referral bypasses scoring completely, the only hard gate that survives it is age.
Why: any scoring model built on four proxies will be wrong about real people. A member vouching for someone is a stronger signal than anything the questionnaire can capture. Rather than tuning the model to catch every edge case, we built a human escape hatch and let it carry them.
Progress without numbers
The progress indicator uses milestone language, "Getting started," "Understanding you," "Almost there." Never "Step 7 of 12," never percentages.
Why: a count turns a conversation into a form. And for a user who's uncertain whether they'll pass, a visible countdown to judgement is the wrong feeling to build.
Guidance on action, not on a schedule
Post-gating coachmarks trigger on what the user does, not on day one or day three.
Why: a day-based schedule assumes a shared pace. In a 55–70 cohort, some users are through the product in an hour and some take a week. Time-based tooltips reach the fast user after they've already worked it out, and the slower one before they need it. Action triggers reach both correctly.
06 The Design
What we designed to watch
The model is a first guess. It was built to be corrected, so the instrumentation matters as much as the questionnaire.
Drop-off per question: if one question loses significantly more people than the others, it's landing as offensive, not as difficult
Quarterly bias audit: acceptance rates across gender, age band, and occupation, with weights adjusted if a skew appears
Manual override rate: a high rate means the model is wrong, not that ops is generous
Relationship managers calling waitlisted users during the first weeks, specifically to find false negatives and fix the questions that produced them
Targets set at launch: 70%+ completion on the questionnaire, 60%+ of accepted users paying for an event within 90 days.
Locked for 30 days before any threshold changes, so early noise doesn't get treated as signal. First adjustments come from cluster weights, not from replacing questions.
09 Impact & Next Steps
What I'd carry forward
The user-facing-benefit rule did more work than any single design decision.
It killed weak questions during definition rather than in review, if we couldn't articulate what the user got, the question wasn't good enough to keep.
Designing for the wrong answer is the real job.
Most of the effort went into the state where someone doesn't get in. That's the outcome nobody wants to design and the one that determines whether they ever come back.
10K+
Downloads
4.4/5
App rating
50K+
Community Members
