Which Customisation Settings Actually Change Anything

Customisable is doing four jobs at once on most feature pages. Some settings change what is drawn, some are text the app reads and loosely follows, some constrain what it will produce, and some only affect the interface on your phone. Only the middle two touch what the app actually says, and both are bounded by limits that are not shown to you.

The useful skill is not configuring these well. It is working out which controls are doing something, which is testable in a few minutes and rarely obvious from the labels.

The four kinds of control

Cosmetic. Appearance, display name, colour scheme, background. Reliable, immediate, and unrelated to behaviour. The visual side has its own considerations in judging an avatar editor before you use one.

Text you write that the app reads. A description field, a list of interests, a few lines of background. These influence output rather than determine it, and the honest way to think about them is as a strong suggestion the app weighs against everything else it is doing. Long entries do not necessarily beat short ones, and contradictions inside the field tend to produce inconsistency rather than a resolved compromise.

Constraints on output. Toggles and sliders for tone, formality, length, topics it will avoid, how much it initiates. These are the settings most likely to have a visible, repeatable effect, because a constraint is easier to implement reliably than an instruction.

Interface settings. Font size, message grouping, sounds, whether replies arrive gradually. Entirely local, entirely dependable, and often the ones that most improve daily use.

Sorting a settings screen into these four categories takes a minute and tells you how much of the advertised customisation is actually about behaviour.

Testing whether a setting works

Compare extremes on the same prompt. Set the control to one end, start a fresh conversation, ask something with a predictable shape. Repeat at the other end. If the two replies are indistinguishable, the setting is either subtle or decorative, and you have no way to tell which — treat it as decorative until shown otherwise.

Check how long the effect lasts. Many behavioural settings hold for a handful of turns and then fade as the conversation grows. This drift is the norm rather than a fault, and it is the single biggest gap between what these controls promise and what they deliver over an evening.

Find out whether it applies retroactively. Some settings affect only messages sent after the change; others reshape the app’s whole approach immediately. Changing a setting mid-conversation and watching the next three replies usually answers this.

Check whether it is global or per-conversation. Apps differ, and an app that keeps settings per conversation will surprise you the first time you start a new one and find the old defaults back.

Read what happens on reset. A control you can turn on and cannot inspect afterwards is a control you will eventually stop trusting.

Your settings sit inside limits you did not set

This is the part that most needs saying plainly, because it explains nearly every case of a setting appearing not to work.

The operator’s own rules run underneath everything you configure and take precedence over it. Where those rules and your settings disagree, the rules win, and the app is not obliged to tell you that is what happened — the usual experience is a reply that quietly ignores a preference you set, with no message explaining why.

Beyond that, the set of available controls is itself unstable. Settings get added, renamed, merged, and removed; defaults change with releases; a control you relied on may be absent after an update, with your previous choice silently mapped onto something else. The general shape of that problem is what an app update can change without asking.

So a claim of extensive customisation is a claim about the current surface area of a settings screen, not a commitment about it. Judge how well the controls that exist behave rather than how many there are.

Settings and remembered things are not the same

A frequent confusion, and worth separating. Something you configured in a settings screen is a stored preference the app applies. Something you mentioned in conversation is retained material, subject to entirely different limits, caps, and failure modes — the ones set out in what memory means when a companion app claims it.

The practical consequence: if a preference matters to you, put it in the settings screen if the settings screen offers it. Mentioning it in conversation is the less durable of the two options by a wide margin.

What to compare between apps

Not the length of the options list. Four things instead: whether the settings are visible in one place rather than scattered, whether they are documented in any form, whether changes have an effect you can observe, and whether they persist across conversations and updates.

An app with six controls that behave predictably is more configurable, in the sense that matters, than an app with forty whose effects you cannot detect.

Where this stops being knowable

You cannot see how a setting is implemented, how strongly it is weighted, or what overrides it. When a preference is ignored, the reasons — a rule taking precedence, drift over a long conversation, a control that was never wired to much — are indistinguishable from the outside, and no amount of testing separates them.

What testing does establish is whether a control has a repeatable effect on the output you get. That is a smaller claim than understanding the app, and it is enough to stop you choosing between products on the strength of a settings screen that turns out to be mostly decoration.