Splitting invoices between two payers
As a Product Designer at EasyPractice, I led the design and implementation of a new invoicing feature that allows practitioners to split invoices between multiple payers; typically a patient and an insurance company.
This project aimed to support the evolving needs of larger clinics and heavily regulated healthcare professions, enabling EasyPractice to better serve enterprise-level customers. I was responsible for research, UX strategy, and end-to-end design execution, working closely with internal teams to ensure seamless integration into the application's existing invoicing system.
As EasyPractice matured, we began attracting larger clinics with more complex operational needs, particularly in invoicing. One key limitation was our inability to split an invoice between multiple payers, such as a patient and their insurance provider. This was a recurring blocker for therapists working in more regulated healthcare environments, who were forced to use incumbent platforms to meet this and other requirements.
This pain point wasn't exclusive to Denmark, where EasyPractice was based; therapists globally often require multi-payer invoicing capabilities. Supporting this functionality represented a strategic growth opportunity, a chance to reduce churn among enterprise leads, and a way to compete more effectively against legacy healthcare software. All without sacrificing our reputation for user-friendly design.
The primary goal was to enable therapists to split invoices between two or more payers within a single, streamlined workflow. We wanted to achieve this without adding friction to the existing invoicing process. This meant designing a solution that felt intuitive and low-effort for high-volume users.
Success would be measured by:
- Adoption of the feature via in-app discoverability (prior to a marketing rollout)
- Reduction in support tickets related to multi-payer invoicing
- Positive feedback from early users in large clinic settings
1. Discovery and research
To ensure the solution aligned with local regulations and user expectations, I began with in-depth discovery. Most EasyPractice customers are based in Denmark, so I collaborated closely with our Danish team to understand the nuances of therapist workflows, insurance structures, and legal obligations.
I mapped existing invoicing processes and collected input from support tickets, user feedback, and internal stakeholders. One insight stood out: While users had framed this as an "insurance" problem, the real need was broader. Clinics wanted to assign a portion of any invoice to another payer, such as a guardian, employer, or partner.
2. Definition and scoping
Recognizing this as a generalizable pattern helped us broaden the scope and increase long-term value. At the same time, I worked with developers to audit the existing invoicing logic; an area of the platform known for its complexity and high user volume. The biggest constraint was that any new feature had to feel native and lightweight, without adding friction to core invoicing flows.
3. Ideation and prototyping
Using FigJam and Figma, I drafted and iterated on flows for how users could assign "Other Payers" and define contribution splits. I explored different approaches for persisting payer preferences, ultimately landing on a model where payers could be pre-associated with clients at the client level. This allowed most users to apply split invoicing in just one extra click, after a lightweight initial setup.
4. Iteration and validation
I worked closely with the development team to implement the new feature and test it as it was being implemented.
I reviewed the proposed flows with internal teams and refined the interface to reduce unnecessary steps. Key usability principles guided the design. While we did not conduct external usability testing, internal testing and feedback sessions helped to validate that the design was intuitive for frequent users.
The feature was made available through the EasyPractice app ecosystem and surfaced natively within the invoicing interface once enabled. This approach preserved the simplicity of EasyPractice's invoicing system while introducing significant functionality. The design minimised context-switching and supported high-throughput use cases, especially for users managing large client loads.
The final experience introduced a seamless way for therapists to split an invoice between two payers. Once enabled, users could associate an "Other Payer" with a client profile and define a default contribution using either a percentage or a fixed value.
This setup became part of the client's profile, meaning future invoices could automatically apply the predefined split. When creating an invoice, the user simply selected the relevant Other Payer, adding only one additional click to the existing workflow.
The feature was adopted at a rate that exceeded expectations - even before any formal marketing or onboarding push. Therapists discovered and began using it organically through the app store and existing workflows, confirming that the design was both intuitive and valuable.
Though it was still early post-launch, initial indicators included:
- Positive qualitative feedback from users in support channels and internal stakeholders
- Significant reduction in support queries related to workarounds for multi-payer invoicing
- Strong usage from larger clinics - an important strategic segment for EasyPractice
The solution also expanded EasyPractice's positioning with enterprise leads, offering a clear response to a blocker that previously forced many therapists to use incumbent platforms. Internally, the project became a model for how to balance high-impact functionality with low-friction usability - especially in complex parts of the product.
This project reinforced the importance of looking beyond the immediate ask to uncover broader, more scalable user needs. What initially seemed like an "insurance-only" requirement turned out to be a more general need for shared payment responsibilities - unlocking value for a wider range of users.
It also sharpened my ability to design within constraint-heavy systems. Navigating a high-complexity, high-throughput area like invoicing pushed me to prioritize simplicity, speed, and low-friction execution at every step.
If I were to revisit this project, I'd explore running moderated usability tests before release to validate edge cases more thoroughly. That said, this project remains a highlight of how user-led design, thoughtful scope expansion, and tight collaboration can deliver real impact - even in areas users might have accepted as "just the way it is."
