How we made ARDS risk readable at a glance for ICU clinicians

01

Project overview

Solution: ICU Angel combined an ARDS medication with a digital monitoring platform.

Objective: Help clinical teams track patient vitals, ARDS progression, and medication response in real time.

We designed the digital part of ICU Angel to work alongside a new ARDS medication. Our work covered two needs:

Give doctors and nurses a clear view of disease progression and medication response.

Give principal investigators aggregated data for research and treatment-protocol reviews.

02

User research and insights

Interviews: We spoke with ICU physicians and nurses about the problems they faced while managing ARDS.

Expert reviews: Six clinicians and three principal investigators reviewed the designs with us in daily stand-ups and regular calls.

Observation: We watched how ICU teams worked, mapped the existing workflows, and noted where information or time got lost.

Surveys: More than 30 ICU staff answered questions about alarm fatigue, system usability, and medication compliance.

Wireframe testing: A pilot group tested the early flows against the clinical requirements and safety-critical tasks.

03

Workflow synthesis

We turned the clinical requirements into ARDS-monitoring workflows that the clinical and product teams could review together.

We separated the clinician-facing bedside view from the investigator view, so each team could focus on the decisions they had to make.

We made changes in disease stage, medication response, and patient status easier to scan, without losing the context around them.

We used prototype reviews to check if the information hierarchy helped people decide on the next clinical or research action.

04

Interaction and risk modelling

The interaction work focused on behaviour that could affect a clinical decision:

ARDS stage: Each stage, including at risk and severe, had its own visual treatment, so clinicians could recognise it faster.

Alert priority: Urgent alerts appeared first, so clinicians could tell them apart from lower-priority notifications.

Medication tracking: Administration times and doses had their own section.

05

Prototyping and the user feedback loop

We built interactive prototypes for admission, medication scheduling, and real-time vital-sign monitoring.

Structured testing: ICU staff and principal investigators worked through the prototypes in moderated sessions.

What we heard: Doctors wanted adjustable alert thresholds. Nurses asked for shorter data-entry forms. IT staff needed clear security controls for clinical data.

06

Context and problem statement

ARDS is a life-threatening condition, and intensive care teams have to make informed decisions about it quickly. The teams we studied didn’t have a single real-time view that connected patient monitoring with the ARDS medication workflow.

07

Key challenges

Fragmented monitoring: Clinicians didn’t have a single view of vital signs, disease stage, and medication response.

Data spread across systems: Nurses and doctors had to check several systems to understand a change in patient status.

Research data: Principal investigators had to combine separate sources before they could analyse treatment outcomes across patient groups.

08

Stakeholder analysis: who we designed for

Doctors

Need: A reliable view of ARDS progression that supports treatment decisions.

Problem: Important changes could get buried in a large volume of patient data.

Nurses

Need: An interface that fits daily ICU work without adding unnecessary steps.

Problem: Alarm fatigue and slow data entry took time away from patient care.

Principal Investigators

Need: A shared dataset for comparing medication response across ARDS stages and patient groups.

Problem: Separate data sources made larger clinical analyses slower and more prone to error.

09

Impact metrics and outcomes

The evaluation looked at these outcomes:

Faster review of critical changes

Validation focus: Could clinicians recognise a critical change and decide what to review next without searching across separate views?

Finding: Before the redesign, the screen used red, green, and yellow everywhere, so nothing stood out, and it took clinicians about 30 seconds to spot a critical change. With a clear visual hierarchy, it took them less than 5 seconds.

Less switching between systems

Workflow focus: Bring disease progression, vital signs, medication response and alerts into one clinical view.

Finding: Clinicians used to switch between six or seven monitoring views. With the combined dashboard, everything was on one view, and they could go deeper into the detail when they needed to.

Patient-outcome boundary

This portfolio documents the research and interface work. It does not claim that the design caused a measured change in patient outcomes.

We designed it to make warning signs and supporting data visible sooner, so clinicians could decide what to investigate next.

Pilot: Once the design was complete and the MVP was built, the platform went into a pilot.