Category page exit rate
People left without touching a product.
I turn user problems into clear products for commerce, workflows and design systems.
13 years in design, from footwear to digital commerce.
Four destinations. Each one a problem worth solving.
Guided discovery · Ravelcare
A guided shopping experience that turns confusion into confident choices.
Eight wins, five of them A/B tested — and the system that carries them across brands.
Independent projects I designed and coded myself — from the first sketch to a working tool.
Post-click commerce · Includ
Designing the whole loop after the click — login, rewards and the cart.
Multi-dog nutrition · Stella & Chewy’s
One quiz for every dog in the house — a plan per dog, one cart, and a My Pets area to keep them current.
Trial project · Rocket Hero
Reading a sample funnel, then designing the journey from ad to filed claim.
Good ideas travel further together.
© 2026 Vineet Tiwari · Senior Product Designer · Bengaluru
Vineet Tiwari · Senior Product Designer · Bengaluru
When more choice
creates less
confidence.
60+ products on one page, and no way to know which was right. A 4-question quiz replaced the listing page — and became the site’s #1 converting entry point.
A category page of 60+ SKUs, with no way to filter by concern. Replays showed rage clicks, back-navigation and exits.
People left without touching a product.
Long visits, no outcome: confusion, not consideration.
Top reason for not purchasing: I didn’t know which product was right for my hair type.
HypothesisMatch intent to product with a guided flow, and add-to-cart will rise. It had to feel like expert advice — not a filter.
The quiz became the entry point; the category page stayed as the control.
Four questions, each cutting 40%+ of the catalogue.
Measured against the old page; per-question data from week 3.
Hick’s law: the more choices, the longer a decision takes.
The biggest cut comes first, so every answer feels like progress.
One line under each question on why it matters — credited with about 8% less drop-off.
A personal headline, proof from people with the same hair type, one clear CTA.
“Step 2 of 4” — people who know how far they are abandon less.
Before code. 8 users ran the prototype without instructions.
A/B test · 4 weeks. Quiz vs. category page — significant by week 2.
The tested prototype, from first question to personalised kit.
Within a quarter, the quiz was rolled out to two more product lines.
Track drop-off per question from day one. We added it in week 3 — and lost three weeks of data.
What happens
after “Add
to Cart”?
Add to cart is only half the job. I redesigned what happens next — login, rewards and the cart — so intent becomes an order, and an order becomes the next one.
Shoppers who had already decided to buy were leaving at login — and once they ordered, nothing brought them back.
Where intent leaked, and what closed each gap.
BeforeDidn’t reassure before paying
After10 staged changes: badges, savings, total on the pay button
Before34% left here — one path for 5 kinds of shopper
AfterOTP-first, a path per shopper: 7 → 3 steps
BeforeNothing earned
After2% back in coins, ₹50 per referral
Before0 reasons to return
AfterCoins to spend, up to 21% of the next cart
HypothesisRemove the login wall, make savings visible and give every order a reason to return — and more carts become orders.
OTP first — only what each shopper needs.
Coins in one toggle, stacked with coupons.
Cart changes staged, one cause per lift.
Returning numbers get the OTP already sent — two taps to checkout.
A friend’s first order gives you both ₹50 in coins.
One toggle, stacks with coupons, shows the exact discount before you pay.
Badges, a countdown, a price breakdown and the total on the pay button.
Ten cart changes, shipped in stages — so every lift has a cause.
All at once would tell us the cart got better — not why.
How it ran. 50/50 for four weeks. Revenue per session first; add-to-cart and bounce second — fixed before launch.
The checkout login sheet and the coins flow, as shipped.
Login, savings and rewards now work as one loop.
After “Add to Cart” is one system. It only paid off when login, savings and rewards were designed — and tested — together.
One household.
Different
needs.
Many homes feed more than one dog, and no two need the same plan. I designed parts of the quiz, the pet profiles and the subscription flows that keep every plan current.
A one-pet quiz means a multi-dog home repeats everything — owner details, the whole flow — and ends with separate carts. Yet each dog still needs its own answers: they set the recipe, the portion and the price.
Owner details are asked once. Each dog gets the same five short steps and a profile checkpoint — then every plan lands in one cart.
Every screen speaks to one dog by name. The household only comes back together at the cart.
Setup, the per-dog loop and the shared cart, as one recording.
“What breed is Rambo?” — never “your dog”.
Goal weight appears only when the shape isn’t ideal.
A profile summary, then “Continue to Bruno”.
Every dog is selected; untick one and the total updates.
Loading screens say what the plan is doing — so a wait reads as care, not delay.
Every wait names the dog and the reason.
My Pets. A card per dog: profile, plan, subscription status.
Update profile. Weight, shape and proteins stay editable as dogs change.
Change a meal. Type, ratio, recipe — then current vs. updated, side by side.
From the first question to the next delivery, for one dog or four.
One dog is a form. Four is a system — deciding what’s asked once, what repeats, and where it all comes back together.
From idea
to
interaction.
Rocket Hero helps people find class-action settlements and file claims. In a work trial with TripleSpeed, I read the funnel first — then designed the journey from ad to filed claim around what the numbers showed.
Every user comes from a paid ad, and only a completed filing counts. So the first question wasn’t how it should look — it was where people drop.
A trial project: the brief came with a sample funnel. I read it stage by stage — what it showed shaped the design.
Sample data from the trial brief — not live results.
Not qualifying didn’t stop people — they browsed other claims more often than those who qualified.
Fewer than half finish the form.
Discovery → Details wasn’t measured. I flagged it to track, not to guess.
Central questionHow might we help more users move from clicking an advertisement to completing a claim filing?
Each decision is a testable hypothesis — not a declared win.
Three ad angles, one landing that continues the ad’s promise.
One question, with “why we ask”. No personal details yet.
“Not eligible” leads straight to other claims — the branch the data said mattered.
Cards show fund, deadline and what’s needed — easy to judge, no push to pick all.
What the fee covers and what happens next. No price in the brief, so none invented.
Details once for every claim, then a full review before submitting.
A settlement fund is not your payout. Every number says what it is.
Said on the screens where expectations get set.
The wider product. Home, My Claims and Claim Status — so one filing isn’t the end.
The states. Seven edge states, each saying what happened and what to do next.
The system. A reusable mobile design system, informed by a review of Sparrow and Settlemate.
The Figma prototype in motion — from the ad’s landing page to claim status.
The sample funnel describes the old journey, not these designs. The work ends with hypotheses to test.
Read the funnel before redesigning it. The best finding was a branch most would design as a dead end — and a number that was missing.
Quotations,
without the
copy-paste.
A biogas plant maker was building long offers by hand in Word and Excel. I designed and built Bifrost: one guided form, beside a live A4 page of exactly what the client gets.
Each offer — gas specs, equipment, codes, prices, terms — began as a copy of the last. So wrong names, stale prices and the wrong letterhead slipped through.
Each with its own letterhead, GST, bank and prefix — picked by hand.
Totals recalculated by hand on every revision.
No single view of what was quoted, to whom, for how much.
Builds a branded offer from a template — no retyping.
Sees every quote, status and total in one place.
Updates a rate once; every new offer uses it.
GoalOne source of truth — and what you see on screen is exactly what gets sent.
Engineers think in the finished document — so the page sits beside the form, and the form follows the page’s order.
No export, check, fix loop — the page on screen is the PDF. Illustrative values.
Client, specs, scope, codes, terms — the form reads like the offer.
A sent offer asks first: duplicate it, or edit in place.
Letterhead, prefix, GST and bank change together.
Monospace numbers that scan; colour only for status.
Most enquiries are variations of a few plant types — so offers start from templates built from real ones.
Prices are typed once and reused. (Counts from the demo data.)
Offline-first. Electron, React and a local SQLite database — client data never leaves the office.
One bridge. All data goes through one layer — which made a safe public demo possible.
Easy updates. One Windows installer; updates swap a single file.
Offers, clients, items and all three companies, in one place.
Design the document, and the form follows. Knowing how offers are read — specs before price — set the whole structure.
Open ABIO/PI/CBG/001, choose Edit Anyway, change a rate — watch the page update.
Open the live demoSmall changes.
Measured
moves.
Testing is how I prove a design decision was right. Audits become ICE-scored backlogs; the strongest ideas ship as A/B tests. Each story: problem, change, result.
The five A/B-tested lifts, on one scale.
Wins only matter if they travel. The PDP framework that lifted Ember became the starting point for every new brand.
The PDP framework: price + MRP above the fold, ratings early, video in the gallery, price on the Add to Cart button.
Native UI Extension API only — works on Plus and non-Plus stores and survives every theme upgrade.