OxiWear · 2026 · Senior UX / Product Designer
Rebuilding the clinical report portal
The web portal where care specialists follow home-based device users and pull the reports that go into a medical record. It had grown feature by feature — scattered navigation, a report flow that wasted their time. I restructured the architecture, rebuilt the report workflow around a verify-first check, and built the design system on the mobile app's validated safety work.
4 → 3
navigation tabs reshaped into task-based hubs
7 hazards
each traced to a concrete interface rule
In pilot
launched Sept 2026 · early signal is qualitative
The 30-second version
- Problem
- A clinical portal grown feature by feature — reports behind two doors, the people in the system under inconsistent names, a config form that could waste several minutes before failing — so every hospital was onboarded through a run of support calls.
- What I did
- Reorganised four navigation tabs — and a buried admin screen — into three task-shaped hubs with one vocabulary.
- Rebuilt the report flow around a fail-fast Verify-data check, and kept every report in a searchable history.
- Turned the mobile app's validated FDA / human-factors work into a web design system — seven use-related hazards, each mapped to a concrete interface rule.
- Result
- Launched September 2026, now in pilot with a small number of prospective hospitals. Too early for hard numbers — the early signal is qualitative: Sales and Customer Success report noticeably fewer onboarding calls.
01Context
OxiWear is an FDA-regulated ear-worn blood-oxygen monitor that lets someone leave the hospital and be watched at home. The web portal is where care specialists follow those device users and pull the reports — General, Sleep, 6-minute walk test — that go into a medical record. Not a crash-cart screen; a calm remote overview that has to stay exact.
Most of the design attention had gone to the mobile app the device user wears. The portal had grown feature by feature with no plan, and it was dragging on hospital onboarding.
Setup runs top-down: a Head care specialist is invited first, invites the other care specialists, who invite their device users.
Team & timeline
- Ya Zhang — Senior UX / Product Designer, lead
- Partnered with the Head of Product, clinical teams, Sales, Customer Success, and software engineers
July – September 2026 · 3 months. Scope was contained: the report module was rebuilt in full, but the restructure only moved where features live — every screen outside the report flow kept its existing UI. And the design system was the mobile app's already-validated human-factors work translated into web components, not built from zero.
My responsibilities
- Restructured the portal's information architecture and standardised its vocabulary.
- Redesigned the report module end to end, around a Verify-data pre-check.
- Built the web design system by adapting the mobile app's validated FDA and human-factors work.
02The problem
Where it broke down
Care specialists come here for two things: watch the people they monitor, and pull the reports that go into a medical record.
Navigation had drifted. The same task sat behind two doors, the same people had two or three names, and the action used most — inviting a device user — was an unlabelled icon. Finding a feature meant calling support.
Reports were worse. Configure one for several minutes, get told there's no data in that range. Download it, and it's gone — nothing kept, nothing to return to.
Every new hospital got walked through all of it, one call at a time.
03Research & constraints
B‑B‑C meant no direct line to the people being monitored, so research ran through the teams who talk to hospitals daily — stakeholder interviews with Sales, clinical, and Customer Success, plus a support-ticket analysis. The restructure was already the brief; what the research pinned down was the one structural cause under everything: features added one at a time, never grouped, so the same task lived in several places under several names. Three findings:
01Inconsistent terminology
The list of people being monitored was a tab called “Devices” — the hardware's name, not the person's. And “Admin” meant two different things at once: a tab that grouped those people, and a separate screen, in the top-right profile menu, for staff roles. Roster work kept ending in a support call.
02Two front doors for reports
General Report came first and went on the dashboard — a one-time download, no history. Sleep and 6MWT came later, needed saving, and got a Reports tab, with 6MWT shortcut back to the dashboard. So General had no home, 6MWT had two, and staff kept asking why.
03Unlabelled icons
Inviting someone — a device user, or another staff member — lived on the dashboard as icon-only buttons. Staff didn't find them there; they went hunting in Devices and Admin.
Safety is a bar, not a nicety
Every decision had a second test on top of “is it usable?” — could this screen make a care specialist miss or misread a reading that matters?
Reuse the validation, don't repeat it
The companion mobile app had already passed formal human-factors testing. I translated its validated principles — type limits, touch targets, colour isolation — into web components instead of paying for the audit twice.
04Restructuring the architecture
Why start here: the structural problem was the root, so it had to be fixed first. Retitling buttons or tidying one screen wouldn't hold while the same task still lived in several places under several names. And for a product adopted hospital by hospital, a predictable structure is the cheapest way to cut onboarding cost. Two things had to be fixed: where features live, and what the people in the system are called.
Part 1 · Information architecture
From four tabs to three hubs
The portal had four main tabs, plus a profile menu in the top-right where admin management sat buried among account settings.
I reorganised those four tabs into three hubs, each shaped around a task the staff already think in — monitor someone, produce a report, set up the roster — and pulled admin management out of the profile menu into Setup, where roster management belongs. The profile menu stays for what it's actually for: account settings.
This was a change of where features live, not a restyle — screens outside the report flow kept their existing UI.
Before — 4 tabs, plus admin management buried in the profile menu
- OxiWear portal
- Main navigation4 tabs
- Dashboardmonitoring, plus report and invite actions bolted on
- General report — downloadbuttonone-time download, no history — the one report with no home
- 6MWT reportbuttonduplicated — also lives in the Reports tab
- Invite device user · Invite care specialisticonsduplicated in Devices / Admin, and unlabelled here
- Reports6MWT and Sleep reports — but not General
- Devicesmisnamed — this is the list of device users
- Admingroups device users — but a second “Admin” lives in the profile menu
- Profile menu › Admin managementtop-rightthe second “Admin” — buried among account settings, manages staff roles
duplicated, buried, or mis-namedReport and invite actions bolted onto the Dashboard as unlabelled icons · the list of device users called “Devices” · two different things both called “Admin,” one of them hidden in the profile menu.
Part 2 · Vocabulary
Naming the roles
Standardising the vocabulary meant naming the people in the system — and every obvious candidate broke on some constraint.
The people wearing the device became Device user, not “Patient.” The portal isn't only used by hospitals; research centres run it too, and the people they monitor aren't patients. Those device users are grouped into Teams, by hospital and medical group.
Naming the staff who read that data was harder, because by then three of the obvious words were already spoken for:
Three obvious words — every one already taken
- “Clinician” / “Doctor” — excludes research staff, who aren’t physicians.
- “User” — already spent on Device user; reusing it would recreate the exact ambiguity I was removing.
- “Team” — already spent too. A Team is a group of device users, so “Team specialist” would make one word mean two things in the same system.
The working option on the table was Team specialist. I proposed Care specialist instead — it keeps the direction the team was already heading, drops the collision with Teams, and “care” tells a new reader which side of the system this person is on. It doesn't assume a medical title, so it holds up in a hospital and in a research centre.
Device user and Teams are settled; the staff-facing term is still with the team at the time of writing.
05The Report Hub
Why the deepest work went here: reports are what care specialists actually come to the portal for — the live dashboard is a glance, the report is the artefact that ends up in a medical record. And the report flow was the most broken part of the product: two different entrances for what should be one task, no history once a file was downloaded, and a configuration form that could run for several minutes before failing on an empty date range.
Four moves fixed it. Each one answers a specific use-related hazard, written up as a rule in the design system (section 06).
Preventative UX
A fail-fast data check, before any configuration
The old flow let a care specialist configure a whole report against a time range that turned out to be empty. I moved a “Step 1: Verify data” gate to the front: choose the timeframe and time zone, and the portal checks telemetry coverage before the form opens. An empty range surfaces in seconds, not after the work is done.
- 1
Verify data
Pick a timeframe and time zone. The portal checks telemetry coverage before anything else.
- 2
Two outcomes
Data available → continue to configuration. No data in range → fix the timeframe now, before any setup.
- 3
Configure
The full form opens only once there’s something to report on.
Impact
A mis-scoped date range used to surface only after a full configuration — several minutes of work thrown away, under time pressure. The Verify gate catches it before the form opens, and it's one of the dead ends Sales and Customer Success point to when they describe fewer onboarding calls in the pilots. Hard numbers are still coming (section 08).
Traces to the guidelines — absolute time
Absolute time is a hard rule in the guidelines: on a night-shift or cross-site handover, a relative timestamp (“2 hours ago”) is a use-related hazard. So the timeframe field is pinned to a zone (EST (UTC−5)), the verify result echoes the full range back with the zone attached, and every timestamp in the report itself is absolute (14:32:05 EST).
Cognitive load
From a fragile modal to a dedicated workspace
Before
- A form too big for its container — a dense configuration form squeezed into a small modal, scrolling inside a page that also scrolled.
- One misclick and it's gone — clicking anywhere outside the modal dismissed it, taking every entered value with it.
- Required fields easy to miss — no sectioning in a long popup, so care specialists scrolled past things they had to fill in.
After
- A full-page split layout — the form on the left, the Verify data check alongside it on the right. Both get the room they need.
- Three collapsible sections — required fields stay visible; the rest opens only when it's needed.
- An unsaved-changes guard — if a care specialist navigates away or closes the tab mid-form, the portal stops and asks first.
The hazard it removes
On a regulated product, “the user lost their work” isn't a usability complaint — it's a use-related hazard. A care specialist configuring a report can be pulled away by something urgent at any moment, and if the configuration disappears with one misclick, the likely outcome isn't that they carefully redo it. It's that the report gets delayed, or rebuilt in a hurry with a mis-scoped range. The unsaved-changes guard is written into the guidelines as the control for that.
Workflow
One hub, one flow, batch actions
The download buttons came off the dashboard. General, Sleep, and 6MWT reports now live in the Reports hub and are created the same way, and every report a care specialist generates is kept in the system — so a past report can always be found again instead of vanishing into a downloads folder. Multi-select adds bulk download and bulk delete for routine roster work.
Destructive actions are deliberately hard
Deleting a report — one or many — doesn't use a plain “Confirm.” It's a multi-step, blocking dialog that asks the care specialist to match a value before it will proceed. On irreversible medical data, a mis-click can't be the thing that loses a record.
Traces to the guidelines
Two guideline rules meet here. Every generated report is retained as the system of record — a downloaded-and-gone file can't be re-pulled for a handover or an audit. And destructive actions use a multi-step blocking dialog with value matching, never a bare “Confirm,” so an irreversible medical record can't be lost to a mis-tap.
Flexibility
Line graphs the care specialist composes
Rather than a fixed chart, a care specialist chooses which vitals to plot together — SpO₂ against pulse rate, for instance — and adds or removes series to make the comparison they need. The rendering rules (below) keep every combination safe to read and safe to print.
Traces to the guidelines — charts
The guidelines' charts rule does the safety work: two series are told apart by line pattern and node shape — not colour — and the legend never hides, so a two-vital graph stays readable on a black-and-white printout. The two-vitals-per-chart limit is the same rule — a denser chart stops being safely legible.
06The design system
Why a system, not just screens: the same low-level questions — how to show a number that updates, a timestamp, a two-line chart so it can't mislead a care specialist — kept coming back on a regulated product. I answered them once, in a written spec the whole web product now builds against: the FDA-Regulated Design System & Clinical UX Guidelines. It's the mobile app's already-validated human-factors work translated into web components.
What makes it defensible on a regulated product: every rule names the hazard it prevents, so any component traces back to a specific risk. Seven use-related hazards, mapped:
Use-related hazard, before
Design control in the system
A care specialist configures a report for several minutes, then hits “no data in this range” — wasted effort under time pressure.
A fail-fast Verify Data step checks telemetry coverage before the configuration form will open.
A report is downloaded and then leaves no trace — nothing is kept in the system, so it can’t be re-pulled for a handover or an audit.
Every generated report is retained in the Report Hub as the system of record.
Decorative red and amber across the interface dull care specialists to a genuine abnormal-vital alert (alarm fatigue).
Red and amber are reserved exclusively for abnormal vitals — never on a control, tag, or decoration.
Line colours disappear on a black-and-white printout or a monochrome display — two vitals collapse into one.
Chart series are separated by pattern and node shape, not colour, and the legend is always on screen.
A relative timestamp is misread across a night-shift or cross-site handover.
Absolute time everywhere — 14:32:05 EST — with the time zone stated, never a relative phrase.
An emergency pulls a care specialist away mid-form and the unsaved configuration is lost.
An unsaved-changes guard on the report form holds the work until they return.
A medical report deleted by a mis-tap cannot be recovered.
Destructive actions require a multi-step blocking dialog with value matching before they proceed.
And the standing rules that came out of it — the spec the whole web product is built against:
Numbers
Tabular figures on every live value; slashed zero on device IDs
Prevents: a shifting column, or an O / 0 mix-up, causing a misread
Time
Absolute 24-hour time with a zone (14:32:05 EST) — never “5 min ago”
Prevents: a relative timestamp misread on a cross-shift handover
Colour
Red and amber only on abnormal vitals; teal is the one interactive colour
Prevents: alarm fatigue — a real warning lost among decorative colour
Charts
Series told apart by pattern + node shape, not colour; legend always visible
Prevents: two vitals collapsing into one on a black-and-white printout
Destructive actions
Multi-step dialog with value matching, not a plain “Confirm”
Prevents: an irreversible medical record deleted by a mis-tap
Alerts & offline
Three-tier alert priority; a persistent offline indicator with sync status
Prevents: a low notice reading as urgent, or stale data read as live
Icon buttons
0 ms action-verb tooltip, 44 × 44 px hit area, matching ARIA label
Prevents: a mystery-meat icon, or a hurried tap hitting the wrong action
From the Figma library
The rules ship as real styles and tokens. The type scale forces tabular figures on every vital and a slashed zero on device IDs; the colour system keeps red and amber off the interface chrome and reserves them for clinical state.
Charts, built for monochrome
Reports get printed in black and white. Pattern and node shape — not colour — keep two series apart, and the legend never hides.
Desaturate it and it stays completely readable — that's the test.
07Validation
Two checks before build, one running now. B‑B‑C meant I couldn't put the portal in front of care specialists directly, so validation leaned on structured review and on the people who work with hospitals every day.
Hazard-matrix walkthrough
Before build, I walked each of the seven use-related hazards against the redesigned flow — does Verify actually stop an empty-range report, does the delete dialog actually stop a mis-tap — and reworked the flow where a control didn't hold.
Moderated task sessions
Task sessions with the Clinical, Customer Success, and Sales staff who stand in for care specialists, running the tasks that broke on the old portal: invite a device user, generate a report for a date range, re-find last week's report, delete one. This is where the smaller fixes surfaced — wording on the Verify result, the order of the collapsible sections.
Pilot feedback loop
Still monitoring. As hospitals come onto the pilot, Sales and Customer Success track onboarding calls and support tickets against the old portal's baseline — the source of the early signal, and of the numbers still to come.
08Impact & reflection
Launched September 2026. It's in pilot with a small number of prospective hospitals — no closed deals yet, so there are no hard numbers, and I'd rather say that plainly than dress an adjective up as a metric.
What is real so far is qualitative, from the teams in the room with those hospitals: Sales and Customer Success report noticeably fewer onboarding calls — clients are finding features and generating reports without the step-by-step walkthrough the old portal always needed. The numbers it should move, once there's enough usage to measure:
↓
Onboarding calls per new hospital
↓
“How do I find…” support tickets
→ 0
Wasted report runs (caught by Verify)
The through-line
A remote monitoring product isn't finished when the dashboard looks good. It's finished when a clean structure, a fail-fast check, and a restrained use of colour let a hospital adopt it without a week of training — and let a care specialist trust the report they hand back.