Most Revit users have been burned by bad families. The geometry looks fine in the vendor's screenshot, but drop it into your project and the problems start: the file balloons in size, the parameters are a cryptic mess, the plan view is cluttered with detail you don't need, and when you go to spec it, the product code doesn't exist. You delete it and start over.
Bad families aren't just annoying. They cost real time, time spent cleaning up, debugging, re-modeling, and explaining to a client why the drawing looks the way it does.
At Fetch, we've spent a significant amount of time thinking about what separates a family that's genuinely useful from one that just technically works. This post breaks down our content strategy from first principles, not as a product pitch, but because we think the reasoning behind these decisions is worth sharing. If you make families, or you're evaluating content for your firm, this is the thinking we'd want you to apply.
The most important thing about Fetch content isn't a specific feature. It's who built it. Our families are made by design professionals who have used Revit on real projects: furniture layouts, lighting plans, equipment schedules, construction documents. We know what it's like to be three days before a DD deadline and discover that a manufacturer's family has a 4MB file size and wrecks your project performance.
That experience shapes every decision we make. When we talk about "5D BIM as a baseline," we mean that cost data and product data aren't afterthoughts. They're part of the core information model from day one. Families include list pricing for budgeting and value engineering. They include real product codes so specifications actually connect to what's on the drawings. Built-in constraints mean you can't model configurations that don't exist in real life, which sounds obvious, but most content doesn't do this.
The goal is a single source of truth: one place where your Revit content, your product data, and your specification information are all aligned and maintained.
A family that's technically correct but hard to use is a bad family. Usability in Revit content isn't soft, it's measurable. How long does it take someone to place the family correctly? How many clicks to find the right type? How often do users set a parameter wrong because the interface didn't make the right answer obvious?
We treat usability as a design problem with real solutions.
Naming follows a consistent logic: families are named from generic to specific, so similar content groups together naturally in the Revit project browser. Types are reserved for meaningful configuration changes, not minor variations that could be handled with parameters. When a family only has one type, we call it "Default." No ambiguity, no hunting.
Parameters are where most family libraries fall apart. Ours follow a strict structure: standard parameter sets across each category, prefixes that signal what a parameter does, parameter groups that stay consistent across all families so users develop muscle memory, and tooltips that explain non-obvious inputs. We use input validation instead of massive type catalogs wherever we can, because it's faster and produces fewer errors. Hidden parameters keep the interface clean. If a parameter isn't something a user should modify directly, it doesn't show up in the properties palette.
Shared parameters are used deliberately across similar product categories. This matters when you're doing large-scale modifications or building schedules. Having consistent parameter names across a whole category means you can write one schedule and have it work across dozens of families.
If you want a working reference for all of this, we turned the full strategy into a checklist you can use on your own families.
A bloated family isn't just a technical problem. It's a statement about how much you value the people using your content. When a model slows down because of bad geometry decisions in a family, everyone on the project pays for it.
Our performance targets are specific:
Getting there requires intentional tradeoffs. We build levels of detail into every family, with simplified geometry in coarser views and detail where it counts. We're conservative about arrays. We only use them when there are more than three repeated objects and the range is wide enough that basic visibility toggling would produce worse results. Voids are avoided unless they're genuinely necessary, because they add computational overhead. All geometry is constrained to reference planes, which makes families more stable and predictable when parameters change.
Plan geometry is simplified deliberately, not because we're cutting corners, but because a cluttered plan view slows down production work. We include a small hidden line to indicate the back of the family, which matters for alignment. All 2D elements follow standard drafting conventions.
Materials matter too. Every Fetch family includes PBR materials using built-in images, which means no broken material paths when you open the family in a different environment. We also provide a complete material library with all standard materials and images for when you need to customize.
Here's the part most content providers don't talk about: how do you know the families are actually correct?
Every Fetch family goes through a structured QA/QC process before it ships, and the same tests run whenever families are updated. These aren't manual spot-checks. They're systematic.
Naming tests use regular expressions to verify that family names, type names, parameter names, and nested family names all conform to our naming standards. If a family comes back with a parameter named inconsistently, it doesn't pass.
Performance tests check file size, verify that plan geometry is hidden where it should be, and confirm that levels of detail are properly configured.
Parameter tests validate that parameters are in the correct groups, that values are appropriate for their type, and that nothing's been left in a broken state.
Import tests check for imported CAD, imported images, imported line patterns, and imported materials. All things that can sneak into a family and cause problems in other environments.
Reference tests verify IsReference settings, flag weak references, and confirm origin references are set correctly. This is the stuff that makes families behave well when users are dimensioning and aligning.
Standardization tests confirm family category is correct, which matters for scheduling, tagging, and electrical properties.
The reason this matters: families break. Products change, Revit updates introduce bugs, and even careful work produces errors. What matters is having a process that catches problems systematically and a team in place to fix them quickly. We do.
Each section returns a score and actionable data on what needs to be fixed
One thing we've learned is that content strategy can't stop at the family file. A well-built family in a project that doesn't have the right tags or schedules to use it is only half the solution.
Fetch provides a complete content ecosystem:
When you bring Fetch content into your workflow, you're not just getting geometry. You're getting a system that works.
We've written all of this out not to tell you our content is perfect, but to be transparent about the standard we're trying to meet and the reasoning behind it. Every decision described in this post represents a real tradeoff: between flexibility and simplicity, between file size and detail, between automation and human judgment.
If you make your own families, we put together an 8-section, 55-point checklist covering everything from naming conventions and parameter structure to performance targets and QA testing. It's the same standard we hold Fetch content to, and you're welcome to use it on your own work.
If you're looking for Revit content that's been built to this standard, that's what Fetch is for. Explore the library.
Have questions about our content strategy or want to talk about how Fetch fits into your firm's workflow? Get in touch