The Problem
Kyla is an AI-driven health care system that provides unique insight into current and long-term health combining patient data, lab tests and our Risk Engine to help patients understand and act on longitudinal health risks.
Working with doctors, data-scientists and engineers, I led the product and design team in developing the HIPAA-compliant Kyla app and Personal Health Manager — our own EHR — to manage patient and doctor interactions.
The design challenge at Kyla was not just in building the risk engine, but designing the layer between a probabilistic model and a human being making decisions about their health - without causing panic, false reassurance, or over-reliance on the system's outputs.
The System
Most health risk tools are static: they take inputs, run a calculation, and return a score. Kyla's engine was different - it was longitudinal. Risk wasn't a snapshot; it updated over time as new evidence arrived.
The inference followed a three-phase structure. The initial probability came from population-level data weighted by age, sex, and demographic baselines - not a generic average, but a personalized starting point.
Questionnaire responses that reflected specific symptom history, lifestyle, and reported conditions refined the Risk Engine score further. Biomarker data gained from lab panels or a medical visit refined the probabilistic picture even more.
Each new piece of evidence - a follow-up questionnaire, a new lab result, a reported behavior change - didn't overwrite the prior assessment - it updated it. The system became more accurate the more a patient engaged, and could surface changes in risk trajectory that a static model would miss entirely.
The key design insight embedded in this architecture: statistical likelihood and clinical priority are not the same thing. A 60% chance of a minor, reversible condition should not crowd out a 15% chance of something with high morbidity. The system had to reflect that distinction explicitly - and the design had to make that reasoning legible to patients and physicians alike.
Blood-spot card and biomarkers
Trust is key.
The Kyla patient journey crossed apps and web flows, lab ordering funnels, box design/instructions, LIMS interface and results - and had to meet or exceed expectation at every step.
The biomarker layer is what separates Kyla from symptom-checkers and generic health questionnaires. Patients could opt into dried blood spot (DBS) testing - a home collection format using a few drops from a finger prick rather than a clinical venous draw. The results fed directly into the Bayesian update cycle.
Blood spot cards were a meaningful design and operational bet. Venous draws required clinical visits and friction. Blood spot cards made lab-grade biomarker collection accessible at home. The clinical validity question was real - validated against venous draw accuracy.
The design challenge was presenting panel choice without overwhelming patients or implying that the base experience was incomplete without biomarkers.
The questionnaire-only path was a real, clinically meaningful product. Biomarkers made it more precise. That framing - additive rather than required - shaped how we introduced the option in the onboarding flow and in the ongoing risk profile experience, building trust.
Confidence intervals accompanied all risk outputs. Where biomarker data was present, confidence was higher and intervals tighter. Where the model was working from questionnaire data alone, that uncertainty was surfaced explicitly - patients and physicians could see not just the risk estimate but how much the system was willing to stake on it, building trust.
Key Design Decisions
Removing the Life Expectancy Clock
Early in the product, I surfaced a dynamic life expectancy estimate based on the user's current risk profile. It got user's attention as designed, stopping people mid-scroll.
I removed it.
What I observed in patient user studies: Users interpreted a probabilistic estimate as a fixed outcome. While it did motivate, it produced fatalism - or anxiety - neither of which led to the positive reaction I wanted. It also led to distrust as patients saw the accuracy as gimmicky.
The clock was statistically honest but experientially destructive.
What I did instead: Surfaced the Bayesian risk engine showing the probability of developing each disease, with attention focused on the condition where intervention would have the greatest clinical impact. Not "You have 50 years, 11 months, 15 days and 30 minutes left to live" - but "this is what's most-likely to matter most and why, and here's what can change it."
The replacement was more honest about uncertainty, more clinically defensible, and more actionable. It transferred agency back to the patient.
Morbidity Weighting Over Statistical Probability
The risk engine's default behavior surfaced conditions by likelihood. Left unmodified, that logic would consistently surface statistically probable but clinically manageable conditions above rarer, more serious ones.
The intervention: I advocated for - and worked with the data science team to implement - a prioritization layer that weighted morbidity alongside probability. Conditions with high severity and meaningful intervention windows surfaced first, even when raw probability was lower.
The tradeoff: Statistical purity and clinical utility are not always the same objective. Weighting morbidity means accepting that the system will sometimes surface a lower-probability condition above a higher-probability one. That's a value judgment embedded in the product layer, not the model layer - and it needed to be owned explicitly.
Confidence Improvement Through Progressive Questioning
Probabilistic models are only as good as their inputs. Incomplete patient data produces low-confidence outputs which - if displayed as-is - either undermine trust or mislead.
Rather than displaying model confidence as a fixed, opaque output, I designed a questioning format that actively improved it.
When the model identified insufficient data on a risk factor, the patient was prompted with targeted follow-up questions. Their answers refined the risk calculation in real time - visible to the user as increasing specificity in their risk profile.
Physician Adoption
Most clinical AI tools fail at the human-AI handoff.
They surface a recommendation without surfacing the reasoning, which leaves clinicians in an uncomfortable position - they can accept a conclusion they can't interrogate, or ignore a tool they don't trust. Neither outcome serves patients.
The Kyla physician-facing interface surfaced the driving factors behind each Risk assessment - the specific inputs and signals the model weighted most heavily.
A physician reviewing a patient's profile saw not just a ranked list of conditions, but the evidence structure behind each ranking: which biomarkers moved the needle, which questionnaire responses were weighted heavily, where confidence was high versus where the model was extrapolating from sparse data.
Physicians didn't just review the outputs. They used the driving factors to structure their diagnostic next steps.
The explainability layer was designed to make the model's reasoning a first-class output, not a footnote. That's a different interaction pattern than "AI suggests X, physician confirms." It's closer to "AI structures the hypothesis space; physician applies clinical judgment to navigate it."
Impactful Human AI Collaboration
Physicians interrogated the model's reasoning rather than accepting its conclusions. The explainability layer was informing clinical judgment, not replacing it.
Provider overrides fed back into model calibration, creating a feedback loop between clinical expertise and probabilistic inference and training data.
What this project is actually about
Designing AI products that handle high-stakes uncertainty requires a different kind of thinking than designing for clarity and convenience.
The core challenge at Kyla - every version of it - was the same question: how do you present uncertain information to a human being in a way that helps them make better decisions, without causing harm in the process?
The life expectancy clock failed that test. The morbidity-weighted risk engine passed it. The physician explainability layer made it useful for clinical practice. The confidence improvement loop made it honest about what it didn’t know.
Design System
Kyla · Figma Design Files
Core screens from the patient app and physician dashboard — built in Figma with a shared component system spanning iOS, Android, web, and EMR integrations.
