Sometimes a caregiver operates the device for someone else, in person or remotely

What it is

This is about whether and how an interface should support the pattern where a third party — an adult child, a caregiver — operates the device on the account owner's behalf or assists remotely. It does not cover why an older user needs this kind of help in the first place, which involves both capability decline and differences in technology experience and belongs to other entries.

Why it happens

Many products are designed assuming the person operating the device is the account owner, with the account system, verification flow, and privacy boundaries all built around a single-user model. In practice, a substantial share of users rely long-term on relatives or caregivers to complete part or all of certain tasks, whether by handing over the device in person or guiding and intervening remotely. When an interface leaves no room for this pattern, the person helping is either forced to share the account owner's full credentials — a security and privacy risk — or has to redo, every time, a verification flow that only the account owner is meant to complete. Either outcome adds friction to the act of helping and indirectly reduces the quality of assistance an older user can actually receive.

Where it stops holding

Supporting proxy operation cannot come at the cost of the account owner's own right to know and ultimate control — if the delegation mechanism is designed so a third party can bypass the owner entirely and perform arbitrary actions without their knowledge, that itself becomes a new source of risk, particularly ripe for abuse in financial contexts. The goal of this adaptation is to reduce friction for legitimate assistance, not to weaken the account's overall security boundary — both need to hold at once, not trade off against each other. Nor does every older user need or want to be assisted; making the "allow proxy access" entry point too prominent risks making users who are fully capable of operating independently feel diminished.

Applying it

• Provide a revocable, scope-limited authorization mechanism (for example, granting a specific relative read-only or tiered operating permissions) rather than requiring the primary account password to be shared to enable proxy management.
• Support screen sharing or guided operation for remote assistance, with a clear start and end to each such session and explicit authorization confirmation, so it doesn't turn into indefinite, ongoing access.
• For high-sensitivity actions involving finance or health, leave the account owner with an after-the-fact record of what happened during proxy operation or remote assistance, rather than no trace at all.
• Verification: design a real proxy-operation scenario (for example, an adult child remotely guiding a parent through a settings change) and observe whether it forced use of a shared password, skipped verification, or left behind long-standing unrevoked access. Any of these shows the current design doesn't genuinely support this usage pattern.

Related

• Same group: A11.03.6 non-blaming error messaging · A11.03.8 modern interface metaphor unfamiliarity causing icon ambiguity
• Nearby: A11.01.8 age and technology experience are independent variables
• Search terms: delegated access · remote assistance · caregiver access