A person opens your application to finish one task. A promotional banner moves, a chat window appears and a notification announces something that could have waited. The software is very engaged. The person is still trying to finish the task.
The World Health Organization’s theme for 10 October 2026 centres on the voices of people with lived experience of mental health conditions and their influence on decisions. It concerns health systems, not a certification for apps. For product teams, our related question is narrower: are the people affected by an interface involved in deciding how it behaves? WHO: World Mental Health Day 2026.
What the evidence supports—and what it does not
In a CHI 2008 laboratory experiment, Gloria Mark, Daniela Gudith and Ulrich Klocke found that participants completed interrupted tasks faster, while reporting more stress, frustration and effort. The task simulated office email work. It was not a long-term clinical study, and it does not establish that a notification causes a mental health condition. Original study, PDF.
A separate 2019 randomised field experiment with 237 participants compared notification schedules over two weeks. Three daily batches showed benefits on several self-reported measures compared with usual delivery; removing notifications entirely did not reproduce the same pattern. A short study with a particular sample and implementation cannot identify a universal schedule for every occupation or person. Fitz and colleagues, Computers in Human Behavior.
The useful engineering inference is to make timing and control testable. It is not to prescribe three notification windows to everyone, call every interruption harmful or advertise an interface as a treatment. A caregiver awaiting an urgent update and someone reading a long document may need different behaviour from the same device.
Start with the event, not the red badge
Before adding an alert, write down who needs it, what action they can take and how late is too late. “The user has not opened our app today” answers none of those questions. “The export failed and the user must correct a field” gives the design team something useful to work with.
Consider a fictional booking app. A cancellation affecting today’s appointment may warrant a prompt notification. A weekly activity summary can usually wait. A new decorative theme is neither an appointment nor an emergency. Classifying these events separately lets the product offer meaningful choices instead of one switch labelled “Everything”.
For each category, define the default, available channels, quiet hours, repeated-alert limit and how a person can find the information later. Respect operating-system permissions and preferences. A notification that can be dismissed should not immediately return wearing a slightly different hat.
Control should be visible and persistent
Accessibility standards offer concrete reference points. WCAG 2.2 criterion 2.2.4, at level AAA, addresses postponing or suppressing interruptions, with an exception for emergencies. It should not be misrepresented as a level-AA requirement or a blanket instruction to hide every alert. W3C: interruptions.
Criterion 2.2.2, at level A, covers specified moving and automatically updating content and mechanisms to pause, stop, hide or control it. Its exact conditions and exceptions matter. A promotional carousel that moves automatically alongside a reading task deserves a real pause mechanism, not a hope that visitors will finish reading faster. W3C: pause, stop, hide.
A useful product check is whether a preference survives navigation and a later visit where the design promises persistence. Also check that keyboard users can reach the control, its name explains the action and pausing does not unexpectedly move focus. A button that exists in the design file but cannot be operated does not give the person control.
Listen before choosing the default
Invite people with different access needs and working contexts to perform a real task. Ask where the interface interrupted them, which information they missed and what they expected to happen next. Do not require someone to disclose a diagnosis to justify a preference. Avoid treating one participant as the representative of everyone with a similar experience.
Make the feedback consequential. Record the proposed change, who owns it and how it will be checked. If a suggestion cannot be adopted because it conflicts with another need, explain the trade-off. A listening session that never changes a decision is good at producing meeting notes; that is a rather limited ambition for product research.
A small experiment your team can run
Choose one non-urgent notification category. Offer immediate delivery, a digest and silence, while keeping the underlying information available in the app. Test understandable labels, persistence and the ability to change the choice. Keep genuinely time-sensitive events separately defined; do not quietly downgrade them as part of this experiment.
Evaluate task completion, missed important events, requests for help and people’s explanations of their choices. A lower session count might mean the product is working more efficiently, not failing to engage. Compare outcomes with the purpose of the feature instead of rewarding whichever version produces the most taps. This is a proposed product evaluation, not a clinical trial or a report of Zephyrus results.
Finally, support recovery. Preserve a draft where appropriate, explain a timeout before work is lost and make the next step clear after an error. People should not need exceptional concentration to survive an ordinary form. Useful software can ask for attention when it matters—and have the manners to wait when it does not.