All case studies08 / 11

Consumer product · Mobile · 2025

SmartGrocery

Compare the whole basket, not one tempting price.

RoleProduct Designer · Product StrategistStatusIndependent conceptContextIndependent concept · India quick commerceEvidenceOpportunity analysis · Basket decision model · Interactive Android prototype
SmartGrocery annotated exploded-view case study cover

Problem

What made this hard

Each service uses different product names, pack sizes, prices, stock, fees, and delivery promises. Rebuilding the same cart makes the comparison slow while a cheap item can still produce an expensive or incomplete order.

Outcome

What changed

An Android concept that turns text, voice, or a photographed list into comparable baskets, then explains the tradeoff between total cost, exact matches, substitutes, missing items, and delivery time.

The thesis

An independent product concept for Indian quick commerce shoppers who want to create one grocery list and compare the complete basket across services.

Case-study proof

The decision record

Enough context to judge the choice, inspect the work, and separate evidence from ambition.

01

Why this, not that

I designed around the complete basket instead of highlighting the cheapest individual item. Item-level comparison ignores fees, unavailable products, substitutions, pack sizes, and delivery time—the factors that decide whether a basket is actually better.

02

Why this case is specific

The model is rooted in Indian quick commerce: rupee totals, Blinkit/Zepto/Instamart-style trade-offs, inconsistent pack sizes, regional-language input, and shoppers choosing between savings, speed, and exact matches.

03

What you can inspect

Interactive Android prototype · static page evidence

The project includes an interactive Android prototype; this portfolio page currently presents representative static interface frames and the underlying decision model rather than embedding a live commerce experience.

04

Decision to outcome

The basket model produced three explainable recommendations—lowest complete total, fastest viable delivery, and most exact matches. It remains an independent concept, so user trust, data access, and switching behaviour are validation questions, not outcomes.

Interface evidence

01 / Opportunity

One grocery list becomes several repeated carts

The research framing focuses on people who regularly use more than one quick commerce service. Their current journey involves repeating searches, resolving inconsistent names, checking stock, and calculating the final value by hand. The estimated ten to twenty minute comparison time is a hypothesis to validate, not a measured product outcome.

02 / Audience

Design for frequent shoppers with different definitions of value

Working professionals and families may optimise for time. Students and budget conscious households may prioritise the final total. Homemakers, senior citizens, and regional language users add accessibility, familiarity, and input needs that a simple price table would miss.

  • Frequent metro shoppers
  • Budget conscious households
  • People who use regional languages
  • Shoppers balancing speed, savings, and availability

03 / Input

Capture the list in the form people already have

A shopper can type, speak, paste, or photograph a list. SmartGrocery then converts rough intent into structured items before asking the person to resolve uncertain matches.

  • Text and voice entry
  • Printed or handwritten list import
  • Regional language input
  • Visible confirmation for uncertain interpretation

04 / Intelligence

Normalisation is the product beneath the interface

Milk, one litre and a platform specific product title may describe the same need. The system has to compare category, brand preference, quantity, unit, pack size, and substitution tolerance without pretending that every match is equal.

  • Exact match confidence
  • Comparable unit pricing
  • Pack size reconciliation
  • User controlled substitutes
  • Clear unavailable states

05 / Decision

Best depends on the complete basket

The comparison separates product total, fees, availability, substitutions, and delivery time. Instead of naming one universal winner, the interface can recommend the lowest complete total, the fastest viable delivery, or the basket with the most exact matches.

06 / Scope

Keep the first value proposition narrow

The concept concentrates on list capture, product matching, and basket comparison. Pantry management, nutrition guidance, budgeting insights, and meal planning remain future possibilities and are not presented as current product capability.

07 / Feasibility

The hardest constraint is reliable commerce data

The experience depends on current prices, inventory, fees, delivery estimates, and platform access. API availability, rapid price changes, product naming inconsistency, inventory synchronisation, platform policy, and aggregation rules can determine whether the concept is trustworthy enough to launch.

08 / Validation

Test trust before expanding the ecosystem

The next research round should verify the current journey estimate, observe how people judge substitutes, and measure whether savings or speed justify switching services. Data access needs technical validation in parallel. Affiliate revenue, premium planning tools, clearly labelled sponsorship, and privacy preserving insights remain business model hypotheses.

Supporting evidence

Bring me the difficult part.

Complex workflows, AI trust, and enterprise systems.

Discuss a product challenge
About KowsikRésuméLinkedInEmail

Next case study

Read Secure Permalinks case study