Zocdoc Payments
Zocdoc Payments
̌
Zocdoc Payments
role + responsibilities
Product design, User research, Product strategy, Roadmap prioritization
TEAM
Product Manager, UX Copywriter, Engineering Manager, Engineers (x7), QA
timeline
March — April 2021
Background
Zocdoc is a healthcare marketplace that helps connect patients with qualified providers across a range of specialities. Our patient-first approach has created a more accessible and personalized healthcare experience for millions of patients across the United States.
Overview
At this time, the Intake product offered practices the ability to gather key pre-appointment information, such as insurance card images & consent, medical, and demographic forms. However, during our initial Intake research, we learned that payment collection, specifically copay collection, was an additional pre-appointment task that practices desired a streamlined solution for.
OPPORTUNITY
By adding a pre-appointment payment collection feature to our existing Intake solution, we could increase the number of practices using Intake by creating a product that facilitates all of their pre-appointment needs.
business Challenge
How might we create a payment collection feature to increase adoption of the Intake product?
USER CHALLENGE
How might we create a payment collection feature to reduce the number of tools practices are using?
Early Explorations
I had explored the concept of collecting copays from patients in my initial LoFi designs of the Intake product. Before diving into research, I spent more time refining this concept through more LoFi explorations.
Payment Hub Explorations
#1: Global controls only
#2: Patient-based + global controls
For research, I decided to pursue a high-fidelity version of exploration #2 as I felt the use of global and patient-based controls was more congruent with the interaction patterns of the Intake product. This version also fostered more focus on requesting payments from patients, which is the core use case of the feature.
Research
Since we heard the desire to collect copayments via the Intake product during Q4 2020 research, I wanted to conduct research focused on practices’ existing payment workflows.
Goals
Understand practices’ current payment collection workflows (tools/systems/devices used, roles involved, timing)
Understand what types of pre-appointment payments practices are looking to collect from patients (copays, visit fees, etc.)
Understand which actions practices need to take at a given moment when it comes to pre-appointment payment collection
Understand what opportunity areas exist in terms of integration with our existing Intake product
Understand how to better support practices in relation to payment collection
Methodology
I conducted 1:1 interviews with 8 practice users who were responsible for payment collection at their practices and were currently using Intake
Discussed practices’ existing workflows for payment collection, for both telehealth and in-person appointments, focusing on what works well and what could be improved
Evaluated proposed designs through a moderated usability test
Designs Evaluated
Requesting a payment
Initiating a refund
Research Outputs
Once research wrapped, I synthesized the sessions focusing on each participants’ discussed workflow and their impressions and reactions to the proposed designs.
Synthesis in Miro
Interview Summaries
Current Payment Workflows: Themes + Learnings
Design Evaluation: Reactions + Feedback
What I found
Current Product
Opting into the feature
We configured Payments as an additional feature available to all practices using Intake. It appears as a new tab within the Intake hub, but in order to leverage the feature, practices need to create an account with Stripe in order to set up their routing and payout preferences.
Sending a payment request
Practices can manually send out payment requests to patients prior to appointments for copays, deductibles, out-of-pocket expenses, and outstanding balances. These requests can be sent via email and text message, as informed by the research.
Sending a reminder
Practices are able to send patients reminders for incomplete payments via both email and text message. The communication method for sending the reminder will default to whichever method(s) the original payment request was sent through.
Viewing payment details and status
Similar to the pattern used in Intake, practices can view payment details for each request sent, including the status of the request—requested, paid, or refunded.
Payment request history
Our research indicated that a payment request feature would be more frequently utilized on a per patient basis than we saw with intake requests, as some practices can see patients as often as once per week. That said, it was important that the design account for a historical view of the requests and transactions that relate to a single patient.
Issuing a refund
During research, we heard that the ability to issue a refund was a necessary component of a payment feature. That said, it was important the design account for issuing partial and full refunds for paid transactions.
Patient specific payment request
Given the frequency of payment requests sent out per individual patient, I wanted the designs to facilitate a streamlined way for practices to send out another request to an existing patient. This flow would pre-populate patient information such as name, date of birth, and communication preference, with phone number and/or email address pre-populated as well.
Making a payment
Patients receive an email and/or a text message prompting them to complete the required payment for their upcoming appointment. They are then able to enter their credit card information to complete the payment.
Notification of Completed payment
Once a patient has completed their payment, the practice receives an email notification, prompting them to enter back into the Payment hub to view further details.
Performance + Impact
Though the user experience of this feature was entirely informed by research, our Payments product has had fairly low utilization.
5 practices actively using it each month
Practices are sending out ~125 payment requests each week
Completion rate of payment requests ~58%
Why is this?
In follow-up conversations with practices (both active and churned), we have learned many useful pieces of information to inform our low utilization rates:
Use case is too limiting. Though we wanted the first release of this product to just focus on pre-appointment payment collection to avoid getting into the intricacies of the billing workflow, practices have told us that not including the billing use cases has made the feature too limiting for their needs.
Patient-facing copy was too restrictive. Given the pre-appointment use case, our patient-facing copy was written in the lens of an upcoming appointment, stressing that the appointment could be canceled if the payment wasn’t completed. Practices stressed that this was too restrictive, as they didn’t always want to send these out before an appointment.
Cost of product. Unlike Intake, our Payments product requires practices to pay a fee per transaction, which is not always competitive with the fees charged through other collection methods, such as credit card machines.
Eligibility checks. Practices noted that being able to have a product that runs eligibility checks and then automatically requests payments from patients based on results would be incredibly helpful in improving their workflows, but for now this is just another system they have to juggle.
So, what now?
REVISITING THE PROBLEM SPACE
In May 2022, one of our UX researchers and I facilitated a workshop with product, product marketing, and engineering leadership to understand our goals and vision for the Payments product, review existing research, and document outstanding questions. The outcome of this workshop was a research plan:
Understand practices’ billing workflow — 1:1 interviews with participants who are responsible for billing at their practice.
Understand practices’ payments workflows in real-time — 1:1 interviews with participants followed by 2-3 hours of contextual inquiry, observing how these participants communicate with patients regarding payments during check-in and check-out times.
Understand what information patients are looking for around their healthcare bill — 1:1 interviews with patients around billing and their comfort level with making these payments online, specifically through Zocdoc.
Understand product fit within the market — a round of product marketing led research to determine if Zocdoc can be a true player within this space.
Recent Research outcomes
In June-July 2022, the UX researcher and I conducted research to better understand bullet points 1-3 above. In doing so, we discovered two key opportunity areas:
Practices are seeking better eligibility information: We were familiar with this finding from our previous research for the eligibility feature; however, in the lens of payments, it reinforces that a robust eligibility feature within Zocdoc can act as a true driver of the Payments product.
Patients are seeking more transparency on cost and benefits: We knew from our eligibility feature that a clear understanding of patient’s benefits is critical for determining if they are the right fit for the practice; however, our research with patients revealed that there is an opportunity area to show visit costs more transparently on our patient side of the product as well.
At this point in time…
With all of the other major initiatives within the Intake product, our work on the Payments product is currently on pause. We hope to pick this work back up in 2023 once we bring on more design + product resources.
Takeaways
Product marketing research is just as important as traditional UXR when pursuing a new offering within a product suite.
Determining a roll-out strategy is key to adoption.
Even if focused on a specific use case, it’s important to consider the overall journey and experience when designing.
