As SnapMD's first in-house design hire, I tackled the challenge of updating an enterprise healthcare web application comprised of "UI as far as the eye could see." Driven by the pragmatic need to design efficiently and consistently, I standardized the type hierarchy, colors, and layout specifications. I then built a library of reusable, versioned components in Sketch. As the design team grew to three designers, this foundational work allowed us to scale a standard approach to design and aspire to build a design system. While I designed a variety of new product functionality, this technical and tooling effort was my most important contribution and accomplishment during my first year with the company.
The slides below present a summary and overview of this work. I created this presentation for a talk a part of General Assembly's Inside the mind of brilliant designers series in downtown LA.
Case Study: Redesign of the application public pages
SnapMD provided a platform for healthcare providers to "spin up" a telehealth solution as part of the care services they offer in a physical facility. Customers utilized the platform via APIs or, more commonly, the Virtual Care product: a web application serving clinicians, administrators, and patients. Thus, an aspect of the product was available to anyone with an internet connection—we called these views the "public pages." The public pages were the entry point for all users, new and returning daily, so they were a central aspect of all user journeys.
My first major design project in early 2017 involved the public pages. I was tasked to design a single, unified landing view for all user types to access the web application. Previously, different users accessed login via different URLs, and there was no default presence for a customer instance. I began with an analysis of the login pages, but also all related pages.
I identified several technical and usability issues with the pages as a whole. However, the central problem I surfaced with the existing implementation was the need for options to create a unique customer presence; customers could only specify their name in the application typeface and select a single color to customize their software instance. While branding is an essential means to establish an identity for any company, branding in the healthcare space also engenders trust from users because it clearly signals they are using a solution directly associated with the company.
Working with the director of product, I established the following objectives for a successful redesign. While these objectives expanded the project's scope, they would deliver a foundational shift in the user experience and the look and feel of the product as a whole.
-
Establish a white-label structure that allows customers to customize their instance of the software with their own branding.
-
Improve visual design consistency across flows: registration, login, and error pages.
-
Ensure the design is fully-responsive.
Flow analysis
Before doing any visual design, my next step was to capture all UI language, inputs, and outputs in the existing registration. I then revised the steps and copy necessary to complete account creation.
Designing new inputs
The implementation of legacy inputs in the web application was the source of several problems. Because fields are displayed in many public page views, I needed to redesign the field component. The new component included a range of states, updated colors and graphics corresponding to those states, and inline validation error copy.
Unified landing and login views
Below are a few examples of how customers used the new branding variables in the white-label solution I designed.
-
Graphic asset (logo)
-
Color band
-
Tagline
-
Hero image
Motion design
To supplement static views of the UI, I used Framer to build a prototype to design the motion in the interaction to switch between login views for different user types. Unfortunately, the prototype disappeared with the sunsetting of Framer Cloud in 2022, but I've included a video export below. The production implementation of the design was faithful to the prototype because I created it using the same technologies our developers used to build the web application frontend (javascript/CSS/HTML).
Graphic specifications documentation
Our client success team performed extensive configuration of each customer instance on the platform. To utilize our white-label variables optimally and avoid extensive trial and error and back-and-forth with clients, I created documentation providing specific guidelines and dimensions to assist the team in procuring graphic assets. Facilitating good communication in this workflow helped to produce attractive, high-quality branding more consistently.
Reflection
Redesigning the public pages of the web application was my first design effort that fundamentally changed a product. The new look and feel of the interface, as well as the flexible branding options, immediately elevated the product's maturity while establishing the value of a systematic approach to UI design. I was fortunate enough to sit right next to our lead frontend developer, so collaboration was almost effortless. He helped coordinate a talented group of overseas developers to realize the design in a well-built implementation.
Where we succeeded
The flexibility of the componentized UI supported several additional flows and new technologies: the flow for guests to join a virtual visit without an account, an account activation flow for clinician users, single sign-on, and non-patient user registration.
The design scaled. We saw usage on the platform grow from several thousand successful patient visits per month to tens of thousands of successful patient visits per month by the spring of 2020—a 7x increase. These patients all completed registration and authenticated before completing a virtual visit.
If longevity is a success metric, this design has stood the test of time. It has remained unchanged in production releases for over six years on two different platform instances. A current production demo site is available at emerald.connectedcare.md.
Where we missed the mark
While I was able to implement some minor accessibility improvements in the design, such as a graphic indicator for error messages, labels for all fields, inline field validation, and a simple, predictable layout, we had to defer others to maintain our release schedule, such as a darker green on the primary-action buttons to pass basic contrast, keyboard navigation between elements, and support for screen readers. More complete accessibility updates never returned to scope for a subsequent release. I've learned that accessibility has to be part of the scope during the design phase rather than a nice-to-have the team will address at the end of a release cycle. It requires buy-in from engineering as well as product.
Looking back, the lack of formal user research informing this effort is striking by today's expectations. As the initial screenshots show, there was plenty of "low-hanging fruit" to address without requiring domain-specific research. I designed using web best practices, accessibility standards, systems thinking, and plain instinct. While this approach worked on several levels, I spent a substantial amount of time generating screen variations for approval from product management rather than first understanding our user's needs and advocating for those as the criteria we should mutually strive to deliver. I would have insisted we do more research if I were approaching this same project today.