Apni Kamai, Apna Hisaab
Delivery workers in India earn daily but can't read their own payslip. This app tries to fix that.
India's gig delivery workers earn daily but receive a payslip they can't read. Most of them don't know what was cut, why it was cut, or what they can do about it.
What we heard in the field
"14 order kiya, 1100 kama, lekin account mein 760 aaya. Bich ka paise kahan gaya?"
Ramesh, 28 · Zomato partner, Pune, 3 years
"Swiggy ne ek din ₹230 kaata. Call kiya toh bole equipment damage. Mujhe yaad nahi kuch hua tha."
Suresh, 34 · Swiggy partner, Pune, 5 years
"Weekly payout ka wait nahi kar sakta. Lekin instant mein fee laga dete hain. Dono mein loss hai mera."
Dinesh, 25 · Swiggy + Zomato, Pune, 2 years
Delivery partners need a way to clearly understand their earnings breakdown because the current opaque system erodes trust, creates financial anxiety, and leads to unclaimed disputes, even when workers have legitimate grounds.
7 interviews across two settings in Pune. 2 at a delivery hub, 5 with gig workers from Swiggy, Zomato, Porter, Zepto, and Blinkit. Not a single session in a meeting room.
2 interviews at a delivery hub in Pune. Workers approached between orders, in their actual environment.
5 interviews with active delivery partners across Swiggy, Zomato, Porter, Zepto, and Blinkit. All based in Pune.
Reviewed earnings screens of Swiggy, Zomato, Porter, Zepto, Blinkit, Uber Eats, and EPFO. Audited: deduction labelling, dispute access, language, and payout clarity.
Asked all 7 participants to share screenshots of their recent earnings screens. Analysed what information was shown vs. what was hidden.
Same audit across all 5 platforms. Every participant used at least 2 of these.
| Platform | Deduction label shown | Explanation provided? | Hindi / regional language? | Dispute access from earnings? | Taps to dispute |
|---|---|---|---|---|---|
| Swiggy | PLAT FEE, TDS, EQ | ✗ None | ✗ English only | ✗ Help Centre → 4 levels deep | 6+ |
| Zomato | Comm., Ins., ADJ | ✗ None | ✗ English only | ✗ Support → raise ticket | 5+ |
| Porter | Deduction | ~ Tap to expand (English) | ✗ English only | ✗ Not accessible from earnings | 7+ |
| Zepto | Platform charges | ✗ None | ✗ English only | ✗ App store review or email | N/A |
| Blinkit | Commission, TDS | ✗ None | ✗ English only | ✗ Help → Earnings issue form | 5+ |
| KAMAI (this design) | Swiggy कमीशन, बीमा, बैग किराया | ✓ Plain Hindi explanation per item | ✓ Hindi Devanagari throughout | ✓ On the deductions screen itself | 1 |
What the research actually said, not what we assumed going in.
82% of workers speak Hindi/regional languages at home. English financial terms (IMPS, NEFT, deductions, disbursement) caused active confusion in all sessions.
Workers don't just not understand. They actively suspect being cheated. Suresh said Swiggy cut ₹230 and told him it was equipment damage. He didn't believe it. He just couldn't prove otherwise.
Multiple workers had physical notebooks on their bike seat with their own delivery count written down. They'd compare it against the app at the end of the day. One participant counted on his fingers while I watched. They don't trust the number the app gives them, so they make their own.
Dinesh said he can't wait for the weekly payout but the instant option charges ₹5 every time. He said "dono mein loss hai mera," both options cost him something. The unpredictability of when money arrives wasn't abstract stress. Raju had rent due. Suresh was sending money home.
Workers are aware disputes exist but none of the 7 people I spoke to had ever raised one. The process requires navigating 4+ screens of English UI that assumes literacy and documentation.
Honest gaps in our research - questions we couldn't answer within the 8-week scope:
The user Raju Bhai's persona doesn't cover. Exists to stress-test the design's assumptions about literacy, age, and tech comfort.
Design questions that framed every screen decision.
Each one started as something a participant said or did. None of them started as a principle.
Every label was written in Hindi or Hinglish before I touched layout. Not translated after. Written first. In mid-fi testing, "Kitne Kaat Liye?" got immediate recognition from 4/5 participants. "Deductions" got 1/5. The screen name is a design decision, not a copy task. I had to learn that by doing it wrong first.
Every worker I spoke to in research was doing their own mental count: orders completed times per-order rate, minus whatever the app showed was cut. They were auditing the app in their head because the app never showed its working. The design had to show gross, then each deduction by name, then net. Not as an accounting table. As a plain explanation. Ramesh said in Week 7 testing that he finally understood why ₹153 was cut. That was the point of this principle.
Dinesh had a cracked screen. One participant had text scaling set to 125%. Another had data saver on, which blocked custom font loading. These aren't edge cases. This is just what phones look like after two years of delivery work. Every screen was checked on a Redmi 10C, not a current-model iPhone. Two layout bugs were found that way and fixed before handoff. They would never have appeared in Figma.
In research, none of the 7 workers I interviewed had ever raised a dispute. The button existed on every platform. It was just buried inside Help Center, behind three screens of English. By the time someone found it, the emotional charge from the suspicious deduction had faded or they'd given up. Moving dispute to the deductions screen, at the exact moment a worker sees a number they don't understand, changed 0 disputes in testing to 3. Same workers. Same frustrations. Different placement.
7 interviews in Pune: 2 at a delivery hub, 5 with gig workers across Swiggy, Zomato, Porter, Zepto, and Blinkit. Competitive review of all 5 platform earnings screens.
Affinity mapping, persona creation, HMW questions. Synthesizing 7 interviews into 5 core design challenges.
5 IA iterations, paper wireframes tested with 3 workers at the hub.
Figma mid-fi. Wrote all copy in Hindi before building screens. It took longer than the screens did.
5 delivery partners, their own phones, same delivery hub in Pune where the research started. Not a lab.
Rebuilt payout screen from scratch, not patched. Polished all 8 screens, final round of testing.
The results are in the metrics section. This is about what I decided before anyone sat down, and why.
Three rounds. Each one had a specific question it was trying to answer, not just "does this look good."
Before opening Figma, I drew 3 rough wireframes on paper and took them to a delivery hub. Boxes and labels, nothing else. The question was simple: does this person look for their earnings where I think they will?
What happened: They scanned bottom-up, not top-down. The big number had to be the first thing they saw. This changed the whole dashboard layout before I'd touched Figma.
I wrote all the Hindi copy before this round, not after. The screen name is a design decision, so it had to be tested at the same time as the layout, not retrofitted later.
What happened: "Kitne Kaat Liye?" worked immediately for 4/5. The payout screen failed badly. 3/5 couldn't find the free option. NEFT and IMPS meant nothing to them.
I rebuilt the payout screen from scratch between rounds. Not tweaked. By the time hi-fi testing happens, structural decisions should already be settled. This round was for confirming the rebuild worked and catching smaller friction: tap targets, contrast, real-device rendering.
What happened: Task completion 63% to 94%. Comprehension 2.1 to 4.6. Also found one card with a tap target below 44px on Ramesh's Redmi 10C. Fixed before handoff.
Think-aloud is a good default. But it needed adjusting for this audience.
These workers are naturally verbal. They use WhatsApp voice notes all day, they call dispatch, they talk to each other at the hub. When something confused them, they said it out loud. "Yeh kya hai?" I didn't have to prompt it. Think-aloud surfaced not just what they tapped but why they stopped.
For the deductions screen specifically, I switched to retrospective probing. Let them read it in silence first, then asked "ab batao, yeh kyun kata?" If I asked them to narrate while reading, they had to process and speak at the same time. That's unfair. First impression was more important than live commentary.
If someone was stuck and quiet for 60 seconds, I asked: "Aage kya karoge?" Not "try tapping here." Not "look at this button." Just: what do you want to do next? Naming the solution poisons the result. All sessions where I had to intervene were logged as incomplete, regardless of what happened after.
I moderated in Hindi, not English. If you ask a question in English and they answer in Hindi, they've translated twice. You lose the raw reaction. The hesitation, the "aaah samjha," the moment something clicked or didn't, all of that comes through clean when you're not making someone switch languages mid-thought.
Pass/fail tells you if it worked. These tell you why.
These aren't rules from a textbook. They're things I learned the hard way on this project or carry from working with non-default users.
A worker checking earnings between orders on a street corner is not the same person sitting in a quiet room with you. The noise, the interruptions, the phone brightness at 40% because the battery's low. Those aren't distractions to eliminate. They're the test. We ran sessions at delivery hubs and in parking lots. If it worked there, it worked.
When the payout screen failed, I wanted to just rename the labels. That would have been faster. But the structure was wrong, not just the words. Patching would have kept the broken frame and added better furniture to it. The rule I use: if 3 or more people fail the same task, the screen needs to be rethought, not edited.
I didn't show participants how the app worked before asking them to use it. No "let me give you a quick tour first." The first time they saw each screen was the test. That's how they'll encounter it in real life too, with no researcher standing next to them. If the screen needs explaining, it's not done yet.
When someone went quiet on a financial screen, my instinct was to prompt. I made myself wait. Silence here often meant fear, not confusion. Fear of tapping the wrong thing, losing money, getting their account flagged. A person staring at the dispute button without touching it is telling you the design hasn't felt safe yet. That's data.
With notification badges and low storage warnings and text scaling cranked up and data saver on. Not a clean test device. Not on my laptop. These aren't confounds to control for. They're just the phone. A design that breaks under normal phone conditions hasn't been tested. It's been previewed.
The comprehension baseline of 2.1/5 was measured in Round 1, not before. Which means it already includes the effect of seeing any structured screen at all. The real baseline would have been testing against the existing Swiggy/Zomato earnings screen before I built anything. I didn't do that. Next time I will.
Every color, typeface, and component exists for a reason tied directly to the research. Orange means money earned. Red means something needs attention. Green means free, safe, confirmed. The system does not deviate.
Three fidelity stages. Each one tested before moving to the next. The copy was written at mid-fi, before the visual polish, not after.
These are not aesthetic preferences. Each one is a direct response to something a worker said, a test that failed, or a constraint that mattered.
The first screen a delivery worker sees after a hard day needs to feel like a win, not a spreadsheet. Orange is the color they already associate with Swiggy and Zomato. Earnings, energy, action. Putting the daily number inside it creates an immediate emotional payoff.
The same number framed two ways produces entirely different emotional responses. Showing what was taken focuses attention on loss. Showing what remains builds a sense of ownership. This reframe is the entire premise of the deductions screen.
Screen names are not labels. They are the first signal of whether the app speaks your language or a bank's language. Every screen name was A/B tested in mid-fi with at least 3 workers before being finalized.
None of the 7 workers I interviewed had ever raised a dispute. Not because they didn't have grounds. Because the button was buried 4 screens deep in a help center written in English. Moving it to the exact moment of discovery is the entire fix.
The original lo-fi had a bottom navigation bar with 5 tabs. Workers in testing ignored it. They navigated by tapping large visible tiles on the dashboard. The 2x2 grid with sub-labels replaced the nav bar entirely. Cognitive load dropped. Task time dropped.
The original design had a 3-screen onboarding walkthrough. In mid-fi testing, 4 out of 5 workers swiped past it without reading. So it was removed entirely. If the interface needs a tutorial, the interface isn't done yet.
Every other design decision flowed from this one. I built the wireframes before writing the Hindi copy. When the copy arrived, every screen had to be redesigned, because "Kitne Kaat Liye?" is not the same shape as "Deductions." For this audience, the words are not filling a box. The words are the design. I won't make that mistake again.
अपनी कमाई, अपना हिसाब
First impression. Sets the expectation that this app is different - it talks like you, not like a bank. Three simple promises in plain Hindi. No jargon on the very first screen.
आज की कमाई
The heart of the app. Orange header shows today's earnings with zero ambiguity. Three quick stats plus a weekly chart give instant financial context. Everything above the fold answers the one question workers ask every day.
कितने काट लिए?
The most important screen. Every deduction gets a plain Hindi explanation. A visual bar shows what percent is "yours". The dispute button is always visible - not buried in a help center four clicks away.
पैसे कब मिलेंगे?
V2 after usability testing. "Abhi Lo" vs "Monday Ko" - clear choice, clear tradeoff. No IMPS/NEFT jargon. Task completion went from 63% to 94% after the redesign. The fix was entirely in the language, not the layout.
हफ्ते का हिसाब
A comprehensive weekly summary that lets workers understand trends over time - not just today's number. Best day highlighted, deductions summarized plainly. Workers often lose track of which week they're in, so dates are always shown.
कुछ गड़बड़?
Proactive alerts for unusual deductions - the moment workers can actually dispute is when they find out, not days later. The same space also celebrates wins like bonus unlocks and payout confirmations - positive reinforcement built in.
But one screen broke completely in testing. Here is what happened, why it failed, and what it took to fix it.
In Week 7 usability testing, 3 out of 5 workers couldn't identify the free payout option. They confused NEFT and IMPS (never heard these terms). The screen was rebuilt from scratch, starting with the question: "What do workers actually need to decide?"
Every number in this section comes from two structured usability rounds. Here is the exact setup.
Week 5 on mid-fi Figma prototypes. Week 7 on hi-fi after the payout screen was rebuilt from scratch. Same 5 delivery partners both times. Using the same cohort was a deliberate choice: it gave a direct before/after reading on the same people, rather than comparing two different groups.
All 5 were active delivery partners in Pune, recruited at the same hub where I'd done the initial research interviews. Platforms included Swiggy, Zomato, and Porter. Each session was 45 to 60 minutes.
Sessions were on participants' own phones. Ramesh had a Redmi 10C with data saver on. Dinesh had a cracked screen. That's not a problem to work around. That's the actual environment.
Think-aloud protocol throughout, conducted in Hindi and Hinglish. If someone was stuck for over 60 seconds, I asked "aage kya karoge?" and nothing more. Any session that needed a prompt was logged as a task failure.
Task Completion: binary. Pass means completed without any prompting. Fail means needed a hint, gave up, or got it wrong. No partial credit.
Comprehension Score (1 to 5) applied to the deductions screen only. After the task, I asked: "Ab batao, yeh kyun kata?" Scored on what they could explain:
All metrics from n=5 moderated usability sessions, Pune, Weeks 5 and 7. Directional only, not statistically significant.
The metrics tell you what changed in testing. This is what that change means for a real person.
Ramesh had been doing this job for 3 years. He'd never understood his payslip. When he saw the deductions screen in Week 7 and said "pehli baar samjha," that wasn't a comprehension score improving. That was three years of low-level suspicion about being cheated, clearing. The original problem wasn't just that workers couldn't read the screen. It was that they assumed the opacity was intentional. Comprehension going from 2.1 to 4.6 is the UX measure. "Ab mujhe kisi se poochna nahi padega" is what it actually means.
When he saw the payout screen in Week 7, his reaction was "Monday free hai? 3 saal se ₹5 deta raha." He'd been choosing instant payout every time because he didn't know a free option existed. At ₹5 per withdrawal and roughly 3 withdrawals a week, that's around ₹780 paid in avoidable fees over 3 years. That's not a UX improvement. That's a specific person's money that a clearer screen could have saved.
In research, none of the 7 workers I spoke to had ever raised a dispute, even though most of them remembered at least one deduction that felt wrong. In Week 7, Vikram tapped dispute during T3 and said "darr nahi laga." It didn't feel scary. The button moved from 4 screens deep in a help centre to one tap from the alert. That's not a UI change. That's access. The process existed before. Workers just couldn't reach it.
This wasn't about making a prettier earnings screen. The information gap between what platforms know and what workers know is not accidental. Every design decision that helped a worker understand their earnings, find the free option, or feel safe tapping dispute, moved some of that information back to the person it belonged to. The task completion rates and comprehension scores are proxies for that. The actual measure, how many disputes get raised, how much money stops going to avoidable fees, whether the trust holds over time, that only comes from a live pilot.
"Yeh screen dekh ke pehli baar samjha main, kyun ₹153 kata. Ab mujhe kisi se poochna nahi padega."
"Monday free hai? Main abhi tak instant le raha tha aur ₹5 deta raha. 3 saal se!"
"Jo alert aaya, main dispute button daba diya. Pehli baar. Pehle darr lagta tha."
Not a balanced list. Just what's true.
I almost didn't. It felt unnecessary. But the delivery hub at 11pm is completely different from 2pm. Workers are tired, they're checking phones fast, the lighting is bad. One participant had his phone brightness at maybe 20% to save battery. That changed how I thought about contrast on the deductions screen. I wouldn't have known if I'd scheduled afternoon interviews.
Writing "Kitne Kaat Liye?" took longer than building the whole deductions screen. I rewrote it four times. At some point I felt like I was overthinking a label. But 4/5 people understood it immediately in testing and none of them understood "Deductions." So it wasn't overthinking.
My instinct was to just show V2 and mention V1 briefly. But the V1 failure is the most honest part of this whole project. Three people couldn't find the free option. That's a bad screen. Showing it broken, with the actual test feedback on it, felt uncomfortable. I think that discomfort is what makes it worth showing.
This is the thing I'd undo most. I had all these mid-fi screens ready and then sat down to write the Hindi copy and realised nothing fit. "Kitne Kaat Liye?" doesn't fit in a box sized for "Deductions." The whole layout shifted. I redesigned six screens I'd already spent a week on. Next time I'm writing every label, heading, and body copy before I open Figma.
I recruited at delivery hubs and everyone I spoke to had basic reading ability. That wasn't a deliberate choice, it just happened. But it means I have no data on what this app looks like for someone who navigates entirely by icon and colour. Shyam Kaka's persona is me trying to think that through, but it's not the same as actually testing with him. I don't fully know where this design breaks for lower-literacy users.
The deduction explainer feature assumes I can access the actual deduction logic from Swiggy or Zomato's API. I don't know if that's possible. It might be locked behind partner agreements. Some of what I designed might just not be buildable. I kept telling myself that was a product problem, not a design problem. But that's a convenient way to avoid a hard conversation I should have had earlier.
7 interviews and 5 test sessions in Pune is not 5 million workers across India. The comprehension scores improved. The disputes got filed. But Ramesh is 28, speaks Hindi, has 3 years of experience with the app, and was willing to sit with me for an hour. There are workers who are 50, speak only Telugu, just started last month, and have 10 minutes between deliveries. I don't know if this design works for them. That question is unresolved and I think it should stay that way until there's a real pilot.
More work
← Return to the Gallery