Validation, verification, design

Validation, verification, design 

I often find myself entangled in discussions on what a brief is, what it does, how a design is structured with respect to a brief and all kinds of rather unproductive situations. Many of them derive from my own stubborn interest in terminological clarity and consistency, which may conflict with established terms and their use. Nevertheless, I don't intend to stop. I see what happens in other areas and it makes me believe that terminological clarity is a good indication that an area knows what it is doing and why (methodological clarity and relevance). So, I wonder what we are doing in architecture to validate and verify a design.

To be clear about the terms I'm using, validation refers to whether the design solves the original problems and validation to whether the design meets the specifications set up for solving the problem. In other words, it goes like this: we identify a problem, then we set some specifications for the designs that should solve it and then we make designs on the basis of this specification. In architecture the specifications (the brief) are often put aside and designers address the problem itself. This may indicate poor specifications or bad designer attitudes; in either case, it's a sign of a poorly operating field. Both verification and validation are necessary when it comes to testing the utility of a design as well as establishing and extending domain knowledge.

A practical example: accessibility is an undeniably serious issue in architecture. To ensure accessibility in a design we have all kinds of rules and regulations that specify constraints on spaces and building elements like the width of corridors or doors. A design can be evaluated against such constraints and so verified as an adequate solution to accessibility. However, it is also important to see if the building is also accessible by really testing it with respect to the movement of people with disabilities or spatial needs. Validation can make evident that e.g. additional constraints are required or that some constraints contribute little. We shouldn't assume that the ones we have been using are right or sufficient. Just think of Blondel's formula for stair design, which is seldom if ever challenged: 2 x riser + tread = step length. Why do we assume that it suffices for the design of safe and comfortable stairs? My own experience tells me that if a tread is not deep enough for my 46-size shoes, descent can be a problem.

I don't walk like that

I don't walk like that 

Some time ago I was testing a fire egress calculation program and was quite shocked by the routes it calculated: the lines seemed to bounce from one wall to another, generally moving in the right direction but rather blindly or perhaps drunkenly. It was comical in its deviation from what we consider normal behaviour. My immediate reaction was to think: I don't walk like that, do I?

It's undeniable that our movement in space is not as smooth and purposeful as we want to imagine. One only needs to observe how people walk in a crowded public corridor, e.g. in a train station. It's a matter we should address in architecture and allow for more fuzziness and chaos in human interaction with buildings. Textbooks are full of certainties and crisp, tight values for everything. More room for error and uncertainty would arguably make the built environment more humane.

On the other hand, computer analyses and simulations have to become more meaningful and reliable. At the moment it seems that anything goes. Much from what I see is based not on scientific knowledge but derives from basic, often outdated textbooks and easy, unsupported assumptions. With simulations of natural phenomena (light, air, temperature etc.) one requires validation but with human interaction anything plausible is just accepted.