Index

Back home

Smart Scheduling —

From feature request to

AI-powered platform

How a simple request for a "shopping cart" booking experience — book multiple appointments, for multiple patients, in one session — became the trigger for reframing the entire scheduling system around natural language, context-aware logic, and clinic-side configurability.

Multi-patient bookings

14%

Share of sessions that now include more than one patient — a flow that didn't exist before.*

(*For the clinics adopt this feature)

Increase in bookings

26%

The clinics are witnessing a general increase in appointments since the adoption.

(*For the clinics adopt this feature)

01 · The Request
The ticket that landed on my desk was deceptively simple.

A partner clinic — and, shortly after, a half-dozen others — asked for a "shopping cart" style scheduling flow. The product team agreed, engineering estimated a few sprints, and it landed in design discovery.

"Shopping cart" multi-appointment booking
Book multiple appointments in one session

Physical + lab + follow-up, without checking out between each one.

Book for multiple patients

A parent scheduling for themselves and two children, in the same flow, without re-entering insurance.

Consolidated checkout & confirmation

One confirmation screen, one set of reminders, one cancel/rebook surface.

02 · Discovery
Then I started prototyping.
The floor gave way.

Two weeks into design exploration, every path to the shopping cart surfaced a system-level constraint. The feature wasn't hard because the UI was hard. The feature was hard because the system underneath was linear, rigid, and single-subject by assumption.

Finding 01
One patient per session

The scheduler authenticated a single patient per session and threaded that ID through every API. "Book for my kid" meant logging out and back in.

Finding 01
One patient per session

The scheduler authenticated a single patient per session and threaded that ID through every API. "Book for my kid" meant logging out and back in.

Finding 02
One appointment per transaction

Each booking was its own atomic call. Multiple appointments created cascading edge cases: partial failures, conflicting holds, no way to roll back.

Finding 02
One appointment per transaction

Each booking was its own atomic call. Multiple appointments created cascading edge cases: partial failures, conflicting holds, no way to roll back.

Finding 03
Rules lived in code, not config

Every clinic rule — "physicals need 30 min with primary, labs need a fasted slot before 10am" — was hard-coded. A cart across visit types would need a release per rule change.

Finding 03
Rules lived in code, not config

Every clinic rule — "physicals need 30 min with primary, labs need a fasted slot before 10am" — was hard-coded. A cart across visit types would need a release per rule change.

"If we ship the shopping cart as-designed, we'll own the edge cases forever. Every new clinic, every new visit type, every new rule becomes an engineering ticket. We're not building a feature — we're papering over a system."
"If we ship the shopping cart as-designed, we'll own the edge cases forever. Every new clinic, every new visit type, every new rule becomes an engineering ticket. We're not building a feature — we're papering over a system."

— my design review note · sent to eng + PM

03 · The Reframe
So I went back to PM and engineering with a different proposal.

Instead of building a cart on top of the existing scheduler, what if we used the pain of the cart as a forcing function to redesign the scheduling system itself — one that could handle any multi-entity booking, not just the requested one?

What was asked for
A feature.

Ship a shopping cart on top of the existing scheduler. Scope it. Contain it. Move on.

Solves: one clinic's use case

Time to ship: 4–6 sprints

Edge cases: owned forever by eng

Future requests: another ticket, another sprint

What I proposed instead
A platform.

Rebuild the scheduling primitives so every booking flow — single, multi-appointment, multi-patient, rescheduling, clinic-defined — becomes a composition, not a feature.

Solves: every current and future booking case

Time to ship: phased · quarter-by-quarter

Edge cases: expressed as config, not code

Future requests: clinic sets it up themselves

The hardest part wasn't the design. It was the conversation. Reframing a P1 feature request as "we should rebuild the system" is a political act. It only works if the alternative is grounded in evidence, respects engineering's estimates, and opens — not closes — the roadmap.

04 · Collaboration
Engineering wasn't an audience for the reframe — they co-authored it.

