Disclaimer: It should be emphasised that the considerations documented here are, at this stage, by no means exhaustive. Rather, they represent a highly specific selection from a much broader framework of ideas and considerations. The selected information and graphics presented below are therefore intended to illustrate some of the overarching principles and underlying considerations informing the work, rather than to provide an exhaustive account of all its aspects.

In this sense, the work remains an ongoing process.



My work and the accompanying publication revolve around a design system that seeks to bring Revit-related efforts together under a shared, coherent visual and systematic language, with a particular focus on the development of Revit Families (digital building components) across an organisation or architectural practice.

When properly integrated, such a system has the potential to reduce the time invested, optimise workflows, and establish greater consistency in the final output, while advancing the objects themselves — and, by extension, the projects they contribute to. In essence, it is an investment in the long-term viability of the work.

As outlined above, the project addresses many of the everyday processes involved in projects of varying scales and types, across all design and development phases, and inevitably shaped, to some extent, by the people involved in the practice.

To meet my own objective of making the documentation function as a reference framework — a practical handbook that can be consulted as needed — I have attempted to organise the various considerations into chapters and groups, each intended to serve a distinct purpose while, as far as possible, following an established sequence or workflow and contributing to a coherent whole.

Combined with a digital library of typical, purpose-built objects and Revit Families developed in accordance with these guidelines, the documentation should provide a sufficient foundation for further development and implementation within an organisation or architectural practice.

Introduction

At the core of BIM (Building Information Modelling) lies the intelligent collection and organisation of data. Beyond information relating to geometry and positioning of all the individual building elements within a project, BIM encompasses all relevant data associated with a building (the Project) and each of its individual components or building elements (Families). This can help reduce misunderstandings, accelerate the design process, and build effective bridges between the teams collaborating to develop timely, well-considered, and results-oriented solutions.

This publication emerged from a desire to communicate these principles and establish a platform for the continued development of the aforementioned Families. Through explanatory texts and illustrations, the material has been shaped into an accessible, visually oriented handbook — a practical reference guide born out of many hours of working with the subject.

The longer-term ambition is to establish the foundations for a more extensive library of ready-to-use, flexible, off-the-shelf components, built around a standardised structure, consistent naming conventions, and an underlying methodology. Together, these principles should help ensure greater usability, a more consistent shared basis for data collection, and increased transparency.

This documentation has gradually taken shape through a series of considerations and reflections I have developed over the past few years. Initially, the intention was simply to collect my own notes in one place. However, it soon became apparent that the work might also serve as a means of sharing knowledge with other relevant professionals who, like myself, have encountered a need for greater transparency and, hopefully, a more systematic approach to the subject.



The fundamental premise behind this work is to streamline the production of Revit Families and BIM content in order to achieve substantial time savings while raising the overall standard of quality.

Too often, when we, as architects or architectural technologists, visit product-specific websites and download Revit content directly from their online libraries, we encounter over-modelled, overly complex, data-heavy Families containing imported 2D CAD geometry, missing essential information, incorrect associated classifications, and endless streams of warnings triggered by even minor adjustments to the excessive and often incoherent parameters.

All of this contributes to an accumulation of unusable elements, an exponential and unnecessary increase in file sizes, a significant reduction in practical value, and a substantial increase in the time required by both individual designers and entire projects.

The principles outlined in this publication therefore seek to establish a working methodology capable of addressing these challenges. The intention is to bring together and structure substantial portions of the documentation required for architectural practice, primarily through geometric representations of proposed projects and building components, the information associated with them, and the eventual integration of these elements into a coherent whole.
  
A higher degree of precision and consistency in subsequent work, together with the minimisation of repetitive processes, should also be achievable and integrated into the workflow through this methodology.

The challenge going forward lies in bringing the objects and the processes through which they are created under a more rigorous — and potentially more centrally managed — framework of guidelines and systematic principles. Such a framework should help establish a more pervasive and consistent approach across projects.

