Different roles should receive different depths of explanation, not the same text

What it is

The same loan denial. The applicant needs to know what is missing and whether it can be added. Audit needs the rule version and sliced performance. Engineering needs feature drift. Three accounts at different depths — not the longest one sent to everyone. Different roles should receive different depths, not the same text.

One text is either too deep for the applicant or too shallow for audit. Both ends fail at once.

Why it happens

Roles have different next steps, so passing depth differs. Depth is the resolution prepared for that next step: field-level for the applicant, policy-level for audit, distribution-level for engineering. A shared text can pick only one resolution. Pick deep, and the applicant drowns in detail; pick shallow, and audit lacks a version number. Miller’s audience constraint becomes product structure here: the audience is a role, not “people willing to read more.”

Role also cannot be a single “advanced mode” cut. An applicant who happens to like machine learning is still doing the applicant’s task; depth should follow the task, with an engineering entry opened separately. Depth binds to role, entry binds to task; do not weld the two into one switch.

Studying it

Three groups (applicant, audit, engineer) each do their own job, given a shared long text, a shared short text, or three packs split by role. Independent variables: material strategy, whether people may open another role’s pack. Dependent variables: completion of their own job, misuse of another role’s material, open rate.

If the split group does the job better with less misuse, the shared strategy is bankrupt. Do not defend sharing with “someone finished the long text.”

Where it stops holding

In a tiny team one person holds three roles and needs to switch, rather than forever seeing one band. A public page that cannot reliably tell roles apart should default depth from the current task, not guessed identity. If oversight requires that everyone can obtain the full file, the full file exists as a downloadable third pack — that is not the same as making it the interface default. This entry neighbours “developers and users need different kinds of explanation,” but the scale here is depth, not kind.

Applying it

• Make three entries by role (or by current task): person concerned, audit, engineering. Do not mix them by default.
• Shared sentences only for the one limit every role needs; the rest is written at each role’s resolution.
• Allow an explicit jump such as “view the audit copy,” and mark that they are looking at another depth.
• Check: have people in the three roles see only the pack defaulted to them, and complete their next step. If any role cannot, depth is cut wrong; if they can only finish by reading someone else’s pack, the split has not split.

Related

• Same group: L5.05.1 Excess technical detail does not produce understanding · L5.05.2 Transparency must serve the user's next decision · 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
• Nearby: L5.02 Local and Global Explanations · L5.01 Types of Explainability · L5.08 Counterfactual Explanations
• Search terms: role-differentiated explanation · audience of explanation · depth by role