SnapMD built both a web and mobile application to support virtual patient visits. As part of the standard product offering, all customers could provide a native mobile patient experience using the Virtual Care app. Providers interested in offering their own branded app in Google Play and the Apple App Store purchased the white-label app. When Virtrial acquired SnapMD in late 2020, we had over 25 instances of white-label apps available in the stores.
-
This "generic" mobile application is still in production under a new name and branding: Virtual Care Management (App Store / Play Store)
-
A handful of white-label versions of the app are still live. See Telescope Health (App Store / Play Store) and Ambient Care (App Store / Play Store) as examples.
Interface design
In the fall of 2019, we began a rebuild of the mobile experience from scratch in React Native. We delivered a code-complete app in five months and iterated for another six to achieve a release candidate. I was the lone product designer on the team. I handled the visual design of all views, creating and managing components in Sketch and Abstract, and articulating flows.
Interaction and flows
Building a SaaS platform for the healthcare industry requires support for many specific use cases. We achieved flexibility in the product to address different customer needs by making it highly configurable. The client success team enabled or disabled functionality modules, customer by customer, via a backend admin utility. Different configurations produced a wide range of states in the interface. Flows through the application also differed significantly from customer to customer, so the design team had to design for variability by understanding numerous branches for core flows in the application.
I typically used Overflow to document master flows in the application to ensure the views we designed covered all possible configurations. Patient Intake was one of the most complex flows for which we designed. Intake, which displays for the patient before entering a visit, could be disabled entirely or have numerous subcomponents enabled. Below is an overview of the master flow for intake before a scheduled visit. I maintained an alternate diagram for on-demand visits. (For details, peruse the diagram itself.)
A key piece of functionality on our platform was a proprietary forms engine. It allowed customers to display customized forms at various points in the application to gather specific data required for their use cases. Designing this engine was an interesting challenge because the content shown was variable rather than fixed. I created specifications for eleven general controls, articulated structures to display those controls, and defined how a person navigated through all states of a form.
To supplement artifacts like the above, I used clickable prototypes to quantify motion design and convey how interactions should feel to guide engineering during development. This early-stage clickable prototype brings to life the essential aspects of the interaction model for completing a form.
While I designed the configurable form views for the mobile application, another designer on my team handled the same views and flows for the web application. We collaborated on the design to ensure the experience was similar for patients using either modality. I liaised with engineering to support building one implementation that either interface could utilize.
This aspect of the application was my deepest dive into systems design. It allowed our solution the flexibility to support a myriad of use cases while ensuring the patient experience was aligned regardless of how they engaged with the product.