Kaiser
Permanente
How virtual care could live inside the existing platform — before “telemed” was a thing anyone was building.
Kaiser already had My Doctor Online, a platform organized around individual doctors, each with their own page. Telemed wasn’t part of it and barely existed at the company. I was brought in on a genuine skunkworks effort — no KPIs, no roadmap slot, no promise anything would ship — to answer “what if?”
Some projects arrive with a spec. This one arrived with a question.
Kaiser Permanente already had My Doctor Online— a platform where patients found their doctors, read their pages, and managed their care. Telemedicine wasn’t part of it. In fact telemed wasn’t really a thing at the company yet at all. My job was to explore what it could be.
“What if?”
No committed roadmap slot. No KPIs. No promise anything would ship. A genuine skunkworks look into the future.
The idea isn’t the point
Telemed is table stakes now — so what matters is what the idea is made of: spotting where a fast-growing product would break, and designing it to hold at scale.
The simple question hid a structural one.
“How would a telemed platform work inside My Doctor Online?”
MDO is organized around individual doctors. So where does telemed attach?
Every doctor had their own page. If virtual care was going to live in this world, that placement decision would shape everything that came after it. The interesting design problem wasn’t the screens — it was the architecture underneath them.
The intuitive answer: put the flow on every page.
Embed a video-visit flow on each doctor’s page — so a patient books right where they’re already reading about their physician. The context they’re in carries the moment. It’s the obvious placement, and it’s where I began.
It didn’t survive contact with scale.
A flow on every page means every flow has to be built, maintained, and kept in sync across a very large roster of physicians. Change the visit experience once, and you change it everywhere.
So I inverted it. One shared flow, two ways in.
Instead of a telemed flow per doctor, one single shared telemed flow— one canonical experience to build and maintain — with contextual launch buttons living on the doctor pages, and the patient’s context preserved on the way in. This is the spine of the whole concept.
One home, context-aware.
The shared home carries a persistent “Visit a Kaiser Permanente Doctor via Video” action — and renders context-aware. Land on it with no health center and it prompts you to choose. Arrive with one attached — a real pilot framing, the NV Health Center on the NVIDIA campus — and it pre-fills the location, address, and hours. Same page, two states, driven entirely by the context you came in with.
the shared home — one page, two context states
A six-step verified wizard that forks on context.
A verified booking wizard runs a short identity gate — member last name, birth month & year, medical record number, CAPTCHA — then forks on exactly the context logic above:a cold start opens on a doctor picker, while an entry from a physician’s page carries the doctor straight in, no re-selection.
the booking wizard — same steps, forks on context
Launch from anywhere; the same flow catches you.
The doctors directory (in the hero) is where the launch buttons actually live — one per physician, beside their bio and hours. And an Hours & Appointments / FAQ layer handles the questions a new virtual-care patient predictably asks, so the concept reads end to end — all feeding the one shared flow rather than a maze of per-doctor variants.
No confirmed stack — so I inferred a provisional one.
The honest hard part wasn’t the interaction design — it was the absence of constraints. With no confirmed technology stack and no platform team telling me what was possible, I inferred a plausible one from My Doctor Online and designed forward as if the concept would be housed on something similar. That assumption wasn’t meant to be correct — validating it was explicitly not the point — it was scaffolding: just enough certainty to explore the experience instead of stalling on unknowns. When there are no parameters, part of the job is manufacturing your own.
A concept build: sketch, pressure-test, land the architecture.
The activity here was brainstorming and wireframing — not research or validation. I sketched the placement options, pressure-tested them against how the platform would behave at scale, and landed on the flow architecture that would hold up.
The placement options
Per-page embed vs. one shared flow — draw both, make the trade-off visible.
Against scale
Run each option forward against Kaiser’s roster — which one breaks, and where.
The full concept, end to end
Telemed home, doctors directory, six-step booking wizard, Hours & FAQ — enough to read as a system.
A defensible point of view where there’d been a question.
This was an exploration, and it delivered what explorations are supposed to: a concrete concept and a defensible point of view where there had been only a question. The core outcome was the flow architecture — one shared telemed experience with contextual launch points on doctor pages — which sidestepped the maintenance trap of per-doctor flows and gave Kaiser a scalable pattern to reason about.
I do my sharpest work inside constraints — so here I had to build my own.
Read today, when telemed is table stakes, the point isn’t the idea — it’s what the idea is made of. Constraints aren’t the enemy of creativity; for the way I work, they’re what makes it possible. The work wasn’t the screens; it was the structure underneath them.
A concept exploration with no KPIs by design — so there are no measured outcomes to quote.