Snifff: a deeper read of India's beauty labels

Beauty products are full of confident claims, but the ingredient label is usually left for shoppers to decode. Snifff was built to make that label more useful: not a flat good-or-bad verdict, but a clearer read of how the product changes with context.

The same ingredient can be treated differently in a product that stays on the skin versus one that is rinsed off. Concentration, audience and regulatory context matter too. The product brings those layers into the page where the purchase is already happening.

Megha led the ingredient research, safety work and master data. I led the product direction, interaction and visual design, Supabase architecture, Chrome extension, frontend and release work. We focused the beta on Nykaa, then let real pages and real edge cases shape what came next.

The initial idea was simple: help people understand what they are buying in a beauty market where ingredient lists, marketing claims and regulatory standards do not always line up neatly.

We wanted Snifff to educate without turning into a medical advice product or a clean-beauty blacklist. Its job was narrower and more useful: read the label, show the relevant context, explain what was found and be honest about what could not be read.

That distinction shaped the whole product. A product page needed a quick answer for someone comparing bottles, but also a deeper path for someone who wanted to inspect the ingredients. The interface had to support both without asking the shopper to learn the system first.

Nykaa was our beta retailer because it gives Snifff access to a large audience of Indian beauty shoppers. It also gave us a useful design constraint: the same information appeared in several shapes across the site.

Some products exposed a readable full list in a tab. Some mixed a short “Key Ingredients” pitch with the complete list. Others kept the list in page data, rendered it only after interaction, or showed it in product imagery. Variant changes could happen without a full page reload.

The response was a layered adapter rather than a growing pile of one-off selectors: find the product, identify the right ingredient source, remove prose that is not part of the label, and leave a clear fallback when the page does not provide enough to read.

v0.1 existed to be thrown away. The first question worth answering was whether a contextual read of a label was reliable enough to put in front of someone mid-purchase, and that answer lived in the backend—real Nykaa pages, real matching, real gaps—not in the panel. So the first interface was deliberately cheap: a score, a bar and the whole list.

It was cheap enough to be wrong in a useful way. Every version after it is easier to describe by what came out than by what went in.

Cutting it gave us a rule the rest of the panel could be checked against: if a control implies more precision than the data behind it has, the control is the bug. That rule is why coverage in v0.4 is a stated number on the same line as the count instead of an asterisk at the foot of the panel, and why the four ingredients we could not score got their own grey segment in the bar rather than a disclaimer under it. Uncertainty stopped being a caveat and became a quantity.

Once the backend and core flow were reliable, we tested the product with friends. They understood the result, but still wanted to know what Snifff was doing and how to use it. That feedback led to a short onboarding flow that explains the score, coverage and the path from the in-page card to the full analysis.

A product that reads the page should not become another thing the shopper has to manage. We changed the default behaviour from an unavoidable panel to a calmer in-page card with an optional click-to-open panel.

Settings make that choice reversible: open the panel automatically or only on click, show or hide the in-page card, follow the system theme or choose light/dark, replay onboarding, and paste a list manually when the retailer only provides an image.

We also kept the product vocabulary simple. Pregnancy and lactation information stays visible as part of the analysis rather than becoming a growing set of modes for different audiences. The product can carry more context without turning the settings page into a taxonomy.

The extension is deliberately thin. It knows how to read a Nykaa page, send the product context, and render the response. The private analysis service owns the matching, contextual resolution, score and anonymous telemetry.

That separation let the same result drive both UI surfaces. It also meant the product could improve its data and analysis without turning the public extension bundle into a copy of the system behind it.

The feedback loop is equally important. A missed ingredient does not become a user-edited safety decision. Anonymous telemetry records what was missed and how many products it blocks; that work is prioritised, reviewed by a human, validated through the release pipeline and then returned to the next version of the product.

The biggest improvements came from cases that looked plausible in a demo. A page could expose the right words in the wrong place. A partial label could produce a number that looked complete. A variant could change while an earlier request was still finishing.

We treated each one as a product failure, not just an implementation detail, because the shopper experiences the result—not the code that produced it.

To test the extension against real pages, I built an internal QA product that automated the repetitive parts of reviewing a PDP. It gave us one place to compare what the page showed with what Snifff extracted and to record the cases that needed another pass.

That shortened the feedback loop. We reviewed 200 product pages in four days, found the edge cases that mattered and turned them into fixes before the next release.

The review surfaced four recurring problems: product text in the wrong place, stale results after a variant change, incomplete reads that looked complete and an extension that was too heavy. We fixed each one and kept it as a regression check for the next release.

The meaningful outcome was not just a larger ingredient database. It was a product with a clearer relationship to uncertainty: it could be present without being intrusive, useful without pretending to know everything, and designed to improve as more labels were encountered.

Snifff changed how I think about product design for systems that interpret messy information. The happy path is only one part of the experience; the boundary states are where trust is earned.

I also became more deliberate about separating a product's public interface from the system that gives it depth. A small card, a deeper panel, a manual fallback and a settings screen can feel like separate features. In practice, they are one conversation about how much the user wants to know and how much control they should have over the interaction.

The best part of building with Megha was that the product could not be reduced to visual polish or backend correctness. Every decision had to make the underlying knowledge more understandable without making it seem simpler than it was.