Open to new roles

Abhishek
Dobriyal.

I design the system before the screen.

Product designer for complex enterprise domains. Research first, synthesis second, Figma last.

Abhishek Dobriyal
Bengaluru, India · Product Designer
Selected Work

Case studies in enterprise product design.

Global Pharma · Patient Access

I designed the system before anyone built a single screen.

OOUX-led research that gave a cross-vendor Salesforce team a structural foundation. 28+ objects defined, 6 roles mapped, zero structural rewrites.

OOUXSalesforcePharma
Read case study →
IPJ · Object-Attribute Map · 28+ objects
02

340B Risk Intelligence Dashboard

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.

Global Pharma · Gov. Affairs · 2024
Read →
03

Bigmixx Planogram Platform

Shelf assortment and product analytics for a global food brand's internal planning platform — turning raw shelf data into decision intelligence.

Kellanova · FMCG · 2024 In progress
04

GenAISys — AI Monitoring Platform

A watchtower for an enterprise GenAI chatbot — utilisation, performance, and root-cause analysis. UX for systems that watch other systems.

Global Pharma · AI · 2025 In progress

UI Design · Behance

Research-led — but I can also make it look good.

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.

All work on Behance ↗

Framework · Conversation Design

I built a framework for auditing how AI speaks.

AXIS is a conversation design auditing framework — 14 evaluation axes, 5 domains, 42 criteria. Not just what AI says, but how it thinks and why it fails.

Explore AXIS →

More Work

Figma files — no writeup, just the output.


About

A designer who thinks before he sketches.

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 →
Based inBengaluru, India
FocusEnterprise product & data design
DomainsPharma · FMCG · Automotive · Retail · F&B · Enterprise IM
Contactuxplorer.abhishek@gmail.com
Work

Case studies &
selected projects.

Enterprise product design across pharma, analytics, AI, and consumer goods. Research-led, framework-grounded, built for complex domains.

01

Intelligent Patient Journey — IPJ

OOUX-led system definition for a cross-vendor Salesforce build. 28+ objects, 6 roles, zero structural rewrites. Research first, screens last.

Global Pharma · Patient Access · 2024–25
Read →
02

340B Risk Intelligence Dashboard

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.

Global Pharma · Gov. Affairs · 2024
Read →
03

Bigmixx Planogram Platform

Shelf assortment and product analytics for a global food brand's internal planning platform — raw shelf data into decision intelligence.

Kellanova · FMCG · 2024In progress
04

GenAISys — AI Monitoring Platform

A watchtower for an enterprise GenAI chatbot — utilisation, performance, RCA, and monitoring. UX for systems that watch other systems.

Global Pharma · AI · 2025In progress
More Work

Figma files.

About

Hi, I'm Abhishek. I think before I sketch.

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.

Currently

Product Designer at MathCo.
Open to new opportunities.

Based in

Bengaluru, India

Domains

  • Pharma & Healthcare
  • FMCG & Food & Beverage
  • Automotive
  • Retail
  • Enterprise Information Management
  • AI / Agentic Systems

Frameworks

  • OOUX + ORCA
  • AXIS (my own)
  • Jobs-to-be-Done
  • Design Thinking

What I bring

Skills across the full arc.

Research & Strategy

  • OOUX system definition
  • Object & attribute mapping
  • User interviews & synthesis
  • Heuristic evaluation
  • Stakeholder alignment

Design & Execution

  • Low-fi to hi-fi wireframes
  • Design systems
  • Interaction patterns
  • Salesforce LWC design
  • Prototyping

Delivery & Leadership

  • Client-facing consultancy
  • Cross-vendor coordination
  • Framework development
  • Data visualization
  • Design documentation
01 / IPJ — Intelligent Patient Journey

I designed the system
before anyone built
a single screen.

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.

