A blood-work product for a preventative medicine practice — built on the gap between what a lab calls normal and what a clinician would call optimal, and on turning that gap into something a patient can actually act on.
Private practice and concierge medicine have been growing steadily as patients look for more personalized, preventative care. Rather than treating illness after it appears, this shift — sometimes called Medicine 3.0 — is focused on optimizing health before problems develop.
I partnered with a preventative medicine-focused clinic who wanted a better way to help 500+ patients understand and act on their blood test results.
The practice was already ordering far more comprehensive panels than a standard annual physical — the kind of testing that produces dozens of markers per draw rather than a handful. Interpretating these results, patient-by-patient, was time-consuming and was ultimately reduced to focusing on critical issues, rather than the healthspan and performance optimization problem that the clinic set out to solve. More data made the underlying gap worse, not better: every additional biomarker was one more number reported against a range that wasn't built for the question being asked.
I collaborated with the medical director and his clinical team to define core requirements and project scope. I planned and executed the user research that was used to uncover patient needs and inform our design direction.
From there, I drove the end-to-end design process, delivering high-fidelity mockups, an interactive prototype, and a scalable design system to support future development.
Interviews and surveys with patients and the clinician across the whole lab-results experience, plus an afternoon going through the process myself to see where it actually broke.
The four-category result model that the entire product rests on, the rules for what the system asserts and what it defers to the clinician, and the MVP scope — what shipped, what waited, and the criteria that decided it.
The end-to-end interface, from a single result through trends and optimization plans, built on a reusable component system so the product stayed consistent as features were added on top of it.
Existing blood test software is built around diagnosing illness, not optimizing health. Results are flagged against wide reference ranges meant to catch disease — not against what "optimal" looks like for a healthy individual actively trying to improve.
A standard reference range is deliberately wide, because its job is to avoid false alarms across an entire population. Inside that range sits a much narrower band a preventative clinician would actually be aiming at. A patient can be comfortably inside "Normal" and nowhere near "Optimal", and standard lab software has no way to say so.
The clinician needed a system that could show patients where they stood beyond a simple normal/abnormal split, and translate that into a plan they could actually act on.
Mapping the current process end to end put the failure in an awkward place. Every step technically works: the lab request gets written, the draw happens, the results come back, the doctor reviews them. Nothing is broken in the sense of being defective.
The problem is where the process stops. It historically ends with an appointment — a conversation measured in minutes, once a year —, focused solely on things that point to disease, rather than a plan for optimization. Everything the practice actually cared about was getting lost.
To understand the real emotional and practical friction patients faced, I ran a mix of qualitative and quantitative research — including going through the process myself, from requisition to results, to see what the experience actually feels like rather than what people report about it afterward. This firsthand experience revealed the anxiety of waiting and confusion of interpreting complex reports without guidance.
I conducted hour-long patient interviews. This was my opportunity to get face-to-face with the prospective user population and have a conversation about their experiences with measuring their biomarkers, exploring what worked well and where the current process came up short.
I used short 10-15 minute surveys across the entire patient population to capture broader patterns and demographics at scale. This method provided a general idea of what their goals and motivations were.
The interviews explained why people were frustrated; the survey established how widely that frustration was shared.
Combining patient stories with personal experience created genuine empathy across our team. I wasn't designing for abstract personas anymore, I was solving problems I had felt myself.
Five core patient voices shaped the product. What's notable is that they describe the same failure from opposite ends — the patients want something the doctor also wants to give them, and neither the appointment nor the existing software has room for it.
"I track everything from my sleep to my workouts, but I'm frustrated that my lab results just tell me I'm 'normal' when I want to know how to be optimal."
"My hormones are all over the place, and I spend more time researching HRT and tracking my symptoms than my doctor spends listening to me during our 15-minute appointments."
"We're busy parents who want to make sure we're healthy for our 3-year-old, but we barely have time to understand our own lab results, let alone figure out what they mean for our family's future."
"My mom had diabetes and my dad had heart disease, and I'm constantly worried about what might be developing silently in my body that my annual checkup isn't catching."
"I want to spend consultation time optimizing my patients' health plans, but instead I'm explaining what their cholesterol numbers mean for the hundredth time this week."
Those five voices became five archetypes — four patients and one doctor — used to prioritize features and to drive user experience. The doctor persona was important because a feature that helped patients, but cost the clinician time in an appointment that was already too short wasn't going to work.
Mapping emotional states across each touchpoint located the low point precisely: not the draw, and not the diagnosis, but the stretch after results arrive, when a patient has numbers, no interpretation, and a year until anyone looks at them again. These findings helped get the team aligned on where the product's value actually had to sit.
Traditional healthcare is built to detect disease, not to optimize health, leaving patients frustrated with "you're not sick" instead of "here's how to thrive." In fact, that was the whole reason they were paying for concierge medicine in the first place versus going to their PCP.
Whether it's busy professionals needing quick insights, parents juggling family responsibilities, or doctors wanting efficient consultations, everyone is constrained by insufficient time. All users need healthcare tools that deliver value efficiently within real-world time constraints rather than adding to their already overwhelming schedules.
Patients are drowning in health data, but starving for meaningful guidance - they have lab results, wearable data, and symptom tracking, but can't connect the dots. Everyone needs complex health information translated into clear, personalized action steps that they can actually follow.
What they needed was a prescription. Not another set of numbers to interpret on their own, but a short, ranked list of things to actually do, with the reason attached and a clinician's name behind it. That reframing is what turned this from a data visualization project into a product.
Display biomarkers with 4 distinct ranges (abnormal, borderline, normal, optimal) instead of traditional binary normal/abnormal, with personalized explanations of what each result means for the user's specific demographics, health goals, and risk factors.
Provide educational information to the patient to help them understand their results. Have explanations that scale in complexity based on user type - from basic explanations for busy parents to detailed correlations for performance optimizers.
Generate specific, prioritized recommendations (lifestyle, supplement, medication, exercise, etc) based on individual biomarker gaps, with clear rationale for why each suggestion will impact specific lab values and overall health goals.
On top of the generated recommendations, the doctor and clinical team should be able to add/edit their point of view for that particular patient.
A single result is nearly meaningless on its own; the same value can be excellent news or bad news depending on where the patient came from. Every biomarker carries its own history, banded by the same four categories, so the movement between results is legible at a glance — and so a patient who has moved from borderline to normal can see that they are winning, which is most of what keeps someone doing the work between appointments.
Provide trend analysis that shows not just historical changes but projected trajectories, enabling early intervention before biomarkers move into concerning ranges and allowing users to see the long-term impact of their optimization efforts.
Offer flexible time-based views (3 months for hormonal cycles, 6 months for lifestyle interventions, etc) that help different personas understand their health changes in the most relevant context for their specific goals and concerns.
Patient gets their blood drawn to be sent for testing.
Test results are delivered directly to the patient's phone in the app.
Along with the results, patients get feedback and a plan from their doctor.
The doctor uses the appointment to answer questions — the patient has already reviewed their results.
The individual test result is the atomic unit of the whole app. Everything above it — the reports, the trends, the plan — is an aggregation of this one component, so it got designed first and argued about longest.
Abnormal, borderline, normal, optimal. The split matters because it changes what the result is for. Two categories answer a yes/no question about disease. Four categories answer a directional one: where am I, which way am I moving, and how far is the target. That's the question a preventative practice is actually asking, and it's the question the software had never been built to answer.
Abnormal is easy: it's the lab's own reference range, and the product doesn't second-guess it. Everything inside that range is where the design work sits, and where the product is making a claim the lab isn't. Those boundaries had to be defined per biomarker — some markers are two-sided, some are one-sided, and several vary by sex, age, and a patient's goals — which made this a clinical design problem long before it was a UI.
Drawing a narrower band than the lab does is a real claim, and the product had to be honest about whose claim it was. The categorization is the practice's position, presented as the practice's position — not an independent diagnosis and not a replacement for the clinician's read. That's why the doctor keeps edit rights everywhere downstream: the system proposes, and the clinician stays in the loop on anything it proposes.
The research produced more good ideas than a first release could carry. The cut needed a rule rather than a vote, and the personas supplied one: ship what hurt every persona, defer what only helped some of them.
That rule is unglamorous and it settles arguments fast. Digestible reports, the four-category system, trends, and improvement plans all cleared it — every archetype, patient and doctor alike, was blocked by their absence. AI coaching, interface personalization, and a branded Health Score didn't. They were genuinely good ideas that happened to serve some personas much more than others, which makes them second-release ideas, not bad ones.
The Health Score is the interesting deferral of the three. It's the most marketable feature in the set and the most dangerous to ship early: a single composite number is exactly the kind of reductive summary the product exists to argue against, and rolling it out before the four-category model had earned patients' trust would have undercut the thing that made the product different.
Wireframes and an IA diagram came first, and the IA earned its keep more than the wireframes did — agreeing on how results, reports, biomarkers and plans related to one another settled a set of naming and hierarchy questions that would have been expensive to discover later in visual design.
Interactive prototypes covered the core workflows before any of it was committed to final visual design. For validation, the original interview participants came back to test against the prototypes — which is the part worth noting, because they could be asked directly whether this solved the specific thing they had described months earlier. A fresh testing pool would have told us whether the interface was usable. This pool could tell us whether it was the right product.
The narrower "optimal" range that is defined for each biomarker is a clinical opinion, not a fact, and "optimal" is far less settled across the field than "abnormal" is. The product handles this by attributing the position to the practice and keeping the clinician in the loop on everything downstream.
Reference ranges shift, and optimal targets shift faster, because the literature underneath them is younger. That's ongoing clinical work and a practice adopting this is signing up for maintenance.
Almost everything interesting in this product comes from movement between draws, and a new patient only has one. The first result is the weakest version of the experience, and it's also everyone's first impression — a real tension the MVP mitigates through historical data ingestion, but doesn't completely solve.
Interviewing people about their blood work selects for people who think about their blood work. That's a fair match for a concierge practice, where patients opted into exactly this kind of care, but it's a genuine limitation on how far these findings generalize past it.
It gets much easier once there's engagement data to personalize against. Doing it earlier would have meant guessing at what to adapt to.
It only works once patients trust the four-category model underneath it, because a composite number is a summary of that model rather than a replacement for it. It requires a whole clinical design process that was out of scope for the MVP.
And to know whether any of it worked, three things are being measured: