Feedback

Connections, Comparisons, And Feedback Directions

The mere existence of a brief and a design in the same project is an invitation to compare the two. Feedforward makes this even stronger, as it provides a direct, explicit, and unambiguous connection between the two. This connection makes evident not only what should be compared but also how: the accommodation of required activities by their presence in the design, direct access between two activities by the existence of a door or similar opening between the two corresponding spaces, required areas by comparing them to the areas of spaces, and so forth. Such comparisons trigger feedback: they may reveal mismatches that could be reasons for change, as well as give indications concerning what could be altered, how and why. In all cases, changes aim to improve the results of the comparison. It is therefore easy to verify that these changes were appropriate or fruitful by repeating the comparisons and seeing of the results have improved. Such iterations are a primary reason why we talk of ‘cyclical design processes.’

So, once a brief and a design have been properly connected along the lines discussed in Chapter 7, you can compare the two, evaluate your findings and, if necessary, feed your conclusions back to the appropriate information source. There, the difference between expectation and results should cause an action, usually an adjustment such as an increase of the floor area allocated to an activity in the design. It is often assumed that feedback is directed towards the design. This is a consequence of the timing of feedback and an already mentioned misconception concerning the brief: feedback obviously presupposes a design, which means that feedback takes place well past the briefing stage and within or after the design stages, when the brief is generally treated as a fixed, static specification, while the design is the objective. Any comparison and analysis is therefore usually directed towards the design, even if it involves partial rejections of the brief. After all, the brief only plays a supporting role in the production of buildings, while the design is the main specification. Moreover, a brief that requires a major revision in the design stage must surely be a very poor one.

However, there is no reason why you should consider a brief as a finished, fixed product, especially after we have taken the trouble to computerize it. Either in a database or in BIM, brief requirements are easily adaptable and responsive to readjustments in client, use, and design approaches. Even the best brief can use incidental, local improvements on the basis of solutions reached in a design. Refusing to implement these improvements simply reduces the potential of the brief and consequently also the performance of the design. You should therefore treat any significant conflict between brief and design either as a design flaw or as a shortcoming of the brief and direct feedback accordingly (Figure 1). It is also possible that adjustment in both the brief and the design improves matters more than a modification in either of the two.

Figure 1.

Possible feedback directions following comparison between brief and design

The ease with which brief databases and design representations can be adapted should not be confused with the significance of the changes. Some modifications can be very simple and local, while their implications for the design or brief are extensive and substantial. It is therefore important to evaluate the meaning and consequences of a conflict between brief and design before committing to any form of feedback. First of all, there are cases where the brief and the design express diametrically opposite views, (e.g., strong preference for different solution types such as low-rise versus high-rise housing). These cannot be solved through simple feedback, but feeding the results of a comparison back to the brief and the design can help identify the extent of the conflict and through this possible causes and effects.