About
When I was around twelve, I noticed that landline phone receivers, when placed at a slight angle, wouldn't fall correctly into the cradle and cut the call. The speaker and mic were shaped the wrong way — they'd sit tilted and the line stayed open. I made sketches in a notebook proposing a solution: a more spherical form that would roll into the socket properly. The sketches went nowhere. The notebook was eventually lost. But the instinct — seeing a broken thing and immediately thinking about how the form should work — that stayed.
I was the kid who opened things and fixed things. At home, when the washing machine broke, I replaced the cracked plastic strip in the drain mechanism with a metal wire — jugaad, improvised problem-solving. It worked. My mother was impressed. What I remember most is not the fix but the clarity: making things work for people felt like the only kind of problem worth solving.
I spent three years in mechanical engineering not realising this had a name.
In 2004, I enrolled expecting to build things. What I found was rote learning — abstract mathematics, theory without making, a system designed to produce engineers who could pass exams rather than people who could solve problems. I was a visual thinker. I consistently failed the math while acing engineering drawing and every practical where I had to make something with my hands. After three years of this mismatch, I gave up on the system and looked for something else.
I found product design. Specifically, MIT Institute of Design in Pune — then so new that I was part of only the second batch of students. Design was barely known in India at the time. My parents, both doctors, had never heard of it. MIT professors convinced them by explaining that everything around us is designed, not just engineered — a car isn't just mechanics, there's a form to it, an experience. That framing landed. I enrolled.
The institute's motto was "Ensure karman, leave phalam" — follow the process right in action and the product will evolve by itself. That became my working creed, not just for design projects but as a way of thinking. The first course that changed how I saw the world was EFSS — Elements of Form Space and Structure — which taught that whether something is a form or a space depends entirely on your frame of reference. I remember sitting by the river behind campus and seeing the world in isometric view. Every subsequent course opened something else. By the time I was in my final year, I'd developed a meta-learning habit: stop evaluating what the teacher is saying and ask instead, what can I extract from this and connect to my own problem?
For my pre-diploma colloquium, I wrote a paper called "What is Design?" — born from the lived frustration of being unable to explain four years of study to people who thought the only noble professions were doctor, engineer, or banker. My honest admission framed the whole paper: the more you think about it, the less you know what it is. But I landed on something that stuck: the line between designed and not-designed is intention. Nature isn't designed, but plant a tree in your garden and it becomes design. And already in 2011, I wrote that as cell phones collapsed into "radii-manipulated cuboids" with no fixed function, products would be differentiated by their interfaces and the experience they give. That turned out to be the thesis my entire career then tested.
My graduation project was an internship at Notion Ink in Bangalore — designing the next generation of the Adam tablet. It was my first encounter with the kind of constraint that design school doesn't teach: 0.1mm tolerances, the cost of material plus process determining what a product can be, the discipline of building something that explicitly was not allowed to look like Apple or Samsung. I wrote in my project report that "minimalist is actually killing the beauty which lies in the form — why make everything look like boxes when they can look different?" A few years later, I would lead a practice at a company called The Minimalist.
My first professional work was at the Human Factors Institute, where I was trained in Human Factors Engineering: the science of designing systems around the actual capabilities and limitations of the people who use them. HFI gave me a vocabulary for something I'd been feeling since the phone sketches at twelve. The core insight of HFE — that failures attributed to user error are usually failures of system design — became the lens through which I read everything.
The projects at HFI made this concrete. An IVR system for a South African bank: semi-literate users in a country without smartphones, losing trust in telephone banking because they couldn't find options and couldn't understand instructions. The redesign mapped the IVR's architecture to how users actually think. When "Please enter your telephone banking PIN" sent users to their phone number instead of their PIN — because semi-literate users latched onto the word "telephone" — the fix was word order: "Please enter the PIN for your telephone banking." Task completion jumped. Sometimes the solution is a simple change in design. I wrote WHEN IN DOUBT, TEST IT OUT on a whiteboard and left it there.
An internet banking simplification project showed me the other side of the same problem. Five different labels for the same task — Download Statement, Request Statement, Historical Statement, View Statement, Transaction Summary — because the data lived on different systems with different rules. The constraint: we couldn't change the backend. The solution: move the routing to system level. The user enters a date range. The system figures out where to fetch from. The label becomes one thing. The systems carry the complexity from their constraints; the design absorbs it and keeps it invisible.
I spent the next several years at The Minimalist building the interaction design practice from scratch. Not the agency — I joined it. But the ID function didn't exist in any structured form when I arrived, and it did when I left. I defined the processes, the ways of working, the frameworks. I grew the team from six to forty-six. I pitched to clients. I expanded us from Mumbai into Bangalore during COVID, hiring designers remotely to serve a new geographic market.
The work spanned banking, FMCG, healthcare, enterprise platforms, e-commerce, edtech — not because I liked variety, but because I wanted to understand what design problems looked like across very different constraints. The constant: organisations know what they want systems to do. They almost never know what it feels like to use those systems. The consistent intervention: absorbing the complexity that systems generate from their constraints and keeping it invisible from the people who have to use them.
GE HealthCare brought a different level of consequence. Clinical decision support: the systems that sit between a clinician's judgment and the evidence and protocols that should inform it. The users are professionals under genuine pressure. The complexity is not interface complexity but epistemic complexity — how do you encode clinical knowledge in a way that is trustworthy, updateable, and legible to the people who act on it?
The work I'm most proud of from this period is not a screen. It's a model for how clinical protocols should be authored, versioned, and deployed — a lifecycle that makes the invisible infrastructure of clinical guidance visible and governable. The most important design decisions were about architecture, not interaction. This has become a recurring theme.
At some point I started sitting with questions that I couldn't answer by working on products. How should humans supervise AI? What makes AI trustworthy? How should AI communicate intent? Can AI help humans understand themselves better over long periods of time? I had read enough and thought enough. I needed to build systems and live with them.
Vipassana changed how I approach this kind of inquiry. Ten days of silent meditation, no reading, no writing — just observation of what the mind actually does when you stop directing it. What I came back with was not a philosophy but a posture: observer before actor. Equanimity before reaction. Impermanence as a fact you can hold lightly rather than fight against. I apply this to research, to design, and now to the question of AI: what is actually happening, before I decide what to do about it?
The AI laboratory started from that posture. Not "here is my theory of AI interaction" but "let me build systems and observe what they actually do." A wellness companion that extracts emotional signals through natural conversation. A reflective dialogue system that interviews me about my own life and career, building structured memory of who I am and how I think. A debate environment where AI agents with distinct personalities interact in a space I designed. A framework for measuring whether software is understandable and operable by AI agents. A local AI workspace that is itself a laboratory for the operating environment of AI.
These are live systems, not prototypes. They run on infrastructure I designed and maintain. They produce things I didn't expect. The washing machine kid is still operating on the same instinct — the problem worth solving is making things work for people. The people, now, include the AI.
Systems carry complexity. The question is always: who carries it? In a badly designed IVR, the caller carries it. In a poorly authored clinical protocol, the clinician carries it. In a badly designed AI system, the human carries it — or, worse, neither the human nor the AI carries it clearly, and it disappears into the gap between them. Designing the space between humans and intelligent systems.