Decision Logic Before Build Cross-platform clinical prototype verification
Principal Product Designer · Discovery engagement, 2025
A clinical mobile product can ship a logic error (an unflagged critical lab value, a wrong dose interval after an oral-to-IV switch) that no wireframe will reveal, because it only shows up when a care coordinator taps the wrong control and the state machine goes silent.
The constraint was Discovery-stage: these failures had to be caught before native build, before backend, before a device-management policy existed. So I built a coded iOS and Android prototype that runs the actual decision logic, not a mockup of it.
Siarhei Mardovich designed and built a cross-platform clinical prototype that verifies decision logic, accessibility structure, and iOS/Android parity before native development. The artifact combines Apple HIG and Material Design 3 patterns in a single running HTML prototype, surfaced 2 pre-build defects, and was handed to native teams as the verification baseline. Relevant to healthtech, clinical informatics, regulated mobile UX, and usability testing.
Hiring teams: use this as a concise case summary.
Role
Principal Product Designer and prototype engineer. Designed and coded both platform variants from scratch: the interaction model, the clinical data structure, the state machine, and the accessibility scaffold. No native app team, no build pipeline, no backend.
Approach
Coded HTML as R&D instrument. Each platform rendered at production constraints inside a 290px iframe. Business logic validated through live interaction (full workflow traversal, form submission, state transitions), not review of static screens.
Outcome
Complete clinical workflow verified across medication management, symptom diary, lab results, messaging, appointments, and reminders, on iOS HIG and Material Design 3 patterns, with accessibility structure in place before native development begins.
Outcome: the native teams inherited a behavior contract (route table and parity rules already fixed) rather than a brief to re-derive interactions during sprint planning. No post-build metric exists; the verified result is that 2 divergence defects were caught before any production code was written.
Domain transfer
| Clinical logic | Fintech equivalent |
|---|---|
| Abnormal lab flag propagation | Fraud / risk alert escalation |
| Medication reminder conflict resolution | Pre-trade compliance check conflicts |
| Empty state handling for missing labs | Missing data handling in credit models |
Why a wireframe review is not enough
In clinical software, a logic error discovered in UAT becomes a compliance incident waiting to happen. A broken conditional (the one that fails to flag a lab value above the critical threshold, or the one that shows the wrong dosing interval when a patient switches from oral to IV) does not announce itself on a wireframe. It announces itself when a care coordinator clicks the wrong button and the state machine goes silent.
The gap between a wireframe review and a functional prototype is the gap between seeing a screen and understanding a workflow. A wireframe can show that a medication reminder screen exists. It cannot show that the reminder fires at the right interval after dose entry. It cannot show that the abnormality flag on a lab result correctly propagates to the care team alert. It cannot show that navigating from the symptom diary to the medication screen and back preserves the user’s scroll position and clears the right form state.
These are logic problems. In clinical informatics, where regulatory requirements, care team trust, and patient safety converge on the same interface, logic problems that surface in UAT cost sprint cycles, compliance reviews, and organizational credibility.
A wireframe review asks whether the screen looks right. A coded prototype asks whether the workflow behaves correctly at every branching point.
The medium that makes the second question answerable, before native build, before backend infrastructure, before a device management policy is in place, is a running application rendered in a browser. Figma, clickthroughs, and simulated interaction prototypes each test one dimension. A coded HTML prototype executes the actual decision logic, handles the actual edge cases, and fails in the actual ways that matter.
Single-file HTML prototypes are the right R&D instrument for clinical informatics Discovery because they compress 4 validation layers into one artifact: business logic, accessibility structure, platform-specific usability patterns, and cross-platform parity, all at production constraints, with no infrastructure cost. I weighed 3 instruments (a Figma clickthrough, a platform-split native spike, and a single-file coded prototype) and chose the coded prototype because only it executes the shared state machine under both HIG and Material 3 at once, which is where the divergence lives.
4 tests. One artifact.
Static design tools can test one thing at a time. A Figma prototype tests visual design and click-through navigation. An accessibility audit tests markup in isolation. Platform-specific usability testing requires platform-specific builds. Cross-platform parity review requires running both builds simultaneously. The result is a sequential, expensive process in which each test generates findings that could have been integrated upstream if the artifact had supported it.
A coded HTML prototype collapses this sequence. At the same time, in the same artifact, it tests 4 things that clinical software must get right before build:
Does the state machine handle every branching case correctly: dose entry, abnormal flag, reminder conflict, empty state?
Are heading hierarchy, landmark roles, ARIA labels, and focus management correct at production font sizes and viewport constraints?
Do iOS and Android interaction patterns (sheet modals vs. bottom drawers, segmented controls vs. chip filters, tab bars vs. navigation drawers) match platform expectations under clinical workflow pressure?
Does the same clinical information arrive with equivalent meaning and equivalent next action on both platforms, or does platform-specific treatment create a divergence that becomes a care gap?
The SignalCare CDX prototype
The SignalCare CDX prototype runs all four tests simultaneously. Both platform variants (iOS HIG-compliant, Android Material Design 3-compliant) run in the same browser tab, driven by the same clinical data model and the same state machine. A clinical stakeholder can trigger the same action on both phones at once and watch whether the workflows stay equivalent. An engineer can inspect the semantic markup of both variants in a single review. A project manager can walk a regulatory reviewer through the entire clinical scope (14 routes, 8 sheet variants, full form validation) without scheduling two separate platform demos.
The prototype is not a preview of the native app. It is evidence that the clinical logic is sound enough to build a native app from.
SignalCare CDX · iOS and Android
The comparison view is designed as a clinical stakeholder instrument. The Run Script button at the top right triggers a scripted walkthrough, the same sequence executed on both phones simultaneously, so a product owner, clinical lead, or regulatory reviewer can observe platform parity directly, without managing two separate demos or switching between screenshots.
The iOS variant implements Apple HIG conventions throughout. System typeface stack, sheet modal pattern for contextual actions, segmented controls for view switching, status bar awareness with safe area insets, and iOS-native color semantics: system red for critical alerts, system orange for caution states, system green for confirmations. Every interaction pattern is something an iOS user recognizes from the system apps they use daily.
The Android variant implements Material Design 3 conventions. Manrope for display and IBM Plex Sans for body, bottom navigation with icon-plus-label targets, chip-based filtering for multi-select states, elevation hierarchy through surface and container tokens, and dynamic color roles. The typographic scale and spacing are tuned to Android’s denser information density norms.
Both variants share an identical state machine. The clinical data model (medications, appointments, lab results, symptom diary entries, reminders, care messages) is the same object graph under both surfaces. Adding a reminder on iOS adds it to the same shared database that the Android variant reads. This is not a coincidence of the prototype design; it is the architecture the native app needs to replicate.
The prototype surfaced 2 pre-build defects that static wireframes had not: scroll state loss during deep-link navigation in the medication detail flow, and an inconsistency in how abnormal lab flags were visually ranked between the two platforms. Both were identified, diagnosed, and fixed in the prototype.
What the native team inherited
The prototype was handed to the native iOS and Android teams as a behavior contract. The state machine, route table, and assertions below capture the decisions that had already been validated before build began.
Validated routes and state transitions
- On launch, both variants render the same patient dashboard from the shared data model.
- Adding a medication reminder on iOS updates the shared state and reflects on Android within the same session.
- Navigating from the symptom diary to a medication detail and back preserves scroll position and clears transient form state.
- An abnormal lab result flagged as critical propagates to the care team alert on both platforms with equivalent priority.
- Empty states display for medications, appointments, and diary when no data exists, without breaking navigation.
- Form validation prevents submission with missing required fields and returns focus to the first invalid input.
- Sheet modal (iOS) and bottom drawer (Android) open from the same trigger, manage focus, and restore focus on close.
- Dose switch from oral to IV updates the interval calculation through the deterministic ruleset.
Playwright assertions: route count = 14; sheet variants = 8; focus trap passes on open/close; cross-viewport layout stable at 290px effective width; pill element single-line integrity across all routes.
Route dispatch, reused from the prototype source
This is the actual renderMain(route) dispatch object from the running prototype, the map every native route had to preserve on handoff.
function renderMain(route) {
const content = {
calendar: renderCalendar(),
"appointment-detail": renderAppointmentDetail(route),
medication: renderMedication(),
"medication-detail": renderMedicationDetail(route),
diary: renderDiary(),
labs: renderLabs(),
"lab-detail": renderLabDetail(route),
messages: renderMessages(),
reminders: renderReminders(),
settings: renderSettings()
}[route.name];
...
}
Annotated defect walkthrough
The prototype surfaced 2 pre-build defects. The first, scroll state loss during deep-link navigation in the medication detail flow, lived in the route transition handler. The state machine was restoring the route but not the scroll position of the previous view, so a user returning from a medication detail landed at the top of the list instead of their prior position. The fix added a scrollRestoration step to the route-onExit hook.
Scroll state lost on return
- User scrolls medication list to item 7
- Taps item 7 to open medication detail
- Returns to list; viewport resets to top
- State machine node:
route.onExitmissing scroll restore
Scroll position restored
- User scrolls medication list to item 7
- Taps item 7 to open medication detail
- Returns to list; viewport returns to item 7
- State machine node:
route.onExitpersists and restores scroll offset
The second defect was an inconsistency in how abnormal lab flags were visually ranked between iOS and Android. The same data object produced different apparent priority because iOS used color alone while Android used color plus an elevation badge. The fix aligned both surfaces to the same visual-ranking grammar: color, icon shape, and label text, with elevation reserved for unread count only.
My starting assumption was that platform divergence would surface in layout. Both defects broke it: they lived in the state machine, in scroll restoration and flag ranking, exactly where a wireframe cannot look. The rule I carry forward: parity is a behavior property, not a visual one.
Methods and standards
The methods below were applied during the Discovery phase. They are listed here as a readable reference for reviewers and recruiters, not as a parser-only keyword dump.
Technical details
- Two single-file HTML prototypes (iOS and Android) combined in a single comparison showcase; no build tools, no framework, no CDN dependencies
- Vanilla JavaScript state machine with a shared clinical data model: medications, appointments, labs, diary, reminders, messages, reports, settings
- 14 named routes per platform covering the complete clinical scope of a specialty-care patient-facing application
- 8 bottom sheet variants: appointment actions, reminder editor, add event, appointment reminder, contact details, and confirmation states
- Full form validation with accessible error states, inline feedback, and submission confirmation flows
- Semantic markup throughout: proper heading hierarchy, landmark roles (
main,nav,region),aria-labelon all interactive elements, focus management across sheet open/close cycles - iOS: system font stack, HIG color semantics, safe area inset handling, sheet modal pattern, tab bar with badge counts
- Android: Manrope + IBM Plex Sans, Material Design 3 color roles, chip-based filtering, bottom navigation with badge indicators, elevation-aware surfaces
- Tested at 290px effective viewport, the production constraint imposed by the dual-phone comparison view at a standard 1440px display
- Playwright headless browser verification: pill element single-line integrity across all routes, cross-viewport layout stability, state transitions
- CSS custom properties with
@layerspecificity management; no!importantin prototype code
Design Trade-offs
Traded faster visual iteration in Figma
For a running state machine that exposes logic errors before native build
Traded cleaner separation of iOS and Android code
For one shared state machine validated under HIG and Material 3 at once
Traded a single reusable component set
For iOS and Android patterns that survive clinical workflow pressure
Let’s Talk
Open to principal/staff product design roles · Greater New York City Area · siarhei.mardovich@gmail.com · LinkedIn · Resume