Users must be able to inspect and reset their preference profile
Aliases: preference dashboard · view and reset · profile transparency
What it is
If personalization lives only in model weights, the user faces a fate they cannot point at. An inspect-and-reset profile is a pair of capabilities: seeing what the system currently takes as “me,” and being able to clear or rewrite that “me.” Missing either piece, personalization cannot be treated as a negotiable setting.
Inspect is not a paragraph in the privacy policy. Reset is not delete-account. Both are in-product actions.
Why it happens
People can only decide about a state they can see. When the profile is invisible, off, correct, and complain have no object, and autonomy collapses to “keep using or leave.” Visibility turns state into an interface object; reset makes the object reversible. They have to arrive as a pair: see-without-change is theatrical transparency; change-without-seeing is a blind switch — the user does not know what they turned off.
Profiles mix explicit ticks, behavioural counts, and inferred labels. If inspect shows only one layer, reset will miss: the user clears a label and the counts still drive ranking. The paired capabilities require that the set you can see and the set you can clear line up, or the action is fake.
Inspect as a prerequisite of reset, and reset having to name what you lose, are finer operational layers. Here the demand is that both capabilities exist in the product and are reachable.
Studying it
Give one group full inspect-and-reset, one group a personalization-off switch with no profile, one group nothing. Task: find why the system keeps pushing a class, and get that class out of future lists. Dependent variables: whether people can name the current basis, task completion, whether the list actually changes afterwards. Independent variables: profile grain (categories vs single records), whether reset is immediate or “takes effect in twenty-four hours.”
If the list does not change after reset, the capability exists only in settings copy. The endpoint is behavioural reversibility, not the presence of a button.
Where it stops holding
A pure timeline or pure search product with no personalization does not need a profile pane. Records the law requires kept (orders, payments) must not be erasable by “reset preferences”; the pane should keep them outside preference. Reset on a shared account hurts others and needs account-level, not device-level, confirmation. This entry argues that inspect and reset must exist as a pair. It does not treat what the default ranking looks like after off, and it does not treat the autonomy loss when there is no off at all.
Applying it
- Put a “what the system thinks you like” page in settings, listing the classes or seeds that currently drive ranking, each editable or deletable, with a whole-page reset at the foot.
- Reset must hit the next screen immediately, not only an “we received that” toast. If the next screen is unchanged, people will judge the button dead.
- Check: give someone new to the product five minutes to find the profile and clear one class, then refresh home. That class should drop. If they cannot find it, or clearing does nothing, the pair has not landed.
Related
- Same group: L6.05.2 Turning personalization off must land on an understandable default ranking · L6.05.3 Personalization that cannot be turned off undermines autonomy
- Nearby: L6.10 Turning Personalization Off and Resetting It · L6.06 Inferred Preferences and Their Limits · L6.07 Presenting Recommendation Reasons
- Search terms:
inspect-and-reset profile·preference dashboard·profile transparency