Settings pages describe what is possible. Defaults describe what happens. Since almost nobody changes a default, the default is the operative policy of a system regardless of what any document says — which makes choosing defaults the most consequential design decision most teams make without noticing.
The observation
Almost nobody changes a default.
Not through apathy. Changing one requires knowing the setting exists, believing it matters, finding it, and understanding what the alternative does. Each step removes most of the remaining people, and four filters in sequence leave very few.
Which means the people who do change settings are not a sample of the users. They are a sample of the people for whom all four steps happened to succeed, and designing around their behaviour tells you nothing about what the system does in aggregate.
Therefore the default is the policy
If a document says data is shared when a user opts in, and the setting ships enabled, then the policy is that data is shared. The document is describing the exception.
This is not an accusation aimed at any particular product. It is how settings behave everywhere, including in software written by people who care. The document is accurate and the default is operative, and the gap between them is filled entirely by inertia.
Where defaults are chosen
Usually in a hurry, by whoever implemented the feature, while thinking about whether the feature works.
That is the uncomfortable part. A default is rarely the output of a deliberation. Nobody convened to decide that telemetry ships enabled; somebody needed to see whether the telemetry worked, and the value that made development easier became the value that governs everybody.
Which is why defaults so often diverge from what the same team would choose if asked the question directly. They were never asked the question directly. They were asked whether the build passed.
Four defaults that decide a system's character
What is collected without asking.
What is shared without asking.
How long things are kept without a decision.
What is visible to others without a choice.
Those four together describe a product's values more accurately than any page headed values, because they are what happens rather than what is intended — and they are readable from outside by anyone who cares to look.
Opt-in and opt-out are not two ways of asking the same question
They produce different populations and a different meaning of agreement.
Opt-out collects from everybody who did not object: those who did not see the question, did not understand it, meant to return to it, or could not find the control. Opt-in collects from those who affirmatively wanted it.
The choice between them is usually discussed as a matter of friction, and it is actually a matter of who is counted as having agreed. One treats silence as yes, the other treats silence as no, and almost everybody is silent.
The test for a team
If the default were reversed, would this still be worth building?
If the answer is no, the feature depends on people not choosing. That is worth knowing before shipping rather than after, and it is a question with an honest answer available in about a minute.
Why this is good news
Because defaults carry that much weight, changing one is the cheapest large intervention available. No education campaign, no new technology, no persuading anybody. One decision, applied to everybody, taking effect immediately.
It is also the change most likely to be resisted, for exactly the same reason: it moves the aggregate, and the aggregate is what the numbers are made of. The resistance is a reasonably good indicator that you have found the real policy.
Close
Read a system's defaults before its documentation. One of them describes what will happen to you, and it is not the one written in prose.