01 — Context & Problem
A founder built an audio data marketplace. I was brought in to
design the mobile experience for the people who'd actually use it.
Feul.AI was an early-stage startup building an audio data marketplace for Indian AI teams — similar in
concept to companies like David AI but focused on Indian languages and regional dialects. The
founder and a small dev team had built a desktop web MVP. I was brought in to design the end-to-end
mobile experience for contributors and validators: the two user types the entire supply side depended
on.
What was broken in the existing product
The desktop MVP worked as a proof of concept — contributors could sign up, pick a task, and submit
a recording. But it was built to validate the idea, not to retain the people doing the work. Three things
were missing:
—
No
payout
system.
The MVP had a recording mechanism but no live earnings display, no wallet, no withdrawal
flow. Contributors had no visibility into what they'd earned or when they'd be paid.
—
No mobile
surface.
India's gig workforce is Android-first. A desktop web product wasn't reaching the people Feul needed to recruit — students, regional workers, dialect speakers in Tier 2 and Tier 3 cities.
—
No reason
to return.
With no earnings feedback, no status updates on submitted clips, and no progression visible
to the user, there was nothing pulling contributors back after their first session.
The founder's early plan for payouts was to pay contributors directly per recording while the platform
was small, then build something more structured once funding came through. That plan had a
compounding problem: without a clear pay structure in the UI from day one, contributors had no way
to evaluate whether the platform was real — and Indian gig workers have seen enough fake earn-
from-home apps to make that evaluation fast and unsympathetic.
What the product is
Contributors complete short audio tasks — called Quests — and earn per validated submission.
Validators review recordings for quality before anything ships to the buyer. Quest Creators fund
campaigns and receive structured datasets. Payout per clip isn't fixed — it depends on the Quest
Creator's budget, language rarity, and task complexity.
Design implication: Better copy doesn't fix a trust problem. Trust has to show up in what's visible — earnings
shown upfront, submission status updated in real time, controls the contributor can actually use.
The problem to solve: If contributors don't trust how they're paid, they don't come back. And without
repeat contributors, the marketplace collapses.
FOunder’s product ideology
02 — Who We're Designing For
Two different users. Both making a trust decision in their first
session.
The MVP gaps pointed to two distinct user types with different trust needs. The contributor needs to
trust the pay. The validator needs to trust the tool. Design decisions that solve for one can undermine
the other — so they need to be understood separately.
The Contributor — The Earner
Students, regional creators, gig workers. Android-first, Tier 2 and Tier 3 cities. Most have used earn-
from-home apps — survey platforms, microtask tools — that paid in vouchers or points with high
redemption thresholds. That history sets their bar for trust before they open anything new.
When they open a new app, the evaluation takes about three minutes and runs three checks:
—
What's on the quest cards — is the number a rupee amount or a points score?
—
What the wallet tab is called — "Wallet" means money, "Rewards" means game
—
Whether a withdrawal screen exists and is findable without digging
If those pass, they stay. If any fail, they close without saying anything. When it works, what they tell a
friend is: "It's actual rupees, straight to UPI." That sentence is the entire product promise. Every
decision in this case study is trying to earn it in the first session.
What they need: Earnings in rupees before they start. Payout within a timeframe they can hold on to.
Control over where their voice data goes.
What breaks them: A withdrawal threshold they didn't know about. A rejection with no reason. Points
instead of rupees. Any of these — and they leave without saying why.
Design response: The payout amount, task length, and withdrawal path must all be visible before the first clip.
Quest cards show ₹ first. The wallet shows pending earnings — not just credited ones. The Data Vault in Profile
shows exactly which datasets carry their voice.
The Validator — The Quality Gate
Rajan, 26. Commerce graduate, Pune. Started as a contributor — eight weeks of morning recording
sessions before his part-time shift. Applied to validate after roughly 180 clips. Grades 40–50 clips in a
sitting, 7am to 9am. Treats it like a second job, not a side hustle.
What burns him out on bad grading tools isn't the volume — it's that they never get easier. The failure
chain on a poorly designed interface:
—
Reading a label on every clip keeps cognitive load flat from clip 1 to clip 50
—
Fatigue at clip 40 means worse judgments than at clip 10
—
Worse judgments → accuracy score drops → pay drops → reason to stay drops
The grading tool isn't a feature — it is the job. It has to be worth showing up for.
What they need: An interface that gets faster with practice. Accuracy feedback that's actionable. Pay
tied to quality, not just clip count.
What breaks them: A grading tool that stays equally slow regardless of experience. Accuracy scores
that drop without surfacing why. Feeling like a replaceable cog.
Design response: Accuracy is the first number on the validator home screen — above earnings. The grading
interface (horizontal segmented control) builds positional muscle memory after ~10 clips. Accuracy streak bonus
is visible on the home screen, not buried in stats.
The Quest Creator — The Demand Side
AI startups and research labs who need datasets without managing the human infrastructure. Their
trust comes from delivery reliability, not UX polish. They're the background constraint throughout this
case study — not the focus.
The shared insight across both user types: Both the contributor and the validator are making a trust
decision in the first session — one is deciding whether the platform will actually pay them, the other
whether it will actually respect their time. The design's job is to give each of them something
concrete to trust before that session ends. Everything else follows from this.
Wireframes
Some initial wireframe ideation with AI
03 — The Wrong Assumption
The MVP gaps were clear. The obvious fix turned out to be wrong.
With no return loop and no earnings visibility identified, the first instinct was the predictable one: layer gamification on top. Points, streaks, levels, a rewards hub. Quest cards led with "⚡ 150 pts" and the rupee equivalent in smaller muted text underneath. It felt like a reasonable approach to retention.
Early designs & points base quest concept
This was my first approach of gamification - points, streaks, levels and a rewards page
Then I looked more closely at what actually causes drop-off in Indian gig platforms specifically. The
finding changed the direction entirely.
The finding: It's not low pay that causes workers to leave — it's obscured pay. Workers can't see what
their labour is worth in rupees, so they assume something is wrong. They don't complain. They stop
opening the app.
What this meant for the design:
—
The missing return loop wasn't an engagement problem — it was a trust problem. Contributors weren't
returning because they didn't know if the platform had paid them fairly
—
Gamification on top of unclear compensation doesn't fix that — it buries the rupee number further and
makes the trust problem harder to diagnose
—
"1,5xx Points" as the hero number was pointing contributors toward the wrong question entirely
The right question wasn't "how do we make this more engaging?" It was: how do we make
contributing feel like a fair financial exchange from the very first clip?
Onboarding — Setting context before the first task
Brand proposition. Sets earning as
the mission.
What they're contributing and why
it matters.
The payout promise. Sets
expectation before they start.
04 — Payout Model
Before finalizing any flow, I needed to figure out how payouts
would actually work.
The UI sits on top of this — if the payout model is broken, good design can't fix it. I looked at three
approaches:
Model A — Direct UPI per clip
Pay the moment a clip is
approved. Fast and transparent.
Eliminated.
UPI gateway fees per micro-
transaction add up quickly. Not
practical once there are many
contributors.
Model B — Points first, cash later
Earn points per clip, convert to
INR above a threshold, batch
transfer weekly.
Eliminated.
Operationally simpler, but this is
exactly the pattern Indian gig
workers tend to distrust.
Model C — INR wallet ✓
Earnings accumulate as real INR
in the platform wallet. Weekly
withdrawal to UPI above a
threshold.
Chosen.
INR visible from clip one. Batch
withdrawals keep costs lower.
One problem remained.
Design response: The wallet shows a live earnings ledger with a status for every submission — Credited, Pending,
Effort Credit, Processing. The INR balance uses monospaced type to feel more like a real number and less like a
game score.
This works if contributors actually check the wallet — if they don't, the transparency is wasted, which
session data would show.
The new user cliff — and how the tier system solves it
Model C has one problem: a ₹500 withdrawal threshold means a new contributor completes many
clips before seeing a single rupee move. That's a retention cliff at exactly the wrong moment.
Solution: threshold and cash ratio scale with contributor trust level. New users see money faster.
Established users get more of it in cash. This is how I'd structure it — the specific numbers would need
testing against real activation data.
Level
Threshold
Cash ratio
What changes
Level 1–2
New contributor
₹50 welcome bonus
Instant on first quest
60% INR
40% platform credits
Credits redeemable for
mobile recharge, grocery
vouchers
Level 3–4
Established
₹300
85% INR
15% XP multipliers
Priority quest access,
higher-value tasks unlock
Level 5+
High-reputation
₹500
100% INR
Clips bypass manual
validation — near-instant
confirmation
Design response: The new user wallet empty state doesn't show ₹0 — it shows a locked progress ring: "Unlock
your first ₹50." The Level Progress card on the home screen makes the tier system legible — what level you're at,
what the next unlock is, how far away.
The same tiering applies to validators — new validators grade alongside gold-standard calibration
samples, high-accuracy validators unlock batch priority and better rates.
The specific threshold numbers
(₹50, ₹300, ₹500) are design hypotheses — they'd need A/B testing against real contributor activation data
before locking in.
Something I'd add: a quality gate before first withdrawal. The current tier system assumes
contributors submit genuine work. Some won't — submitting random audio to unlock the welcome
bonus quickly is a real risk. A minimum number of accepted (not just submitted) clips before the first
withdrawal would help here. It's invisible to honest contributors but catches the obvious gaming early.
Something similar for repeat defaulters — routing them out of the active pool quietly, without a harsh
ban screen, would reduce noise without punishing the majority.
On fees: No platform fees on withdrawals at launch — deliberately. Every friction point in the first
withdrawal is a reason to churn. Once contributors are retained and active, a modest processing fee is
a post-PMF conversation.
Wallet balance and history
All earnings status
Wallet
Every submission has a live status — Credited, Pending, Effort Credit, Processing. Money is never in a black box.
Amount input - 1st step
Confirmation - 2nd step
Withdraw Initiated
Low Balance withdraw attempt
Wallet
Withdrawal flow (amount → review → confirmation) lives in the wallet, not buried in settings.
05 — Making Earning Feel Worth It
After fixing the payout model, the app communicated earnings correctly — but it still felt passive. You
had to already want to record. The design goal shifted: make it easier to get started, and give
contributors a reason to come back.
The approach: reduce friction at the start, show proof quickly, and give enough pull to open the app again tomorrow.
1
See earning opportunity
₹ amounts on quest cards.
Urgency tags. Time-sensitive
bonuses immediately visible.
2
Start instantly
One tap from home to recording.
Voice calibration quest pre-
loaded for new users.
3
Earn quickly
Auto-check gives immediate
feedback. Short quests available
as fast entry points.
4
See proof
Celebration screen with spring
animation. Wallet updates. Ledger
entry appears immediately.
5
Feel progress
Streak counter. Level progress.
Small visible signs that activity is
building up.
6
Come back again
Scarcity tags. Expiring bonuses.
Small nudges toward opening the
app again tomorrow.
The first earning experience
Old flow: onboarding → task list → pick one → wait for validation → maybe get paid. Five potential
drop-off points before any reward — a long way to go before a new contributor sees anything in their
wallet.
First Earning Flow — From hook to ₹ in wallet
First earning hook. The locked ₹50
becomes the goal.
Easy quick audio tasks.
Wallet updated before home
screen loads.
₹50 visible, next quest pre-loaded,
streak counter active.
New flow: onboarding → "Earn ₹50 in 2 minutess" → voice calibration → celebration screen → home
with ₹50 already showing. The calibration quest bypasses the validation queue and can't be failed.
The first session ends with money in the wallet.
Urgency tags: Tags like High Demand, Expires in 2h, and "14 slots remaining" reflect real information — Quest Creators do have budget limits, and some languages are genuinely in shorter supply. The goal is to surface that naturally without making every card feel artificially urgent.
Contributor Walkthrough
Ananya, 22. BSc final year, Nagpur.
She heard about Feul from a WhatsApp group — "record some sentences, get paid per clip." It's not the first earn-
from-home app she's tried. Survey and microtask platforms that paid in vouchers or points with high redemption
thresholds have set her expectations low. She's not hostile — but she opens the app already running the checks
she's learned to run: what's on the quest cards, what the wallet tab is called, whether a withdrawal screen exists.
She opens Feul with one question: is this real money? The screens below walk her from first open to ₹50 in the
wallet. Every design decision along the way exists to answer that question before she has to ask it.
The moment she almost dropped off — and the design decision that caught her
After her first few quests, Ananya checks the wallet. She has ₹38 credited and taps Withdraw — where she sees a
₹300 minimum threshold. This is the retention cliff. A ₹300 bar with ₹38 in the account doesn't feel like progress
— it feels like the same high-threshold pattern she's seen before. The number is different; the feeling isn't.
What keeps her: the Level Progress card on her home screen shows her current level, the current threshold, and —
specifically — how many quests away the next level is, where the threshold is lower. The problem didn't go away,
but it became a legible problem with a path through it.
What the onboarding was designed to do — and what was deliberately left out
The original founder spec had role selection as the first screen: Contributor, Validator, or Quest
Creator. I removed it — someone opening an earn-from-home app for the first time doesn't know
what a Validator is, and forcing a choice before they understand the product means they'll choose
wrong and land in an empty state they can't make sense of. Everyone enters as a Contributor.
Validator and Quest Creator are progressive unlocks in Profile.
Everything else cut from onboarding:
—
No feature tour
— features explain themselves when the user has a reason to use them
—
No permissions wall
— microphone permission requested at the moment of first recording, not before
The constraint: by the end of onboarding, she knows what she's doing, why it matters, and what she'll
earn. Nothing else. Three slides, each with one job:
Important before the First Earning Flow
Data Collection Consent Agree
Data Collection Consent
Recording tips
Recording tips
Profile creation after first earning activity
Name
Language Choices
Direct UPI information for
payout trust
WHY After ?
So that the new user is reeled in to create their account to claim their first earning. And the setup is just
three steps for fast onboarding while we fetch and attach user information to their UPI.
06 — Design Decisions
Five design decisions and the reasoning behind them.
01 — Wallet replaces Rewards in navigation
Swap Rewards tab for Wallet. Move XP and vouchers into Profile.
Information Architecture
Rejected
Home · Quests · Rewards · Profile — Rewards as a primary nav tab positions this as a
gamification platform. That's the wrong message for workers evaluating whether to spend
their time here.
Chosen
Home · Quests · Wallet · Profile — XP rewards and voucher redemption live in Profile under
"Perks & Multipliers," collapsed by default.
Turning point
Read "Rewards" again with the actual user in mind — a gig worker who's already been
burned by apps that turned out to be points and vouchers. The bottom nav isn't just
navigation. It's the product's first declaration of what it is. "Rewards" says game. "Wallet"
says money.
Tradeoff
Gamification is harder to discover. Navigation shows what the product prioritises —
showing Wallet as a primary tab signals that earnings come first.
Old Rewards hub
Rewards available through profile
New XP Rewards Hub
Rewards Screens
02 — INR is always the first number
₹ appears first, larger, darker. XP appears second — smaller, muted —
everywhere.
Display Logic
Rejected
"⚡ 150 pts (≈ ₹15)" — the original pattern. Points as the headline, rupees as the footnote.
This tends to make the platform feel more like a game than a place to earn money.
Chosen
₹15 in accent green, prominent. +150 XP in muted text, smaller. Consistent across quest
cards, wallet, post-submission screens, and the onboarding earning hook.
Turning point
One question looking at the original layout: who is this hierarchy designed for?
Contributors don't leave because the number is too low — they leave because the first
number isn't the one they care about. Flipping it was the simplest expression of what the
platform actually is.
Tradeoff
XP loses visual surface area. Gamification motivates retention, but it shouldn't compete
with the rupee amount for a contributor who's deciding if this is worth their time.
Hero card — ₹ dominant
Wallet Balance
₹50.00
Available to withdraw
Credited
Voice Calibration — Welcome Bonus
+₹50.00
Quest card — ₹ first, XP secondary
03 — The grading interface for Validators: six methods evaluated
Validators grade 40–50 clips per session. The grading control is the most-used interaction in the
product. I looked at several approaches and tried to pick one that would get easier with practice rather
than staying equally effortful every session.
all methods evaluated
Binary Accept / Reject
Out
Fastest. Loses all nuance —
minor noise gets the same
rejection as an unusable clip.
Dataset loses the granularity
Quest Creators need.
Star Rating 1–5
Out
Stars carry restaurant-review
connotations. Validators anchor
on 3 as "average" regardless of
audio quality. Wrong mental
model for audio QC.
Swipe Gesture
Out
Binary in practice. Nuance
requires complex gestures.
Swipe-heavy on mid-range
Android causes accidental inputs
on QC-critical decisions.
Keyboard Input 1–5
Out
Fast for experienced users. Can be full eyes off the screen experience but not viable for a mobile interface unless a blackberry phone or maybe a future adoption for tablets with accessories like keyboard.
Vertical Radio List
Out
The options forces to scroll down the screen thats extra friction just to give a high rating. Can result in higher negative ratings. Cognitive load stays constant regardless of experience — never gets faster. This was the original design.
Horizontal Segmented
Control
Chosen
5 positions, red → amber →
green gradient. Labels as legend
below, not on the bar. Builds
positional muscle memory after
~10 clips — gets easier with
practice in a way the other
options don't. Then the submit
button went too.
Why: Mapping a full validator session — 40 clips, each requiring a grade — made the compounding
problem visible. Every friction point doesn't cost once, it costs 40 times. The question that changed the
direction: what if the grading tool could get easier with practice? After roughly 10 clips with the
segmented control, the validator stops reading labels and taps by position. Clip 40 is
faster than clip 1. No other option in the evaluated set had that property.
Submit button removed: One tap grades and the screen moves to the next clip. Validators aren't
making irreversible decisions — a consensus model can flag outliers. A short undo toast covers
accidental taps. It removes one step from every clip.
Finalised method:
Segmented Control
Method : thumb arc
Method : Labelled Pills
Method : Keyboard Grade
Method : Binary + Flag
Grading Methods
Five grading variants explored. The horizontal segmented control was chosen because it builds
muscle memory with practice — useful when validators are working through large batches.
04 — Validator and Quest Creator as aspirational tiers, not default roles
Remove role selection at onboarding. Gate Validator and Quest Creator
behind application forms in Profile.
Product Structure
Rejected
Role selection at start — "Are you a Contributor, Validator, or Quest Creator?" Forces a
decision before the user knows what any of those mean. Three separate flows, three
separate empty states.
Chosen
Everyone enters as a Contributor. Profile → "Grow with Feul" section contains two
application entry points: "Become a Validator" (form: languages, availability, experience)
and "Are you a company looking for audio data?" (form: company, campaign volume,
languages needed).
WHY
—
Mapped the role-selection screen and hit the empty state problem immediately
—
Validator selected without contribution history → blank grading queue. Quest
Creator selected without context → a form they don't understand
—
Role selection was branching into three separate products at the exact moment
the user knows the least about any of them
—
Deeper issue: why would a validator be good at grading? Because they've
recorded and know what makes a clip usable
—
Making Validator an applied role after contribution experience isn't just a UX
decision — it's a data quality decision
Why it works
Contributors who've recorded before tend to grade with more context for what's hard to
get right. And making Validator an applied role makes it feel more considered — both for
the person applying and for the platform accepting them.
Role Progression — Application Forms & Profile Tier CTAs
Applications on Profile page
& Data Vault
Language skills, hours available,
why you want to validate
Company details, campaign
volume, expected data volume
Validator Application Submission
Quest Creator Application Submission
05 — Data Vault: consent that stays accessible
Consent lives in the profile. Contributors can see and revoke it per dataset —
without contacting support.
Ethics / Trust
Rejected
Consent checkbox at onboarding, ticked once, inaccessible afterward. The norm for most
data collection platforms — and the reason contributors don't trust them with their voice
long-term.
Chosen
Data Vault in Profile shows every dataset a contributor has contributed to, with consent
status per entry and a per-dataset "Revoke Consent & Delete Data" CTA. Persistent, not
historical.
Honest gap
The moment before first recording — when contributors should understand what their
voice will train — is a principle here, not a built screen. First thing to build in a real sprint.
Another gap
Contributers will be charged back the amount they received for that data with a fine or else
majority will keep deleting their data after earning.
06 cont. — Validator Design Decisions
The validator experience matters as much as the contributor one.
The quality of the data a Quest Creator receives depends entirely on how validators do their job. Validators can’t be treated secondary. A few decisions shaped how this works.
Validator — Dashboard & Profile
Accuracy primary, earnings below,
streak bonus visible
Batches by language and priority
Accuracy trends, badges, earnings
06 — Accuracy score leads the validator home screen
Accuracy is the first number shown — above earnings, above clips graded.
Hierarchy
Rejected
Earnings hero card first, accuracy as a secondary metric below. Mirrors the contributor
layout. Creates a consistent design but the wrong message — it tells validators their job is
throughput, not quality.
Chosen
Accuracy score (e.g. 94.8%) is the primary number. Earnings and clips graded appear
beneath it. The idea is that leading with accuracy helps reinforce that quality is the main
thing being measured.
Why it matters
Validators who feel measured on throughput tend to rush. Rushing leads to inconsistent
grades. Putting accuracy first on the home screen is a small nudge toward the right
behaviour.
07 — Payout tied to accuracy, not just volume
Validator payout multiplier is accuracy-gated. Quality earns more than
speed.
Incentive Structure
Problem
Pay-per-clip rewards speed. But fast grading on subjective quality tends to be less
consistent. The dataset gets noisier over time, but the validator keeps earning.
Solution
Accuracy measured via consensus clips and gold-standard samples. High accuracy
unlocks a per-clip rate multiplier. "Accuracy Streak Bonus: +₹X active" is shown on the
validator home — visible enough to feel worth protecting.
This assumes validators don't game the consensus mechanism — which needs monitoring in early rollout.
Validator — Wallet
Validator Wallet
Validator Wallet payouts
07 — Visual & Interaction Decisions
A few notes on how the visual and interaction decisions were
made.
Every product decision has a visual counterpart. This section covers the hierarchy, color, component,
and interaction choices and why they were made.
Visual hierarchy
The key rule: ₹ always gets more visual weight than XP. Balance uses large monospaced type on a dark
navy card. Quest card earnings sit top-right in terracotta. XP and streak data use small muted grey —
present but not competing. This carries through the copy too — contributors "earn" rupees, they
"gain" or "unlock" XP.
Color system — every token has a job
Semantic Color Assignments
Ink Navy
#1A1F2E
Main
surface for
earnings
and status.
Not used
decoratively.
Terracotta
#C4622D
Money.
CTAs.
Positive
values.
Urgency.
Success
#1F6B3A
Credited.
Approved.
Confirmed.
Trust.
Olive
#6B4F00
Auto-check
passed. In-
progress.
Not yet
money.
Navy Blue
#1E3A6E
Under
review.
Waiting. Not
negative,
not positive.
Deep Red
#8B0000
Rejected.
Action
required.
Entry to re-
record.
Muted
#8896A7
XP,
timestamps,
metadata.
Lower
priority —
readable but
not
prominent.
The dark navy card (#1A1F2E) is used on contributor earnings, validator accuracy, and the celebration screen —
the same visual treatment across roles helps the app feel consistent even when the content changes. Differences
between roles come through in the content itself, not the colour.
Component system — quest cards, status chips, wallet entries
Quest Card — 3 Variants
Standard: White card, 1px border, ₹ top-right in
terracotta monospace. Title left, time + clips as muted
caption below.
Featured: Navy background, waveform texture, orange
arrow. Hierarchy signals "recommended" — no label
needed.
Urgent: Standard + urgency tags above title. Max 2 tags
per card — more causes tag blindness.
Scan logic: Eye enters left (title), exits right (₹). Time +
clips tell the user how much they're committing before
they tap.
Status Chips — 4 States
Auto-check passed: Olive/gold — promising, not
confirmed.
Under Review: Navy blue — neutral wait. Not negative.
Approved ₹X: Success green. ₹ amount in the chip itself.
Rejected: Soft red, tappable. Tapping it goes directly to
the rejection detail and re-record CTA — so a failure
message doubles as an entry point back into the flow.
All combos exceed 4.5:1 contrast — dark-on-light only.
Components in context
Quest Card Variants
Standard, Featured, Urgent side by
side
Wallet Ledger States
Credited / Pending / Effort Credit
/ Processing
Status Chips
All 4 chip states in the activity feed
Wallet Ledger Entry — 4 Variants
Credited:
+₹X
terracotta monospace. The + signals
gain at scan speed.
Pending: Grey, no + prefix. A promise, not a fact.
Effort credit: Olive-gold. Visually distinct — partial, not
failed.
Processing: Italic grey — in motion.
Primary CTA Button
Shape: Full-width pill, 56–62px. Confident, decisive —
not a link.
Glow shadow:
0px 8px 28px rgba(196,98,45,0.40)
.
Scale varies — larger on the First Earning CTA, softer on
wallet withdraw.
Disabled: Grey + glow removed. Visual energy
disappears with availability.
09 — States & Edge Cases
Where trust is actually built.
Happy paths are easy. These are the states where users decide if the platform is honest.
Activity feed — 4 chip states
Morning News Reading
Approved ₹15 credited
+₹15.00
Product Descriptions
Auto-check passed
₹25.00
Short Story Narration
Under Validator Review
₹50.00
Conversational Dialogue
Rejected — See reason ↗
States in context — contributor side
Reason shown, re-record CTA,
effort credit
Language filter CTA, not
abandoned
Locked ₹50 ring, not ₹0
States in context — validator side
Accuracy score visible even with
no work
Banner + local draft saved
Consensus Mismatch
10 — If This Shipped
What I'd measure — and what I'd build next.
First-session completion rate
Hook validation
% of new users who complete Voice Calibration and reach the "+₹50 earned"
screen. If this is low, the first earning experience isn't landing — and most of
the engagement design depends on that first moment working.
Day 7 return rate
Retention
Of contributors who completed at least one quest, what % come back within
7 days? A good first session that doesn't lead to a return suggests the
urgency signals and streaks aren't pulling people back the way they should.
Validator accuracy over time
Interface check
Is accuracy improving session over session for the same validator? If yes, the
grading interface is working. If it's flat or dropping, it might mean the
segmented control isn't building the consistency I expected.
Validator workload over time
Future direction
As the platform collects more validated data, it could train a model to pre-
filter obvious bad submissions — silence, wrong language, clipping — before
they reach validators. The idea: validators spend time on borderline cases, not
clear failures. This metric would track whether that's actually reducing the
noise in what they review.
11 — Reflection
What I'd do differently.
The scarcity signals — High Demand, Expires in 2h, limited slots — are meant to reflect real information, not create fake urgency. But I haven't tested whether a first-time contributor who's already skeptical reads them that way. That's something that would need testing before shipping.
Two things I'd want to add: a minimum number of accepted submissions (not just submitted ones)
before the first withdrawal unlocks, to prevent gaming the welcome bonus. And a way to quietly
remove contributors who consistently submit unusable work, without making it a visible ban for the
majority who are doing it right. The tiered thresholds are guesses based on retention logic, not real data.
Longer term, as validated data builds up, there's an opportunity to train a model to filter out obvious
failures — silence, clipping, wrong language — before they reach validators. The goal isn't to replace
human review. It's to focus it on the cases that actually need judgment.
Feul.AI — Making earnings clear, trustworthy,
and worth coming back for.
Feul.AI is a product design case study. Payout thresholds, tier structures, and economic models
described are design hypotheses, not validated product decisions. Gig worker earnings data sourced
from NITI Aayog Gig Economy Report 2022 and Economic Survey 2025–26.