A healthtech platform for rare-⁠disease patient groups, with 10% more patients completing onboarding

Background

When someone gets a rare disease diagnosis, the first place they turn is often a Facebook group. Patient advocacy group (PAG) leaders are the people running those groups: patients, caregivers, parents.

PAG leaders manage whole rare-⁠disease communities through spreadsheets and email, on volunteer time.

Citizen Health set out to give them a real platform. I joined with almost no prior designs to build on. I built the PAG Leader Platform up from near-⁠scratch, and I have also contributed to the patient-⁠facing platform (web and mobile).

Problem

Citizen Health was building one platform to replace the spreadsheets, email and Facebook groups, and leaders’ feedback pointed to four problems it had to solve.

1. 1

   Patients weren’t reaching the platform.

   Many dropped out of onboarding, put off by medical terminology and worried about getting their answers wrong. Most of them were caregivers, not patients.

2. 2

   Leaders couldn’t see who had joined.

   Contact lists lived in spreadsheets kept by hand. Nothing showed who had signed up, who had consented and who had stopped halfway, so leaders couldn’t tell whom to follow up with.

3. 3

   Leaders didn’t have the time.

   They’re busy volunteers who don’t log in every day, and building a research survey from scratch was more than most could take on alone.

4. 4

   Leaders couldn’t use their community’s data.

   They had no picture of their community as a whole: nothing to show families, and nothing to bring to researchers and pharma.

Every leader tool depends on patients being there: a leader can’t reach, survey or learn from anyone who never finished signing up.

What made it harder: no clear product direction (features were hypotheses), leadership opinions that research didn’t always back, two connected platforms for two very different users, and a thin UI kit with no design reviews.

Process

Research first. When I joined, a lot of research already existed but it lived in scattered docs and past discovery sessions, and nobody had synthesised it into product direction. I ran a structured desk research pass and competitive analysis, then worked closely with the CEO and PO, using direct input from PAG leaders already partnering with the company to shape features. In an early-⁠stage startup, research often meant quick conversations and educated guesses. I pushed for rigour where I could; made peace with uncertainty where I couldn’t. What came out of it: leaders’ needs came down to the problems above, and the PAG Leader Platform was built around them. One place to manage the community, a way to bring new patients in, and data leaders could actually use.

Started with the least flashy module. The first plan was surveys and insights, to drive engagement. We deprioritised them and built the Contact Registry first. Leaders’ contact lists, usually spreadsheets, were the master list of every patient they needed to bring onto the platform, and without that list surveys and insights had no workflow to sit in. Advanced cohort insights waited until they could be validated, and full self-⁠serve research tooling moved to future work.

Consent as a trust layer, not a legal wall. To a family, joining a PAG, sharing contact details, sharing onboarding status, research consent and survey answers all sound equally alarming, and they mean different things. I kept them apart and showed each one at the moment it mattered: a plain explanation of what the leader would see and why, with the full legal text under “View more”. In the registry, a leader sees a patient’s details only with their consent; without it, the row stays anonymised. And sharing a survey with a research partner never shares the answers by itself.

Designed for leaders who aren’t power users. PAG leaders are busy volunteers, not SaaS admins, and many didn’t want to set everything up alone. So surveys work two ways: the leader builds one from ready templates instead of a blank canvas, or the Citizen team prepares it on their behalf and it appears in the leader’s profile, ready to launch.

One idea we cut: showing community results before a person answers. It promised more engagement, but on research surveys it could sway the answers, so it came out of V1.

Kept both platforms in sync. The PAG and patient experiences are tightly connected: a survey a leader creates becomes something a patient answers. I worked closely with the patient-⁠side PO to map the cross-⁠platform logic and catch conflicts early, before they became dev problems.

Why patient onboarding was a leader problem. Leaders’ first ask was “help us recruit and convert patients”, so when patients were dropping out of onboarding, fixing it was the most direct way to help leaders.

Pushed back when it mattered. On patient onboarding, leadership wanted to collect as much information as possible upfront, a reasonable instinct but one that clashed with what we were seeing in the data. Together with the Design Director, I ran usability testing on the existing onboarding with real patients: we interviewed them and watched them go through the flow. They hesitated at complex medical terminology, worried about making mistakes, and often dropped off before finishing. The case for a redesign wrote itself, but we still had to argue for it more than once.

