role
Focus
Timeline
Context
———— The bet had two layers
Broadway, a high-end mall in Hyderabad, was hosting Deep Holistics' wellness kiosk: a quick scan of a shopper's skin, hair and body.
Would people pay for recommendations built around their unique health data, not generic categories like "oily skin"? And could that pull them toward the flagship full-body analysis?
The scan could produce the data. The problem was everything that came after. The machine generated a dense, clinical report packed with graphs, scientific terms and unexplained metrics. It was technically correct, but almost impossible for a customer to interpret.
And this wasn't a concept to polish over weeks. It had to go live in a working store over one weekend. A dashboard was out of scope. We had roughly 1.5 days.
problem 01
Make the data understandable.
A person standing in a store should grasp their result in minutes, not decode a clinical printout.
problem 02
Make it produceable, fast.
Fast enough that a live store with a queue could actually keep churning reports.
———— frame 01 decode
I came on expecting to design a report. But even our own design team couldn't confidently interpret the machine's output.
The face scan had eight panels with no explanation. The hair analysis had fields like "single follicle proportion" and "follicle double root ratio." Body composition reported metrics like SMM; some graphs had no axis at all.
So I stopped designing and decoded the source first.
I worked through a vendor walkthrough, cross-checked it against videos of the same scans, and mapped the machine's opaque terminology onto customer-relevant concerns. With the doctors, I decided which metrics actually mattered to a person receiving the report, rather than a specialist reading raw output.
Running new research would have been the obvious move; skipping it was the deliberate one. A month earlier I had run research for our flagship product, with real customers, colleagues and clinic visits. It had already surfaced the pattern: people understand the scan, not the report.
With only 1.5 days, repeating that research wouldn't have changed the design decision. The scarce time was better spent understanding the actual black box.
———— frame 02 REdesign
The raw report handed a customer a verdict and left them alone with it.
But the customer still had to work out: what does this measure? where does it apply? should I worry? what do I do about it? The science was right. The presentation was built for a machine, not for a person trying to understand their body.
— principle
Every finding became a small, self-contained explanation. The result itself wasn't softened. "Poor" stayed "Poor." What changed was the framing around it. Instead of giving someone a number that might trigger anxiety, the report gave that number context and a constructive next step.
The goal wasn't to hide an uncomfortable result. It was to make the result understandable enough to act on.
— directions before converging
That consistency mattered beyond aesthetics. Every report used the same mental model, a stable way to read results and compare them over time. The report grew past 20 pages, but each page asked the customer to hold less in their head.
———— frame 03 personalise
A rules sheet could map a scan result to a product. But a scan alone couldn't know whether that product actually suited the person. So the system started with a machine suggestion, and a wellness expert adjusted it in conversation, based on the customer's routine, suitability and circumstances. That final call was written back into the report.
The experience aimed to fit a recommendation to a person, not push a category, and the report was the persistent record of that call.
———— frame 04 systemize
The first reports were built manually. Each one took around 15 minutes. That worked for a few customers, not for a live store with hundreds waiting. A dashboard was the obvious long-term fix, but not before the pilot proved demand: we had no developer or testing time, and the vendor shipped only rendered PDFs, not raw data.
So the PDF had to stay. Could it behave more like a system? After building several by hand, I noticed something.
Every scan image landed in the same position in every report. That repetition changed how I looked at the layout.
If a position never changes, it isn't just layout anymore. It's an anchor.
I standardized those anchors. For every image I defined an X/Y position, a width and height, and a semantic frame name. The engineer built a plugin that read the frame name, matched the extracted scan image to its fixed coordinate, and dropped it into place.
The visual system, the coordinate map and the naming structure were mine, extended from the company's existing design language rather than invented from scratch.
That structure is what the automation could run on.
— Result
Image extraction and placement took about 4–5 seconds once automated; data population ran off the same coordinates. The risk sat in one place: pulling images out of a rendered PDF. So I scoped the bet to that step and kept manual entry ready as a fallback. When the machines finally arrived Friday night, the first test failed exactly there. We patched the plugin on the spot, and the system was ready for launch.
———— frame 05 Launch
The launch weekend was real demand, not a controlled design exercise.
friday evening
Machines were still arriving. The first automation test failed. We patched the plugin and retested.
saturday
Demand was strong. Report waits sat around five minutes. The scan cost ₹1,500 for three scans.
Saturday → Sunday
Demand kept climbing. The team raised the price ₹1,500 → ₹1,800 to slow it down. People kept buying at the higher price.
sunday
The system couldn't keep up. Waits stretched beyond an hour, and some reports weren't delivered until the next day.
The bottleneck had moved. The report itself was no longer the primary problem. The production system was.
An honest qualification: the 2 to 3 minutes was per-report production, not end-to-end time at launch scale. Generation was fast, but the full line still jammed under the queue at peak. That gap is exactly what Phase 3 closed.
— PDF launched
— measured what the pilot proved
Over the 3-4 March launch weekend:
These figures are blended from payment records and on-ground counts: strong but estimated, not audited. Revenue lift and conversion into the flagship full-body analysis weren't tracked, so I don't claim them.
———— frame 06 phase 3
The pilot answered enough of the business question to justify investing further. The team later shipped a web dashboard.
No manual PDF handling. No WhatsApp sending. Scan-to-report finally came down to under ten minutes end-to-end. Earlier PDF customers were migrated, and the kiosk kept running.
We did not need to build the dashboard first. The lightweight system proved demand before anyone committed to the big build. The pilot wasn't the final system. It was the fastest system we could responsibly use to learn.
———— 06 What i learned
The visible product was a report. But the leverage wasn't only in the screens. It came from understanding the source data, deciding what a customer actually needed to see, standardizing the experience, and then making that structure usable by an automated system.
interface
made the data understandable.
system
made the interface scalable.
———— next what i'd build next
These were deliberately left out of the MVP: Broadway had no product-image repository, fulfillment capability or stock API to support them.