Room data sheets are one of the most widely used tools for communicating requirements in building projects. They help clients and design teams discuss, define, and verify the required qualities of the spaces within a building.
In practice, however, the usefulness of room data sheets is often undermined by excessive or poorly defined information. For this reason, it is important to think carefully about the setup of room data sheets. What is their purpose? Who will use the information, when, and how? What information should be included, and what should not?
In this two-part article, we explore these questions and provide practical guidance on creating effective room data sheets.
In this first part of this article, we’ll discuss the broader purpose of room data sheets and the project context in which they are being used. In this, there are five key considerations:
- Target groups and their information needs;
- Project phasing;
- Type of tender;
- Type of project and space;
- Type of requirements.
We’ll briefly discuss all five considerations.
(1) Target groups and their information needs
The first question to ask when developing room data sheets is: who are they for?
In general terms, the primary target group is the design team. However, a design team typically consists of many disciplines, each with different information needs.
Architects will primarily be interested in room sizes, adjacencies and access to daylight. Electrical engineers will want to understand power and data requirements. Structural engineers may need information about floor loads, while mechanical engineers will focus on thermal comfort and air quality. Interior designers, in turn, will be interested in requirements relating to furniture and furnishings.
When all these target groups are involved, room data sheets inevitably become information-heavy. It therefore becomes crucial to structure information into logical categories so that stakeholders can quickly find what they need. In addition, it should be possible to create discipline-specific reports and overviews.
At the same time, a siloed approach should be avoided, as many requirements are closely interrelated. Requirements concerning infection control, for example, may affect room adjacencies, pressure regimes, ventilation systems, finishes, and cleaning procedures. It is therefore important that different disciplines not only focus on “their” requirements, but also understand the intended functionality of the space and the relationships between different requirements.
A final consideration regarding target groups concerns the building’s users. While the design team is typically the primary audience for room data sheets, building users may also be involved in reviewing and validating requirements. In such cases, additional non-technical explanations may be required. For example, rather than simply stating that a wall should achieve a certain acoustic insulation value, it may be helpful to explain what this means in practice—for instance, whether conversations will be audible in adjacent spaces.
BriefBuilder allows quantitative requirements to be combined with functional explanations. In this example, the description explains the practical meaning of a sound insulation requirement.
(2) Project phasing
Closely related to the above is the matter of project phasing. The information needed during the early design stages differs from the information required later in the project.
In the early stages, the design team will primarily need basic spatial information, such as room types, quantities, sizes, zoning, daylight access, and adjacencies.
As the design progresses, the need for technical information increases rapidly. Engineers will require more detailed input on indoor climate, structural loads, and utilities in order to design the building’s systems.
In the later stages of the project, the required information may become even more detailed, covering fixtures, fittings, and furnishings. The interior designer may, for example, need to know whether the client prefers wall-hung or floor-mounted toilets.
The key point is that information needs evolve throughout the project and that there is no need to define everything from the outset.
If detailed information is already available at an early stage, it is advisable to create phase-specific reports and views that prevent information overload and allow stakeholders to focus on what is relevant at that point in the project.
Spatial requirements are most relevant during the early design stages, when the architect is developing floor plans, sections, and the overall building form.
(3) Type of tender
The required level of detail in room data sheets also depends on the project’s procurement route.
In traditional design-bid-build projects, room data sheets primarily support the design process. As the client remains closely involved throughout the design stages, requirements can often be refined and clarified as the project progresses.
This differs from design-and-build projects, where the architect is typically part of the contractor’s team. In such projects, the client has less direct influence over the detailed design. Room data sheets therefore become a much more important instrument for steering and safeguarding design quality.
In these situations, data quality is crucial. If room data sheets are incomplete, additional costs for variations are likely to follow. If they contain ambiguities, the client may receive solutions that differ from what was intended—often cheaper or lower-performing alternatives. And if the requirements contain errors, these may directly affect project costs, timelines, and contractual discussions.
As a general rule, room data sheets become more contract-like and more comprehensive when clients are less directly involved in the design process.
When room data sheets become more contract-like, it is often useful not only to capture requirements, but also to link them to a verification plan (who verifies what, when, and how?) and to record the verification outcomes (have the requirements been met?).
Verification plans define who verifies compliance, when, and how. In BriefBuilder, the resulting verification tasks and outcomes can be monitored through a dedicated dashboard.
(4) Type of project and space
Some building types are more demanding in terms of room requirements than others.
Room data sheets for residential projects, for example, are often relatively simple. In contrast, room data sheets for hospitals and laboratories can become highly detailed due to the complexity of the activities taking place within these buildings.
A laboratory or clean room, for example, may require detailed information on air quality, pressure regimes, vibration limits, chemical resistance, and specialist utilities. In projects with these kinds of spaces, a high level of detail may be unavoidable.
At the same time, it is important not to let exceptional spaces determine the format of all room data sheets within a project. The fact that highly critical spaces require extensive information does not mean that ordinary offices, meeting rooms, or circulation spaces should contain the same level of detail.
The level of information should therefore be proportionate to the complexity and criticality of the space.
Not all requirements apply to every space. By assigning specialised requirement sets to specific space types, detailed requirements can be captured where needed without overloading other room data sheets. In this example, visual geometry requirements are applied only to lecture halls, keeping other room data sheets concise.
(5) Type of requirements
A final important consideration concerns the nature of the requirements themselves. Do the room data sheets describe functional needs or predefined design solutions?
For example, a functional requirement may state that a room should achieve an illuminance level of at least 1,000 lux while limiting glare. A prescriptive specification, on the other hand, may define the exact luminaire type, dimensions, and lamp configuration to be used. In the latter case, the room data sheet starts to resemble a technical specification rather than a briefing document.
In general, our recommendation is to focus on functional requirements. This gives the design team the freedom to develop the most appropriate solution while still achieving the intended outcome.
That said, there are situations where a client may have good reasons to specify particular solutions. When renovating an existing building, for example, it may be desirable to maintain consistency with existing fixtures, fittings, or finishes. Likewise, clients with specialised operational knowledge may know from experience which solutions perform best in a particular context.
Example of visual comfort requirements that clearly describe the desired conditions without prescribing specific design solutions.
Next part
Against this general background, we’ll go more into detail in the second part of the article discussing the actual contents of room data sheets.