Brand Voice and Editorial Style

Naming Convention Register

Standardize product, feature, plan, interface, campaign, and internal names with definitions, ownership, usage rules, dependencies, and retirement plans.

Free editable Markdown · Brand teams, product teams, and technical writers · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Name identity

Register ID: [Durable identifier]
Object: [What is being named?]
Hierarchy: [Portfolio, product, feature, plan, campaign, or internal project]
Definition: [Included and excluded meaning]
Audience: [Who encounters it?]
Status: [Proposed / Approved / Deprecated / Retired]
Name owner: [Role]
Confidentiality: [Public or restricted]

Approved usage

Approved name: [Exact form]
First reference: [Full treatment]
Later reference: [Short form]
Capitalization and spacing: [Rule]
Abbreviation: [Allowed or None]
Plural and possessive: [Forms]
Pronunciation: [If useful]
Do not use: [Variant and reason]
Example sentence: [Correct use]

Checks and language

Adjacent names: [Potential confusion]
Search or URL collision: [Result]
Legal review status: [Owner and date; not a rights claim]
Localization status: [Translate / Retain / Locale-specific review]
Regional concern: [Meaning or pronunciation]

The name does not imply an unsupported capability.
Interface and spoken contexts were considered.
Technical identifiers are distinguished from public labels.

Rollout and lifecycle

Launch date: [YYYY-MM-DD]
Dependencies: [UI, URL, docs, schema, support, assets, analytics]
Migration owners: [Role and due date]
Previous name: [If renamed]
Transition phrase: [Temporary explanation]
Redirect or archive plan: [Action]
Review trigger: [Hierarchy, conflict, confusion, or legal change]

How to use this template

Define the named object, hierarchy, audience, lifecycle, and distinction from adjacent concepts.
Evaluate candidate names for clarity, collisions, connotation, pronunciation, localization, and required clearance.
Record the approved form, grammar, first-reference treatment, exceptions, and owner.
Map launch, technical, content, support, analytics, localization, and redirect dependencies.
Verify rollout, monitor confusion, and execute a documented retirement or rename process when needed.

Name a defined thing

Write the object’s scope, audience, hierarchy, and difference from neighboring objects before proposing a label. Naming debates become circular when one person names a product family and another names a single feature. Record whether the label is public, internal, temporary, legal, technical, or interface-only. Check collisions across products, plans, URLs, abbreviations, analytics, support language, and existing customer vocabulary. A memorable name that obscures what something does can create repeated explanation and search problems.

Specify complete usage

Record exact spelling, capitalization, spacing, punctuation, article use, abbreviation, pronunciation, plural, possessive, and how the name appears on first and later reference. Define prohibited constructions only when there is a reason, such as confusing hierarchy or implying a capability. Include examples in headings, sentences, buttons, and speech. Provide translators the concept, naming status, and translatability decision; leaving a name in English may still require grammar and script guidance. Check that compact interface forms do not collide with another approved name.

Plan launch and retirement together

Map every dependency: interface strings, code-facing identifiers, URLs, metadata, schema, help content, contracts, training, sales assets, localization memory, analytics, and redirects. Decide which technical identifiers remain stable and which public labels change. For renamed items, define a transition phrase, redirect period, support script, and archive treatment. Assign an owner and source of truth. Review after product hierarchy changes, legal conflicts, audience confusion, or acquisition. Preserve effective dates so historic references remain interpretable.

See the fields in context

Fictional example: “Field Notes”

Northwind Survey Kit and its feature names are invented.

Object: A fictional feature for attaching observations to a survey location.
Approved name: “Field Notes”; lowercase “notes” only when referring to generic records.
Collision check: An older help category had the same name and is renamed before launch.
Localization: Translators receive the functional definition and may use a natural local equivalent after review.
Retirement rule: If notes expand beyond locations, the owner must reopen the naming decision rather than stretch the definition.

Frequently asked questions

Is this register a trademark search?

No. It records editorial and operational naming decisions. Use qualified legal processes for clearance and rights questions, and record only their status and owner rather than claiming the register provides protection.

Should internal code names be included?

Include them in a restricted register when they affect migrations or confusion, but clearly separate them from public names. Do not expose confidential launch information through public documentation.

Can a name be translated?

That depends on brand strategy, function, grammar, recognition, and locale. Record the decision by language or region and provide the underlying concept. “Do not translate” still requires localization guidance.

How long should an old name remain visible?

Base transition on audience recognition, support burden, contractual references, links, and risk. Define a review date and removal conditions rather than leaving “formerly” language indefinitely.