Yerbba

Yerbba began with a structural question: why are patients expected to make life-altering health decisions with information written for someone else?

The early venture work focused on turning that question into a viable product direction. We narrowed the scope to breast cancer because the condition combined several important factors: a complex treatment journey, long decision timeline, high emotional stakes, well-documented standards of care, and a patient population actively seeking better information.

Through customer discovery, we found that patients were not simply lacking information. They were surrounded by information they could not evaluate. Doctor conversations were constrained by time and liability. Online search produced generic, unreliable, or non-personalized guidance. Patient portals exposed records, but not meaning.

Policy, health IT adoption, and patient behavior were moving in the same direction. Patients had more access to medical information, but access alone did not help them understand what it meant for their care. Yerbba was designed for that translation gap.

This early product roadmap outlines how Yerbba moved from concept to MVP: first validating the patient need, then defining the core report experience, building the service flow for consent-based record access, and translating clinical data into patient-readable treatment guidance. It shows the product taking shape around one central promise: help breast cancer patients understand their care options without asking them to manually decode their own medical records.

That insight shaped the business position: Yerbba would not be another education site. It would be a personalized clinical translator between the health system and the patient.

The defining UX decision was the zero-input promise. Asking patients to manually enter staging, biomarkers, treatment history, and diagnosis details would reproduce the burden Yerbba was trying to remove.

That principle forced the product architecture. Onboarding had to focus on consent, not data entry. The system had to retrieve and parse records. The interface had to expose confidence, gaps, and next steps without overwhelming the patient. The report had to be useful even when clinical data was incomplete or newly updated.

I developed a three-layer information architecture:

• Dashboard: current status, urgent actions, and orientation.
• Treatment Plan: personalized treatment options with plain-language explanations.
• Disease Index: deeper educational content for patients who want to understand more.

The design goal was not to simplify cancer. It was to make complexity navigable.

I built Yerbba's frontend in React.js, which made the gap between static design and live healthcare data impossible to ignore.

Patient records varied widely in completeness, formatting, and timing. A component could not assume every field existed. A timeline could not assume every event had the same level of certainty. A treatment recommendation could not assume all supporting clinical markers were available. The interface had to handle absence, ambiguity, and updates gracefully.

That experience changed my design practice. I began writing design specs around states, not screens: complete data, partial data, missing data, delayed retrieval, updated records, and clinical combinations that did not fit the happy path.

Yerbba taught me that in healthcare UX, frontend craft is not cosmetic. It is part of patient trust.