How to Better Manage Your Revit Content - Part 1

This is the first article of a three-part series. You can find the second article 
here.

As Leo Tolstoy wrote in Anna Karenina, "Happy families are all alike; every unhappy family is unhappy in its own way." Though he wrote those words almost 150 years ago, well before the advent of BIM, it's not a stretch to say Tolstoy's maxim applies to Revit families as well. Functional, well-constructed Revit families all share common guidelines. These families use consistent standards, are organized in an effective library, and adhere to strict quality control guidelines. Unhappy families, however, are a whole other ballgame.

Ever loaded a family into your project file and found the parameter names weren't in English? Ever searched through the family browser looking for a particular casework family only to realize, after twenty minutes of looking, that some clown named it "Joe's Awesome Family"? How about the time you loaded that cool-looking toilet family into your project, created 20 or so instances, then pulled your hair out after your model swelled up to 10x its original size?

In this three-part series, I'll describe the major steps for successfully managing your Revit content. These steps include:

• Standardizing your content.
• Organizing your content into an easily accessible library.
• Maintaining the quality and usefulness of your content over the long term.

In today's post, we're going to dive into standardization. Let's get started.

Standardize your content

A while back, I was working on a large residential project in Revit. One of the team members had created some custom window families that I needed to insert into the exterior wall I was working on. After spending 10 minutes rooting through the family browser in the project file, I gave up. I couldn't find the families. So I walked over to my colleague who created the family and asked him what they were named. "Um. . . I think they're called 'exterior windows' or something like that." He spent another ten minutes looking for the families until, finally, I heard him yell "Found them!"  He shuffled over to my desk with his head hung low. "Yeah. . . well. . . that family is named 'zzzzz'. I was in a hurry that day. . . I guess." After fixing him a dirty look, I promptly renamed the family something a little more descriptive.

The couple of minutes spent properly naming his family would have saved us the 20 minutes we collectively spent looking for the family. And this was just one instance. Imagine if five people went looking for that family over the course of a week.

The first step in standardizing your Revit families is deciding on a naming convention. This naming convention should encompass the name of the .RFA file, at the most basic level, and should extend to the family types and parameter names as well. Let's look at each of these items in more detail.

Family names

When it comes to Revit families, you're either using out-of-the-box content, downloading content from an online repository or manufacturer's site, or you're creating your own. In each case, you'll want to reconsider the name of the family so you can identify where it came from and easily locate it in your model's family browser.

Your naming convention should be clear and easily understood. If you want it to be used, make it easy to use. I worked at a firm that used a super-compact but extremely cryptic naming convention for AutoCAD blocks. You needed to refer to a cheat sheet just to figure out what was in the block. Guess what happened? Total chaos. No one could figure out the convention and instead, made up their own. While it may make sense to you, test it out on your co-workers before you implement it.

Families that you or your firm have created should have a prefix for your company or other such identifier so they sort in the family browser. If it's a project specific family, it should have a project prefix. This will make the family easier to identify when you go through the family harvesting process I describe in part 3 of this series.

If you're using the Level of Development standard, you should consider adding the LOD to the family name as a suffix. This will make it easier to audit the model and swap out higher or lower LOD families as needed. It also tells the user how much detail they can expect in the family. Ever loaded a family into your schematic design model only to find the thing includes all the screws, bolts, and washers? Identifying the LOD of the family definitely helps in this regard.

Family types

If you're creating a parametric family, you'll need to consider a naming convention for each family type. The name of the types should be easily understood by future users of the family. The name should clearly indicate the difference between each type and briefly describe the parameter value that changes.

Suppose you're creating a new parametric window family. Naming the 3 types in the family "window 1", "window 2", and "window 3" isn't very helpful. While you might know the difference between them, a future user of the family isn't. Do yourself and the user a favor by clearly naming the types. You'll save everyone time in the end.

Using our example above, a better series of names for the window types would be "30 x 60", "30 x 80", and "30 x 100" for windows with a fixed width and variable heights.

The concept is really basic but I've come across countless family types that were named all sorts of crazy things. Always assume someone else is going to use your content. Show some empathy and name the family types accordingly.

Parameters

Parameters are great. Parameters are horrible. Like most things, it's all in the execution. Use parameters when they make sense but don't overcomplicate your families. Nothing's more frustrating than trying to create a new family type in a family with 100s of parameters.

The family should be just parametric enough. I love a good parametric family but if I see more than ten parameters, my eyes glaze over, my pulse quickens and I start to hyperventilate. Imagine how a novice Revit user will feel.  Anticipate how a family will be used and who will be using it.

Try to limit your editable parameters to five or six max. Anything more than this gets too complicated and the likelihood of the families being used correctly (or used at all) diminishes rapidly. Put that dream of creating the "one family to rule them all" on hold, at least for now.

Parameter names

Once you've standardized your family names and types, it's time to take an inward look at your parameter names. In this case, it's helpful to consider how people are going to use your family. The rule of thumb here is "keep it simple". If someone needs to edit your casework family and create a new type, are they going to know that the parameter "z3d" represents the height cabinet height? Or that "w1" is the cabinet width.

One interesting option I've seen is to create text parameters that act as comments and describe how the parameters are to be used. This made working with fairly complicated families much easier. Here's an example from an Anderson Window family:

When you're first developing the family, it may be easier and faster to simply use short-hand names for your parameters. However, as we'll discuss in part 3, when you migrate your families into the real world, you should make an effort to walk in the shoes of your co-workers and clean up and clarify your parameter names.

Parameter categories

So you created a bunch of parameters and gave them good, descriptive names. How can you ensure users find the parameters? Setting each parameter under the proper parameter category is the easiest way to group similar parameters together.

Revit comes with a default set of parameter categories. As far as I know, there isn't a way to add new categories, which is unfortunate. When selecting a category, choose the one that best fits the parameter. Again, think of the end user and ask yourself what category would make the most sense to them. Keep it simple and group like parameters together as best you can.

What's Next

Now that you've standardized all your family, family type, and parameter names, we'll next look at how to best organize your family library in the second installment of this series.

So how about you? How do you manage your Revit content? Do you have any stories about trying to find poorly named Revit families? Or does your firm have a family naming convention in place? If so, what's included in the convention?