Two phone screens side by side, a green health app showing a 98% streak and five-star ratings on the left, versus a red error-filled experience with lost data, no caregiver access, and unrecognised symptoms on the right, separated by a not-equal sign.

Why rare disease apps fail their patients-A UX designer’s perspective

We design for the average user. But for people with rare diseases, there is no average.

The health tech industry has a metric problem. Not a data problem, not a research problem , a metric problem. We measure success by retention rates, daily actives, and app store ratings. And by those measures, a lot of health apps are doing just fine.

The patients they were built for would disagree.

Rare disease patients are one of the most digitally abandoned user groups in existence. Not because no one is building for them, apps exist, platforms launch, grants get awarded. But because the definition of “success” that drives most health tech product decisions was never built around them in the first place.

Here’s what a successful health app looks like by industry standards: high engagement, smooth onboarding, strong retention in the first thirty days, positive reviews from users who found it intuitive. Here’s what a rare disease patient needs: an app that still makes sense on day 400, when their condition has progressed, their care team has changed, their diagnosis has been revised, and they’re logging symptoms at midnight because that’s when the flare hit.

Those are not the same product. And we keep building the first one and calling it healthcare.

First, who are we talking about?

There are thousands of known rare diseases globally. Each one affects a small slice of the population , but collectively, rare disease patients make up a vast and chronically underserved group that health tech almost always treats as an afterthought.

The classification of “rare” creates a strange invisibility. Each individual condition is too small to warrant major investment. But the total population living with rare diseases is enormous, quietly suffering across waiting rooms, specialist referrals, and years of unanswered questions.

And before they even reach a point where an app might help them, most have already survived something exhausting: the diagnostic odyssey. Rare disease patients wait years from the first onset of symptoms to a confirmed diagnosis. Many are misdiagnosed along the way , sometimes repeatedly, sometimes for decades. For conditions like Ehlers-Danlos Syndrome, patients have reported waiting the better part of their adult lives before receiving the right answer.

By the time a rare disease patient opens a health app, they have already spent years navigating a system that wasn’t designed for them. Then they open the app, and the same thing happens again.

Photo by Vitaly Gariev on Unsplash

The five ways we fail them

1. We build for common conditions and call it “Health”

Most health apps are built around the most prevalent conditions: diabetes, hypertension, depression, obesity. The logic is reasonable from a business perspective , large addressable markets, abundant research, established care pathways. But when the same design patterns get applied to rare disease contexts, they break.

A symptom tracker designed for a diabetic patient has a predefined list of relevant symptoms. A patient with a rare mitochondrial disease has symptoms that span neurology, cardiology, gastroenterology, and ophthalmology , often simultaneously. Asking them to pick from a dropdown of common symptoms is not just unhelpful. It’s a replication of the dismissal they’ve already experienced from the medical system.

Healthcare UX design, at its worst, is built around the common diagnosis. Rare disease patients exist precisely because their condition isn’t common. When we force their experience into generic templates, we send a message: this tool wasn’t made for you.

2. We underestimate cognitive load

Here’s something no persona document ever captures: rare disease patients often use health apps on their worst days. Flare-ups. Post-hospital discharge. Managing overlapping medication schedules while experiencing the very symptoms they’re trying to track.

Standard UX principles around cognitive load , keep navigation simple, reduce steps, limit choices are correct in theory. But in rare disease contexts, the stakes of getting this wrong are significantly higher. An ineffective interface isn’t just frustrating. It’s a barrier to a person managing a life-threatening condition under pressure.

Multi-step onboarding flows that ask for complete medical histories upfront. Forms that don’t save progress. Symptom logs that reset after a session timeout. These aren’t minor inconveniences. For someone managing a condition with episodic crises, losing data they just painstakingly entered can mean the difference between an accurate clinical record and a gap that confuses their specialist.

The worst thing about cognitive load failures in rare disease apps is that they disproportionately impact the people who are already carrying the most cognitive weight.

3. We forget who else is in the room

Rare disease patients frequently don’t navigate their care alone. They have caregivers , often family members , who manage appointments, track symptoms, coordinate between multiple specialists, and carry enormous amounts of invisible labor.

