---
title: "Crisis and self-harm"
description: "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."
url: "https://opsinjs.pensievelabs.org/health/crisis-and-self-harm"
source: "https://opsinjs.pensievelabs.org/health/crisis-and-self-harm.md"
section: "Health"
kind: "health"
evidence: "opinion"
reviewed: "2026-09-02"
reviewer: "design"
aliases: ["self-harm", "suicide", "crisis line", "safeguarding", "distress", "mental health crisis"]
implements: ["questionnaire", "care-card", "alert-banner", "consent-sheet", "disclaimer-note"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
## What this means [#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 [#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](./clinical-status-semantics.mdx) |
| 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](./consent-and-disclosure.mdx) |
| 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](./alarm-fatigue.mdx) |
Rules 5 and 7 are not classified in "Why (evidence)" below, and their `Basis`
cells are left empty rather than filled by assumption.
The organisation deploying a product that includes any item capable of
eliciting a disclosure of risk of harm must design that item's response with
someone who holds clinical mental health expertise, and must record the
response as a specified pathway rather than assembling it screen by screen.
Where that expertise is not available to the team, removing the item is the
safer course, because asking a question the product has no response to is
itself a harm to the person who answers it.
## Why (evidence) [#why-evidence]
We mark this `opinion` because we are describing interface behaviour and have
not run studies on it. Rule 8 rests on a well-established body of practice
that the implementing team should read directly rather than take from us:
guidance on responsible communication about suicide has been published by the
World Health Organization, and in the UK the Samaritans publish media
guidelines that are widely used well beyond journalism. Both are current
documents, both are freely available, and both are more authoritative on this
than a design system can be. We name them and do not paraphrase their content,
because paraphrasing safe-messaging guidance is how it gets diluted.
Rules 1 to 4, 6 and 11 are our design judgement, and that judgement rests on an
asymmetry in the cost of getting the response wrong. A person who has just
disclosed something difficult and is met with a progress bar learns that this
product is not a place to answer honestly. That lesson shapes the answers they
give afterwards, including the ones a clinician needs. We consider the cost of
an over-gentle response to be near zero and the cost of a dismissive one to be
high and lasting.
Rule 3, which keeps this off the clinical status axis, is the one most likely
to be argued with, because the disclosure is serious and the status axis is
where serious things go. We keep it separate because the status axis compares
values against ranges, and because an `urgent` red banner in response to a
person's disclosure of their own thoughts reads as a machine reacting to a
threat.
What would change our mind: a written pathway from a clinical mental health
specialist that contradicts rules 1 to 4, or that specifies the repeat case
left open by rule 10, would revise those rules, and we would follow it in
preference to our own reasoning on this page.
## Applying it [#applying-it]
"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."
"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.
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.
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.
"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.
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.
Keep the support surface reachable afterwards through a persistent, quiet
entry point in the app, and not only in the moment of the disclosure.
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 [#components-that-implement-this]
{/* Generated from `implements`. Do not restate the list by hand. */}
`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 [#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 |
Specify the repeat-disclosure pathway with clinical input: what a person
who discloses weekly should see on the second, fifth and twentieth occasion.
## Updates to this page [#updates-to-this-page]