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 designer, I worked with the product and engineering teams based in Aliso Viejo, California. My job was to improve the overall usability, look and feel of patient experience in all product areas. Also, I designed several significant new cross-platform patient feature experiences and white label variants.
I took ownership of the Virtumedix initial "design system" in mid-2016. I worked with the product and sales team leaders, in union with the engineering teams, to create and incrementally roll out a new design system.
Patients expected custom experiences, requiring a radical departure from the existing framework.
The old framework
The style guide
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 system picker manual for each customer. We shared online prototypes via Jira feature stories. Non-UI patterns, such as copywriting guides and icon libraries, were stored and transmitted via Github to developers.
We started with an undefined Scheduling feature request. The biggest concern would be that the feature could be complex and might significantly modify the application. We wanted to avoid that and were able to narrow the initial scope down to two primary mandates. Allow patients to schedule appointments, pick a doctor.
Specialist value. We discovered that Specialists required Scheduling over generalists and provided more value. Our primary goal became matching available specialists with a patient. A secondary objective was to allow a patient to search for their doctor by name.
Discovering scheduling complexities of 3rd party scheduling components.
Scheduling systems for physician groups are complex, highly customized, and very expensive. Fortunately, they were outside the scope of our objective.
A competitive analysis helped us to understand the USPs of our product. We soon discovered that many of our competitors were well funded. Our two primary competitors were Doctor On Demand and Teledoc. Both had scheduling components, and neither was doing it well at the time.
Having reviewed both, we discovered that we had a primary advantage over them - we were far faster and easier to use. The question was, how do we maintain that advantage while adding new features like Scheduling?
Airlines showed clear departure and destination cities, dates, and the "Search" button - all in one line. The actions are simple and lead to ticket purchases. The design avoided the monthly calendar, except for in the dropdown.
Scheduling a doctor could be more accessible. All the patient needed to select is a specialty, then choose from a list of available doctors who had times that worked for the patient.
General Learnings from airfare booking
To understand Scheduling's physician side, we reviewed some of the options, which turned out to be very complex, expensive, required long sales cycles, and fortunately landed outside our objective scope.
User testing: Monthly-calendar views led to decision fatigue
• The large calendar confused users. "Does this connect to my computer calendar?"
• Users wanted to see a doctor "now".
• Booking more than a few days in the future was not the goal.
• Users saw telemedicine as a "fallback" to visiting their doctor.
The new design created a bias toward action. With just a few clicks patients could find a specialist, a time and book it.
The whole system was easy to diagram for the engineering team.
With a solid concept, we set about prototyping the design so that QA could review it. We leveraged the knowledge and experience of the QA teams to find inconsistencies and potentially missing "unhappy" flows and error screens.
We then set about prototype testing with users. All of them found it very easy to use. They were happy because there were fewer options where our larger competitors were getting hung up. The bias was toward scheduling every time. Since the process was simple, user testing was often brief.
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.
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.