Skip to main content

Digital Health Product Design and Validation

By July 20, 2022July 27th, 2022No Comments
Doctor reading a patient alert message on their smartphone
Doctor reading a patient alert message on their smartphone

Building products in digital health is extremely rewarding for those working in the industry, but it also demands careful product planning and robust processes. At patientMpower, we’ve built product processes that we’d like to share with other health-tech companies. Drawing from a recent feature we launched, Alerts, we’ll introduce some of the key processes we used to build it, and a few important things we learned along the way.

Our users

It’s estimated that 545 million people in the world had a chronic lung condition in 2017, an increase of 39.8% since 1990. Our platform enables patients to manage their lung condition from the comfort of their home. With our patient and clinician apps, health data is captured at home and used to make better and faster care decisions. The COVID-19 pandemic has also accelerated the adoption of digital health solutions.

As patient numbers grow, small clinical teams are being tasked with monitoring more patients on our clinician app. It’s our responsibility to make sure that monitoring 100 patients or more remains quick and easy, that we deliver clear and prompt health insights, and that all patients are safely monitored. This became our next product goal, but where do you start in finding the right solution?

How we gather ideas and problems is not covered in this blog. Instead, we’ll talk about some key steps we take to:
  1. Validate the problem we want to solve
  2. Ensure that the problem is worth solving and aligned with our business goals
  3. Define the right solution

Go wide, then decide 

Our processes are built around the Zendesk triple diamond. We “go wide, then decide” when exploring the problem and solution. This ensures we are open to solutions and that the right features get built. This visualisation is missing activities that are important for digital health companies, such as clinical risk analysis, and we’ve added these over time.

The Zendesk Triple Diamond (slightly adjusted)

Zendesk’s visualisation of their product and design process

Build a business case  

It’s easy to get excited about a problem and jump straight into defining the solution. A common pitfall in Product Development is getting fixated on a solution, without taking the time to analyse the problem properly. Additionally, it’s important to look at whether it is a significant problem across all customer segments.

This is why writing a Business Case when exploring a new feature is crucial. It helps to ensure that you’re solving the right problem and that it aligns with your company goals. A Business Case is also a brilliant resource for sharing with your design and development teams, so they can understand why a product feature is a priority and how it aligns with your company strategy. Product documentation in general is an important part of your Quality Management System (QMS) and regulatory processes e.g. ISO 13485 – standards that are used in Digital health.

We created a Business Case template that helps us to:
  1. Support the problem statement with research
  2. Measure the impact of the proposed solution
  3. Gain a clear view of the requirements needed
Our Business Case template contains sections like:
  • Problem statement, Proposal, Use cases, Business requirement, Success metrics, Market information, Customer feedback, Strategic alignment, Risks and  assumptions, Alternative options, Cost analysis, Project milestones

A problem statement is the foundation of a good Business Case.

Define the problem statement

A good problem statement clearly communicates what problem you’re trying to solve and why it’s important. It also helps to create sympathy and buy-in from other stakeholders. We love how Indeed explains what a Problem Statement is, which is based on 4 elements:

  • Ideally… 
  • In reality…
  • As a consequence… 
  • Proposal… 

We took the problem of wanting to enrol more patients safely and translated it into a Problem Statement. It’s important that the problem statement doesn’t mention a solution, but focuses on the desired outcome.

Unlike Indeed’s template, we separated the “Proposal” element from the Problem Statement. This is because we want the Problem Statement to be devoid of bias. We used the following proposal to guide Product and Design on how to investigate and resolve the problem:

Proposal… we have data-driven health insights for when a patient’s health deteriorates (rapidly or gradually over time) and these are communicated clearly.

The problem statement is a great starting point, but what supporting evidence do we have? This is where market and user research comes in.

Challenge assumptions

Carrying out user research can be done in many ways. We have a highly-skilled Customer Success team, who help us engage with clinical teams and patients regularly. For our Alerts feature, we used surveys to capture quantitative feedback, usability tests to validate our designs, and beta-testing to test our product in the real world.

We sent a survey to clinical teams in order to validate our problem and our proposal. We had assumed that most of our clinical users would use our new Alerts feature, but from our survey, only 60% of those surveyed said they would like to receive alerts. 

Image of survey results showing 60% of users would use an alert and 40% would not use alerts

Understanding our target customer segments

We had assumed that alerting clinical teams promptly via text message or phone call would be ideal. However, our survey results showed us that email and our clinical app were the best means of communication.

Image of survey results showing 71% of users surveyed wanted to receive an alert via email

Backing up product designs with data

With this research, we realised that Alerts are better suited to some patient groups and clinical teams than others. Findings such as a preference for Email Alerts also helped us define our Minimal Viable Product (MVP). Of the 40% who preferred not to get an Alert, we investigated why and used their feedback to refine the product specifications further.

Our testing begins with some hallway testing, with co-workers, before approaching clinical teams and patients. This allows us to check the basics of our solution. Then we begin preparing tasks and questions we will use on call with participants. We try our best to remove bias by avoiding leading questions and using interview techniques like Boomerang.
We test as early as possible and often. Working on Alerts was no different and we tested an early prototype with our users. This highlighted areas that needed change before the next iteration.

User interviews and tests are usually run remotely over video call. We record the sessions and use tags to highlight parts for analysis. We create tags based on a number of things like user journey stages, features, and the overall experience felt e.g. positive or negative experience.

Examples of tags created on Dovetail during user research

An example of how we’ve tagged and added notes in Dovetail.

For a large feature like Alerts, we beta-tested with multiple clinical teams before releasing it to the rest of our users. Our goal with beta testing was to make sure that our Alerts feature provides an excellent user experience and keeps patients safe.

Prioritise patient safety

Our Clinical Safety Team brings together people from all across the company to discuss patient safety. In a nutshell, we assess every idea, problem, product requirement, design, development spec and release plan. We ensure that our product is reliable and easy to use.

For our Alerts feature, we wanted to reduce the risk of an alert getting missed. A missed Alert could lead to a patient not receiving urgent attention. A simple example of how we addressed this was to include the number of Alerts on a notification badge. This made it very clear when a new alert came in.

Define success metrics

What does success look like if we address this problem correctly? Setting success metrics ensures that everyone is aligned on what the goals are, keeps us focused, and lets us know if we’ve succeeded in making the product better.

Our success metrics for the Alerts were:
  • Clinical teams who set up Alerts enrol more patients
  • High adoption of Alerts across our target customer segments.

Think about what metrics you need to track before your new feature is developed. Doing this allowed us to closely monitor product adoption and user behaviour. It also informed the next iteration of alerts.

Test, learn & adapt

Our product process is something that we’ve adapted over time, and it continues to evolve. The above steps are quite simple, but they help us make product decisions based on research and not just gut instinct. Reflecting on the success metrics we were able to:
  • Help clinical teams with Alerts enrol 44% more patients within 6 months.
  • Achieve an adoption rate of 71.4% for Alerts across our target customer segments.
Image showing quote from Clinical Nurse Specialist on the importance of Alerts for them

Clinical Nurse Specialist in Portlaoise Hospital that started using alerts

Image showing statistic that hospitals have increased the number of patients they are monitoring by 44% in under 6 months

Clinical Nurse Specialist in Portlaoise Hospital that started using alerts