Even though the world around us is changing rapidly, our buildings do not. Buildings do not have the ability to transform from one configuration into another. Perhaps the most important reason for that is that they are not designed for such changes. Designers typically regard buildings as static structures and ignore that businesses grow, shrink or go bankrupt, that people age and family compositions change, and that innovative technologies replace older ones. But new usages persistently reshape or retire buildings anyway, which then unavoidably results in excessive amounts of waste. As just one step towards the design of more transformable buildings, we have been developing software that can provide designers with interactive feedback on the topic.
“Almost no buildings adapt well. They’re designed not to adapt; also budgeted and financed not to, constructed not to, administered not to, maintained not to, regulated and taxed not to, even remodeled not to. But all buildings (except monuments) adapt anyway, however poorly, because the usages in and around them are changing constantly.”
It is a fundamental design flaw that buildings are not being designed to cope with change. The result is that most buildings have, what we propose to call, low ‘transformation capacity’. The transformation capacity of a building indicates the ability of a building design to deal with functional, technical or physical changes without generating material waste. A design with a higher transformation capacity implies lower environmental impact from changing building configurations. In this research project, we explore how designers can get interactive feedback on the transformation capacity of a design-in-progress during the draft design stage.
Design-science research
To deal with this problem, we took an approach based on the design-science paradigm. This is a kind of research in which “knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact” (Hevner, 2004). The ‘artifact’ (here: the software) takes a central position in design-science research. Only after (I) borrowing rigorous theories, methods and experience and (II) identifying relevant potentials to improve the problem area, it is possible to (III) create and (IV) evaluate that artifact. That is graphically represented as follows.
(I) Rigor – knowledge base
The parameters, rules and constraints that determine the transformation capacity of a building are still being studied. Earlier works, however, provided points of departure. Brand (1994: p.192), for example, suggested that the only configuration of space that can deal with change well is the rectangle as it “grows well and subdivides well and is really efficient to use.” This would imply that spaces with a rectangular shape should score higher in terms of transformation capacity. A research-through-design project I wrote about earlier also helped to understand how the position of the ‘core’ structure of a building enables or limits transformations. Other valuable points of departure were the work of Habraken (1998) and the knowledge model based on the disassembly potential of building structures from Durmisevic (2010). For the first iteration, the knowledge base was concretized by considering just one transformation model of 12x12m with an inner core.
(II) Relevance – application domain
The people, organizational systems and technical systems interacting towards a goal together make up the application domain. We tried to get a better understanding of the domain by interviewing an architect about the techniques and procedures used in design. According to Cross (2011: p.4-5), interviews are a common method for researching ‘design thinking’. The main lessons from the interview were that architectural design (1) starts with an extensive analysis of the context of the building, (2) considers many iterations driven by creativity, and (3) is resistant to the adoption of new (ICT) tools that may limit design freedom.
“There’s always an urge within creatives to be innovative and to see if there’s a different solution. That’s kind of the DNA of a creative person.”
Architect
The interview results were considered as initial input requirements from the application domain. It was decided to base the artifact-to-be-created on SketchUp, since this software enables one to create and modify shapes in a very intuitive manner (which is very important in the draft design stage). Its major limitation is that the resulting 3D models are non-parametric: they just consist of geometry without any additional information (such as materialization).
(III) Creation
A first step was then made in the creation of a prototypical artifact: a dynamic and extendable software framework that communicates with SketchUp. For reasons of efficiency and modularity, the software architecture of this artifact, the so-called ‘virtual simulator’, makes a distinction between four layers: integration, preparation, manipulation and visualization. The user interacts with the prototype by clicking a button in SketchUp. The software then identifies those building elements that limit the ability to change the building configuration of that model and presents the feedback to the user. Behind the scenes, the SketchUp data is send to and received from the prototypical framework (in which all calculations are made).
Credits for the software engineering go to Usama, visiting student/researcher from Egypt.
(IV) Evaluation
The prototypical software was presented and evaluated at an international workshop with experts in the domains of (among others) software engineering, architecture and construction management science. Most participants were rather positive about the prototype, honoring its modular design and usability. However, they were completely right to identify two major limitations. First, the prototype essentially compares one design proposal with seven theoretical ‘ideal’ configurations while there are obviously many more possible. Second, the choice to use a non-parametric tool (SketchUp instead of any BIM software) unnecessarily complicates the transformation capacity calculations behind the scenes and limits the possibilities to transfer data to ‘smarter’ (design) applications.
Very original and useful tool
Workshop participant (#8)
The premise of the measuring algorithm is based on locating deviation from a specific preset, presumed to be the ‘perfect solution’. Such a tool would stimulate all design to be the same, completely generic.
Workshop participant (#15)
Did you investigate going the other way around: simplifying Revit instead of complexifying SketchUp
Workshop participant (#7)
Discussion
The first steps of this design-science research have been completed. More iterations and developments are currently being undertaken. We hope that our efforts ultimately lead to an artifact that informs the existing knowledge base with new insights and improves the application domain by supporting transformable building design.
Do you have any questions or supportive ideas? Let me know by writing a comment below!