Before any of this reached leadership, I spent four weeks with the scheduling platform lead mapping what a truly flexible booking primitive would look like. Design artifacts and system diagrams evolved together on the same Figma board.

01
Phased scope

We agreed on a three-phase plan: (1) re-model the booking primitive, (2) ship natural-language input, (3) ship the clinic-side configurator. Each phase de-risked the next.

02
Shared success metric

Not "ship the cart." Instead: "cut time-to-build per new booking flow from 4 sprints to 4 days." Both design and engineering could pull toward the same number.

05 · The Platform
What shipped wasn't a cart. It was a set of primitives.

Three interlocking systems, shipped in phase, that together let patients book anything — and let clinics configure anything — without another line of code.

01
Primitive · Flexible booking core
A booking model that doesn't assume one patient, one slot, one rule.

We re-modeled the scheduling primitive around a session — a transaction that can contain any number of subjects (patients), any number of appointments, and any number of rules. The shopping cart became a special case of this model. So did solo booking. So did rescheduling. So did clinic-side rebooking on behalf of a patient.

Multi-subject sessions

Shared insurance & identity

02
Surface · Natural-language patient flow
Patients stopped filling out forms. They told us what they needed.

The old flow was a chain of rigid dropdowns: patient, then provider, then visit type, then date. The new flow opens with a single prompt — "What do you need to book today?" — and uses an AI layer that turns natural language into a structured booking session. Context-aware logic resolves the rest: family members on file, provider rules, real availability, insurance scope.

One-field entry point

Patient + provider + availability inference

Clarifying follow-ups, not error statesvider + availability inference

Carry-over across children & dependents

03
Surface · Clinic-side configurator
Admins now describe their scheduling rules. The system builds them.

This was the quiet win. Instead of filing a ticket — "we need same-day pediatric sick visits to block out the first lab slot of the morning" — a clinic admin types that sentence into the configurator. The AI layer turns it into a versioned rule, shows them the affected flows, and lets them preview the change on a simulated day before publishing.

Natural-language rule authoring

No engineering in the loop

06 · Before / After · Patient
The same goal. Book a physical for me, a check-up for my son.

Left is what the original scheduling would have been — stapled on top of the rigid system. Right is what went live once the platform existed underneath.

Before · rigid & linear
4 flows. 2 logins. 1 parent losing patience.
01
Logs in as herself

Picks specialty → provider → visit type → date → slot. Confirms.

+0:00

02
Logs out

The session is scoped to one patient. No way to switch.

+2:40

03
Logs in as her son

Re-enters insurance. Re-chooses provider. Re-navigates every dropdown.

+4:10

04
Gets two separate confirmations

Two reminder threads, two cancel links, two sets of intake forms.

+6:25

After · one session, natural language
"Physical for me and a check-up for Leo, same afternoon."
01
Types the whole goal in one line

The system recognizes her, looks up Leo on her family account, reads both provider rules.

+0:05

02
Sees 3 paired-slot proposals

Same afternoon, back-to-back, correct providers. Age-appropriate rules already applied.

+0:14

03
Confirms once

The session commits both appointments atomically. If one fails, neither books.

+0:22

04
One thread. One invite. One intake.

Both appointments in one confirmation, one reminder chain, one tap to move either or both.

+0:35

07 · Patient surface
One field replaces every dropdown.

The AI layer doesn't chat at patients. It does the opposite: it listens for one sentence of intent, infers everything it can from context, and only asks when it has to.

Smart Suggestions, Not Manual Search

The system understands patient context and surfaces the best appointment options — date, provider, and location — without requiring manual filtering.

Blending structure with flexibility

Critical information is captured through structured inputs, while the rest of the experience remains conversational — reducing friction without sacrificing accuracy.

Multi-subject, multi-appointment

A single session can carry the patient plus any number of dependents, each with their own appointment. The booking primitive treats this as one transaction.

Fast selection with familiar UI

For precise actions like picking a time, we use a bottom sheet with structured options — allowing users to quickly scan and confirm without friction.

Smart Suggestions, Not Manual Search

