About The Project
Project Overview
Role: Senior Product Designer/Usability Engineer at Philips (10+ years of UX experience)
Translated clinical/engineering requirements into end-to-end user workflows that can be reviewed by Risk + Clinical + Engineering.
Defined RFP-specific scenario deltas (what’s truly new vs. what is inherited from SpO₂).
Product: Philips bedside patient monitoring (IntelliVue/Delta platform capabilities)
Focus areas:
SpO₂ monitoring workflows (sensor application, source/label selection, alarm settings)
Continuous Temperature (ContTemp) workflows (smart cable + probes, dual temperature difference)
RFP (Respiration From Pleth) as a derived parameter from the SpO₂ pleth signal (adult/pediatric only)
Patient Monitoring as a feature of the overall Delta Platform
Objective: Ensure new/updated capabilities are safe, understandable, and testable by designing clear user workflows (use scenarios) and identifying safety-related user tasks for risk evaluation (uFMEA) and study planning.
I ran structured stakeholder discovery to pin down what is factual vs. assumption:
Liased with clinical, risk, engineering and capability owners to confirm and validate aged vales concept, alarming approach: inherit standard Delta limits, and RFP can be enabled/disabled, but alarm limits are not separable per RR source (limits apply to the RR parameter broadly). Also flagged the 70 rpm ceiling for RFP vs. higher ceilings for other RR sources (a real safety/logic edge case).
User Research & Insights
I started by separating assumptions from facts. Early notes from stakeholders were directionally right but inconsistent in wording (e.g., “error %” vs “rpm accuracy,” and “age values” vs “H values”). I converged the language into what would survive formal review: aged values, accuracy expressed in rpm, and platform-alarm inheritance aligned with standard Delta behavior.
Next, I mapped what we must not duplicate. SpO₂ already covers the physical workflow select sensor, apply sensor, connect cable, confirm numerics so creating a full second set for RFP would be noise and would dilute the safety review. Instead, I scoped RFP to the minimum set of distinct, safety-relevant UI behaviors that are not already covered.
While drafting these scenarios, I flagged the exact UI uncertainties that would break scenario validity and later UFMEA quality:
What exactly happens on Neonate selection (dialog, disabled state, auto switch-off, feedback)?
Where exactly is RFP toggled on/off (parameter menu, sidebar toggle, context menu), and how is default-on represented for Adult/Ped?
How does the UI make it unmistakable which respiration source is currently active (ECG vs pleth-derived), especially when both are available?
To resolve the design dependency, I prepared targeted stakeholder questions (UI architect / SMEs) that focus strictly on observable behavior, not implementation details, so the scenarios stay defensible in review.
Conceptualization
Drawing from user research, we envisioned ICU Angel as a unified interface that:
Tracks ARDS progression using algorithmic graphs.
Alerts healthcare professionals in real time to any critical changes.
Integrates seamlessly with existing hospital systems to populate patient data automatically.
Wireframing
We created low-fidelity sketches outlining:
Stage-Based Visualizations: Each ARDS stage (at-risk, severe, etc.) is color-coded for rapid recognition.
Alert Management: A hierarchical system displaying urgent alerts at the forefront, minimizing alarm fatigue.
Medication Tracking: A dedicated section for viewing drug administration times and dosages.
Prototyping & User Feedback Loop
Next, I developed interactive prototypes to simulate the core workflows, from admission and medication scheduling to real-time vitals monitoring.
Hands-On Testing: ICU staff and principal investigators tested these prototypes in structured sessions.
Key Feedback: Doctors desired customizable alert thresholds, nurses requested simpler data entry forms, and IT staff advocated for robust data security frameworks.
Context & Problem Statement
Philips was introducing or refining capabilities that are clinically meaningful but easy to misuse under ICU conditions:
Users operate under interruptions, alarm fatigue, cognitive load, and time pressure.
New parameters (like RFP) may be technically “part of SpO₂,” but still introduce new UI behaviors and new failure modes (e.g., latency to first value, neonate restrictions, shared alarm limit behavior).
For ContTemp smart cable workflows, risks include wrong accessory selection, incorrect setup, and infection-control failures during disconnect/disposal.
The gap wasn’t “missing screens.” The gap was missing operational clarity:
What does the user do, see, decide, and verify and where can that go wrong?
Design decisions I enforced
Inheritance boundary: physical setup stays under SpO₂ scenarios; RFP scenarios begin only once the sensor chain is already connected.
Expectation management: RFP is allowed to appear later; the scenario explicitly treats delayed availability as normal, not as an error.
Aged values language: used the term “aged values” formally (values with known age, still displayed).
Alarm alignment: default alarming behavior is inherited from standard Delta alarming, including limits; RFP does not introduce a separate “alarm system.”
Neonate restriction is a safety boundary: the lockout must be explicit in the UI, not a hidden rule.
Outcomes
This work turned an “algorithm add-on” into a reviewable interaction design with a defined safety perimeter. Instead of debating RFP and delta device add on abstractly, stakeholders could now validate:
what the clinician sees, when they see it, and what the system expects them to do
how Neonate restriction is enforced in a way that is testable
how RFP fits into existing alarm and respiration-source behavior without creating contradictory UI states
More than 14 scenarios designed for where using add-on devices to and fro to bedside monitor eliminating risks of data loss, patient risk and management problems.
