Service and behavioural design · Service design lead
Alarm fatigue starts before the alarm does.
Alarmease is a service concept for the emergency department of OLVG-Oost in Amsterdam. In comparable departments, 85 to 99 percent of monitor alarms need no action, and many begin with a monitor left on its default limits. I moved the intervention from the alarm to that setting: a click beside the monitor once the limits fit the patient, a team-level view at the nurse station, and cards for the launch week. In our test at OLVG-Oost, with one emergency nurse, the visible status started a conversation between a nurse and a doctor about a patient’s limits. The same test sent the next version into the monitor itself.
- My role
- Service design lead
- Team & I owned
- Andyka Jonathan, Barbora Halanová, Negin Bokaei and Duco Boomsma.I owned the problem framing, the research synthesis, the service blueprint and the ethical direction, co-built the side reminder and designed the challenge cards. Not mine: the design of the nurse-station visual, which was the team’s.
- Challenge
- Brief from the emergency department of OLVG-Oost, for the Master Digital Design healthcare playground
- Lower the load bedside alarms put on emergency staff, while every alarm is still taken seriously
- Work with the monitors the hospital already uses
- Deliverable
- A tested service concept, not a deployed medical product
- The problem moved from the alarm to the moment a monitor profile is set
- Three parts for one behaviour: a side reminder at the monitor, a team-level view at the nurse station, and cards for the launch week
- Tested at OLVG-Oost on 7 May 2026 with one emergency nurse: the visible status started a conversation between a nurse and a doctor, and the next version moved into the monitor itself
- Date
- March to May 2026 · nine weeks
01 · The problem
Most monitor alarms ask for nothing. Nurses learn to stop hearing them.
In comparable emergency and intensive care settings, 85 to 99 percent of monitor alarms need no clinical action (Drew et al., 2014; Huo et al., 2023). Each one still asks a nurse to look, weigh and decide, so the alarm that matters competes with all the ones that do not. The brief asked us to lower that load without letting a single alarm be ignored.
Most alarms ask for nothing
Loose sensors, a patient who moves, and above all limits never set for this patient. A low athletic heart rate trips the same threshold as a patient in trouble.
Experience makes it worse
Desensitisation grows with exposure (Fang et al., 2026). “The longer you work, the less responsive you are to alarm,” a nurse told us during our observation.
Nobody owns the response
“There is no strict coordination. It’s mostly a spontaneous act when an alarm beeps.” Whoever is nearest responds, and the limits are rarely checked again.
The limits start generic
Staff were not sure how to set the thresholds for each patient, so monitors often keep their default profile. The setting that would prevent the alarm sits on the screen that sounds it.
An alarm that is almost always wrong teaches people to stop listening.
The bedside scene, the photographs and the monitor clips above are generated imagery, used as atmosphere; only the side reminder in the bedside scene is taken from the prototype. Generated images on this page are always labelled as generated; the research and prototype material is shown as it was made.
02 · Evidence
The blueprint I built showed that nobody owned the monitor profile when it was set.
I set the research up as four kinds of evidence: what we saw on the floor, what staff told us, what the literature showed, and where it all landed on the patient journey. A design decision only stood if at least two of them pointed the same way.
The observation space
On 20 March we spent an afternoon observing the emergency department of OLVG-Oost. We mapped the space by what reached the people working in it: where they walked, where they talked, where the alarms sounded, and how intense each place felt.
The heaviest routes ran past the beds and round the station, where alarms and calls pile up. The quiet places were the desks, where the central monitor can mute an alarm or set a threshold. The setting that prevents alarms sat in the calmest part of the room; the alarms landed in the busiest.
- Low stimuli
- Medium stimuli
- High stimuli
- Staff walking
Redrawn from the team’s floor-plan mapping, 20 March 2026. The walking routes follow the areas the map marks as staff walking; the colours build up as you scroll and end on the map as we drew it.
Co-creation at OLVG-Oost, 2 April 2026. I walk the group through our first directions; staff then work through the phases of their shift on sheets we made for each one, with cards and sticky notes for their own ideas.
Four kinds of evidence, and the decision each one moved
01
Intervene where the profile is set, not where the alarm fires
- Observation · OLVG-Oost, 20 March 2026
- Monitors often kept their default profile, and it was rarely checked again when a patient moved on.
- Reading
- The false alarms were being produced upstream, in the monitor's settings, long before one sounded.
02
Time the prompt to admission
- Co-creation · OLVG-Oost, 2 April 2026
- A nurse told us that admission has the most room in the workflow.
- Reading
- The alarm is the worst moment to ask for one more action. Admission is the best one.
03
Add a prompt beside the monitor, not another alert
- Literature · Fogg, 2009
- A prompt only works when motivation and ability are high enough at the moment it arrives.
- Reading
- Nurses wanted fewer alarms, and the monitor already allowed the change. What was missing was a prompt at the right moment.
04
Make the status visible to nurse and doctor alike
- Service blueprint · my own
- In the acute phase no one consistently owned the choice of profile. Nurses and doctors could each assume the other did.
- Reading
- The gap sat between two roles, so a reminder aimed at one of them would not close it.
The service blueprint
I built the service blueprint across the emergency patient journey, from arrival and triage to monitoring, transfer and the team's learning loop. The most useful thing it showed was not a missing interface.
In the acute phase, when the patient is connected to the monitor, no one consistently owned the choice of profile. Nurses could assume the doctor would decide; doctors could assume the monitor setup was nursing's. The setting fell between two roles, and a generic profile carried forward into every alarm that followed.
That turned a reminder problem into a coordination problem, and the blueprint became the document the team checked every idea against.
| Phase 01Arrival & handover | Phase 02Triage | Phase 03Trauma 1 acute phase | Phase 04Monitoring & treatment | Phase 05Decision / transition | Phase 06Team learning loop | |
|---|---|---|---|---|---|---|
| 01Patient journeyWhat the patient experiences | PatientArrives via ambulance handover or walk-in | PatientUrgency assigned, patient is routed | PatientConnected to Philips IntelliVue; care starts | PatientTreated while vitals and alarms stay active | PatientMoves to Trauma 2, ward, OR or discharge | PatientNo direct patient action |
| 02Nurse experienceEmotional and cognitive load | FeelingAlert, information-loaded, scanning for risk | FeelingFocused, prioritising, time-pressed | FeelingAttention split between patient and protocol | FeelingCognitive load high, alarms felt as background noise | FeelingHand-off uncertainty, ownership unclear | FeelingReflective, motivated to improve |
| 03Nurse actionsWhat the nurse does | ActionTriage nurse receives intake and key facts | ActionTriage nurse sets urgency, routes patient | ActionConnects monitor while physician begins assessment | ActionWatches vitals, reacts to alarms, supports physician | ActionTeam decides next step; profile ownership unclear | ActionNurses reflect on results, discuss better habits |
| 04Frontstage touchpointsVisible to the nurse | TouchpointShort handover with high information load | TouchpointQueue, urgency cues, first clinical actions dominate | Core frictionTouchpointMonitor often starts on default or generic profileNo clear owner for profile selection. | TouchpointAlarms continue but profile status easy to miss | TouchpointProfile rarely checked again during transfer | TouchpointReal-time poster in breakroom shows trend |
| 05Backstage & technologyInvisible to the user | SystemSBAR and intake data enter the care flow | SystemTriage system and room routing shape next steps | SystemPhilips profile can stay generic or be personalised | SystemAlarm thresholds and load depend on chosen profile | SystemProfile may carry over or reset on patient move | SystemAlarm and profile data logged for team feedback |
| 06Alarmease supportWhere the design intervenes | TouchpointChallenge cards used in briefing and onboarding | Prompt“Who owns the profile check?” handover prompt | StickerMonitor sticker: check patient profile now | Side reminderStatus indicator: generic or personalised, with parameter context | ProtocolTrigger: recheck profile at every handover or move | VisualBreakroom poster links behaviour to fewer false alarms |
The research did not tell us what to build. It told us where the alarms were being made.
03 · The decision
I moved the intervention from the alarm to the admission.
The obvious answers all acted after an alarm had fired: filter it, route it, send it to another device. I asked what created so many alarms in the first place, and the evidence kept pointing at the same moment, a monitor profile left generic when the patient was connected. That is where the project turned.
The brief
How might we reduce the cognitive load of people working in A&E in relation to bedside alarms, while making sure every alarm is taken seriously and responded to?
The reframe
How might we help the care team set patient-specific monitor limits at admission, without adding another task or alert?
A model built for care, not for hooks
I also considered Eyal’s Hook model and Clear’s Atomic Habits. Hook is built for addictive products, the wrong aim in a care setting, and Atomic Habits centres one person where this needed a team. Fogg’s model gave the same mechanism without the manipulation.
Three principles the evidence earned
Cut alarms at the source, with no new alert channel. Sit at the point of action, beside the monitor. Protect clinical judgement: make the action easier, never automatic.
Going wide first
We started wide. We sketched on our own and together, ran Crazy 8s, the sprint exercise of eight quick sketches in eight minutes, and clustered the cards into six themes: sound, physical objects, the room, lighting, the screen and the workflow.
Most cards answered the alarm once it had sounded: a louder light, a smarter sound, a device that buzzes. The workflow cards were the first to reach back to what happens before one.
Sketch pages from the first weeks: a smart badge that vibrates on urgent calls, patients colour-coded by blanket, AI that filters alarms, voice notes for reports and a light above the most urgent bed.
The filter
Every direction had to answer two questions. Does it add a task to a nurse's shift, or does it ride on work already done? And does it speak about one bed, or the whole team? The directions that survived all ride on work already done.
For the whole team
At one bed
- A dashboard or a leaderboard
A screen to read, and a ranking that turns a team signal into a verdict on a person. It came back after the test on 7 May, because emergency staff can be competitive, and we refused it again: one shift cannot settle team dynamics.
- The central visual
- Challenge cards
One answer at a glance at the nurse station, about the team rather than a person; and paper cards for the launch week, which leave no digital trail.
- An app, push alerts or a smartwatch
Another device to wear, charge and answer, and a second place to enter what was already set on the monitor.
- The side reminder
A physical object beside the monitor. One click confirms what was already done on the screen.
Adds a task
Rides on work already done
Adapted from the medium matrix in my process portfolio. There the horizontal axis read screen against no screen; the central visual runs on a screen, so here it reads by what each direction asks of a nurse.
What else we ruled out
Four ideas from the wall and the sketch pages, rendered for this page: a camera that watches the bed, light columns in the corridor, a smartwatch that buzzes, blankets in an urgency colour. Generated imagery; none of them was built.
AI that filters alarms, or watches the bed
It acts after the alarm has already been made, and hides clinical reasoning inside a system nobody on the floor can inspect.
Light columns and colour cues in the room
OLVG had developed and tested light signalling before, and it had not touched alarm fatigue. It adds one more signal to read.
A new alarm sound
Philips has already redesigned the sound under healthcare regulation, and a better sound is still a sound after the fact.
Patient-context video
OLVG said its protocols would allow it. We set it aside anyway: permitted is not the same as proportionate.
A one-tap digital confirmation
We prototyped it and dropped it. It added a step without making the behaviour any clearer.
A status inside the monitor itself
The most credible place for it, and the hardest to reach inside the Philips ecosystem in nine weeks. We tested the behaviour first; chapter 05 comes back to it.
The concept is defined as much by what we refused as by what we built.
04 · The intervention
Three interventions, small on purpose: a click, a view and a card.
Setting a profile is a behaviour, not a feature. Nurses wanted fewer alarms and the monitor already allowed the change, so motivation and ability were there. What was missing was a prompt at the right moment, a confirmation that it was done, and feedback that it made a difference. Alarmease is one loop across three small media: a side reminder at the monitor, a visual at the nurse station, and cards for the launch week.
01 · The side reminder
It sits beside the monitor, where the action happens, and asks for no login, account or screen. Try it: this patient's resting heart rate sets off the default profile.
Default profile. A resting heart rate of 44 is under the default limit of 50, so the monitor alarms although this patient is fine.
Drawn for this page: version 2 of the side reminder beside a generic patient monitor, not a Philips interface. The values are illustrative.
Version 1: visible, and too weak
Laser-cut wood with a panel that slid, then flipped, from red to green. In co-creation the gesture proved too slight to feel finished, and the colour wore through where the slide ran. The problem was not visibility; it was feedback.
Version 2: a click that means done
It borrows the click of a toaster. One press drops a spring-loaded plate from Standard to Personalised, and larger colour blocks read from across the bay. I built both versions with the team on the laser cutter, and pushed for the mechanical click over an earlier magnet.
Version 1: the frame on a monitor in the lab, its parts, and me setting up the next cut.
Version 2: Standard, then Personalised after the click; and both versions side by side on the monitor.
02 · The visual: the signal, not the smile
A glanceable view at the nurse station, for the team. Its first version was a face that brightened or saddened with the alarm count: readable, engaging, and wrong. The decisive change was conceptual, not aesthetic.
The team’s three iterations rebuilt in code, so the change plays. The numbers are illustrative, as they were in the prototypes.
Feedback, 16 April
At the Feedback Feast the risk came up: a nurse coming off a hard shift could still be met by a disappointed face.
Reading
A face turns the conditions of a shift into a verdict, and a number without context cannot tell a hard shift from a careless one (Powell 2012; Drucker 2014).
Decision
Report the team's status per bed, not a mood. The unit moved from how this shift performed to how the team is doing.
The three iterations as the team exported them: dropped, refined, final. The team designed the visual; my part was the behavioural framing, and catching the risk of the face before we committed to it. We nearly kept it, because three nurses had called it fun.
03 · Challenge cards and stickers
A light social layer for onboarding and the launch week, not a tracked task: small challenges to set one limit, spot one threshold alarm, share one tip. A digital tracker would create a record; a sticker keeps the data footprint small. The test later moved them to launch material only.
The card and sticker designs I made; the illustrations on the cards were generated.
A screen asks for input. A click confirms something already done.
05 · Testing and the next step
The visible status started a conversation between a nurse and a doctor. The same test moved the concept into the monitor.
On 7 May we tested the concept at OLVG-Oost before it looked finished: the side reminder on a monitor, and the nurse-station visual. One emergency nurse took part, so every finding below is a direction, not a result.
Finding 01
The visible status started a conversation between a nurse and a doctor about adjusting a patient’s limits.
Doctors can feel less responsible for monitor settings. A status both can see pulls them in, which is the gap the blueprint found.
Keep the status visible to nurse and doctor alike.
Finding 02
“Then you can directly see which part of the monitor is red.”
Nurses adjust each vital sign on its own. One red or green state per patient is too blunt to act on.
Show the status per parameter: heart rate, oxygen, blood pressure, perhaps breathing rate.
Finding 03
“I think the right place is in the nurse station, next to the screen where all the monitors are.”
The overview is for staff, not for patients and visitors in a hallway, and it only helps where it can be acted on.
Move the overview to the nurse station, with bed numbers.
Finding 04
Setting the monitor and then updating a separate object would be double work.
Acceptable for a pilot. In a busy emergency department, double administration kills adoption.
Drive the status automatically from the monitor’s own limits.
Finding 05
The cards and stickers were fun, and would likely end up in a corner of the break room within days.
When patients are very sick there is no room for play. The cards suit a kickoff, not a shift.
Keep the cards for launch and onboarding only.
Finding 06
Emergency staff can be competitive; a leaderboard might motivate them.
A real value, but one shift cannot settle team dynamics, and a ranking turns a team signal into a verdict on a person.
Refused again: the view stays at team level.
Quotes as the team recorded them in the notes of the test on 7 May 2026. One participant; no reduction in alarms and no effect on safety was measured.
Monitors travel with the patient
The nurse pointed out that monitors move with the patient to other rooms, so anything clipped to one has to come off easily or stay behind.
Knowing how to set a limit
Staff practise setting limits on patient cases, and not everyone is sure how. A reminder alone will not fix that; it belongs next to training.
The next step is not another object
The strongest signal from the test pointed at the monitor itself. A standalone object helps a pilot, but adoption drops the moment staff have to update two systems. So the status has to live where the limits already are, and reach the nurse station on its own.
A future product direction, drawn for this page: not a Philips interface and not a shipped result. The values are illustrative.
Team level only
Never a named individual, and no ranking. The status describes beds and parameters, not people.
No performance use
It does not feed a performance review unless OLVG decides so explicitly.
A manual override
Even when the monitor drives the status, staff can correct it by hand.
The restraints I want to travel with the data once it lives inside the monitor, from my research report. Aggregated, the same data could compare individuals, and the opt-out the standalone reminder offered would be gone.
Product hypothesis
Alarmease could add a workflow-level status signal to the monitor ecosystem: which beds and parameters still run their defaults, and where review may be needed.
A hypothesis, not a measured outcome. It needs technical validation, clinical governance and a controlled pilot. The next moves: turn the test findings into a feature brief for Philips, building on a visit from Philips representatives; share it through that contact; and co-define a small pilot with OLVG in which monitor changes drive the status.
The object disappears. The behaviour stays.
06 · Contribution and reflection
What I did, and the order I design in now.
I did not design the final visual; that was the team's work. My part was the reasoning the team built on.
I challenged the brief's focus on the alarm, set the research up as four kinds of evidence and built the service blueprint that showed nobody owned the monitor profile at admission. I framed setting that profile as a behaviour, co-built and iterated the side reminder, designed the challenge cards, tied each ethical risk to a design decision, and turned the test on 7 May into the direction that moved the status into the monitor.
My business background helped most where the work was not visual: listening for the problem behind a stakeholder's first request, structuring conflicting input, and making the value of a direction clear to people who care about different things.
The order changed
Before this project I drew it on paper, refined the thing and defended the thing. Evidence came in afterwards, mostly to support what I had already decided. GreenPixel was strong on craft and weak on framing. Alarmease reversed the order.
Frame the leverage point
Structure evidence from different sources
Define what the intervention must not do
Build the smallest form that can test the behaviour
Test it in context before it looks finished
Let the evidence change the medium
The artefact is allowed to be small, as long as the framing is right.
What worked, and what I would change
| Process | What worked | What it cost | What I would change in action |
|---|---|---|---|
| The service blueprint as anchor | It forced framing first and kept the team aligned on one document. | A week passed before any artefact existed. It felt slow. | Check the wall after two days and commit then, instead of waiting a full week to validate the framing. |
| Co-creation before end-user testing | The risk in the smiley surfaced before the visual was committed, which saved craft time later. | It produces more ideas than a team can use. We almost kept the smiley because three nurses called it fun. | A triage rule: test each idea against the framing, not against how likeable it is. |
| AI as an experiment | It sped up production: the written argument, the structure, a code skeleton. | It shrinks brainstorming. The blank page is uncomfortable but necessary, and AI fills it before I have sat with it. | Write the brief and the early sketches without AI, and bring it in only once a direction is committed. |
After Schön: the middle columns look back on the action, the last one is what I would adjust while doing it. From my process portfolio.
Together first, divided too late
We worked in one room, which kept our framing of cognitive overload consistent, and shared ownership cut the handover time on prototype direction. The cost came later. We stayed in forming too long and split the work only when we started prototyping, skipping the norming step where a team agrees who owns what (Tuckman). By then, deciding ownership again meant rebuilding an artefact.
| RACI | What we did | What we should have done |
|---|---|---|
| Responsible | Unclear per component | One named person per component |
| Accountable | Everyone, so no one | One person per decision |
| Consulted | Everyone, always | Chosen by topic |
| Informed | Informally | A short daily check-in |
Next time, role clarity is a shared ritual rather than a personal fix: a one-hour kickoff agreement with a RACI, and a short daily check-in owned by the whole team. The lesson is not that I should take more control. It is that I should set up the structure in which shared ownership can happen earlier.
A feature brief for Philips
Turn the test findings into a brief for a status at the central station that updates by itself when alarm limits change.
Framing first, on my own project
Apply the same method to Komo, a coffee subscription I am reframing around intention rather than convenience.
Work that holds an ethical line
Grow as a service designer in healthcare and the public sector, where what a design refuses matters as much as what it does.
I design the interaction, not the object.
Who made what
Duco Boomsma
The problem framing and the move from the alarm to admission, the research set up as four kinds of evidence, the service blueprint, the behaviour framing, the ethical restraints, the challenge cards and stickers, co-building the side reminder, and turning the test into the monitor direction
Andyka Jonathan, Barbora Halanová, Negin Bokaei
The design of the nurse-station visual and its data visualisation, from the first smiley to the view per bed
The whole team
The observation at OLVG-Oost, the co-creation session, the Crazy 8s, the prototypes and the test on 7 May
OLVG-Oost
The brief, access to the emergency department for observation and co-creation, and the staff who took part
Scope and attribution
Alarmease is a tested concept, not a deployed medical product. It was tested once, with one emergency nurse. No reduction in alarms, no effect on patient safety and no commercial result has been measured, and none is claimed here. Prototype data was illustrative; no patient data was used.
Generated imagery: the bedside scene in the opening, the four photographs and four monitor clips in chapter 01, the four ruled-out renders in chapter 03 and the illustrations on the challenge cards. Each is labelled where it appears. The photographs of the research sessions and the prototypes are the real material.
Philips is named because OLVG-Oost uses its monitors. The monitors on this page are simplified drawings, not a Philips interface, and the project has no affiliation with Philips.
A Design for Health Care playground project in the Master Digital Design at the Amsterdam University of Applied Sciences, briefed by the emergency department of OLVG-Oost. Who did what is set out under Who made what, above.
Curious about the thinking behind this? Read the bio or get in touch.