Blog

Measuring wellbeing without surveilling the people you are measuring

You cannot support people you know nothing about, and monitoring destroys the trust that makes disclosure possible. How to design out of that corner.

The Lurno teamAugmental3 agosto 202611 min di lettura

Questo articolo non è ancora tradotto — viene mostrata la versione inglese.

You cannot support people you know nothing about, and the monitoring that would tell you everything destroys the trust that makes disclosure possible. The way out is not a better promise. It is to collect less, and to make the little you do collect structurally unreadable: an individual answer legible to nobody but the person who wrote it, enforced by the database rather than by a paragraph in a privacy notice, and a group result withheld entirely until enough people have answered that no one can be picked out of it.

Anyone who has run a staff or student wellbeing survey knows the failure mode. Answers cluster on the safe middle. Response rates hold for two rounds and then fall, and the people whose answers you most needed stop answering first. That is not apathy. It is an accurate reading of who might be looking.

A confidential survey means somebody could identify you and has undertaken not to. An anonymous one means the link does not exist to follow. Most wellbeing tools are the first, described in words that sound like the second. And the test people apply is not the privacy notice — it is whether they can build a chain. There were four of us on the team. There was one question about workload.

Lurno

One read policy on the answers table, naming the author and nobody else — so a manager's query returns zero rows, and so does a report built next year by somebody who never read the policy.

Not this

A privacy notice promising confidentiality, above a table three teams can query, one integration copies nightly, and a support engineer can dump at two in the morning.

Withhold the group result below a threshold

k-anonymity

A published result is k-anonymous when every person it describes is indistinguishable from at least k−1 others in it. In a wellbeing programme, k is how many people must answer before a group result appears at all — with k = 5, a four-person team never produces a chart, an average or a count. The threshold must hold per cell, not per total: four people answering fine and one answering badly clears a check on the total of five, then publishes a bar of height one with a name attached to it in everybody's head. Cells too small to publish should fold into one other bucket rather than vanish, since dropping them leaves the totals short by exactly the number you were hiding.

Thresholds exist because identity is rarely in the name column. Latanya Sweeney showed this in the late 1990s, re-identifying the medical records of the then governor of Massachusetts inside a state insurance dataset released as anonymous, by matching it against a public voter roll. A wellbeing dataset is worse: team, site, role and shift pattern single somebody out long before a name is needed, and the person who wants to know already knows who works that shift.

So run the check against whatever combination the reader can request, not the raw population — and suppress on the server, before anything is serialised. A number that has reached the browser has been disclosed. Watch for differencing too: the same breakdown published in March and again in April, with one person leaving in between, subtracts down to an individual.

What is the minimum group size for reporting wellbeing survey results?

Five is the usual floor and a reasonable default, applied per cell of the breakdown rather than to the total, and re-checked on every filtered view a reader can construct. The number matters less than two properties around it: the organisation can raise it, and nobody can lower it — not the vendor, not an administrator. A threshold the most senior person in the building can turn down reads as a privacy control while working as a switch for turning privacy off.

An individual answer should be unreadable by design, not by agreement

The people who read your wellbeing data in three years will not have read your policy. They are a report built for a board pack, an export written in a hurry before an audit, an integration with an HR system bought after you left. A governance document reaches none of them. A predicate on the table reaches all of them, because it runs on every read.

-- The only read policy on the check-in table.
create policy checkin_self_read
  on wellbeing_checkin for select
  using (author = auth.uid());

-- Note what is absent: no policy for managers, none for
-- wellbeing leads, none for administrators.

Write answers against a keyed pseudonym rather than a user id and the row a service process can reach stops saying whose it is. A keyed hash, under a root key the application database cannot read, with a separate salt per purpose, keeps an anonymous item from being joined to that person's check-ins. There is no reverse map, so there is nothing to leak.

Then be honest about the exception, because most institutions need one. If a safeguarding duty means somebody must occasionally be identified, build it as a break-glass path and say so: a permission granted to no role by default, two people, a written reason, a log entry, and a rule on whether the person is told afterwards. An exception designed in the open costs little trust. One discovered later costs you the programme.

Can my manager see how I answered a wellbeing check-in?

In a properly built system, no — and neither can the wellbeing lead, the HR director or the platform administrator, not because they have agreed not to look but because the read policy on the table matches the author's own identity and there is no second policy for anyone else. Ask the vendor to run a manager account's query against your answer and watch it return nothing. If the answer involves role configuration instead, you are being offered confidentiality rather than anonymity.

A signal prompts a human conversation. An alert triggers an automated one.

This distinction decides whether a programme is support or surveillance, and it is almost never made explicitly. A signal is a movement in something aggregate that gives a person a reason to ask a question: workload scores across a department have slid for three rounds, so its head books time with the team. An alert is a rule that fires on an individual and acts without anybody deciding.

The second requires the exact capability the last section removed. To alert on a person's answer, something has to read that answer and attach it to a name. A product offering automated individual alerts is telling you, whatever its privacy page says, that individual answers are readable.

Who is named? A signal names a group and a trend. An alert names a person to somebody with power over them.
Who decides to act? A signal ends with a human choosing whether to have a conversation. An alert has already acted by the time anyone reads it.
Would you print the rule? If a rule cannot go in the participation notice without changing how people answer, the notice is a decoy.

