Setting names should describe effects, not just jargon

What it is

An option's name decides whether a player can judge "does this help me?": technical names ("TAA anti-aliasing," "motion blur Q8," "chromatic aberration correction") presuppose graphics knowledge, while effect names ("smoothing for screen-edge blur," "reduces blur during fast movement") let anyone infer the changed experience from the name itself. Effect-describing names are a necessity in accessibility contexts—players needing support often don't know the support's technical name; they search from their problem (can't read text, can't keep up with reactions), and only effect-named options match those problems.

Why it happens

Naming affects discovery through matching between search terms and option names. A player seeking support starts from symptoms ("text too small," "camera movement makes me dizzy," "can't hear dialogue"), and if option names are technical ("subtitle render scale," "camera velocity damping," "dialogue dynamic range compression"), matching symptom to option demands a translation ("can't read" → "render scale")—failed translation means the player walks past the option. Effect names carry symptom language directly ("subtitle size," "camera movement speed," "dialogue volume boost") with zero translation. A supporting layer (description text under each option) adds second-level explanation: names stay short (menu width constraints) while descriptions supply detail ("when enabled, screen edges darken during fast movement to reduce dizziness"); the two-layer structure (short name + effect description) balances menu efficiency and full understanding. Technical terms are not banned—attaching the technical name in parentheses after the effect name serves both searching (experts search by term) and comprehension (everyone else by effect).

Where it stops holding

Effect naming does not mean excluding terminology—jargon is the community's lingua franca ("FOV" is more recognisable to players than "field of view size"), and total de-jargonising leaves advanced users without their anchors. The balance is "effect name primary, term secondary" ("Field of view (FOV)"): menus lead with effects, community documents with terms. The length-versus-clarity conflict (menu width) resolves with the two-tier structure (short name + hover/expanded description) rather than compressing names into nonsense. Localisation doubles the naming problem: effect names' translation quality directly decides non-English usability; machine-translated technical names are already hard, and translated effect names can drift further from meaning ("motion blur" rendered as "dynamic motion blur degree" becomes harder still)—localisation review must include "does the translated name still let someone infer the effect?" Search usability also rides on naming: effect names plus symptom-word aliases (searching "dizzy" matches view and shake options) upgrade search from term matching to need matching.

Applying it

• Establish a settings naming spec: effect first (the name states the resulting experience), terms annotated (common technical names kept in parentheses), and symptom aliases configured for search.
• Give every option a one-line effect description (what changes, who it suits), reviewed alongside localisation.
• Verification: have testers unfamiliar with graphics/audio jargon complete goal configurations ("reduce screen sickness," "make dialogue clearer") using only the settings interface. Completion rates and time reflect the naming's self-explanation; unachievable goals get renamed or re-described.

Related

• Same group: W8.08.1 Accessibility settings need one centralised hub, not scattered menus · W8.08.2 First launch should surface accessibility options · W8.08.4 Buried options make players believe the game lacks support
• Nearby: T1.01 Functional layering of UI copy · S1.01 UI copy localisation · W8.08 Discoverability of accessibility settings
• Search terms: plain language · settings naming · UX writing · option labels