TASK: Redesign the billing dialog to incorporate Secondary Electronic Claims data
The billing dialog is the central hub for all billing users to modify any details about a date of service prior to billing to an insurance company. While planning the larger Secondary Electronic Claims epic, the need arose to redesign this dialog to accommodate secondary insurance policy information. The information in the dialog at that time was not organized intuitively, and though we were able to make some band-aid improvements by quickly adding some dropdowns to accommodate billing to an insurance company, we wanted to improve the way information was organized and displayed in the dialog to be more intuitive.
In addition to that, each date of service can include one to several service codes that represent services rendered during the appointment. Service codes for a date of service had previously been listed in a table format in the dialog. This table was not responsive on mobile devices, so we needed a fresher, more modern design to represent multiple service codes while maintaining some existing functionality such as displaying totals for the entire date of service, as well as multiple units of a service code.
Open the images above to see the dialog in it's original form.
One of the biggest challenges we had to solve for was how to make all of the calculations work (below the service code table) when secondary claims were part of the date of service. Those calculations were originally built to just represent the logic of billing to a single insurance provider; and when we tried to band-aid this part of the dialog, we were finding it just was not intuitive for a user at all. At any given time, it was really hard for them to decipher a) what stage of the claims process the date of service was in, b) who exactly they were waiting on payment from, and c) what tasks, if any, the user had to do to move things along.
So... we had to redesign the whole thing.
Open the images above to see the dialog in it's redesigned form.
I started by taking every piece of information currently available on the dialog, and every piece of information that would become available on the dialog (for secondary claims/insurance), and determined what all those pieces of information belonged to. It was most important to show, depending on the stage of the claims process the date of service was in, what had been paid and by whom. In different iterations of this dialog, "Paid" will appear in both the Primary Insurance and in the Secondary Insurance containers, once claims have been submitted to a secondary payer. You can see the entire finalized design file here - and here is where I step through the happiest path possible to show how the dialog changes as the date of service advances through the claims process.
TherapyNotes, unlike many more modern applications, is not built on a design grid system. Responsiveness was handled on a page-by-page basis, and guidelines for it were handled at a project level. While TherapyNotes had defined breakpoints for us to reference, they were not the only breakpoints we potentially needed to consider. For this project, I provided responsiveness guidance for developers for each possible scenario of the billing dialog, but most odious to address were the Single and Multiple Service Code scenarios.
TherapyNotes is in the midst of both building out an older design system (Psyche), and also building a brand new design system (Cerebral). For a while, and depending on the project and when it would go live, designers have been working out of both; but downstream, developers had some issues understanding Figma DevMode (not all developers had this level of access), and the design system properties and values. To help my teams out, I wrote out design requirements whenever I could, to reduce confusion, and to help developers build out features faster. During a recent design survey, our lead designer let me know that I was the only designer to receive kudos from her developers, and a large part of that was because I spelled so much out for them and didn't make them think so hard when building out a design.
Want to connect? I'd love to hear from you!