Crisis and self-harm
What an interface must do when someone discloses thoughts of suicide or self-harm, and how to signpost support without ambush, judgement or a dead end.
What this means
Mood questionnaires and wellbeing check-ins are common in consumer health products, and many of the standard instruments include an item about thoughts of self-harm or of being better off dead, because clinicians need to know. That item will eventually be answered affirmatively inside a product built on these components, by someone alone with a phone and with no clinician anywhere in the loop.
By that point the product has elicited a disclosure it is not equipped to answer clinically, and every screen that follows is a design decision, owned by the team that shipped the questionnaire and taken long before the moment it applies.
This page is written against two failure modes that err in opposite directions. Absorption is the screen that carries on: the score appears, the progress bar advances, the reader is congratulated for completing the questionnaire, and what they disclosed is averaged into a number. Ambush is the screen that over-reacts: an alarming interstitial that reads as a system responding to a threat, or a telephone number presented with no acknowledgement of what the reader has just said.
A design system's ordinary vocabulary of components, states and budgets does not reach this surface. Deciding what the response must contain is a clinical question before it is an interface question, and the organisation deploying the questionnaire is accountable for obtaining clinical mental-health input on it.
The rule
A disclosure of risk of harm is acknowledged in place, immediately, without alarm, and always leads somewhere. It is never scored silently, never congratulated, and never a dead end.
| # | Requirement | How a reviewer checks it | Who owns it | Basis |
|---|---|---|---|---|
| 1 | Acknowledge before anything else. The next surface the reader sees responds to what they said, ahead of any score, any progress bar and any thank-you. | Answer the item affirmatively on a device and confirm no score, progress indicator or thank-you paints before the acknowledgement. | The implementing team | Design judgement |
| 2 | Plain, warm, unshocked language. "Thank you for telling us. Many people have these thoughts, and support is available." No clinical register, no alarm, no exclamation marks, no red. | Read the acknowledgement copy and confirm it contains no clinical term, no exclamation mark and no red. | The implementing team, writing the copy | Design judgement |
| 3 | A calm surface outside the escalation ladder. The response is calm, prominent and visually distinct, and it carries neither the urgent status nor the visual language of a clinical alert. | Screenshot the response beside an urgent clinical alert and confirm no shared token, colour or icon. | opsinjs owns the status axis. The implementing team owns the surface | Design judgement. The status axis is defined in Clinical status semantics |
| 4 | More than one route onward. Talking to someone now, talking to someone later, information to read, and a way to tell a clinician already involved in their care. | Count the routes offered on the response surface and confirm all four kinds are present and reachable. | The product owner, assembling the routes | Design judgement. People in distress differ enormously in what they can do |
| 5 | Routes configured per region and kept current. opsinjs ships no crisis numbers, no services and no opening hours, because a wrong or stale number here is worse than none. | Open every route configured for the region under review and confirm the service, its hours and its coverage still hold on the date of the check. | The product owner owns the list and owns keeping it right | |
| 6 | Freedom to continue, to leave or to say nothing more. No surface blocks the reader, traps them, or compels a further answer. | From the response surface, continue the questionnaire, close it, and leave the next item unanswered, and confirm each of the three succeeds. | The implementing team | Design judgement |
| 7 | No account, payment or completed profile. Support routes sit outside every sign-in, payment and profile-completion gate. | Reach the support routes from a signed-out install with no payment method and an incomplete profile. | The product owner | |
| 8 | Safe-messaging practice. No method detail, no lethality information, no graphic imagery, and no framing of suicide as a solution or an inevitability. | Read the response copy and imagery against the guidance named in "Why (evidence)" and confirm no method detail, lethality information or graphic image appears. | The implementing team, working from the published guidance | Established practice in the field rather than a stylistic preference. The sources are named in "Why (evidence)" |
| 9 | An explicit statement of what happens to the answer. Whether a person is contacted, whether a clinician sees the answer, and whether anything else is triggered, stated because silence here is read as surveillance by some readers and as a safety net by others, and both are dangerous guesses. | Confirm the statement appears both before the item is answered and on the response surface. | The product owner, with the organisation's clinical and information-governance leads | See Consent and disclosure |
| 10 | The repeat case, specified in advance. Someone who discloses every week receives neither the same interstitial every week nor nothing at all, and the repeat pathway is written down before the product ships rather than decided at the second occurrence. | Ask for the written repeat pathway and confirm it predates release and names what a second, fifth and twentieth disclosure produce. | The product owner, with clinical mental-health input | Deferred to clinical mental-health advice |
| 11 | No engagement mechanics near this surface. No streaks, no badges, and no "you are on a roll" on a mood questionnaire. | Complete a mood questionnaire, then abandon one part-way, and confirm no streak, badge or reward fires on either path. | The implementing team | Design judgement. Escalation is budgeted in Alarm fatigue |
Rules 5 and 7 are not classified in "Why (evidence)" below, and their Basis
cells are left empty rather than filled by assumption.
Why (evidence)
Applying it
Do
"Thank you for telling us. That can be hard to say. If you would like to talk to someone now, here is how. You can also carry on, and this will still be here."
Don’t
"Question 9 of 9 complete. Your score is 18. That is moderately severe." The scored questionnaire routes the disclosure straight into an aggregate and returns a band, with no acknowledgement between the answer and the score.
Do
Offer several routes with different demands: a helpline, a text service, a self-help page, and a way to flag it to a clinician already involved in their care, and say which of those routes are available at the moment the reader is looking.
Don’t
Show a single phone number and a Close button. A single telephone route excludes every reader who cannot make a call at that moment, and the Close button is then the only control the screen offers them.
Do
"Your answers are shared with the clinical team at your surgery. They may contact you about this." Say it before the question, and again here.
Don’t
Leave it ambiguous. An unstated consequence changes what the reader answers rather than what they think, because a reader who suspects a consequence answers to avoid it.
Do
Keep the support surface reachable afterwards through a persistent, quiet entry point in the app, and not only in the moment of the disclosure.
Don’t
Show it once, lose it on dismissal, and require the person to disclose again before the same help can be found a second time.
Components that implement this
questionnaire ships, and this page is the constraint on using it here: an
instrument that can elicit a disclosure needs a specified response pathway before
it needs a React component, and the component supplies no such pathway. It has
no risk-response slot, so the product owns that slot and owns testing it.
What this does not cover
Five areas sit outside the scope of this page. Where this page can name the party it expects to hold one of them, the Who owns it column does so, and where it cannot, the cell is empty.
| Out of scope | Why it sits outside this page | Who owns it |
|---|---|---|
| Clinical assessment and risk stratification of any kind | opsinjs contains no instrument, no scoring, no thresholds and no triage. | The organisation's clinical governance |
| The crisis services themselves, including numbers, hours, coverage and eligibility | They are regional and change without notice, which is why rule 5 places them outside what opsinjs ships. | The product owner, configuring them and keeping them current |
| Safeguarding duties | Whether a disclosure must be acted on, and how, is a legal and clinical governance question rather than an interface one. | The organisation deploying the product |
| Content moderation of anything a reader writes freely | It is a separate discipline with its own policy and tooling, none of which is supplied here. | |
| Children and young people | Consent, confidentiality and safeguarding all differ substantially for this group, and this page is not sufficient for it. | The organisation's clinical and legal governance |
Updates to this page
Last read through against the system on 2026-09-02. Due for review every 3 months; expiry is reported by pnpm run check:freshness.
Emergency and escalation
What an interface must do when a value may mean someone needs help today. The one path in the system that outranks every other rule, budget and preference.
Delivering difficult results
Tone, sequence and structure for the moment an app tells someone something they did not want to hear, with no clinician present and no question available.