BIM mindset: you are building a database, not drawing lines
In Revit, the model is the source of truth. Plans, sections, elevations, schedules, and quantities are different views of the same coordinated building data. “Modeling for BIM” means you place real building elements (walls, floors, doors, roofs, structural framing, MEP components) with the correct category, type, and parameters so that documentation stays consistent automatically.
Drafting mindset vs. BIM mindset
| Drafting approach | BIM approach |
|---|---|
| Draw lines to represent a wall | Place a Wall element with a defined type (layer build-up, function, fire rating, etc.) |
| Manually label and count doors | Use door families with parameters; schedules count and tag automatically |
| Fix inconsistencies view-by-view | Edit the model once; changes propagate to all views |
| Use “whatever works” layers | Use categories/subcategories, object styles, and view templates for control |
What “correct category, type, and parameters” means in practice
- Category controls how an element behaves and is documented (tags, schedules, visibility/graphics). Example: a door modeled as a
Generic Modelwill not schedule like aDoor. - Type is the reusable definition (e.g.,
Basic Wall: Exterior - Brick on CMU). Changing a type updates all instances of that type. - Instance parameters vary per element (e.g., door
Mark, sill height, comments). These drive tags and schedules. - Hosted relationships matter: doors should be hosted in walls; fixtures hosted on faces; windows hosted in walls. This keeps coordination stable when walls move.
Rule of thumb: if you find yourself “drawing around” a problem in one view, you are likely not modeling the right element or not using the right parameters.
Revit file ecosystem: projects, families, and how changes propagate
Project files (.RVT)
The .RVT file contains the building model, views, sheets, schedules, annotations, and project settings. When you edit a wall type, move a level, or change a door width, every view that references that data updates.
Family files (.RFA)
.RFA files define reusable components (doors, windows, furniture, tags, titleblocks, detail items). Families contain geometry and parameters. You load families into a project, then place instances.
How edits propagate (and why it matters)
- Model edit (e.g., change wall location) updates all plans/sections/elevations automatically.
- Type edit (e.g., wall layer thickness) updates every instance of that type across the project.
- Family edit (edit
.RFAand reload) updates all placed instances in the project, potentially affecting schedules and clearances. - View control (view templates, filters) changes how the same model is displayed without changing the model itself.
This is why a clean start prevents downstream rework: if you begin with incorrect units, messy naming, or miscategorized content, you will spend time fixing hundreds of view-specific symptoms instead of correcting the root data.
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
Starting a small-building project the right way (step-by-step)
Step 1: Create a new project from the correct template
Choose a template that matches your discipline and region standards. For a small building, you typically start from an architectural template (unless you are doing structural/MEP as the primary model).
- Go to File > New > Project.
- Select a template such as
Architectural Template(or your office template). - Confirm you are creating a Project, not a Family.
- Save immediately: File > Save As and name it using your convention (example below).
Why this matters: templates carry view templates, object styles, default families, line weights, and browser organization. Starting from the wrong template often leads to inconsistent graphics and missing content.
Step 2: Set project units before modeling anything
Units affect input, displayed values, and rounding. If you model with the wrong units, you can end up with walls that are 10x too thick or site coordinates that make no sense.
- Go to Manage > Project Units.
- Set length (e.g., millimeters or feet/inches), area, volume, slope, and angle formats.
- Set rounding appropriate for your documentation (e.g., 1 mm or 1/8").
Practical tip: after setting units, place a temporary dimension between two points you know (e.g., 1000 mm / 3'-0") to confirm input behaves as expected.
Step 3: Establish project location basics (for consistent north and sun studies)
Even for a small building, set basic location early so that true north, shadows, and any future coordination with civil/site data are not a scramble later.
- Go to Manage > Location and set the city/nearest location.
- Decide how you will treat Project North vs. True North:
- Project North: convenient orientation for drawings (often the building “upright” on sheets).
- True North: real-world orientation for sun/shadow and site coordination.
- If you already know the rotation, set it using Manage > Position > Rotate True North (or postpone until you have a site reference, but document the intent).
Step 4: Define a naming convention (views, levels, grids, sheets)
Consistent naming makes the Project Browser usable and prevents duplicate/ambiguous views. Decide a convention before you create dozens of views.
Example naming conventions for a small building
- Levels:
Level 00 - Ground,Level 01 - First,Roof - Grids: numbers one direction, letters the other (e.g.,
1-6andA-F) - Plans:
A-PLN-00 Ground,A-PLN-01 First - Ceiling plans:
A-RCP-01 First - Elevations:
A-ELV-North,A-ELV-East - Sections:
A-SEC-01,A-SEC-02(with a short descriptor if needed) - 3D views:
A-3D Coordination,A-3D Presentation - Sheets:
A101 Floor Plans,A201 Elevations
Practical tip: keep view names short but structured; avoid “Copy of Copy of Level 1”. If you need variants, add suffixes like (Working), (Permit), (Coord).
Step 5: Organize the Project Browser early
The Project Browser is your navigation system. If it becomes cluttered, beginners waste time opening the wrong view, editing in the wrong place, or duplicating views unnecessarily.
- Go to View > User Interface > Browser Organization.
- Create a browser organization scheme that groups views by:
- Discipline (Architectural / Structural / MEP)
- View type (Plans, RCP, Elevations, Sections, 3D, Schedules)
- Phase or Purpose (Working, Coordination, Sheets)
- Apply consistent view templates so that “Working” vs. “Sheet” views have predictable graphics.
Practical tip: create a dedicated folder-like grouping for “Working Views” and keep “Sheet Views” clean. This reduces accidental annotation in the wrong view.
Structured initial setup checklist (small building)
| Category | Task | Done |
|---|---|---|
| File start | Create project from correct template; save with standard name | ☐ |
| Units | Set Project Units (length/area/volume/rounding) | ☐ |
| Location | Set project location (city); confirm Project North vs True North intent | ☐ |
| Levels | Confirm required levels exist and are named consistently (Ground/First/Roof) | ☐ |
| Grids | Set grid naming convention (numbers/letters) and place primary grids | ☐ |
| View naming | Rename default views to match convention; delete/avoid duplicates | ☐ |
| Browser | Set Browser Organization; create “Working” vs “Sheet” grouping | ☐ |
| Templates | Assign view templates for plans/sections/3D; verify scales | ☐ |
| Content | Load only needed families (doors/windows/tags) from trusted library | ☐ |
| QA quick test | Place one wall/door; verify tags and schedule category behavior | ☐ |
Common beginner mistakes (and how to avoid them)
Mistake 1: Modeling without levels (or with poorly named levels)
Symptom: elements end up at random heights; sections look wrong; stairs/roofs become difficult to control.
Prevention: define and name levels first. Use levels to drive constraints (Base Constraint / Top Constraint) rather than manual offsets.
Mistake 2: Random view names and uncontrolled duplicates
Symptom: “Level 1 copy 3” everywhere; people annotate the wrong view; sheets reference the wrong plan.
Prevention: rename views immediately, and use a consistent prefix system. Duplicate views intentionally and rename them right away (e.g., A-PLN-01 First (Working) vs A-PLN-01 First (Sheet)).
Mistake 3: Incorrect units at the start
Symptom: imported details are the wrong scale; dimensions look odd; model elements are wildly oversized/undersized.
Prevention: set units before placing any geometry. If you receive external references, confirm their units before linking/importing.
Mistake 4: Using the wrong category (especially Generic Models)
Symptom: elements do not tag or schedule correctly; visibility control becomes messy; quantities are unreliable.
Prevention: choose families with correct categories (Door, Window, Furniture, Casework, etc.). If you must use a placeholder, document it and replace it later with the correct category.
Mistake 5: Editing graphics view-by-view instead of using templates
Symptom: inconsistent lineweights and visibility across sheets; time wasted “fixing” each view.
Prevention: rely on view templates, filters, and consistent object styles. Treat per-view overrides as exceptions, not the workflow.
Mistake 6: Starting “messy” and hoping to clean later
Symptom: rework multiplies as the model grows; schedules and sheets become hard to trust.
Prevention: spend the first 20–40 minutes on setup: units, levels, naming, browser organization, and a quick QA test placement to confirm categories and tags behave correctly.
