Industry

Healthcare

Client

Tekhne SA

Year

2024

Debt Payment and Refinancing

A portal designed to provide members of a healthcare provider with a simple and accessible way to manage and refinance their outstanding debts. Through this platform, users can assess their financial situation, review their current debts, and choose from various refinancing options tailored to their needs.

Main Project Image
Main Project Image
Main Project Image

The Challenge

The main challenge was to redesign a platform that would not only allow online payment of invoices (whether overdue or not), but also incorporate the complex process of debt refinancing, making it accessible and easy to understand for users. Specific Challenges Financial information complexity: There were three different types of debt, and each refinancing plan had to be aligned with the specific type being managed. Tight timelines: The project needed to be completed quickly—two weeks for the core work and one more for minor adjustments—while also juggling other ongoing projects.

The Outcome

Successfully adopted + 1 client

New Clients

After launch, the portal was successfully adopted by the initial client’s users — significantly improving clarity around debt refinancing and full payments. Due to the success of the solution, another healthcare organization requested to implement the same platform, validating the design’s scalability and business value.

Successfully adopted + 1 client

New Clients

After launch, the portal was successfully adopted by the initial client’s users — significantly improving clarity around debt refinancing and full payments. Due to the success of the solution, another healthcare organization requested to implement the same platform, validating the design’s scalability and business value.

Successfully adopted + 1 client

New Clients

After launch, the portal was successfully adopted by the initial client’s users — significantly improving clarity around debt refinancing and full payments. Due to the success of the solution, another healthcare organization requested to implement the same platform, validating the design’s scalability and business value.

The Process

Discovery phase

Discovery phase

Discovery phase

User Research and Data

We refer to this as a redesign because there was an existing payment portal. However, it only offered a basic feature: viewing and printing invoices for cash payment. As mentioned, the updated portal needed to support online payments and debt refinancing. We began by reviewing screens from the previous system and mapping out what existed. From there, we analyzed the structure using diagrams and user flows to understand what the system currently did—and what the new one needed to do. In parallel, we did a brief investigation into technical vocabulary and specifications related to financing and types of debt. This allowed us to build a map of the current state and the ideal future state of the product.

Project Gallery Image for 50% width of the screen #1
Project Gallery Image for 50% width of the screen #1
Project Gallery Image for 50% width of the screen #1

Discovery phase

Discovery phase

Discovery phase

Insights

Debt refinancing was a core user need, but each type of debt had different financing rules — adding complexity to the design

sers expected to refinance existing debts directly within the portal. However, each debt category had its own conditions, interest models, and available plans. This made it difficult to create a one-size-fits-all refinancing flow

Debt refinancing was a core user need, but each type of debt had different financing rules — adding complexity to the design

sers expected to refinance existing debts directly within the portal. However, each debt category had its own conditions, interest models, and available plans. This made it difficult to create a one-size-fits-all refinancing flow

Debt refinancing was a core user need, but each type of debt had different financing rules — adding complexity to the design

sers expected to refinance existing debts directly within the portal. However, each debt category had its own conditions, interest models, and available plans. This made it difficult to create a one-size-fits-all refinancing flow

Users needed a direct path to pay off their debts entirely — not just refinance them

In addition to partial or scheduled payments, many users simply wanted to settle their entire balance in one transaction. This behavior was especially common

Users needed a direct path to pay off their debts entirely — not just refinance them

In addition to partial or scheduled payments, many users simply wanted to settle their entire balance in one transaction. This behavior was especially common

Users needed a direct path to pay off their debts entirely — not just refinance them

In addition to partial or scheduled payments, many users simply wanted to settle their entire balance in one transaction. This behavior was especially common

Access to expired or overdue payment receipts was essential for user clarity and compliance

Users often searched for past receipts or wanted to verify if a payment had lapsed, either for personal tracking or to present documentation. Not showing expired vouchers caused confusion and increased support requests

Access to expired or overdue payment receipts was essential for user clarity and compliance

Users often searched for past receipts or wanted to verify if a payment had lapsed, either for personal tracking or to present documentation. Not showing expired vouchers caused confusion and increased support requests

Access to expired or overdue payment receipts was essential for user clarity and compliance

Users often searched for past receipts or wanted to verify if a payment had lapsed, either for personal tracking or to present documentation. Not showing expired vouchers caused confusion and increased support requests

Develop phase

Develop phase

Develop phase

Wireframes, Flows, Conceptualization

The image featured in the carousel #2
The image featured in the carousel #2
The image featured in the carousel #2
Large Project Gallery Image #2
Large Project Gallery Image #2
Large Project Gallery Image #2

Design Decisions Through Collaboration During our first iteration with the development team, it became clear that allowing users to refinance multiple types of debt at once introduced considerable complexity. Each type required its own installment plan, and this complicated both the UX and backend logic. After an open discussion across teams, we agreed to separate the selection of debt types at the start of the process. This meant that users would select one type of debt at a time and be shown only one refinancing option accordingly. While this removed the ability to refinance multiple types at once, it wasn’t a mandatory requirement for this use case—and it significantly reduced confusion. To support this change, we introduced tab navigation, allowing users to switch between categories (e.g., Category A, B, and C).

The image featured in the carousel #3
The image featured in the carousel #3
The image featured in the carousel #4
The image featured in the carousel #4

Develop phase

Develop phase

Develop phase

Unfolding the solutions

What Could Have Been Improved In retrospect, it would have been incredibly valuable to conduct broader user testing with more actual members. Due to limited resources and tight timelines, we were only able to test with internal users from the organization. This meant we missed out on richer insights that could have come from real-world usage. What We Learned This project helped us gain a much deeper understanding of the system, particularly the value of breaking down complex systems into user flows. Doing so gave us clearer visibility into user interactions and allowed us to build a more coherent and user-friendly product.