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.