Financial Ecosystem
Financial Ecosystem
Financial Ecosystem
Redesigning Platforms for Medical Loans
Redesigning Platforms for Medical Loans
Redesigning Platforms for Medical Loans
Redesigning Platforms for Medical Loans
Redesigning Platforms for Medical Loans
Industry
Industry
Healthcare / FinTech
Healthcare / FinTech
Healthcare / FinTech
Healthcare / FinTech
Healthcare / FinTech
Role
Role
Head of Design / UX Lead
Head of Design / UX Lead
Head of Design / UX Lead
Head of Design / UX Lead
Head of Design / UX Lead
Product
Product
Patient Application · Customer Portal · Practice Portal
Patient Application · Customer Portal · Practice Portal
Patient Application · Customer Portal · Practice Portal
Patient Application · Customer Portal · Practice Portal
Patient Application · Customer Portal · Practice Portal
View on Figma
View on Figma
Designs
Designs
Designs
Designs
Designs
01 — The Challenge
01 — The Challenge
01 — The Challenge
01 — The Challenge
DocFinance helps patients afford healthcare procedures through personalized financing, working together with medical practices and banks.
DocFinance came to us with a clear request: update the business model and modernize the backend processes.
The platform had an online application form, but submitting it was only the beginning. What followed was a mostly manual process of emails, phone calls, paper documents, and manual checks between patients, practices, DocFinance, and banks.
At the beginning of the project:
38% application completion rate
62% of applicants dropped off before financing was completed
3–6 weeks from application to funding
DocFinance had limited visibility into where patients abandoned the process.
DocFinance helps patients afford healthcare procedures through personalized financing, working together with medical practices and banks.
DocFinance came to us with a clear request: update the business model and modernize the backend processes.
The platform had an online application form, but submitting it was only the beginning. What followed was a mostly manual process of emails, phone calls, paper documents, and manual checks between patients, practices, DocFinance, and banks.
At the beginning of the project:
38% application completion rate
62% of applicants dropped off before financing was completed
3–6 weeks from application to funding
DocFinance had limited visibility into where patients abandoned the process.
DocFinance helps patients afford healthcare procedures through personalized financing, working together with medical practices and banks.
DocFinance came to us with a clear request: update the business model and modernize the backend processes.
The platform had an online application form, but submitting it was only the beginning. What followed was a mostly manual process of emails, phone calls, paper documents, and manual checks between patients, practices, DocFinance, and banks.
At the beginning of the project:
38% application completion rate
62% of applicants dropped off before financing was completed
3–6 weeks from application to funding
DocFinance had limited visibility into where patients abandoned the process.
02 — The Outcome
02 — The Outcome
02 — The Outcome
02 — The Outcome
DocFinance had a financing process, but not yet a connected digital financing experience.
I turned a fragmented process into one connected ecosystem: three products built on one shared financing lifecycle.
DocFinance had a financing process, but not yet a connected digital financing experience.
I turned a fragmented process into one connected ecosystem: three products built on one shared financing lifecycle.
DocFinance had a financing process, but not yet a connected digital financing experience.
I turned a fragmented process into one connected ecosystem: three products built on one shared financing lifecycle.
03 — The Problem
03 — The Problem
We initially saw a high bounce rate, but analytics alone could not explain why patients were leaving.
At the same time, DocFinance could not reliably track the patient journey beyond the initial application.
I started with a kickoff working session involving Product Management, Engineering, Legal & Compliance, and Design. Together we mapped the full process: the patient journey, bank communication, compliance requirements, technical constraints, manual internal work, and the practice's role.
The goal was to understand the entire process before touching the interface.
The conclusion changed the project:
The problem wasn't the application form. It was everything that happened after it
03 — The Problem
03 — The Problem
03 — The Problem
We initially saw a high bounce rate, but analytics alone could not explain why patients were leaving.
At the same time, DocFinance could not reliably track the patient journey beyond the initial application.
I started with a kickoff working session involving Product Management, Engineering, Legal & Compliance, and Design. Together we mapped the full process: the patient journey, bank communication, compliance requirements, technical constraints, manual internal work, and the practice's role.
The goal was to understand the entire process before touching the interface.
The conclusion changed the project:
The problem wasn't the application form. It was everything that happened after it
We initially saw a high bounce rate, but analytics alone could not explain why patients were leaving.
At the same time, DocFinance could not reliably track the patient journey beyond the initial application.
I started with a kickoff working session involving Product Management, Engineering, Legal & Compliance, and Design. Together we mapped the full process: the patient journey, bank communication, compliance requirements, technical constraints, manual internal work, and the practice's role.
The goal was to understand the entire process before touching the interface.
The conclusion changed the project:
The problem wasn't the application form. It was everything that happened after it
04 — Research
04 — Research
04 — Research
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
05 — Key Insights
05 — Key Insights
05 — Key Insights
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
06 — Validation and Collaboration
06 — Validation and Collaboration
06 — Validation and Collaboration
Before moving into high fidelity, we validated the concepts with internal specialists who work with patients and practices every day: Customer Support, Operations, Product, and Legal & Compliance.
The internal QA team tested the high-fidelity prototypes and the implemented flows across all three products. They walked through the key scenarios end to end: applying, choosing an offer, signing the contract, making a payment, and managing applications in the Practice Portal.
In healthcare finance, design can't work alone:
Product Management aligned goals, priorities, and scope.
Engineering defined what could be automated, such as bank verification and status tracking.
Legal & Compliance helped make required disclosures clear instead of overwhelming.
The platform launched with a pilot group of practices before rolling out to all partners, supported by a marketing campaign tailored to each audience.
Before moving into high fidelity, we validated the concepts with internal specialists who work with patients and practices every day: Customer Support, Operations, Product, and Legal & Compliance.
The internal QA team tested the high-fidelity prototypes and the implemented flows across all three products. They walked through the key scenarios end to end: applying, choosing an offer, signing the contract, making a payment, and managing applications in the Practice Portal.
In healthcare finance, design can't work alone:
Product Management aligned goals, priorities, and scope.
Engineering defined what could be automated, such as bank verification and status tracking.
Legal & Compliance helped make required disclosures clear instead of overwhelming.
The platform launched with a pilot group of practices before rolling out to all partners, supported by a marketing campaign tailored to each audience.
07 — Reflexion
07 — Reflexion
07 — Reflexion
DocFinance originally came to us to update their business model and backend processes. Design wasn't seen as a priority, and there was skepticism about spending time on research. The team wanted fast results.
A large part of my role was showing why the backend alone wouldn't be enough. Even a perfectly automated process wouldn't bring new patients if the experience on the front still felt confusing and slow. Without a better experience, there would be no growth in applications and no growth in revenue.
The service blueprint became the turning point. Once the team saw the backstage and frontstage on one map, it became clear that both had to change together.
DocFinance had a lot of data that could have been a strong foundation for research. Because of its sensitivity, it couldn't be shared with the design team. So we relied on support tickets, interviews, and conversations with internal teams instead. Next time, I'd agree on a secure way to access anonymized data at the very start of the project.
Thanks for reading! If you'd like to hear more about the details behind this project, I'm happy to walk you through them in person.
DocFinance originally came to us to update their business model and backend processes. Design wasn't seen as a priority, and there was skepticism about spending time on research. The team wanted fast results.
A large part of my role was showing why the backend alone wouldn't be enough. Even a perfectly automated process wouldn't bring new patients if the experience on the front still felt confusing and slow. Without a better experience, there would be no growth in applications and no growth in revenue.
The service blueprint became the turning point. Once the team saw the backstage and frontstage on one map, it became clear that both had to change together.
DocFinance had a lot of data that could have been a strong foundation for research. Because of its sensitivity, it couldn't be shared with the design team. So we relied on support tickets, interviews, and conversations with internal teams instead. Next time, I'd agree on a secure way to access anonymized data at the very start of the project.
Thanks for reading! If you'd like to hear more about the details behind this project, I'm happy to walk you through them in person.
04 — Research
04 — Research
Listening first: support tickets and calls
I started by analyzing with around 60 support tickets and 13 call transcripts because they provided a fast, low-cost way to identify recurring problems directly from real customer interactions.
The most common questions were:
"Did you receive my application?"
"What do I need to do now?"
"Why haven't I heard anything?"
41% of tickets were about application status and 23% about next steps. Patients weren't confused by individual screens. They didn't understand the process as a whole.
Three audiences, three methods
"The user" was not actually one user.
I identified three audiences with very different needs and stakes.
Applying patients: 12 interviews. Seven of them had abandoned their application. Abandoners showed us exactly where and why the funnel broke.
Enrolled patients: 8 interviews. Managing a loan happens over weeks, so we followed a full payment cycle.
Practice staff: 6 semi-structured interviews across 2 practices Instead of asking staff what they wanted, I asked them to walk me through recent real cases step by step, for example "Tell me about the last patient who asked about financing." Anchoring the conversation in specific cases revealed what staff actually did, which tasks took longest, and when they had to contact DocFinance.
05 — Key Insights
05 — Key Insights
Service Blueprint
The research showed where patients struggled. But it didn't yet explain why the process took so long.
DocFinance wasn't a single product. It was a service spanning patients, practices, internal teams, and banks, with several touchpoints along the way. In complex scenarios like this, a journey map alone isn't enough. A service blueprint shows how all the parts behind the experience work together.
I created the blueprint together with Product Management, Engineering, Legal & Compliance, and Operations.
We mapped four layers across the entire financing journey: what patients and practices do, what they see, what happens behind the scenes at DocFinance and the banks, and which systems support each step.
Jobs to Be Done
The blueprint showed us why the service broke down. Next, we needed to define what each audience was actually trying to achieve.
We used the Jobs to Be Done framework to translate our research into user needs. The idea is simple: people "hire" a product to get a specific job done. If it doesn't do that job well, they "fire" it and look for something else.
At DocFinance, this was happening already. Patients who abandoned the application often fell back on credit cards or postponed treatment. Practices "fired" the existing process by calling DocFinance instead of relying on the system.
JTBD helped us shift the focus from activities to outcomes. Instead of asking "How do we improve the application form?", we asked "What is the patient really trying to accomplish?" The answer wasn't "fill in a form." It was "get treatment without financial stress or uncertainty."
For each audience, we explored two questions:
What is the user trying to accomplish?
What makes the job successful, functionally and emotionally?
How might we
The next step was to turn those needs into opportunities the team could design for.
We reframed the biggest pain points as "How might we…" questions. This kept the focus on the problem while leaving room for different solutions.
We had more opportunities than we could address in the first release. Together with Product and Engineering, we rated each one by impact on our goals and effort to build.
Opportunities with high impact and manageable effort went into the first release: progress visibility, bank-based verification, the pending state with next steps, the patient dashboard, and status visibility for practices.
07 — Reflexion
07 — Reflexion
DocFinance originally came to us to update their business model and backend processes. Design wasn't seen as a priority, and there was skepticism about spending time on research. The team wanted fast results.
A large part of my role was showing why the backend alone wouldn't be enough. Even a perfectly automated process wouldn't bring new patients if the experience on the front still felt confusing and slow. Without a better experience, there would be no growth in applications and no growth in revenue.
The service blueprint became the turning point. Once the team saw the backstage and frontstage on one map, it became clear that both had to change together.
DocFinance had a lot of data that could have been a strong foundation for research. Because of its sensitivity, it couldn't be shared with the design team. So we relied on support tickets, interviews, and conversations with internal teams instead. Next time, I'd agree on a secure way to access anonymized data at the very start of the project.
Thanks for reading! If you'd like to hear more about the details behind this project, I'm happy to walk you through them in person.
06 — Validation and Collaboration
06 — Validation and Collaboration
Before moving into high fidelity, we validated the concepts with internal specialists who work with patients and practices every day: Customer Support, Operations, Product, and Legal & Compliance.
The internal QA team tested the high-fidelity prototypes and the implemented flows across all three products. They walked through the key scenarios end to end: applying, choosing an offer, signing the contract, making a payment, and managing applications in the Practice Portal.
In healthcare finance, design can't work alone:
Product Management aligned goals, priorities, and scope.
Engineering defined what could be automated, such as bank verification and status tracking.
Legal & Compliance helped make required disclosures clear instead of overwhelming.
The platform launched with a pilot group of practices before rolling out to all partners, supported by a marketing campaign tailored to each audience.
Transforming Ideas Into
Digital Experiences
From first research to final
handoff, let's create something worth using
Transforming Ideas Into Experiences
Transforming Ideas Into
Digital Experiences
From first research to final
handoff, let's create something worth using
Transforming Ideas Into
Digital Experiences
From first research to final
handoff, let's create something worth using
Transforming Ideas Into
Digital Experiences
Transforming Ideas Into
Digital Experiences
From first research to final
handoff, let's create something worth using
Transforming Ideas Into
Digital Experiences
From first research to final
handoff, let's create something worth using