OxiWear · 2025 · Senior UX Designer
OxiWear Health Monitor Redesign
On an FDA-regulated pulse oximeter, dropped Bluetooth connections were hiding live blood-oxygen readings — driving returns and support calls. I led the redesign that treated connection feedback as a safety-critical system, not a surface fix.
42% ↓
Device abandonment
50% ↓
Reconnection-related support tickets
Frustration → trust
How users described the shift
01Overview
OxiWear is an FDA-regulated ear-wearable pulse oximeter that lets users monitor live blood-oxygen data and share clinical reports with their doctors. As a medical device, every design decision had to balance usability with patient safety.
This project tackled connection failures that were driving device abandonment, support escalations, and user frustration. On a medical device, a dropped connection that hides oxygen data isn't a UX inconvenience — it's a safety risk with real business cost. I led the redesign, treating connection feedback as a safety-critical system rather than a surface-level fix.
Team & timeline
- Ya Zhang — Senior UX Designer, lead
- YJ Liu — UX Designer
- Software, hardware & firmware engineers
- Product & clinical partners
Jan 2025 – Mar 2025
My responsibilities
- Led user research that reframed a “connectivity bug” into a UX and safety problem.
- Designed the non-blocking notification system that keeps health data visible during connection loss.
- Drove cross-functional alignment to ship auto-reconnection, overcoming engineering pushback.
02The challenge
Critical problem
Users opened the app to log notes, review past data, and share clinical reports with their doctors. But whenever the wearable naturally disconnected — as it did throughout the day — the app locked them out entirely, blocking even the features that didn't need a live connection. Getting back in meant a frustrating manual reconnect.
The result: users abandoned the device, and many couldn't use it without contacting support.
High
Device abandonment
Heavy
Support burden
Frustrated
Users
03Discovery
Process
When returns spiked, marketing's survey showed high dissatisfaction — but only surface complaints: “connection issues,” “inaccurate data.” Stakeholders wanted immediate design changes off that.
I pushed back — surface symptoms aren't root causes — and ran contextual research to see how the device actually failed in daily use: 7 user interviews with real users, 3 in-home field observations, and a review of the 30+ survey responses marketing had collected.
Survey review · 30+ responses→User interviews · 7 users→Field observations · 3 homes→Journey mapping
Key insight
Root cause
A human-factors mismatch
The system assumed users keep their phone nearby for continuous monitoring. In reality they left it 10–30 ft away during daily activities — so the connection kept breaking.
Three critical use errors
The same mismatch showed up as three use-related hazards:
Hazard 1: Blocked access to health data
Users kept their phone at a distance, so the device disconnected several times a day. Each drop threw a full-screen popup that froze the app and hid live readings.
Every time I check my phone after exercise, I can't see my O₂ levels — just another connection error.
Hazard 2: High recovery friction & task fatigue
Reconnecting meant a 7-step manual process buried in Settings — 5–10 minutes every time.
I spend more time fixing connections than checking my health.
Hazard 3: System ambiguity & data-integrity risk
With no clear indicators, users couldn't tell a normal disconnection from a real problem — or whether cached data was still trustworthy.
Is this my current oxygen level, or from this morning?
04Design process & decisions
Every decision below is also a risk-control decision. On a regulated medical device, the question isn't just “is this usable?” — it's “could this interface cause a user to miss or misread critical health information?” I designed against that.
Solving blocked access
Risk-control constraint
The bottom of the screen is reserved for the life-critical SpO₂ alert. Connection status is lower priority — it has to live somewhere it never covers a reading.
The decision
A header banner (＋ a snackbar for quick actions)
Status sits in a fixed slot above the content — visible when the user needs it, dismissible when they don't, and it never covers SpO₂, pulse, or the graph.
Header banner
Sits above the content — no reading is ever covered.
Alert / popup
A modal in the middle hides the live readings.
Toast / bottom alert
That slot is reserved for the life-critical SpO₂ alert.
Solving recovery friction
Why the obvious fix failed
I started with a “Connect” button. In testing it backfired: even one tap made the device feel unreliable, and post-exercise — exactly when the reading matters — any step is too many.
The trade-off
Cost~6 weeks of engineering, plus hardware / software alignment.
GainZero friction at the moment users need their reading most.
The decision
Make reconnection invisible
- Reconnects automatically in the background, on proximity.
- No user action — the use error is designed out.
Solving system ambiguity
The problem
On disconnect, the live data and graph vanished with no explanation — users couldn't tell a routine drop from a device failure. “I thought my device was broken.”
A use-related hazard
Unclear status could lead users to distrust valid readings — or trust invalid ones.
The decision
Three layers of status, revealed only as needed
- Icon — connection state at a glance: connected / connecting.
- Text — a plain-language line: “Connecting…” / “Syncing data…”
- Progress bar — a thin line under the status that fills while data syncs, so the wait has an end.
05The solutions
Non-blocking design + a centralized hub
Solves Hazard 1 · Blocked accessThe change
Connection status moved out of a blocking modal and into a fixed slot in the header. It reports the state without taking over — during a disconnect the user keeps full use of the app: past readings, notes, and clinical reports.
A full-screen popup takes over the app. Nothing else is usable until the user reacts to the popup itself.
The same message as a header banner. It informs without blocking — the rest of the app stays usable while the device reconnects.
Auto-reconnection — the engineering perspective
Solves Hazard 2 · Recovery frictionThe problem
The friction peaked at the worst moment. A low-oxygen alert fires mid-workout — and to see the reading, the user first had to reconnect the device by hand: roughly 7 steps and 5–10 minutes, according to user interviews, while anxious and out of breath. A “Connect” button wouldn't fix that. I proposed moving reconnection into the background, which meant getting the hardware and software teams on board.
The blocker
“We've explored every option. The Bluetooth hardware has limitations, and the software can't override device disconnects. There's nothing we can do.”
— engineering team meeting
How I moved it forward
- 1
Reframed the standstill. “Nothing we can do” was really “is this worth it?” — a priority question, not a Bluetooth one. That was what I set out to answer.
- 2
Made the case in their terms. Brought the engineers into the field studies to see the reconnect struggle firsthand, then set it against support tickets, returns, and customers already lost.
- 3
Met them in their language. My CS background let me discuss technical approaches, not just requirements. Once we agreed the problem was real, the engineers found the path themselves — software located background-task opportunities, hardware extended advertising intervals.
6 stakeholder meetings across 1.5 weeks to a green light. We were solving the health access problem together.
The result
Seven anxious steps became none. The same moment — a low-oxygen alert during exercise — before and after:
Scroll sideways to follow the full journey →
Keeps the phone at a distance while working out
Device vibrates from an SpO₂ drop
Opens the app
Disconnection popup blocks all functionality
Has to manually reconnect the device to see data
Data-sync popup appears, blocking all functionality
Finally sees the live data and takes action
Exercises comfortably, trusting the device to monitor them.
Concerned, and needs to check their health status right away.
Expects to see their health information immediately.
Frustrated and blocked from accessing health information.
Struggles with technical steps while anxious about their health.
Breathing heavily, dizzy, fumbling with the phone
Hits more frustration with another blocking step.
Gets the information at last — but now distrusts the device.
“The worst part is when I feel it vibrate — I think something's wrong with my health, so I rush to check, but then I'm stuck for 10 minutes going through all these menus just to reconnect.”
— Robert (pseudonym), 60sNames are pseudonyms; quotes are from research interviews.
A visual status system
Solves Hazard 3 · System ambiguityThree layers of feedback, each adding detail only when the user needs it. The prototype runs through the real device states — connecting, syncing, synced.
- 1
Icon — The ring by the graph — battery and charge state when the device is connected, a searching state while it reconnects.
- 2
Text — The header line, in plain words — “Connecting…”, “Data Syncing…” — so a routine reconnect never reads as a fault.
- 3
Progress bar — Only while syncing: a thin bar across the top of the screen fills to 100%, so the wait has a visible end.
06The impact
42% ↓
Device abandonment
Users kept the device instead of giving up on it.
50% ↓
Reconnection-related support tickets
Half as many users needed support to reconnect their device.
In follow-up interviews, users described the change in one word: from frustration to trust.
What shipped
- Non-blocking notifications — connection status never hides a reading
- Automatic background reconnection — no user steps, triggered by proximity
- A three-layer visual status system — icon → text → progress, revealed as needed
In users' own words
Names are pseudonyms; quotes are from research interviews.
07Key takeaways
1. Regulatory constraints sharpen design, not limit it
Working on an FDA-regulated device changed how I evaluate design decisions. The question was never just "is this usable?" — it was "could this interface cause someone to miss or misread critical health information?" That framing forced a discipline I now carry into every project: every choice needs a defensible rationale, not just a preference. Deciding where a status alert lives wasn't an aesthetic call — it was a safety decision I had to justify. Regulation didn't slow the design down; it made every decision more intentional.
2. Involve stakeholders in user research — don't just present results
Field research revealed that users naturally kept phones at a distance, contradicting our assumptions — but data alone didn't convince the engineering teams. When engineers hear research findings secondhand, they struggle to grasp the importance and lack empathy for the user's pain. By inviting engineers into the interviews and field studies to witness the struggles firsthand, I got faster, stronger cross-functional alignment than any presentation could.
3. Hardware products demand cross-functional UX leadership
Unlike software products, health devices involve hardware constraints and multiple engineering disciplines. My UX role extended beyond interface design to facilitating alignment between software, hardware, and business teams. Using tangible user pain points to unite diverse technical teams around shared goals proved essential — solving the user problem became the path to solving the business problem.
4. Technical literacy amplifies design impact
My CS background proved essential on this hardware project. Understanding the technical constraints didn't limit creativity — it let me propose solutions that were both user-centered and technically feasible, bridging design and engineering.