If a duty of care genuinely requires individual escalation, constrain it hard. Make the rules data rather than code — a signal type, a compared value, this happened N times in D days — so the whole set can be printed for the people it applies to. Send the recipient a reference code and the rule's name, never the answers.

One more rule earns its keep: never ask a question you have no answer for. Until a support contact exists — an assistance line, a counsellor, a safeguarding lead — questions about how somebody is coping stay switched off.

What you should never collect

Passive telemetry as a wellbeing proxy. Keystroke rates, hours in a document, message sentiment, camera-based emotion detection, location traces. The EU's AI Act prohibits emotion-recognition systems in the workplace and in education, with narrow medical and safety exceptions — and even where a technique is lawful, it turns wellbeing from something people tell you into something taken from them.
Clinical detail. Diagnoses, medication, therapy history. Under the UK and EU GDPR, data concerning health is a special category carrying a higher legal bar, and a daily check-in is the wrong container for it.
A per-person wellbeing score. The moment a number is attached to an individual, somebody will sort by it — and everyone answering assumes somebody already has.
Anything joined to performance management. Not the same table, not the same identifier, not the same reader. One suspicion here ends candour across the organisation.
Data with no retention clock. Two clocks work well: the first drops the identity and keeps the pseudonym, so a trend does not rewrite itself when somebody leaves; the second removes the row.

What wellbeing data should you never collect from staff or students?

Anything taken passively rather than offered — keystroke and activity monitoring, message sentiment analysis, camera-based emotion detection, location traces — along with clinical detail such as diagnoses or medication, per-person wellbeing scores, and any field joined to performance or disciplinary records. The EU's AI Act prohibits emotion-recognition systems in workplaces and educational institutions, and health data is a special category under the GDPR. The rule that catches the rest: if you would not show a field back to the person it describes, do not create it.

Tell people what is visible, in the same words the system enforces

Honesty here is not only an ethical position, it is the measurement instrument. A programme people do not trust returns noise, and noise is worse than silence because it looks like data and gets acted on. The error runs one way: everything looks fine in exactly the teams where people feel least safe saying otherwise. So write the participation notice as a description of mechanism.

Who can read an individual answer. If the honest answer is nobody, enforced by the database, that sentence is worth more than the rest of the document.
The threshold, as a number. We do not show results for groups smaller than five is understood by everyone; aggregated to protect privacy is understood by nobody.
What causes a human being to make contact, and what that person is shown.
How long answers are kept, when the identity is dropped, and when the row is deleted.
How to withdraw, what happens to answers already given, and whether skipping is noticed. Say plainly that it is not — no streak, no follow-up, no list of non-responders.

The UK's Information Commissioner's Office, in its 2023 guidance on monitoring workers, is explicit that workers must be made aware of the nature, extent and reasons for any monitoring — so the notice is rewritten the day behaviour changes, not the quarter after. Store the wording somebody agreed to, verbatim: editing the screen next year must not change what everyone already consented to.

Small choices carry the message too. Send reminders inside the product, never by email or to a lock screen, and never carrying anything about how somebody answered. Record nothing when a person opens a self-help article. Each is a place where the system could gather something useful and deliberately does not.

How do you get honest answers from a staff wellbeing survey?

Make dishonesty unnecessary rather than discouraged. Keep it short enough to answer truthfully on a bad day — two questions and fifteen seconds beats a quarterly questionnaire nobody finishes. Guarantee at the data layer that no individual answer is readable, then say so in one plain sentence. Publish the minimum group size as a number. Remove every incentive to perform: no streaks, no non-responder lists, no link to appraisal. And close the loop visibly, because the second most common reason people stop answering, after fear, is watching nothing happen.

What this looks like when it is built in

The wellbeing module in Lurno is built on these rules rather than around them. A check-in is two taps and about fifteen seconds. Each answer is written against a keyed pseudonym, and the only read policy on that table matches the author's own user id — so a manager, a wellbeing lead and an administrator all get nothing back, and no setting changes that. Group results are released only once k people have answered: the floor is five, an organisation can raise it, and neither the organisation nor we can lower it. Below the threshold nothing is shown at all.

The guardrails match the argument above. The module stays off until an administrator enables it for one organisation. Coping questions stay disabled until a support contact exists. Opening something in the Calm Corner writes no row. Escalation rules are data rather than an expression language, and the lead who receives one sees a reference code, not the answers. One scope note: the module covers staff. Learners and guardians are not wellbeing subjects in it; learner-side visibility runs through the guardian portal.

The claim is checkable rather than rhetorical: Separation between organisations is enforced underneath the platform rather than only by the screens on top — which is why the check-in table behaves the same way under a query nobody anticipated. The rest of that model is on the security page.

The short version

Collect the least that could still tell you something. Make an individual answer unreadable in the data layer rather than in a document, and design the exception in the open. Withhold every group result below a threshold you can raise and nobody can lower. Keep signals, which give a human a reason to ask, apart from alerts, which act on a person without asking. The programme that measures least often measures best, because it is the one people tell the truth to.