Decision 01 · Insight 03
Hick's Law
Duplicates get two buttons. Skip, or add anyway — one tap, never a menu. A contributor with thirty seconds of patience won't open one.
One cart.
The whole household.
Fig.01 · The Shared Cart — join · live cart · split & pay
The problem
Watch how a flat
of three orders.
Requests drip into WhatsApp. One person compiles them from memory, orders alone, fronts the bill — then spends two days collecting ₹600s. Every quick-commerce app treats all of that as a single shopper.
The cart, the payment, and the awareness of both live in three different places. I put them on one screen.
The research
What our research
told us.
Six of us split into tracks for the sprint. Mine was household ordering — 12 interviews, a 60-person survey, five real group-order threads read line by line. The rest covered store operations, delivery trust and the base build. These four findings built the feature:
Insight 01
61%
Orders are group decisions paid by one person. money must be visible to every member, before checkout.
Insight 02
80%
One "default orderer" compiles everyone's items from memory. everyone adds their own — joining must cost nothing, not even a sign-up.
Insight 03
2in 5
A duplicate lands weekly; 78% forget items. guard the add moment itself — two-button checks, never cleanup after.
Insight 04
₹600×3
Chasing money is social friction; being chased feels like surveillance. settlement is structural — caps, quiet approvals, per-member payment.
“I don't mind ordering. I hate being the house bank.”Interview 07 · a household's default orderer
The multi-user flow
Here's the flow we designed —
two people, one system.
Hover any step — the frame shows its actual screen
Organiser — control without chasing
01Creates the cart
02Picks the payment model — Admin Pays or Each Pays
03Shares the invite code
06Reviews the joint cart as items arrive
10Locks the cart & starts checkout
13Pays the total, or per-member splits go out
Contributor — autonomy without surveillance
04Joins with the code — no sign-up
05Sees the live cart, members and budget
07Adds items — marked common or personal
12Pays their own share via UPI
Done here — the Organiser carries it to checkout
System · carries the friction
05aSyncs the cart live; logs every change
08Catches duplicates — skip, or add anyway
09Updates the household budget bar
11Opens a 10-minute payment window
13Confirms one order — tracked by everyone
The decisions
Four calls I made
to make it work.
Decision 02 · Insight 01
Public cap
The budget is public. One cap every member sees, editable until the cart locks — never a surprise at checkout.
Decision 03 · Insight 04
Quiet approval
Over-cap items wait, silently. The Organiser approves or removes; the contributor never sees a call-out.
Decision 04 · Insight 04
Split & pay
Everyone pays their own share in a 10-minute window. A miss at 9:59 never drops the cart — the Organiser covers the share, and the household still gets its groceries.
The outcome
What I'll claim —
and what I won't.
Straight answer
This is a mini-project — no usage data, and I won't pretend otherwise. What I will claim: a working multi-user feature that Blinkit, Zepto and Instamart don't ship. I checked all three directly.
If it shipped, I'd measure:
Duplicate-guard acceptance
Settlement time in the window
Orders with 2+ contributors
Repeat carts per household
01
Design and build should move together — two screens were designed before they were wired in. Fixed, and noted.
Credit
Who did what,
on what.
My role
Household research track, Shared Cart feature design, design-system tokenization — shipped as CSS variables consumed across the React build — and AI-agent build direction
Team
Five teammates ran the store-operations, delivery-trust and base-app build tracks
Tools
Figma, Stitch, React, Claude-based agentic build pipeline
Program
IIT Madras — UI/UX with Agentic AI & GenAI, 2026