O2.02.1Specific purpose noticedesignresearch

Explain a concrete function rather than a generic purpose

Aliases: function-level disclosure · purpose specification · concrete-use notice

What it is

A specific purpose notice explains processing through a function or decision people can observe—“use current location to show nearby pickup stores”—rather than an indefinitely elastic phrase such as improving experience or operations. It should support predictions about which output changes, who uses the data, and whether a new profile results. Specificity is not internal jargon; it translates organizational aims into testable user consequences.

Why it happens

A generic purpose has no stable behavioral boundary, allowing almost any future operation to become optimization or security. Users cannot judge necessity, while engineering and governance teams cannot detect drift. Function-level language establishes a causal input–output mapping that makes a new use appear as a difference. It also supports minimization: a field with no explainable effect on a function is harder to justify.

Studying it

Participants can read alternative notices and classify processing cases, with open responses measuring boundary agreement, omission, and overgeneralization. Materials should include neighboring uses such as navigation, nearby recommendation, and location advertising. Independent teams can also map notice language to flows; substantially different inferred scopes across reviewers indicate insufficient specificity.

Where it stops holding

Fraud and security detection may not reveal complete rules but can still state data class, protective objective, decision type, retention boundary, and appeal. Copy tied too narrowly to one button can conceal continued background work; granularity must cover the actual lifecycle. Examples aid comprehension but one benign example cannot substitute for a broader real purpose.

Applying it

  • Rewrite each purpose as data used to produce an observable result, naming nearby uses that are explicitly excluded.
  • Interrogate abstractions until an output is identifiable; pause or split collection when the owner cannot provide one.
  • Put recipient role, duration, and profiling or decision consequences beside the purpose rather than only in general terms.
  • Ask testers to classify real allowed and disallowed scenarios from the notice, narrowing wording after over-inclusion and reconciling it with runtime flows.

Related

  • Same group: O2.02.2 Put a summary first and make detail expandable · O2.02.3 Explanations must match actual behavior
  • Adjacent: O1.03 Purpose limitation · O2.01 Permission-prompt information design
  • Search terms: specific purpose notice · purpose specification · function-level disclosure

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O2.02.1