Defining the product form, competitive positioning, and clinical agent architecture for QuantumLife's next fundraising milestone.
0→1 Product Definition
Product Strategy
Product Design
UIUX Design
Clinical AI Agent
Sole Designer
Dashboard
Report Analysis Interface
Processing
Supporting Studies List
01 Product Context
The Strategic Problem:
Building a Fundraising-Ready Product in a Market Without Standardization
Longevity medicine lacks the clinical standardization that defines established medical fields. There are no universally adopted diagnostic protocols, no standardized treatment pathways, and no consensus evidence hierarchy for longevity-specific interventions. Physicians entering this space rely on fragmented literature, inconsistent supplement research, and manual synthesis — assembling action plans from scattered sources without systematic support.
Physicians spend hours manually assembling evidence-based action plans for each patient.
Constraint 1
No existing tool automates the full pathway from patient report to action plan.
Constraint 2
This gap represents both the market opportunity and the product challenge. QuantumLife's Longevity.Omics had validated the B2B2C distribution model and institutional adoption pathway through deployment at Gleneagles Hospital Hong Kong. The next fundraising round required a product that could demonstrate scalable clinical value.
Longevidence was that product. The core business hypothesis: a platform that automates evidence-backed action plan generation from patient reports would capture the clinical infrastructure layer of longevity medicine.
Whoever standardizes this workflow owns the highest-value position in the longevity clinical stack.
I joined as
the sole designer.
Within the first week, I identified that the team had not resolved a prerequisite
question:
what category of product Longevidence actually was.
02 Leading Product Strategy and Interface Design
I led product strategy and end-to-end interface design as the designer on the project. For Longevity.Omics, I independently drove:
✍️Product Strategy
🔍UX research
🧩IA (Information Architecture) Design
🏥Clinical Interface Design
👤Enterprise Admin System Design
📇Design System
🛠️Developer Handoff and QA
I worked directly with QuantumLife's CEO and engineering team, translating business requirements and physician research into a deployable platform within three months.
03 Product Definition
Surfacing a Product Form Misalignment with Category-Level Implications
Before designing any interface, I initiated a product definition process — writing a product brief for the technical team to validate, establishing documented functional scope to align design and engineering requirements.
Undocumented requirements create compounding alignment risk; I needed written confirmation of what we were building before committing design resources.
An all-in-one clinical platform
Report Upload
Evidence Synthesis
Physician Customization
Biomarker Extraction
Supplement Recommendations
Automated Action Plan Generation
I designed an initial low-fi based on the understanding:
When I presented to the team, the technical lead redirected: Longevidence should be closer to a search tool, referencing examine.com as the primary model.
I cross-referenced his direction against every written product artifact. The documentation consistently described all-in-one. The verbal direction consistently described search.
I diagnosed this as a product category conflict, not a design feedback issue. To make the implications concrete, I mapped both directions against five business dimensions:
Competitive risk assessment of the search architecture:
The action plan product form eliminates both risks. The action plan product form eliminates both risks. It occupies a workflow automation category that neither examine.com nor OpenEvidence operates in.
Both product forms share the same core functions — search, report upload, evidence display, action plan generation. The question is which function leads. Different emphasis produces different product positioning, different competitive dynamics, and different investor narratives. A search-led product enters OpenEvidence's category. An upload-led product defines a new one.
I brought this analysis to the CEO with a specific recommendation: the team needed to decide which function to prioritize before any downstream design or engineering work could be directionally sound.
04 Validation
Designing a Controlled Test to Resolve the Product Form Decision
The CEO approved user testing. I designed the test methodology, built both prototypes, and structured the evaluation to isolate the strategic variable from confounding factors.
Defining the test variable:
The real question was which product architecture matches physician workflow needs. This determined what I built and how I controlled for bias. I needed to compare mental models: does the physician want to drive the synthesis process (search) or validate an automated synthesis (action plan)?
Both prototypes implemented identical core functions — search, upload, evidence display, action plan generation.
The structural difference was the information hierarchy: which function was positioned as the entry point, and which was secondary. Product positioning determines feature emphasis. Feature emphasis determines homepage architecture. Homepage architecture determines user behavior patterns — and by extension, the product's competitive category, engagement model, and monetization surface.
Controlling for completion bias &
I brought both prototypes to equivalent completion levels. Users reliably gravitate toward whichever option appears more complete; if Prototype A had richer interactions than B, the test would measure polish preference, not architecture preference.
Result
50+ physicians tested over two weeks. Decisive preference for the action plan architecture.
05 Market Confirmation
Competitive Event Confirms the Strategic Logic of the Product Form
Three days after the product form was confirmed, Ali Health — Alibaba's healthcare division — launched a clinical evidence search product structurally similar to the architecture we had just rejected.
I assessed the competitive implications immediately.
Direct competition with Alibaba ($200B+ market cap) on information retrieval — the incumbent's strongest dimension. The advantage compounds with scale. A three-person startup has no structural differentiation to prevent displacement.
If QuantumLife had adopted the search architecture
The product form test cost two weeks. Building the wrong product form would have been irreversible.
The validated action plan architecture places Longevidence in a different competitive category entirely. I mapped the positioning:
Overlap
Minimal — different user needs, different workflow stages
This positioning allows Longevidence to grow without triggering competitive response from a resource-dominant player — the ideal strategic condition for an early-stage startup.
06 Design Focus
Designing for Trust, Transparency, and Value Perception in a Clinical AI Agent
AI interface design in 2026 faces two core UX challenges that determine adoption:
Users must understand why they should trust the generated output
Trust Calibration
Users must perceive the AI's effort as valuable, not trivial
Work Perception
In most consumer AI contexts, these are parallel problems solved through separate design mechanisms. In clinical AI that generates prescriptive action plans — plans that physicians will directly apply to patient care — these challenges converge.
I identified four design priorities to address these challenges for Longevidence:
1
Product Form Signaling
Homepage information hierarchy communicates product category on first contact
2
Platform Process Transparency
Retrieval breadth (number of studies, participant counts, database coverage) simultaneously communicates agent value and establishes clinical trust: comprehensive retrieval reduces risk of publication bias and population bias in recommendations.
3
Building Verifiable Trust in AI-Generated Recommendations
Every element of the action plan interface serves one purpose: giving physicians sufficient basis to adopt the recommendation. When AI output directly affects patient care, trust is not only a UX preference but also an adoption prerequisite.
4
User Workflow Integration
Interaction design aligned with physician decision-making patterns. Minimizes friction between the agent's output and the physician's clinical judgment process.
1
Product Form Signaling
The homepage must communicate the product form immediately — physicians should understand within seconds that this is an upload-first action plan platform, not a search engine.
The design challenge
Most AI products follow a conversational model, centering a search bar or chat interface as the primary entry point. Longevidence's validated product form inverts this convention — upload is the primary action, search is secondary. Currently, rare established AI product pattern exists for this hierarchy.
My Solution
To determine how to structure this unfamiliar hierarchy, I inspired by Pinterest and LinkedIn.
I used functional hierarchy analysis method, deconstructed both into primary action zones (highest-intent behavior, most critical content) and secondary action zones (lower-frequency, supporting actions).
This analysis produced a placement framework I applied to Longevidence: upload occupies the primary action zone, search is positioned in the secondary zone — accessible but subordinate to the core workflow.
Phase 1 · Report Parsing
OCR extraction, biomarker identification, abnormal marker flagging. The physician verifies the system correctly interpreted the report, particularly the biomarker chips, which allow immediate confirmation that the right indicators were flagged, establishing accuracy trust.
Phase 2 · Evidence Retrieval
Search terms, matched paper counts, identified supplements. When a physician sees "2,737 papers matched," the perception shifts from "can this system read my report" to "this system searches at a scale I cannot replicate manually." This establishes capability trust.
Phase 3 · Evidence Scoring
Four weighted scoring dimensions, qualification thresholds, final rankings with scores. The physician understands that recommendations are derived from methodology, not arbitrary selection. This establishes methodological trust.
Phase 4 · Action Plan Generation
Dosage, treatment duration, drug interaction alerts, consolidated summary. The physician knows the next screen will present a complete, reviewable, and editable plan. This establishes utility expectation.
2
Platform Process Transparency
The analysis phase is the physician's first encounter with the agent's intelligence. This phase is critical for establishing physician trust in the AI-generated output.
The design challenge
The system executes a multi-step pipeline (OCR → biomarker extraction → evidence retrieval → scoring → ranking) that is entirely invisible by default. In AI agent design, invisible processing creates a black box: the user submits input, waits, and receives output with no basis for evaluating how it was produced. In clinical AI, this gap is particularly damaging — a physician cannot trust recommendations whose reasoning process was completely opaque.
My Solution
I designed a scrolling step-by-step analysis sequence that makes each stage of the agent's pipeline visible as it executes: which biomarkers were identified from the report, which databases were queried, how many studies were retrieved per biomarker, and how participants and trial data were aggregated.
3
Building Verifiable Trust in AI-Generated Recommendations
Every element of the action plan interface serves one purpose: giving physicians sufficient basis to adopt the recommendation.
The design challenge
AI-generated recommendations are inherently less trusted than physician-derived conclusions. Physicians need to inspect not just what the system recommends, but the reasoning and evidence behind it. Every interface element must contribute to building verifiable trust.
My Solution
I designed a multi-layered evidence display for each recommendation: composite evidence score with four weighted sub-scores independently inspectable, specific dosage and treatment duration, clinical risk considerations, drug interaction alerts, and a full reference panel linking to primary studies with authors, journals, sample sizes, and trial outcomes. The physician can trace any recommendation from aggregate score → scoring methodology → individual study — a complete auditability chain from conclusion to source.
The evidence display is structured as a drill-down path from conclusion to source. The recommendation card above gives physicians the composite score, sub-score breakdown, dosage, and cautions — sufficient for rapid triage. When a physician needs to verify the basis of a score, the reference panel below surfaces the underlying studies with findings extracted specifically for this biomarker-supplement relationship.
Trade-off
Multi-layered evidence display increases interface complexity per recommendation. Prioritized verifiability over simplicity.
Outcome
Physicians can trace any recommendation from composite score to scoring methodology to primary source — a complete auditability chain that enables adoption without requiring independent literature verification.
4
User Workflow Integration
Physicians interact with multiple recommendations across multiple biomarkers in a single session. The interface must support efficient review, selection, and documentation without disrupting clinical decision-making flow.
