Do not inflate how necessary the permission is

What it is

Purpose copy that writes an optional capability as "required to use the product" inflates necessity. Notifications, approximate location, and matching friends from contacts are often not physical preconditions of the core task; the camera is, for "photograph this ID." Inflation frames refusal as product failure, so people cannot trade off against real dependency. This entry is only about whether the copy matches actual dependency. It is not about how the rest of the product continues after a denial, and not about writing a feature-level sentence.

Why it happens

"Must" is a strong modal: it cancels refusal as a legitimate option. When copy says required and the implementation can degrade, people are being moved by false information, and grant rate no longer means informed consent. Conversely, a truly required capability (no microphone, no call) should be stated; hiding the dependency produces a later illusion of a bug. Inflation also poisons later copy: once someone discovers nearby search still works without location, every future "must" reads as sales.

Studying it

Label each permission "task fails without it" or "task degrades without it," then compare honest copy with "must enable" copy.

Independent variables: whether copy claims the permission is required, whether the product is actually unusable after denial, whether the pre-prompt hides skip. Dependent variables: allow rate, task completion after denial, accuracy of "can I still use it if I refuse," trust scores after the false claim is discovered.

An allow-rate lift that coincides with "refusal still works" is measuring coercion, not effective explanation. A comprehension item should ask, separately, what the next step can still do after Don't Allow. Do not instruct lab participants that they must finish the task; that turns inflated necessity into the experimenter's demand.

Where it stops holding

In payments, clinical, or access-control flows, a capability can be a compliance or physical precondition; saying "this step cannot complete without it" is not inflation. Store-review rules that require a purpose string to name a function are not a license to write optional analytics or marketing as the core feature. An A/B test where "must" copy raises allow rate shows the wording works, not that the dependency is real.

Applying it

• Write an internal verdict for each permission: without it, does the current task fail, degrade, or barely change. Only "fail" may use "need / must" in user-facing copy.
• For degradable permissions, write both sides: "with this you can…; without it…." Do not sell only the on-state.
• Do not disguise optional permissions—especially notifications and contacts—as a launch gate behind a full-screen blocker.
• Verify by force-denying the permission in a test build and walking the main path. If the path still completes while the copy says "must," the copy fails. Then ask the denial group what they thought would happen—if their expected harm is worse than the actual outcome, the copy inflated necessity.

Related

• Within the group: H4.02.1 Explain the purpose before the system dialog · H4.02.2 Name a concrete feature, not a generic purpose
• Adjacent: H4.03 Degradation after Denial · O2.06 Consent Interface Design and Abuse · O1.05 The Usability Dilemma of Informed Consent
• Search terms: inflated necessity · false required permission · coerced consent