OOUX ORCA Framework Enterprise Healthcare Salesforce Design Consultancy Systems Thinking
2 months, full involvement
Lead Designer & Design Consultant
Design Manager, Junior UI Designer (I led)
Global Pharma Company (anonymised)
SF Visual Designer + SF Developers (external vendor)

Three meetings in,
something felt off.

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.

Week 1

The brief arrives

Global pharma client. Salesforce build. Multi-vendor setup. Timeline pressure. "Design the patient journey."

Week 1–2 · The moment

I notice the real problem

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.

Week 2

I propose OOUX

Not assigned. Not prompted. I put it in front of the team as a risk mitigation tool, not a research phase.

Week 2–6

Research, synthesis, framework

42 objects identified. System model built. Role-permission matrix defined. All before a single Figma frame.

Week 7–8

Low-fi handoff to SF team

Structural wireframes grounded in the object model, handed to the Salesforce visual designer and developers.


Two rooms pushing back.
One designer holding the line.

The Client Said

"We don't have time for research. Show us screens. We know what we want."

My Team Said

"We've never done OOUX on this account. Do we actually know how to run it? Will the client buy it?"

What I Did

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.

Leadership Note

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.

What I Delegated

Execution: screen iteration, copy-paste work, UI assembly. I kept my headspace for thinking. That's a deliberate choice, not a convenience.


OOUX + ORCA.
Not a methodology. A lens.

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.

O

Objects

The core nouns of the system. Not features — entities with identity, attributes, and life. Patient. Case. PA. BV. Fill. Appeal.

On IPJ: 42 objects identified. 28+ core objects mapped with full attribute inventories.
R

Relationships

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.

On IPJ: Has-1 → single field. Has-Many → lists. Has-0-1 → conditional sections.
C

CTAs

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.

On IPJ: CTAs per object defined before any button was drawn. Role-based CTA visibility built into the permission model.
A

Attributes

What each object contains — separated into Core Content, Metadata, and nested Object Relationships. Each category drives different design decisions.

On IPJ: Core Content drove form fields. Metadata drove filtering and status. Relationships drove navigation.
Why This Matters for Developers

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.


Six artefacts.
Zero guesswork for the dev team.

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.

01 Object-Attribute Map
↗ Click to expand

Object-Attribute Map

34 objects as columns, attributes as rows. Colour-coded: yellow = Core Content, pink = Metadata, blue = Object + Relationship. The canonical reference for all teams.

02 System Model
↗ Click to expand

System Model

Patient as the root object, with Has-1, Has-Many, and Has-0-1 typed relationships cascading to 20+ dependent objects. This determined the entire navigation structure.

03 Role-Object Matrix
↗ Click to expand

Role-Object Matrix

6 user roles mapped across 28+ objects. CRUD, Update, Share, Connect, or NA — per cell. The Salesforce team's permission model, before a single screen existed.

04 Object Identification
↗ Click to expand

Object Identification Doc

Every object formally defined: name, structure, instance examples, and purpose. This document ended the vocabulary disagreements between teams.

05 Interventions by Scenario
↗ Click to expand

Intervention Priority Matrix

35+ patient scenarios rated by intervention priority (High / Low). This translated clinical context into design decisions — what to show, when, and to whom.

06 Stage-wise Flags
↗ Click to expand

Stage-wise Intervention Flags

Per therapy stage, which patient signals require immediate attention. This directly informed what data the UI needed to surface at each journey step.


One screen. Six states.
That's the OOUX system working.

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.

Full Patient Profile
Patient Profile — Full Object View  ·  Internal Reference Screen ↗ Click to expand

What didn't happen
is the result.

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.

28+
Objects Defined
Patient through Copay Claim — complete system coverage before a single screen was built
6
Roles Mapped
Intake, Care, Insurance, FRM, PAP Agent, Contact Centre — all before UI began
0
Structural Rewrites
The dev team built on a correct foundation. No objects discovered wrong mid-sprint
2
Months
Full delivery: research → artefacts → low-fi handoff to multi-vendor SF team

