Why Digital Health Adoption Stalls

Adoption problems are often diagnosed too narrowly. In digital health, low usage is frequently treated as a training problem: run another session, create another guide or remind the team again.

Training matters, but it is rarely the whole explanation.

Across NHS mental health implementations, I saw capable and motivated clinicians struggle to onboard people consistently. The product was only one part of the journey. Staff capacity, confidence, local ownership, patient contact and competing clinical priorities were just as important.

The lesson was simple: a workflow can be clinically sensible and still be operationally unrealistic.

The hidden work around onboarding

Onboarding a person to a digital therapeutic is not a single action. Someone has to identify who may benefit, explain the offer, answer concerns, confirm consent, help with access, troubleshoot the first use and follow up when engagement drops.

In a clinician-led model, that work competes with appointments, risk management, documentation and urgent care. Even enthusiastic teams can struggle to sustain it. The result is often a long list of theoretically suitable people but an unpredictable route from that list to active use.

This creates a misleading diagnosis. Low adoption can look like resistance to the product when the actual constraint is the amount of coordination the service model asks clinicians to absorb.

Testing a different division of labour

We began shaping a digital navigator approach. The principle was to separate clinical ownership from the practical work of onboarding and follow-up.

Clinicians remained responsible for clinical decisions and alert response. Navigators supported the non-clinical journey: making contact, explaining the service, helping people get started and resolving routine friction.

One early test began with a list of 15 people. Twelve were considered suitable, six had a phone conversation and four were onboarded within two weeks by one navigator working roughly a day and a half per week.

Those numbers were not a final evaluation, but they were useful operational evidence. They showed that focused capacity and a clearer journey could turn a static list into real conversations and informed choices.

What changed in the implementation model

The navigator model changed more than who made the phone call. It forced us to make the journey explicit.

We needed clearer scripts, contact attempts, escalation routes and expectations for the first weeks of use. We needed to define which questions a navigator could answer and when a clinician should become involved. We needed reporting that showed the difference between someone being identified, contacted, interested, onboarded and retained.

This produced reusable assets rather than relying on individual memory:

• conversation and hypercare scripts;
• launch and readiness trackers;
• defined follow-up points;
• feedback routes for patients and staff;
• adoption and retention reporting;
• clearer ownership between delivery and clinical teams.

Adoption is a service-design problem

The biggest shift was conceptual. We stopped treating adoption as a final step after deployment and started treating it as a service that needed to be designed.

That means asking where the burden sits, what choice feels like for the patient, which hand-offs are fragile and what support is available after the launch team leaves. It also means being honest when the evidence does not support the story we hoped to tell.

A good product still needs an operating model that can survive a busy Tuesday. In this case, that meant a community mental health team. The broader lesson is the same: implementation succeeds when the thing and the service around it are designed together.