Bargain Rani Mobile · Process

The full process

The research, personas and flows behind Bargain Rani Mobile. The case study covers the decisions; this is the work underneath them.

02 — Discovery & Research

Where the phone actually wins

Mobile is not a smaller web. Reviewing what each context is genuinely good at changed which screens got attention and which were allowed to be simple ports.

Browsing is a phone activity
Discovery happens in spare minutes — a queue, a commute, a break. The explore grid and the live ticker matter more here than on desktop.
Negotiation is a phone activity
Haggling is conversational and impulsive. A thumb-reachable slider beats a precise input for a decision made in seconds.
Checkout often is not
Address entry and payment remain easier on a larger screen. Keeping the cart synced means she can start on the phone and finish on the laptop.
Sellers work from phones
Small sellers photograph, list and reply on a phone, not a desktop. The seller path had to be first-class on mobile, not a stub.

03 — Defining the Opportunity

Parity by construction, not discipline

Relying on the team to keep two clients aligned is a process that fails quietly. The opportunity was to make divergence structurally difficult rather than merely discouraged.

01
One source of truth for data
Cart, wishlist and orders should be one record read by two clients, not two records kept in sync.
02
One source of truth for style
Tokens defined once per platform in a mirrored file, so a brand change is a two-file edit and reviewable at a glance.
03
Native ergonomics, shared language
Bottom tabs, thumb-zone actions and gesture affordances — expressed entirely in the shared visual vocabulary.
04
Bargaining rebuilt for thumbs
The negotiation moment redesigned around a drag, not a form.

04 — Design Strategy

Share the system,
respect the platform.

The rule was simple: anything that carries brand meaning is shared, anything that carries platform expectation is native. Colour, type and copy are identical. Navigation, gestures and input are not.

01
Mirror the tokens
lib/colors.ts and lib/fonts.ts mirror the web's globals.css exactly — same names, same values, reviewable side by side.
02
Share the backend
One Supabase project serves both clients. Cart and wishlist are rows, not local state, so device switching is free rather than engineered.
03
Rebuild navigation natively
Bottom tabs, a live ticker in the header and thumb-reachable primary actions — none of which exist on web, all of which speak the same visual language.
04
Redesign the bargain for touch
The negotiation becomes a full screen with a drag slider and a single send action, rather than a modal with numeric input.
Back Return to the case study