Most Revit projects that become slow, unstable, or difficult to schedule did not get that way through modeling volume. They got that way through content. A single badly built family, loaded across a hundred instances, can add more to file size and regeneration time than an entire building level of well-constructed geometry.
Family creation is therefore not a peripheral task. It is a structural decision about how the model will behave for the rest of the project.
What a good family does
A well-built family satisfies four requirements simultaneously.
It schedules correctly. The parameters a quantity surveyor, estimator, or facilities team needs are present, correctly typed, and populated — not embedded in the family name.
It flexes without breaking. Changing a type parameter produces the expected geometry at every size within the intended range, with no constraint errors.
It is light. Geometry is modeled at the coarsest resolution that serves the purpose, with detail level controls hiding complexity in coarse and medium views.
It behaves correctly in context. Hosting, cut behavior, room calculation point, and material assignment all respond as a user would expect.
Content that fails any one of these will eventually be worked around by users, and workarounds are where model integrity is lost.
Start with the right template
Family template choice is effectively irreversible; converting between categories later ranges from awkward to impossible. Choose the category that matches how the element must be scheduled, tagged, and filtered — not the one that is geometrically convenient.
A recurring error is modeling equipment as a generic model because the correct category template was inconvenient. The result is content that cannot be scheduled with its peers, does not respond to category-based view filters, and will be rebuilt later.
Similarly, decide host behavior deliberately: face-based, wall-hosted, or unhosted. Wall-hosted content is elegant until the wall is deleted and every instance disappears. Face-based content is more resilient in most workflows.
Build the skeleton before the geometry
The most common structural mistake in family authoring is modeling geometry first and adding parameters afterwards. The correct sequence is the reverse.
- Place reference planes, name them, and set the appropriate ones to strong reference so they can be dimensioned in the project.
- Dimension between reference planes and apply labeled parameters to those dimensions.
- Flex the parameters through their full intended range before any solid exists. If the skeleton fails here, it will fail with geometry attached and be far harder to diagnose.
- Model geometry constrained to the reference planes — locking each sketch line to a plane rather than to another solid.
- Flex again.
Families built in this order almost never produce the "constraints are not satisfied" errors that plague content built geometry-first.
Parameter discipline
Type versus instance. A parameter is type if it defines a purchasable variant, instance if it varies per placement. Getting this wrong forces users to create dozens of types for what should be a single flexible one, or the reverse.
Shared parameters for anything scheduled or tagged. Family parameters cannot be scheduled across families or tagged. Any parameter that must appear in a schedule or on a tag has to come from a managed shared parameter file. That file should be controlled centrally, version-tracked, and never edited casually — GUIDs, not names, define identity.
Correct data types. Length, area, and number are not interchangeable with text. A dimension stored as text cannot be totaled, filtered numerically, or unit-converted. This is the single most common cause of unusable schedules.
Formulas over manual entry. Where one parameter is derived from another, drive it with a formula and lock it. Derived values entered manually will diverge.
Keep geometry light
Practical rules that reduce file size and improve performance:
- Model at the level of development required, not the level available from the manufacturer's CAD file.
- Never import a manufacturer's DWG or STEP solid directly into a family for anything placed repeatedly. Imported geometry carries far more surface data than a native equivalent and cannot be controlled by detail level.
- Use visibility settings by detail level: simplified geometry in coarse, full geometry in fine only.
- Avoid voids where a modified solid sketch would do; voids are computationally more expensive.
- Use nested families deliberately. Shared nested families schedule independently, which is valuable for components inside assemblies; non-shared nesting keeps the schedule clean. Choose consciously.
- Purge unused subcategories, materials, and nested content before saving.
A useful benchmark: most architectural and MEP component families should be well under 1 MB. Content in the multi-megabyte range almost always contains imported geometry or unnecessary detail.
Subcategories and materials
Every solid should sit in a named subcategory so line weight, color, and visibility can be controlled per view. Content built entirely in the default category subcategory cannot be graphically managed and forces users into overrides.
Materials should be assigned by parameter, not hard-coded, so the project can control appearance and so material takeoffs reflect actual specification.
Library management
Individual family quality matters less than library governance over the life of a firm.
- A single source of truth. One managed library location, with project folders holding only project-specific content.
- Naming convention. Category, description, and variant, applied consistently. Names carry no data, so keep information in parameters and reserve names for findability.
- Version control. A change log recording what changed and when, because content updates propagate to every future project.
- A gate for new content. A short checklist — correct template, flexes, schedules, subcategories, file size, purge — applied before anything enters the library.
Firms that skip governance accumulate multiple near-identical families, which is how schedules become impossible to reconcile.
When to build custom versus adapt
Manufacturer content is worth using when it is well built and the specification is fixed. It is worth rebuilding when it is imported geometry, when it lacks the parameters you schedule on, or when it will be placed at high volume. A short audit — open it, check file size, check parameters, flex it — takes two minutes and prevents a great deal of downstream cost.
Auditing an existing library
Most firms inherit a library rather than design one, and an audit is usually more valuable than new content. A practical audit sequence:
1. Inventory by size. Sort every family by file size. The largest twenty will account for a disproportionate share of every project's weight, and they are almost always imported geometry.
2. Check category assignment. List anything in generic models that should be in a proper category. These are the families that break schedules.
3. Test parameter integrity. For each family, confirm scheduled parameters are shared rather than family parameters, and that dimensional data is stored as length rather than text.
4. Flex the top fifty. The content used most often should be flexed through its full range. Constraint errors that appear here are appearing on every project.
5. Identify duplicates. Near-identical families under different names are the reason schedules cannot be reconciled. Consolidate to one, and record the mapping.
6. Check subcategories and materials. Content with no subcategories cannot be graphically controlled; content with hard-coded materials cannot be specified.
An audit of a mid-size library typically finds that a small proportion of content causes most of the problems, which makes remediation tractable. Fixing thirty families is a week of work; replacing a library is a quarter.
A checklist for accepting new content
Whether built internally or received from a manufacturer or a partner, content should pass a fixed gate before entering the library:
- Correct category template and host behaviour
- Reference plane skeleton present, named, with strong references set
- Flexes through full intended range without error
- Type and instance parameters correctly assigned
- Scheduled and tagged parameters are shared parameters from the managed file
- Dimensional data stored as length, not text
- All solids assigned to named subcategories
- Materials by parameter, not hard-coded
- Detail level visibility configured
- No imported geometry
- Purged and audited; file size proportionate
- Named to the firm convention
Applying this consistently is what keeps a library usable at the five-year mark rather than at the five-month mark.
Frequently asked questions
How long should a family take to build? A straightforward parametric component with a handful of parameters typically takes one to three hours including flexing and QA. Complex assemblies with nested shared components and multiple detail levels take considerably longer.
Can families be created from manufacturer specifications alone? Yes. A dimensioned cut sheet and a parameter schedule are sufficient input for most component families.
Should families be built in the project or in the family editor? Always the family editor. In-place families cannot be reused, bloat the file, and are a recurring source of performance problems.
Related reading: BIM Outsourcing: A Practical Guide for AEC Firms · LOD 100 to LOD 500 Explained: A Practical Reference · CAD Layer Standards: AIA, BS 1192 and ISO 19650 Compared
Vantage CAD Services builds and audits parametric Revit content libraries to firm standards, including shared parameter management. Contact info@vantagecadservices.com or +1 (512) 543-0831.