Company: Teladoc Health

Role: Lead Product Designer

Timeline: 3 Months

Enabling Provider Scheduling with AI Prototyping

OVERVIEW

PROJECT OVERVIEW

As a UX designer at Teladoc Health, I led the discovery and prototyping of a new scheduling experience for our Hospitals & Health Systems product line. The goal was to empower provider organizations to manage their own shift availability while accommodating deep integrations with third-party scheduling systems.

This feature needed to serve both administrators (who set shifts across multi-state systems) and providers (who may set limited-time availability and need real-time consult routing). We aimed to determine whether to build vs. buy this solution based on usability and market needs.

PROBLEM 

We needed a comprehensive scheduling management solution to enable more complex features for our providers and administrators (such as matching consult requests with available providers). Beyond just integration, we needed to find quick solutions to meet clients where they were in their scheduling tool needs, be it a full solution or integrating within their current space.

PROBLEM VALIDATION

A SCHEDULING TOOL AUDIT

I completed a quick audit on some commonly used tools for scheduling in order to get a better understanding of the language and common features being used.

A FAILED SURVEY

One of our biggest challenges was collecting user feedback within our limited timeline. I worked with our sales team to start building relationships with our clients and begin a process of building ongoing points of feedback. Despite initial outreach efforts over two weeks, we received limited engagement and ultimately paused the survey to redirect focus toward prototyping. 

Research goals:

  1. Understanding current scheduling pain points

  2. Validating feature needs and priorities

  3. Assessing workflow integration

  4. Evaluating value perception (buy vs. build)

  5. Understanding compliance and security concerns

View Survey

SOLUTION DISCOVERY

DEFINING A COMMON LANGUAGE

I collaborated closely with our engineering team to align our design taxonomy with FHIR HL7 standards (a universal healthcare integration language), ensuring a shared language across UI components, database structures, and API endpoints.  We started by creating a common language for us to build both our databases as well as our design concepts from. 

  • Shift: Is a block of time (start date/time and end date/time) an actor is available to provide a service (FHIR calls this a schedule).

    •  Actor(s): Resource(s) that availability information is being provided for. Actors can be a patient, provider, practitioner role, related person, care team, device, healthcare service, location. 

    • Specialty: Type of specialty needed

    • Name: Human-readable label of the shift/

    • Service: The specific service that is to be performed during the shift.

    •  Planning Horizon: Period of time covered by shift

  • Provider Schedule:  A collection of one or more shifts.

  • Service Request:  A request for a specific service.  

  • Healthcare Service Available Time: These are the hours that a service request can be submitted. and also known as the hours of operation. 

REFINING IN REAL TIME WITH AI PROTOTYPING

To meet these needs, we proposed a modular scheduling system within our platform with two entry points:

  • Manual schedule management, allowing admins to create/edit provider shifts by date, service, and state

  • CSV-based bulk upload, with downloadable templates, error handling, and post-upload editing

I worked with Lovable AI to prototype an MVP version of the feature. The prototype emphasized:

  • Filtering by provider, state, and service

  • Recurring shift logic

  • Lightweight calendar visualization

  • Provider-facing view for real-time availability toggles


I started with an initial prompt (below) and a couple of initial wireframes for reference.

  • We’re building a scheduling feature inside our telehealth platform. The goal is to allow practice administrators (our primary users) to manage provider availability efficiently—while also supporting API-based integrations with external scheduling tools.

    Most clients will prefer to integrate their existing scheduling tools via API. However, we also want to offer native capabilities within our UI for:

    Core Functionalities:

    • Individual Schedule Management

      1. Add working hours for a provider by selecting specific dates and times .

      2. Set recurring working hours (e.g., every Tuesday from 9–5)

      3. Delete individual working hours or entire recurring blocks.

      4. View a provider's schedule, filtered by service (see attached wireframe for reference)

    • Bulk Upload & Error Management

      • Download a CSV template to guide formatting (including: provider name, dates, start times, end times, service, etc.)

      • Upload a completed CSV file to populate the schedule

      • Identify and manage import errors directly in the UI via in-line editing or validation prompts

    • Definitions & Domain Concepts These are core concepts used in our scheduling model:

      • Shift: A block of time when an actor is available to provide a service (FHIR refers to this as a "schedule")

      • Actor(s): Entities for which availability is defined (e.g., provider, care team, device, healthcare service, location)

      • Specialty: The clinical specialty associated with the shift

      • Service: The type of care or interaction to be delivered during a shift

      • Provider Schedule: A collection of one or more shifts -

      • Service Request: A request for a specific service (e.g., virtual consult)

      • Healthcare Service Available Time: Operational hours during which service requests can be submitted

    • Expectations

      • We’re looking for a demonstratable prototype that shows both manual schedule entry and the CSV upload workflow. -

      • Interaction clarity is more important than final visual styling.

      • Please use the attached wireframe as a starting point—especially for filtering by service within the provider’s schedule view.

Reference wireframe 1 used during initial prompt

Reference wireframe 2 used during initial prompt

View Prototype

IMPACT

IN DEVELOPMENT

Although the feature has not yet launched, this work laid the foundation for a scalable scheduling system and informed our approach to integrating third-party tools across the platform. It also accelerated our ability to prototype and test with clients in future cycles.