Every Revit tutorial mentions families within the first ten minutes, and almost none of them stop to explain what a family actually is or why the distinction matters. That gap shows up later, usually as a wall: a modeler who can place a door but cannot build one, or fix one that behaves strangely on site.
Families are not a side topic in Revit, they are the material Revit is made of. Walls, doors, furniture, dimensions, even the levels and grids running through a project are all families under the hood. Understanding how they work is the single biggest jump between "can draw in Revit" and "can work in Revit."
What Is a Family, Really?
A family is a container of geometry plus data: shape, dimensions, materials, and any custom information a project needs, bundled into one reusable definition. Place ten instances of the same door family in a model, and you have ten copies of one definition, not ten separate objects - change something on the family, and every instance that shares it updates at once. That behavior is exactly what makes Revit a database with a 3D view attached rather than a drawing program, and it is the same mechanism this site's "What Is BIM?" guide describes at the methodology level: a family is where that idea actually lives in the software.
The Three Kinds of Families
Every element in a Revit project belongs to one of three family categories, and the difference between them matters far more than most beginners assume.
System families are built into Revit itself: walls, floors, roofs, ceilings, stairs, and project settings like levels and grids. You cannot save a system family out to its own file or load one in from somewhere else - you can only duplicate an existing type inside a project and edit its parameters. This is by design: these are the elements Revit needs deep, native control over to keep the model consistent.
Loadable families live in external .rfa files and get loaded into a project as needed: doors, windows, furniture, casework, fixtures, planting, and most of the "purchased and installed" content in a building. This is where almost all custom family-building work happens, and where a company's content library lives.
In-place families are built directly inside a single project for a one-off piece of geometry - an unusual reception desk, a sculptural stair, a custom soffit that will never repeat anywhere else. In-place families are useful, but they are also the most misused tool in Revit: every in-place family lives only in that project (it cannot be reused, scheduled cleanly across projects, or shared through a library), and heavy in-place use is one of the most common reasons a model becomes slow and hard to coordinate. The rule of thumb worth internalizing early: if a piece of geometry might repeat, or needs to show up in a schedule with real data, it almost always belongs in a loadable family instead.
Inside the Family Editor
Loadable and in-place families are both built in the Family Editor, a separate authoring environment from the main project. A few concepts carry most of the weight there:
- Family category - determines how the family behaves and schedules (a door family must be a Doors category to host in a wall opening and appear on a door schedule). Chosen when you start from a family template, and it should not be changed casually later.
- Reference planes and reference lines - the invisible scaffolding that geometry locks to. Building this scaffolding correctly before drawing geometry is what makes a family flex correctly when its parameters change; skipping straight to geometry is the single most common cause of a family that breaks when resized.
- Family types - the set of named variations a single family offers (a door family might have Type "36x84" and "30x80"), each with its own parameter values, all sharing one underlying geometric definition.
- Visibility settings - controlling whether parts of the geometry show up in plan, in 3D, or at coarse versus fine detail levels, so a family looks appropriate at every scale instead of cluttering a small-scale plan with fixture details.
Parameters: Type vs. Instance
Parameters are what make a family more than static geometry, and getting the type/instance choice right is the most consequential decision in building one.
A type parameter applies to every instance of that family type at once - change it on one door of "Type 36x84," and every door of that type in the project updates. An instance parameter applies only to the one copy you are editing, letting each placed instance vary independently (a door's swing direction, or a piece of furniture's rotation, are natural instance parameters; the door's frame width almost always is not).
As a general rule, default to type parameters - they give more control over consistency and can be linked together with formulas. Reach for an instance parameter only when individual copies genuinely need to vary. One real constraint to plan around: formulas can only link type parameters to other type parameters, and instance parameters to other instance parameters - mixing the two inside a formula does not work, so the type/instance decision has to be made before you start writing formulas, not after.
Shared parameters solve a different problem: a parameter defined once in a shared parameter file (a plain text file most firms keep under version control) that any family or project can reuse, guaranteeing the same underlying parameter, not just the same name, across a whole company's content library. This matters because only shared parameters can be both tagged and scheduled - a parameter that only lives inside one family, with no shared-parameter definition behind it, cannot be pulled into a project-wide schedule or tag. Anyone building content meant to be reused across projects should be defining parameters as shared from day one, not retrofitting it later.
Nested Families and Type Catalogs
Complex families are often built from simpler ones nested inside them - a door family nested with a separate door-hardware family, so hardware can be swapped without rebuilding the whole door. Nesting keeps each piece manageable and lets shared components (a hinge, a handle, a light fixture inside a furniture family) live and update in one place.
For families that ship with dozens or hundreds of size and configuration variants - a manufacturer's full catalog of one product line, for instance - a type catalog (a companion text file listing every type's parameter values) lets a user load only the specific types a project actually needs instead of every variant at once, keeping the project file leaner.
Beyond Standard Families: Adaptive Components
For genuinely non-standard geometry - a faceted canopy, a parametric facade panel that needs to twist and stretch along a curved surface - Revit's standard family framework runs out of flexibility. Adaptive components are a more advanced family type built around adaptive points that can attach to a host surface or path and drive geometry procedurally, closer to true parametric/computational design than a standard rigid family. They are a deliberately more advanced tool, worth learning once standard family-building is second nature, not before.
Building a Family the Right Way
A few habits separate a family that behaves predictably from one that breaks the first time someone resizes it:
- Start from the correct family template. The template sets the category and default reference planes - starting from the wrong one (a generic model template for something that should be a proper door family, for example) causes problems that surface much later.
- Build the reference plane and parameter scaffolding before any geometry. Lock dimensions to reference planes, name every plane and parameter clearly, and only then start modeling.
- Flex the family constantly while building it. Change every parameter to its extreme values as you go, not just at the end - a family that only gets tested once, after it is "finished," tends to reveal its broken constraints in the middle of a live project instead of during authoring.
- Keep geometry as simple as the use case allows. Over-modeled detail that will never be visible at a project's actual print scale mostly just slows the model down.
- Document and name consistently. Parameter names, type names, and family names that follow a firm's naming convention are what make a family library searchable and trustworthy months later, not just usable by the person who built it.
Managing a Family Library
A firm's value in its Revit content compounds over time, but only if it is organized. The practices that separate a library people actually trust from one people quietly route around: a single source location (not scattered across project folders), a naming and categorization convention applied consistently, a review step before new content is added company-wide, and periodic auditing to catch families that have drifted from standards. This is exactly the kind of resource this site's own free family and template library exists to provide - a starting point of vetted, working families rather than starting every project's content from a blank template.
Where This Fits in Your Learning Path
Families are Stage 3 in the learning order this site recommends elsewhere: after interface fluency and a basic modeled shell, before sheets and documentation. It is the stage most self-taught learners are tempted to rush past, and the one that determines whether the rest of Revit clicks into place or stays a collection of disconnected tricks.
If you want to build this skill with real feedback instead of trial and error on a live project, that is exactly what our courses are built to teach.