VirtuMedix As Sr UX Designer

Helping patients to schedule an virtual doctor appointment on Virtumedix

Virtumedix is a cross-platform early-stage cross-platform virtual medicine product for clinics, insurance companies, pharmaceutical trials, pharmacies, and institutions.

As the Sr UX and UI designer and Information Architect, I worked with the product and engineering teams based in Aliso Viejo, California. My job was to add a scheduling component and improve the application's overall usability across all platforms.

I took ownership of the Virtumedix UX in mid-2016. I worked with the product, engineering, and sales team leaders to upgrade the UI and design a new foundation of scheduling appointments into the system.


First Challenge

The existing UX framework

The existing UX framework at the time was not consistent across platforms. Nor did it align with expected patient experiences. The framework needed to be customized in order to make user friendly experiences.

The old framework and style guide


UI Redesign

For Virtumedix to move forward, it needed a new user-friendly cross-platform design system for the white-label customers. We created the following design system for the current version, with a design language that could serve as the foundation for new features.

To optimize the process, I documented all of the platforms in their current states and defined what would receive the new design. We reviewed with the key stakeholders and completed the needed work to determine the style and deliver in 6 weeks.

Master Adobe XD files held all design pattern documentation and color systems for each white label customer. We shared online prototypes internally via Jira feature stories. We shared in-app elements with the developers via Github.


Second Challenge

Design the scheduling component

We started with an undefined Scheduling feature request that might significantly impact the overall application experience. First, I wanted to understand what the scheduling component required in order to be effective for the user.

Specialist Value

I soon learned that specialists require scheduling and that generalists did not. Our primary goal thus became matching available specialists to the patient. A secondary objective would be to allow patients to search for their generalist doctor by name.


Scheduling systems for Patients

Discovering scheduling complexities of 3rd party scheduling components.

3rd party scheduling systems for patients were complex, highly customized, and very expensive. They did not match the patient experience we wanted to create.


Doctor schedules

To understand specialist availability, I familiarized myself with some of the doctor groups' scheduling systems at the time. All were complex, expensive, and highly customized for each physician group. Fortunately was outside our objective scope. We would ingest and update availability from these systems.


Competition Analysis

Competition

Doctor On Demand

Doctor On Demand Discoveries
Pros - threats
• Massive funding: $75MM+
• See a medial doctor now option (like virtumedix)
• Building framework and foundation for larger business (with more doctors and groups)
• Relationships with major health companies
• Major Group Types in one app: Medical, Mental, Pediatrics, Pregnancy & Newborns

Cons - can we improve upon
• One-Size-Fits All App not congruent with diverse medial groups and practices.
• Not enough local doctors to fill the calendar or queue.
• See a Doctor Now / Schedule Appointment flow had long questionnaire to complete either.
• FREE Chat did not connect with doctor at all.
• Press, Media, Blog, FAQ, About are not necessary in an app.
• No cash option. Required an insurance provider account

Our competitors, though well funded with scheduling components, were not doing scheduling well at the time. Neither Doctor On Demand, nor Teledoc, made the process easy to use.

This competitive analysis helped me understand our potential competitive advantage: Scheduling a Specialist Quickly and Easily.


Influencer

Hipmunk

Influential Learnings

A: Clear departure and destination and date
B: Available times
C: Search, then Book based on available results.

Note: If the user does not like the results offered, then the option to revise the search is presented consistently as an orange "Search" button on the results page, like on the start page.

Similarities and differences
Similarities:
A: High-cost future, potentially stressful "appointments."
B: Requires decisive action by the user.
C: Fulfill a custom need (destination/time or specialist/availability)

Differences:
A: Airlines tend to book further in advance.
B: Airlines require departure, destination, date, and "Search."
C: Specialists require specialty, patient state (i.e., CA, TX), and "Search."

Seeing such potentially a complex scheduling feature, like booking flights, executed so easily made the idea of scheduling a physician seem like a walk in the park!


Exploratory design and user testing with monthly calendars

Initially, the physician groups requested that we begin by show patients a two-month availability schedule for each specialist. The request was understood, designed, and tested for understanding.

Here is what we learned:
• Monthly-calendar views led to decision fatigue
• Booking more than a few days in the future was not the goal.
• Users wanted to see a doctor of their choosing "ASAP."
• The large calendar confused users. "Does this connect to my computer calendar?"
• Users described telemedicine as a "fallback" to visiting their doctor in person.


A design that worked

The new design created a bias toward action. With just a few clicks, patients could find a specialist, a time, and book it.

The Patient and Doctor user flows

The whole system was easy to diagram for the engineering team.


Design prototype testing

With a solid concept, I set about prototyping the whole system. I then leveraged the knowledge and experience of our QA teams. They were very good at finding obstacles and inconsistencies with the existing system.


I then began prototype testing with users in different parts of our office. All of these real-world users found the prototype very easy to use. They liked the direct action, reduced options. Each had experience booking doctors on the systems of our larger competitors. Since the process was simple, user testing was often brief.

Outcomes and learnings

Scheduling a specialist is now simple for patients. What took dozens of clicks in our competitors' apps now took six to ten on Virtumedix. Also, our scope reduction sped up the release date by several months. Patients of all ages found it easy to book and see a doctor.

Business outcomes: Corporate conducted an outside Business review. Virtumedix came in as the #1 in the industry for ease of use and speed in scheduling a doctor appointment. Based on the final scheduling version, six new clinics purchased white-label versions of the system over the next eight months.

Final Design. Select to see more.

Reflection

Respect the user bias to action

We attempted to begin with a calendar that created relatedness to a user's calendaring software in early iterations.

While testing our prototypes, we found that simplified design often goes hand in hand with obvious and straightforward terminology and minimal instruction—users in testing scheduled appointments more quickly when the flow supports it. Options tended to interrupt this bias and, at times, lead to abandonment.

Being responsible for crafting functional systems from scratch reminds me that ongoing research, reductive thinking, and questioning the details through the process are essential. Not only listening to users but watching what they do, led us to the final design solution.