Billing is notoriously the most complex and hard to solve domains across all dental practice management system providers. Since the conception of Archy it has been the top domain in number of costumer inquiries.
The most obvious problem with the POC designs is visual. There is so much to look at making it really hard for the user to understand, read and make sense of all the numbers presented.
The root of this visual confusion though is that the initial approach was to give the patient ledger a very literal accounting view. But the people working in the dental practices are not accountants, they are not trained to analyze billing from an accounting perspective.
While researching and conceptualizing for a log term solution we worked on and released an interim design to clean up the ledger and offer a Payments screen.
While these moves were welcomed by stakeholders and users, the feedback was that it didn’t completely solve the problems.
The first thing we did was to analyze the costumer support tickets that were created around Billing, which gave us many insights about the issues users were encountering.
User interviews were also conducted and we heard that they would come to this domain with several different tasks, each one requiring more or less data access. So we decided to approach this with the strategy of progressively revealing data as the user decides to dive deeper into the interface.
We looked at financial interfaces that presented the data in a simpler, easier to digest way. It had become very clear we had to slice and dice the information on the ledger so the user could consume it as needed.
As far as visual language, definitely needed to bring the interface into the same direction the rest of the app was going, simpliying and cleaning up the styles.
We looked at the competition and the busy, accounting based UI was common across all the main players in the market.
One of the first considerations was how to initially present the data and it just made sense to use the patient appointments to be the entity that organized and nested all other billing information.
We also reduced the number of columns on the ledger table to show only the patient and insurance status and pending amounts and the overall appointment amount and the outstanding balance.
The right rail panel was kept but repurposed and reorganized to be more useful, and a system of tabs was introduced to organize the different ways we could present the data.
An accordion system was devised to enable progressive deeper dives into the billing data for each appointment. As the user expands the appointment, details about the procedures and costs are revealed, as well as other nested items, such as invoice, claims or adjustments.
Once visible, the nested items can also be expanded to reveal details about themselves, giving the user a complete picture of all financial activity on the appointment.
Payment collection was moved into it’s own full screen and we introduced the concept of multi-invoice/family payment, considering most families use the same dentist and usually only one family member is responsible for making payments.
We moved the payment method management panel into a drawer, a component frequently used for quick edit flows across the app.
We added a couple of new tabs that pretty much resurface similar data to the ledger, but with a focus on a specific element of billing, catering to specific tasks the user might have on a daily basis.
The Invoices tab isolates all invoices and gives a quick reading into the payment status and amount due for each one and makes them available for collection.
The payments tab gives a detailed view of each payment done on that specific patient account, including the method, the invoices it covers and if it included invoices from other family members. This tab becomes really useful when patiets call i the clinic asking for clarifications on where was their payment applied to.
The wallet tab covers all activity happening on the patient’s wallet, including deposits and withdraws.