TCC — meeta

Replacing a spreadsheet-run respite program with a platform people can trust…

Tennessee Caregiver Coalition ran its volunteer respite program on a borrowed, faith-branded registration tool and a stack of spreadsheets. I owned discovery, requirements, and the registration flows for two of the platform's three user roles, on a ten-person team building toward a production handoff.

Role

UX Designer — owned discovery and registration flow design for volunteers and caregivers

Timeline

May – Aug 2026 · 12 weeks

The business problem

TCC's Volunteer Group Respite Program pairs trained volunteers with family caregivers of children and adults with disabilities, so caregivers get a few hours to rest. Running it meant relying on My99Balloons, a registration platform TCC didn't own, originally set up through faith-based grants and Christian partner organizations. It worked, but it wasn't built for TCC, and it wasn't accurately tracking who was actually coming.

Why now?

Two problems were compounding. First, TCC wanted to move to an independent platform that reflected its own inclusive mission rather than a legacy faith-based grant relationship. Second, and more urgent operationally: volunteers and care recipients were showing up mismatched at events, because nothing in the old system communicated that registering was an application, not a guaranteed spot.

Designer by title, requirements owner in practice

Discovery & requirements

Scope

Audited the My99Balloons platform, ran comparative analysis against Eventbrite, Humanitix, and SignUpGenius, and interviewed caregivers and volunteers to translate what I learned into the acceptance criteria for the volunteer and caregiver registration requirements in the PRD.

Prioritization

Execution

Team

10 people: PM, DM + 8 designers

6 prioritized flows · 3 stakeholder roles, design-only, Figma prototype

A volunteer program that had outgrown its own tools

My role

I wasn't the product manager on this team, but on a pro-bono engagement with eight designers and no engineering team to hand off to mid-project, the six PRD requirements got split by owner, and I was accountable for two of them end to end: research through acceptance criteria through shipped Figma flows.

Stakeholder alignment

Within my two flows, decided that reusable caregiver profiles had to ship before anything else in the caregiver flow — the interview data showed re-entering care recipient details was the single biggest source of drop-off, so it became the foundation the rest of the intake built on.

TCC's leadership was explicit that the platform could not imply a guaranteed placement — a legal and operational constraint, not a design preference. I owned translating that into interface language ("pending confirmation" instead of "you're registered") across every confirmation and status screen in both flows, and building the consent pop-up TCC's PRD specifically called for.

Took the volunteer and caregiver registration flows from low-fidelity wireframes through a fully interactive, hi-fidelity Figma prototype, including the care recipient intake forms, consent flow, and role-based entry points.

Discovery

What research actually changed

We audited the old platform, ran a competitive scan, and interviewed caregivers, volunteers, and staff including TCC's CEO Dr. Megan Schwalm and Volunteer Coordinator Imani Wright, then synthesized findings through affinity mapping in FigJam.

The insight that shaped my flows

Caregivers were re-entering the same care recipient information emergency contacts, sensory needs, communication preferences every time they registered for a new event. Interviews and affinity mapping both pointed to this as the primary source of cognitive overload and drop-off during intake, which is why reusable profile cards became the anchor decision for the caregiver flow.

Separately, mapping the full decision tree for both roles waitlists, cancellations, profile updates, password recovery surfaced edge cases the old platform simply didn't handle, which fed directly into the acceptance criteria I wrote for both requirements.

Mapping the volunteer side

The volunteer flow carried more account-management complexity than expected — password recovery, profile and role changes, and event sign-up all needed to coexist with the same "application, not guarantee" framing. I flagged the open question about where training content would eventually live directly on the flow itself, so the next team wouldn't have to reverse-engineer the gap.