Connecting underserved communities to care

01The problem

Secured Health connects underserved communities with culturally competent community health workers (CHWs). The hard part is not the match, it is what happens after. A CHW carries a caseload of patients, each with a care plan, appointments, referrals, and follow-ups that have to be tracked, updated, and handed off. That coordination lived across spreadsheets, texts, and memory, and when a step slipped, the person with the least slack was the one who missed care.

This is workflow-heavy product work: multi-step task queues, care-plan state that changes as patients move through it, and hand-offs between CHWs and the administrators who supervise dozens of cases at once.

02My role

I was the lead product designer for the care-coordination features of the web app. I owned the end-to-end flows: the CHW caseload dashboard, the individual patient care-plan view, and the task and follow-up queue. I ran the SME interviews, drove scoping with the PM and engineers, and specified the interaction model and system states down to empty, loading, and error cases.

03The approach

I interviewed CHWs and administrators before designing anything. Two findings changed the direction. CHWs did most of their coordination on a phone between home visits, not at a desk, and they distrusted any screen that hid what to do next behind navigation. So I anchored the design on a single prioritized "today" task queue instead of the multi-tab case-management layout we first sketched.

For v1 we cut two-way SMS to patients and a reporting dashboard for program managers. Both mattered, but the SME sessions showed the acute pain was the CHW losing track of follow-ups, so I scoped v1 to the caseload, care plan, and task queue and pushed the rest to later. I designed the states non-technical staff actually hit in time-pressured field work: an empty caseload for a newly onboarded CHW, loading and partial-sync states for weak-connection visits, clear error and retry when a care-plan update failed to save, and an overdue-follow-up state that surfaced the case instead of burying it. I kept contrast, tap targets, and text sizing accessible for older workers and outdoor screens.

04What I built

The shipped v1 covered three connected surfaces: a CHW caseload dashboard, a per-patient care-plan view whose status advances as the patient moves through the plan, and a prioritized task and follow-up queue.

Scope was negotiated tightly with the PM and engineers. Engineering flagged that patient status could not sync reliably in real time over the connections CHWs worked on, so instead of live status I designed an explicit last-synced timestamp with a manual refresh, and made every care-plan edit optimistic with a visible pending-then-confirmed state so a CHW was never left guessing whether a change stuck. That constraint shaped the whole interaction model, and I iterated the queue and care-plan components with engineers to match what the API could actually deliver.

05Outcome

After launch, watching real usage showed CHWs were completing tasks but administrators still could not see whether a caseload was on track, so follow-ups slipped at the supervisor level. For v2 I added a caseload health view for administrators, rolling up overdue and at-risk cases across a CHW's patients. It was the reporting need we had deliberately deferred, now shaped by real behavior instead of a guess.

Directionally, CHWs stopped keeping their side spreadsheets and moved coordination into the app, and administrators reported catching overdue follow-ups earlier instead of discovering them after the fact.

06Reflectionoptional

Deferring the administrator view was the right call for shipping, but I under-weighted how much supervisors needed visibility, and it showed up as slipped follow-ups until v2. Next time I would design the CHW and administrator perspectives as one system from the start, even if I still shipped them in stages.