Mixing "you" and "my" confuses who is speaking

What it is

Interface participant-role disambiguation makes every message answer who is speaking, acting, owning an object, receiving an action, or bearing its result. “You,” “I,” “we,” and “your” have no intrinsically fixed referent in interface fragments: they may come from the product, current user, content author, collaborator, administrator, or support agent. Different persons can coexist. The defect is more than one plausible participant for the same expression, causing responsibility or consequence to be misread.

Why it happens

Connected discourse establishes referents upstream; an interface renders headings, controls, fields, notifications, and embedded content separately, often removing the antecedent. The same object is also seen by different roles. A creator may call it “my file,” but a recipient cannot read the same “my” in a sharing notice as ownership by themselves. Concatenation, reuse, and templates exposing only {name} further conceal actor, owner, and recipient. A stable message model declares speaker, addressee, actor, owner, recipient, affected party, and object before complete copy expresses the actual relationship.

Studying it

Build a participant–action matrix spanning self-action, product automation, administrator action on behalf of someone, collaborator requests, ownership transfer, and third-party content. Without extra explanation, ask participants who spoke, acted, owned, was affected, and what a click would do; record multiple answers, wrong actions, time, and confidence. Test controls beside body copy, notifications detached from their source page, linear screen-reader order, and missing or duplicate names. Grammar review is insufficient. Consequential cases must establish correct understanding of action, object, irreversible scope, and recovery owner.

Where it stops holding

“We” for a product and “you” for a person can coexist clearly, and first-person navigation may be an established convention. Uniqueness of reference, not pronoun count, determines the defect. Repeating a name or role can matter more than fluency at a responsibility boundary, though repetition everywhere adds load. “I” inside user text or a quotation belongs to its original speaker and cannot become product self-reference. Some languages express roles through omission, morphology, or honorifics, so a translation need not retain every source pronoun; it must retain the participant semantics.

Applying it

• Define a participant-role schema for dynamic messages with at least speaker, addressee, actor, owner, recipient, and affected object. Variable documentation states whose name appears and who initiated the action.
• Deliver and render complete messages rather than concatenating pronouns, names, and verbs. If one message serves different role relationships, provide explicit branches or rewrite it instead of making {name} carry all reference.
• In payment, deletion, transfer, permission, sharing, and automation copy, state actor, action, object, affected scope, and recovery path. Do not rely on control position or a previous page for a consequential participant.
• Export messages with person and role variables, expand every role combination automatically, then run “who does what to whom” tests with target readers. Treat multiple plausible answers, false ownership, and misassigned responsibility as defects.

Related

• Same group: T1.01.1 Person choice positions the relationship between product and user · T1.01.3 Voice must stay consistent across the product · T1.01.4 Tone should adjust with situation gravity, not stay uniform
• Adjacent: T1.03.2 Omitting the subject creates unclear reference · T2.01.3 A button and its context form the sentence together
• Search terms: referent ambiguity · participant role schema · actor owner recipient