The system understands patient context and surfaces the best appointment options — date, provider, and location — without requiring manual filtering.

Blending structure with flexibility

Critical information is captured through structured inputs, while the rest of the experience remains conversational — reducing friction without sacrificing accuracy.

Multi-subject, multi-appointment

A single session can carry the patient plus any number of dependents, each with their own appointment. The booking primitive treats this as one transaction.

Fast selection with familiar UI

For precise actions like picking a time, we use a bottom sheet with structured options — allowing users to quickly scan and confirm without friction.

Smart Suggestions, Not Manual Search

The system understands patient context and surfaces the best appointment options — date, provider, and location — without requiring manual filtering.

Blending structure with flexibility

Critical information is captured through structured inputs, while the rest of the experience remains conversational — reducing friction without sacrificing accuracy.

Multi-subject, multi-appointment

A single session can carry the patient plus any number of dependents, each with their own appointment. The booking primitive treats this as one transaction.

Fast selection with familiar UI

For precise actions like picking a time, we use a bottom sheet with structured options — allowing users to quickly scan and confirm without friction.

08 · Clinic Surface
The same AI primitive runs on the clinic side, too.

This was the real payoff of the reframe. If booking rules can be expressed in natural language on the patient side, they can be authored in natural language on the clinic side — and instantly reshape every flow downstream.

Admins stop filing tickets. They start writing sentences.

The old workflow: a clinic ops lead emails their account manager, who files a ticket, which becomes a config change, which eventually ships in a release. Time: anywhere from 2 days to 2 months. The new workflow is one conversation in the configurator.

Describe the rule in plain language

"Same-day pediatric sick visits should block out the first lab slot of the morning." — the AI translates this into a structured, versioned rule.

Preview the consequence

Before publishing, the admin sees a simulated week with the rule applied — which slots appear, which disappear, which patients would be affected.

Publish, version, roll back

Every rule is versioned. "Go back to last Tuesday's configuration" is one click. No release needed. No engineering in the loop.

Rules compose, don't conflict

The AI layer flags conflicting rules before they ship. If "no walk-ins on Fridays" collides with "always accept acute pediatric same-day," the admin sees the collision and picks a winner.

09 · Outcomes
The original request shipped — and so did everything it hinted at.

The shopping cart is a feature inside the platform now. It took three sprints to enable for the partner clinic that requested it — because the hard work had already been done underneath.

Multi-patient bookings

14%

Share of sessions that now include more than one patient — a flow that didn't exist before.*

(*For the clinics adopt this feature)

Increase in bookings

26%

The clinics are witnessing a general increase in appointments since the adoption.

(*For the clinics adopt this feature)

10 · Reflection
What this project taught me about being a designer.
Lessons
01
The feature request is the tip of the iceberg.

The shopping cart was the request. The actual need was a scheduling system that didn't treat every new case as a release.

02
Design is not just the surface.

The most important design artifact on this project was a data-model diagram made on the engineer's screen — not a screen I drew.

02
Design is not just the surface.

The most important design artifact on this project was a data-model diagram made on the engineer's screen — not a screen I drew.

03
Reframing is a political act, not just a design one.

I earned the right to say "let's rebuild the system" by first earning engineering's trust. No reframe survives an adversarial room.

04
The quietest win is the biggest win.

The clinic-side configurator doesn't look like AI. It looks like nothing changed. That's the point — the work is invisible because it finally fits.

What's next

The platform keeps absorbing what used to be feature requests. On the roadmap: pre-visit readiness (intake, insurance, labs-before-visit) composed as sessions inside the same primitive — and clinic-side analytics that let ops leads watch their rules' consequences in real time.

The reframe also changed how our design team works. We now ship a single "system brief" at the start of any large initiative — a document that names what's feature, what's platform, and which decision has to be made before Figma opens. It's become the artifact I'm proudest of from this project.

The original ticket said "shopping cart." The product that exists today can book one appointment, or twelve, for one patient or a family, described in a single sentence, governed by rules a clinic wrote yesterday. That's what happens when a feature is allowed to become a platform.