Project Overview
The Problem:
In SimplePractice, services are set up with one default rate. It is common for clinicians to have different rates for the same service in group practices. Customers use various workarounds that are time consuming and prone to errors.
My Role:
User research, concept testing, usability testing, prototyping, and UX/UI design
The Opportunity:
Giving practices the flexibility to assign different rates to clinicians offering the same service will cut errors and the time customers spend manually updating rates. This redesign will help eliminate insurance claim submission errors for clinicians.
Tools:
Figma (Prototyping, UI/UX deliverables), and Zoom (User interviews and usability testing)
Team:
Catalina Clavijo Rey (Senior Product Manager), Kristian Tumangan (Product Designer), Audrey McNay (Senior Content Designer), Nicolas (Full Stack Engineer)
Discovery
Before starting customer interviews I wanted to understand how clinicians were solving the problem within the current SimplePractice EHR (Electronic Health Record) product. Below are some of the ways clinicians handled the problem.
The first most common way clinicians were addressing the problem was to create custom service codes to differentiate clinicians offering the same service.
Another workaround was changing the fee for each individual appointment, which is time consuming and can lead to errors due to the sheer number of appointments.
Lastly, clinicians would create a custom service per client which was time consuming for practices with large case loads.
User interview and concept testing
After understanding the workflows users were using to accomplish assigning different rates within our product, the team and I then went into interviewing users to understand the reason why different rates were being assigned. These round of interviews were a combination of not only understanding the why, but to also test some design concepts on how these rates can be assigned.
I was in charge of putting the research plan together and designing the two concept prototypes we would be showing to clinicians. The task we asked users to accomplish in the design concepts phase was to edit clinician rates. The two designs were differentiated by a clinician-first vs. a service-first model. We wanted to know if the scenario of updating all the services for each clinician separately made more sense or if they preferred updating one service for all clinicians at once.
Interview Insights:
1. Experience and licensure are the main drivers on why the same service rate may differ between clinicians (e.g. Education (MA/MS vs. PhD), license (LCSW-A vs. LMFT), and additional certifications.
2. Holding licenses in different states may impact different pricing strategies.
3. Rates differ from a client to client basis when insurance payers have different rates. Some pay higher/lower rates.
Design Concept Insights:
1. Users preferred the clinician-first model as it was easy to change rates as clinician circumstances change (e.g. pre-licensed clinician to licensed).
2. It was easier to get an overview of clinicians' information and services provided in the clinician-first model.
3. In the setting of staff turnover in a practice, the clinician-first model felt easier to manage staff rosters and their different rates.
Implementation
With a better understanding of clinicians’ desires to easily differentiate between the practice’s service rate vs. a clinician’s service rate, I designed the services page to adjust the view between a practice’s default service rate and the clinician’s rate to make the distinction clear.
Next, I designed flows on how users would be able to adjust the rate for services offered by specific clinicians. The flow also enabled users to adjust which specific services different clinicians in the practice offer.
As these designs were being worked on, I also shared them to our engineer, Nicolas, to get an estimate of how long it would take to develop on both the front-end and back-end.
Pivot
As designs and development timelines were being finalized, a new company-wide product development MVP framework was implemented; thus we had to adjust our solution. The team now needed to launch this feature in a 6-week timeframe, which was significantly less time than the original release estimation.
My team and I pivoted our solution to accommodate for this framework change. Despite the new product development cycle, we didn’t want to lose the clinician-first view approach to adjusting rates that we learned from all our user interviews and initial concept testing. I quickly put a design together that leveraged the current services page, but added more functionality on top of it.
This design still kept with the current mental model clinicians had with adjusting service rates for a practice, but I built upon it by redesigning the clinician section when a service is being edited. This updated clinician section allowed the capability to adjust rates individually per clinician.
Once I put this design together, my team and I quickly performed some usability tests with 9 clinicians to ensure the functionality of the designs were usable. Because the designs were an update to the existing experience, the findability of the clinician section wasn’t hard to get to, and they all thought the fields to adjust specific clinicians’ rates still gave enough functionality to accomplish their desire to change a specific clinician’s rate.
Since this design implementation leveraged the existing service page setting experience, the release hit the new company wide MVP development framework timeline/release.
Reflection
With this project I learned how to pivot and iterate quickly, while still keeping core user discovery principles and insights intact when implementing a different solution that departs from the one I originally had. Even when sudden changes to a project come along, the collaboration and communication with my squad made the shift to implementing a different solution easier within the constraints of a new timeline/framework.
View More Projects