Hopefully, the results will be reflected in a higher and more comprehensive standard of quality wherever these building components are implemented. This should be evident not only in optimised workflows, but also in a more consistent approach to the associated processes, as well as to the necessary data inputs and outputs.

In short, my work has taken me through numerous aspects and less explored corners of this perhaps somewhat niche field of knowledge, yet one with potentially far-reaching implications. Through this work, I have sought to identify opportunities to contribute to architectural practice across processes, project phases, and content.

Processes 1

In this chapter, I will attempt to outline the overarching principles behind these processes and the strategic considerations that must necessarily serve as the foundation for the development of individual Revit Families.

As complexity increases and demands grow — not only in terms of the volume of information that each consultant is required, and expected, to address — we must become capable of mastering, managing, and making effective use of these emerging data-driven methodologies.

Consequently, new expectations are also placed on the capabilities of individual objects, including their flexibility, adaptability, capacity for integration, graphical settings, and, perhaps most importantly, their associated structured data. This data must be organised and made available at different levels and at different stages throughout the design and documentation process.



There is, therefore, every reason to establish a systematic approach to the process of creating these objects.

To communicate knowledge in a well-founded and structured manner, and to enable others to understand the underlying processes, the aim is to standardise as many of these processes as possible. Many of the exercises and considerations presented here are therefore specifically geared towards the reuse of objects across projects of varying scales and objectives, with a strong emphasis on time efficiency.

The intention is to avoid spending excessive time and limited resources on technical and underlying aspects of the work that may contribute relatively little to the project's overall objectives. In doing so, the importance of this deliberate and relatively rigorous system is emphasised.



Processes 2

Here, the focus shifts to the more technical, qualitative, and underlying processes that must inevitably form the basis for the creation of Revit Families at some stage.

Given the increasing complexity and ever-growing demands placed not only on the speed at which we work, but also on the information contained within each object, the documentation of choices, processes, and decisions, as well as flexibility and adaptability, there is every reason to harness the computer's greatest strengths: its ability to perform calculations and execute processes as defined by the end user.



Dynamo is an extension of the Revit design environment. It provides access to a wide range of more customised functionalities through what is known as a Visual Programming Language (VPL), offering capabilities beyond those available through Revit’s standard interface. In essence, this allows users to assemble or develop their own specialised tools to perform tasks according to the specific requirements and needs of the designer. These tools can operate within individual project and Family files, as well as across multiple files, creating a unique opportunity to develop and maintain a structured, up-to-date library of Revit Families without relying on manual, labour-intensive, and often error-prone processes.

Furthermore, Dynamo enables the integration of data from external sources, geometric manipulation and form-generation exercises driven by precise inputs and systematic rules, and the implementation of standardised, automated workflows. As outlined above, these can be used to identify and correct errors and omissions, reduce file sizes, and standardise and adjust input data.



Opening up Revit’s inner workings in this way brings with it a wide range of advantages, but also certain drawbacks. Small automation tasks can quickly consume many hours of work, and it should therefore always be carefully considered, in each specific situation, whether defining and developing these underlying processes is necessary in the first place.

There are entire communities dedicated to developing tools with both broad and highly specific objectives in mind. These tools can help ensure consistency not only at the individual project level, but also across an entire architectural practice — spanning multiple projects.



Examples of potential applications for Dynamo graphs (definitions) include, but are not limited to, the following:

Paramaters (input):

