Decision Logic Before Build
An iOS and Android clinical mobile prototype sharing one data model and one state machine, with divergent platform treatment, built to verify decision logic, accessibility structure, and workflow coverage before a single line of production code was written.
The design challenge was not to produce polished screens. It was to surface every logic error, accessibility gap, and platform divergence while they were still cheap to fix: in Discovery, not UAT.
In clinical software, a logic error discovered in UAT is not a design problem. It is 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 not visual problems. They 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.
The question a clinical wireframe review answers is: does this screen look right? The question a coded prototype answers is: does this workflow behave 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. Not Figma. Not a clickthrough. Not a simulated interaction prototype. A coded HTML prototype that executes the actual decision logic, handles the actual edge cases, and fails in the actual ways that matter.
That is what makes single-file HTML prototypes the right R&D instrument for clinical informatics Discovery. Not convenience. Not speed. The ability to test business logic, accessibility structure, platform-specific usability patterns, and cross-platform parity simultaneously, in a single artifact, at production constraints, with no infrastructure cost.
Four 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 four 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 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 · Simulated patient data · No real clinical or personal information
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 two categories of issues 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 in under an hour. In a native build, either issue would have required a sprint cycle and a platform-specific regression test.
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
All patient data, clinical records, medication names, lab values, and care team details are simulated. No real patient, no real clinical information, and no HIPAA-regulated content appears in this prototype. The prototype demonstrates workflow logic and platform treatment, not real clinical data.
What This Demonstrates
Clinical informatics R&D is not primarily a design problem. It is a logic verification problem. The question that matters most in Discovery is not whether the screens are polished. It is whether the clinical workflow is internally consistent, platform-appropriate, and accessible at every branching point, before the native app team starts the sprint that will make those decisions expensive to change.
A coded HTML prototype is the right instrument for that verification because it is the only medium that closes the gap between a design review and a running system without requiring native app infrastructure. It executes the actual state machine. It runs at actual viewport constraints. It exposes actual accessibility gaps in actual semantic markup. And when two platforms are rendered simultaneously in the same browser tab, it makes cross-platform parity a directly observable fact rather than an assumption carried forward from a design spec.
This showcase demonstrates a Discovery methodology for clinical mobile software. The prototype is not a deliverable. It is an R&D instrument that compresses what would otherwise be a multi-sprint native development cycle into a single artifact that a clinical lead, a product owner, and a regulatory reviewer can evaluate together, in a browser, before build begins.
What Gets Measured
Clinical benchmarking rebuilt as an exception-led command center for care quality, equity, and cross-service comparison.
View case study →
Know Who Knows
An enterprise talent mapping interface that makes the topology of expertise visible across three coordinated views.
View case study →