Ten pillars of a well-built Revit Template


Too often we leap before we look - the value of a well-built template is often underestimated due to the non-billable hours required to be invested in its setup. In this article, we aim to cover the core pillars of what I think all Revit templates should be built to achieve.


It probably goes without saying, but every company using Revit should create (and continuously develop) their own Revit template. Autodesk did not design Revit to come out of the box with guns blazing; on the one hand this is unfortunate, on the other it forces companies to revisit and refine their own workflows.


I've built my fair share of Revit templates during my career, and have learnt each time that there are a core set of principles all of these ended up requiring and benefiting from. Some firms struggle to look past their line weights and patterns, but I'll take you beyond this to what really matters when developing a template.



BIM Guru's Template


For those keeping an eye on our website, you may have noticed we now have an online store! Currently there are 4 products, one of which is a Revit 2020 architectural template - we will be announcing some promotions for this shortly on our social channels.


Coming soon: The BIM Guru Revit template!



Pillar 1: Pro-active 'Buy-in' Strategies

Not seen here: The afor-mentioned


More often than not, this is actually the most critical yet time consuming aspect of developing a template. The moment everyone finds out what you're doing, every person in the company and their dog has an opinion about what the correct masonry hatch is and why 'their line weights' are better than the company standards.


I've always found that the best process for buy-in is as follows:


  1. Research industry standards that may benefit your template (e.g. ISO19650)

  2. Prepare an action plan (make it clear and concise)

  3. Get approval from the management level of your company

  4. Hold a single workshop where anyone may attend and propose ideas

  5. Blinkers on, roll out the changes

  6. Pilot the changes on a project that can afford some testing delays


It is crucial that during step 4 (a workshop) all attendees are encouraged to reach a consensus on their ideas - conflicting opinions should not be left unmediated, otherwise they will rear their heads again at a later date (restarting the process essentially). Have reasoning behind your choices ready so you can more easily dismiss ideas with less merit for collective needs.



Pillar 2: Order of Dependency

The actual updating of a template usually best follows a specific order. There are certain aspects that rely on previous ones being established, for example: wall types may require shared parameters to be set up prior. Your goal should be to avoid 'doubling back' in as many aspects as possible.

Aspects of a template: A lot to consider!



In my experience, this tends to be the order of creation that invokes the least backtracking due to dependency between elements:


1. Establish naming conventions


2. 2D Graphical standards

  • Line Weights

  • Line Patterns/Styles

  • Fill patterns, filled region types

  • Fixed/spot dimension types

  • Grid/Level/View reference types


3. Systems

  • Shared parameters

  • Keynotes

  • Assembly codes

  • Material library


4. System families

  • Basic wall types

  • Curtain panel/wall types

  • Floor/Ceiling/Roof types

  • Railing types


5. Loadable families

  • Essentials only, eg:

  • Door/Window families

  • Parking space families

  • Casework families

  • Will vary depending on your discipline


6. Views and Sheets

  • View types and templates

  • Titleblocks

  • Base views and sheets



Pillar 3: Well documented systems


A common trap to fall into when developing a template is to internalize your thought process - it is an intense process, and the blinkers always come on to some degree. Remember that others will need to use your template, and should be able to understand the logic applied to each system used.


If you use national/international standards to form aspects of your template, make sure these are clearly referenced and made available to the right people so they can audit and maintain their projects against these. Remember, not everyone is aware of these standards beyond the surface level!


System/rule views: We use many in our templates!


Good practice is often to include a set of legend or drafting views somewhere in your project browser where users can visit and view the systems/rules in place so they can better learn about the expected ways to use the template - over time these will become second nature to them.


Pillar 4: Adaptability


If your template is larger than 30MB, chances are you've put too much into it. A well known methodology applied to templates in larger companies is the 'Chassis/body/trim' approach. Essentially, the template should act as a framework which can receive changes to suit the needs of the project it will be used on.


Chassis/Body/Trim: Make your template adaptable!


Just as a concept designer has no need for LOD400 content, a technician has no need for a concept presentation view template. By storing various aspects of your template in separate models you can keep the template light, containing the essential bare bones only.


Revit provides us with two powerful template aids; 'transfer project standards' and Dynamo. The first allows us to migrate in additional template aspects, whilst the latter allows us to make blanket additions/changes/removal to the template itself.


Make sure that when you gauge what your user's need, you take into consideration all types of users and project stages - the lighter you can make the template, the more likely users will do things the intended way.



Pillar 5: Universal_Naming-Conventions [1]


Naming is an important principle in any template based exercise, however it's crucial that the number of conventions being used should be minimized as much as possible. A common mistake I've made in the past is inventing a convention for each system, for example: naming materials one way, but naming family content entirely differently.


My core goals when it comes to naming are:


  • Search-ability

  • Human readability

  • Process-ability


Pillar 3 is also crucial here, naming conventions should be documented extensively. If you can't summarize the convention in less than a few paragraphs, chances are it's too complex and people will get it wrong when they create new elements.



Pillar 6: Render-ready Materials


One of the best reactions I got from a user who was trying out a new template was when they came to the point of rendering a 3D view. They approached my desk, asked me how long it would take to prepare the model for rendering, and my reply was simply 'as long as it takes to hit the button'.


What the user did not realize is that whilst I built the template I had also prepared and applied render-ready materials to all the content we had available. Whilst this took time, the enjoyme