• Adding all standardised parameters that, according to the architectural practice's own standards and the relevant classification systems, should be assigned as metadata to individual objects. This can be based on the object's type or categorisation, either selected manually from a predefined list or retrieved automatically from Revit's own category assignments (e.g. Walls, Windows, Doors, Furniture, etc.).
• Removing unwanted or redundant parameters and generally eliminating irrelevant information.
• Checking for unwanted geometric elements and linework according to consistent criteria established by the practice, and subsequently determining whether these should be retained or removed.
• Renaming existing custom parameters, where technically possible, to conform to the practice's standardised naming conventions.
• Populating associated data fields wherever possible, based on defined categorisation systems. For example, a Family categorised as Windows will have a particular set of data requirements, while a Family categorised as Doors will have its own specific requirements.
• Connecting the aforementioned automated categorisation processes to established classification systems and data standards, such as IFC-related classification references (Industry Foundation Classes), BIM7AA classifications, and CSS classifications.
• Auditing data already entered into Type and Instance parameters, verifying compliance with naming conventions, and checking whether the relevant fields are correctly and sufficiently populated.
• Ensuring consistent parameter definitions across the library, including the correct use of shared parameters, parameter data types, and the distinction between Type and Instance parameters.
• Validating the completeness and integrity of associated data, including required fields, permitted values, units of measurement, and category-specific requirements.
• Establishing a more rigorous and consistent approach to automated data handling, reducing the need for manual intervention and limiting the risk of human error.
• Generating validation reports that identify missing, inconsistent, or incorrectly assigned parameters, enabling errors to be corrected systematically rather than relying solely on manual inspection.

Parameters (output):

• Extracting data, potentially using the Bumblebee package for Dynamo, for subsequent processing in third-party applications such as Microsoft Excel for calculations, Microsoft Power BI, various data and geometric visualisation platforms, other data-processing tools, and, not least, cost-estimation applications.
• Establishing a general, relatively consistent workflow that can broadly be outlined as follows a) selecting relevant data,
  b) cleaning the selected data, c) normalising the data, d) mining and analysing the data, and, e) interpreting the results, potentially through visualisation.
• Exporting data ranging from quantitative information, drawing schedules, and object inventories to error logs, documentation relating to responsibilities and project history, area calculations, usage patterns, and data associated with sustainability objectives.
• Generating automated reports on data completeness, compliance with project or practice-specific standards, and the overall quality of the information contained within the Families or project models.
• Establishing traceable records of automated operations, including the changes made, the objects affected, and any errors or exceptions encountered during execution.
• Structuring extracted data so that it can be reused consistently across applications and project stages, minimising redundant data entry and reducing the risk of discrepancies between different sources of information.

Geometry (input):

• Assigning objects or geometric elements within a Family to appropriate subcategories and, where supported by Revit's category structure, reassigning objects to the correct category.
• Continuously checking for duplicate object instances and, where relevant, performing clash detection to identify overlapping or conflicting geometry.
• Verifying that Family naming conventions are respected and updating names where necessary, in accordance with the standards established by the architectural practice or the individual project.
• Reviewing the standardised representation of three-dimensional geometry and two-dimensional linework across plans, sections, elevations, isometric views, and perspectives, in accordance with the practice's guidelines for Family development.
• Checking the placement of reference planes, insertion points, origins, constraints, and work planes to ensure that individual Families behave predictably when inserted into projects and positioned relative to other building components.
• Validating visibility settings and the appropriate display of geometry at different detail levels, ensuring that the correct representation is shown in accordance with the intended view and level of detail.
• Testing the parametric behaviour of Families by changing relevant dimensions and parameter values, identifying geometric failures, unexpected deformations, or broken constraints before the Families are released for general use.
• Checking that geometric complexity is appropriate to the intended purpose of the object, avoiding unnecessary detail that increases file size and reduces performance without providing meaningful project information.

Geometry (output):

• Exporting geometry for visualisation, subsequent analysis, calculations, or other purposes in third-party applications, including structural and economic calculations, through standardised and automated workflows.
• Exporting the current project status to static or non-editable formats, such as PDF, or other appropriate formats for documentation, review, and communication.
• Exporting geometry in predefined formats and structures suited to the requirements of downstream applications, ensuring consistency in units, orientation, positioning, and object identification wherever relevant.
• Generating consistent geometric representations for use in visualisation, model coordination, quantity calculations, and other analytical workflows, reducing the need for subsequent manual preparation.
• Comparing exported geometry against previous versions or defined reference states to identify changes, omissions, and discrepancies between successive project issues.
• Producing geometric outputs accompanied by the relevant metadata, allowing exported objects to remain identifiable and traceable when transferred to other applications or workflows.

