Naming breaks when the convention isn’t designed for day-to-day realities:

• People search differently. Some search by category (“Door”), others by performance (“Fire Rated”), others by type (“DDA compliant”).
• Libraries scale faster than governance. What works for 50 families collapses at 5,000.
• Inconsistency kills automation. Anything you want to batch-rename, schedule, tag, or audit needs predictable structure.

Autodesk’s family content style guidance (and broader best-practice ecosystems) treat naming as foundational because it directly impacts reusability and performance across projects. 

Before you decide what goes into the name, lock your syntax.

A safe, widely-used rule set:

• Use A–Z / 0–9 / underscore / hyphen only
• Avoid special characters and inconsistent spacing
• Reserve separators for meaning (don’t use hyphens for “style” if you also use hyphens for “segments”)

Many BIM content guides recommend restricting characters and enforcing consistent separators to keep libraries portable and prevent issues with systems, exports, and audits.

Recommended separators

• Use underscore _ for segment breaks in family names (human-readable + script-friendly)
• Use “ - ” (space hyphen space) inside Type Names only if your office prefers readability over strict machine parsing (otherwise keep it underscore everywhere)

Type names are where most teams get chaotic: sizes, materials, ratings, and options get mixed randomly.

Type Name Formula

[Size]_[Material/Finish]_[Performance]_[Option]

Keep it consistent, and don’t include what you can schedule from parameters.

Examples

• Door Type: 0900x2100_PaintGrade_FD60_Acoustic
• Window Type: 1500x1200_Alu_Thermal_UValue1p4
• Furniture Type: 1600x800_Laminate_CableTray_YES

Pro tip: if a parameter already exists (e.g., Fire Rating), don’t duplicate it in the name unless your team depends on name-based search. Duplicate data increases drift.

If you have many types, consider a Type Catalog workflow so the same family can be loaded with consistent type definitions. Autodesk specifically documents type catalogs as a method for managing families with many types. 

A lot of people try to cram classification into the name. That usually makes names unreadable.

Better approach:

• Keep the name human-friendly
• Store classification in built-in parameters



Revit supports classification systems like OmniClass and UniClass/Uniclass, and Autodesk explains how these classifications help organize information about building elements.

Key idea:

• Use OmniClass Table 23 (Products) or your regional classification system as data, not as part of the visible name.
• Revit’s OmniClass parameters at family level (Number/Title) are a standard way to assign Table 23 classifications.

If you’re operating in UK-aligned standards or clients request it, Uniclass is widely used as a unified classification system and is updated regularly. 

Families “feel” messy because parameters are messy.

Rules that keep parameter naming clean:

• Use full words: Width, Height, Leaf_Thickness (not W, H, Thk)
• Prefix shared parameters by domain: ID_, PERF_, MAT_, MFG_ (optional but powerful)
• Never create duplicate parameters with near-identical meaning

This aligns with the broader Revit content guidance ethos: standardization in naming and parameters is what allows consistent scheduling and automation.

Putting v3, final_FINAL, or dates into names is how libraries rot.

Instead:

• Use a Content Register (spreadsheet/Notion) with version tracking
• Store “Last Updated” as metadata (outside Revit) or in a shared parameter if required
• Use controlled publishing (e.g., “Approved” folder vs “WIP” folder)

This also keeps your families stable when you migrate projects or audit historical models.

If your standard can’t fit on one page, adoption collapses.

Your one-page rules

1. Family Name = Category_Function_Descriptor_Host_Std
2. Type Name = Size_Material_Performance_Option
3. No special characters; consistent separators
4. Classification goes in parameters, not names
5. No versions in names

This is the kind of standard that survives new hires, freelancers, and multi-office teams.

Before any family becomes “official,” check:

• Does the family name start with the correct Category?
• Are type names consistent and predictable?
• Are key parameters filled (Fire rating, material, manufacturer, identity data)?
• Does it carry the right classification in the right parameter fields?
• If there are many types, should it use a type catalog?
• Does it load cleanly without warnings and unnecessary nested bloat?

If you want, I can turn this naming convention into a copy-paste office standard:

• a one-page PDF guideline
• a “family naming generator” table (Category + Function + Descriptor dropdowns)
• and a library audit checklist you can run before every release

That’s how you stop arguing about naming and start shipping clean BIM content.