Atharva Hambir
I think in models,
I think in models,
not mockups.
To contribute to a product's function, I first need to understand how it came to be.
Scroll
To contribute to a product's function, I first need to understand how it came to be.
I joined a hyper-growth health startup at 70 people and around 2,000 active clients.
A celebrity endorsement had changed the trajectory overnight and the company hadn't caught up to its own growth. Hiring was manual, patient management was stitched together, commerce had no structure. I was hired to solve that.
Observation before everything. Not to gather inputs but to find the pattern underneath the problem.
Most design problems are modelling problems. Get the model right and one solution covers ten things at once. Before anything gets built, I spend time understanding how something came to be. Abstraction over output. What comes out tends to be constructs rather than solutions. Things configured for a context, not hardcoded to one.
The goal is to leave you with tools, not answers.
Three problems came in at once: hiring, patient care, and commerce. I didn't want three separate answers. I wanted one model that could carry all three, and whatever came after them.
Each of them already existed in the real world. Companies have hiring pipelines. Hospitals have treatment protocols. Stores have catalogs. The process was there. What wasn't there was a digital model that actually reflected how these things work.
A hiring pipeline. A patient's treatment journey. A commerce catalog. Here's what they have in common.
Hiring at a fast-growing org isn't really a form problem. It's a configuration problem. Every role needs a different mix of people, activities, and documents, and when you're adding headcount fast, managing that manually breaks quickly.
The answer was a hiring request card. It held the job description, the rooms needed to run the process, reporting structure, required documents, and the offer. From the moment the request existed, the system already knew which rooms to fire for any candidate attached to it. No manual routing, no re-setup per candidate.
When someone was hired, their employee card was created and the same room construct picked up: attendance, payroll, performance reviews, and eventually exit. Exit fired a sub-room, ran the form and approval chain inside it, and on clearance bulk-reassigned every task the person held.
AI came in as a listener. It read role requirements and generated hiring request details and room configurations automatically. Every config built for a role was reusable for the next hire. The system got faster as the org scaled instead of slower.
Patients don't arrive as forms to fill. They arrive with a history and a problem, and how you receive them sets the tone for everything that follows.
The flow started with a sales room. Qualification, intake, and context-gathering happened before anything clinical was touched. Once a patient was ready, a treatment room opened: a 90-day program with daily logs, meal planners, and a personalised subscription built around what they actually needed.
The listener was the part I was most invested in. It ran sentiment analysis on patient responses, flagged patterns, and generated recommendations without waiting for a clinician to manually review every entry. Meal suggestions, activity adjustments, alerts. The clinician saw the signal, not the volume.
Onboarding ran through the store checkout, which meant the patient profile carried forward without re-entry anywhere. Clients ended up with one place for their health, not a patchwork of tools.
A health platform's catalog isn't a product list. Every item has a duration, delivery channel, terms, and a price that shifts depending on what the patient already has and how long they need it. Static pricing tables don't hold up here.
The catalog was built in four layers. At the base, the Atom held native information: base price, duration, terms, delivery channels. Atoms were grouped into Rooms (Offerings). Rooms got wrapped in Store Items, the commercial layer that held sticker price and batch configuration. Store Items surfaced through the Store Front.
A CPQ proration engine calculated price dynamically based on duration, availability, and demand. No manual adjustments per order.
Checkout was the bridge between commerce and care. The patient's clinical profile came in and personalised what they received. Buying a subscription and starting a treatment program were the same action, one flow.
The constructs work for three domains. They'd work for any domain.
Right now I'm working on opening this up as a multi-tenant platform. Other organisations will be able to use the constructs for their own context. The grammar stays the same. What they build with it is theirs.
Before design there was art. A drawing and painting class, mostly out of curiosity, mostly trying to figure out why things look the way they do. That question never went away, it just moved to a different field.
Outside the screen I follow football and F1 quite seriously, listen to a lot of rock, travel when I get the chance, and photograph everything while I'm out there. Photography is the one thing I never have to remind myself to do.
Product designer. Came into this through art, spent a long time trying to understand why things look the way they do before I started building anything. Eventually the making caught up to the questioning.
I care a lot about the people I work with and keep close. Not whether they always pull it off, but whether they always show up completely. The ones who go all in regardless of the outcome are the ones I want around. That effort, to me, is a win on its own.
Amura Health
Leading design across hiring, patient care, and commerce. Built the room-based model behind all three, now growing it into a platform other teams can build on.
Pineapple Design Studio
First role leading and mentoring a team. A six-month stretch of fast turnarounds, shipping real client work at a pace I hadn't worked at before.
Persistent Systems
Designed across five clients in one stretch: Bluedart, Microsoft, UChicago, KFC, and Zendesk. Logistics, enterprise software, higher education, retail, and support tooling, five different sets of users and constraints back to back.
Intuit
First full-time role, inside enterprise finance software at global scale. Learned how design decisions move through a large organisation before I'd shipped much of anything myself.
You've read the work. If something made you curious, ask.
Design thinking and the age of AI tools.
A guest lecture to branding and advertising students on how design thinking holds up when AI does most of the execution. The talk covered why knowing your user is the most critical thing in any customer facing industry, how that understanding is what separates good advertising from irresponsible advertising, structured inquiry over output, and why the skill that matters now is knowing what to ask, not knowing how to make it.
