Explanations must point to causes the user can change

What it is

The bar for an explanation is not "the user understands" but "the user can act". A proper explanation names a cause the user can modify — a rule's condition, a threshold, a device's placement. This is an actionable explanation.

The counter-example is the phrasing smart homes commonly ship: "Based on intelligent algorithms, your humidifier has been switched off." It explains the behaviour, but the named cause — the intelligent algorithm — is not an object the user can intervene on; the user's takeaway is a confirmation of powerlessness. The actionable version reads: "Indoor humidity is above your 60% ceiling, so the humidifier is off; the threshold can be changed in ×× settings." The cause (the humidity threshold) is both checkable and changeable.

The test is simple: after reading, does the user know what they could do next, and where to do it?

Why it happens

Explanations sit inside a loop: behaviour surfaces → cause sought → understood → decide whether to intervene → act. Actionability decides whether the last link closes.

An explanation naming a changeable cause welds "understanding" directly onto the editing entry point: the cause is itself a configurable object, so the explanation doubles as a diagnostic and a debugging interface. The user takes away not just what happened, but which knob to turn for a different outcome next time — that is where a sense of control comes from.

An explanation naming an unchangeable cause ("the algorithm decided", "model confidence was low") completes the cognitive work while sealing the behavioural exit. After a few rounds, the lesson learned is "asking is pointless"; the explanation channel falls into disuse, behaviour reverts to a black box — the intelligibility investment returns zero, with trust as interest paid out.

Accountability layers on top: by locating the cause in one of its own configurable parts, the system concedes that the part can be held responsible. A system that refuses to name a changeable cause is in effect declaring "even when it goes wrong, it is none of your business".

Studying it

• Extensions of the explanation typology: within the why / why-not / how-to question types from intelligibility research, the how-to class ("how do I make it stop doing that") and its relation to perceived control is the direct theoretical source of this entry — the explanation toolkit explicitly lists intervenability as a design dimension.
• Explanation-to-intervention experiments: give participants two explanations of the same surprising behaviour (descriptive vs. naming a configurable cause) and measure whether they subsequently complete a targeted modification, plus time and help-seeking. Interfaces in end-user programming research that treat explanations as rule-editing entry points evaluate along these lines.
• Field corroboration: long smart-home deployments document the learned helplessness users display facing unchangeable-cause explanations — they stop attempting adjustments and route around the system.

One methodological caution: "could complete the modification" is easily confounded by editor usability — an actionable explanation behind an unusable editor still measures as failure. Keep the actionability of the explanation and the reachability of the editing entry point as separate measures, or the attribution goes wrong.

Where it stops holding

• Not every cause is changeable. Physical limits (sensor accuracy, signal coverage) and safety constraints (deliberate lockouts) are real. Here the obligation is neither to lie nor to be vague, but to say why it cannot be changed and what the workable alternative is — "unchangeable, but bypassable" is still actionable.
• Actionable does not mean immediately acted on. Most often users read an explanation only to confirm the system isn't broken and change nothing. Actionability pays out at moments of failure and dissatisfaction, while its costs (maintaining entity links, keeping explanations in sync with configuration) are always paid — so budget it against the rare actions, not all of them.
• Granularity has a privacy edge. An explanation should carry the minimum information that locates the changeable layer; anything beyond is simultaneously burden and exposure.

Applying it

• Make every configurable entity in an explanation (rule, threshold, time window) a link to where it is edited: an explanation is a modification entry point, not an announcement.
• Give explanation templates two endings — "you can change this" (with entry point) and "system constraint" (with reason and workaround) — and ban the third, vague ending ("intelligent optimisation").
• Quote real configured values ("your 60% ceiling") rather than restating abstract rule names — users should be able to check the relation between their setting and the behaviour.
• How to check: show ten real explanations and count the share where users know the next step and where to take it; then take one recent unsatisfactory behaviour and time how long it takes from reading the explanation to completing a targeted modification. If the share and the time fail, the explanations are still announcements.

Related

• Same group: Z7.01.1 Users must be able to answer why the system did that · Z7.01.2 Unexplained automation gets attributed to malfunction
• Nearby: Z7.03 Modifiability · Z2.08 Correcting the system's context judgements
• Search terms: actionable explanation · intelligibility · end-user programming · accountability