I design the system before the screen.
Product designer for complex enterprise domains. Research first, synthesis second, Figma last.
A BI platform surfacing national drug-loss exposure at three levels of complexity — built so a Government Affairs team could present hard data to legislators.
Shelf assortment and product analytics for a global food brand's internal planning platform — turning raw shelf data into decision intelligence.
A watchtower for an enterprise GenAI chatbot — utilisation, performance, and root-cause analysis. UX for systems that watch other systems.
UX is my primary lens, but good design is the full picture. These projects show the craft side: visual systems, interaction design, and screens that hold up on their own.
I design for complex enterprise domains. My work isn't about making things pretty — it's about making systems that hold up when the domain is messy, the stakeholders are impatient, and the dev team needs a foundation, not a mood board.
More about me →Enterprise product design across pharma, analytics, AI, and consumer goods. Research-led, framework-grounded, built for complex domains.
OOUX-led system definition for a cross-vendor Salesforce build. 28+ objects, 6 roles, zero structural rewrites. Research first, screens last.
A BI platform surfacing national drug-loss exposure at three levels of complexity — built so a Government Affairs team could present hard data to legislators.
Shelf assortment and product analytics for a global food brand's internal planning platform — raw shelf data into decision intelligence.
A watchtower for an enterprise GenAI chatbot — utilisation, performance, RCA, and monitoring. UX for systems that watch other systems.
I'm a product designer with 4+ years building enterprise platforms across pharma, data analytics, AI systems, FMCG, automotive, retail, and food & beverage. I work at the intersection of research, frameworks, and execution — in that order.
Most designers start with a screen. I start with a question: what is this system actually made of? That question has saved more projects than any prototype ever has.
I bring frameworks to rooms that only have opinions.
My background is in design consultancy — client-facing, deadline-accountable, structurally responsible for decisions other teams build on. I've led research in domains I had no prior knowledge of, worked across multi-vendor engagements, and handed off work that was immediately buildable.
I'm not interested in brainless pixel-pushing. I care about why something is designed the way it is, and whether that why is grounded in research or just assumed.
I also build frameworks, not just products. AXIS is a conversation design auditing framework I developed independently — the kind of thing I do when a problem doesn't have a good tool yet.
Currently based in Bengaluru, seeking a role where complexity is a feature, not a bug.
Product Designer at MathCo.
Open to new opportunities.
Bengaluru, India
A Product Designer's account of how object-oriented thinking stopped a multi-vendor Salesforce build from collapsing under its own assumptions — and why starting with a spreadsheet was the most important design decision I made.
The brief was clean enough: design the patient journey for a pharma patient management platform being built on Salesforce, involving two external vendor teams.
Everyone kept talking in features. Dashboards. Alerts. Case lists. Forms. But nobody had agreed on what a Patient actually was in this system. What information lived on it. Whether a Case was part of a Patient or separate. Whether a Fill was a child of a Case or its own object. Whether a BV and a PA were siblings or parent-child.
The vocabulary wasn't shared. And if the vocabulary isn't shared, there's no product — there's just a collection of screens that don't add up to anything.
Global pharma client. Salesforce build. Multi-vendor setup. Timeline pressure. "Design the patient journey."
Stakeholders are speaking in features, not objects. Nobody has defined what the system is made of. A dev team is about to start building without a structural foundation.
Not assigned. Not prompted. I put it in front of the team as a risk mitigation tool, not a research phase.
42 objects identified. System model built. Role-permission matrix defined. All before a single Figma frame.
Structural wireframes grounded in the object model, handed to the Salesforce visual designer and developers.
"We don't have time for research. Show us screens. We know what we want."
"We've never done OOUX on this account. Do we actually know how to run it? Will the client buy it?"
I reframed the conversation. Both conversations. Differently.
"You're about to hand a Salesforce build team a specification for a system nobody has agreed on. I can give you that agreement in two weeks — or you'll spend sprint 6 undoing sprint 2."
What I said to the client
For the client, I didn't sell OOUX as a UX methodology. I sold it as a project risk tool. I showed them the structural ambiguity — what a Patient was, what a Case was, who could update what — and made the cost of that ambiguity visible. They understood that language.
For my team, I simplified the framework into action. OOUX is often treated like a recipe to be followed step by step. I treated it like a thinking tool — adapting it as I learned more about the domain, changing my approach when something wasn't landing, and teaching it to my junior as I went.
I was client-facing. I was also managing up to a Design Manager and delegating down to a Junior. Every decision about approach, pace, and framing was mine. I was the only person doing the systems research — and the only one who could have caught this problem when I did.
Execution: screen iteration, copy-paste work, UI assembly. I kept my headspace for thinking. That's a deliberate choice, not a convenience.
Most designers learn frameworks and apply them as checklists. I use them as diagnostic tools — picking what I need, adapting what I don't, and knowing when to break the recipe.
The core nouns of the system. Not features — entities with identity, attributes, and life. Patient. Case. PA. BV. Fill. Appeal.
How objects connect. Patient HAS-MANY Cases. Case HAS-1 PA. Case HAS-0-1 BV. The relationship type determines the UI pattern and navigation structure.
The actions available on each object — what a user can do, initiate, or trigger from any given state. CTAs are role-gated and context-sensitive.
What each object contains — separated into Core Content, Metadata, and nested Object Relationships. Each category drives different design decisions.
When a Salesforce developer receives a design spec that says "Patient has-many Cases, Case has-1 PA," they can model the database correctly from day one. No re-architecture at sprint 6. This is what I handed the SF team — a structural contract, not a visual suggestion.
Every artefact below was built by me, grounded in domain research with the client's on-ground SME, and handed off to the Salesforce team as a structural build reference.
The Patient Profile isn't six different screens — it's one object-grounded view that adapts its content, actions, and data density based on where the patient is in their therapy journey.
This is the design principle the object model made possible: because we knew exactly what information belonged to each stage, we could show the right data at the right moment without cluttering the interface with everything at once. The junior designer assembled these in Figma. I designed the logic that drives them.
The best measure of this work is the structural rework that never occurred, the sprint that never needed rewinding, and the project that didn't collapse under multi-vendor misalignment.
The Salesforce team would have started building without a shared model. When the objects turned out to be wrong — and they would have — sprint velocity would have collapsed.
Without knowing which objects matter most and how long each takes to design and develop, the client would have continued asking for the wrong things in the wrong order.
Two vendor teams, no shared vocabulary. The object model became the contract between teams — design, development, and the client's SME all working from the same document.
A multi-vendor engagement with timeline pressure and no structural clarity is a recipe for client attrition. Defining the system first made progress visible and defensible.
Most designers at this level would have opened Figma. I opened a spreadsheet. I proposed a framework my own team hadn't run before, sold it to a sceptical client, adapted it as domain complexity surfaced, and handed off structural wireframes that the SF team could build directly from.
The approach wasn't assigned to me. I identified the gap, proposed the solution, and convinced two rooms — my team and the client — that slowing down to define the system would accelerate everything downstream. That's a different kind of design skill.
Most designers think about the user. I think about the system the user lives in. A screen is a surface expression of a data model. If the model is wrong, the screen is wrong — and no amount of visual polish fixes that. OOUX is how I make system thinking visible.
OOUX wasn't the obvious choice on this engagement. It was the right one. Knowing the difference — reading a project's underlying structural problem and matching a framework to it — is a skill that comes from pattern recognition across complex domains, not just portfolio accumulation.
I delegated all execution work to my junior. Deliberately. My job was to think at the system level, face the client, and make the structural decisions. Protecting that headspace — while still delivering — is a leadership skill, not a luxury.
The client didn't want research. My team wasn't sure about OOUX. I adjusted how I communicated to each audience without adjusting what I was doing. The outcome of a designer who can hold conviction under pressure is a better product — not just a faster one.
"The kind of designer who researches first, synthesises second, and only then opens Figma — because the thinking is the design."
How I describe myself
A government affairs team had billions in policy data and no way to make it legible to a legislator. My job was to turn a reporting tool into something a non-analyst could pick up and argue with — confidently, in the room.
I designed a transparency dashboard for a government affairs team who present 340B policy cases to legislators. The previous tool gave them data; what they needed was a way to walk into a hearing and make a point. I owned the work end to end — research, the structural reframe, five concept directions, the iterations, and the final hi-fi prototype.
I structured the whole dashboard around the questions a legislator actually asks, in the order they ask them — how much has grown, who benefits, how the money moves. Each section leads with a plain-language question and answers it with one unmissable number. The user doesn't assemble the argument under pressure; the interface has already done it for them.
I kept the layout identical when a user drills into a state — only the data changes. Someone mid-presentation can move from national to local without ever relearning where things are. Predictability was a deliberate design goal, not an accident.
For a single hospital, I mapped its parent-child pharmacy network against neighbourhood income and underserved-area overlays. It turns an abstract compliance point into something a person can see and immediately understand — the hardest insight made the most visual.
Every interface choice answered one question: can a non-analyst pick this up cold and understand what it's telling them — and what it implies?
Decisions in the Visual Language
I titled each section with the question it answers. People don't think in metrics; they think in questions. Framing the data this way meant a user could find the answer they needed by scanning for the question they were asked.
I gave each section a single oversized takeaway. Under time pressure, a user needs the headline first and the supporting detail second — so I built the hierarchy to land in exactly that order.
I chose a filled-state map over plotted points so hotspots read at a single glance, with a toggle to switch what the colour represents. The user changes the lens without ever leaving the view.
Decisions in the Experience
The relationship map was the decision I'm proudest of. A compliance argument is hard to feel as a percentage; as a map of clustered sites with a radius drawn around them, it becomes obvious. I led with the visual where the insight was hardest to grasp.
I annotated policy changes directly onto the timeline, with the full explanation inline. A user fielding a question about a past spike doesn't go hunting — the reason sits attached to the moment it explains.
I reused one layout across every scope. It would have been easy to design each view bespoke; choosing restraint meant the user's instincts carried over everywhere, which matters most when they're not looking at the screen.
The value I added wasn't executing a brief — it was reframing it. Here's how I got there, and the calls I made along the way.
I started with a knowledge-transfer session, then went deep on the policy landscape myself — how the program works, who benefits, why it's contested. I don't think you can design credibly for experts without earning a basic fluency in their world first. That fluency is what let me push back later.
Two interviews with users of the existing tool surfaced the actual issue: they had data but no meaning. They were doing the interpretation in their heads — work the tool should have been doing. That reframed the project from "rebuild the dashboard" to "design the thinking."
Rather than arrive with a single answer, I presented five structurally different concepts. This wasn't indecision — it gave the client genuine ownership of the direction and surfaced their real preferences early, before any expensive build. We converged to two, then to one, together.
The final design is simpler than my first hi-fi. Each round I cut density, enlarged the takeaways, and pushed the narrative framing harder. The transparency angle that anchors the whole tool emerged through iteration — I treated "what to remove" as the actual design work.
The final React-friendly prototype became the client's own tool for winning internal sign-off. Knowing that shaped how I built the interaction — it had to be legible to someone who'd never seen the design process, presenting it cold to their own stakeholders.
The brief said "replace the tool." My research said the tool was never the problem — data had been dropped into an interface with no design thinking about what it meant. I made the case to the client that the real job was building an argument, not a report. That redefinition was the most valuable thing I contributed.
Showing five concepts on a tight timeline felt risky. I did it anyway, because converging with the client beats presenting to them — when stakeholders pushed back later, the client could say "I chose this." I designed the process to protect the project politically, not just the pixels.
Six weeks gave me room to refine, not just deliver. I used it to move the design from analyst tool toward advocacy tool — the difference between showing someone data and handing them a case they can make.
The Arc
Distinct directions, shown side by side.
Chosen with the client, taken to wireframes.
Transparency framing becomes the spine.
Cut density, enlarge takeaways, sharpen story.
Prototype, stakeholder-approved.
A senior designer is defined less by what they make than by the calls they make. These are the ones that shaped this project.
The user isn't quietly at a desk — they're often presenting, fielding questions they didn't expect. I designed every hierarchy and density decision around that reality. The best interface here isn't the most feature-rich; it's the one that holds up when its owner is under scrutiny and can't look down for long.
I gave each section one oversized takeaway and let the detail sit beneath it. People remember the headline, not the footnote — so I built the visual hierarchy to deliver the point first and the proof second. That's an opinion about how people read under pressure, expressed in layout.
The most important argument was also the least intuitive as a number. So I made it a map — clustered sites, a visible radius, neighbourhood overlays. Choosing where to spend visual weight, and pointing it at the insight that needed the most help, is the kind of decision I think distinguishes craft from decoration.
I could have designed each view bespoke. Instead I reused one structure everywhere, because consistency served the user better than variety would have. Knowing when not to add is, I'd argue, a more senior instinct than knowing what to add.
Reading what the client actually needed — not just what he asked for — and designing a process that gave him ownership and political cover was as much a part of the work as the screens. The deliverable wasn't only a prototype; it was a client who felt confident defending it.
"I think this is great — I will be able to use this way better than what we have."
Analyst · Primary End User"I think this is what we needed from the beginning. Now that I have this, I will actually be able to make a strong case in front of the legislators."
Primary Stakeholder · Government AffairsThe measure wasn't whether the prototype looked good. It was whether someone could open it cold, in front of a legislator, and immediately speak with authority. That was the brief I set for myself — and the one the design was built to answer.
Before, the team had a reporting tool with near-zero adoption — data without meaning. After, they had something that framed every figure as a point they could make, scaled from national to a single entity in seconds, and made the hardest argument visible at a glance. The work was selected for a flagship industry showcase — a signal it had value beyond the immediate client.
A framework for evaluating conversational AI products that actually matter.
Most chatbot evaluation still borrows from visual interface heuristics written before voice assistants existed and before large language models changed what "understanding" means. AXIS starts from scratch — built specifically for data chatbots, GenAI assistants, task-automation agents, and visualisation bots.
A Product Designer passionate about simplifying complexity through design and using UX as a strategic lever for business growth. I blend UI/UX craft, research depth, and data storytelling to create experiences that not only empower users but also drive measurable impact. At MathCo, I am expanding this craft by integrating design thinking into analytics and product strategy — turning raw data into narratives that inform, engage, and influence decision-making. I believe great design goes beyond aesthetics; it is a business differentiator that translates user empathy into clarity, efficiency, and competitive advantage.
Currently working at MathCo as a Product & Data Visualization Designer, blending design thinking with data storytelling to create intuitive, insight-driven experiences. Focus lies in shaping user-centric products and analytics dashboards that transform complex data into clear, actionable insights for decision-makers.
UX Designer with proven expertise in creating intuitive designs for global enterprise clients. Skilled in translating UX research into impactful UI solutions and leveraging emerging technologies including Gen-AI to drive innovation using Design Thinking methodologies. Led OOUX-based system definition for a multi-vendor Salesforce platform build in pharma, resulting in zero structural rewrites and an on-time, on-spec handoff.