L6.10.1inspectability as reset prerequisitedesignresearch

Being able to see the profile is a prerequisite of being able to reset it

Aliases: see then reset · cannot correct the unseen · inspect before reset

What it is

Settings offer a large red “reset personalization,” and the profile is nowhere to be seen. The user does not know what will be cleared, whether it should be, or what will remain. Inspectability as reset prerequisite means a correction is conditioned on seeing its object — an unseen state cannot be changed with aim, only blindly pressed.

That inspect and reset must exist as a pair is the previous group’s claim. What is nailed here is order: seeing comes first, or reset is a lottery.

Why it happens

Correction is propositional: deny P. When P is invisible, people do not know which sentence to deny, and can only choose “destroy everything” or “touch nothing.” The first collaterally damages parts they still use; the second leaves bad features alive. The button then looks like control and actually downgrades the decision from “change which part” to “whether to gamble.”

If the profile shows only explicit ticks and hides behavioural counts and inferred tags, what is seen is not the set that will be reset. The prerequisite requires that the visible set cover the set that will be rewritten, or the order holds only on the surface: people see A and clear B.

Studying it

Contrast: inspect a complete profile then reset; reset with nothing to see; see an incomplete layer. Task: clear one specific wrong class, keep the rest. Dependent variables: whether people can name what will be touched, collateral damage, later regret. Independent variables: which layer is visible (ticks / counts / inferences), whether reset is global or per item.

If the inspect-first group completes more often with less collateral damage, the prerequisite holds in behaviour. Do not count “they found the button” as success — finding a blind button is not seeing.

Where it stops holding

When the user explicitly asks to “forget me entirely,” a global reset can run without a close reading, but the categories that will be lost should still be listed first — that is the next layer’s cost disclosure. Records the law requires kept are not in the preference profile; not seeing them is not a violation of the prerequisite. This entry only argues that correction is conditioned on seeing. It does not treat whether the post-off default is an editorial arrangement, and it does not treat inference from context after off.

Applying it

  • The reset entry must be walked into from the profile page, not parked as a lone master button in a settings list with no object. List the classes and seeds that will be touched first.
  • Align the visible list with the fields that will actually clear. Behavioural counts and inferred tags must not live only under “advanced.”
  • Check: have one group reset without seeing the profile, another inspect then clear by item. The first should be unable to say what they changed; the second should be able to point at a class. If the groups do not differ, inspectability has not yet become a prerequisite.

Related

  • Same group: L6.10.2 Reset has to say what will be lost, or users will not touch it · L6.10.3 The default ranking after personalization is off is still an editorial choice and must be intelligible · L6.10.4 Deleting one record and resetting everything solve different problems and both must exist · L6.10.5 Still inferring from the current context after personalization is off is undeclared personalization
  • Nearby: L6.05 Turning Personalization Off · L6.06 Inferred Preferences and Their Limits · L6.07 Presenting Recommendation Reasons
  • Search terms: inspectability as reset prerequisite · see then reset · correcting the unseen

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L6.10.1