THE ART & SCIENCE OF SEAMLESS EXPERIENCES

Leading research and product definition for a clinical AI in a high-trust environment

A large Health Maintenance Organization faced a strategic question with no obvious answer: How can artificial intelligence improve physician efficiency and clinical outcomes in a way that becomes a marketable solution?

The opportunity was real, but the path was not. Physicians were drowning in a growing body of medical literature, short on time, and often unsure whether their electronic health records held the most current picture of a patient. My charge was to take that ambiguous business problem and shape it into a defined AI product concept — one grounded in physician reality and built on trust.

At a Glance

Business problem: Turn a broad AI ambition into a defined, marketable physician decision support product
My role: UX strategy and research lead; owner of the research plan, hands-on across every phase, and active in shaping design between iterations
Team I led: Senior Design Researcher and Anthropologist, UX Designer, and Product Manager (direct reports)
Cross-functional partners: Chief Medical Officer, Enterprise Architect, Data Engineer, and Client Account Executive
Approach: Ethnographic fieldwork, a three-day Design Thinking workshop, synthesis, and MVP prioritization
Key outputs: Research-driven persona, As-Is and To-Be journey maps, prioritized Hills, and a clear MVP direction
Strategic value: A defensible product concept for AI-assisted clinical decisions, framed around trust, evidence, and workflow fit

Research Driven Persona: Paul the Physician

The Challenge

Product Definition

The client knew AI could help physicians. What they didn't know was how — or whether any version of it would actually earn a place in a clinician's day.

The problem was harder than it looked. Physicians weren't just short on time; they were handling the same literature again and again, and they didn't automatically trust the sources or the systems in front of them. Fragmented electronic medical records made the picture worse, with data scattered across practices that couldn't reliably talk to each other.

So the real work wasn't building a feature. It was resolving ambiguity: separating what physicians said they wanted from what they actually needed, and defining a product that leadership could confidently invest in and take to market.

The Approach

I designed the engagement so a small, senior team could move quickly and still reach conclusions the client trusted.

Ethnographic fieldwork. I built the research plan and ran a series of ethnography studies to understand how physicians consumed and applied medical literature in practice. This surfaced patterns no survey would have caught — including how often physicians reprocessed the same information and how much they worried about the trustworthiness of what they found.

Three-day Design Thinking workshop. I facilitated a cross-functional workshop with physicians, product managers, developers, and the sales team. Bringing these perspectives into one room early kept the eventual product grounded in clinical reality and commercial viability at the same time.

Synthesis. We turned fieldwork into structure, connecting physician pain points to the broader system and data environment around them. This is where adjacent issues — like EMR fragmentation and weak interoperability — moved from "out of scope" to central design constraints.

MVP prioritization and Hills. We sketched the strongest feature concepts, then used them to decide what genuinely belonged in an MVP. The Hills gave the whole team a shared, outcome-focused definition of success to build toward.

Key Insights

The research reframed the problem for leadership. A few findings shaped every decision that followed:

Trust was the real barrier. Physicians needed to validate and trust the source of any literature before they would act on it. Speed alone wasn't enough.

Effort was being wasted. Physicians were handling the same literature multiple times, with no system to capture or reuse prior work.

The data foundation was fragmented. Disparate sources produced inconsistent reporting, and systems couldn't exchange information between practices — which directly limited what any AI layer could credibly promise.

Together, these insights made one thing clear: an AI tool would only succeed if it was transparent, evidence-backed, and built to fit the physician's existing workflow.

Product Direction

From synthesis and prioritization, we defined a physician decision support concept anchored in three outcomes — captured as our Hills:

Ranked treatment options in one place. Paul, the acute-care physician, can view treatment options ranked from exhaustive research for a specific patient — without hunting across sources.
Evidence he can stand behind. He knows a choice is sound because he can see the inputs that substantiate each option, turning a black box into a decision he can defend.
Learning built into the work. By surfacing evidence-based options he wasn't aware of, the tool helps him continuously learn and adapt.

This gave the client a concrete, buildable direction: not a vague promise of "AI for physicians," but a defined product shaped around trust, evidence, and daily use.

Role and Team

I owned UX strategy and research for this engagement, from the research plan through synthesis and product definition. I stayed hands-on across every phase and worked closely with design to make rapid changes between research iterations, keeping the concept moving as fast as our learning did.

My direct reports:

Senior Design Researcher and Anthropologist
UX Designer
Product Manager

Cross-functional partners:

Chief Medical Officer
Enterprise Architect
Data Engineer
Client Account Executive

Much of the value I added came from connecting these perspectives. I translated between clinical priorities, technical constraints, and commercial goals — earning the Chief Medical Officer's confidence in the clinical grounding while keeping the Enterprise Architect and Data Engineer honest about what the data environment could actually support.

How the artifacts drove decisions

The deliverables weren't outputs for their own sake. Each one moved the work forward:

"Paul the Physician," the research-driven persona, aligned a diverse team around a single, realistic user — his time pressure, his workload, and his distrust of incomplete records.
The As-Is journey map exposed exactly where physicians lost time and confidence, and made the case for why adjacent EMR problems couldn't be ignored.
The To-Be journey map gave stakeholders a shared picture of the future experience and a reason to invest in it.
The Hills turned open-ended ambition into prioritized, testable product commitments that scoped the MVP.

Why It Mattered

This engagement is a clear picture of how I lead. I take an ambiguous, high-stakes problem — part technology, part clinical practice, part human behavior — and turn it into a product strategy a leadership team can act on.

It also reflects a conviction I bring to every product and team I lead: AI in healthcare only creates value when it earns trust. Physicians won't adopt what they can't verify, and they won't rely on what doesn't fit how they work. My job is to make that trust real — through transparent evidence, sound research, and an experience built around the clinician — and to lead the people who bring it to life.