Product and UX Content
Settings Label Inventory
Standardize setting names, descriptions, defaults, dependencies, consequences, search terms, accessibility, localization, and help references.
Free editable Markdown · Content designers, product teams, and localization teams ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Setting record
- Setting ID and current path
- [Enter]
- Behavior controlled
- [Describe]
- Scope
- [User / Workspace / Item / Device / Other]
- Roles allowed to change
- [Enter]
- Current default and source
- [Enter]
- When change applies
- [Immediate / Next session / Other]
- Reversible
- [Yes / No / Conditions]
- Owner and release
- [Enter]
Content
- Proposed label
- [Write]
- Current-state expression
- [Enter]
- Description or help
- [Write]
- Required warning
- [Enter or None]
- Confirmation copy
- [Enter or None]
- Product term and definition
- [Enter]
- Search synonyms
- [List]
- Help destination
- [Verified route]
Dependency and exception
- Required plan or permission
- [Enter]
- Parent or inherited policy
- [Enter]
- Dependent settings
- [List]
- Unavailable/disabled reason
- [Message]
- Privacy, security, cost, or sharing impact
- [Describe]
- Migration from old label
- [Enter]
- Deprecation behavior
- [Enter]
- Support escalation
- [Enter]
QA and governance
- Terminology approver
- [Name/date]
- Tested build and roles
- [Enter]
- Update trigger
- [Behavior/default/plan/permission]
- Label, state, and description are meaningful to assistive technology.
- Product, help, notification, and support terms agree.
- Default and consequence are accurate.
- Dependency, role, and inherited states were tested.
- Localization has context, screenshots, and sufficient layout.
How to use this template
- Inventory every setting's behavior, scope, owner, default, permission, dependency, and consequence.
- Compare labels and terms across product, help, notifications, APIs, and support.
- Draft consistent names, descriptions, search synonyms, warnings, and help links.
- Review accessibility, localization, inherited state, responsive layout, and live behavior.
- Approve a controlled vocabulary and maintain it through releases and deprecations.
Record behavior before naming
For every setting, identify what changes, which object or account it affects, who can change it, its default, whether it applies immediately, and whether it can be reversed. Document dependencies, plan or region limits, inherited organization policy, and states where the control is unavailable. A toggle label that says “Private” may be ambiguous about whether on means private or sharing is enabled. Prefer a label that describes the controlled behavior and pair it with current status where needed. Work with product and engineering so copy reflects system truth rather than historical naming.
Build consistent terms and grouping
Compare setting labels with navigation, forms, notifications, help, release notes, APIs, and support language. Choose one term per concept and record permitted synonyms for search, not for visible inconsistency. Group settings by user goal and consequence, not the team that implemented them. Use descriptions for important scope, prerequisites, and impact; do not overload labels with entire policies. Make dangerous or irreversible changes visibly distinct and provide confirmation or review where appropriate. Defaults should be communicated when they affect privacy, cost, communication, or shared work.
Prepare settings for access and localization
Record grammatical context, variable behavior, character constraints, and screenshots for translators. Avoid labels formed only by a noun beside an unlabeled switch; assistive technology needs a meaningful name, role, state, and description. Test keyboard, focus, zoom, search, deep links, dependency changes, inherited states, and permission differences. Provide help for complex choices and ensure it matches the released version. Give each setting an owner and deprecation plan so old labels and links do not survive after behavior changes.
See the fields in context
Fictional example: link access setting
ShareFern and its access behavior are invented and are not GPTHuman settings.
- Ambiguous label: “Public” beside a switch, with no explanation of the on state.
- Behavior: The fictional control lets anyone with a link view one document; it does not make it searchable.
- Revision: Label the action “Allow anyone with the link to view” and show current status.
- Dependency: Workspace policy may disable the control, and the message names the admin route without exposing private details.
- QA: Test owner, viewer, inherited-policy, and long localized labels.
Frequently asked questions
Should toggle labels describe the on state?
Use wording that keeps the controlled behavior and current state clear in context, including for assistive technology.
Where should detailed consequences appear?
Near the control before action when they affect privacy, cost, sharing, access, or irreversibility, with deeper help linked as needed.
Can different teams use different names for the same setting?
Avoid visible inconsistency. Maintain an approved term and use synonyms only for discovery or migration where appropriate.
How often should the inventory be reviewed?
On behavior, default, permission, plan, navigation, localization, or deprecation changes and at a scheduled product review.