Designing beyond the screen in a complex billing system

Show eligibility response details where the user was at and when the user needed it.

TherapyNotes already offered insurance eligibility checks, but users had to navigate away from what they were currently doing to see the returned eligibility information. A more contextual interaction sounded simple: request eligibility and show the response right alongside the stored insurance information.

Eligibility responses arrived as a 271 transaction that carried a lot of useful information like coverage, subscriber and patient data, plan details, benefit categories, deductibles, copays and more.

Displaying the payer’s eligibility data alongside the patient’s insurance info was a great idea, but It turned out that the real challenge was when the returned information conflicted with what the user already had entered in TherapyNotes.

The design had to protect the record, not simply replace it. I solved the original ask by putting the eligibility information on the same page where the user was working, but more importantly I worked through field mappings, merge states and exceptions rather than just designing the happy path.

The user needed to see the differences clearly, make deliberate choices and preserve their intent instead of blindly trusting the payer response as a replacement. That change was the result of understanding the problem more completely.

Some values couldn't be merged at all and changing certain policy identifiers—such as member ID, policy group or policy holder—could matter differently when claims had already been paid or partially paid.

The emerging screens optimized for the necessary use cases: run eligibility from the patient's billing settings, show the status there, and move into persistent discrepancy work when necessary.

This was part of this design process I really valued: the more accurately I understood the data and workflow, the better the user’s experience became because I could anticipate many of the user’s needs before the user encountered them.

Providers often received provider EOB information in PDFs or images instead of usable ERA data, which meant their staff had to manually re-enter payment information into TherapyNotes.

The proposed feature would let a user upload that EOB PDF and then the Azure-based document AI processing would turn it into structured data that would get fed into the existing payment system.

But the requirements I had only described the happy path. I still needed to know what happened when the AI extraction went sideways, because that answer would change the UI and what the user needed to do next.

When our product managers were too overwhelmed I volunteered to investigate the possibility of errors myself. What I found was critical.

Different failures required different recovery. We needed to separate a total extraction failure from a usable result containing questionable fields.

A complete failure might require someone to do manual entry with the source still visible and a partial result demanded review, correction and approval before posting.

That meant treating an original EOB as a working reference during review, not merely as an attachment that disappeared after upload. I designed a comparison interface toward the following outcomes:

Hard stop — The import could not safely continue, so we would send the EOB directly to our customer support team where they would resolve the import manually and build a log of what was causing import errors.

Review required — The import produced usable structured data but our validation checks flagged that verification was needed by the user. We would then show the user the imported result alongside the original document so the user could review, correct and approve it.

Success — Even if our validation checks returned all green lights we felt that it was still important for the first release to always ask the user to review the results. With the right communication and a beta test group as our first audience we could respond to error patterns quickly and safely until we eventually removed the review process as we improved the importing system.

Our detailed review loop accelerated how quickly I learned the product.

This project was one of my first major TherapyNotes projects. It went through multiple rounds with stakeholders which included detailed executive reviews.

The amount of refinement was demanding, but it also gave me an accelerated education on the product's interaction language: which existing patterns mattered, where consistency was expected, how edge states were handled and how precise the final behavior needed to be.

By the time I reached the handoff stage, I had annotated the interaction details explicitly, checked the visual values intentionally, added tablet and mobile responsive states and also added the dark-mode versions.

Most important, I stayed involved when the design became code. Before I started design QA, I scheduled time with the developer and product owner to explain how I wanted to work through the review and make sure we agreed on the process.

That relationship mattered. Design QA can feel like someone arriving late to point out everything engineering did wrong. I wanted the developer to know that I cared about the shared result, that I had documented the design carefully, and that I would work through discrepancies with him rather than throw a screenshot of red circles over the wal

The implementation arrived in three major segments: the modal, edit mode and view mode. For each segment my design QA had four review steps:

1. Interaction behavior — verify every annotated requirement from Figma worked as written.

2. Visual and responsive accuracy — compare the implementation against the intended UI and at the sizes I had designed.

3. Design-system implementation — inspect the rendered code and verify that the appropriate design-system variables were actually being used.

4. Dark mode — confirm that the alternate theme behaved and looked like the design rather than treating it as an afterthought.

I created Excel sheets where I logged the bugs I found with screenshots and detailed reproduction information. Across the review process I logged more than 20 implementation issues that the developer then fixed.