Case study
The app PINK Coach had been listed as a DiGA (Digitale Gesundheitsanwendungen or Digital Health Application) for one year and was in the process of becoming permanently listed.
The business model of DiGAs depends on three crucial steps:
DiGA manufacturers receive payment from public health insurances only after the activation code is successfully redeemed within the app. Users with private health insurance usually purchase the activation code directly from Pink’s website and get reimbursed.
At the time, it was well known in the DiGA manufacturer community that obtaining the activation code is a significant challenge for users:
Since this whole process of obtaining an activation code happened offline, it was hard for PINK! to measure how many people try to get the code and give up because it’s too much effort.
The main goal of this project was to reduce friction and increase the number of activation codes redeemed in the app.
We started collecting data on the process of obtaining the activation code, from the following sources:
The following pain points were identified, in the discovery phase:
Based on these findings, we reframed the problem in a how might we question:
How might we simplify the process of obtaining an activation code for the PINK! Coach app, so more breast cancer patients can benefit from the app, and PINK! can increase its revenue?
Six months before I joined the project, there were discussions about creating a system where users could email their prescriptions or proof of diagnosis to customer service, who would then handle contacting the health insurance. However, I wasn’t involved in this phase, and the feature was never launched because our data protection officer advised against it due to the lack of encryption, making email an unsafe method for sharing medical data.
As a result, discussions shifted toward finding a more secure solution, ideally an in-app feature hosted directly on our servers.
When I joined the project in September 2023, I advocated for exploring solutions beyond simply uploading files in the app.
I saw an opportunity to better guide users by providing tailored information rather than overwhelming them with a page on the website containing a large amount of content and expecting them to find what matched their situation.
This should reduce requests and questions sent to the customer service. Additionally, this approach would allow PINK! to collect valuable data about the user, in the process, and offer personalised support based on their specific needs.
The idea was to begin the flow by asking users a few questions about their health insurance and their current stage in obtaining the activation code, so we could provide tailored guidance based on their specific situation.
The product team as well as the leadership team agreed, that this would add value to the business and accepted to increase the scope of the project.
Once we were all aligned on the project, the product manager and I started listing the different kinds of flow there were to obtain an activation code, depending on the type of insurance the users had.
We came up with 4 different groups of users, and mapped out a flow for each group:
For each user group, the process for obtaining an activation code varied. However, we identified six key steps that were common across all groups. Based on their responses to the questionnaire, different content would be displayed to each group.
After mapping out all the different journeys to get the activation code, the product manager and I reviewed them all and decided to simplify some parts and merge the Beihilfe journey with the privately insured journey as they were quite similar.
Read from top left to right and then bottom left to right.
We conducted unmoderated user tests on the new flow, and users found it easier to navigate. Most participants expressed trust in PINK! to handle their medical and personal data securely and were willing to use the prescription service.
To measure the success of this new feature, we should observe the following key metrics:
The designs were handed over to the software engineers in October 2023. However, the feature was not launched until June 2024 due to a shift in priorities.
I had already left the company by the time of the launch and no longer have access to the database. For privacy reasons, this data cannot be shared with external parties.
It is still too early to fully measure the impact of this new feature on the business, but I am confident that it has provided valuable insights and eased a significant burden for patients.