User Preferences

Defining Preferences

A preference is something each user sets for themselves.

Where to find it

Architect Panel → Configuration:

• Custom User Preferences — the preferences you define

What makes a good preference

• It genuinely varies by person, with no right answer.
• The user knows their own answer better than you do.
• It affects only them.
• A wrong choice is easily reversed.

What should not be one

• Anything with a right answer. If one setting is correct, set it — do not make everybody decide.
• Anything affecting other people or shared data.
• Anything security-relevant. A preference is a user-editable value; it must never gate access.
• A workaround for a design problem. Offering "compact view" because the default is too cramped fixes it for the few who find the setting.

Every preference is a decision you hand over

The cost people underestimate. A preferences screen with twenty settings asks every user to make twenty decisions about software they wanted to use rather than configure.

Most will change none, so most of that screen is doing nothing except making the settings that matter harder to find.

The default is the real design decision

Because nearly everybody keeps it. A preference with a poor default is a bad experience for the great majority and a setting the minority found — so effort spent on the default is worth more than effort spent on the option.

If you are unsure what the default should be, that uncertainty is not resolved by making it configurable.

Name them for what they do

In the user's language, describing the effect rather than the mechanism. "Show more rows per page" is a preference somebody can act on; "Pagination mode" is not.

Group and order them

A flat list of unrelated settings is hard to scan. Group by area and put the ones people actually change near the top.

Preferences are personal data

Modest, and still information about an individual. Include them in retention and in what you disclose on request.

Worked example

An organisation offers six preferences — rows per page, default landing screen, notification channel, date format, theme and language. Each genuinely varies by person. A proposed "show advanced fields" preference was rejected: the real problem was that the form showed too much, which was fixed for everybody instead.

Recommendations

• Only where there is genuinely no right answer.
• Spend the effort on the default.
• Never let a preference affect access.
• Fix the design rather than offering a setting around it.

Defaults

The default is what a preference is set to for somebody who has never touched it — which is most people.

Where to find it

Architect Panel → Configuration:

• Custom User Preferences — preferences and their defaults

Almost nobody changes a default

Consistently, across every kind of software. The proportion who open a preferences screen at all is small, and most of those change one thing.

So the default is not a fallback — it is the setting for the overwhelming majority of your users, and it deserves the attention you would give a design decision rather than a configuration value.

Choose for the common case

Not for the power user, not for yourself. The person you are designing the default for is somebody who will never see the preference screen and does not know the option exists.

Default to the safer option

Where a preference has any privacy or disclosure dimension, default to the more conservative setting and let people opt into the other. Somebody who never made a choice should not be treated as having consented to the more exposing one.

Watch what people change

The most useful signal you have. If a meaningful proportion change the same preference to the same value, your default is wrong — change it, and their explicit choice is preserved anyway.

Nobody will report a bad default, because it does not look like a fault. They will just work around it or accept it.

Changing a default afterwards

The subtlety worth understanding: it affects people who never chose, and it should not disturb people who did.

If changing a default overwrites an explicit choice, you have overridden a decision somebody made deliberately — which is worse than a poor default, because they will notice and will not know why it changed back.

Tell people if it is visible

A default that changes how the application looks or behaves will be noticed. A brief note prevents support calls from people who think something is broken.

Do not use defaults to force behaviour

If everybody should have a setting, do not make it a preference defaulted to your preference — set it. A preference implies a genuine choice, and using it as a soft mandate is dishonest and produces a setting people flip back.

Worked example

An organisation reviews preference usage after six months. Rows per page had been defaulted to 20; 40% of users had changed it to 50. The default became 50, leaving explicit choices untouched, and complaints about paging stopped.

Recommendations

• Treat the default as the design decision.
• Default to the conservative option where privacy is involved.
• Review what people change — nobody reports a bad default.
• Never overwrite an explicit choice.