What's the challenge?

Sirono aims to improve the financial experience for medical companies. "The idea is that any Contact Center Agent who speaks with a patient will have the information and tools to be able to have a discussion about the financial obligations. Essentially, any Contact Center agent becomes a collector." As is often the case, time was not on our side. I joined the project two months before we had an interactive prototype for clients.

Financial Health

With such a short time frame it was important to build on what we already knew. Our users are calling patients and collecting payment info over the line. They didn't have the ability to view a lot of information. It had to be a quick, fluid process from start to finish.

For this project I chose Figma. On a short production timeline it was important to get feedback from shareholders as quickly as possible. We had the user flow already; the design of the app just had to match their experience within Salesforce.

Testing methods

Due to timeline limitations and, in later iterations, the COVID-19 situation, live user testing with each iteration could not be done.

Each version, including seemingly minor design changes, was shared with our team and stakeholders. I valued their opinion of my design decisions. Even if I couldn't test with users I could get valuable feedback from team members with a wide array of experiences of their own. I sought feedback at every stage of the process from as many eyes as I could get; good design is iterative and collaborative.

User flow and wireframes

We had a well defined user flow. A simple version, explained in this diagram:

 

The user is performing their normal call duties with the patient.

They can see our app to check the patient's financial standing.

If the patient was consistently paying their bills no action was required; if they were not they could access more information and eventually take a payment from the patient.

 

But for now this app inside the Salesforce page was our MVP. Our focus was getting this app properly built to get info on the patient and begin the longer process of taking payments.

The 'Financial Health' app is now in development and is being shown to prospective clients!

'Einstein' recommendations is an AI-driven feature that advises the caller on what to do next.

 

The system will check various factors regarding the patient's financial situation. From there it can recommend things such as offering a payment plan, offering a financial assistance program, adding an invoice to a payment plan, and much more. 

The devil's in the details

With the overall structure in place we had to focus on those elements that would support it.

The top row features up to seven icons while the top-right corner has a banner that displays the patient's overall financial status. These are designed to quickly alert the call center worker to the patient's status. If I'm scheduling an appointment with a patient, it may also interest me to see a big red badge on my screen, telling me I should go over billing.

The seven icons on the top row give quick bits of easily digestible info. Is the patient a large donor/VIP for the medical center? Do they have outstanding debt? Are we missing info?

These sprites pushed us to pivot several times. We tried them on the bottom. We tried different iconography. We tried showing the descriptions without an on-hover. In the end we stuck with this version as it best served our users' needs. Keeping it up top lets the user start with the quick bits of important info. Rather than using descriptions in small type we let the color do the talking; green, yellow, and red are a color pattern users recognize for positive, neutral, and negative.

We poured over these details many times. Arrows or triangles? Hamburger menu or boxes? 'Take Payment' row or button? In such a rapid process teamwork drove us on many decisions; open discussion brought logic, logic guided design decisions. But the caller wouldn't stop here.

Take a payment

Once the medical center worker discussed the billing situation with the patient it was time to get that information. In our Salesforce environment this would be done in a modal. We wanted to design something bigger and bolder. After all, our user is giving their attention both to this experience and to their patient; we need to make that as easy as possible for them.

Working against this philosophy is the reality of medical billing. Some patients have many, many charges on their account. Each charge has 8 pieces of important information. Some want to pay with checks, credit, or a saved payment method. How can we balance this depth of information with the required ease of use for someone having a conversation on the phone?

We went with a 2-column design. When callers select any combination of charges the total will automatically populate. If the patient needs to know how much the total is, the caller can easily see that information.

In this design, we made it as simple and accessible as possible while allowing that wealth of information to display in its entirety. Our users are in a unique balance; let's let them thrive in it.

Next steps

This is only the beginning. There are many steps in the billing process and we plan to help our users every step of the way. These two elements provide the groundwork for our complete array of products in the Salesforce environment. We hope to build upon the designs set in our MVP and the take payment screen.

The Financial Health app will launch live first; this will provide us with valuable feedback from the hospitals we seek to help. The intended benefit to these medical facilities would be a more efficient and lucrative billing system. As this app goes live we can use hard data to see if this intended effect holds true. 

For now we focus on the payment screens. But having this data in hand could enable A/B testing and a wide pool of user feedback on a product they use live. Then the real fun begins!

This site was designed with the
.com
website builder. Create your website today.
Start Now