Most health apps design a single user journey: the patient. A caregiver who needs to log symptoms on behalf of a loved one, or hand off app access during a hospitalization, encounters a system that has no concept of their role. Shared access, role-based views, and caregiver-specific onboarding are almost never part of the initial product scope.

This isn’t just a feature gap. It reflects a deeper UX assumption: that the person experiencing the disease is always also the person managing it. For many rare disease patients, particularly those with conditions affecting cognition, energy, or motor function, that assumption is wrong.

4. We design for stability, not uncertainty

Most app UX assumes a relatively stable relationship between user and condition. You have X. Here are the tools for managing X. Check in regularly.

Rare disease patients frequently live with uncertainty as a permanent condition of their existence. Their diagnosis may be new and poorly understood. Treatment protocols may not exist yet or may be actively changing as research evolves. Their condition may be progressively degenerative, meaning the interface that worked six months ago may not account for how their functional needs have changed.

We design apps with defined states: onboarding, active use, support. Rare disease patients live in a state that most design frameworks don’t have a name for (ongoing limbo). The app that doesn’t account for “still waiting for a diagnosis,” “recently changed treatment,” or “condition has progressed since I last used this” is an app that will lose their trust quickly.

5. We treat accessibility as a checkbox, not a foundation

Accessibility in most health app design is an afterthought, added after core functionality is built, tested against basic WCAG criteria, and declared compliant. For rare disease patients, this is particularly catastrophic.

Many rare conditions directly affect sensory or motor function. Patients with conditions affecting their hands may struggle with small touch targets. Those with visual impairments need screen reader compatibility that actually works, not just technically passes. Those with cognitive symptoms need language that is genuinely plain and interfaces that don’t require holding multiple steps in working memory.

Accessibility in rare disease contexts requires designing from the margins inward, starting with the most complex user needs and building back from there. Instead, we almost always do the opposite.

What it would take to do this right

None of this is impossible. But it requires decisions that challenge how most health tech product teams operate.

Start the research differently. Patient advocacy organizations for specific rare diseases exist for nearly every condition with an active patient community. They are usually reachable, often eager to collaborate, and can facilitate research access in ways that are both ethically appropriate and practically efficient. NORD, EURORDIS, and condition-specific organizations are not just PR resources , they’re research pipelines that most design teams never tap.

Design for the caregiver journey from day one. Shared access, role-based permissions, and delegation flows shouldn’t be version 2 features. They should be foundational UX decisions made during architecture, not patched in after launch.

Build for episodic use under pressure. Every critical flow, symptom logging, medication tracking, emergency information, should be designed under the assumption that the user may be experiencing a flare, may have limited energy, and may be doing this at 3am with their phone at 20% battery. If it doesn’t work under those conditions, it doesn’t work.

Treat flexibility as a core feature. Symptom libraries, condition profiles, and care team structures in rare disease apps need to be genuinely customizable , not in a “add a note” way, but in a structurally flexible way that allows patients to build a record that reflects their actual, specific experience rather than a generic health template.

Measure success differently. Engagement metrics and daily active users are the wrong KPIs for rare disease health tools. What matters is whether the app helps a patient communicate more clearly with their specialist, whether it reduces the emotional labor of managing their condition, whether it builds an accurate longitudinal record that improves their care.

The bigger failure

The thing is, rare disease apps don’t fail because their teams don’t care. They fail because of how the industry is structured.

Research budgets favor common conditions. User testing pools skew toward the healthy and the available. Product roadmaps are driven by market size. Accessibility gets allocated a sprint rather than a philosophy. Patient advocacy doesn’t have a seat at the kickoff meeting.

These are systemic problems, and fixing them requires more than good UX intentions. But UX designers are not passive recipients of system constraints. We are at our best, the people in the room who ask “have we actually talked to these users?” We are the ones who make the business case for including edge case needs in the core product rather than the backlog. We are the ones who name the gap between what the brief describes and who is actually suffering.

Some rare disease patients wait longer for a diagnosis than most of us have been working in our careers. The apps that accompany them into that journey should, at minimum, feel like they were made with some understanding of what those years cost.

That’s not a product requirement. It’s a responsibility.