Shikhar

Shikhar is HUL’s ordering app for kirana stores, the small neighbourhood shops that sell most of India’s FMCG. The owner opens it to restock: detergent, shampoo sachets, tea, soap, the inventory his shop runs on. He orders directly from the brand instead of waiting on a distributor’s salesman.

He is not browsing. He has a rough list in his head, a margin he needs to hit, and a customer at the counter. Three things about him shaped every decision on this project:

On the listing screen every product carried its schemes as stacked full-width rows underneath it: “Get additional 3% off per unit”, “Get Flat Rs.50 OFF on Bill of Rs.500”. Two schemes roughly doubled the height of a product card. Merchandising adds schemes weekly, so the layout got worse over time and no designer was in that loop.

The effect on a 360px screen: a retailer scanning for one SKU saw barely two products at a time, and most of what he scrolled past was promotional copy rather than products. The offers were not helping him decide. They were standing between him and the decision.

The cart used the pattern every shopping app uses: one long vertical list of line items, with everything else stacked below it. That works when the basket is three products. A kirana restock is thirty.

At that size, everything the retailer actually needs before paying (his redeemable points, the bill breakdown, the total) sat several thousand pixels down the page. Functionally they did not exist. He was being asked to scroll past his own order to find out what it cost.

A retailer’s question at checkout is not “what does this cost”. It is “what do I make on this, and what did I actually save”. That information already existed in the system (retailer margin, scheme discounts, platform discounts, points earned) but it arrived as a single number with no working shown.

So the summary became an expandable ledger: total MRP, items total, retailer margin, scheme discount with a count of how many offers fired, Shikhar discount, total savings, total payable, points earned.

A real share of retailers were not ordering in the app at all. Some were not comfortable with it. Many more were simply too busy to assemble a thirty-line order on a phone between customers. Their fallback was to call the distributor’s sales rep, who knew the catalogue and could take the order in a minute of speech.

The tempting fix was to make the app easier until the call stopped happening. I did not believe that would work. The call is faster than any interface, forgiving of a half-remembered SKU, and happens in the retailer’s own language. What the call lacked was a record: an order placed by a rep left the retailer with nothing to check.

So rather than compete with it, I brought the call inside the product and gave it the one thing it was missing.

The decisions I argued against are a better description of the work than the ones I shipped.

All four flows were live business requirements, went into development, and shipped. The changes below are structural: you can verify every one of them against the screens above without taking my word for it.