Your Digital Health Product Was Tested on the Wrong Patients

Product advisory for patient-facing digital health: why usability testing with healthy participants hides your real failures, and what a review from the chronic illness user perspective finds.

Your onboarding flow was tested by people who could sit up.

I do not mean that as a joke. I mean it as the most common structural flaw in patient-facing digital health, and it cascades into almost every other problem I find when I review these products. Your usability cohort was recruited from people who were well enough to attend a usability session, at a scheduled time, for forty-five minutes, sitting upright, holding a device in two hands, with sustained attention.

Your actual highest-need users are doing none of those things. They are lying down. They are using one hand. They are reading through brain fog on day four of a flare. They have eleven minutes of usable attention before the cost of the interaction exceeds its benefit, and they are making a continuous unconscious calculation about whether your product is worth the energy.

The people you tested with have no reason to perform that calculation. So your product has never been measured against the constraint that actually governs its use.

The energy budget is the real currency

Every interaction with a patient-facing product costs the user something. For a healthy user the cost is attention and it is trivially available. For a chronically ill user the cost comes out of a fixed daily budget that also has to cover eating, washing, medication, appointments and possibly work.

So the question your product faces is never "is this good." It is "is this worth the spoon." Products that cannot answer that question get abandoned, and your analytics will record the abandonment as low engagement — a motivation problem, to be solved with notifications. It was not a motivation problem. Your users did the arithmetic and your product lost.

This reframing is the single most useful thing I bring to a product review, because it converts a vague accessibility conversation into a measurable one: what does this flow cost, and what does the user get for it, and is the ratio defensible on a bad day.

What I find, nearly every time

Onboarding that front-loads the cost. Eleven screens before any value is delivered. A healthy evaluator experiences this as slightly tedious. A user in a flare abandons at screen four and never returns, and you have lost them permanently at the moment of highest intent.

Session timeouts written for banking. A form that logs you out after ten minutes of inactivity is a form that cannot be completed by someone who has to lie down halfway through. This one detail silently excludes your sickest users from the feature you built for them. Save the draft. Always.

Motion and contrast that hurt. Parallax, autoplay, animated transitions, low-contrast grey-on-grey. Migraine and light sensitivity are near-universal comorbidities in this population, and a great many products are physically painful to use. Honour the reduced-motion setting rather than treating it as an edge case.

Two-handed interaction as the default. Drag-to-reorder, pinch gestures, anything requiring a steady grip. Try your own product one-handed, lying on your side, and the list writes itself.

Daily logging designed by someone who has never logged daily. Symptom trackers that demand a full entry every day train users to lie, because on the worst days — the days with the most clinically valuable data — the user has the least capacity to complete the entry. So your dataset is systematically missing its most important observations. Make the minimum entry one tap and let the detail be optional.

Tone that describes the user rather than addressing them. Copy written about patients, in the third person, lifted from clinical documentation. Users detect this instantly and it determines whether the product reads as built for me or built about me. This is not a polish issue, it is a retention issue.

And the failure that costs most: no accommodation for the caregiver. A meaningful proportion of your sickest users are operating the product with help, or having it operated for them. Almost no product has a supported route for this, so people share passwords, and then your consent model is fiction.

Why review beats research here, sometimes

You should do user research with this population. Recruit for it properly, pay participants, accommodate asynchronously.

But there is a reason a review has a place alongside it. Recruiting chronically ill users into a study selects, again, for the ones well enough to participate — and the asynchronous accommodation that would fix that is exactly what most research operations are not set up to do. A structured review by someone who is both an experienced user of these products and able to read your codebase covers the same ground in days rather than months, and gets you to the point where you know what to ask in the research.

I come at this from two directions that are unusual together: a decade as a patient using every one of these tools in earnest, and a working development practice — I build patient-facing software, so the recommendations arrive as implementable changes rather than as findings you have to translate.

The test you can run this week, free

Take your primary flow. Complete it on a phone, one-handed, lying on your side, with the screen at minimum brightness, having not slept well.

Then do it again with a sixty-second interruption in the middle, walking away and coming back.

Everything that breaks in those two runs is breaking for your highest-need users every day. You do not need a consultant to run that test. You need someone senior enough to be embarrassed by the result, which is usually the actual blocker.

What good looks like

The products that work for this population share a small number of properties. Value before registration. State saved continuously and aggressively. One-tap minimum interactions with optional depth. A visible route for someone acting on the user's behalf. Reduced motion honoured. And copy that assumes the reader is intelligent, exhausted, and has been let down by something like this before.

None of that is expensive. Almost all of it is decided early and is costly to retrofit, which is why this review is worth running before launch rather than after the retention numbers come in.

I review patient-facing digital health products from the chronic illness user perspective — accessibility, energy cost, consent and caregiver paths — as a project or monthly advisory. See how that works →