Yerbba

‍

‍

The observation that started Yerbba wasn't a usability problem — it was a structural one. Clinical information is produced for clinicians. When it reaches patients, itarrives as a stack of documents in medical language, with no translation layer, no prioritization, and no guidance on what to do next. Patients in active treatment are expected to navigate this alone.

What made the problem solvable was the intersection of three conditions: Standards of Care data is structured and documented, EHR interoperability was making consent-based record retrieval technically feasible, and the translation work from clinical document to patient-readable report could be automated at aquality exceeding what any patient could manage manually.

We validated through extended conversations with breast cancer patients and oncology nurses before writing a line of code. The consistent finding: patients didn't want more information. They wanted the right information, translated into a formthey could act on.

The defining service design constraint was the zero-input principle. Asking breast cancer patients to manually enter clinical data — diagnosis codes, staging, treatment history — creates exactly the friction the service is supposed to eliminate. We committed to a service architecture where the patient's only action is consent.

This forced every design decision downstream. Data ingestion had to be automated through HL7 FHIR-compliant EHR connections. The processing pipeline had to map raw clinical data to Standards of Care categories without human intervention. The frontend had to render outputs that were accurate, readable, and visually structured enough that a patient under stress could navigate them in under five minutes.

Service flow: Consent & onboarding → Automated record retrieval → Clinical data parsing →Standards-of-Care matching → Personalized report generation → Patient-facing dashboard with guided interpretation.

‍

The output of the pipeline was rich but initially overwhelming: diagnosis profile, staging, biomarkers, treatment options across all modalities, clinical trials, andfollow-up schedule — all personalized to the patient's specific case.

I developed a three-layer hierarchy: the Dashboard (current status and most urgent actions),the Treatment Plan (all options with plain-language explanations ranked by relevance to her case), and the Disease Index (deep reference content forpatients who want to understand more). Progressive disclosure let patients whojust needed 'what do I do next' get that on the first screen, while patients who wanted to understand every treatment pathway could drill down without the top-level view becoming cluttered.

‍

Frontend Development

I built Yerbba's frontend in React.js. The design-to-build process taught me that the gap between a component that looks right in Figma and one that performs reliably across data edge cases is significant. Patients' records varied enormously in completeness and formatting — every component had to handle missing data, partial records, and unusual clinical combinations gracefully. Building my own product gave me a designer's instinct for implementation constraints before they become problems. I now write design specs with error states, empty states, and data-absent states as first-class considerations.

I co-developed the business model and go-to-market strategy alongside CEO Beltran Figueroa:the consent-based data access model, the data partnership strategy with health systems, and the initial focus on breast cancer as a beachhead condition with a well-documented standard of care and a highly engaged patient community. The strategic framing that guided the brand: Yerbba is not an information aggregator — it is a personalized clinical translator that sits between the clinical system and the patient.

‍

Founding Yerbba was the most complete design experience of my career: concept, strategy,service design, interface design, frontend development, and user research conducted in parallel, with real patients, on a live product. The hardest design problem in healthcare is not the interface. It is the service layer beneath the interface — the decisions about what information to surface, when, in what form, and with what level of confidence. Getting that layer right requires clinical domain knowledge, data science, and design workings imultaneously.