Materials (intput):

• Naming materials in accordance with the aforementioned classification systems and connecting them to external databases containing relevant metadata.
• Reviewing all associated data and properties for individual material instances in accordance with the practice's guidelines, including naming standards and consistent methods for populating the relevant data fields.
• Identifying duplicate materials, materials with missing information, and materials that do not conform to the established naming or classification conventions.
• Verifying that material assignments and associated properties are consistent with the intended use of each object and its role within the overall project.
• Connecting material definitions to relevant product information, manufacturer references, technical specifications, and environmental data where such information is required and available.
• Checking that material assets, appearance settings, and physical properties are used consistently and that unnecessary or redundant material definitions are identified for review.

Materials (output):

• Connecting the material and data export processes to the aforementioned third-party applications, including tools for structural and economic calculations, thereby enabling faster and more precisely defined downstream workflows. This includes automating the transfer of quantities, material specifications, and other relevant information.
• Automating quantity take-offs and improving the naming, sorting, and categorisation of materials, including the classification and identification of individual material groups.
• Exporting material quantities and specifications in a standardised format suitable for cost estimation, procurement, specification writing, and further technical analysis.
• Linking material quantities to relevant cost databases and, where appropriate, environmental data sources to support more consistent cost calculations and sustainability assessments.
• Ensuring that material quantities are accompanied by clearly defined units, classification references, and calculation assumptions, thereby reducing ambiguity and improving the comparability of results across projects.
• Establishing repeatable workflows for updating material data when product specifications, quantities, or project requirements change, minimising the need for repeated manual adjustments.

Maintenance (input):

• Minimising individual Family file sizes by systematically reviewing their contents, primarily to eliminate redundant geometry, unnecessary linework, and irrelevant associated information. This should also take into account the established and current Level of Development (LOD) requirements, where applicable.
• Reviewing the number and complexity of Family types, nested Families, imported CAD geometry, and other embedded content to identify elements that may be unnecessary or disproportionately resource-intensive.
• Checking for unused materials, redundant parameters, obsolete types, and other residual content that may accumulate as Families evolve over time.
• Identifying warnings, errors, broken constraints, and other potential issues affecting the stability, usability, or performance of individual Families.
• Establishing consistent maintenance criteria for deciding which content should be removed, retained, or flagged for manual review, rather than relying on ad hoc decisions for each individual Family.
• Reviewing the continued relevance of Family content against current practice standards, project requirements, and intended levels of detail, ensuring that the library does not become burdened with outdated or unnecessarily complex objects.
• Recording the results of maintenance operations so that changes can be reviewed, validated, and traced back to the relevant Family version.

Maintenance (output):

• Achieving cleaner exports of both geometry and associated data, with reduced file sizes resulting from the removal of unnecessary geometric elements, linework, data, and material definitions.
• Producing optimised Families with a more appropriate balance between geometric complexity, information content, performance, and intended use.
• Generating maintenance reports documenting the changes made, the content removed, any warnings or errors encountered, and any issues requiring manual intervention.
• Establishing an automated quality-control process in which updated Families are tested and validated before being published to the shared library for wider use.
• Maintaining consistent versioning and revision records for individual Families, supporting the identification of approved versions and reducing the risk of outdated or unverified objects being reintroduced into active projects.
• Ensuring that the resulting Families remain lightweight, technically reliable, and consistent with the architectural practice's established standards, thereby supporting a more efficient and sustainable approach to the ongoing development and maintenance of its BIM library.

Examples: Object Types

The following section seeks to illustrate selected examples of different Family types through visual representations accompanied by non-exhaustive lists of associated properties.

The aim is to demonstrate a range of the considerations explored throughout this publication by applying them to concrete Revit objects, and by establishing consistent, systematic, and carefully considered methods for assigning and structuring their associated parameters, data, and information.

With this in mind, I have selected the following Revit System Families and Loadable Families: