Design brief (ToR): structure and common mistakes

Updated: 2026 · Reading time: ~6 min

In design, the key is not “to avoid mistakes” as a slogan, because errors lead to critical consequences for the project and later become defects, rework and schedule delays. Below is the structure we use as a baseline for design.

1) Properly prepared general data

The “General data” section in a ToR is a project passport that removes 80% of misunderstandings between the client and the designer. It should clearly define: facility name and location, functional purpose, consequences class (CC), key technical and economic indicators (area/volume/storeys/capacity), design boundaries (what is included/excluded), requirements for stages and discipline composition, baseline data (geodesy, geology, urban planning conditions, technical conditions/utility connections), expected timelines and the interaction procedure (responsible persons, communication channel, approval schedule). A typical mistake is using generic phrases without specifics and without a baseline data list — design starts “blind” and inevitably requires rework.

2) All critical requirements for the facility are defined

Critical requirements are parameters whose violation leads to project stoppage, problems with expert review, additional costs or inability to operate. They include: land plot constraints and protection zones, maximum elevations and geometry, fire safety requirements, evacuation, accessibility, foundation bearing capacity and structural system, reliability categories of engineering systems, redundancy/uninterrupted operation (if required), energy efficiency, noise/vibration, corrosion protection, as well as technology/equipment requirements (for industrial or infrastructure facilities). A typical mistake is not fixing “immutable” parameters at the start — later any change triggers a chain of recalculations and redesign across disciplines.

3) Specific requirements for the facility are stated

Specific requirements depend on the facility type, operating conditions and risks. In the ToR they must be formulated clearly and measurably: architectural/planning constraints, requirements for materials and façade systems, higher requirements for durability and maintainability, aggressive environment conditions, wind/snow regions, seismicity (if applicable), BIM modeling requirements and delivery formats (IFC/Revit etc.), client expectations for deliverables (specifications, quantities, material schedules), occupational safety and construction organization requirements. A typical mistake is mixing “nice to have” with “mandatory”, or postponing special requirements — this creates conflicts during approvals and on site.

4) Who is the client for the expert review is defined

The ToR must unambiguously define who acts as the client of the expert review (and who signs/pays for expert services), as well as the review format: full/partial, by directions, with authors’ support of disciplines. This is important because the expert review client receives official remarks, organizes submission/resubmission, confirms baseline data and agreed solutions. A typical mistake is not defining the responsible party and the procedure for responding to remarks: deadlines are lost, letters “hang”, and the project is delayed at a critical stage. A PRO approach is to prescribe: who submits, who supports, who decides on controversial remarks and the response time for each round.

5) Reporting / supporting documentation is agreed

It is worth fixing in the ToR which reporting/supporting deliverables the client expects together with the project. These may include: explanatory notes of the required composition, calculation justifications, quantities statements, equipment and material specifications, load schedules, coordination protocols, change register, typical details album, BIM source files, and a tender package (if needed). A typical mistake is not agreeing on the format and depth of “reporting”: the design may be formally correct, but unusable for procurement/estimating/construction management. The earlier reporting requirements are defined, the faster and cheaper they are prepared without “last‑minute” rework.

6) The design stage is selected rationally

The choice of stage (sketch/pre‑design studies, “P”, “R”, or another staging under the contract) should correspond to the project goal, timelines, risks and the construction contract model. If the client plans a construction tender, the documentation must be detailed enough to compare bids correctly and minimize “hidden” works. For complex/high‑risk facilities, it is reasonable to include intermediate approval milestones to “lock” key decisions before issuing working documentation. A typical mistake is trying to obtain “R” immediately without proper baseline data or without an approved “P”: this almost guarantees rework, schedule slippage and conflicts with the contractor. Rational staging means controlled quality and a predictable budget.