Learn to surf before riding the AI wave
1 December 2025
The usability gap: why compliance is not enough
4 December 2025
The built environment is caught in a project-operations gap caused by the prioritisation of technical compliance of data over operational usability of that data. Justin Kirby sets out his human-centred solution to the issue.
The built environment faces a systemic and stubborn problem: despite decades of technological and standards progress, the industry still often struggles to hand over digital systems and data streams that genuinely work for the people who operate, maintain and occupy the built environment. We are caught in a project-operations gap that has persisted for decades. This is the definition of structural inertia – we do the same thing over and over, invest heavily in compliance, yet expect a different operational outcome. Cultural change will not occur while the lived experience of the process remains the same.
My engagement in this sector has been driven by the need to address this persistent friction point. This diagnosis is the result of 3.5 years of extensive stakeholder engagement and research. The industry is stuck because we confuse information management with human-centred design (HCD). The core problem is that we are prioritising technical compliance over operational usability.
The structural failure: compliance vs usability
At its core, the problem is a structural and cultural failure that allows the project mindset to remain dominant. Information management is heavily funded by construction budgets (capex) to ensure technical compliance and deliver a contractual asset. Conversely, HCD, which prioritises operational usability, is largely ignored as an upfront investment.
In a right-to-left design strategy, HCD should be an upfront investment to design the building for optimal use – this is ‘product thinking’. Instead, the failure to integrate this cost means operational budgets (opex) are left to pay for the consequences of project failure (reactive troubleshooting, asset degradation, energy waste, etc). This structure maintains the focus on the contractual deliverable rather than on long-term operational value.
The widespread belief that following ISO 19650, or the plethora of existing technical standards and professional frameworks, solves the operational data problem is fundamentally misguided. These standards are structurally insufficient to solve it on their own, focusing only on managing data supply. They do not address the demand side – how a human operator interacts with that data under pressure. Crucially, they lack the mechanism to enforce the cultural shift required for agile, user-centric practice. The repeated creation of ever more compliant standards does not change the underlying mindset problem or deliver the required change in practice.
Information management: the technical asset and its mindset
The information management approach is dominated by the project mindset, focusing on compliance and technical documentation. Its goal is a data asset that is technically complete. This validation is simple: is the data structured correctly?
HCD: the usable tool and the product mindset
In contrast, HCD is a design philosophy that enables the product mindset, focusing on usability and process design. This approach is highly relevant because it serves the operational mindset (the pragmatist), who must ensure the building runs efficiently. HCD’s output is a usable tool that is actionable and efficient. This validation is complex: it demands testability – does the data flow enable the user to complete the task and achieve the operational outcome?
Because projects stop at information management validation, we hand over data that may be technically accurate but is far too often operationally unusable. This creates the usability gap. The traditional waterfall construction process cannot accommodate the agile, iterative testing required by modern digital systems. This structural failure prevents the necessary cultural shift from the project mindset to the product mindset.
The minimum data handover requirement
To close this gap, we must stop treating data as just a compliance deliverable and start treating it as a testable product as well. This requires a fundamental shift, moving information management from a destination to the technical servant of HCD. The proposed solution is the minimum data handover requirement (MDHR), applied during commissioning as a minimum viable product.
The MDHR requires projects to shift the definition of ‘done’ from:
- the old way – “We transferred the files, and the data is compliant”;
- to the new way – “The operational team successfully completed a core maintenance task using the live information system”.
This introduces the missing link – the mandatory prototyping and testing phase. This ensures data is verified against human need, not just technical schema. This small, upfront HCD effort provides the lived experience of testability necessary to initiate a cultural shift, thereby eliminating significant downstream operational liabilities. In this sense, the MDHR is a form of digital soft landings.
Scenarios: usability in practice
Scenario 1: the blind technician (maintenance)
The user is a mobile technician tasked with diagnosing an alarm and ordering a filter quickly.
- Compliance failure: data provided is “Refer to O&M Manual Vol 4.” Result: two hours wasted measuring the filter. The data was compliant, but utterly useless.
- MDHR success: data provided is specific: “Bag Filter F7 592×592.” Result: Task done in 10 minutes. The data was treated as a testable product.
Scenario 2: the phantom load (energy)
The user is an energy manager tasked with identifying why the building used 400kW when it should have been empty.
- Compliance failure: the manager downloads two separate csv files (metering and BMS), but timestamps don’t align. Result: four hours spent manually fixing data in Excel. Energy waste remains ambiguous.
- MDHR success: the manager opens a single dashboard overlaying “BMS Enable Signal” (Off) vs “Power Draw” (On). Result: a rogue chiller in manual mode is identified in minutes. Integrated, usable data delivered immediate, actionable insight.
Contractual requirements
The MDHR framework provides the foundation and practical test scripts required to plug the usability gap. This framework offers a minimum viable solution that embeds the practice of agility directly into the project lifecycle.
The persistent nature of the project-operations gap proves that a different approach is necessary. Relying on the continued creation of ever more compliant standards and frameworks alone is not going to work. We are caught in the definition of insanity: doing the same thing over and over, yet expecting a different operational outcome. Therefore, we must think differently and try something testable. If MDHR proves right – if our prototypes are validated – it not only helps solve the immediate problem, but starts to embed more agile practice as a lived experience.
The logical next step in this design process is to move to the prototyping and testing phase. One way to achieve this is by factoring pilots into overall project budgets to validate the MDHR hypothesis. Furthermore, integrating MDHR testing into performance-based and extended soft-landing contracts provides the clearest funding pathway to demonstrate the model.
Plugging the usability gap, therefore, requires demanding data as a testable product and making user validation a contractual requirement. The evidence gathered from these pilots, combined with research into existing best practice, will form the foundation for a fully defined MDHR playbook – the ultimate destination for scaling this approach. This embeds HCD principles, initiating the cultural shift needed to ensure the next generation of smart buildings truly work seamlessly for the people who run and use them.
Keep up to date with DC+: sign up for the midweek newsletter.
Story for Digital Construction Plus? Get in touch via email:
[email protected]