What would have
gone wrong without this.

  • Development standstill

    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.

  • Client confusion on priorities

    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.

  • Multi-vendor misalignment

    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.

  • Potential project loss

    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.

What I Did That Others Wouldn't

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.

On Proposing OOUX

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.


I don't just design.
I diagnose.

I think in systems,
not screens.

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.

I know which
framework to reach for.

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 lead by
making space to think.

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.

I translate
pushback into progress.

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

Case Study 2026 · Global Pharma · Web + Tablet · React

The 340B Hub —
Transparency
Dashboard

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.

ClientGlobal Pharma Company
PlatformWeb + Tablet · React
My RoleSole Designer · Client-Facing
Timeline6 Weeks · Concept to Final
What I Shipped

A tool people could
actually argue with

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.

National Transparency Dashboard
National Overview — Default State

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.

State drill-down view
State Drill-Down

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.

Entity-level detail
Entity Detail

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.

5 → 1
Concept directions explored, then converged with the client to a single build
6 wks
From first KT session to a stakeholder-approved final prototype
1 layout
One structure reused across national, state, and entity scopes
Sole
Designer on the project, working directly with the client throughout
The Craft

How I made the
argument legible

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

Questions as section headers

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.

One conclusion per section, set large

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.

A map that fills by intensity

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

Making the abstract physical

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.

Context where it's needed

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.

Consistency as a feature

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.

How I Worked

Six weeks, and a real
point of view

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 learned the domain before I designed

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.

I talked to users and heard the real problem

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."

I showed five directions, not one

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.

I iterated toward simplicity

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.

I built it to sell itself

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 Reframe

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.

A Judgment Call I'd Defend

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.

What the Extra Weeks Bought

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

01 · Diverge

Five concepts

Distinct directions, shown side by side.

02 · Converge

Down to two

Chosen with the client, taken to wireframes.

03 · Reframe

Report → argument

Transparency framing becomes the spine.

04 · Iterate

Refine to clarity

Cut density, enlarge takeaways, sharpen story.

05 · Final

Ship

Prototype, stakeholder-approved.

Judgment

The decisions
behind the work

A senior designer is defined less by what they make than by the calls they make. These are the ones that shaped this project.

01

I designed for the room, not the screen

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.

02

I led with the conclusion

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.

03

I put the hardest insight where it could be felt

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.

04

I chose restraint over novelty

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.

05

I treated the client relationship as part of the design

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.

Outcome

A capability they didn't
have before

"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 Affairs

The 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.

What Changed

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.

Independent Research · Conversational Experience Standard · v1.0

AXIS

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.

14
Evaluation Axes
5
Domains
42
Criteria

Abhishek Dobriyal

Product Designer
Research-first · Systems-led · Never just execution

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.

Product Designer
MathCo  ·  Bangalore
April 2025 – Present

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.

Associate Consultant (UX)
Capgemini  ·  Gurugram
July 2022 – April 2025

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.

User Centered Design
User Research
Usability Testing
UX Auditing
Enterprise Applications
B2B & SaaS Product
Agile Methodology
Data Visualization
OOUX Methodology
Crisis Management
Figma & FigJam
Jira Certified
OOUX + ORCA
Object-oriented UX for defining system structure before screens. Used to prevent structural rework on complex enterprise builds.
AXIS Framework
Proprietary conversation design auditing framework — 14 evaluation axes, 5 domains, 42 criteria. Independently developed.
Design Thinking
End-to-end application from discovery and synthesis to ideation, prototyping, and validation.
Jobs-to-be-Done
Outcome-led research framing to uncover the real motivations behind user behaviour.
Bachelor of Product Design
Unitedworld Institute of Design, Ahmedabad  ·  2018 – 2022
Pharma & Healthcare FMCG Automotive Retail Food & Beverage Enterprise Information Management AI / Agentic Systems Data Analytics