The new flow ended up longer than the old one, and that was the point.

Most people signing up were caregivers, and what they needed wasn’t speed. They needed to feel understood: that they weren’t alone, and that someone was there to help and listen. So the redesign traded a few extra screens for plain language instead of medical terminology, a warmer tone and progressive disclosure, with some of leadership’s questions still in, just asked more gently.

The AI advocate connects the two sides as well. Leaders feed it their own research and resources through the AI Library, and patients talk to it in the mobile app. Before anyone designed it, I researched what would make patients trust it.

Researched the AI experience before a single screen was designed. Ahead of the patient mobile app launch, I benchmarked how companies use AI and messaging for proactive health guidance (PicnicHealth, Guava, NHS digital messaging, WhatsApp Business), mapping patterns across trust signals, tone, notifications, onboarding, and caregiver workflows. I wanted to understand what makes an AI health assistant feel genuinely useful and not intrusive.

Key findings that shaped the direction:

• Sensitive health info should never appear in notifications. The right model is a pointer (why now + one next step) that brings users into the app, without exposing PHI on a lock screen
• Records are only valuable when tied to action. Competitors show a new result or appointment and stop there, without turning it into concrete next steps
• Silence kills trust: users need visibility into what the AI advocate is doing: drafted, waiting, received, follow-⁠up due
• Caregiver-⁠first architecture is an unmet need. Rare disease care is often managed by caregivers; existing tools largely ignore this

The bottom line I delivered was that we should build a trusted advocacy workflow system.

From a thin UI kit to a design system. When I joined there was barely a UI kit. For the first couple of months I was the only designer, so I extended it just enough to close tasks faster. When the Lead Designer joined, we started building a proper design system together: tokens set up as Figma variables, and every component documented with its purpose, states, and usage. We didn’t work in engineering’s code, so we closed the gap from our side, bringing the Figma library in line with what the developers had in Storybook, component by component. Alongside that I started design reviews and regular syncs, which the team hadn’t had before.

Solutions

Patient onboarding. The caregivers signing up were put off by medical terminology and worried about getting answers wrong. We rebuilt the flow for them: plain language, a warmer tone, one thing at a time. It got longer, but it felt like being heard rather than tested. More caregivers finish signing up, so leaders get more of their community onto the platform without chasing each family by email.

PAG Leader Platform, designed end to end from near-⁠scratch, replaces the spreadsheets, email and Facebook groups leaders ran everything on.

Each module takes over one job leaders used to do by hand.

Contact Registry. Leaders upload the contact list they already keep, and the registry checks it against Citizen: who has joined, who has consented, who stopped halfway through onboarding. From the same screen they send an invitation to anyone who hasn’t joined and a reminder to anyone who hasn’t finished. A patient’s details appear only with their consent. Leaders know exactly whom to follow up with, without cross-⁠checking a spreadsheet against their inbox. For Citizen, every leader’s existing list becomes a way to bring new patients in.

Home. Leaders are volunteers who drop in when they can. Home opens on everything new since their last visit: new sign-⁠ups, survey responses, news. A leader with a few spare minutes sees what changed and what needs them, without opening every section.

Surveys & Answers. Leaders wanted research surveys but had neither the time nor the research background to build them. They start from ready templates, or the Citizen team prepares a survey for them and it appears in their profile, ready to launch. Answers patients already gave are reused, so families aren’t asked the same thing twice, and sharing a survey with a research partner never shares the answers. A leader can run a research survey without building one from scratch, and families answer fewer questions.

Insights. The data patients share becomes community-⁠level dashboards: demographics and baseline clinical and genetic charts. Research partners receive consented, de-⁠identified data through a separate process. Leaders can show families what their community looks like, and show researchers and pharma that their disease area is worth investing in, which is how a small rare-⁠disease community gets research started.

AI Library. Leaders upload the resources and research they’ve gathered over the years, and the library feeds the AI advocate patients talk to and the chat widget. Families get answers grounded in their own community’s knowledge, and leaders stop answering the same questions one by one.

Widgets. Branded sign-⁠up blocks leaders embed on their own websites and pages. New families can join from places they already trust, without the leader recruiting each one personally.