OxiWear Clinical Report Portal

Two ways to select vitals

V1 of the reporting flow was rigid: reports defaulted to just SpO₂ and pulse rate, capped at a hard ten-minute window of raw, one-second-resolution data. As we expanded the flow to let clinicians build custom multi-vital reports, I hit a decision point with my Head of Product at report-configuration step two: keep the portal's established grouped-dropdown pattern for selecting vitals, or adopt a side panel — every vital as a checkbox, with live min/avg/max previews.

My first instinct

I initially resisted the side panel — its own width would eat further into an already tight ten-minute window. But the design principle forced a sharper question than which one looked better: was this step a diagnosis stage or a setup stage?

The question that settled it

It's setup — an administrative step where the chart is a sanity check, confirming which streams are active and roughly what they look like, not something a clinician is diagnosing off of. Shrinking that preview cost nothing in safety. With safety off the table, ease of use won: for someone toggling through dozens of raw physiological streams, the side panel's multi-select and live summaries were a clear improvement over reopening a dropdown for every vital.

Where the trade-off still shows up

That full resolution doesn't carry over to a printed report, though — paper can't scroll. A print shows the overall trend rather than every data point past a certain range. That's an accepted limitation of the static medium, not a gap in the interactive design.

The pattern behind the escalations

A specialist would select a time range — an afternoon window, say — expecting it fully populated with one-second data, and the generated report would come back with noticeably fewer points than expected, or visible gaps in the line graph. Real device gaps cause this: the device wasn't worn continuously, or a Bluetooth connection dropped. But to the specialist it looked broken, and they'd contact Customer Success, who'd loop in engineering to check the backend — confirm the device user, confirm the timeframe — before concluding it really was just a gap in wear time. That round-trip cost time for the specialist, CS, and engineering, every time it happened.

A modal with its own problems

The modal it happened in had its own separate problems. It was a blocking popup — a specialist couldn't step away mid-task and come back to where they left off — and content-heavy interactions, editing the graph especially, ran into real technical constraints trying to fit inside it. A full-page split layout replaced it: room enough for that interaction itself, and room enough to add a real diagnostic step alongside it.

Where the first fix fell short

The first version of that diagnostic step verified against a low bar: if a single valid data point existed anywhere in the selected range, it passed. That caught the worst case — a genuinely empty range — but not the more common one: a range that was mostly gaps, verified successfully, and then generated a report with far less data than the specialist expected.

Showing the real coverage

The version that shipped replaced pass/fail with the actual data-point count per reading type, shown before configuration opens — so a specialist can see real coverage for themselves, and tell a legitimate gap from a configuration mistake, without escalating to find out.