Transparency must serve the user's next decision

What it is

Machine translation produces a draft contract. The user’s decision now is: take it to be signed, or treat it as gist and have it retranslated. If transparency serves that decision, it says this is gist, not signing text. If it talks about subword splits and attention heads, the decision is not served. Transparency has to work for the next decision, not for “seeing the inside.”

The next decision is the one on this screen, not an abstract right to know.

Why it happens

Every time an account is opened, the user stands at a fork: send, edit, ask someone, quit. Each sentence in the account either helps them pick a side or spends the time that picking needed. Miller treats explanation as an answer to a particular question; in a product the question is the current fork. Transparency that answers the wrong question looks dutiful; decision quality does not rise.

“Next” changes with the setting. The same translated passage: when browsing news, next is “gist is enough”; when signing, next is “can this be the body.” Of the same internal information, only the layer that meets the current fork should appear.

Studying it

First mark the next steps that actually exist on the interface (send / edit / hand off). Then give copy aimed at that fork, or unrelated internals, and watch whether the choice changes and whether it becomes more appropriate. Independent variables: whether the copy names the current fork, how high the fork’s stakes are. Dependent variables: change of choice, agreement with expert disposition, rate of still following the original plan after reading.

“Read it” is not the endpoint. Split cases where nothing changed and nothing should have.

Where it stops holding

Some moments have no next step; the person is archiving or satisfying curiosity, and the account can lean toward a record rather than a decision. When stakes are high but the user cannot change anything (look only), transparency serves later accountability, not an on-the-spot decision — that is a different packet. This entry is about purpose. The test of whether there is enough, and whether leftover unactionable information is noise, are neighbouring rulers.

Applying it

• Before writing, write down the few controls the user can press now. Keep only sentences that can change which of those is chosen.
• When the fork changes, change the copy. Browse mode and sign mode must not share a paragraph of internals.
• Split “about the system” from “about this choice of yours,” and open the latter by default.
• Check: after reading, can they point to which control they will press next, and why. If not, transparency is not serving the decision.

Related

• Same group: L5.05.1 Excess technical detail does not produce understanding · L5.05.3 Information that cannot be acted on is noise · L5.05.4 Transparency is sufficient only if the user can change the next action from it · L5.05.5 Excess detail crowds out attention needed for key information · L5.05.6 Transparency and usability are in tension; full disclosure makes the interface unusable · L5.05.7 Transparency does not necessarily produce trust; exposing complexity can lower it · L5.05.8 Different roles should receive different depths of explanation, not the same text
• Nearby: L5.01 Types of Explainability · L5.02 Local and Global Explanations · L5.03 Trust Calibration
• Search terms: decision-serving transparency · next action · explanation for choice