the last question

Work slots and earnings

Work without a full-time commitment

With Flex, we wanted people to book packing shifts at Zepto without taking a full-time job. I designed the application, slot booking and earnings experience.

Someone had to get through the application before they could book work. Once they started working, they needed to understand what they had earned. The earnings card became a substantial design problem of its own because the amount depended on both picking work and minimum-guarantee eligibility.

We shipped the non-video onboarding. I also designed a video-led version, but video production and technical complexity delayed its implementation. The onboarding images below show that planned version. The earnings work follows the drafts through to the design we finalized.

Getting through the application

The planned onboarding paired a presenter with the task the applicant was completing. I kept the main flow to choosing a work arrangement, choosing where to work, submitting documents and arranging an interview. Detailed tasks such as the map and camera opened separately.

The planned video-led flow.

Choosing Flex needed more explanation than a selected button. I tried a compact comparison with earning expectations and a longer one with hours and work terms. The compact version left room for the presenter. The longer one put more of the explanation directly in the interface.

Location was a separate choice. Detecting the applicant’s current city was not enough because they could be applying to work elsewhere. I included manual city selection and let them choose up to three areas. Store distances and a map gave them information to make that choice. An unavailable city led back to city selection.

Recovering from an incomplete application

A document problem should not leave the applicant guessing which step to repeat. I used a checklist for the selfie, Aadhaar and PAN, with capture instructions before submission and a reason beside a failed item.

An unclear photo could be retaken. A duplicate document or an existing application needed a different response. Those cases could not all be handled by the same retry message.

Handing the application to the store

The application eventually needed a person at the store. The interview confirmation brought together the appointment, location, contact action and the OTP used for verification. The OTP was only available on the interview date.

After the interview, waiting for a decision was different from leaving a form unfinished. I separated that waiting state from the shortlisted state, where the applicant had a contract to review. The next instruction after accepting it explained the return to training.

A booking was not always a confirmed shift

A worker could choose a slot and still be on a waitlist. Calling both states booked without further explanation would hide that distinction. I kept the waitlist position visible and labelled confirmed slots separately. Future slots also needed to say when booking would open.

The store, hours and earning offer stayed with the slot so the worker could compare the work before booking it.

Explaining what someone earned

Picking earnings and minimum-guarantee eligibility were different things. A worker could earn from picking without qualifying for the guarantee. If they qualified, the guarantee established a floor rather than a second payment added in full.

For example, with a ₹100 guarantee and ₹45 in picking earnings, qualification would add ₹55. If picking earnings already exceeded ₹100, there would be no top-up. The card had to explain the amount without making the worker reconstruct that rule.

I wanted it to be a lone traveller that could tell its own story. Someone should be able to encounter the card without another person beside it explaining the rules. It also needed a consistent identity that they would associate with earnings.

That gave it a specific job. Start with the offer or amount earned, explain the condition that applied, show progress and provide the full rates and payout timing. The drafts below explore ways to do this. Their amounts and thresholds are illustrative and sometimes inconsistent. They document design work rather than production calculations.

A lock did not explain the amount

The oldest draft showed an earned amount beside a message saying the worker did not qualify for daily earnings. It was unclear what the failed condition actually took away. The money was still there.

Other drafts emphasized a zero or a locked-rewards message. Naming the reason for a lock was useful, but it still left the main question unanswered. How did that condition affect the money from work already completed?

Early workbench drafts.

Showing both calculations

I tried showing minimum earnings and picking earnings together, with the applicable amount highlighted. This made the comparison explicit. Once eligible, the worker got the higher amount.

The progress display was harder. Time determined qualification, while items determined picking earnings. I tried connecting each calculation to its own progress section. Across the variants, the bar could mean time in one place and items in another. Combining the two calculations had introduced another distinction to explain.

Treating it like a bill

A simpler branch used rows for picking earnings, the guarantee and the total. The picking row could expand to show progress. This kept the calculation visible without requiring the progress graphic to carry the whole explanation.

I also tried expressing the guarantee as a top-up. In the example below, ₹140 from picking and a ₹60 top-up make ₹200. This explains what the guarantee adds, instead of asking the worker to compare two competing totals.

Collapsed and expanded workbench alternatives.

Should an unavailable rate remain visible?

The component needed a rate card for inspecting the offer and earnings cards for reporting a result. The result could be above or below the time threshold for qualification. That was separate from whether picking earnings were above or below the guaranteed amount.

I tried moving the condition into a ribbon, a badge, a tooltip and a separate explanation. Each placement changed how much of the rule was visible beside the progress bar. These were alternatives explored on the workbench, not a single sequence of improvements.

The time tabs exposed another question. Should someone who had not qualified still see the other rate? It might motivate them to qualify, but it also asked them to interpret a hypothetical amount beside what they had actually earned.

There was a smaller version of the same problem at the end of the bar. I tried “20+” to show how many checkpoints had been compressed. Was that count useful, or was an ellipsis enough? The full schedule was already available through Show Rates.

I made a lighter version to check whether the deep green and orange were adding unnecessary visual weight. The question was how much emphasis the card needed while the amount and its explanation remained readable. I also continued varying which states retained the tabs.

The lighter intermediate treatment.

What we finalized

The rate card kept both time tabs. Before work, comparing the two schedules was part of understanding the offer. The earnings card dropped them and explained the applicable result. This separated a question about what could be earned from a question about what had been earned.

We kept the lighter treatment and used an ellipsis without the checkpoint count. The amount led the card. The guarantee condition followed it, then progress, the full rates and payout timing.

Finalized rate cards above and earnings cards below.

Qualification and progress needed separate states

Two qualification states were not enough to describe every result. Someone could cross the time threshold and still earn below the guarantee from picking. Someone else could miss the threshold but earn above the guarantee anyway.

I worked through all four combinations. Below the guarantee, the explanation names the top-up or the missed condition. Above it, picking earnings already determine the amount. Qualification still has its own label.

The final four-state set with corrected progress.

Progress also needed to move on from the early checkpoints. The later states show the relevant completed milestones instead of keeping the initial locked levels on screen. The guarantee explanation and picking progress have different jobs even when they share the card.

Keeping the full calculation available

The compact bar could not show every rate. Show Rates opened the complete table, including the effect of the guarantee at each earning level. That let the card summarize progress without becoming the only place to verify the calculation.

Connecting the card to the earning history

A self-contained card still needed context. A weekly total alone could not explain which slot produced an amount or adjustment. The final flow connected the weekly history to days, then to individual slots with their store and time.

Earning a reward was also different from receiving it. Payment status and the credit date were separate from the earned amount. Weekly incentives had their own conditions rather than being folded into the slot’s guarantee explanation.

The final end-to-end flow.

Weekly history, daily earnings, slot detail and weekly incentives.

The slot rows carried the same explanation as the card. Expanding one could show a top-up or an unmet condition beside the work it belonged to.

The central problem was making one earning amount understandable when it depended on two different measures. The final design kept the comparison in the rate card and the result in the earnings card, with the full calculation one step away.

That is the design we finalized. These screens alone do not establish whether workers understood the guarantee more accurately or whether keeping another rate visible would have motivated them. Those are different claims from showing how I worked through the interface.