Routledge Revivals

Architectural Programming
and Predesign Manager

In this book, first published in 1999, Hershberger presents architectural programming

and predesign management in a clear, detailed manner. With numerous examples and
illustrations from both his and his colleagues’ experience, he shows the reader step by
step how to use the techniques of architectural programming, setting values, resolving
issues, applying tested methods, and leveraging skills when working with clients. This
title will be of interest to students of architecture.
This page intentionally left blank
Architectural Programming
and Predesign Manager

Robert G. Hershberger
First published in 1999
by McGraw-Hill Companies, Inc.
This edition first published in 2015 by Routledge
2 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN
and by Routledge
711 Third Avenue, New York, NY 10017
Routledge is an imprint of the Taylor & Francis Group, an informa business
© 1999 Robert G. Hershberger

The right of Robert G. Hershberger to be identified as author of this work has been asserted by him in
accordance with sections 77 and 78 of the Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this book may be reprinted or reproduced or utilised in any form or by
any electronic, mechanical, or other means, now known or hereafter invented, including photocopying
and recording, or in any information storage or retrieval system, without permission in writing from
the publishers.

Publisher’s Note
The publisher has gone to great lengths to ensure the quality of this reprint but points out that some
imperfections in the original copies may be apparent.

Disclaimer
The publisher has made every effort to trace copyright holders and welcomes correspondence from
those they have been unable to contact.

ISBN 13: 978-1-138-18353-7 (hbk)

ISBN 13: 978-1-315-64572-8 (ebk)
Architectural Programming
and Predesign Manager

Robert H e rs h b e rg e r, Ph.D., FAIA

Library of Congress Cataloging-in-Publication Data

Hershberger, Robert G.
Architectural programming and predesign manager / Robert G.
Hershberger,
p. cm.
Includes bibliographical references and index.
ISBN 0 - 0 7 - 1 3 4 7 4 9 - 6
1. Architectural design— Data processing. 2 . Computer-aided
design. I. Title.
N A 2 7 2 8 .H 4 7 1999
7 2 0 — d c2 1 99.14447
CIP

McGraw-Hill
A Division of The McGraw-Hill Companies

Copyright © 1 9 9 9 by The McGraw-Hill Companies, Inc. All rights reserved.

Printed in the United States of America. Except as permitted under the United
States Copyright Act of 1 9 7 6 , no part of this publication may be reproduced
or distributed in any form or by any m eans, or stored in a data base or re­
trieval system , without the prior written permission of the publisher.

2 3 4 5 6 7 8 9 0 DOC/DOC 0 4 3 2 1 0

P/N 1 3 5 2 1 8 - X
PABT OF
ISBN 0 - 0 7 - 1 3 4 7 4 9 - 6

The sponsoring editor for this book was Wendy Lochner, the editing supervisor
was Andrew Yoder, the copy editior was Audrey Brichetto Morris of the
Herberger Center for Design Excellence of Arizona State University, and the
production supervisor was Pamela A. Pelton. It was set in MattAntique by Lisa
M. M ellott through the services of Barry E. Brown (Broker— Editing, Design
and Production).

Printed and bound by R.R. Donnelley & Sons Company.

McGraw-Hill books are available at special quantity discounts to use as

premiums and sales prom otions, or for use in corporate training programs. For
more inform ation, please write to the D irector of Special Sales, McGraw-Hill,
Two Penn Plaza, New York, NY 1 0 1 2 1 - 2 2 9 8 . Or contact your local bookstore.

^ ^ This book is printed on recycled, acid-free paper containing a mini­

mum of 5 0 % recycled de-inked fiber.

Inform ation contained in this work has been obtained by

The McGraw-Hill Companies, Inc. (“M cGraw-H ill”) from
sources believed to be reliable. However, neither McGraw-
Hill nor its authors guarantees the accuracy or completeness
of any information published herein and neither McGraw-
Hill nor its authors shall be responsible for any errors, omis­
sions, or damages arising out of use of this information. This
work is published with the understanding that McGraw-Hill
and its authors are supplying information but are not at­
tempting to render engineering or other professional ser­
vices. If such services are required, the assistance of an
appropriate professional should be sought.
 Dedication
This book is dedicated to my wife, Deanna, and our children, Ver­
non and Andrew, who have given me both the love and encour­
agement that I needed to persevere for the twenty-three years that
this book has been in process.
This page intentionally left blank
 Contents

Foreword ix
Preface xiii
Acknowledgments xvii

Cha pter 1: Arch itectu ra I Prog ra m mmg 1

1.1 The Nature of Architectural Programming 1
1.2 Definitions of Architectural Programming 4
1.3 Approaches to Architectural Programming 6
1.4 Design-Based Architectural Programming 7
1.5 Knowledge-Based Architectural Programming 14
1.6 Agreement-Based Architectural Programming 17
1.7 Value-Based Architectural Programming 25
1.8 Exercises 35
1.9 References 36

Chapter 2: Values and Architecture 41

2.1 Importance of Values 41
2.2 Enduring Values of Architecture 42
2.3 Contemporary Values of Architecture 53
2.4 HECTTEAS (TEST EACH) 56
2.5 Case Study: Alleluia Lutheran Church 57
2 .6 Case Study: Hershberger Residence 60
2 .7 Exercises 70
2.8 References 71

Chapter 3: Values Become Issues 73

3.1 Human Issues 75
3.2 Environmental Issues 89
V
yj Contents

3.3 Cultural Issues 108

3 .4 Technological Issues 123
3.5 Temporal Issues 132
3 .6 Economic Issues 140
3.7 Aesthetic Issues 145
3 .8 Safety Issues 161
3 .9 Exercises 167
3 .1 0 References 168

Chapter 4: Preparing to Program 171

4.1 Pre-Design Services 171
4.2 Architectural Programming 180
4.3 Discovering Critical Issues 181
4.4 Program Planning 182
4.5 Exercises 190
4.6 References 191

Chapter 5: Information Gathering 193

5.1 Literature Search and Review 195
5.2 Diagnostic Interviewing 219
5.3 Diagnostic Observation 246
5.4 Questionnaires and Surveys 273
5.5 Site and Climate Analysis 306
5.6 Exercises 313
5 .7 References 317

Chapter 6: Work Sessions 321

6.1 Client/User Work Sessions 323
6.2 Executive Work Sessions 331
6.3 Work Session Setting 334
6.4 Matrix Development 335
6.5 Presentation Methods 346
6.6 Requirement Sheets 359
6.7 Exercises 364
6.8 References 365

Chapter 7: Program Preparation 367

7.1 Program Form 368
7.2 Program Content 369
7.3 Preliminaries 370
 Contents

7.4 Executive Summary 372

7.5 Values and Goals 375
7.6 Design Considerations 376
7 .7 Project Requirements 382
7.8 Space Identification and Allocation 390
7.9 Relationship Matrices and Diagrams 395
7 .1 0 Space Program Sheets 404
7.11 Budget and Cost Analysis 406
7.12 Project Schedule 415
7 .1 3 Design Analysis 418
7 .1 4 Appendix 430
7 .1 5 Exercises 431
7 .1 6 References 432

Chapter 8 : Methods o f Evaluation 435

8.1 Program Evaluation 436
8.2 Design Evaluation 446
8.3 Building Evaluation 44 8
8.4 Body of Knowledge 451
8.5 The Next Commission 452
8 .6 Exercises 453
8 .7 References 454

Appendix: Sample Architectural Programs 457

A .l The Planning Department,
The University of Arizona 457
A. 2 Mikvah for an Orthodox Jewish Congregation 470

Index 487
This page intentionally left blank
 Foreword

hroughout a long and distinguished career as an educator, a

T significant piece of which was at Arizona State University in

the College of Architecture and Environmental Design (of which I
am currently the Dean), and then most recently at the University
of Arizona (where he has only recently stepped down as Dean),
Bob Hershberger has sustained in parallel an active architectural
practice. This volume draws richly from this joint background.
Donald Schoen has written vividly of the need for reflective prac­
tice. Perhaps no one should feel more powerfully that challenge
than the educator/practitioner. In this book we all benefit from
Dr. Hershberger’s reflections on a career that has included the rig­
orous research required for his Ph.D., the careful structuring re­
quired to transform students into professionals, and his own
work as a practicing architect.
I should declare immediately that I am the direct beneficiary of
Bob Hershberger’s efforts. For a brief period he was my Associate
Dean before the University of Arizona called. The new addition to
our College of Architecture and Environmental Design celebrates
through the work of Alan Chimacoff of the Hillier Group an ex­
traordinarily thoughtful program for which Bob Hershberger and
Tim McGinty provided the major effort and guidance. And every
day of my working life is spent in the context of Bob Hersh­
berger’s two efforts on Mill Avenue in Tempe, both of which are
described in this book. I am referring to his influence that caused
the city fathers to rethink their plan to bulldoze Mill Avenue,
which was then replaced with a much more responsible plan to
honor the historic heritage and create a richer and far more hu-

ix
X Foreword

mane urban center. I also enjoy my daily salute to the Alleluia

Lutheran Church on Mill Avenue where the existing modest house
became the springboard for his design of the sanctuary.
This book is a contribution to the literature on programming
and acknowledges its debt to its predecessors, most notably the
work of William Pena whose series of volumes, all of which have
the phrase “Problem Seeking” in their title, began in 1969. Other
names familiar from the literature, such as Henry Sanoff, Wolf­
gang Preiser, and Mickey Palmer are invoked, as are institutions
such as the ALA and GSA who have helped define the current
practice.
This book differs, however, in several respects. First, it is
clearly intended primarily as a text to be used in an educational
setting. Second, it is much more discursive and inclusive, draw­
ing heavily on the author’s academic and professional experi­
ences. Third, and most significantly, it emphasizes the
qualitative, or value, issues as having priority while accepting as
a competent professional that there remain quantitative, and par­
ticularly economic, realities that must be addressed.
As a text I suspect the book will be easy to use. The eight chap­
ters relate nicely to a sixteen-week semester. The exercises at the
end of each chapter are valuable pedagogical tools. And the in­
structor will be able to develop an interesting dialogue with the
voice and ideas of the author. The voice, and those ideas, lend a
personality to the text. The reader gets to know and admire the
author as a reflective practitioner and a natural teacher, whose
own values of respect and caring for his clients and his students
are transparent.
Ever since Amos Rapoport wrote House Form and Culture, ed­
ucators have been appropriately loath to refer to climate, site,
technology, and use, as “determinants” of architectural form. Let
me quote:
My basic hypothesis, then, is that house form is not simply the
result of physical forces or any single causal factor, but is the con­
sequence of a whole range of socio-cultural factors seen in their
broadest terms. Form is in turn modified by climatic conditions
(the physical environment which makes some things impossible
and encourages others) and by methods of construction, materials
available, and the technology (the tools for achieving the desired
environment). I will call the socio-cultural factors primary, and
the others secondary or modifying.
 Foreword xi

Given a certain climate, the availability of certain materials,

and the constraints and capabilities of a given level of technology,
what finally decides the form of a dwelling, and moulds the
spaces and their relationships, is the vision that people have of
the ideal life.
Amos Rapoport was writing primarily about buildings that
were the product of what he calls the “preindustrial vernacular.”
That is to say, buildings that may have been built by craftsmen
but were not the conceptual products of professional architects. I
see this book as an effort to bring to the self-conscious work of the
architect a similar priority of cultural value.
One of the questions that is always raised when programming is
discussed is whether programming and design are necessarily sep­
arate and sequential activities, and the corollary question of
whether the programmer and the designer can or should be the
same individual. This book does not firmly answer those ques­
tions, while it does discuss the pros and cons behind them. As an
architect who often has designed the buildings he has pro­
grammed, and who is intimately familiar with the dialogue that can
be so fertile between program and design, Bob Hershberger clearly
does not fit in the camp of those who would hold them firmly sep­
arate. Indeed, as a student, he studied under Louis Kahn, whose
building designs are as much an interrogation of the program of an
institution as they are a consequence of that program.
In closing, I have a suggestion as to how to read this book. I
would start at the end, with the two sample programs. In partic­
ular I would start with the program for a Mikvah for an Orthodox
Jewish Congregation. Dr. Hershberger is not an Orthodox Jew, in­
deed a significant part of his practice has been churches for the
Christian faith that informs his life and values, but in this pro­
gram there is evidence of the profound respect for the values of
the institution which is being served. That is the very center of
what this book is about. Having come to terms with it, one can
turn with profit back to the beginning to follow the logic of the
text in the comfortable company of its estimable author.
John Meunier
July 1 9 9 7
This page intentionally left blank
 Preface

his book is intended to be a teaching/learning tool-a text/

T workbook that can be used in the college classroom to help

students in architecture and other environmental design disci­
plines learn a sound basis for architectural programming. It will
also be useful in the architectural office for practitioners who
have not had sufficient educational background in architectural
programming. Each reader can learn from the text about the the­
oretical and methodological aspects of programming and employ
the suggested exercises to develop needed programming skills.
The intent of the book is to provide a strong philosophical ba­
sis and the appropriate methodology for programming that begins
the process leading to architecture—buildings that accomplish the
goals, meet the needs, and express the highest and most appro­
priate values of the clients, users, and architect to become works
of art.
Because of its emphasis, the book should appeal to architects,
architectural designers, architectural educators, and architectural
students. Interior designers, landscape architects, and urban de­
signers should also find this programming approach to be useful
as they endeavor to create works of art in their own areas.
The book will also prove of interest and use to behavioral and
social scientists engaged in architectural programming because
the philosophical basis is not alien to their objectives, and the
methodologies are decidedly biased toward those used by behav­
ioral and social scientists. They will find themselves on familiar
ground during discussions of literature search and review, obser­
vation, interviewing, questionnaire preparation, sampling, and

xiii
the like. They will also find the emphasis on values to be of cur­
rent interest in their own fields.
The point of view offered is that effective architectural pro­
gramming can enhance the quality of design, and conversely that
some programming approaches actually inhibit quality design.
Those methods of programming that focus only on the collection
of facts and figures about the presumed needs of the client or user
group are likely to miss the most important information for de­
sign: values and goals. Without an initial understanding of these
areas, there is a very high probability that many of the collected
facts and figures will be irrelevant and misleading. The important
values and goals must be identified for the programmer to know
what facts and figures need to be articulated in the program. The
designer, on the other hand, needs values and goals to know on
which areas to focus the design effort. The designer can also use
the expressed values and goals to evaluate the appropriateness of
various design decisions. The behavioral scientist needs to under­
stand the values and goals for meaningful post-occupancy evalu­
ation.
The intent, therefore, is to provide the reader with a text/
workbook that articulates a sound and general basis for architec­
tural programming and sets forth the fundamental methods, tech­
niques, and tools to be utilized. It differentiates itself from other
texts and publications currently available in this area by:
1. Providing an extended theoretical discussion of the reasons
for preparing an architectural program.
2. Stressing the importance of value identification prior to es­
tablishing specific program goals and requirements.
3. Covering in some depth the most essential and general pro­
cedures for developing programming information
4. Showing how work sessions can be used effectively at the
conclusion of information gathering and the beginning of
program preparation.
5. Showing what program documents should contain and how
to assemble them.
6. Introducing specific exercises by which the reader can de­
velop the skills necessary to do quality architectural pro­
gramming.
 7. Demonstrating how such an approach can help architects
evaluate, and hence improve, their design solutions.
8. Providing two excellent examples of program documents in
the appendix to show the reader how a final program docu­
ment should be presented.
Finally, the organization of the text and abundance of illustra­
tions should make reading both easy and enjoyable for those in or
aspiring to be in a visually oriented design profession. They
should find this book of use in their endeavor to create architec­
ture.
This page intentionally left blank
 Acknowledgments

s an architectural student I did not take a course in archi­

A tectural programming. I was given the program, usually a

brief one, by the studio instructor and was expected to begin to
design. However, like other students in the typical five-year ar­
chitectural program, I was required to do research and write a
program for my bachelor’s thesis. I selected a two-year medical
school for my project, and in the process of literature review dis­
covered Louis I. Kahn and his seminal work on the Richards
Building at the University of Pennsylvania. I was amazed at the
depth of his thinking about architecture, not just design but also
questions about the nature of form and its relation to human in­
stitutions. I decided that I should study under this master archi­
tect and teacher. I must acknowledge the seed that he planted as
he considered with his students the essential nature of various de­
sign projects—a house in Chestnut Hill, a consulate for Angola, a
river boat on the River Thames and finally the Salk Center. It
started me thinking about the nature of architecture. My sincere
thanks to Louis I. Kahn.
In my first teaching job at Idaho State University, I regularly
ate lunch in the Faculty Club where, to my constant amazement,
I listened to other faculty talk about their research, statistics and
the like. I found their conversations stimulating and baffling, be­
cause my education had practically nothing in these areas. The
University of Pennsylvania had just begun a Ph.D. program in ar­
chitecture, so I decided to go back and learn about research, es­
pecially as it might apply to architecture. This time I discovered
Russell Ackoff, professor and head of Operations Research. He

xvii
X y jjj A c k n o w le d g m e n ts

had graduated in architecture, but had found research more to his

liking. He applied the problem solving mentality of the architect
to this new field. His work and teaching were fascinating because,
like Kahn, he looked beyond the obvious for the profound—for
understanding, not just description. I gratefully acknowledge his
influence on my way of thinking. Dean G. Holmes Perkins rein­
forced this type of thinking as he guided me through my disserta­
tion study on Architecture and Meaning. His incisive directions
and insistence that I manage the scope of the research also greatly
contributed to how I think. I acknowledge and thank him. He is
my model of a fine human being and an outstanding educator and
administrator.
I presented my dissertation research at one of the first meet­
ings of the Environmental Design Research Association (EDRA) in
Blacksburg, Virginia. Here I met other architects and social scien­
tists interested in research questions in architecture. A few, like
Gerald Davis and Jay Farbstein, were practicing as architectural
programmers. I have been greatly influenced by a number of these
people including Walter Moleski, Robert Bechtel, John Zeisel,
Kent Spreckelmeyer, and Wolf Preiser, to name a few. Returning to
the annual EDRA conference every year for ten or more years in­
fluenced my thinking a great deal.
After receiving my Ph.D. at the University of Pennsylvania, I
took a position as Associate Professor at Arizona State University
where I began teaching research methods and architectural pro­
gramming. I also began teaching design with Calvin C. Straub,
who became a personal mentor. His devotion to site analysis and,
especially, client/user analysis greatly influence how I think, how
I teach design, and especially how I have come to think about and
teach architectural programming. I especially acknowledge his
contribution to this book.
And, of course, a professor’s best teachers are students. I
greatly appreciate the education that they have given to me. I es­
pecially acknowledge how their insights and concerns have grad­
ually shaped the text on programming to its present state. I have
been able to include some of their work in the text, but there has
been so much more that could not be included. Thank you every­
one. Your contributions are most appreciated. Similarly, the prac­
ticing professional’s best teachers are clients! They often selected
my firm because it offered programming services. I have had
many outstanding clients and acknowledge their contribution, es­
 A ckno wledgm ents

pecially how they showed me that “values become issues,”

whether we want them to or not. They taught me how to program.
I began working on this book in the summer and fall of 197 6 .
The book took second place to an active programming and design
practice for about ten years, but was nearly complete when I left
Arizona State University in 1988 to become Dean of the College
of Architecture at The University of Arizona. I team-taught pro­
gramming that spring with Susan Moody, who then taught the
course for the next seven years using my nearly complete docu­
ment. I very much appreciate the insights that she and her stu­
dents gave me from that time period.
I thank Chuck Hutchinson for his encouragement and good ad­
vice over the years. I also thank Donna Duerk, Kent Spreck-
elmeyer, Wolf Preiser, and Walter Moleski for being thoughtful
reviewers of the manuscript in its various stages. I deeply appre­
ciate the thoughtful foreword by Dean John Meunier of Arizona
State University. I thank Carl Okasaki for the many excellent
sketch illustrations, Nancy Cole for her computer graphic images,
and Claudette Barry for initial editing of the manuscript. I espe­
cially thank Audrey Brichetto Morris of the Herberger Center for
Design Excellence at Arizona State University for her exception­
ally thoughtful copyediting of the final manuscript. I stand in awe
of her special abilities in this area. I am equally impressed with
the expertise of Kelly Ricci, Lisa M. Mellott, Nadine McFarland,
and Toya Warner of Barry E. Brown, Broker, in designing, format­
ting, layout, and graphic design of this book. Finally, I want to ex­
press appreciation to Mary Kihl, Director of the Herberger Center,
and Wendy Lochner, Architectural Editor for McGraw-Hill, for
their timely and incisive answers to my many questions about
how to get the book published. Thank you all!
A b o u t th e A u th o r
Robert Hershberger is a professor and dean emeritus of the Col­
lege of Architecture at the University of Arizona in Tucson and a
practicing architect who has won numerous design awards. He is
a fellow of the American Institute of Architects.
 vjz
Architectural Programming

1 .1 The Nature of Architectural Programming

1.2 Definitions of Architectural Programming
1.3 Approaches to Architectural Programming
1.4 Design-Based Architectural Programming
1.5 Knowledge-Based Architectural Programming
1 .6 Agreement-Based Architectural Programming
1 .7 Value-Based Architectural Programming
1.8 Exercises
1 .9 References

1.1 The N ature o f A rc h ite c tu ra l Programming

Programming is the first, and perhaps the most important, stage
in the architecture delivery process. Whether provided as an inte­
gral part of professional architectural services, as an additional
service, or not consciously provided by anyone, programming
takes place at one level or another in the interaction of the client,
users, and the architect.

Programming is the definitional stage of design— the time to dis­

cover the nature of the design problem, rather than the nature of
the design solution.

The programming stage is a crucial time in which serious mis­

takes can happen or insightful, formative decisions can be made.
The implications for the design solution are as enormous as the
differences between the Taj Mahal (Fig. 1-1) and a car wash (Fig.
1-2). Both are appropriate architecture for very different problems.

1
2 A rch itectu ra l Programming and Predesign Manager

Figure 1-1 Taj Mahal.

Photo Credit: Calvin C. Straub

Figure 1-2 Weiss Guys Car Wash.

 Architectural Programming 3

It is the nature of the problem as expressed in the architectural

program that has the most profound effect on the design solution
in architecture. As one outstanding architect and educator, Calvin
C. Straub, FAIA, stated (1980):

“The program is the design!”

He was not implying that the talents of the design architect are
of little consequence, but that many of the most important “for­
mative” decisions are made before the architect begins to design.
For instance, the decision may have been reached to have only
one building instead of two; or an auditorium within the fabric of
a larger building rather than freestanding on its own site; or of­
fices in a building separate from the classrooms, or vice versa.
The budget could be set so low as to preclude any number of de­
sign opportunities, or the time span for completion of the design
and construction could be so short that only the simplest of forms
could be utilized in order to finish on schedule.
If the client and programmer are primarily interested in func­
tional efficiency, organizational and activity decisions may be made
that could significantly affect the form of the building. If the client
and programmer are more concerned with the social and psycho­
logical needs of the users, prescriptions for form may be inherent in
the listed spaces, sizes, characteristics, and relationships. If they are
concerned with economics, it is possible that numerous material
and system opportunities, as well as potentially unique spaces and
places, will be eliminated from design consideration. Conversely,
for any of the above illustrations, the lack of concern for and infor­
mation on important design issues may restrict the designer’s op­
tions. The point is that the values and concerns of the client and the
programmer will have a significant impact on the form of the build­
ing, because they choose the information presented to the designer.
Some architects have expressed concern that poorly conceived
programs limit their design decision-making freedom, and they
have taken steps to be certain that architectural programs address
their concerns as well as those of the client and programmer.
William Pena of the architecture and engineering firm Caudill
Rowlett Scott (CRS) developed and articulated a very systematic
and successful approach to architectural programming, which at­
tempts to define the “whole problem” by making certain that every
program produced by the firm provides essential information in
4 A rchitectural Programming and Predesign Manager

four distinct areas: function, form, economy, and time (Pena et al.
1 9 6 9 , 1977, 1987). It is apparent from the many design awards
received by the firm that this approach to developing information
about the whole problem has had a significant positive impact on
the quality of the firm’s design efforts.
Other architects, such as Louis I. Kahn, upset by the poor
quality of architectural programs received from clients, insisted
on going back to “original beginnings,” rethinking with the client
about the nature of the design problem (Kahn 1961). Numerous
other practicing architects and programming specialists have
dealt similarly with these issues and tried to bring understanding
to this first stage of the architectural design process (Becker
1959; Demoll 19 6 5 ; Horowitz 19 6 6 ; Evans and Wheeler 1 969;
Davis 1969; White 197 2 ; Farbstein 19 7 6 ; Sanoff 19 7 7 , 1 992;
Preiser 1978, 1985, 19 9 3 ; Davis and Szigeti 19 7 9 ; Zeisel
1981; Palmer 1 9 8 1 ; Marti 19 8 1 ; Hershberger 1 9 8 5 ; Spreck-
elmeyer 1986; Lang 198 7 ; Duerk 1993; Kumlin 1995).
This book is deeply influenced by many of these efforts. It uti­
lizes insights obtained from these sources and the author’s experi­
ences in practice and teaching to set forth a general programming
approach applicable to a wide range of architectural design prob­
lems, and provides both theoretical and practical frameworks for
learning how to do effective architectural programming.

1.2 D efinitions o f A rch ite ctu ra l Programming

Definitions of programming in the design professions are as diverse
as the people involved in its practice. These people have even had
difficulty arriving at an appropriate modifier to distinguish the ac­
tivity from the more pervasive “computer programming.” Combina­
tions such as building programming (Davis 1969), environmental
programming (Farbstein 1976), facility programming (Preiser
1978), functional programming (Davis and Szigeti 1979), and de­
sign programming (GSA 1983) have been used to describe the ac­
tivity.
The above-stated modifiers to programming and the resulting
definitions do not set high enough standards. It is not enough to
“facilitate” a client’s operations. “Function,” while important in
most projects, is not the only reason for building. “Environment”
simply implies that which surrounds, neither good nor bad. Even
“design programming,” with its process rather than product ori­
entation, misses the essential reason why architects should be in­
terested and involved in programming. For architects, the purpose
 A rch ite c tu ra l Programming 5

of both programming and design should be to achieve architec­

ture: buildings that respond effectively to the program, but in
synthesis become works of art.
The objective, then, is to program for architecture, for environ­
ments that transcend the “problem” to create something of won­
der that captures the essence of the institution; relates
marvelously to the site, climate, and time; goes beyond immedi­
ate needs to enhance the potential of the users; expresses the
highest aspirations of the client, architect, and society; and
“moves” all users in some special way.
The terminology proposed here is the most generally used: “ar­
chitectural programming.” A carefully conceived and executed
program should promote architecture. It should not focus exclu­
sively on “defining the problem.” It should serve as a vehicle to
“question the problem,” to discover the nature of the “institu­
tion,” to explore and discover the values of society, client, user,
and architect; to uncover constraints and opportunities, so that in
the hands of a talented designer, the program becomes a guide-
post for achieving architecture.
What then is the appropriate definition for architectural pro­
gramming?

Architectural Programming is the first stage o f the architectural

design process in which the relevant val­
ues o f the client, user; architect, and so­
ciety are identified; important project DESIGN
goals are articulated; facts about the pro­
ject are uncovered; and facility needs are
made explicit.

It follows then that:

PROGRAM CONSTRUCT
The architectural program is the docu­
ment in which the identified values,
goals, facts, and needs are presented.

Programming is an essential part of the OCCUPY

overall architecture delivery process, which
can roughly be defined as having four
EVALUATION A N D R E S E A R C H
stages: programming, design, construction,
and occupancy. Between each stage is an
appropriate time for evaluating the effec- Fi«ure1-3 Architecture Delivery Process.
tiveness of the previous stage (Fig. 1-3). Credit. Nancy Cole
0 A rch itectu ra l Programming and Predesign Manager

1.3 Approaches t o A rch ite ctu ra l Programming

Various programming methods have been developed and used over
the years as clients, architects, and programmers have tried to ar­
rive at appropriate definitions for particular architectural prob­
lems. These methods range from informal discussions between
client and architect to carefully articulated research studies cover­
ing similar facilities and users leading to a comprehensive and de­
tailed program. Most programming approaches fall between the
two extremes.
Historically, programming appears to have fallen outside of
normal architectural services. In fact, in the current AIA Standard
Form of Agreement between Owner and Architect (AIA Document
B141), programming is identified as an additional service. The
expectation is that the owner will provide the architect with the
needed program information. In England, this document is re­
ferred to as the “client’s brief.” Aptly named, these documents
are typically very short lists of the required rooms and their
square footages, with very little explanation of the values of
client, users, or society; purposes to be served by the building; re­
lationships between the spaces; requirements of the spaces; and
so on. This type of program was adequate at a time when most in­
stitutions were relatively simple and slow to change, allowing ar­
chitects to intuitively understand what was needed.
This client-based approach to architectural programming be­
came less effective toward the middle of this century, as buildings
became more complicated and difficult to understand. In these
cases, when insufficient or inaccurate information was provided to
the designer by the client, it proved costly during design, construc­
tion, and after occupancy because of the necessity for expensive
changes to make the building work. As a result, architects such as
Herbert Swinbome (1958), Nathanial Becker (1959), and Louis
Demoll (1965) began to offer architectural programming services
to their clients in order to achieve more reliable and valid programs.
In 1966, Harold Horowitz, an architect working at a federal re­
search agency in the United States, wrote a seminal article on the
nature of architectural programming and its relationship with re­
search in the behavioral sciences: “The Architect’s Programme and
the Behavioral Sciences” (Horowitz 1966). In this article, Horowitz
discussed 11 areas of information that should be included in an ar­
chitectural program as well as how the work of behavioral scientists
could contribute to the development of information in each area.
 Architectural Programming ~J

The article was of great interest to a

1. Objective of the master plan.
number of architectural practitioners 2. Special restrictions and limitations on design.
and social scientists. Indeed, it was 3. Characteristics of the site.
highly influential and continues to de­ 4. Site development requirements.
fine the essential elements of architec­ 5. Functional requirements for the facility.
tural programming today (Fig. 1-4). 6. Characteristics of the occupants.
7. Specific facility requirements.
8. Relative location and inter-relationship of the spaces.
9. Budget.
1.4 Design-Eased 10. Flexibility for future growth and changes in function.
11. Priority of need among the various requirements.
A rch ite ctu ra l Programming
Figure 1-4 Horowitz Programming Areas.
Today’s most frequently used pro­
Credit: (Horowitz 1966) 72-73. Permission: A rch ite ctura l Science Review
gramming method occurs simultane­
ously with the design process. In this
method, a minimum amount of programmatic information is gen­
erated prior to initiation of the design process. Usually, the archi­
tect and client meet to discuss the client’s design problem and the
architect takes notes as the discussion proceeds. Sometimes the
client has already prepared a short program statement or client’s
brief, which may list the spaces required, square footage for each,
maximum construction budget, and occasionally some particular
material or system requirements, or desired special effects.
In most cases, a minimum amount of time and effort are ex­
pended in generating the program, and the design proceeds forth­
with—sometimes at the first meeting. This happens both when
the client has already generated a plan for the architect “to draw
up,” and when the architect brings pencil and paper to the meet­
ing and begins to sketch design ideas based on the client’s brief
and/or the discussion with the client. The programming process
then continues over a number of meetings as the client reacts to
the designs generated by the architect.
If something was left out of the brief and not covered in the
discussion, it becomes evident in the drawings. The new informa­
tion is then taken into account and a new drawing is produced.
This process is repeated until the client and architect are satisfied
that all problems have been uncovered and resolved in the design.
This approach sometimes works, depending on:

1. The thoroughness and accuracy of the client’s brief.

2. The effectiveness of the architect as an interviewer.
3. The scope of the project.
g A rch itectu ra l Programming and Predesign Manager

If the project is very simple, such as an artist’s studio or a

small house for an individual or couple, the hopes, dreams, and
requirements of the client may be completely articulated in one or
two meetings, and a satisfactory solution achieved with minimal
formal programming or cost to the client or architect. However, if
the client has prepared an inadequate brief and/or the architect is
not an effective interviewer, problems may arise.
If the client has already prepared a plan, as is often the case
for residences, the architect may try it and sketch some elevations
to see how they look. What if they do not look good? This is quite
likely, since the plan would have been prepared by a non-designer.
What is the architect to do next? Tell the client that the plan is
bad because the elevations do not look good? An adversarial rela­
tionship is likely to develop if this takes place. Or should the ar­
chitect simply accept the plan even if the elevations do not look
good? The architect, if interested at all in creating architecture,
will probably be extremely uncomfortable doing this.
Conversely, if the client does not offer a plan, then the architect
may come up with plan and elevation studies, and the process will
be reversed. The client may find something missing from the plan
that had not been previously discussed. Or, the elevations may not
be considered satisfactory by the client, because the plan does not
seem to work. A negative situation may develop in which the
client always has the last word. The key problems here are that:
1. The process might become reactionary, rather than creative,
in nature.
2. The interaction between client and architect may erode any
initial confidence or rapport between them.
It may also shift the authority to make aesthetic decisions from
the architect to the client. This is almost inevitably disastrous
to the creation of architecture. The proverbial camel is created
as the committee of client and architect react to each successive
design.
Another problem with the design-based approach is that it can
be expensive and time consuming. It is much simpler and less ex­
pensive to generate program requirements (words, numbers, dia­
grams) than to generate designs. An architect in a reactionary
relationship with a client may be tempted to accept less than an
excellent and artistic solution in order to cut financial losses. Or,
an architect with artistic integrity may start a new design each
 Architectural Programming g

time new information is gener­

ated, but it will be at consider­
able personal cost.
The author knows of one ar­
chitect who prepared four com­
plete schematic designs for a large
house using design-based pro­
gramming procedures. At that
point, the client completely lost
confidence in the architect’s abil­
ity to solve the problem. The ar­
chitect had spent nearly four
times the normal budget for
schematic design before the con­
tract was terminated. What a ter­
rible and foolish loss! All four of
the designs had artistic merit,
but none solved the client’s inad­
equately defined problem. The Figure 1-5 Are We Really Communicating?
client ended up thinking the ar- Credit: Carl Okazaki
chitect was incompetent, and the
architect ended up thinking even worse of the client (Fig. 1-5).
Louis I. Kahn is known to have completely redesigned build­
ings after he discovered something new about the essential char­
acter of the facility. He had the integrity to take substantial
financial loss to produce a design of great significance. Perhaps,
however, it would have been possible to understand the essential
nature or “existence will” (as he might have called it) of the build­
ing before going through the great expense of preparing the de­
signs he rejected. It would have saved a great deal of time and
money for both the client and the architect. Fortunately, Kahn
was interested in seeking out the very essence of a problem and
the discoveries and insights were his own, not the result of client
critiques of his designs. Clients were awed by how profound his
discoveries were, rather than chagrined by the fact that some­
thing had been missed earlier. For lesser architects, however, such
changes are often the result of inadequate programming—and the
discovery by the client that needs are not being met. This cir­
cumstance can create serious problems for the architect.
Another exception to the often unsatisfactory approach of
programming by design has been used and articulated by Joseph
'IQ A rch itectu ra l Programming and Predesign Manager

Esherick, architect and professor of architecture at the University

of California at Berkeley (Esherick 1 9 8 7 ). Working primarily on sin­
gle family residences, Esherick meets with the client several times-
at their home, at the site, in the architect’s office. At each meeting,
he produces very simple analytic sketches and diagrams in response
to the client’s input. He leaves these sketches with the client and
does very little, if any, work on the project until the next meeting,
at which time the process repeats itself as the client provides new
information and the architect generates new sketches. This goes on
until the client is satisfied that the architect knows and appreciates
the client’s expectations for the house. Esherick then proceeds to
develop the actual design for the house (Figs. 1-6 and 1-7).
Esherick avoids an adversary relationship because the concep­
tual diagrams and sketches are simply representations of what the
client is discussing— manifestations of the client’s own thoughts.
The tendency of the client to become sole judge of design is
avoided, because the sketches are not designs but reflections of
the discussion. The high cost in terms of time, money, and espe­
cially lost rapport between client and architect is completely
avoided, since the architect makes no investment in design be­
tween meetings (Fig. 1-8).

Figure 1-6 House: Sketch.

Credit and Permission: Esherick Hornsey Dodge and Davis
 A rc h ite c tu ra l Programming j ]

Figure 1-7 House: Plan.

Credit and Permission: Esherick Hornsey Dodge and Davis

Figure 1-8 House: Interior.

Credit and Permission: Esherick Hornsey Dodge and Davis
'12 A rchitectural Programming and Predesign Manager

Similarly, an architect who sees his or her role as facilitator

and resource to the client may be more comfortable with designs
resulting from a highly interactive process in which the problem
and its solution are not known until the design is complete
(Sanoff 1 9 7 7 ). Designers who delight in complex, contradictory,
and even discordant final design statements may enjoy program­
ming by design, because whatever turns up at the end of the
process can be developed into an aesthetic statement satisfactory
to the architect. The fact that the process is essentially reac­
tionary and inefficient may be of little importance if the client and
architect are happy with the results.
A fine example of this interactive process with outstanding re­
sults is the programming and design of St. Matthew’s Episcopal
Church (Fig. 1-9) in Pacific Palisades, California, by Moore Ruble
Yudell Architects and members of the congregation, who worked
together to assemble a three-dimensional model of the overall
scheme (Knight 1 9 8 4 ).
A cogent argument for “programming as design” has been ad­
vocated by Julia Robinson and J. Stephen Weeks of the University
of Minnesota College of Architecture. Their premise is that “an
architectural problem cannot be fully understood prior to design;
thus any definition of the problem is premature until the design is

Figure 1-9 St. Matthews Episcopal Church.

 A rc h ite c tu ra l Programming ] 3

com pleted” (Robinson and

Weeks 1 9 8 4 ) . The entire de­
Program Design
sign process is seen as a
process of problem definition.
Robinson and Weeks further Segregated approach to design (after Palmer)

argue that the distinction is

not between analysis and syn­ Program Design Program Design
thesis, nor rational and intu­
itive, but between verbal/
numerical and formal/spatial Interactive approach to design (after Palmer)
exploration. Words and pic­ Formal elements
tures are more powerful pro­
Verbal elements
gramming tools in concert than
alone, and, thus, a program 1 1
is not complete without them Integrated-interactive approach to design (Robinson/W eeks)
(Fig. 1 -1 0 ).
The author agrees with
Figure 1-10 Programming Approaches.
some of the above assertions
Adapted from diagram by Julia Robinson in Robinson and Weeks, 1984, page 4, with permis­
and feels that design explo­ sion from Julia Robinson.
ration is appropriate during
programming, especially in an academic setting where a real
client, user, and/or site cannot be identified. However, in a pro­
fessional setting, the earlier cautions about “programming by de­
sign” still apply. It is true that no problem definition is ever
complete— even after design is complete! Our understanding of
the problem becomes clearer as time progresses. Similarly, orga­
nizations, environments, and economic situations are constantly
changing. They do not stop changing when the program is com­
plete, the design is complete, the building is complete, or any
time thereafter. This should not mean that an adequate problem
definition cannot be generated from which to begin design.
Beginning design with a carefully developed program does not
preclude some overlap of programming (verbal/numerical) and
design (formal/spatial) activities late in programming and early in
design, especially if the design architect is involved in program­
ming, such as is the case with many fine architects. This overlap
takes place in two ways: 1) when design ideas are articulated
(verbally and visually) during the programming process by the
client, users, and designer; and 2) as the programmer initiates de­
sign analysis by seeking clarification as to whether certain combi­
nations of activities, spaces, and relationships will be viable. This
j4 A rch itectu ra l Programming and Predesign Manager

kind of design exploration or analysis

PROS
1. A minimum amount of time is spent on (rather than synthesis) is almost always
generating programmatic information. helpful to both the architect and the client
2. Design can begin at the very first meeting in understanding the architectural problem
of client and architect. more completely. It may lead to changes to
3. There is intensive and often positive
the previously accepted program. This is to
interaction between client and architect.
4. The review of various design schemes may be expected. If done systematically at the
help the client recognize new ways to end of programming or at the beginning of
accomplish their objectives. design, such changes can be included in
5. Both client and architect can claim the the final program statement or a suitable
design solution as their own. addendum.
In any case, the desirability of design ex­
CONS
1. If the client’s brief is flawed, it may be ploration does not mitigate against develop­
difficult to overcome with design. ing the best possible architectural program
2. If the client already has a plan, the as a beginning point for design. Also, there
architect may have difficulty adjusting to is no reason to confine programming activi­
the limited aesthetic possibilities.
ties to verbal/numeric data. There are good
3. The client may assume authority to make
all decisions, including aesthetic and
reasons to use visual information through­
technical ones. out the programming process to show site
4. The process may become reactionary and conditions, existing facilities both on and off
adversarial rather than creative. the site, required furnishings or equipment,
5. In these cases, the process can be time desired relationships, design ideas, and the
consuming and costly for the architect.
like. Programming is not solely a verbal/nu­
Figure 1-11 Design-Based Programming.
meric activity (Fig. 1-11).

1.5 Knowledge-Based
A rch ite ctu ra l Programming
In the late 1960s, a new group of people began to have an impact
on architectural programming. These were social and behavioral
scientists who began to direct some of their attention to the built
environment. A new social science specialization alternatively re­
ferred to as environmental psychology, environmental sociology,
or human ecology began to emerge (Conway 1973). Many of
these social scientists became affiliated with the Environmental
Design Research Association (EDRA), an organization in which ar­
chitects, interior designers, and other design professionals began
to interact with social scientists in the common concern that
many buildings and other designed environments did not work
particularly well for the people they were meant to serve. These
 Architectural Programming j 5

interdisciplinary groups generally chose to utilize research meth­

ods, techniques, and tools developed by social and behavioral sci­
entists to study human attitudes and behavior-literature search
and review, systematic observation, controlled interviewing, ques­
tionnaires and surveys, sampling, and statistical analysis. This
ushered in a time of extensive research oriented to developing
knowledge about the environmental needs of various user groups.
Seminal studies of personal space and territoriality by Edward
Hall (1966) and Robert Sommer (1969) were introduced to the
architectural profession and influenced many architects, who
gave consideration to their findings in both programming and de­
sign. Other behavioral scientists such as Irwin Altman (1975),
Powell Lawton (1982), Bechtel et al. (1987), and Glare Cooper
Marcus (1975) followed with more directed studies on privacy,
special needs of the elderly, survey research, and special building
types. A number of architects including Henry Sanoff (1977,
1992), Gary Moore (Moore and Gooledge 1976), Paul Windley
(Lawton et al. 1982), Kent Spreckelmeyer (Marans and Spreck-
elmeyer 1981), and the author (Hershberger 1969) adopted
some of the same methods, techniques, and tools to study prob­
lems of interest to them. Still other architects, such as Gerald Davis
(1969), Jay Farbstein (1976), Wolfgang F. E. Preiser (1978, 1985,
1993), Walter Moleski (1974), and Michael Brill (1984) began to
utilize research in actual programming practice. All have been suc­
cessful in their own ways and
have accounted for a large Snapshot Diagrams: Queuing
number of the programs pro­
duced for major clients in re­
cent years (Fig. 1-12).
Typically, these program­
ming efforts have been of
great benefit when consider­
ing facility needs for large,
complex building types such
as prisons, hospitals, air­
ports, research facilities,
governmental office build­
ings, and the like, where the
architect or even the key ad­ Figure 1-12 Queuing Study.
ministrators may not have a Credit: Jay Farbstein and Associates and Min Kantrowitz and A ssociates fo r Einhorn Yaffee
Prescott, 1996. Albuquerque Test M a rk e t Post O ccupancy Evaluations: Summary. United
very good conception of the States Postal Service. Permission: Jay Farbstein and Associates
 "IQ Architectural Programming and Predesign Manager

values, goals, and needs of persons in various divisions of the or­

ganization. In order to make these determinations, it is necessary
to interview key personnel in the various divisions about their
values and goals and to observe how people use their current en­
vironments. It may also be possible to review the research litera­
ture on special user needs, to visit other facilities to see how they
respond to similar problems, and to devise questionnaires to sam­
ple typical users about their attitudes and ideas about specific fa­
cility, furnishing, and equipment requirements.
The information gained from the various research approaches
is assembled, statistically analyzed, and summarized in a program
document that attempts to cover all of the human requirements of
the organization. Indeed, program sheets are developed for every
space in the proposed facility. Such a systematic approach to pro­
gramming provides highly reliable information that is of consider­
able value to the designer in preparing plans to meet the needs of
the client and the various
user groups of the building
(Fig. 1-13).
Commons
Given the generally sys­
tematic approach to knowl­
J\ | edge-based programming,
f \ f Lockers, \| I Stepped |
Service
&
& t
Mail B o x e T l
I Terrace w / |
I ramp | there tend to be few problems
V _________ J
I i
Kitchen
with resulting programs. In
some cases, the interest in
I Lobby

from parking area L being systematic in develop­

y Sem'r ,|
J* Rm •I
• Period '
p
N 1 -icals |jr
ing knowledge about users
may tend to obscure issues
_ Lobby
R e a d in g Rm ,
of importance to the design
Refer­
Augsburg Fortress
Book Store ence architect. Similarly, the fact
that oftentimes the design
jk o (
architect has yet to be hired
S ta ff !
Staff
u u
prevents the designer’s exper­
service
Biblical ,
B e fe r a 1
tise and values from influenc­
Collect'n \
ing the program. Utilization
Floor levels of Learning Center to
align with Library floor levels.
of high-powered research
methods on comparatively
easy problems can also re­
Figure 1-13 Lutheran Theological Seminary.
quire excessive amounts of
Credit: Walter Moleski, ERG/The Environmental Research Group, 1996. Program m ing Study for
Lutheran Theological Sem inary. Philadelphia, Pennsylvania. Permission: ERG/The Environ­
time and money. Indeed, this
mental Research Group is the primary problem with
 Architectural Programming j

the knowledge-based approach to programming. Knowledge-

based programming tends to consume great quantities of time in
planning, making arrangements for the actual studies, doing the
studies, and analyzing the large amounts of data generated. This
is not a problem unless it leaves insufficient time or money to ad­
equately consider the remaining environmental, technological, le­
gal, temporal, economic, aesthetic, and safety issues in architecture.
If something crucial to the eventual architectural solution is not
studied sufficiently or covered adequately in the program, the re­
sulting building could fail in one manner or another.
In a situation of unlimited time and resources, it would be
ideal to devote an extensive systematic research effort to devel­
oping knowledge on every relevant design issue, so that no area
of potential importance would be left unstudied. However, few
programming projects are done in conditions where time and
money are of little concern. Indeed, most programming endeavors
are conducted under conditions where time and money are lim­
ited, and there is not enough of either to do the kind of job the
programmer would prefer. If knowledge-based programming is to
be utilized, it is important that the programming team isolate the
crucial variables, in whatever issue areas they are found, and be
sure to devote research efforts to these variables. The high costs
of research, then, can be focused where the
cost of error is high, and less expensive pro­
gramming approaches can be used to ob­ PROS
tain other kinds of information (Fig. 1-14). 1. Brings to bear all currently available
knowledge on the design problem.
2. Develops new knowledge using the
systematic methods of the sciences.
1.6 Agreem ent-Based 3. Provides all of the information needed to
design each space.
A rc h ite c tu ra l Programming 4. Especially useful on large, complex, or
innovative projects, when no one has a clear
The agreement-based approach to pro­ grasp of the project requirements.
gramming has a number of advantages,
especially when time and money are at a CONS
premium. This approach to programming 1. Can be time consuming and costly for typical
relies on the knowledge of several key in­ building projects.
2. If a social scientist is the programmer, there
dividuals in the client’s organization to
may be a tendency to under emphasize non-
generate the required programming infor­ behavioral science areas such as site/climate,
mation. Often the key participants are of­ economics, time, and technology.
ficers of the organization and departmental
heads who are appointed to a planning or Figure 1-14 Knowledge-Based Programming.
"j g A rchitectural Programming and Predesign Manager

Figure 1-15 Work Session.

Photo Credit: Richard Brittain

building committee to generate the needed programmatic informa­

tion, to hire the architect, and possibly to monitor construction.
The programmer works with this planning or building commit­
tee to arrive at a mutually acceptable set of design requirements.
It is assumed that key individuals appointed to the committee will
have sufficient knowledge of the organization to arrive at a satis­
factory program, or they can access other information as needed
(Fig. 1-15).
In this approach, the programmer serves as a knowledgeable
catalyst to guide the committee in assembling the program. First,
the programmer collects readily available information from the or­
ganization’s records, local site and climate data, applicable govern­
mental regulations, and the like, and sets forth areas where more
information is needed from the client and users. In a working ses­
sion with the programmer, the committee either responds directly
with additional needed information, or the members return to their
respective divisions to obtain needed information from others. The
programmer points out potential areas of conflict or inconsistency
in the information and leads the committee in working out differ­
ences to arrive at an agreeable program statement. The keys to the
success of this approach are the understanding of the programmer
relative to the information that will be needed by the designer, and
the capability of the committee to provide reliable and accurate in­
formation in a timely way.
 Architectural Programming

The most notable example of this approach to programming is

the work of CRS of Houston, Texas (Pena et al. 1969, 1977,
1987). Their approach developed over a number of years under the
able guidance of William Pena has been one of the hallmarks of the
programming profession. In this approach, referred to by Pena as
“problem seeking,” the intent is to discover the nature of the whole
design problem. In order to accomplish this, they proposed the
completion of a predetermined information matrix, which the firm
believed to be capable of providing a complete definition of the de­
sign problem. The completion of such a matrix and agreement on
its content is the fundamental task in each programming situation.
The problem seeking matrix has four value, or issue, categories
along one side: function, form, economy, and time. Pena argues that
any relevant information in a design project can be placed in one of
these categories. For example, site, context, climate, materials, tech­
nology, landscape, and aesthetics can be included under form. Simi­
larly, building purpose, special users, way finding, task performance,
safety, and security all fall under the function category.
Along the top of the matrix are five information areas: goals,
facts, concepts, needs, and problem statement. If the resulting
twenty cells of the program matrix, including the four problem
statement cells, are filled with acceptable information about the
project, then the problem is considered to be defined (Fig. 1-16).

Goals Facts Concepts Needs Problem

Function

Form

Economy

Time

Figure 1-16 CRS Programming Matrix.

Adapted from Pena et al. (1969,1977,1987). Permission: Am erican Institute of A rchitects and HOK
2Q A rch itectu ra l Programming and Predesign Manager

The approach to filling the twenty cells of the matrix is as fol­

lows: the programmers from the architecture firm independently
search out readily available facts about any of the four informa­
tion areas (function, form, economy, time). They then gather in
“squatter” work sessions, usually at the client’s existing facility,
to interact with a representative group of the client/users, with
an open invitation for anyone in the client’s organization to par­
ticipate. During these work sessions, specific project goals are
identified, additional facts are generated, conceptual ways of
dealing with the problem (programmatic concepts) are identified,
and specific need statements are generated for each value cate­
gory. A representative of the architect’s design team joins the
work session to fashion the problem statements in the fifth col­
umn of the matrix. This final column is included as a feedback
mechanism to ensure the client and users that the designer really
does understand the nature of the design problem.
The matrix is placed on a large plain wall in one of the client’s
meeting rooms—it often fills the entire wall. Cards indicating the
value categories are placed along the left wall and cards indicating
the other information areas are placed along the ceiling before the
session begins. Strings are stretched between the category cards
to indicate the twenty “cells” of the matrix. Five-by-eight-inch
cards are prepared by the architect’s programming team members
and placed within the cells to visually and verbally display the in­
formation obtained (Fig. 1-17).
Cards are added throughout the programming work session,
changed as necessary, and even moved from one cell to another
until everyone agrees that the appropriate and complete problem
definition is being presented on the wall (Fig. 1-18).
After the matrix is complete, the programming team continues
to work with the client’s programming group to develop specific
lists of required spaces, square footages, and appropriate rela­
tionship diagrams. They do these on brown sheets of butcher pa­
per (or on white grid paper), which, like the programming matrix,
are attached to a wall in the work session room where they can
easily be seen by all of the work session participants.
The brown sheets are developed using chalk on the butcher pa­
per so they can be continuously modified until all work session
participants agree that the information contained on them is cor­
rect. The participants also work together on these sheets to de­
velop realistic budgets and schedules. They continue to work in
 A rch ite ctu ral Programming 21

Figure 1-17 Completed Card Matrix.

Figure 1-18 Placing Cards on a Matrix.

Photo Credit: Richard Brittain
22 A rch itectu ra l Programming and Predesign Manager

Figure 1-19 Completed Brown Sheet.

this manner until all elements of the program are agreed to by the
members of the work session team, including the client, the pro­
grammers, and the designer (Fig. 1-19).
It should be noted that in the programming approach advo­
cated by CRS, completing brown sheets containing information on
space allocation, relationships, estimated costs, and schedule
completes the active information gathering stage of programming.
CRS consciously avoids the development of design development
information, such as space program sheets, in order to maintain
an exclusive focus on schematic design. Design development pro­
gramming is conducted after the schematic design has com­
menced or even been completed. (See section 4.1 for full
descriptions of schematic design and design development.)
There are several advantages to the above architectural pro­
gramming process. First, it is a way to ensure that information is
obtained for every area in which the architect has design con­
cerns. Second, it is an economical method of generating the in­
formation needed to begin design. Very little effort is spent on
time-consuming research on user needs. The firm relies, instead,
on a representative group of users to communicate these needs
during work sessions. Third, and perhaps most importantly, both
 Architectural Programming

client and architect agree on the nature and scope of the design
problem before design commences. Fourth, time is conserved in
the initial programming process by avoiding development of in­
formation not required to commence schematic design.
Because of the above listed advantages, this programming ap­
proach avoids both the misunderstandings and reactionary nature
of the design-based programming process and the higher costs
and time requirements of the knowledge-based process. And, the
design results are generally very positive as evidenced by most
projects by CRS including the Indiana Bell (Fig. 1-20) and Irwin
Union Bank buildings (Fig. 1-21) in Columbus, Indiana.
There are, however, some disadvantages to the agreement-
based programming approach as advocated by CRS. One disad­
vantage is the pre-fixing of the value categories. If the four
categories chosen to define the whole problem appear to exclude
certain value areas, there is a chance that the design problem will
be inadequately defined. When trying to use the CRS system, this
author always found it necessary to introduce a context category
to accommodate issues such as site, climate, and urban setting,
because it seemed unnatural to include them under the form cat­
egory. Another firm that utilizes the problem seeking method, An­
derson DeBartolo Pan (ADP), added an energy category, because

Figure 1-20 Indiana Bell.

24 A rch itectu ra l Programming and Predesign Manager

Figure 1-21 Irwin Union Bank.

this issue was not easily absorbed within the four predetermined
value categories (Pan 1985). I understand that CRS originally
placed form first in the matrix until a number of clients indicated
that function was their first concern. All of these changes indicate
that limiting the matrix to four value categories may not be ap­
propriate in every case. There will be other influences as well!
Another disadvantage of the CRS approach relates to how the
information is obtained. If the client’s selected programming
group is not representative of the entire organization, or is unable
to understand or communicate important user concerns and
needs accurately during the on-site programming sessions, the re­
sulting program data may be flawed. This would be most likely
for unfamiliar building types.
Similarly, the information area identified as concepts in the
CRS matrix appears to be appropriate only for certain types of
projects, and perhaps only for firms that design numerous pro­
jects of the same building type. It has proven difficult for most
student programmers and especially clients/users to separate
“programmatic concepts” from “design concepts,” hence there is
a confusion of roles as clients and programmers begin to tie down
“design” approaches, perhaps prematurely (Marans and Spreck-
elmeyer 1981). If the designer is on the programming team and
 Architectural Programming 25

primarily responsible for advancing the com

PROS
cepts, this may not be a problem, but if de­ 1. Ensures that information is obtained for
sign concepts are advanced and accepted by every area in which the architect has
others, they may be overly restrictive or in­ design concerns— the “whole problem.”
appropriate. 2. Having a representative group develop the
The purposeful separation of schematic program information during work sessions
is efficient and economical.
design programming from design develop­
3. Visually displaying the programming
ment programming in the CRS system elim­ information during the work sessions helps
inates detailed information that may be the participants to understand and
important to the design of individual spaces. influence the program.
Detailed information may be important to 4. The client, users, and architect agree on
obtain and place in the program if a room the nature and scope of the problem before
design commences.
must be of a particular shape to function 5. The costs of programming changes during
appropriately, or if it must have access to design are generally avoided.
natural daylight, or have a particular view 6. The design results are typically positive as
or orientation. Even specific needed types evidenced in projects by users such as
or arrangements of furniture should be CRS and ADR
known by the designer so they can be ac­
CONS
commodated appropriately. 1. The pre-fixed value categories in the CRS
Finally, it is not appropriate to fill in the matrix may be too limiting for some
problem statements for each value area if projects.
the designer is not a part of the program­ 2. Important information may be missed by
using on-site work sessions as the primary
ming team. This may not be possible if the
information gathering method.
programmer is hired before the architect 3. Limiting clients and users to programmatic
(Fig. 1-22). concepts is frustrating when they have
design ideas that they want to express and
include in the program.
4. Not including detailed information on
1.7 Value-Based individual spaces may result in
inappropriate schematic design decisions.
A rc h ite c tu ra l Programming 5. The problem statement requires the
Legend has it that Frank Lloyd Wright designer to be actively involved in the
programming process.
moved in with some of his clients for several
days or weeks prior to designing them a new
• 4-u* 4.-
i
house. During i
this time he i i i
would have nu­ Figure 1-22 Agreement-Based Programming,

merous conversations with the clients, see

and experience how they lived, and have time to visit and analyze
the site for the new house. By the end of this period, he had de­
veloped an excellent understanding of the family’s values and
goals for the new house. He also had developed an understanding
of the constraints and opportunities of site, climate, budget, and
the like.
26 A rch itectu ra l Programming and Predesign Manager

The above legend also indicates that Wright returned to his of­
fice after the intensive time period with the client and site to
“draw up” the design that he had already completely realized in
his mind. There was no need to erase or redraw any element of
the design. The truth of the story is not clear, but the result, in­
evitably, was architecture (Fig. 1-23).
Louis I. Kahn was similarly intense exploring the problem with
his clients. In so doing, he came to an understanding of the most
important issues to be
confronted during the de­
sign process. For exam­
ple, in programming for
the Richards Building, a
medical research facility
on the campus of the
University of Pennsylva­
nia, Kahn discovered that
the laboratory needs of
the scientists were con­
stantly changing and,
thus, they required a
large, high, open labora­
tory space to allow for
different types of experi­
ments. In order to make
the laboratory spaces ef­
fective, Kahn also real­
ized that there was a
need for flexibility of
service to and strict en­
vironmental control in
these research laborato­
ries. Indeed, he found
that a very substantial
portion of the construc­
tion budget would have
to be expended on bring­
ing mechanical, plumb­
ing, and electrical service
systems into and out of
Figure 1-23 Kaufman Residence (Falling Water). each laboratory. There
 Architectural Programming 27

was a need for an effi­

cient and effective way
to bring in clean materi­
als and to dispose of
waste materials. His de­
sign for the Richards
Building (Fig. 1-24) took
into account this impor­
tant design issue, and in
so doing allowed him to
create an entirely new
form of academic re­
search building: a design
expressing the impor­
tance of the “served”
spaces for the scientists
(the offices and the labo­
ratories) and of the “ser­
vant” spaces (the high
towers for the mechani­
cal, plumbing, and elec­
trical systems and for
egress in case of emer­
gency).
Calvin C. Straub,
FAIA, of the Southern
California architectural
firm of Buff, Straub and
Hensman, was similarly
intense in his architec­
tural programming activ- ... „
,jL. tt • n Figure 1-24 Richards Building,
lties. He was especially
sensitive to the lifestyle
values and needs of the client/user in relationship to the oppor­
tunities offered by site and climate. The 1,400-square-foot
Thomson residence is a particularly good example of his work
(Figs. 1-25 to 1-27). In spite of its small size and modest bud­
get, it is a spacious and beautifully articulated wood frame
house that fully meets the needs of the family and relates well
to the sloping wooded site and mild climate of Southern Cali­
fornia.
28 A rch itectu ra l Programming and Predesign Manager

Figure 1-25 Thomson Residence: Exterior.

Photo Credit: Julius Shulman

Figure 1-26 Thomson Residence: Interior.

Photo Credit: Julius Shulman
 A rc h ite c tu ra l Program m ing 2 9

Will Bruder, architect, of

New River, Arizona, is so thor­ I PECK Baow =
ough when interviewing his
clients, so careful in discovering
their values and goals and ana­
lyzing budget, site, climate, and
other external influences, that
UPPER PART OF KITCHE)M )IM N&llVniG H
> BEDROOM .
he is able to develop initial de­ BEDROOM □ T il ^ J3\!?----
signs that are usually accepted 13x13* T F r j| j \ ’

without change by the client.

~~ * s\ —
Bruder indicates that “by cele­
brating the client’s poetic and
pragmatic program aspirations
as opportunities for unique so­
lutions, the client takes owner­
ship of the architecture from the
i carport /
beginning, as they see them­
selves reflected in the first draw­
ings, models, and ideas” (Bruder
1997). The quality of Bruder’s
work, and his success in having
original designs accepted and
built, attests to his diligence
and perception in the inter­
viewing and analysis processes,
as well as to his design ability
(Figs. 1-28 and 1-29).
H IP L E X k it c h e m h iiiig L
In their thoroughness of pre­ 10xl* u
design analysis, Wright, Kahn, ....
Straub, and Bruder avoid the _ j
— P .-----. ----------
iLllYINGTHNING flflffl
^ 13x21* fl
pitfalls of design-based pro­ 153* PllIOJ El a
gramming and accomplish
something more akin to, but
less formal than, the value-
based approach to program­
ming being advocated in this
SHOP
text.

Value-based programming (UREXCAVATED!

tries to incorporate the best

aspects and avoid the worst
problems o f all o f the pro- Figure 1-27 Thomson Residence: Plans.
gramming approaches dis- credit Calvin c. Straub, faia
cussed above.
30 A rch itectu ra l Programming and Predesign Manager

Figure 1-28 Platt Residence: Exterior Evening.

Photo Credit: Hans Lettner. Permission: W illiam P. Bruder

Figure 1-29 Platt Residence: Entry Evening.

Photo Credit: Hans Lettner. Permission: W illiam P. Bruder
 Architectural Programming

First, value-based programming introduces an examination of

the fundamental nature of the design problem into the earliest
stages of architectural programming. Thus, it incorporates an in­
tensive search for the essential purposes for which human institu­
tions exist and are perpetuated. In order to do this, it relies heavily
on the type of interviewing and discussion sessions between ar­
chitect and client used by leading designers such as those dis­
cussed above to uncover the strongly held values and goals of the
client. In addition, it employs this approach with other users and
representatives of the community to discover their understanding
of the nature of the organization. By conducting this search for
values early in the programming process, rather than waiting until
design, the value-based programming approach allows the entire
balance of programming activities to be influenced by the impor­
tant values uncovered. This is the crucial difference between this
approach and other approaches to architectural programming. The
reason for this difference is to make the program itself the first
step in the quest for architecture, to program for architecture. An
understanding of strongly held values is essential in this pursuit.

Value-based programming m akes certain that the most impor­

tant design issues are addressed in the programming document.

Second, the value-based programming process adopts the sys­

tematic procedures used in knowledge-based programming when­
ever they are needed to ensure that the information obtained
during programming is reliable and valid. Literature search and
review, interviewing, observation, questionnaire development
and administration, and various sampling and statistical methods
are used in the value-based programming process to establish val­
ues and goals; to collect, organize, and analyze facts; and to es­
tablish needs. Value-based programming, however, differs from a
purely research-oriented approach in that it acknowledges the
typically limited budgets and short time schedules allowed for
programming activities. By determining the important values re­
lating to the design problem early in the programming process, it
becomes possible to identify those crucial areas in which more
systematic research procedures should be used. This is done be­
cause of the potentially high cost of error if these areas are not
carefully examined. In less crucial areas, the less structured in­
formation gathering systems employed in design- and agreement-
based programming are utilized.
32 A rch itectu ra l Programming and Predesign Manager

Value-based programming uses systematic information gathering

procedures to ensure that important information is not overlooked
in the programming process.

Third, the value-based approach to programming is heavily in­

fluenced in structure and approach by the agreement-based
method of programming developed by CRS. It incorporates the
objective of being comprehensive (of defining the complete archi­
tectural problem) and relies on a similar matrix format to ensure
that all of the necessary information is collected, presented, and
agreed to by the client’s programming team. Important values are
listed down the left side of the matrix, and categories for goals,
facts, needs, and ideas are listed across the top of the matrix. Ad­
ditional needs information is recorded on brown sheets or grid
sheets. It utilizes the very efficient and effective work session
method advocated by Pena to obtain much of the needed pro­
gramming information and, especially, to obtain agreement.

Value-based programming recognizes the importance o f obtain­

ing agreement with the client, users, and community in open
work session environments.

There are, however, four distinct differences from the agree­

ment-based programming approach to obtaining agreement:
1. The CRS system maintains that the four value categories
(Function, Form, Economy, Time) listed to the left of the ma­
trix are complete, constant, and apply to all building types,
user groups, and presumably architectural firms. The value-
based approach, on the other hand, uses an eight-value
starting point, but seeks to discover the unique set of values
applicable to each design project. In value-based program­
ming, the most important value areas are typically listed
near the top of the matrix and decrease in importance as the
list descends. In this way, a sense of priority is made known
to the designer. Thus, the value-based programming ap­
proach avoids a commitment to a restricted list of values
and asks: What about the reason for being of an organiza­
tion, its institutional purpose? Does function alone define an
organization? What about the natural environment and the
urban context? What about history, tradition, and meaning?
Some important value areas, at least for some architects,
clients, and users, are hard to fit into the CRS programming
matrix. The left column of the value-based programming ma-
 Architectural Programming

trix, thus, might vary from project to project. In one case, it

might include symbolic, institutional, functional, technical,
environmental, temporal, and financial values. In another
case, the list might include image, function, special users,
safety, economics, and urban context as more appropriate
values. The point is that it should be possible for the value
areas to change for every project, client, and architect.
The intent in value-based programming is to let the most im­
portant values or issues set the tone o f the programming ef­
fort, while making certain that recurring value areas are not
inadvertently omitted.
2. The CRS system develops a listing of appropriate goals, facts,
concepts, and needs for each value area, followed by a prob­
lem summary statement. The value-based programming ap­
proach is similar, but avoids the difficult task of developing
programmatic concepts prior to finalizing the need state­
ments. Rather, it allows for programmatic or design concepts
to be introduced into the program simply as undifferentiated
ideas to be considered by the designer. The kinds of ideas pre­
sented in the program are not really important, as long as the
designer is not required to follow them. In value-based pro­
gramming, they are presented simply as ideas which the pro­
gramming group hopes will be explored by the designer. Some
will be programmatic ideas. Others will be design ideas.
Many will prove to be preconceptions that will be considered,
but then will be discarded by the designer because, during
careful design analysis, they prove to be inappropriate.
Value-based programming encourages the clients and users
to set forth both their programmatic and design ideas fo r the
project so that the designer will have benefit o f their unique
perspectives.
3. The CRS system assumes that the designer is part of the pro­
gramming team, hence, is available to provide a summary
problem statement as part of the program. The value-based
system attempts to state the design problem in such a way
as to allow the designer to develop an understanding of the
important design issues whether or not the designer is part
of the programming team. Thus, it does not advocate in­
cluding a cursory problem statement by the designer in the
matrix. The ordering of the values in the matrix helps the de­
signer to recognize what the client, user, and programmer
consider to be the most important values and goals. The rest
34 A rch itectu ra l Programming and Predesign Manager

of the matrix, along with the accompanying brown or grid

sheets, display the agreed upon nature of the design prob­
lem. The programmer is expected to summarize the nature
of the problem in the executive summary of the program
document and the designer is expected to confirm the pro­
gram with the client before commencing schematic design.
The value-based architectural program is prepared in such a
way as to completely define the architectural problem whether
or not the designer is a participant in the programming process.
4. The value-based programming approach does not seek to
differentiate between schematic design and design develop­
ment programming. In interviews and work sessions as well
as in the literature search and observational studies, con­
siderable information is forthcoming that relates more to de­
sign development than to schematic design. There is no
reason to avoid collecting this information during the pro­
gramming process—if it is known, why not collect it? This
information typically relates to specific requirements for in­
dividual spaces, areas, or systems in the new facility. As
such, it can be developed and presented on space program
sheets in the overall architectural program. These sheets are
like mini-programs for each of the rooms, public spaces, ser­
vice spaces, and exterior spaces of the new facilities. Rather
than get in the way of effective schematic design, these
space program sheets provide the designers with detailed
knowledge about each space so they can place them appro­
priately in the new facility. Some rooms may need to be on
outside walls for fenestration, others on the interior to avoid
outside light or temperature fluctuations, others isolated
from public spaces to minimize noise disturbances, etc. This
information is also helpful to the designer to decide on room
configuration. Should a room be long and narrow, or nearly
square, or odd shaped for one reason or another? Without
space program sheets or a lot of prior knowledge about a
particular room type, the designer has little basis to decide
such questions. Having this information will allow the de­
signer to make appropriate schematic design decisions.
Complete value-based programs include design development
information presented on space program sheets in order to
help the designer m ake informed schematic design decisions.
 Architectural Programming

1.3 Exercises
1. Write down a definition of architectural programming with­
out looking back over the chapter.
Compare your definition with the one in Section 1.2. What
are the differences? Are they important? Would program­
ming based on your definition be different from or similar
to the definitions described in Sections 1.4 through 1.7?
2. Discuss the advantages and disadvantages of design-, knowl­
edge-, agreement-, and value-based programming with some
of your colleagues.
a. Is value-based programming an improvement over the
other programming approaches?
b. Is flexibility in establishing value areas an improvement
over the CRS fixed matrix?
c. Would one fixed value list be better for you? Would it be
the CRS list, another list, or one of your own? Would it
be appropriate for every commission? Is there a better
way than any discussed so far?
3. Set aside a couple of hours to begin the design of a house
for a friend. Select a site (or make one up), bring drawing
paper and a soft pencil, and sit down with your friend. Be­
gin to design as you discuss your friend’s desires and needs
for the house. Be sure to get beyond the plan view to at
least one elevation and a perspective sketch in the two-hour
period.
Consider what you accomplished and the nature of the in­
teractive process. Was it positive? Fun? Were there any
problems? Do you personally like the result? Does your
friend?
4. Pick another friend for whom to design a house on the same
site. Spend approximately an hour discussing this friend’s
aspirations and needs and write them down on a sheet of
paper. Have the friend review the information you have
recorded and confirm that it is correct. Spend another hour
by yourself coming up with a preliminary design including
a plan and at least one elevation and a sketch perspective.
Consider what you accomplished and the nature of the in­
teractive process. Was it positive? Fun? Were there any
30 A rch itectu ra l Programming and Predesign Manager

problems? Do you personally like the result? Does your

friend?
5. Compare the two processes. What were the advantages and
disadvantages of each? Which process produced the best re­
sults? Which process worked best from your friends’ point
of view?
Were there differences in the types of information dis­
cussed? Were there differences in the nature of the designs
related more to the processes used than to the differences
in the friends’ ideas? Keep these differences in mind as you
proceed through the text and the exercises at the end of
each chapter.
Remember to have fun as you read the text, consider what it
says, and do the exercises at the end of each chapter. Program­
ming and design are interactive processes which can be accom­
plished in a number of ways. You should try to discover the
approach or approaches that work best for you.

1.9 References
Alexander, Christopher. 1965. “The Theory and Invention of
Form. Architectural Record. 137(4): 177-186.
Altman, Irwin. 1975. The Environment and Social Behavior: Pri­
vacy, Personal Space, Territory, Crowding. Monterey, Calif.:
Brooks/Cole Publishing Company.
Bechtel, Robert, Robert Marans, and William Michelson, eds.
1987. Methods in Environmental and Behavioral Research.
New York: Van Nostrand Reinhold.
Becker, Nathaniel. 1959. Space Analysis in Architecture. Ameri­
can Institute o f Architects Journal. 31(4): 40-47.
Brill, Michael, Stephen T. Margulis, Ellen Konar, and BOSTI.
1984. Using Office Design to Increase Productivity. Buffalo,
N.Y.: Workplace Design and Productivity, Inc.
Bruder, William. 1997. Letter to the author. 10 August.
Conway, Donald, ed. 1973. Social Science and Design: A Process
Model fo r Architect and Social Scientist Collaboration and Report
o f a Conference, October 19 7 3 , Coolfont Conference Center,
Berkeley Springs, W. Va. Washington D.C.: American Institute
of Architects.
 Architectural Programming

Davis, Gerald. 196 9. The Independent Building Program Consul­

tant. Building Research. 18(2) 16-21.
Davis, Gerald, and Francoise Szigeti. 1979 . “Functional and
Technical Programming: When the Owner/Sponsor is a Large
or Complex Organization.” Paper presented at the Fourth In­
ternational Architectural Psychology Conference, 10-14 July
1 9 7 9 at Louvain-la-Neuve.
Demoll, Louis. 1965. Operations Programming and Planning. In
Comprehensive Architectural Services: General Principles and
Practice, edited by William D. Hunt Jr. New York: McGraw-Hill.
Duerk, Donna P. 1993. Architectural Programming: Information
Management fo r Design. New York: Van Nostrand Reinhold.
Esherick, Joseph. 1987. Lecture on the work of Esherick Hornsey
Dodge and Davis, Arizona State University, Tempe, Ariz.
Evans, Benjamin H., and C. Herbert Wheeler, Jr. 19 6 9 . Architec­
tural Programming: Emerging Techniques o f Architectural Prac­
tice—A Continuing Study by the Committee on Research o f
Architects. Washington, D.C.: American Institute of Architects.
Farbstein, Jay D. 19 7 6 . Assumptions in Environmental Program­
ming. In The Behavioral Basis o f Design: Proceedings o f the Sev­
enth International Conference o f the Environmental Design
Research Association, Vancouver, British Columbia, Canada,
edited by P. Suedfeld and J. Russell. Vol. 1. Stroudsburg, Pa.:
Dowden, Hutchinson and Ross.
GSA. 1983. Design Programming. PBS 3 4 3 0 .2 . Washington,
D.C.: General Services Administration.
Hall, Edward T. 1966. The Hidden Dimension. Garden City, N.Y.:
Doubleday.
Haviland, David, ed. 1994. The Architect’s Handbook o f Profes­
sional Practice. Washington, D.C.: American Institute of Archi­
tects Press.
Hershberger, Robert. 1969. A Study of Meaning and Architec­
ture. Ph.D. diss., The University of Pennsylvania.
_________. 1985. Values: A Theoretical Foundation for Architec­
tural Programming. In Programming the Built Environment,
edited by Wolfgang F. E. Preiser. New York: Van Nostrand
Reinhold.
Horowitz, Harold. 1 9 6 6 . The Architect’s Programme and the Be­
havioural Sciences. Architectural Science Review. 9(3): 71-79.
Kahn, Louis I. 1961. Design studio discussion at the University
of Pennsylvania, Philadelphia, Pa.
33 A rch ite ctu ra l Programming and Predesign Manager

Knight, Carleton. 1984. Built on Religious, Regional Traditions:

St. Matthew’s Episcopal Church, Pacific Palisades, Calif. Ar­
chitecture. 73(5): 178-185.
Kumlin, Robert R. 1995. Architectural Programming: Creative
Techniques fo r Design Professionals. New York: McGraw-Hill.
Lang, Jon. 1987. Creating Architectural Theory: The Role o f the Be­
havioral Sciences in Environmental Design. New York: Van
Nostrand Reinhold.
Lang, Jon, Charles Burnette, Walter Moleski, and Steven Vachon,
eds. 1974. Designing for Human Behavior: Architecture and
the Behavioral Sciences. Stroudsburg, Pa.: Dowden, Hutchin­
son and Ross.
Lawton, Powell, Paul Windley, and Thomas Byerts, eds. 1982.
Aging and the Environment: Theoretical Approaches. New York:
Springer.
Marans, Robert, and Kent Spreckelmeyer. 1981. Evaluating Built
Environments: A Behavioral Approach. Ann Arbor, Mich.: Sur­
vey Research Center, University of Michigan.
Marcus, Clare Cooper. 1975. Easter Hill Village: Some Social In­
dications o f Design. New York: The Free Press.
Marti, Manuel. 1981. Space Operational Analysis: A Systematic
Approach to Spatial Analysis and Programming. West
Lafayette, Ind.: PDA Publications Corp.
Michelson, William, ed. 1975. Behavioral Research Methods in
Environmental Design. Stroudsburg, Pa.: Dowden, Hutchinson
& Ross.
Moleski, Walter. 1974. “Behavioral Analysis in Environmental
Programming for Offices.” In Designing fo r Human Behavior:
Architecture and the Behavioral Sciences, edited by Jon Lang,
Charles Burnette, Walter Moleski, and Steven Vachon.
Stroudsburg, Pa.: Dowden, Hutchinson & Ross.
Moore, Gary, and Reginald Golledge, eds. 1976. Environmental
Knowing: Theories, Research and Methods. Stroudsburg, Pa.:
Dowden, Hutchinson & Ross.
Palmer, Mickey, ed. 1981. The Architect’s Guide to Facility Pro­
gramming. New York: Architectural Record Books.
Pan, Solomon. 1985. Programming Seminar at ADP offices in
Tucson, Arizona.
Pena, William, and John W. Focke. 1969. Problem Seeking: New
Directions in Architectural Programming. Houston, Tex.:
Caudill Rowlett Scott.
 Architectural Programming

Pena, William, William Caudill, and John Focke. 19 7 7 . Problem

Seeking: An Architectural Programming Primer. Boston, Mass.:
Cahners Books International.
Pena, William, Steven Parshall, and Kevin Kelly. 198 7 . Problem
Seeking: An Architectural Programming Primer. 3rd ed. Wash­
ington, D.C.: AIA Press.
Preiser, Wolfgang F. E., ed. 1978. Facility Programming: Methods
and Applications. Stroudsburg, Pa.: Dowden, Hutchinson &
Ross.
_________. 1985. Programming the Built Environment. New York:
Van Nostrand Reinhold.
_________. 1993. Professional Practice in Facility Programming.
New York: Van Nostrand Reinhold.
Robinson, Julia, and J. Stephen Weeks. 19 8 4 . Programming as
Design. Minneapolis, Minn.: Department of Architecture, Uni­
versity of Minnesota.
Sanoff, Henry. 1977. Methods o f Architectural Programming.
Stroudsburg, Pa.: Dowden, Hutchinson & Ross.
_________. 1992. Integrating Programming, Evaluation and Par­
ticipation in Design: A Theory ZApproach. Brookfield, Vt.: Ave­
bury.
Sommer, Robert. 1969. Personal Space: The Behavioral Basis o f
Design. Englewood Cliffs, N.J.: Prentice-Hall.
Spreckelmeyer, Kent. 1986. Environmental Programming. Chap­
ter 8 in Methods in Environmental and Behavioral Research,
edited by Robert Bechtel, Robert Marans, and William Michel­
son. New York: Van Nostrand Reinhold.
Straub, Calvin C. 1 9 8 0 . Lecture on architectural programming at
Arizona State University, Tempe, Arizona.
Studer, Raymond. 1966. On Environmental Programming. Arena.
81(902): 2 9 0 -2 9 6 .
Swinborne, Herbert. 19 6 7 . Change is the Challenge. American
Institute o f Architects Journal. 47(5): 83-90.
White, Edward T. III. 1972. Introduction to Architectural Pro­
gramming. Tucson, Ariz.: Architectural Media.
Zeisel, John. 1 9 8 1 . Inquiry by Design: Tools fo r Environment-
Behavior Research. Monterey, Calif.: Brooks/Cole Publishing
Co.
This page intentionally left blank
References

1 Chapter 1: Architectural Programming

Davis, Gerald. 1969. The Independent Building Program

Consul tant. Building Research. 18(2) 16-21.

Davis, Gerald, and Francoise Szigeti. 1979. “Functional and

Technical Programming: When the Owner/Sponsor is a Large
or Complex Organization.” Paper presented at the Fourth In
ternational Architectural Psychology Conference, 10-14 July
1979 at Louvain-la-Neuve.

Demoll, Louis. 1965. Operations Programming and Planning.

In Comprehensive Architectural Services: General
Principles and Practice, edited by William D. Hunt Jr. New
York: McGraw-Hill.

Duerk, Donna P. 1993. Architectural Programming:

Information Management for Design. New York: Van Nostrand
Reinhold.

Esherick, Joseph. 1987. Lecture on the work of Esherick

Hornsey Dodge and Davis, Arizona State University, Tempe,
Ariz.

Evans, Benjamin H., and C. Herbert Wheeler, Jr. 1969.

Architec tural Programming: Emerging Techniques o f
Architectural Prac tice—A Continuing Study by the
Committee on Research o f Architects. Washington, D.C.:
American Institute of Architects.

Farbstein, Jay D. 1976. Assumptions in Environmental

Program ming. In The Behavioral Basis o f Design:
Proceedings o f the Sev enth International Conference o f
the Environmental Design Research Association, Vancouver,
British Columbia, Canada, edited by P. Suedfeld and J.
Russell. Vol. 1. Stroudsburg, Pa.: Dowden, Hutchinson and
Ross.

GSA. 1983. Design Programming. PBS 3430 .2 . Washington,

D.C.: General Services Administration.

Hall, Edward T. 1966. The Hidden Dimension. Garden City,

N.Y.: Doubleday.

Haviland, David, ed. 1994. The Architect’s Handbook o f

Profes sional Practice. Washington, D.C.: American
Institute of Archi tects Press.
Hershberger, Robert. 1969. A Study of Meaning and Architec
ture. Ph.D. diss., The University of Pennsylvania.

_________. 1985. Values: A Theoretical Foundation for

Architec tural Programming. In Programming the Built
Environment, edited by Wolfgang F. E. Preiser. New York:
Van Nostrand Reinhold.

Horowitz, Harold. 1966. The Architect’s Programme and the

Be havioural Sciences. Architectural Science Review. 9(3):
71-79.

Kahn, Louis I. 1961. Design studio discussion at the

University of Pennsylvania, Philadelphia, Pa.

33 A Knight, Carleton. 1984. Built on Religious, Regional

Traditions: St. Matthew’s Episcopal Church, Pacific
Palisades, Calif. Ar chitecture. 73(5): 178-185. Kumlin,
Robert R. 1995. Architectural Programming: Creative
Techniques for Design Professionals. New York: McGraw-Hill.
Lang, Jon. 1987. Creating Architectural Theory: The Role o
f the Be havioral Sciences in Environmental Design. New
York: Van Nostrand Reinhold. Lang, Jon, Charles Burnette,
Walter Moleski, and Steven Vachon, eds. 1974. Designing
for Human Behavior: Architecture and the Behavioral
Sciences. Stroudsburg, Pa.: Dowden, Hutchin son and Ross.
Lawton, Powell, Paul Windley, and Thomas Byerts, eds. 1982.
Aging and the Environment: Theoretical Approaches. New
York: Springer. Marans, Robert, and Kent Spreckelmeyer.
1981. Evaluating Built Environments: A Behavioral
Approach. Ann Arbor, Mich.: Sur vey Research Center,
University of Michigan. Marcus, Clare Cooper. 1975. Easter
Hill Village: Some Social In dications o f Design. New
York: The Free Press. Marti, Manuel. 1981. Space
Operational Analysis: A Systematic Approach to Spatial
Analysis and Programming. West Lafayette, Ind.: PDA
Publications Corp. Michelson, William, ed. 1975. Behavioral
Research Methods in Environmental Design. Stroudsburg,
Pa.: Dowden, Hutchinson & Ross. Moleski, Walter. 1974.
“Behavioral Analysis in Environmental Programming for
Offices.” In Designing for Human Behavior: Architecture
and the Behavioral Sciences, edited by Jon Lang, Charles
Burnette, Walter Moleski, and Steven Vachon. Stroudsburg,
Pa.: Dowden, Hutchinson & Ross. Moore, Gary, and Reginald
Golledge, eds. 1976. Environmental Knowing: Theories,
Research and Methods. Stroudsburg, Pa.: Dowden, Hutchinson
& Ross. Palmer, Mickey, ed. 1981. The Architect’s Guide to
Facility Pro gramming. New York: Architectural Record
Books. Pan, Solomon. 1985. Programming Seminar at ADP
offices in Tucson, Arizona. Pena, William, and John W.
Focke. 1969. Problem Seeking: New Directions in
Architectural Programming. Houston, Tex.: Caudill Rowlett
Scott.

Pena, William, William Caudill, and John Focke. 1977.

Problem Seeking: An Architectural Programming Primer.
Boston, Mass.: Cahners Books International.

Pena, William, Steven Parshall, and Kevin Kelly. 1987.

Problem Seeking: An Architectural Programming Primer. 3rd
ed. Wash ington, D.C.: AIA Press.

Preiser, Wolfgang F. E., ed. 1978. Facility Programming:

Methods and Applications. Stroudsburg, Pa.: Dowden,
Hutchinson & Ross.

_________. 1985. Programming the Built Environment. New

York: Van Nostrand Reinhold.

_________. 1993. Professional Practice in Facility

Programming. New York: Van Nostrand Reinhold.

Robinson, Julia, and J. Stephen Weeks. 1984. Programming as

Design. Minneapolis, Minn.: Department of Architecture,
Uni versity of Minnesota.

Sanoff, Henry. 1977. Methods o f Architectural

Programming. Stroudsburg, Pa.: Dowden, Hutchinson & Ross.

_________. 1992. Integrating Programming, Evaluation and

Par ticipation in Design: A Theory ZApproach. Brookfield,
Vt.: Ave bury.

Sommer, Robert. 1969. Personal Space: The Behavioral Basis

o f Design. Englewood Cliffs, N.J.: Prentice-Hall.

Spreckelmeyer, Kent. 1986. Environmental Programming. Chap

ter 8 in Methods in Environmental and Behavioral Research,
edited by Robert Bechtel, Robert Marans, and William
Michel son. New York: Van Nostrand Reinhold.

Straub, Calvin C. 1980. Lecture on architectural

programming at Arizona State University, Tempe, Arizona.

Studer, Raymond. 1966. On Environmental Programming. Arena.

81(902): 290-296.

Swinborne, Herbert. 1967. Change is the Challenge. American

Institute o f Architects Journal. 47(5): 83-90.
White, Edward T. III. 1972. Introduction to Architectural
Pro gramming. Tucson, Ariz.: Architectural Media.

Zeisel, John. 1981 . Inquiry by Design: Tools fo r

Environment- Behavior Research. Monterey, Calif.:
Brooks/Cole Publishing Co. This page intentionally left
blank
3 Chapter 3: Values Become Issues

Duerk, Donna P. 1993. Architectural Programming:

Information Management for Design. New York: Van Nostrand
Reinhold.

Duffy, Francis. 1990. “Measuring Building Performance.”

Facili ties. May: 17.

EDRA. 1969-96. Proceedings of the Annual Conference. Pub

lisher varies.

Feerer, Michael. 1977 . Family Services Ward:

Environmental/ Architectural Programming. Program for
Atascadero State Men tal Hospital, Atascadero, Calif.

Goldman, Mark, and Frieda D. Peatross. 1993. Planning for

a Captive Audience. In Professional Practice in Facility
Program ming, edited by Wolfgang F. E. Preiser. New York:
Van Nos trand Reinhold.

Hall, Edward T. 1959. The Silent Language. Garden City, N.

Y.: Doubleday.

_________. 1966. The Hidden Dimension. Garden City, N. Y.:

Doubleday.

Hart, Vaughan. 1995. “Erich Mendelsohn and the Fourth

Dimen sion.” /TRQ Architectural Research Quarterly. 1(2):
50-59.

Hershberger, Robert. 1969. “A Study of Meaning and

Architec ture.” Ph.D. diss., The University of
Pennsylvania, Philadelphia.

Hoag, Edwin, and Joy Hoag. 1977. Masters of Modern

Architec ture: Frank Lloyd Wright, Le Corbusier, Mies van
der Rohe, and Walter Gropius. Indianapolis: Bobbs-Merrill.

House Beautiful. 1955. The Character of the House is the

Begin ning of Architecture. November: 248 , 292.

International Conference of Building Officials. 1994.

Uniform Building Code: Administrative, Fire- and
Life-Safety, and Field Inspection Provisions. Volume 1 of
Uniform Building Code. Whittier, Calif.: ICBO.

Jerde, Jon. 1992. Public lecture in the College of

Architecture at The University of Arizona.
Kahn, Louis I. 1961. Masters design studio discussions at
the University of Pennsylvania.

Lawton, M. Powell. 1975. Planning and Managing Housing for

the Elderly. New York: Wiley.

Marans, Robert, and Kent Spreckelmeyer. 1981. Evaluating

Built Environments: A Behavioral Approach. Ann Arbor:
Survey Re search Center, University of Michigan.

Moleski, Walter, with Roberts, Wallace and Todd. 1990.

Richard Allen Homes Site Safety and Security Analysis.
Philadelphia, Pa. Newman, Oscar. 1972. Defensible Space:
Crime Prevention through Urban Design. New York:
Macmillan. Novitski, B. J. 1996. “Telecommuting Design:
Merging Technolo gies Change the Rules of Collaboration.”
Architectural Record. 184(10): 46-51. Pastalan, Leon A.,
and Daniel H. Carson, eds. 1970. Spatial Be havior o f
Older People. Ann Arbor, Mich.: Institute of Geron tology,
University of Michigan; and Wayne State University. Pena,
William. 1980. Lecture at continuing education seminar at
the University of Wisconsin, Madison. Ramsey, Charles
George. 1994. Ramsey/Sleeper: Architectural Graphic
Standards. New York: J. Wiley. Sheydayi, Yury. 1985.
Lecture by faculty colleague at Arizona State University,
Tempe. Sommer, Robert. 1969. Personal Space: The Behavioral
Basis o f Design. Englewood Cliffs, N.J.: Prentice-Hall.
________ . 1974. Tight Spaces: Hard Architecture and How to
Hu manize It. Englewood Cliffs, N.J.: Prentice-Hall.
Spencer, Eldridge. 1962. Site Location Analysis for
Lawrence Hall o f Science. Spencer and Lee, Architects,
San Francisco, Calif. Straub, Calvin C. 1970. Design studio
discussion at Arizona State University, Tempe. Stratta,
James L., Ted J. Canon, C. Martin Duke, and Lawrence G.
Selna. 1976. Reconnissance Report Mindanao, Philippines
Earthquake, August 17, 1976. Oakland, Calif.: Earthquake
En gineering Research Institute. Venturi, Robert. 1977.
Complexity and Contradiction in Architec ture. New York:
Museum of Modern Art. Wilson, Forrest. 1984. A Graphic
Survey o f Perception and Be havior for the Design
Professions. New York: Van Nostrand Reinhold. Wineman,
Jean D., ed. 1986. Behavioral Issues in Office Design. New
York: Van Nostrand Reinhold. Zevi, Bruno. 1957.
Architecture as Space: How to Look at Archi tecture. New
York: Horizon Press.
5 Chapter 5: Information Gathering

later date. The catalog entry for a book will also note if
it contains

may help you decide if the particular document is worth

pursuing.

C O N S U LT TH E A P P R O P R IA T E IN D E X E S TO

P E R IO D IC A L L IT E R A T U R E

The librarian may also be able to refer you to the

appropriate in

dexes to periodical literature. Some of the appropriate

indexes for

architectural periodicals include the Avery Index to

Architectural

Periodicals, Art Index, and Architectural Index. The Avery

Index

can be accessed in some libraries with a computer search. A

valu

able resource for finding appropriate indexes is Information

Sources in Architecture, edited by Valerie J. Bradfield

(1983). The

librarian may also be able to refer you to appropriate

indexes, bib

books, write down the complete citation for each article:

author,

title of article, title of journal, volume and issue

number, full date

of issue, and inclusive page numbers, as well as the index

and

subject headings consulted. If the particular periodicals

in which

you are interested are not covered in a standard index, a

time
consuming review of the tables of contents of each
publication

may be necessary to

find articles or chap

ters applicable to the

problem at hand. In

this case, always try to

find relevant informa

tion in the most cur

rent documents. They

may make reference to

earlier publications, so

you can avoid a seem

ingly endless search

through the contents of

numerous periodicals.

This is an especially

good strategy in using

unindexed trade jour

nals and newsletters

(Fig. 5-14). Figure 5-14 Indexes in Architecture Library.

IN V E S T IG A T E THE G O V E R N M E N T D O C U M E N
T S IN D E X Government documents are generally located in
a special section of major libraries. You must work with
the section librarian to lo cate the desired materials,
because they are not referenced in ei ther the library’s
main catalog system or indexes. The librarian will likely
refer you to specific materials as well as acquaint you
with the use of the Monthly Catalog o f United States
Government Publications and other special reference tools.
As mentioned ear lier, some government documents can be
invaluable in a pro gramming effort. For instance, many
government documents sections maintain complete up-to-date
codes and ordinances ap plicable within a specific area of
the country. C O N D U C T A C O M P U TE R LIT E R A T
U R E S EA R C H In many libraries, it is also possible to
conduct a literature search on CD-ROM or over the
Internet. It is also possible to request a special
computer literature search. Features of such searches are
speed of retrieval, access points beyond the standard
author-title- subject approach of a printed index, and
other specialized search capabilities. Some data bases
currently available include Art Liter ature International
(RILA), Avery Index to Architectural Periodicals On-line,
and the Architectural Database o f the Royal Institute o f
British Architects. Similar data bases exist for other
fields which may be of interest for a particular project.
One example is Medline for medical facility design issues.
Such searches are worth pursu ing if speed is an object. A
charge may be involved for the search. O B T A IN A N D R
EV IE W THE M O S T P R O M IS IN G S O U R C E S OF IN
F O R M A T IO N With all of the bibliographic information
in hand, it is now time to find the most promising
sources. The books contained in the cata log should be
available in the library. If checked out, request a re
call. If available, they can either be accessed directly on
the shelves or brought to you from closed stacks. Most
libraries will also have public serials lists, which
indicate if a periodical is available in the library and
if it is in paper copy or some microformat. It is likely
that some sources will not be available in the library. In
this case, it may be necessary to utilize the services of
interlibrary loan to ob tain the materials. Be prepared,
however, to wait several days to obtain the materials and
to pay a small charge for the service.

Non-Library Search Procedures

Traditional literature search procedures such as those

described

above are appropriate for only some of the printed documents

needed for architectural programming and design. Many docu

ments will not be in a library or indexed, so the search

can be

time consuming and even fruitless if not approached

systemati
cally. This is especially true for organization archives.
First the

archives must be found, then the filing system determined,

and fi

nally the search for specific useful information

undertaken. An ex

cellent approach to retrieval of useful archival

information is

provided in the book Inquiry by Design by John Zeisel

(1981).

This book should be available in any architectural library.

Often, copies of the needed information can be obtained
from

appropriate agencies, such as the city planning, building,

and en

gineering departments. Documents relating specifically to

the site

for a building project are typically stored in the files of

local,

county, and state offices and can be accessed through their

cata

logs or filing systems.

Manufacturers’ catalogs are available in the architect’s

library

and accessed in accordance with a uniform specification

number

ing system. If information on a particular product is not

available

in the architect’s library, calls to the Sweet’s BuyLine

(1-800

892-1165) or to local building product distributors will

usually

result in a response from a product representative who will

bring
the needed materials to the office.

Some trade publications may be found lying around the

client’s

facilities. If their content appears to be promising, it

may require

correspondence or calls to parent organizations to locate

original

publications. This may involve exasperating delays in

obtaining

ordered materials. Depending on the nature of the problem,

it

may be very important to obtain this missing information.

An his

toric preservation or restoration project, for instance,

may take a

great deal of research in a variety of places to establish

the origi

nal design characteristics of a building. Should one

proceed with

out it? Probably not. The same is true for many other
problems.

Literature Review Procedures

There is probably much to be said for the systematic note

tak

ing advocated in most bibliographic research procedures. The

author, on the other hand, has found for a programming

search that photocopying of title pages and appropriate
content pages onto 814" x 11" sheets is more efficient and
effective, and in the long run produces more readily
retrievable information than notes on cards. If the
information source is available on an on-line data man
agement system, it can be called up using a personal
computer and the desired pages printed. Original copies
can then be filed for future use and, when appropriate,
the pages can be incorpo rated into an appendix to the
program. Key statements can be highlighted or marked in
the margin for easy retrieval. If an entire book or
journal contains appropriate material, then it should be
checked out for the duration of the programming process, or
pur chased for the programmer’s permanent collection. The
actual relevance of material will, of course, be determined
by the person doing the literature review. Here, as in all
areas of information gathering, the best tests of
relevance are whether the information is likely to make a
design difference and whether there will be a substantial
cost of error if the design is not done properly. Some
care must also be taken relative to reliability and
validity. Just because something has been published does
not make it true. A notation system relating to the
reliability of the in formation may be appropriate for any
materials excerpted from a questionable source. Matrix
Summary In the first stages of literature review, it is
best to summarize the information within the eight value
categories covered in Chapters 1 through 3 or a similar
comprehensive set of cate gories with which the programmer
is comfortable, as well as to designate whether the
material appears to relate to project goals, facts, and
needs for the new facility. Using such a system of
classification and summary can help in the development of
the ultimate programming matrix (Fig. 5-15). It can serve
as the original basis for determining the direction of the
firsthand in formation gathering techniques: interviewing,
observing, and questioning. Areas of the programming
matrix in which there is limited or no information may
indicate the need for more directed literature search or
firsthand information gathering techniques. Areas where
much has been discovered in the literature will be of great
help in defining the problem, but the information will need
to be

Values Goals Facts Needs Ideas

Human

Environmental

Cultural

Technological

Temporal

Economic

Aesthetic
Safety

Figure 5-15 Value-Based Programming Matrix.

confirmed for the specific project using firsthand

information

gathering techniques.

Sampling Plan

As with any information gathering procedure, only the

amount of

information that can be reasonably processed and summarized

within the constraints of time and budget should be

collected. A

plan should be developed before beginning the search. The

plan

must address one fundamental issue—what does the designer

need to know? In other words, what can be found that will

make

a design difference? The plan must also be made with

respect to

the available time and money for conducting the literature

search,

review, and summary. And there must be time and money left
af

ter this activity to obtain and summarize firsthand

information

and to meet and work directly with the client/user group to

de

velop and publish the program document. So, the literature

search and review process must fit within a general

research and

programming plan. Once this is determined, the programmer

should develop a particular search strategy. Which of the
sources

are likely to contain the most useful information? Go to

these

first! Which of the sources are likely to contain valuable

informa

tion not available using other information gathering

techniques?

Check out these sources also! In other words, try to decide

where the highest return on invested time is likely to
occur. After search ing the areas of high return,
summarize what you have found us ing the matrix as a
guide. If something is missing, go directly to the most
likely source of information. Do not wander aimlessly
through the library or interesting periodicals hoping that
some thing will turn up— it usually does not. When the
search time budget is nearly used up, summarize what you
have found for each category of the matrix and use this as
the basis for planning the next stages of information
gathering. What has been found that is sufficient? What
needs to be con firmed by firsthand observation or
interviewing? What has to be completely developed from
original sources? Is there still some thing that must be
obtained in the literature? If so, what can be shortened
in the balance of the programming process in order to
obtain the necessary information by further literature
search? Ask yourself, what is the likely cost of error if
the missing in formation is not obtained? If the cost is
likely to be great, then the information must be obtained.
If the cost is likely to be very small, then it may not be
worth the time and money needed to go after it. The
specific design solution may accommodate the expected
problem satisfactorily and no one will know the
difference. But, if the information could make a great
dif ference, like the existence of an un- buildable
easement through the property, it must be found. Other
wise, design decisions may be made or the building may be
constructed in such a manner that it must be re moved
from the easement at great cost to everyone involved. The
pro grammer must always be alert to the crucial variables
and make cer tain that they are adequately cov ered. If
we do not discover and note such important information in
the program, the architect could even design a building
on someone else’s property— a very costly error (Fig.
5-16).
Figure 5-16 Building Over Property Line.

Credit Carl Okazaki PROBLEM s.

5.2 Diagnostic Interviewing • Value and Goal Seeking •

Planning the Interviews • Interviewing Process •
Interviewing Skills Interviewing is the most frequently
used method for gathering

information in architectural programming. The very first

contact

with the client, even before obtaining the commission,

tends to be

an interviewing situation in which the client attempts to

deter

mine if the architect or programmer is qualified to do the

work,

and the architect or programmer tries to obtain an initial

under

standing of the nature of the proposed project. They

interview

each other. After obtaining the commission, the programmer

begins in

earnest to interview the client, and then various users,

expert

consultants, and others who may have special knowledge. The

goal is to discover the primary reasons that a new facility

may be

needed: the particular values and goals of the client;

requirements

for the master plan; requirements for the first phase of

develop

ment; expected growth and/or change; any special conditions

or

restrictions relative to site, materials, and systems; the

construc
tion budget; and possibly the client’s expectations
regarding the

image or aesthetics of the project. The programmer, thus,

tries to

obtain a complete understanding of the design problem to be

un

dertaken. If the project is quite large or complex, with a

sizable

staff having important information to share, or with

special users

whose needs might be rather unusual, an extensive series of

in

terviews may be needed to help discover the special nature

of the

proposed project. The activity is very much like that of a

doctor

trying to make a medical diagnosis, but the architect is

looking for

information that will help to define the architectural

problem

rather than the medical problem. We, therefore, refer to the

process as “diagnostic interviewing.” Note that this type

of interviewing is sometimes referred to as

“unstructured interviewing.” However, this is inappropriate

ter

minology, because there is a great deal of structure

required in

carrying out such an interview successfully. The required

method

ology and the associated techniques and tools of diagnostic

inter

viewing are covered in the following sections. Value and

Goal Seeking The main purpose of diagnostic interviewing is
to discover the pri mary architectural values and project
goals of the clients, staff, and users of an architectural
facility. This helps the programmer obtain an early
understanding of the important values and goals of clients
and users in order to develop a framework in which to con
sider facts, needs, and ideas relating to the project. This
may not be easy to do. Some clients already will have
decided what they need, and will have difficulty trying to
discover the values and goals that led to their decisions
about needs. Nevertheless, it is im portant to get them to
back up a bit to determine if their needs re late to the
essential values and purposes of the organization, or if
they are not needs at all, but wishes—something that is
desirable, but by no means essential (Marans and
Spreckelmeyer 1981). It is necessary to identify the
various values and goals in order to help the designer
gain an understanding of the important de sign issues and,
thus, to give the designer a basis on which to evaluate
design decisions. Continuing with the medical analogy, it
is important to make the appropriate diagnosis before
deciding upon the treatment. Understanding the values and
goals of an or ganization changes architectural design
from a problem solving activity into an activity in which
important goals can be achieved and important values can
be expressed. Planning the Interviews • Defining the “Whole
Problem” • Natural Categories • Sampling Plan • Logistics •
Priming • Documentation • Analysis As with any information
gathering activity, planning can save one a great deal of
time and effort both in collecting the needed information
and analyzing it later. Planning typically involves some
type of preliminary resolution of how the whole problem
can be defined; what data can make a design difference;
which persons can provide the most useful information;
which persons have authority to make tradeoffs and
establish priorities; what

timeframe and budget are available; how interviewing fits

into the

several methods that will be used to gather the needed

information.

D E F IN IN G THE "W H O L E P R O B L E M "

If a programmer can establish the goals, facts, and needs

relating

to the eight value areas outlined in Chapter 2, there is a

good

chance of developing a comprehensive definition of the

architec

tural problem. As discussed earlier, a programmer can begin

with

an entirely different set of value categories, such as Pena

and

Focke’s (1969): function, form, economy, and time; or

Palmer’s

(1981): human factors, physical factors, and external

factors. Planning for an interview requires that the
interviewer re

member the various value areas that may significantly

influence

the design of the facility, so as to be able to use them as

a kind of

checklist during the interview. As noted previously, the

author

uses the acronyms “HECTTEAS” or “TEST EACH” to remember

the eight value areas. Any number of similar associations

can be

used to recall each of these or similar issue areas. The

interviewer will receive essentially five types of program

matic information from interviewee: values, goals, facts,

needs,

and ideas. Each area should be included in a mental matrix

so

that significant information can be sought, particularly

with re

spect to important values and goals: Values Goals Facts

Needs Ideas

Human

Environmental

Cultural
Technological

Temporal

Economic

Aesthetic

Safety

Other?

N A T U R A L C A T E G O R IE S

In a series of interviews, some of the above listed value

categories

may not be considered to be important by the person(s)

being in

terviewed. This is okay! Only the programmer need be

concerned

about defining the whole problem. The programming approach

should be flexible enough to admit new categories of

information

if they arise and especially to allow “natural” categories

to surface and be substituted for the value categories
listed above. Image may be very important to the client,
and if so, image could be used in place of aesthetics.
Similarly, a client may be interested in building systems
and, if so, building systems could be substituted for
technological. If economics was found to be of very little
con cern, as is possible in academic problems but rarely
in real world problems, this category could be left out
all together. Economics would not be necessary to the
definition of the “whole” problem. The point is that the
final programming matrix should include the value areas
that the client, programmer, and designer agree cover the
important issues for a particular design problem. They may
or may not be the eight HECTTEAS areas used as the begin
ning point in structuring the interviews. S A M P LIN G
PLAN (PERSONS, PLACES, T IM ES) If the project is a very
simple one such as a home, it may be read ily apparent who
should be interviewed: the wife, husband, chil dren,
grandparents . . . anyone who would ultimately live in the
house. If the project is for a large institution, it may
not be so ap parent who should be interviewed. The
programmer should re quest an organizational chart and
review it with the client to identify the key officers,
department heads, and other persons who are likely to be
knowledgeable about or have the authority to make
decisions regarding facility needs. The client should also
be asked about other per sons in the organization who
might have some spe cial knowledge. The client should
identify users and visitors who are not part of the
organization, but who nevertheless must use the facility.
These could be pa trons, suppliers, service persons, city
fire depart ment personnel, and many others. For some
projects this would include cus tomers— the most impor
tant users of the facility (Figs. 5 -1 7 and 5-18).

Figure 5-17 Organizational Chart.

Credit: Nancy Cole D 9 o R enl I 1 Dean [— | Secretary

Administrative________________________Business Associate
Manager A s s o c ia te ________________________Assistant
Dean Dean ,__, — T ~ - t — ,__, Library Research Shop
Custodians Staff Director Super Staff , Director Director
Director Planning Architecture Design

Secretary U Administrative I Secretary Administrative

Secretary U Administrative

7 Assistant ______ 1 Assistant ______ y Assistant Planning

Architecture Interior Industrial Faculty Faculty Faculty
Faculty Students Students Students Students

Dean

Associate Dean

Assistant Dean

Administrative Associate

Business M anager

Administrative Assistant

Development Officer

Receptionist

Shop Superintendent

Librarian
Archivist

Head Custodian Architecture Faculty First year students

Second year students Third year students Fourth year
students Graduate students Graduate Assistants Director
of Architecture Administrative Assistant Secretary Third
year students Fourth year students Graduate students
Graduate Assistants Director of Design Administrative
Assistant Secretary Interior Design Faculty First year
students Second year students

University President

University Provost

Advisory Council Pres.

AIA President(s)

Campus Planning Dir.

Facilities Director

Faci I ities Management Director o f Planning

Administrative Assistant Secretary Planning Faculty First
year students Third year students Fourth year students
Graduate students Graduate Assistants Industrial Design
Faculty First year students Second year students Second
year students Third year students Fourth year students
Graduate students Graduate Assistants

Figure 5-18 Architecture Interviewees. It is not always

advisable or even possible to interview only in

dividuals. Group interviews have the advantage of time

efficiency,

because they cover the interests of a number of persons

with pre

sumed similar concerns at one time. If they are “primed,”

the per

sons involved can meet and discuss their concerns prior to

the

interview and possibly arrive at a consensus on some

issues. The

danger is that some persons’ viewpoints may be suppressed

because

others might dominate the exchange, or there may be fear of

some

type of reprisal. The gain in efficiency in obtaining the

views of

larger numbers of people must be weighed against the

possible cost

of error of obtaining biased information. There is no way

to antici

pate the size of this error, but if it seems like the cost
might be great,

precautions must be taken. The groups might be reformed. Or

any

individual wishing a personal interview should be granted

one. In any case, a listing of persons to be interviewed
should be

prepared for each new programming commission. If the list

in

volves a great number of individuals, it may be necessary

to de

velop a sampling plan whereby only a representative sample

of

each category of user is interviewed. The objective is not

to see

how many people can be interviewed, but rather how few can
be

interviewed to obtain complete and reliable information

(Figs. 5-19

and 5-20). Figure 5-20 Small Group Interview. Figure 5-19

Individual Interview. When possible, interviews should take
place in the client’s or

user’s existing environment. This is especially true if the

intervie

wee will be relocated to the new facility. This tends to

make the

person more comfortable in answering questions, but also

makes

it easier for the person to focus on his/her own

architectural en

vironment. If something is difficult to explain, the

interviewee

can point out characteristics of the existing facilities

that are sat

isfactory or unsatisfactory. The one exception to this is

if the in

terviewee’s environment is simply too uncomfortable: too

noisy,

too cluttered, lacking in privacy, or some other

circumstance that

would make conducting an interview very difficult. In this

case, it

would be important to identify a nearby conference room or

other

suitable space where more favorable interviewing conditions

could be found, but close enough to his/her own place for

the in

terviewee to recall issues of importance and even to take

the in

terviewer to the appropriate location to point out key

problems or

solutions. The time of the interview is also important.

Select a time when

the interviewee is not being expected to produce work.

Ideally,

the client or someone on staff should arrange an interview

sched

ule in which everyone to be interviewed would be prepared

to un

dertake the interview at an appointed time. If this cannot

be

arranged, then the interviewer will simply have to be

somewhat

flexible and prepared to adjust the interview schedule as

circum

stances require.

L O G IS T IC S

The first interview should not take more than an hour. If

more

than one hour is required, another interview should be

scheduled.

There are several reasons for this. First, the primary

purpose of the

first diagnostic interview is to get at the key issues that

are of con

cern to the interviewee. It should not take longer than an

hour to

get at a person’s primary values and goals, a number of

important

facts and needs, and some key ideas for reorganization or

design.

Second, it is generally more productive to obtain a clear

picture of

the values and goals of the different participants before

attempt

ing to obtain all of the factual information and specific

needs that

might best serve the organization. Third, interviewing

fatigue is a

reality that should not be ignored. If too much time is

spent in the
interview, most people will lose interest and want to
return to ac

tivities of more concern to them. In other words, it is

best to use the first interview to estab lish a framework
for later, more directed research. This research may
involve fo cused interviews to obtain more factual
information, but because of time and budget
considerations, may also involve a structured questioning
and/or an ob servation period followed by group work
sessions to cut down on both the time and expense of
further in formation gathering. Interviewing is a very
effective but inefficient way of obtain ing information.
It is undoubtedly the most effective way to get at the
owner’s, client’s, user’s, and customer’s values and goals.
It generally is not an efficient way to obtain facts or to
establish needs for the facility. Facts can be obtained
more efficiently through literature search and review,
observation, measurement, and by structured questioning
procedures. Needs, on the other hand, can be established
most efficiently during client/user work sessions, where
several people can review the values, goals, and facts
before arriving at a conclusion regarding needs. What
inter viewees express as needs may be personal ideals,
wants, or wishes that are not necessary to satisfy the
purposes of the orga nization. More importantly, however,
the interviewer must not project what he or she thinks are
the purposes of the organiza tion onto the interviewee.
The interviewer must learn to listen (Fig. 5-21). P R IM
IN G It is a good idea to give each person to be
interviewed some ad vance notice of what is to be
accomplished in the interview, so he or she can think
about key programming issues and requirements. This should
not be a list of specific questions. Rather, it should in
clude broader categories of information such as: • The
purposes of the organization • How a department or position
supports those purposes

Figure 5-21 Interviewer versus Interviewee Ideas.

Credit: Carl Okazaki • Key values or design issues •

Specific goals that could be better met with improved
facilities • Constraints that must be considered •
Important performance or design requirements. For
interviews with staff, the

priming issues should include

value areas identified earlier by

the leadership of the organization

as important areas of concern for

the persons being interviewed.

However, it should be made

clear that the categories listed

are only a stimulus to get the in

terviewee^) thinking about the

nature of the architectural prob

lem and that they should feel

free to bring up other areas of

concern during the interview. It

is also important to tell them

how their response will be useful To: Interviewee’s Name

Fr: Programmer’s Name Re: Interview date, time, and place
Please consider the following as you prepare for the
interview: 1. The purposes of [name of organization] 2. The
role of your department in serving these purposes 3.
Specific goals that should be accomplished by improving
the facilities 4. Important conditions or constraints that
must be considered 5. Specific requirements for your
department We will try to remain focused on these topics
through out the interview, because our time will be
limited to one hour. We appreciate very much your
thoughtful considera tion of these issues and look forward
to talking with you on [date, time, place]. Figure 5-22
Priming for an Interview. to the designer (Fig. 5-22).

D O C U M E N T A T IO N

The purpose of the interview is, of course, to obtain

informa

tion that can be kept and analyzed with other information

gath

ered in the programming process. It is necessary,

therefore, to
have a systematic way of recording the information obtained
for

later retrieval and analysis. It is best to plan ahead for

both the

documentation and the analysis to be certain they can be

done

efficiently and in a manner that does not bias the results.

This

is not easy to do. Regardless of how an interview is docu

mented, the information obtained tends to have less

structure

than other more quantitative information. If one is not

careful

in documenting the interviews, the amount of information

gath

ered can be so vast as to be unfit for analysis within time

or

budgetary restrictions.

SMALL COMMERCIAL BUILDING IN TE R V IE W IN G SCHEDULE

Commercial B u ild ing Name and Address " ffiP P U T —

TEMPS

In te rv ie ve e T it le ^ * * j5 5 a In te rv ie w e r
Name. f ^ T E — ---------------Date 3~2?\~S~1—

Values, goals, facts, needs and ideas fo r a new building

to house the commercial enterprise with which

the person being interviewed is associated. Consider such

areas as the Human, Environmental, Cultural,

Technological, Temporal, Economic, and Aesthetic issues

which miqht be important design determinants

in the minds of those being interviewed.

1 rOGSfc u * * * . * "So ^ l M a r r . Cc*jlS* BG. KCfST

OKI U6s.ViC> . CuWfcfcMTUx
M W C>6. C*X*SL££> Crt’ T H t UM O O . ( ^ 6 tp ) i f f
* . ffcR. A MORS. PROMiKJSjort _ . USOfTvevA cJL Vt UtAAT
A

M O R S 1 V M t T CUK.R6JOT

Vb <JtUfMA\cuMU. Tfc MAIOX .

3. AKTVtoOC-H /A«>Yr B ov^O C Si t i M 6R B k U n W D K x

J S CskJ “T U S M A O f iC O O Y u 3\ O O O wO . ' ')

& . ~bA^-iSFi€L.o u o r r H There are some general

techniques for ensuring that some of the worst problems do
not occur. First, it is important to develop a recording
instrument that will allow easy identification of the pro
ject, interviewee, his/her position or title, interviewer,
and the time and location of the interview. This informa
tion should be at the top of each sheet or card on which
the data will be recorded. Second, all of the issues that
the pro grammer wishes to cover during the interview
should be listed just be low in a compact, read able form
so as to allow maximum room for re cording the
information obtained (Figs. 5 -23 and 5-24). Contrary to
the nor mal practice for “struc tured” interviews, it is
important not to provide a number of specific questions
on each page with a limited amount of space to record
each an swer. This does not allow the interviewee the
flexi bility to approach the subject from her/his point
of view, but rather forces her/him into the inter
viewer’s framework. This can have disastrous re sults in
terms of omitting important ideas and in formation that
may have come out had the inter- viewee(s) been allowed
to discuss the topic more toerr u Jtv u c . \>o ( STR&E.T
feO- FfcApLft. TE> • ( .m c c o )

4, WAJtJTS -*>nv**Vu>oc. Ateaur m 'Tb CCVCCO, ftMPLfc*

A«T5*m©*-5. (0JW*RMTVS< TW t &UUJOv»OG O WUfctVT £££>} MOfc
SfclD T V * r uJOR.CS <3W c*T . ffc.GjJtoOSu* iOA^ A. u
te& fc 0*4 TU k€ . CVTSVDC. ( & & L . ) \AM SPEOM- COm5>ut^
CA2.E^ eiJCiRAUTSW (S) TU&r JOBCXa AfcsAi

"Tb OtO. fcJoa*+ c-r 2 l . (►Jeep'j

Ip . M O \K rrCR-C^T \ y j COJOSfciJ IVOG, £ * K iK v T

W C . U\K)OOvO% v»0 SUKIL.VC K T £ T C . ( c u R R b o J
T tv A S (vJ&SD)

1. “bKOuJeflOM. JoSCfc e>e TOO TUMO OWtKi-r (®cf) *3*0

OAUJS Tb TWJPu/s V. A- f t u ) ^HVkJO OR. TWS>Ut5 .
CfiAtx)

Figure 5-23 Interview Summary Sheet.

Credit: Scott Walker, 1987. Program for Trophy Den.

Permission: School of Architecture, Arizona

State University f u> gi 5: ■SVWStCCMs '■sweAtot l __

INTERVIEW GUIDE ^ ‘ ^ " 4- 1 ■' * 1 ^ ■-'" I ' V r

rNTER V IE W ER : f r ? \ E X .

SEX: Male © Fem ale______ I

RELATIONSHIP: Owner/Manager 9 Staff_____ Patron_______

Other_______________

1. Q THF. rp*»T i r p g r f A ir f LS*Ut nf a-OTmi-[6

-ftkLES?, A Z - ,, I? ' 'U y ^ p b r j; icxysrl p r j.

l a hjr. s.o^otz* ai» frMoP a 'a f 7f r P f A x ‘M&f.

( tgv ? tjpf to e e 'p rj -j^e. puwesj- ^ T ^ jy

3. a ftr.'hij A. ^r.ciaijY —HE K}jgU» gf ---,<iu|o|c^

r|e.|C^ £^» ua .l _fc]ii?_.ai^c>r|L|e. jfcusjloi-p.

4. © A ii^ r|r-|< f-^yleriF.hif.r. Uipj fcrpp^rpis- p b *

p r ] a

s. (S irjAXpg. o’PrjVFr^i? -rfjiapiJ/^ — A HP p p rrT

ELCVffl^rj pee <£| .ELErjC-rjp’ -jW ^ e-1T|,'|6| '|1 cf e
‘H ' f ^ —ifj .rojiL e*p>*£~ - : '

Figure 5-24 Interview Summary Sheet.

Credit: Rob Osier, 1987. Program for DAX. Permission:

School of Architecture, Arizona State University

freely. Conversely, if the interviewer has a restrictive

recording

format but allows the interviewee(s) to move about freely,

the in

terviewer is constantly required to search through the

recording

sheets to find the category into which the information

should go.
This may make it very difficult for the interviewer to
concentrate

on the interview, and it is distracting to the interviewee.

Finally,

not everything discussed needs to be recorded, only the

conclu

sions. If care is taken in this regard, the recorded

information can

be both understandable and manageable to analyze.

A N A L Y S IS

The analysis of the results of the interviews is difficult

because

each respondent is likely to have brought up different

values and

issues. Even when considering the same value area, the

intervie

wees may have expressed different goals, as well as facts

and needs. Here, again, it is helpful to use a matrix
format to organize the information obtained. The analysis
could use a numerical des ignation for each person
interviewed, beginning with the highest ranking person as
number one. A check could then be placed un der the number
of each respondent that mentioned the particular value,
goal, fact, need, or idea. These could then be tabulated to
determine the relative importance of each item (Fig. 5-25).
C ategory 1 2 3 R espondents 4 5 6 7 8 9 TOTAL VALUE 1.
[name] / / / 0 / / 0 0 0 5 2. [name] / / 0 / / 0 0 / / 6 3.
[name] 0 / 0 / 0 0 / 0 0 3 GOAL 1. [name] / / 0 / / 0 0 0 0
4 2. [name] / / / / / / 0 0 / 7 3. [name] 0 / / / / 0 0 0 0
4 FACT 1. [name] / 0 / 0 0 0 / 0 3 2. [name] 0 / / 0 0 / 0
/ / 5 3. [name] 0 / / / / 0 / 0 0 5 NEED 1. [name] / / / /
/ 0 0 0 5 2. [name] 0 / / / 0 0 0 0 / 4 3. [name] 0 0 / / 0
0 0 / 0 3 IDEA 1. [name] 0 / 0 0 / / 0 0 0 3 2. [name] 0 /
/ 0 / 0 / 0 0 4 3. [name] 0 / 0 0 0 0 0 / 0 2 Figure 5-25
Interview Coding Sheet (1). An alternative would be to
designate if the value, goal, fact, need, or idea was
considered to be extremely important (3), very important
(2), important (1), or not mentioned (0). The numbers
could be added to get a more sophisticated idea of the
relative im portance of each entry (Fig. 5-26). Note that
even here the tabulation does not reflect the whole
picture. In a number of cases the highest ranking person
(person

C ategory R espondents 1 2 3 4 5 6 7 8 9 TOTAL

VALUE

1. [name] 3 3 3 1 2 3 2 1 1 19

2. [name] 2 2 1 3 3 2 1 3 3 20

3. [name] 1 2 0 2 0 1 3 2 1 12

GOAL

1. [name] 3 2 0 3 2 1 0 0 0 11

2. [name] 2 3 3 3 3 3 2 2 3 24

3. [name] 1 2 3 2 2 0 0 2 0 12

FACT

1. [name] 3 1 0 3 1 1 0 3 0 12

2. [name] 2 3 3 0 0 3 2 3 3 19

3. [name] 1 3 3 2 3 0 3 2 0 17

NEED

1. [name] 3 2 0 3 2 1 0 0 0 11

2. [name] 2 3 3 3 2 2 2 2 3 22

3. [name] 0 0 3 2 2 0 0 2 0 09

IDEA

1. [name] 0 2 0 0 2 1 0 0 0 05

2. [name] 0 3 3 0 3 0 2 0 0 11

3. [name] 0 2 0 0 0 0 0 2 0 04

Figure 5-26 Interview Coding Sheet (2).

1) has been out-voted in terms of which values, goals,

facts,
needs, and ideas are most to least important. Should the
majority

rule? Should the person(s) who will be held responsible for

the

success or failure of the project have more say? This must

be de

termined in order to have a meaningful analysis of the

data. There will also likely be more value, goal, fact,
need, and idea

statements expressed for each category [value, goal, fact,

need,

idea] than the three shown on the preceding matrix. It is

therefore

best to use a separate coding sheet for each category and

to in

crease the statements in each category as they occur. It

should be expected that persons with different
responsibilities

in an organization will have different values and goals, be

aware of

different facts, have different needs, and desire different

resolu

tions to the perceived design problem. The interview coding

sheets

will allow the programmer to see the areas of consensus as

well as of division. The results can be summarized on a
series of lists, such as the adjoining one, or placed in a
programming matrix, with controver sial areas flagged so
they can be considered later during client/user work
sessions (Fig. 5-27). Because the purpose of diagnostic
interview ing is to obtain a feeling for the important de
sign issues, this works quite well. But it must be
understood that this is only the beginning of the
information gathering. Controversial areas that might be
settled through input from a larger sample of people can
be followed up with addi tional focused interviews or a
questionnaire- based survey. Questions of fact can be
checked using observation techniques and by returning to
the appropriate literature. Ultimately, in value-based
programming, the areas of impor tance and difference are
sorted out in a group session typically involving most of
the interviewees. The results are placed before the group
in an initial matrix and discussed un til a decision is
reached about the inclusion and importance of each item.
This procedure will be discussed thoroughly in Chapter 6.
Interviewing Process • Introduction • Appraisal • Diagnosis
• Recording • Review • Open Ending The introduction,
review, and open ending each occur just once during each
interview. Appraisal, diagnosis, and recording, on the
other hand, occur numerous times as the interview shifts
from one topic to another. IN T R O D U C T IO N The
introduction involves a few very important activities.
First, it is important to recognize the different roles of
the interviewer

Key Values and G oals

1. Location Having lots of pedestrian traffic in the area

is essential.

2. Visibility The store must be seen by passing pedestrians

and vehicles.

3. Image It must convey its purpose with signs, displays,

materials, and colors.

4. Inviting The entry must be convenient, ample, and

protected.

5. Display The merchandise must be displayed under the most

favorable conditions

Figure 5-27 Interviews Analysis Summary Statement

and interviewee(s). The interviewer should state briefly

his/her

name, position, what should be accomplished, and how long

the interview should take. The fact that the interviewer is

part

of the design team is generally enough to make interviewees

both cooperative and interested. Long introductions or

rapport

building are neither necessary nor desirable. Second,

confirm
that the interviewee(s) are correctly identified by name
and ti

tle and record the time and location of the interview.

Third,

outline the categories of information that will be covered

during

the interview. If the interviewee (s) have already been

primed for the inter

view, it does no harm to reiterate the issues of concern.

This will

help keep the interviewee on track. The interviewer should

take

charge and make clear that the interview is a time for

architec

tural business, not casual conversation or complaining

about per

sonal problems with staff or superiors: 1. Introduce the

interviewer: name and position. 2. Indicate what is to be
accomplished. 3. State the length of interview. 4. Confirm
the interviewee’s name and position. 5. Record the time and
location of the interview. 6. Outline the categories of
information to be covered: values, goals, facts, needs,
and ideas. The final part of the introduction is to mention
the first issue,

such as: Let’s begin by discussing the central purpose(s)

of your organization. In what ways will the new building
help your organization meet its ob jectives?

A P P R A IS A L

This step should consume 90 to 95 percent of the time of

the in

terview (Ripley 1980-85). It is the time spent actively

listening as

the interviewee(s) discuss what they know or think they know

about the proposed project. It involves only minimal

question
asking by the interviewer. In fact, many times it is better
not to

ask a question at all, but rather to begin with a statement

about an area on which the interviewer would like to obtain
informa tion—something like the following: Tell me your
feelings about the overall purposes of the organization and
how they should influence the design of the new facility.
This is generally enough to get a response from the
intervie wee. The purpose of appraisal is to keep the
interviewee talking about architectural issues until
something is learned that could make a design difference.
To do this involves a whole series of lis tening skills,
supporting gestures, comments, and probes to keep the
interviewee talking until an accurate diagnosis can be made
for some aspect of the building problem. The key is to
listen for what the interviewee(s) think are the important
values, goals, facts, needs, and ideas to be addressed in
the program while pro viding the necessary cues to support
and encourage them to con tinue at this level of
discourse. There are five essential skills used in the
appraisal stage of an interview: acceptance, reflection,
clar ification, amplification, and redirection. These
techniques will be discussed in detail under Interviewing
Skills. D IA G N O S IS This is the crucial stage when the
interviewer attempts to inter pret and summarize the
concerns of the interviewee(s). The im portant kernels of
information about values, goals, facts, and needs, as well
as ideas, that shed light on the nature of the ar
chitectural problem are distilled from what the interviewee
has said. This generally involves interpretation of what
has been said, stepping a little beyond the information
presented, and re stating it in terms that will fit into
the programming matrix. This demonstrates to the
interviewee(s) that the interviewer has heard them and
understands and appreciates their concerns. It also al
lows the interviewer to bring a certain topic to closure so
as to be able to go on to the next. There are two
important diagnostic skills that the interviewer needs to
learn: interpretation and sum mary. These will also be
covered in detail in the Interviewing Skills section. R E
C O R D IN G Whenever a diagnostic summary statement has
been made by the interviewer and affirmed by the
interviewee, it is time to record

the diagnosis. This is all that is recorded! The

interviewer does

not try to take down everything that the interviewee says.

This

would be much too laborious, would interfere with the

ongoing

interview, and would provide a mountain of data that would

be

very time consuming and costly to analyze. The intent is to

record

only those items of information that have been identified

as im

portant by the interviewee(s). The first attempt at a

diagnostic statement may not be agree

able to the interviewee(s). If so, the interviewer must try

again,

and perhaps again, until the interpretation is agreed to by

the in

terviewee^). When several interpretations have been agreed

to,

such that an area of discussion is complete, then the

diagnosis is

summarized and recorded while the interviewee(s) watch—know

ing that their concerns are having an influence on the

program

ming process. In this way a major part of information

analysis is

accomplished in the field. This is an extremely important

point—

only the verified conclusions are recorded and carried

forward

into the programming process. This has the psychological

advan

tage of showing that the interviewee’s concerns have been

articu

lated while avoiding the recording and analysis of

everything that

has been discussed.

The interviewee(s) will feel comfortable and can relax while

the interviewer records the important information that has

just

been summarized, confident that their concerns have been

heard.

This also provides a time break when the interviewee(s) can

be

thinking of other areas of concern. It may be appropriate

for the

interviewer to indicate what the next area of discussion

will be, or

conversely simply to suggest that the interviewee(s) be

thinking of

something else to discuss. Please be thinking about_______

while I write this down.

This type of recording works well for interviews with up to

three interviewees. When the interview is with a larger

group, it

generally works better to record the same information, but

on

newsprint or graph paper set before the group on an easel,

or per

haps on 5M x 7M cards taped to a wall surface, so that the

entire

group can confirm that what is recorded is correct. This

tech

nique, which typically involves more than one interviewer,

will be

outlined in Section 6.1.

Note that the use of a tape or video recorder is rarely

desirable

during diagnostic interviewing. Not only is this

intimidating to most people, especially those who are lower
in a hierarchy, but it also leaves all of the raw data to
re-analyze after the interview, when the person(s) who can
correct or clarify are no longer pre sent. This can be a
tremendous waste of time and result in serious
misinterpretations of the interviewee’s comments.

Interviewer:

Interview Time: ItMOAiM , Position: ^ Location: I ^ om

Intended Accomplishment: to gain insight on what you think

are the central

purposes of the architecture college and how the new

addition of planning and

landscape can help the college meet its objectives

Interviewee: k l Posi t i on:

Values/Issues: "1* ^VioW 'ptfrVcktb in \ i AW place vv*-

i*Li;W»-k \o MjUuVfc ^ VlW " fe W fvi\ of

Goals: c^k\svu^ wdix <*»'"« Yoot. (<b z.lU#0 \ fr • fV ^ S

A A C i. \A 0> M U A 3\ v iv J .

Facts. ~\q\J0jV\ -(W ov'b -fa Tx> . hltij ! U^\gAf r<?PKU&

0^0p6. VU U** vs Vu>f Wqpf u>p. Wliiyi^ Wluv^ i* \ r c d
\ \A o \o ^ t?U<5W> {Vbyo/t W O-C L?U\l^ l^ To _^o4Wr.

Needs: ^ -p. ^u»-WVuTv|. A prebtvia A v/€l£e>vu*/v^ pla^

je. iv\ ajx^ u^Tvj . /U.dvc M^^tJ ^ A > ^ pv v o w is f

Ideas: i^Hjh-hy| ‘SVwtl c^ia^^VDows luchc flMohovi^ b

4?p>evi Lv\^ je V^ v-e. jotocc • K ilo -h? ViA/e c?tA" owl
a W h)vc WMJ j W T K<sh

Figure 5-28 Interview Summary.

Credit: Jennifer Keaton, 1997. Architecture Expansion

Program. Permission: College of Architecture,

The University of Arizona. R EVIEW Review takes place to

ward the end of the in terview. It is a verbal summary by
the inter viewer of everything that has been recorded.
The review of the sum mary verifies that the in
terviewee’s concerns have been recorded and will be
carried forward in the programming process. It often
stimulates the in terviewee to add other important
thoughts to be recorded. The review also serves as a time
for the inter viewer to determine if all of the
programming cate gories have been dis cussed. If not,
this can be pointed out, and the in terviewing process
re peated for the category(s) remaining to be covered
(Fig. 5-28). O PEN E N D IN G This is the time to ac
knowledge the value of the information that has

been provided and to briefly point out what will be done

with it,

what the balance of the programming effort will involve,

when the

interviewee(s) might be involved again, and to offer thanks

for

their help. If it appears that additional interviewing time

would

be productive, as with the principal officers of a

corporation or

other persons with a wealth of information, then it is also

an ap

propriate time to make an appointment for another

interviewing

session, work session, or whatever else would be useful. If

it becomes clear early or at some point in an interview
that

a person has little to offer, is extremely preoccupied with

a dead

line, has an important phone call, has become bored with

the dis

cussion, or is otherwise unable to concentrate, the

interviewer

should be sensitive to this and terminate the interview. If

appro

priate, another interview time can be scheduled or an early

open
ending can occur, with the person advised when it will be
possi

ble to review the results of the interviewing session.

Interviewing Skills • Acceptance • Reflection •

Clarification • Amplification • Redirection •
Interpretation • Summary

The successful diagnostic interview requires the development

of a number of interviewing skills to be used during the

appraisal

and diagnosis stages of the interviewing process (Ripley 1

980

85; Rae 1988; France and Kish 1995). These are crucial to
the

success of the interview. The first three skills

(acceptance, reflec

tion, clarification) relate to the appraisal portion of the

interview

and are known as “active listening” skills. The next two

skills

(amplification, redirection), known as “management” skills,

also

are part of the appraisal process and involve short verbal

probes

to manage the interview. The final two skills

(interpretation, sum

mary) relate to the diagnostic portion of the interview and

bring

closure to a portion of the interview. A C C E P T A N C E

Acceptance is both an attitude and a technique. As an
attitude, it conveys respect for the worth of the
interviewee. It implies that that interviewee has inherent
value as a person and has important things to contribute.
As a technique, it involves both verbal and non-verbal
responses. The verbal responses are very simple, such as
“uh-huh,” “interesting,” and “yes, go on.” Any simple
phrase implying that the interviewer is listening and what
the intervie wee is saying is okay will do. The technique
is employed through out the appraisal portion of the
interview and is especially useful in keeping the
interviewee talking. There are also several non-verbal
aspects of acceptance that are at least as important as
the verbal acceptance skills, and to gether they are very
powerful tools: • The facial expression and nodding o f the
interviewer: The facial expression of the interviewer,
including eye contact, must convey genuine interest in
what is being said. A smile and vertical nod of the head
when the interviewee has said something of interest
encourage the person to continue speaking. If an
interviewee is rather hesitant in speaking, these gestures
should be both frequent and exaggerated (like an actor) to
be most effective. The nodding can be of the entire upper
body. While this may seem silly and con trived at first,
it is very effective. • The tone o f voice and inflection
o f the interviewer: The small comments are essentially
meaningless, except in the sense that they communicate
that the interviewer is there and is interested. The tone
and inflection of voice are important in expressing
interest in what is being said. • The distance and posture
o f the interviewer: If the inter viewer sits at a
comfortable distance and leans slightly for ward, the
interviewee will infer a friendly interest on the part of
the interviewer. It will help them to feel secure in re
sponding to the interviewer’s questions. On the other hand,
if the interviewer sits fairly far away, then leans back,
crosses her/his legs, or looks away, disinterest will be
com municated. This combination usually will prevent any
inter viewee from continuing with their responses. In
fact, many people are very sensitive to the semiverbal and
nonverbal cues, and react to them more than to anything the
in

terviewer has to say. The slightest negative gesture of the

inter

viewer may be interpreted as rejection or disinterest.

Yawning,

crossing the legs or arms, stepping back, and looking away

are all

negative cues that may be interpreted as disinterest and

may stop

the interview cold. The down-beat “umm-hum” of the bored

com
pared to the up beat “uh-huh” of the interested can make a
world

of difference in whether an interviewee decides to continue

with

what she/he is saying. Indeed, the interviewer needs to

learn when to use both posi

tive and negative techniques! If the interviewee is talking

too

quickly or heading in the wrong direction with irrelevant

banter,

the interviewer should use no active listening techniques

at all.

This will usually slow the person down. If not, stepping or

lean

ing back or some similar negative gesture can often stop an

irrel

evant line of discussion. Then a forward, open motion and

simple

probe can be used to get an interviewee back on track

without

telling them they are wandering. But if the interview is to

be suc

cessful, the upbeat tone and gesture must be used

frequently and

the downbeat tone and gesture used only very rarely.

Otherwise,

the interviewer will be seen as manipulative and the

interviewee

may become uncooperative or guarded in what he/she says.

R E F LE C T IO N

Reflection is the restatement or paraphrasing of the

interviewee’s
comments. It involves both content and affect. Reflecting
content

involves feedback of what has been said, often in a more

concise

manner. The following are examples of reflection of

content: Interviewee: I am really most concerned about the
safety of the clients. (nod) They simply do not look after
their own best interests and often walk into equipment or
throw open doors without any concern as to who might be
beyond them. (I see) They. . . etc. Interviewer: Your
primary concern is the safety of the clients. or:
Interviewee: If I had my way around here, we would have a
copy ma chine in every department, rather than one central
one which always takes me away from my desk, and has
people waiting when I need something done right away,
(uh-huh, nod) Besides, the machine is bro ken down half
the time, so we must send our materials out for repro
duction, which is even more inconvenient. (I see, nod) A
copy machine in the department, even a small one, would
make my job much easier and more productive. Interviewer:
The centralized reproduction department doesn’t meet your
needs as well as would a departmentalized system.
Interviewee: That’s right. As often as I use the copy
machine, I proba bly need one right by my desk! (smile) or
I nterviewee: We need to communicate to those passing on
the street that they are welcome to come in and shop.
Interviewer: A welcoming appearance at the street is
important. Note that the interviewer is adding nothing new
to what has been said, but is distilling the essence of a
more lengthy discourse. The exact statement is not
repeated. A parrot-like response should be avoided,
because it can be irritating, especially if re peated
several times during an interview. Crystallizing the in
terviewee’s comments in new words shows that the
interviewer is really listening to what is being said.
This is generally taken to be a compliment and reacted to
favorably by interviewees. It must not be done too often,
however, or it will soon become stilted and old. It needs
to happen only when the interviewer feels something has
been said that could be important for the program. A
reflection can also be of the expressed attitude. An
interview for Frank Lloyd Wright’s Kaufman House (Falling
Water) might go something like the following (Fig. 5-29):

Figure 5-29 Kaufman House (Falling Water). Interviewee:

When I visited the Kauf man house, I was really awed by
the incredible site, (yes!) Then as I ap proached the
house I became aware that the environment was closing in
on me. (nod, uh-huh) When I reached the entry, I was
completely enclosed and in a tight space. But when the
door opened, it was as if the world had opened up to me.
The space was huge and I could see out over the wonderful
forest beyond. I was really dumbstruck! Interviewer: This
was an incredibly moving experience for you! The
reflection should be the essence of the experience. The in

terviewee will feel both understood and affirmed. The key

is to

make a fresh, new statement with the same meaning as the

words

of the interviewee. Do not worry about getting it just

right. The

client will let you know when your reflection is wrong. The
fact

that you are actively listening will help him/her feel

comfortable

about telling you more.

C L A R IF IC A T IO N

If the interviewee is vague in the discussion, or talking

about

things with which the interviewer is unfamiliar, it may be

neces

sary to seek some additional information to clear up the

inter

viewer’s understanding. In these cases, it is necessary for

the

interviewer to insert some gentle probes into the

discussion. An excellent example of clarification in an
interview could be

taken from an interview that the author had with a member of

First Presbyterian Church, Sun City, Arizona (Fig. 5-30).

Interviewee: The problem with the south aisle is the
blasted “head knockers. ” Interviewer: I don’t understand
what you mean. Interviewee: Oh, the "head knockers" are
those confounded structural members that come down at an
an gle over the side aisle of the church. Interviewer: Go
on, I am still con fused about the problem. Interviewee:
Well, the people going down the south aisle, if they are
not really careful, may wander to the left a little and
bang their heads against the wood members, (oh!) It really
hurts! (ouch!) Some people have even been knocked down or
cut their heads!

An alternative way of seeking clar

ification is simply to use the confus

ing term again as a question. The Figure 5-30 Head

Knockers. interviewer might have followed up the first
interviewee statement somewhat as follows: Interviewer:
Head knockers? (silence) Interviewee: Oh yes, you wouldn’t
know, (nod, for sure!) Those are those structural members
that come down at an angle over the south aisle and hit
people on the head when they are not watching. Interviewer:
Hit people? Interviewee: Well, if people don’t watch where
they’re going, they may get too close to the member and
bump their heads. It really hurts, you know! (I would
think so!) A M P L IF IC A T IO N If you are not getting
enough information on the topic using the three active
listening techniques, it might be necessary to intro duce
some additional verbal probes to obtain the needed infor
mation. These could involve simple questions or statements
such as the following for almost any issue being
discussed: Could you tell me more about that? What else?
That's useful information. Tell me more! An amazing tool
for amplification is silence. If the interviewee needs
encouragement to talk, one of the best techniques is for
the interviewer to remain quiet and let the interviewee
fill the silence. There are very few people who can stand
to look at an interviewer for long without saying
something. Once they begin to talk, the other skills can
take over. The interviewer should consciously de velop
his/her own tolerance for silence, so as to “outlast” the
in terviewee and cause him/her to continue the
conversation. R E D IR E C T IO N If an interviewee is
extremely talkative, it may be necessary to re mind
him/her gently that time is going quickly and that unless
at tention is paid to the architectural issues, there will
not be time enough to cover all areas that might be of
concern. This might in volve such statements as: Let's get
back to issue. That is really interesting, but we need to
focus on . It may be necessary to redirect after each
recording session.

This generally involves two techniques. Early in the

interview

when the interviewer is clearly trying to discover what is

on the

interviewee’s agenda, these probes (not specific questions)

are

generally as follows: That was excellent. Now what else Is

of concern to you? Okay. Is there something else I should
know? If the interviewee is persistently too focused,
particularly the

client or another leader of the organization, it might be

necessary

to be more specific: Now that we’ve covered some key

problem areas of the current facili ties, let’s redirect
our attention to plans for the future. What are some key
issues there? Later in the interview, as the interviewer
considers what is

needed to complete the mental matrix, the questions may be

even

more focused, but still not specific. These may follow an

interme

diate review of what has already been recorded. Now, let’s

go to the second area. Where does your department fit
within the overall organization? How should this affect
design of the new facilities? or We have now
covered_______ , , , a n d __ . What about safety or
budget? Are these issues of concern to you? The
amplification and redirection probes are ways to keep peo

ple talking about the areas in which the interviewer is

interested.

Notice that the interviewer asks very few direct questions,

espe

cially ones that can be answered yes or no. This is very

impor

tant—when the interviewer asks a direct question, he/she may

get only a direct answer, often a very simple one, then

silence re
turns as the interviewee waits for the interviewer’s next
question.

The interviewer may feel he/she must go on to the next

question

to fill the silence. This should be avoided by using the

techniques

described here. For instance, if the last question about

concerns

for safety or budget had been answered, “Yes,” the

interviewer

should follow up with something like: Uh-huh (nod and

smile) Go on! (silence) If this is not enough, add a
redirect such as: Tell me more about safety concerns!
(questioning look with brows raised, then silence) Notice
that neither of the follow-up techniques involves a
question. The interviewee is first directed to a new
subject area, then essentially forced to elaborate on the
brief answer. After the second probe, the interviewer
should remain silent until the in terviewee responds. It
would, of course, be better if the final redirection did
not in volve a question at all. We have covered__________
, ____ , a n d . Now, let’s talk about safety or budget.
This redirect can not be answered with a yes or no. It
requires some discussion of the two issues. IN T E R P R E
T A T IO N Once the interview reaches the stage where the
interviewer feels that an important point has been made
(i.e., a point with design implications), then it is time
to offer an interpretation in terms of values, goals,
facts, needs, or ideas. This usually in volves going
beyond what has actually been said to make an ini tial
diagnosis of some kind. For example, in the illustration on
the “head knockers,” the interviewer might offer the
following conclusion: Interviewer: You ’re saying that you
do not want any "head knockers ” in the addition to the
building. Interviewee: That’s true. But we also want to get
rid of the head knock ers in the existing building! Note
how the interviewee will clarify any incorrectness in the
interpretation. This paves the way for a summary statement.
S U M M A R Y After one of the issues or focus areas has
been completely dis cussed and several diagnostic
interpretations made, it is well to recapitulate, to
condense, and to crystallize the essence of what the
interviewee has said. This will help to close out a phase
of the interview or possibly to stimulate the interviewee
to bring up ad
ditional thoughts. When the topic has been covered
sufficiently

the interviewer says something like the following:

Interviewer: Okay, relative to the head knocker issue, we
are agreed that all circulation areas in the new addition
must be clear of obstructions and that the existing “head
knockers” will have to be removed, even though they are
important structural elements in the existing building. Is
this correct? Interviewee: Yes. Enough people have been
hurt by those darn things! The above is a summary statement
for project needs. There

could also be a more general summary statement after several

such items had been discussed: Interviewer: A most

important value for this project is safety for the users
of the building. A specific goal would be to eliminate all
building hazards that threaten the health or safety of the
building occupants. The summary should be used to close out
an area of discus

sion, but not restate every point made (Fig. 5-31). Once
stated the interviewer should say something like: This is
really important. I would like to record it while you begin
to think about . As you can see, diagnos

tic interviewing is a very

powerful and effective way

to get at the issues of great

est concern to the intervie

wee^). Is it very difficult

to master the techniques?

Not for some individuals.

They have learned to be ac

tive listeners on their own,

usually because they are

people who have a sincere

interest in what other peo

ple have to say. They have

already learned many of

the techniques during in

formal conversation. They

need only to develop a few

of the specialized skills. Figure 5-31 Solution to Head

Knockers. For those of us who would rather hear ourselves
talk, it takes a concerted effort to learn all of the
techniques and to use them. Good luck! 5.3 Diagnostic
Observation • Different than the Diagnostic Interview •
Understanding • Types of Observation • Observation Formats
• Photographic Methods Although most architectural
programming commissions begin with an individual or group
interview session, it is not possible for most programmers
or designers to understand and define the architectural
problem fully or to offer appropriate design sugges tions
until they have personally experienced the project site and
existing and/or other similar facilities. It is like a
physician ask ing the patient about symptoms to discover
important clues as to the nature of an illness, but
observing the patient to find further, often more
reliable, clues. Such observation includes visual in
spection, listening to the heartbeat, and taking the
patient’s tem perature, blood pressure, and so on to check
for abnormalities or other problems. This analogy is
appropriate for architectural pro gramming and design. It
is important to observe all areas of envi ronment and
human interaction to discover what seems to be working
satisfactorily and where there are significant problems
that could be eliminated by appropriate design. This
section will include discussions on the kinds of observa
tion that are most useful, alternative levels of focus, the
impor tance of scale and time, examples of various
observation formats, and comparative levels of
obtrusiveness. Different than the Diagnostic Interview
Observation and interviewing are at opposite ends of the
spec trum in the way that information is obtained. With
interviewing, the client or user is treated as a subject.
Each person is considered as a potential source of
information, knowing something that can be communicated to
the interviewer. The interest is in the inter

viewee’s values, feelings, beliefs, and attitudes as well

as their

perception of the goals, facts, needs, and ideas related to

the pro

ject being programmed. When observing, on the other hand,

the client or user is

treated as an object. The interest is in what they do,

their actual

behavior. By careful observation the programmer can develop

an

understanding of how the activities of the client, user, or

other

building occupants are supported or inhibited by the

architectural

environment. Quite often the observer finds that what

people say

they do is not really true. Conversely, what one observes

may not

predict very well what the observed person is really

thinking or

feeling. Interviewing and observation are complimentary.

They serve

to verify each other, to be reliability checks. Taken

together they

help the programmer diagnose the nature of a design problem

and

consequently help the designer understand what needs to be

ac

complished. The interviewer is more effective in obtaining

an un

derstanding of a person’s strongly held beliefs, values,

attitudes,

ideas, and the like. Observation is more effective in

obtaining an
understanding of the relationships of buildings to users,
of build

ings to their surroundings, and of patterns within the

building it

self. The point of both is diagnosis, to understand the

nature of

the architectural design problem (Deasy and Lasswell 1985).

Understanding

Observation can be used to gain understanding of nearly all

of the

design issues discussed in the earlier chapters.

Observation of the

relationships of form and content can shed light on human,

tem

poral, safety, and aesthetic issues. Observation of the

relation

ships of form to context can lead to understanding of the

physical,

temporal, and cultural environments. Similarly, observation

of

the relation of the building to its own parts and the

principles of

its organization, like syntax in language, should clarify

both tech

nological and aesthetic values.

Sometimes it is possible to detect causal relationships,

when

one factor changes in response to changes in another

factor. In

contrast to Louis Sullivan’s (1949) statement that “form

follows

function,” Winston Churchill said, “We shape our buildings:

thereafter they shape us!” (Bardens 1969). Churchill’s
argument

was that the parliamentary system of the United Kingdom,

with

Figure 5-32 House of Commons: Plan Diagram.

Credit: Nancy Cole

Figure 5-33 French Assembly: Plan Diagram.

Credit: Nancy Cole the parties of the “government” and of

the “loyal opposition,” was at least partially the result
of the equally divided sides of the halls of parliament,
in essence forcing a two- party system of government. On
the other hand, the aisle-less hemicycle of the French
assembly allowed for many political parties and fractions
of parties moving from the left to the right. It was easy
for a member to make a slight move to the left or right
and, thus, to change political affiliation. In the United
Kingdom, on the other hand, it was very diffi cult
politically to move across the center aisle to change
dramatically from one party to the other. Churchill
believed that this helped to create the stability of the
British govern ment and the instability of the French
government. This was understanding resulting from a
lengthy period of observation by Churchill (Figs. 5-32
and 5-33). Similarly, the object of both interviewing and
observation is to increase the programmer’s under
standing of the nature of the design problem. As Russell
Ackoff and others have said, “An ounce of explanation is
worth a ton of descrip tion” (Ackoff 1967). It is
possible to gather exten sive amounts of description from
either interviewing or observa tion, but to obtain
understanding takes diagnostic skills. The objective
should not be to gather as much information as possible,
but to observe those things that have the potential to make
im

portant design differences, to gather only as much

information as

is necessary to understand the problem—that is, to obtain

the

“ounce of explanation.” A carefully planned and executed

inter

view and observation program can do much to ensure that

useful

information is collected and useless information is not.

Types of Observation • General Observation • Walk-Through •

Space Inventory • Trace Observation • Behavioral Mapping •
Systematic Observation

There are several distinctly different types of observation,

each of which can be included in the information gathering

activ

ities of architectural programming. The extent of use of

each will

vary for any particular commission.

G E N E R A L O B S E R V A T IO N

As human beings, and especially as architectural programmers

and designers, we are constantly involved in general

observation

of the world around us. This observation typically is

simple and

unstructured. We watch the world to understand it. The more

we

concentrate on the relationships of various things to the

architec

tural environment, the more we build our intuition as to

how ar

chitecture can best relate to and support the human

activities to

be accommodated. We also gain understanding of

organizational

and aesthetic principles, and which materials, systems, and

forms

respond best to external influences. We gradually build our

un

derstanding to the point where we can easily and quickly

decide

how something should be designed.

But this sometimes leads us to err! The problem with general

or undirected observation is bias. We look for things that

interest

us and ignore things that do not. We may even color our

percep

tion of how well something works by whether we think it is

at

tractive, or perhaps come to consider something attractive

if it

works very well. Even so, constant alertness to the

physical and

aesthetic attributes of buildings and their relationships

to content

and context is very important for programmers and

designers. We should begin observing for programming when
we first step onto the client’s property, and continue
during interviews, when visiting similar projects, and on
the first visit to the new site. This provides a
sensitivity to environmen tal issues and a head start in
knowing where to look as we begin more directed types of
observation. For example, casual

Figure 5-34 Dislocated Parking Bumpers. observation at the

Uni versity of Texas at Austin revealed that bicycles
were parked almost anywhere on campus where there was a
means to lock them to something, but not in
university-provided racks that required locking through the
wheel spokes where the spokes could easily be damaged.
Could this in fluence how to design bicycle parking?
Similarly, at The Univer sity of Arizona, it is easy to
observe that the surface-mounted automobile bumpers are
soon dislocated and present a very un satisfactory
appearance (Fig. 5-34). W A L K -T H R O U G H A
combination of observation and interviewing takes place
simul taneously in the building walk-through, an
information gathering technique used frequently in
architectural programming. If a client has come to the
point of being unable to conduct operations satisfactorily
in an existing facility, they often seek out an archi tect
to design an addition or new facility. The architect first
dis cusses the problem with the client in a diagnostic
interviewing session, often in the client’s office or
conference room. But as var ious problems are discussed,
the client invariably suggests that they get up and go
look at some of the problem areas. A walking observation
and interviewing situation has begun. They get up to
gether and go from place to place to observe and discuss
the key issues and problems as the client sees them. This
approach to information gathering is very beneficial to
the architect in that it couples the objectivity of direct
observation

with the subjective viewpoint of the client as to the

nature of each

problem. It is an excellent way to begin preparation for

more sys

tematic observation. If planned in advance, the

walk-through can

be very effective in generating hypotheses about the nature

of the

problem; for instance, if combined observation/interview

forms

are used. This is especially effective if arrangements can

be made

for each department or section leader to meet the client

and pro

grammer as they enter their area, because experiences of

these

persons can be shared as the walk-through proceeds. This

can en

hance the information obtained by involving those with more

di

rect experience in that particular environment. It is also

important to walk through similar facilities to those

for which you are programming. Arrange to visit other

projects of

the same or similar types and sizes to listen and observe

how they

work, perhaps in contrast to your client’s facilities.

Recording observations and comments during a walk-through

is not easy, because the walk-through usually proceeds

rapidly

and covers many important issues. A clipboard with a number

of

sheets of paper folded vertically down the center, with

observa

tions down the left side and commentary down the right side,

works well, if the programmer can remember to record the

room

name and location prior to each observation and the

commenta

tor’s name prior to each comment (Zeisel 1981). The

recorded notes

should be brief, but de

tailed enough to remind

the programmer of the

entire observation and

associated commentary.

This is important, be

cause the programmer

may want to return to

an apparent problem

area later on to observe

it more carefully. The

walk-through notes can

also serve effectively in

generating a more thor

ough and systematic ob

servation effort (Figs.

5 3 5 a n d 5 3 6 ) . Figure 5-35 Walk-Through

Observation Sheet. Bldg_________________ comment (Identify
Person) Observer Date. SMALL COMMERCIAL BUILDING FAClLITY
fCT ______ Observation ( Ide n tify space) WALK THROUGH
OBSERVATION _0 BS E R Y E p fe f i f r V V ^ T T T A IM Q
nATf Comments ( id e n tify com m entator) C^UlBES IS> L A
ft^ C A«P ig e r ts ftJ»4ot1ot4AL_ PlSPM-YS ffcP-
FL>PP/'S, H-b E 5MALL. AlAP -HtB K£. £toSkT 5C C H . TO
I5£. V&FY size&ps. Ljx f>^g. Oe-PS +U ue- A-LAEfjC pxtue&
L. i(Aclo5tC> Serrtu<2j *Td Bfc PncA/_ e>*=-■SloEE . 2 '5
‘ V I2 ‘ PA-6PIT fc:&M.H.ePS> T^-*=fe y p
CouSlDft-E-ABL/E. £>M lc)ALX_ *GEP1 -pi, 13 & MCSSY. 5riAW-
/HwPW- 15 C-EAMP&P C X P ' J P3PT JPALW- T 2 <%° ’^ oor^
-T^ S r^ ALL. Flifr Z-00^ 16 Ape«?^-£ p>U2-< S&SMS A'o
tD AL£fT OP Pn=FP<J-B>'rr~ c scc^ m e°°n 1S lwco^ &* S,t4P
-HA& * * * * * * 5£&n^ HvAU-. Vi r r is < s^od e y c & r
r k 4 f te K fe^pmq Bieps . mes&Y ice-7 sPAc-g: tc^ <xMD
be, p e s iP A B u ^ c ^ r k it, C b^r- 4^E>-HVe,
ZApGjE, e>lfcC?S Af2€- v e ^ Y <^op 5 e a ^ i ^ <^ o d 0
<^AK f i y iw S /O d . -mle p-voctr^ abb of-u_Y
-rBrtPaeAR-Y • oM.-n<-JEA&TBP-. t h e y a e c - VEPY
TCSSY. PEOPLE to n -msr >et- ^ ofc- at- ^iKAc-b i^v^s >
Fe>A ^ c o r^ \^ > ^ IP P ^ K F^GMf Y/EU7 1r SA*J“P S££
)6>lWr AW-V -p3,^(i w U i a . >wOrt>-rtic m f W H
pVLve-ra cckBOP T4C <2j^On(H^ ■to B e M & l" ^a .£ C £ £
. HVoeC gaoH p?)Z- &ACt=^ A i j p i^ 0|iz-^- so& L’V jhc
j. * ?eon ^ Si^AT~ TO -KUL S^c*=r t ^ o L P o f B e e o
fk r r ^P Al MST A- 1/J-& U-. Figure 5-36 Walk-Through
Observation/Interview. Credit: Perry Vettraino, 1987.
Program for Retail Pet Shop. Permission: School of
Architecture, Arizona State University S P A C E IN V E N
T O R Y After the initial walk-through is complete, it is
important to make arrangements to return to the
walk-through area to review the in formation obtained and
then to make an inventory of the space,

furnishings, and equipment. It is best to do

this after a typical day, but before janitors or

maintenance personnel have come in, so you

can observe where objects are actually used. If

available, take appropriately scaled plans and

elevations of the area on which to sketch fur

nishing and equipment arrangements. If plans

and elevations are not available, take a clip

board to obtain the same information. It is

also important to have a tape measure to ob

tain sizes of objects and distances between the

objects and the surrounding walls, and to take

a camera to provide photo documentation of

the space. Polaroid or digital cameras are ex

cellent for this purpose, because you can de

termine if you obtained a satisfactory picture

before leaving the space. Space inventory categories

include: 1. Dimensioned plan of space 2. Furnishings and
equipment shown to scale on plan 3. Annotated elevations
or perspective views (photographs or sketches) 4. Key to
trace evidence of use and misuse of the space 5.
Identification of key issues, good solu tions, and problem
areas The site developed space inventory sheets

will vary according to the nature of the space

and the information available about it. The ad

joining are typical student developed on-site

space inventory sheets (Fig. 5-37). Similar on

site space inventory sheets by the author can

be found in Appendix A-2. The initial sheets can be refined

to make

a more systematic and handsome presenta

tion of the space inventory information (Fig.

5-38). SMALL COMMERCIAL BUILDING SPACE INVENTO RY/TRACE
(PLA N ) FACILITY r UNWeearrV ceKTtHR. T H E ^ L t h e
t=ecc-ouoiM<v,', p c d r . e * e t tN ic e : H ei_P
duauwrtitt. proiT -s»«*>4\ce WKDKiNe a . R*-P«Nfri w R t
e t h \6 l“SiU5"5=- a l s o C-CA*<VPPET> |K) F E S L
VJEiO_A.«=> U O S K -i. __ _ -P U B S v ^ ~ r r
GOA-■peopePL, • , o i e P f l -£Xa) us/ |t^SM ALL
COMMERCIAL BU ILD IN G SPACE IN VENTO RY/TR AC E (E L E V
S ) i . F c x O iv i^ -QlrQ2. JL_ No F\ooo<rtoe.c( I .
otv "tKxb -—j tioe o f wee. J_ Cool c <TYv\b^ < VaAj c "
'Bi-COe - ivix>i«ee<rr Ljaiwr. !3 J pe&i_ A-b ower < A p p
r .o f c c n e i . n o r ™ w e s r C<=WADej«e>. ')EMD(Ne1
PKCJTPOOe IKVTC. T H E S E -s P A tf G2*» “ l& f l F a
ie r t H e ^ . o(«:ta>.n Nfe, TGTIE' ■sauAF \OKli.
t>fc^A^GD RCCfc. n t e s •p e o to r CPUAfiAeie* • Fftn\
PRGUIOO*, CS6|E_- FLcv^S. UC CATIOM 5e »e »oe»o -n>
t>»E>fe1ES> ofL FOOWJ4, / T f t B u e t . . W ^.r> T W c
e m e M T T 5»c <ra*t>jess.. ■iAotoCTC-f Ct^ rrs TSd
T>-^srA«sr d reon v . iAs.Heie-. .£>6 €O0TA\Aie&T. Figure
5-37 On-Site Space Inventory Sheets. Credit: Jhon C. Casey,
1987. Coin Operated Laundry Program. Permission: School of
Architecture, Arizona State University Level-2nd Area
Nature of Activities: Used for the viewing sorting, and
storage Comment: -Missing ceiling panels, visually
unpleasant. -Insulation hanging from ceiling. -Open
central space -Messy and unorganized. -Plenty of room.
Figure 5-38 Finished Space Inventory Sheet. Credit:
Jennifer Keaton and Erik Peterson, 1997. Section 1. Second
Year Design Studio. A rchitecture Expan sion Program.
College of Architecture, The University of Arizona
Professional programming firms will often develop space in
ventory forms to expedite information gathering and to
ensure that what will be needed later is included (Fig. 5
-39). The space inventory can be an important adjunct to
other in formation gathering techniques. It is rarely
covered in program ming and research texts, perhaps
because its need is not so obvious 200C

S P A C E I N V E N T O R Y S H E E T

Space: PATROL UNIT COMMANDER

Space no: 17

Amount: 1

Occupants: 1

Floor: Ground floor

Area: approx. 170 sq.ft.

Nature of activities:

•Supervision of patrol

•Team briefing {up to 10 people)

•Writing information for public meetings Comments: •Well

located; near Roll Call Room •Good visibility to
Lobby/Reception Area •Good visibility to Communications
Center •Dimension too small •Disorganized space •Office
occupied 24 hours/day with shifts from 5 Patrol Unit
Commanders

Picture:

Figure 5-39 Professional Space Inventory Sheet.

Credit: Raymond Bertrand (1993). Permission: Wolfgang F. E.

Preiser

and the methodology appears to be so simple. Yet, it is

often an im

portant step in developing an architectural program. Simply

put, the

space inventory involves the physical measurement,

photographic

documentation, listing, and counting of the materials,

equipment,

and furniture in the interior and exterior spaces of the

client’s ex

isting building(s) that will be affected by the plans for

expansion Pattern: - j — — — z jcottinor ujtrw
fwOKKHBAM or relocation. It can also involve similar
documentation of other comparable facilities thought to be
more adequate than those cur rently occupied. This type of
inventory serves as a kind of checklist for the pro
grammer to make certain that nothing is forgotten in the
new fa cility. It also serves as the primary basis for the
client and users to estimate what will be needed to serve
them in the new facility. Using the information from the
inventory, they are able to see and easily understand what
they currently have, compare it with similar facilities,
and then project what they will need for the new facility.
T R A C E O B S E R V A T IO N Observation of physical
traces is a very good and unobtrusive way of gathering
information about how an existing facility has been used
and abused, and can often be accomplished as an ad junct
to the space inventory effort. It involves observation of
evi dence left behind by users (Zeisel 1981). Throughout
the diagnostic observation process, the observer should
not only be aware of the interactions of people and their
en vironment in an overall or global sense, but should
also look care fully to see if clues about the human and
environment interaction have been left by previous users.
Signs of rearrangement or remod eling can be important to
diagnosis. What areas of the building have already been
subjected to a number of changes in use? It may be likely
that such areas will continue to be rearranged and modified
given their previous history. If chairs or tables are
located in different places each time a room is visited,
it may indi cate that the room is used for more pur poses
than those indicated in an interview with the client.
Signs in un usual places may indicate some inade quacy in
the original design. For example, door signs such as “Do
Not Open Quickly” or “Door Swings Out,” or pavement
markings as shown in Fig. 5-40, may indicate a major
problem in door location. Wear and tear on furnishings,
floor surfaces, wall surfaces, and the like are good
indicators of use, providing excel-

Figure 5-40 Door Swinging into a Walkway. lent clues as to

how the architect could

improve design. Are there marks on the

walls where the backs of chairs have

rubbed against them? Perhaps a wainscot

or a thicker base or base shoe is needed to

keep the chair backs away from the wall,

or another chair should be selected for the

new building. Signs of pedestrian traffic,

such as worn spots and smudge marks on

carpets, can show where and how they

have been used. Broken light fixtures and

windows or spray paint on walls may indi

cate areas of high vandalism where con

cerns for building security should not be

underestimated. Freezing and thawing can

cause very noticeable abrasion on brick

faces, especially at exposed edges and cor

ners (Fig. 5-41). Abrasion also frequently occurs because

of traffic in areas not intended for heavy

use. Bicyclists on a university campus, for

instance, like to go everywhere that pedes

trians go. If adequate provisions are not

made, they will often make trails through

grassed or garden areas to reach their des

tinations (Fig. 5-42). There may also be examples of

accretion

rather than abrasion. This frequently hap

pens on doors where inadequate space has

been provided to post notices (Fig. 5-43). However, as

shown on the next page, if

a conveniently located bulletin board is

covered by a locked glass door, there are

few people who will get permission to have

their notices posted there. They will simply

post them on the door (Fig. 5-44)! Look for locations where
the paper piles

up at the end of the day, both on the desk

and in the wastebasket. Are there adequate

work surfaces, filing spaces, and trash re

ceptacles? Examine an architect’s environ

ment after a major charrette! Look in the

rest rooms. Are there redundant paper dis

pensers and waste receptacles? This may Figure 5-42 Bicycle

Ramp by Stairs. Figure 5-43 Accumulation of Notices. Figure
5-41 Abrasion on Masonry Steps.

Figure 5-44 Notices in Convenient Location.

Figure 5-45 Paper Dispensers and Receptacles. W

Figure 5-46 Debris at Trash Enclosure. indicate the

inadvisability of providing built-in containers when the
owner is go ing to hire a supply firm to put in their own
system (Fig. 5-45). It would be better to save the money
for use elsewhere. Are there similar problems outside? Is
there an accumulation of debris at the trash enclosures
(Fig. 5-46)? Or what if the architect forgot to in clude a
mailbox in a design? One could show up just outside of the
school door (Fig. 5-47). Unlike the more descriptive space
in ventory, the purpose of trace observation is to
discover relationships explaining how people behave in and
use spaces. Just as the good physician does with a
patient, it is necessary to look very closely to make the
correct diagnosis, so proper treatment or intervention can
be prescribed. For ex ample, in the programming for the
College of Architecture and Environmental Design at
Arizona State University, the program mers documented
numerous situations that indicated problems with existing
spaces. The faculty offices were found to be much too
small to accommodate all of the stor age space needed for
books and oversized documents and models (Fig. 5-48). As a
result, the program called for larger of fices and better
provisions for storing oversize materials. The
accumulation of furnishings and equipment near a required
exit from the Architecture Library at The University of
Arizona indicates a need for more space and attention to
safety issues (Fig. 5-49). Similarly, heavy barricading and
bolt ing of the rear exit door of a gun shop is probably
a very good indicator that there are serious problems with
burglary and theft that must be dealt with during de sign
(Fig. 5-50). %
Figure 5-47 Mailbox near School Entry.

If^ rupce +i\ F^or^i-'LXAr. »*■ **a*«NXV-f A. 0COC

fteajJgg' »&] £*4A ier& A * C * in . T H € ’ vxi*rC \ € V

iT its f^Aui-TW neeirtee- « s x > n/\-»ito^ AajSC P-»XO^
faOTb A^fc ^WACW^O LlA? tX*T TtS A. Of- -»(T>o^jS.

Figure 5-48 Typical Faculty Office.

Credit: Greg Daugherty, Marianne Dziki, and Leanne Streit,

1986.

Permission: School of Architecture, Arizona State

University Figure 5-49 Library Exit Area. Figure 5-50 Rear
Door of Gun Shop. Credit: Ethan Hine, 1987. Gun Shop
Program. Permission: School of A rch itec ture, Arizona
State University * a # \ M\Lp£j

Figure 5-51 Solar Oasis Pedestrian Circulation.

Credit: Richard Larry Medlin and NBBJ/Gresham Larson, 1988.

Program for

the Arizona Solar Oasis, Phoenix, Arizona. Permission:

Richard Larry Medlin

Figure 5-52 Jefferson Park Behavioral Map.

Credit: Hester, Randolph T. Jr. 1975. Neighborhood Space.

Stroudsburg, PA: Dowden,

Hutchinson & Ross Inc. Permission: Randolph T. Hester Jr. B

E H A V IO R A L M A P P IN G Behavioral mapping is a
technique de veloped by social scientists to obtain a
better understanding of how people use various public
spaces (Ittelson et al. 1 9 7 0 ; Cook and Miles 1 9 7 8
). It typically involves the use of a map or plan of the
space or place being stud ied. The observer takes this map
to the site and records where people are lo cated and
codes what they are doing. This is done throughout an
entire time cycle, often at different times of year, in
order to get a good idea of how the space or place is
used. The frequency counts can reveal heavily used areas,
seldom used areas, paths of travel, places of
conversation, and the like and, hence, can be most helpful
to the programmer in coming to an under standing of
existing behavior in a space. This is of value when re
modeling or adding to an existing space. It is also of
value in com ing to a general understanding of how people
use space. Pedestrian patterns are shown in the follow
ing illustration from the program ming study for the Solar
Oasis in Phoenix, Arizona (Fig. 5 -51). A more specific
behavioral map showing a variety of activi ties occurring
in an urban park was conducted by Randolph T. Hester Jr.
(1 975 ) in the Big Court of Jefferson Park (Fig. 5 -52).
An excellent example of such mapping is shown in the film
The Social Life of Small Urban Spaces by William Whyte (1
9 8 8 ). In this study, Whyte discovered that the key
elements in designing a sueActivity Key [tech letter op
the petwi doing thit h Siop ton* % ThartfliAfl 9ui p p p p
p p p p p p p p p p p p p b b b b b a a a a o a b b b b b
b b b b c c c d d d 1 f f f I f f b b bo o b b o t a c o
a df o a h h h h h c c c c c c b b b b b b b b b b b b f
O 20 AO U | JEFFERSON PAf K BIG COURT Ecology Observations
Total forMav 28 and 29. 1970- -Sunny and Warm

cessful urban space included:

sun(light), access to street,

seating, water, trees, and food

vendors as important elements,

and a combination called “tri

angulation” as key to attracting

users. Studies by Downs, Stea,

and others (Downs and Stea

1973) have revealed similar in

sights for both outdoor and in

door environments. A simplified version of the

same technique can be used in

mapping existing circulation

systems when programming for

the expansion of existing facili

ties. It is also useful in studying

places of particular congestion

or importance, such as the

nursing station in a hospital or

the cooking and serving areas

of restaurants, in order to de

termine the space or arrange

ments required to relieve traffic

congestion or especially incon

venient movement in these

kinds of situations (Fig. 5-53). SHALL COMMERCIAL BUILDING

FACILITY » OBSE RYER Vho, (h*s w hit, to /w ith ’whom,
vh<*n( v tn fr * , how? Does Arch no Ip o r hinder? How
could do be tte r? SYSTEMATIC OBSERVATION DATE * / l
«..... ft— 3? ~ S a k b a /s path ~ 'S PATH path Figure
5-53 Specialty Bakery Serving Area. Credit: Radziah
Mohamad, 1987. Specialty Bakery Program. Permission: School
of A rch i tecture, Arizona State University

S Y S T E M A T IC O B S E R V A T IO N • Problem Oriented
• Multiple Focuses • Time/Scale Sampling • Statistical
Analysis Systematic observation as used in programming
differs from

other types of observation in several respects. First, it

is planned

or structured to obtain specific information about

previously identi

fied problems in the relationships between buildings and

their hu

man content, their physical surroundings, and elements of

the

buildings themselves. Second, it is structured to minimize

bias

and preconceptions by making certain that the observer

takes into consideration all factors that may be
influencing a particular en vironmental situation. It is
an important supplement to the other forms of observation
when some question about conflicting find ings needs to be
resolved. • Problem Oriented: In programming, systematic
observation should be conducted only to answer specific
questions raised or to test specific hypotheses developed
from the results of the other five forms of observation,
the initial interviews, and the literature search and
review activities. If the interviews conflict with the
observa tions relative to how some space is used, it may
be advisable to set up a specific study to discover the
actual behavior in a space. For instance, if doctors and
nurses have different perceptions of where they spend
their time and on what kind of hospital ac tivities, it
may be possible to set up a situation in which the doc
tors and nurses can be observed systematically over a
period of time to confirm or disprove the other findings.
This would be im portant, of course, only if the results
could make a design differ ence and impact on some
important human values. In the above example, this could
involve the time it takes the doctor or nurse to get to a
patient who suddenly is discovered to be in a life
threatening situation—the survival value comes into play.
How far can the nursing station or the doctor’s parking
area be from a patient room and still maintain an
acceptable margin of safety? Functional values could also
be involved. How many times can nurses go between the
nursing station and a distant patient’s room in an
eight-hour shift without compromising their effective ness
due to exhaustion? The problem to be studied should be one
that is considered im portant relative to the design of
the facilities to be programmed and for which the previous
evidence regarding requirements is in conclusive. •
Multiple Focuses: In order to ensure that all parts of the
par ticular problem are considered, it is usually wise to
alternate the focus of observation between people, places,
tasks, and objects. - People If people are the primary
focus, the observation ac tivity may involve the tracking
of people to see what they do during the course of a
workday. This would include fol lowing them about and
recording what they do, with whom they interact, how and
when certain interactions take place, what furnishings or
equipment support the in teraction, and on. This was
accomplished very well by Roslyn Lindheim in a hospital
study titled “Putting Re search to Work” (Lindheim 1966).
It allowed her to diag

nose which areas in a

hospital had essential

relationships with each

other (Fig. 5 -54)

Places If places, or set

tings, are to be the focus,

then the observation

will involve staying in

one place and noting all

of the people who use

the place, why they use

it, when they use it,

whether they do it

singly or in groups, and

again what furnishings

or equipment tend to

support the interaction

(Barker 1 9 6 8 ). For ex

ample, careful observa

tion of multiple patient

rooms in special care

facilities for the elderly

has led researchers to

the conclusion that a

single person will occupy

the room (Fig. 5 -5 5 ),

and that the others will

be absent as often as

possible (Pastalan and

Carson 1 9 7 0 ).

Tasks A focus on tasks

would result when

someone has identified

the importance of a

particular activity, and

the designer must know

how many and what

kinds of people are in

volved in the activity,

where and when it

takes place, and the

props that are used to

1 9 7 6 ) . © ©-©©>—- ®(© r0®% f _,h © @ @ ( 3 0 ) @@ © '

® ® :,r-® 1- 2 1- 3 2- 4 3- 4 4- 5 10-11 7- 9 9-11 11-13
13-14 6 - 8 8-12 12-15 Physician has completed patient’s
exam. Physician tells nurse to order X-ray examina tion.
Physician calls radiologist to check on X-ray exam. Nurse
makes appointment with Central Ap pointment Facility by
sending requisition. Radiologist verifies type of
examination with CAF. CAF communicates confirmation to
nurse. CAF sends patient information to master file. CAF
sends requisition to in-patient informa tion facility.
Nurse prepares patient. In-patient supervisor checks
requisition and plans schedule for patient. In-patient
information facility contacts nurses’ station concerning
availability of patient. In-patient information facility
sends orderly to pick up patient. Orderly reports to
nurses’ station. Orderly picks up transportation vehicle.
Orderly locates patient. Master file clerk pulls patient’s
card. Master file clerk gives information to file orderly.
Orderly pulls patient’s old films and diagnostic
materials. Orderly takes films to assembly desk. Clerk
takes films to technician in charge of fluoroscopy rooms.
In-patient orderly brings patient to X-ray. HOSPITAL A
16-18 18-19 19-20 16-20 20-21 21-22 22-23 23-24 24-25
25-26 26-28 28-29 31-32 28-33 33-34 Technician picks up
patient's records. Technician identifies patient. Patient
is waiting. Technician brings patient to X-ray room.
Examination takes place. Technician identifies the film.
Technician brings films to processing room. Films are
developed. Technician inspects films. Clerk brings films to
assembly table. New and old films are put together (if
there are no old films, a new envelope is prepared).
Radiologist inspects films. Radiologist tells supervisor to
discharge patient. Supervisor tells information desk to
discharge patient. Patient waits. Information tells
orderly to return patient to the wards. Orderly leaves the
department with patient. Radiologist records the
diagnosis. Secretary picks up the recording of the
diag34-35a File clerk brings envelope to file room. 35a-36
A copy of the diagnosis is pasted to the envelope by the
file clerk. 36-37 File clerk files envelope in file room.
37-38 Physician checks the films and reads diagnosis.
33-37 Physician and radiologist confer. Figure 5-54
Uncoupling Spatial Systems. Credit: Lindheim, Rosyln, 1966.
Putting Research to Work. AIA Journal. February: 46-53.
Reprinted with permission from ARCHITECTURE, February,
Copyright 1966, BPI Communi cations, Inc. support it
(Moore and Golledge Figure 5-55 Multiple Patient Room.
Figure 5-56 Layout of Manufacturing Facility. Credit:
Mostafa Shalaby, 1968. Dissertion: Optimum Layout of
Manufacturing Facilities, The University of Pennsylvania.
Permission: Mostafa Shalaby. - Objects Focus on objects is
crucial if the observer is to com prehend such things as
an assembly line cycle. An under standing of what happens
to a particular manufactured item, from the raw material
entering the facility to the finished product leaving the
facility, could effectively determine the optimal spatial
layout of a manufacturing plant (Fig. 5 -56). • Time/Scale
Sampling: It may not be readily apparent, but it is true
that we all live in different worlds. For almost any indi
vidual, the world changes day by day. For various
individuals, the scale of environmental focus can be
drastically different. One per son may visit a place and
concentrate on how the site impacts the buildings placed
upon it; another person may visit the same place and
concentrate on how the buildings impact the surrounding
FINISHED PRODUCT STORAGE FABRICATE PART 2 R A W M A T E R
I A L S FA^RjCATE [PART 1 i FABRICATE PART 4

community; still another person may concentrate on the views

from the site. In systematic observation it is important to
vary the

scale of observation to ensure that a complete

understanding of

the design problem will result. Scale is particularly

important as we consider the various

phases of programming. If the programming is for master

plan

ning, attention to the site and its surroundings is most

important.

It would be necessary to establish interrelationships of

various

buildings and other features both on and off the site. If,
on the

other hand, the intent is to produce a program for

schematic de

sign of a particular building after the master plan has

been estab

lished, then the focus will be narrower and relate to the

content

of the building to be designed as well as to its

interaction with the

immediate external environment. For purposes of design

develop

ment, the focus will be almost exclusively on details,

materials,

equipment, and furnishings to see how they are used and how

they hold up. In all cases, it is important to sample from

at least

the next higher and next lower scales to obtain a better

under

standing of the nature of the design problem. The various

scales of place focus include: • Region • Community •
District • Neighborhood • Site Surroundings • Site •
Buildings • Zones within Buildings • Rooms • Spaces within
Rooms Time of observation is also of considerable
importance. What

a person observes at one time of the day, week, month, or

year

may have little to do with what would be seen at another

time. In

the life of most businesses, Monday morning is a time of

consid

erable interaction and confusion. In the life of a church,

nothing

happens early Monday morning, because the big occasion was

the

day before. The observer must carefully sample from the

times

when it will be most fruitful to observe. This can be based

on what the clients and users have said about various
periods of use or by random or systematic sampling of all
possibilities. In pro gramming, however, because of the
typical lack of time and money to conduct a study, it is
usually necessary to concentrate on what the client/users
consider to be the crucial times. For any kind of retail
business, this might include the peak periods, the slow
times, and the typical or average times. In a restaurant,
the crucial times would be similar; however, these periods
might oc cur and be rather different three times each day
at meal times. However accomplished, systematic observation
must cover the complete cycle or cycles of use to obtain
an accurate understand ing for program diagnosis. Such
studies could have a crucial im pact on the size of the
facility, possibilities for outside overflow, for
one-person staffing at slow periods, or other such factors.
It may also be useful to understand the frequency and
duration of use. What are the peak periods of use? How
frequently do they occur? How long do they last? These are
important questions when it comes to planning ingress and
egress from a site. Will a traffic light be required? How
much backup space will be needed to minimize conges tion
and accidents? The same is true for interiors. How much
room is required at a nursing station in a home for the
el derly? (Fig. 5-57) If observa tion of several such
facilities reveals that these places are typically
congested at certain times of the day because many of the
wheelchair bound and other elderly gather to observe the
activity of the nurses, even when plans of the building
suggest that the residents should be elsewhere, the pro
grammer needs to understand why this is the case. The
client may wish to enlarge the area

Figure 5-57 Nursing Station and Dayroom. around the station

or to locate

Credit: (AIA Task Force on Aging 1985), 113. Permission:

American Institute of Architects & dayroom adjacent to it
in OrSOIL JANITOR STAFF NURSES' f t ™ ™ TOILET STATION U
CLEAN CENTRAL BATHING ■ H /TELEPH O N E STORAGE LLi C AC f
= ° V n Z V

DAYROOM/DINING

der to accommodate this typically unprogrammed activity,

rather

than allowing it to interfere with important nursing

functions

(AIA Task Force on Aging 1 9 8 5 ). Duration of an activity

may be of equal importance. If one ma

jor activity overlaps with another major activity, it could

create se

rious spatial problems. For instance, if people are coming

to park

for one event before people attending another event have de

parted, there may be a considerably increased need for

parking

for the few minutes of overlap. How is this accounted for

in the

existing facilities or other exemplary facilities? If a

facility is only

used periodically or seasonally, problems of shutdown and

startup

may be very important. Seasonal variation of activities may

be

pronounced, even for a continuously operating facility.

These vari

ations should be accounted for, even if the period for

observation

must be confined to only one season. It may require further

liter

ature search and/or interviewing to fill in the needed

information. These are all important issues that could have
major impacts on

design requirements. Systematic ob

servation, coupled with trace obser

vation and archival research for times

or events that cannot easily be ob

served, can prove most useful in un

covering important information that

can make a design difference. • Statistical Analysis:

Systematic

observation should be organized to

allow for easy analysis when infor

mation gathering is complete. If the

expected cost of error is not great,

this may involve the simple counting

of events and other descriptive sta

tistics to show the frequency, magni

tude, and distribution of various

events. The results of such counting

and averaging can be shown in his

tograms, pie charts, graphs, and ta

bles (Figs. 5 -5 8 through 5 -61). The

development of such statistics is dis

cussed in detail in a number of books

written by social and behavioral sci

entists (Siegel 1 9 5 6 ; Blalock 1 9 6 0 ;

Rosenbaum 1 9 7 9 ; Weisberg et al.

1996). % 35 ■ 1 8 5 + M 75-85 I 155-64 1900 1920 1940 1960

1980 2000 2020 2040 Percentage of Population over 65. The
over 55 population increased from 9 percent in 1900 to 21
percent in 1980. It will take a dramatic leap early in the
next century. Figure 5-58 Histogram: Percent over Age 65.
Credit: (AIA Task Force on Aging 1985), 2. Permission:
American Institute of Ar chitects 3 0 2 5 2 0 1 5
1 0 5 0 j 65-74 SELECTED TABLE FROM ARCHITECTS HIRING
CRITERIA When schools of architecture place such an
emphasis on the portfolio, it is sometimes difficult for
students to realize th at the portfolio may not be the
single most important tool when looking for work. Perhaps
one of the most informative questions on the professional
survey asked the alumni to distribute 100 points between
conventional job-seeking tools in order to rate the
importance of each tool. Please see "Alumni Rating of
Relative Importance of Job- Seeking Tools.” Alumni Rating
of Relative Importance of Job-Seeking Tools 18.25% I
PerRonal interviews. ■ Letters of recommendation. □
Connection to familiar contacts. £3 Cover letters. II
Follow-up phone calls. B M ailer. Figure 5-59 Pie Chart:
Job-Seeking Tools. Credit: Daniela Fruenfelder, 1993.
Master's Thesis, Decoding Architect's Hiring Criteria and
Students' Percep tions of the Job-Seeking Process, in
Communication, College of Architecture, The University of
Arizona, 21 July 1993,2. College of Architecture, The
University of Arizona 50 40 j 30 20 10 _L _L _L J_ J
SUNDAY MONDAY TU ESD A Y WEDNESDAY THURSDAY F R ID A Y
SATURDAY DAY Fig. 4. The percentage of occupancy of study
stations on each floor of the library for the week of
November 3 to November 9, 1974. Figure 5-60 Frequency:
Percent of Occupancy. Credit: Robert Cass, Fred Marks, and
Steve Sedor, 1974. Research Study on Use o f Existing and
Future Space in Hayden Library. Permission: School of
Architecture, Arizona State University O---O FLOOR 1 O--O
FLOOR 2 £> & FLOOR 3 □ --□ FLOOR 4 0----0 FLOOR 5 5.66
5.91% 7.91% I 14.20% - 3.47% 39.35% □ Portfolio. B
Resume. >• u z < SLI 331 o o H z w o DS g QUESTIONNAIRE
SUMMARY PART 1 CHANDLER TEACHERS FIGURE 12 Q U E S T I O N
Windowed Windowless I lik e to be in th is room# Pos Pos
I find i t easy to teach in th is room. Pos Pos I lik e
to spend the en tire day in th is room. Neutral Pos This
room gets too cold. Pos Neutral This room gets too hot.
Neutral This rooa doesn’t get enough ven tilation , Pos
Pos Neutral I t ' s too bright in th is room. Pos Pos I t
gets too noisy in th is room. Neutral Pos I fee l
confined in th is room. Pos There i s n 't enough privacy
in th is room. Pos This room makes me fee l tire d . Pos
Pos Thi3 room is depressing. Pos Pos The students are
easily d istracted in th is room. The students are
anxious to get outside. Neutral Pos This room needs more
tack space. Pos Pos I fee l th at I don't have control
over temperature conditions in th is room. Pos Neg I fee
l secure leaving valuahles in my room overnight. Neutral
Neutral I lik e the way th is building looks. Pos

Figure 5-61 Table: Windowed versus Windowless.

Credit: Patricia Partridge, Tony Rodriguez, Barbara Sacks w

ith Professor Robert Hershberger, Advisor, 1983.

Windowed vs Windowless Schools: An Analysis o f Economy

Behavioral and Academic Effectiveness. Post

Occupancy Evaluation. Permission: School of Architecture,

Arizona State University If the costs of error are likely
to be very high, as with a fre

quently repeated element such as the patient room in a

hospital,

a space station environment, or even a building to be

repeated

many times across the country, then the client may be

satisfied with

nothing less than a study in which the probability of an

error oc

curring might be as little as .001 percent. In other words,

this would Pos involve setting up an experimental or
quasi-experimental situation involving significance tests
using inferential statis tics. In such cases, the
beginning pro grammer would be advised to associate with
an environmental scientist familiar with the conduct of
such studies to make certain that the probability of an
event can be predicted accurately. The devel opment of
such studies is the subject of complete textbooks and will
not be cov ered here (Bechtel et al. 1987). Observation
Formats A number of different observation for mats have
been developed for systematic observation studies (Zeisel
1981). One approach is to take the various focus cat
egories and develop a holistic informa tion listing (Fig.
5-62) to be certain that a complete observation has been
taken and recorded (Lindheim 1966). The first six
categories are capable of observation and are descriptive
in na ture. The final two categories are the subjective
interpretation and diagnosis by the observer, as well as
suggestions or prescriptions by the client for possible
treatments or interventions that would improve the
situation. These cate gories help to develop understanding
of the relationships between human activities and the
architectural environment. The descrip tion alone means
little unless it results in an accurate diagnosis of the
problem, so that an appropriate remedy can be proposed.
Some observers are comfortable with such a structured
matrix. Others prefer to keep the eight categories in
their heads or only at the top of the first recording
sheet, to allow for more freedom of response and recording
in each of the focus categories. The re mainder of the
sheet can remain blank for recording a series of ob
servations, taking as much space as needed, including
additional pages. The important thing to remember is to
cover all of the fo cus categories listed at the top of
the sheet. It is hard to tell when

B ldg._______________ Rm. Date

Who (principal characters)

Does What (activity, task)

To/With Whom (others)

How (with what objects)

Where (place, setting)

When (time, frequency, duration)

Does architecture help or hinder? Why?

Could it be better designed? How?

Figure 5-62 Observation Form #1.

observing what information will prove to

be useful during analysis (Fig. 5-63). Another format used
in the walk

through observation and by experienced

observers for systematic observation in

volves creasing the observation sheet

near the center and reserving the left side

for observations and the right side for

commentary, as described on page 251. In any format, it is

important to be

clear about what is actually observed and

what is inferred from it. The two types of

information should not be mixed, so

someone else can make sense of the infor

mation when it comes time to incorporate

it into the program. In other words, ob

served facts and inferred ideas or con

cepts should be kept distinct, so that a

person interpreting the results does not

mistake a fact for an idea, or vice versa. Depending on the

specificity of the re

search task, it might be necessary to de

velop a recording format specifically for

the observation task. For example, this Figure 5-63

Observation Form #2.

could include the floor plan of an area to

be used for behavioral mapping. It could also involve a

series of

specific questions or required observations in which a

simple

count is taken. Such forms must be developed in response to

the

observation to be undertaken. In any case, the observer

should

become very familiar with the observation problem(s) to be

able

to make critical observations, and not to collect a great

deal of

useless data. In programming, the emphasis should be on

gather

ing only the information necessary to develop an

understanding

of the design problem, rather than gathering as much

information

as possible.

Photographic Methods

A number of social scientists (Collier 1967) and programmers

(Davis and Ayers 1975) are strong advocates of photographic

documentation as a primary observation method. There is no

subBldg._____________ Rm.________ Date_______ Who, does
what, to/with whom, how, when, where? Does Arch
help/hinder? How can design it better?

m s I I I I . . I V n i l I I W I H > Dropoff# Pick up

of )VVt l i C v i A a r < V»v ^ C A *o k i>i^ wAY ft|
PV>#r *yjyjC ^ (AA»\ U, Aut&duVl#. - A<U^uuuCt AU*

•4. Mur.vo <5s>i^ s.*^ <k'r \«. ■*» OCA*»V< <K*sdk ^ r o >
A V c 4 stitute for such documentation when it comes to the
space inven tory. Photographs of rooms showing all of the
principal elevations, the furnishings within the room, the
type and spacing of light fix tures, and the like are
invaluable as the programmer begins work on space
requirement sheets for the new or expanded facility. It is
impossible to remember all of the details of the existing
spaces un less they have been documented. Photographs are
undoubtedly the most accurate and efficient way to
document everything in a space. Various programmers
advocate different film types for this job. Polaroid shots
have the advantage of letting you know immedi ately if you
have recorded the needed information and allow cod ing of
room, orientation, and special commentary as you proceed.
It is, however, quite tedious to use this proce dure on
large projects. An al ternative for the competent
photographer is to use high speed color print film and
either a log or previously pre pared plan of the building
on which to show the location of each shot by number.
Addi tional information such as room name, furnishing, or
ceiling heights can also be recorded in any of these for
mats. Digital cameras are be coming popular and have the
advantage of direct transfer into the program documents.
It is rather easy to document trace evidence using any of
these methods. Photographic images make very convincing
evidence of findings when in cluded as part of a program
ming report (Fig. 5-64). Photographic techniques for
systematic observation are much more complicated

3 . Vtevsj C<x^vue.« c t o o a T - T a^ h c *1© fet

eJUMfcuJ

Figure 5-64 Annotated Photograph: Drug Store.

Credit: Marcia Morris, 1987. Drug Store Program.

Permission: School of Architecture, Arizona

State University

and expensive (Webb 1981). They often involve time-lapse

pho

tography to cover the full spectrum of use of a facility.

As with

other systematic methods, this approach is most fruitful

when

a hypothesis has been generated. It is important to

generate ac

tual counts to determine if what was observed at a certain

time

was really characteristic of a total situation. This allows

re

peated observation of the same place, so that information

missed the first time can be picked up later. The approach
is es

pecially valuable when some important architectural feature,

such an escalator or conveyor, is going to be used in a

major

public building and there is concern about how well existing

ones work.

5.4 Questionnaires and Surveys • Relationship to Other

Methods • When to Use the Questionnaire • Planning Is
Essential • Understanding • Questionnaire Preparation •
Steps to Prepare a Questionnaire • Logical Order of a
Questionnaire • Question Types • Sampling • Bias • The
Survey • Data Analysis • Cost of Error A questionnaire is
an instrument that employs a predeter

mined set of questions to be answered by a respondent. A

sur

vey is the administration of the questionnaire to a group of

respondents. It can be administered by an interviewer who

records the responses, or given to the respondents to

answer at

their convenience (Blalock 1960 ; Berdie et al. 1986 ;

Weisberg

et al. 1996). Relationship to Other Methods The

questionnaire/survey is different from diagnostic
interview ing, primarily because it relies on
pre-established questions, which each respondent is asked
to answer. The questions typi cally are closed, that is,
having a limited rather than an open- ended response
format. The respondent is required to follow both the line
of questioning and the line of answering predetermined by
the persons preparing the questionnaire. Unlike
observation, both interviews and questionnaires treat the
respondent as a sub ject rather than as an object. They
are also more intrusive than observation in that they
require the respondent’s full attention. The
self-administered questionnaire is somewhat less intrusive
than the interview, because the respondents can answer the
ques tions at their at a time and place of their own
choosing. However, the questionnaire requires respondents
to answer questions de veloped by the programmer in the
order presented—to accept the programmer’s agenda rather
than discussing areas of greatest per sonal interest. As a
result, the diagnostic interview tends to be more
effective in discovering issues of importance to the
respon dent, while the questionnaire is usually more
effective in obtain ing factual information about specific
facility and equipment needs. The questionnaire can also
be very effective in determining whether or not most
respondents share the viewpoints of those initially
interviewed. Like the interview, and unlike observation,
the questionnaire can be used to get at why people do what
they do, what they think works well or poorly, and how
they think something might be done better—but only within
the limits of the alternatives actually provided in the
questions. Just how effective the questionnaire is in this
respect depends on the proficiency of the programmer in
preparing, administering, and analyzing the results of the
questionnaire. When to Use the Questionnaire A
questionnaire should not be used in architectural
programming until after literature review, diagnostic
interviewing, and diagnostic observation have been
completed. Even then, it should be used only if it would
be more expensive to obtain additional needed informa tion
by continuing with the other information gathering
techniques. For most small- to medium-sized programming
commissions this

is rarely the case. It is usually quicker and less

expensive simply

to go back and ask someone for additional information or to

count

or measure something to obtain the missing data. The time

and effort to prepare, administer, and analyze a ma

jor questionnaire intended to obtain information about

respon

dent values, goals, needs, and ideas is warranted only when

programming facilities for very large or complex

organizations.

On those occasions, it is advisable to employ a survey

specialist

to assist in developing and administering the questionnaire

to en
sure its reliability and validity. It is, however,
important for the

programmer to understand the purposes of the questionnaire

and

the procedures to be followed in order to provide guidance

to the

specialist. It is also important for the programmer to be

able to

develop and administer more limited questionnaires focusing

only

on specific facility, furnishing, and equipment needs for

mid-size

projects for which funding for professional survey

consultants

may not be available.

Planning Is Essential

While casual (unplanned) observation and interviewing are

both

reasonably effective ways of obtaining useful information

about

issues of importance to various user groups, there is no

such use

fulness to casual questionnaires. The effective use of

question

naires requires more preparation than any form of

interviewing

and most forms of observation. The programmer must first

estab

lish what information is needed, and then use the

questionnaire

only if the information cannot be more easily obtained by

search
ing the literature or through interviewing and/or
observation.

Having established that a questionnaire will be required,

the pro

grammer must determine the specific questions that should be

asked to obtain the needed information. It must also be

estab

lished who will receive the questionnaires and whether the

se

lected respondents can provide reliable and valid answers.

It

should also be determined if there is enough budget and time

available to administer and analyze the questionnaire.

The medical analogy might once again be of some use, even

though it breaks down in several respects. Most physicians

have

developed a medical history form, a questionnaire that they

use

to ask each patient (or parent) to complete prior to

interviewing

or observing the patient. Such questionnaires ask about

basic de

mographics: name, address, occupation, age, sex, and the

like. They also ask about previous illness (even in the
patient’s family), if related persons are still alive,
current medications, allergic reac tions to drugs, and so
on. You might wonder why such a standard questionnaire is
not appropriate in architectural programming? The answer
is that most people are very much alike in terms of their
basic anatomy, physiology, and types of medical problems.
Most buildings are not! Each building type has fundamental
dif ferences in organization and structure as well as
specific space needs. The doctor is trying to diagnose
problems within a group of similar entities. The
architectural programmer is trying to di agnose the nature
of the entity itself, an entity which as yet does not
exist, albeit an entity nowhere near the complexity of the
hu man body. There are, however, instances in which the
medical analogy is appropriate regarding the use of
questionnaires in architectural programming. If an
architectural programmer has done numerous programs for a
particular type of facility (offices, hospitals, schools),
there are likely to be recurring questions. Question
naires developed to provide such information on previous
pro jects might be adapted for use on each new project.
Such repetition has the advantage of developing some
standards of comparison and eventually, perhaps, of
developing some general- izable knowledge about the nature
of a particular institution, user group, or activity area.
In any case, the time and effort re quired to develop an
appropriate ques tionnaire for each new commission should
not be expended until the pro grammer has a good idea of
the nature of the specific architectural problem. This
can usually be determined through literature search and
review, diagnostic interviewing, and diagnostic observa
tion. If information is still needed, a questionnaire can
be developed to test preliminary conclusions or to uncover
additional facts about the user, con text, climate, etc.,
that would be too time consuming and costly to generate
through additional diagnostic inter-

Figure5-65 Typical Checklist Questionnaire. viewing or

observation (Fig. 5-65).

Name______________ Position_______ Date _J_J_

1. Please check all of the equipment needed for your

workstation: 3'x4' desk or 3'x5' desk ; typing re tu rn ,
left s id e or right s id e ; secretary ch a ir , with a
rm s or w ithout ; side chair(s) , with arms or without ;
table lam p , telephone computer (model type and number, if
known_______________________); filing cabinet(s) (indicate
number of each) 2 drawer , 3 drawer , 4 drawer ; shelves
(indi cate linear feet______________ ); other___ (please
name each item)_____________________________

Understanding

The purpose of the entire programming process is to obtain

and

communicate the information needed to help the designer

obtain

a correct understanding of the architectural problem. The

intent
is not to generate a large quantity of descriptive data.
The ques

tionnaire is different from diagnostic interviewing in that

its pri

mary use in programming is to obtain supporting evidence:

facts,

opinions, and needs to enrich understanding, rather than to

ob

tain a broad understanding of the issues and activities

important

to the client and user groups.

Questionnaire Preparation

The process of preparing a good questionnaire is quite

involved

and time consuming (Berdie et al. 1986; Weisberg et al.

1996). It

is similar to when a professor prepares an “objective” test

using

true-false and/or multiple choice answers. It is time

consuming

and even exasperating to develop a series of “objective”

questions

to test the broad issues and understandings that an

instructor

hopes the student has obtained. Such “objective” tests do

not lend

themselves to questions about broad issues or areas of

under

standing. Rather, they tend to force the teacher to ask

about facts:

names, dates, and formulas which the student must memorize.

However, if the instructor is able to develop a

satisfactory set of
questions, the answers can be placed directly on a computer
cod

ing sheet by the student and machine graded, thus taking

virtually

no time on the part of the instructor to analyze the

results. On the

other hand, if the instructor chooses to administer a

“subjective”

short answer or essay test, the problem is reversed. It may

not take

long to develop a set of satisfactory questions, but the

reading and

evaluation of the answers will be time consuming and

fraught with

subjectivity as the grader tries to determine if the

students really

understood the material on which they were being tested.

In programming, the way out of the dilemma is obvious. Use

the diagnostic interview to get at the broader conceptual

issues.

Use the questionnaire to confirm or refute what has been

discov

ered using the other information gathering methods, but more

particularly, to obtain information on the specific space

and

equipment needs of the individual respondents. In a large

organi

zation, obtaining this type of information could be very

time con

quirements that served as

the starting point for devel

oping a questionnaire on

how to improve the archi

tecture building at The Uni

versity of Arizona (Fig.

5-66). Determine who

should be answering the

questions: client, users,

others. There is no sense asking

a question of someone who

has no idea how to answer

it, or who may provide ir

relevant or inappropriate

answers. Should there be one overall questionnaire to be an

swered by everyone, or should there be two, three, or more

dif

ferent questionnaires to be answered only by those capable

of

answering particular questions? Would it be easier to go

back to

certain key individuals and ask them some of the questions?

Just

as information should be provided to those who need to

know, in

formation should be sought from those who do know. The

chances are that a number of questions will be dropped from

the

questionnaire as a result of this analysis and re-addressed

by di

agnostic interviewing or observation. A number of other

ques

tions will be asked only to subsets of the respondents.

PR EPAR E A S C H E D U LE FOR THE T Y P E S OF

Q U E S T IO N S TO BE A S K E D

Organize the needed information so a systematic way of

asking the

questions can be developed. Will demographics come first?

Will

opinions on organizational issues come second? Will

controversial

issues follow? Will detailed personal equipment needs come

last?

How can each of these question types be best asked? Can

each ques

tion within a group be asked using the same format? If not,

should

a subset be formed to allow two or more different question

types?

D E V E L O P S P E C IF IC Q U E S T IO N S FOR E AC H

P A R T OF THE Q U E S T IO N N A IR E

Write down each question as clearly as possible using

simple ter

minology. Consider at all times what the designer really

needs to 1. Shop facilities are completely inadequate and
poorly located. 2. Studio spaces are not large enough to
provide adequate student stations at the sophomore and
junior levels. 3. The lecture room is unattractive, noisy,
and cramped, with uncomfortable seating. Its lighting
controls are very difficult to use effectively, especially
by visiting speakers. It is also difficult for visitors to
find. 4. The slide library is much too small and crowded.
Figure 5-66 Key issues and requirements. know to make
design decisions. Will a simple “yes” or “no” answer suf
fice? Are there several options that allow for a multiple
choice response? Can the question be an inventory list,
where the respondent simply checks off the appropriate
cate gories? Or does there need to be a ranking of items
in terms of priority? Should the answer involve rating,
such as from “highly desirable” to “highly undesirable?”
Should the question be open-ended, requiring the
respondent to fill in a blank area with his/her own words?
Try to ask the question in a way that will get the needed
information in as clear and understandable a manner as
possible, so that the an swers can be easily coded, tabu
lated, and computer analyzed (Fig.

Figure 5-67 Checklist versus Rank Order. 5-67). Would a

simple checklist or a rank ordering be better? Would the
ranking questions yield important information not ob
tainable by the checklist questions? Or would a rating
question be more desirable and easier to analyze? Would
it be desirable to know why (Fig. 5-68)? After a series of
questions has been formulated, it is relatively easy to
see if some questions are asking the same thing and, thus,
might be combined or the least effective ones eliminated.
By reviewing the ques tionnaire goals and the question
categories, it is also possible to see if an essential
question has been left out, or that a question, as
phrased, will not obtain the desired information. Revise
the questions as necessary to arrive at the needed
information (Fig. 5-69).

1. How does Room 103 function as a classroom? excellent___

goodfa ir poor______ very poor__
Why?________________________________________

2. How does the T.M. Sundt Gallery function? excellent___

good _fa ir poor______ very poor__
Why?________________________________________

Figure 5-68 Rating Scale with Explanation.

1. In addition to the equipment currently in the shop,

which of the following should be in the new shop? Check all
that apply. a. metal working and welding equipment b.
plastic working and molding equipment c. ceramic working
and finishing equipment d. miniature model making tools e.
painting booth f. other or Rank order from 6 (most needed)
to 1 (least needed) a. metal working and welding equipment
b. plastic working and molding equipment c. ceramic working
and finishing equipment d. miniature model making tools e.
painting booth f. other ............... Does including
“why” pro

vide the programmer with es

sential information? Will there

be enough analysis time for

the programmer to code and

tabulate all of the “why” an

swers, especially if they are di

verse? Would it be better to

ask more detailed questions

about each room (Fig. 5-70)? In the previous example,

would it be important to add

a follow-up ques

tion such as in Fig.

5-71. Rate how each space functions excellent good fair

poor very poor a. Room 103 __ __ __ __ __ b. Room 204c
__ __ __ __ __ c. Room 302 __ __ __ __ __ d. Conf.
Room __ __ __ __ __ e. Sundt Gallery __ __ __ __ __
f. 1st fir studio __ __ __ __ __ g. 2nd fir studio __
__ __ __ __ h. 3rd fir studio __ __ __ ___ __ i. Grad
studio __ __ Figure 5-69 Combining Questions.

A N S W E R THE

Q U E S T IO N S A S

IF Y O U WERE

IN E AC H

R E S P O N D E N T

G R O U P

Gan the people you

will be questioning

really answer your

questions? Will the

answers be as you

expected? For ex

ample, in a multi

ple choice format,

the respondent may

wish to choose two

or three answers,

or think to herself,

“Well, sometimes

it’s this way, and

other times it’s that

way, now which

should I check?” 1. Evaluate the effectiveness of Room 103

on the following scale excellent good fair poor very poor
a. size __ __ b. siaht lines c. seatina d. acoustics __
__ e. liahtina f. liahtina control g. ventilation __ __ h.
slide proj. i. video j. overhead proj. __ __ k. chalkboard
__ __ I. floor surface m. HC access Figure 5-70 More
Detailed Questions. Indicate the most needed improvement(s)
Figure 5-71 Follow-up Question. Can the question be phrased
to avoid these difficulties? Or, quite often people in one
respondent category simply will not have the understanding
necessary to answer the question. For example, first-year
students who have not yet been admitted to a professional
program in architecture will not know how well the upper
division studios work. If you asked them that ques tion,
they might respond, but how much confidence would you have
about the answer? Similarly, questions relating to the de
sired size of a space or object are often very difficult
for layper sons to answer. They may be able to tell you
what they do and what equipment and/or furnishings they
need, but few can tell you the size of space that will be
required. That is something that the programmer will have
to figure out from the answer able questions and the
wealth of information that can be ob tained in other ways.
REVISE THE QUESTIONS TO MAKE THEM CLEARER This is an
iterative, laborious process. The questions have to be
just right or you receive practically nothing of worth for
your ef fort. You cannot probe, answer the respondent’s
questions, or give examples of what you mean if you are
not there to do so. This, of course, is a good reason to
have an interviewer admin ister the questionnaire. Even
so, if it becomes clear after a num ber of persons have
already responded that a question has been poorly written,
what should be done with their answers? It is much better
to spend the time and energy beforehand to be cer tain
that problems will not occur that could invalidate some re
sponses. The story is told about one of the early Kinsey
Reports on the sex lives of Americans of a question that
asked: “Do you think that new babies should be
sterilized?” The majority of re spondents said “Yes.”
Apparently these people thought the question related to
keeping babies clean or in a clean environ ment. Others
who responded “No” apparently thought the question dealt
with sexual sterilization. But could anyone be certain?
Because there could be no follow-up, as in the diag nostic
interview, there was no way to tell what the respondents
really did mean, so the question had to be discarded. There
was no reliable way to interpret the result. The same
frequently hap pens with much less controversial topics
such as those found in architectural programming.

ATTEMPT TO TABULATE THE ANSWERS

AND SUMMARIZE THE RESULTS

If only one or two persons in the organization can answer a

ques

tion, ask them! There is no sense in asking everyone. Most

orga

nizations are not truly democratic. The opinion of the boss

will be

far more important than that of a temporary employee. But

if you

need a majority opinion or to summarize or average the

answers

from some particular group, can it be done with the type of

an

swers you will be receiving? Can these answers be easily

analyzed

by computer? Will you have enough time and money to hand

code

and tabulate the answers? If not, you may need to

reformulate the

questions so that the answers can be more easily tabulated.

Or

you may wish to reassess your strategy and be satisfied

with the

results of additional interviews with a few key people.

REVISE THE QUESTIONS TO MAKE TABULATION POSSIBLE

Does the question really need to be answered? Can the

program

mer figure out the answer from the literature review,

interview

ing, and observation activities? Are there standards

available and

little reason to suspect that the current situation is

really unique?

Could a different question be asked that would confirm the

stan

dard or reveal the few ways in which the situation is

unique?

Many questions simply need not be asked. It might be

interesting

to know, but in truth it is not likely to make even a minor

design

difference!

Why burden the respondent with the question and the pro

grammer with the work of tabulating and trying to make

sense of

such answers? There is rarely time or budget to waste in

pro

gramming. But for those questions that remain to be

answered in

a questionnaire, it is important to make it as easy as

possible to

administer, code, tabulate, and analyze the results.

PRE-TEST THE QUESTIONNAIRE WITH YOUR PEERS

AND MEMBERS OF THE RESPONDENT GROUP(S)

The pretest is an essential part of the preparation of any

ques

tionnaire. It involves a small number of respondents who are

asked to complete the questionnaire and to comment on its

mer

its and faults. It lets the programmer know if the

questions are

presented in a reasonable order, phrased in understandable

terms, and if the answers generated will be useful to the

designer. The programmer also learns how long it takes for
a respondent to complete the questionnaire and sees if it
is possible to make sense of the answers. Indeed, it
allows the programmer to check if all previous steps were
well carried out. At least two pretests should be
conducted. In the first pretest, it is desirable to ask
other members of your peer group, particularly the persons
most likely to be involved in the design and design de
velopment of the project, to pretend to be respondents as
they com plete the questionnaire. There are five typical
steps in a pretest: 1. Ask the respondents to complete the
entire questionnaire while you keep track of the time it
takes them to do so. 2. Ask them to critically review each
question, the order of the questions, and the length of
the questionnaire. 3. Go through their answers with them to
see if they answered appropriately. 4. Ask them to offer
suggestions to improve the questionnaire. 5. Try to
tabulate the answers to determine if the results will be
understandable. Have you asked the most important
questions? Were they in a logical order? Was the
questionnaire too long? Did you ask lead ing questions?
Did you use jargon that could not be understood by some
respondents? The answers to these questions might prove
embarrassing if your colleagues are highly critical of the
questionnaire. However, as a professor once said (Ackoff
1967): Better to be a fool among your peers than before the
world. If you cannot take the constructive criticism of
your col leagues, it will be worse from members of the
respondent group. Actually, most respondents will be very
guarded in their criti cisms and suggestions to the
detriment of helping you improve your product. Because
your colleagues and friends have your best interests in
mind, they are likely to be more aggressive, hence more
helpful, in their criticisms and suggestions. After you
have repeated steps one through nine of question naire
preparation in answering the criticisms rendered in the
first pretest, it is time to conduct a pretest with
members of the re spondent group(s). This pretest should
involve two or three per sons from each of the actual
subgroups relating to the facility for

which the program is being prepared and should be conducted

us

ing the same three steps as in the first pretest. Again,

this pretest must be followed by a careful review of the

results to make certain that the answers given can be

coded, tab

ulated, and analyzed in a satisfactory manner. Will the

answers be

useful to the designer? Will they provide information that

will

help the designer obtain a better understanding of the

problem?

Indeed, it may be necessary to iterate through the entire

10 steps

several times to refine the final questionnaire. If this

appears to

be a very time consuming and tedious procedure, rest assured

that it is! However, it will be worth the initial time

spent in terms

of overall time saved. Students reading this material will

no doubt recall midterm or

final examinations in which certain questions were phrased

in a
very confusing way, or dealt with areas that had hardly
been cov

ered in the course, or were about trivial issues, when

important is

sues had been covered. Unfortunately, it is difficult for a

professor

to pre-test an examination because of the distinct

possibility that

the questions will leak to the remainder of the class,

invalidating

the test. And how would the instructor grade the students
selected

for the pretest? Fortunately, with a questionnaire there is

no such

problem, so validation of its potential effectiveness

through pre

testing can be done to the great benefit of the

questionnaire.

Logical Order of a Questionnaire • Interest the Respondents

• Discover Who They Are • Proceed from General to Specific
• Save Personal Questions Until Last • Allow for
Explanation or Justification • Tell the Respondents What to
Do When Finished with the Questionnaire

The above listed order works well for questionnaires associ

ated with architectural programming. It is not necessarily

the

ideal order for other kinds of questioning situations,

particularly

those where a person might feel uninvolved, as with a public

opinion survey or with the evaluation of colleagues

relative to orga

nizational change. The programming questionnaire can go

directly
H M O : F A C I L IT Y R E Q U IR E M E N T S

Name______________ Position_________Date

This questionnaire is aimed at discovering the specific

furnishing and equipment needs of the staff of HMO

Company. It is important that you respond to all

questions so that your needs can be determined and

the designer be required to provide you with adequate

space. Please take the time necessary to respond to

each question thoughtfully and accurately. Thank you

very much for your help?

Figure 5-72 Introduction to a Questionnaire. If the

demographic questions are

limited in number and were not con

sidered to be overly personal in the

pretest, it works well to put these

questions at the beginning of the

questionnaire. People typically like

to think about themselves, and if the

response categories are obvious and

broad enough, most respondents can

provide reliable answers with little

effort. They are thus off to a good

start with the questionnaire and in

an appropriate mind-set relative to

stating their personal ideas about

the desired information (Fig. 5-73). The first question

could be an

important one on which to separate

the questionnaires to see if there

are significant differences in hous

ous ages of adults. No difference

may appear between some adjoin

ing categories, but differences may

become evident between several

categories, e.g., under fifty and

over fifty. This category might also

be interactive with other categories

such as sex and marital status. Sin

gle women over fifty living alone

are likely to have different housing

women over fifty living with a

spouse, and than married women

under fifty living with a spouse and Fjgure5_73

|ntroduction and Demographics.

children. There may also be differ

ences relating to housing prefer

ences between persons of different ethnic groups owing to

their

cultural backgrounds.

Note that it was not considered important in the above ques

tionnaire to discover if the single person was divorced,

widowed,

Figure 5-74 Simplified Demographics Section. added?

P A R T O N E (Please respond to each question by

underlining the appropriate answer)

1. Number of male adults living in household? One Two Three

Four Over four

2. Number of female adults living in household? One Two

Three Four Over four

3. Ages of Adults? 18-29 30-49 50-69 Over 69 (underline as

many as currently apply)

4. Number of children living in household? One Two Three

Four Over four

5. Age of Children? Under 6 6-12 13-18 (underline as many

as currently apply.)

6. Ethnic background? Caucasian Black Asian Mexican

American Indian Other

7. Affordable monthly rent? Under $200 $200-$300 $300-$400

Over $400

PR O C EED FRO M G E N E R A L TO S P E C IF IC

You cannot assume that a respondent

shares your concerns about a particular

problem, or even that he or she is con

centrating on the questionnaire or think

ing about what it will accomplish. It is far

more likely that he or she will be thinking

about personal affairs. Hence, the ques

tionnaire has to be structured to get the

respondent into the programmer’s mind

set. The introduction and demographic

questions begin this process. But the first

few substantive questions really set the

tone and serve to get the respondent think

ing about architectural issues (Fig. 5-75). The first

question gets right to the

heart of matter. Which type of housing

would be preferred by the respondent?

Here it is important not to offer an option

that could not be made available because

of cost, density requirements, or other Figure 5-75 General

to Specific,

limits. The designer needs to know what

will help him/her make intelligent design decisions within

the

various constraints imposed by site, climate, client,

economics,

etc. Was this a good lead question? Could it have been

asked more

clearly? What first substantive question might you have

asked in

stead of the one shown? More specific questions that follow

might relate to the number

of bedrooms or baths. Although here again the type of

housing, or

more precisely society’s willingness and/or the tenant’s

ability to

pay, may limit the number of bedrooms even for large family

groups: one for the cohabiting adults, one for single

males, one

for single females, regardless of age. A low-income family

will

likely have to share one bathroom regardless of the size of

the

household. In any case, only questions to which the

architect can

actually respond should be asked.

S A V E P E R S O N A L Q U E S T IO N S U N T IL L A S
T

Any question that seems very personal in nature is best

located to

ward the end of a questionnaire. Otherwise, the respondent

is likely

to feel that the questionnaire is being unnecessarily

inquisitive, 1. Which type of housing would meet your needs
best? Rank in order of preference: 1 most preferred to 4
least preferred. a. Single Family detached (one or two
stories) _____ b. Single Family attached (duplex, triplex,
row) _____ c. Multiple Family walkup (up to three stories)
_____ d. Multiple Family elevator (up to ten stories) _____
2. Once into your unit could your family live comfortably
in a two story unit? ye s n o (check one) If you answered
“no” , is someone in your household disabled in some way?
yes n o . Please describe:__________ and may not complete
it or may give inaccurate responses—either of which makes
the overall results of the questionnaire less useful. An
ex ample would be the provision of showers in schools and
other public facilities. In the past, it was assumed that
men were willing to share gang-type showers, while women
required in dividual stalls. It would be useful to
discover if most women today would gladly give up the
privacy provided by shower stalls in order to have a
greater number of toilet stalls. A ques tion that could
get at this issue might be phrased somewhat like that in
Fig. 5-76. How many other ways could this question be
asked? The objective in writing the ques tionnaire is to
get at important design issues in an easily understood
way. The first question may be too short and brusque. Will
the re spondents understand what gang-type means? The
second question may be too long. How could each question
be better phrased? If nearly all of the men respondents
replied

Figure 5-76 Personal Questions. y e s ancj mQst of the

women respondents said yes, what should the designer do?
What about the opinion of the minority? Perhaps they have
an extremely valid reason for saying no. Here is a case
where it would be important to allow for amplification or
justification of the answer, and quite possibly to
encourage the designer to allow for choice. It may be that
a number of both men and women would prefer individual
shower stalls. The same may be true for other situations
relating to issues such as personal territory, privacy,
and safety. A variety of options can be discovered and
provided for in design, if questions are phrased in such a
way that an appropriate variety can be determined. ALLOW
FOR EXPLANATION OR JUSTIFICATION It might be useful to
state at the beginning of the questionnaire that the
respondent should feel free to explain any answer, and to
include a blank line after each question or a final blank
page for this purpose (Fig. 5-77). This way, no one should
feel unduly constrained by the questionnaire. Such
amplification is often use

9. Would you be willing to accept gang-type showers in the

locker room if the number of toilet stalls could be
increased? y e s ; n o .

or more elaborately

9. Limited school budgets normally preclude supplying

toilets or urinals beyond the minimum required by code.
However, if gang-type showers in both the men’s and
women’s locker rooms were acceptable to the users, it
would be possible to provide two additional toilet stalls
in the women’s toilet rooms and two additional urinals in
the men’s toilet rooms. Would this be a desirable
tradeoff as far as you are concerned? y e s ; n o ; not
sure .

ful to the designer. On the other hand, if the

questionnaire is to go to several hundred re

spondents, it may become financially impos

sible to code and tabulate all possible

answers, so such amplification may in fact be

wasted. The person(s) preparing the questionnaire

must assess the time and money available to

analyze the questionnaire. If the time and

money are not available for proper analysis,

do not ask the question(s).

TELL THE R E S P O N D E N TS W H A T TO DO

W H EN F IN IS H E D W ITH THE Q U E S T IO N N A IR E

The respondent must know what to do with

the questionnaire when it is completed. This

can often be stated as part of the introduc

tory section or in a cover letter. However, this

information should also be provided at the

end of the questionnaire after a salutation

such as in Fig. 5-78.

Question Types • Dichotomous • Nominal • Ordinal • Interval

9. Please explain your answer: or if you prefer to be more
specific 9. If you answered “no” to the above question,
please explain your answer. This will be of great help to
the designer. Figure 5-77 Supplemental Questions. Thank you
very much for com pleting this questionnaire! Please fold
the questionnaire in thirds along the dotted lines shown
on the back sheet and insert it in the pre-addressed,
stam ped envelope attached to the questionnaire. Remember,
the questionnaire must be returned no later than Friday,
April 12, 1998, to be useful to the designer. Thanks again
for your help! Figure 5-78 Instructions at Ending. • Short
Answer • Open-Ended There are a number of different types
of questions that may be

used in a questionnaire. They vary from simple checklists to

open-ended free-answer questions (Blalock 1960; Bradburn et

al.

1979). As mentioned before, the simpler the response, the

easier

it is to code and analyze the results. Also, the simpler

and clearer

the question, the less problems there are with reliability;

that is,
the more likely the respondents will provide the same
answers un

der slightly different circumstances of time or place. The

answers must also be valid. Validity in this sense means
answers that are both true and important relative to
design. If you repeatedly ask a group of uninformed or
misinformed people a question, you might get consistent
(reliable) answers, but they would be mis leading, hence
invalid. Similarly, if you ask a question requiring
answers that are more detailed or precise than the
respondents are capable of providing, the results are
likely to be imprecise at best. Some respondents will
leave the question blank, indicating they do not know,
while others will venture a guess, providing an swers that
are neither reliable nor valid. In any case, the effort
should be made to ask questions to arrive at the needed
informa tion in the most reliable and valid way possible.
This generally means that the questions must be phrased
simply and clearly rel ative to the particular respondent
group’s understanding of the problem, and that the
possible answers be equally simple and clear for the
benefit of analysis. This is easy to say, and difficult to
accomplish. D IC H O T O M O U S (T R U E /F A LS E A N D
Y E S /N O Q U E S T IO N S ) These questions usually
involve an assertion that the respondent must determine to
be true or false, or with which they agree or disagree
(Fig. 5-79). Such answers can be coded onto computer answer
sheets and analysis would involve only counting the number
of positive and negative answers. If the demographics
allow separating the an swers into respondent groups, it
may be possible to determine if opinions vary for
different groups. For example, women faculty, staff, and
students may have different atti tudes in this regard.
Perhaps only the fac ulty/staff toilets require additional
stalls. Male respondents would have no basis on which to
respond to the above questions, nor would they be
affected, so they should not be asked to respond. It might
be better to rephrase the question to omit “women’s” so
that both men and women could respond relative to their
own experiences, and then to separate out the answers for
analysis based on

Figure 5-79 True/False and Yes/No Questions. sex, so as to

be able to determine if the need

5. There are an insufficient number of toilets in the

women’s rest rooms in the College of Architecture. True
False___
or

5. It would be desirable to increase the number of toilets

in the women’s rest rooms in the College of Architecture.

Yes N o___

for more stalls is general, or ap

plies only to one or the other of

the sex groups (Fig. 5-80).

N O M IN A L (S IN G L E W O R D ,

C H E C K L IS T S , M U L T IP L E

C H O IC E )

This type of question is often a

variation of the dichotomous

question, which requires only

a check for affirmative (or negative) answers. It is

particularly ef

fective when there are long lists of similar questions. The

most

common lists in programming typically deal with furnishings

and

equipment. Another such list might relate to activities of

the re

spondent. These are easy to code directly onto computer

coding sheets for

analysis, which can be as simple as computing the total

number of

checks for each answer for a particular respondent

subgroup. The

answers in the final column below would, of course, have to

be

hand tabulated and considered on the merits of the

justifications

offered. Here, it might be important to know the names or

titles of

the specific respondents to determine if there is actually

a smaller

subgroup than the demographic data indicates. In any case,

the to

tal number of checks allowed should be reasonable and based

on information gained in the

previous literature review, di

agnostic interviewing, and di

agnostic observation activities

(Fig. 5-81).

The multiple choice ques

tion is a variation where there

are more choices than yes/no,

but usually only one answer is

permitted, as the following

question indicates (Fig. 5-82).

This question would, of

course, only be applicable for

a person who had previously

indicated a need for a secretar

ial desk. Figure 5-81 Nominal Questions (Checklist). 6.

Please place a check in the appropriate column for
furnishings needed in your office. indicate if more than 4
item & number 0 1 2 3 4 More a. executive desk _ _ _ __ _
__ b. secretarial desk _ _ _ __ _ __ c. executive chair _ _
_ _ _ __ d. secretarial chair _ __ _ _ _ __ e. side chair _
_ _ _ _ __ f. conference table _ __ _ _ _ __ g. conference
chair __ _ _ _ _ __ h. 4 drawer filing cabinet __ _ __ __
__ i. 2 drawer filing cabinet _ _ __ __ __ 5. There are
an insufficient number of toilet stalls in restrooms in
the College of Architecture. True False___ or 5. It would
be desirable to increase the number of toilet stalls in
restrooms in the College of Architecture. Yes N o___ Figure
5-80 Reworded Dichotomous Questions.

7. Your preference for a secretarial desk is which of the

following? (check one) a. left side typing surface ____ b.
right side typing surface ____ c. typing surface on both
sides ____ d. other (explain) ____

Figure 5-82 Multiple Choice Questions.

10. Please rank the following in terms of their importance

to you. (1 as most important to 7 as least important) a.
Functional Relationships _ b. Response to Climate _ c.
Relationship to Existing Building _ d. Structural
Expression _ e. Initial Cost _ f. Operating Costs _ g.
Aesthetic Image _

Figure 5-83 Rank Ordering Questions.

Please rate the following questions from: 1. (extremely

important), 2. (moderately important), to 3. (relatively

unimportant).

8. How important to you is each of the following relative

to the addition to the College of Architecture? (Check the
appropriate blank) 1 2 3 a. Functional Relationships __ __
__ b. Response to Climate___________ __ __ __ c.
Relationship to Existing Building __ __ __ d. Structural
Expression __ __ __ e. Initial Cost __ __ __ f.
Operating Costs __ __ __ g. Aesthetic Image __ __ __ h.
Safety/Security________________ __ __ __

allow easier sta-tistical analysis. It is possi

ble to calculate totals, means, and distribu

tions for the several possible answers to

each question. It is also possible to establish

the rank order for a question for the whole

group. In the above case, the highest rank

would be given to the category with the low

est total score, and the lowest rank being

given to the category with the highest total

score. It is also possible that some categories

may rank the same, or nearly the same (Fig.

5-85).

S H O R T A N S W E R 100 90 80 70 60 50 40 30 20 10 0 __
Figure 5-85 Histogram Showing Rank Ordering.

These questions are necessary when more specific

information is

needed than could reasonably be provided using a finite

number

of categories. Questions asking for a person’s name,

address, and

telephone or identification number are examples of short

answer

questions for which simple categorization is rarely

appropriate.

These are all demographic questions and are nominal in

nature.

Questions asking a respondent what he or she thinks are

impor

tant design issues, or for suggestions as to how to solve a

prob

lem, may also prove difficult to cover with a limited set of

alternatives. It may not be appropriate to assume that you

have

thought of all of the alternative ideas. A short answer may

be re

quired (Fig. 5 -86). The problem with the short answer is

coding. Each answer
must be content analyzed and coded by a person, which takes

time and money. If the possible answers are seemingly

endless or

approaching infinity, then coding simply breaks down to the

most

frequently mentioned categories and the rest are grouped

under

an “other” category. This may be useful for an exploratory

ques

tionnaire when interviewing to accomplish

the same purpose would be difficult or im

possible. However, the diagnostic interview 14.

is better suited to finding answers to such

questions. If some doubt exists about whether

the persons interviewed are representative of

the group, additional interviews can be con

ducted until sufficient understanding of the

categories of response can be established. What are the

three most important issues for the design of a new
architecture building? a. _____________________________ b.
_____________________________ c.
_____________________________ Figure 5-86 Short Answer
Questions. g. a. b. f. c. d. e. h. The most common short
answer question that should be used in a questionnaire is
the request for amplification, clarification, or in
sertion of nominal information for “other” categories.
Here again, the value of this in formation is
questionable, unless there is sufficient time and budget
for the survey team to analyze the results. When this is
possible, a number of in sights can be gained that would
otherwise have been missed (Fig. 5-87). O P E N -E N D E D
Use of open-ended questions in a questionnaire can be
problem atic. It is difficult to count or summarize the
variety of answers likely to be obtained from a large
number of individuals, but it is possible to read through
the responses to gain a feeling for the sentiment of the
group. However, this approach to analysis is fraught with
uncertainty about how much the reader brings from past
experience to the conclusions reached. It is, of course,
possi ble to do a complete content analysis in which
certain groups of answers are identified and their
instances counted, but this is a very time consuming
activity. In either case, the wisdom of using open-ended
questions in a questionnaire is doubtful, because the same
information could more easily be obtained through diagnos
tic interviewing. Sampling As with the methods of
information gathering discussed earlier, sampling is
extremely important when using questionnaires (Blalock
1960; Ackoff 1962). If the wrong persons are asked to
respond, the answers may be useless. It is, therefore,
important to develop a careful sampling plan. So who
should be included? The people who are likely to know the
answers! Depending on the role they fill in an
organization, the people questioned may have very
different, but possibly equally valid, answers. It is
important to identify all of the different categories of
people likely to be affected by the design solution and to
survey a sample from each of these groups. For example, a
questionnaire relating to the expansion of an
architectural building may need to be responded to by each
of the following groups: student majors, other students,
faculty, staff, administrators, and maintenance personnel.
Probably, how

Please explain

Figure 5-87 Short Answer Clarification.

ever, only the student group would be so large as to

require that

a questionnaire be used. A representative sample or even

the en

tire group of persons in other categories could be

interviewed. In the case of the students, it might make
sense to survey a

sample from each class level (freshmen through senior under

graduate, first- and second-year graduate, non-majors using

the

building, etc.). If there are 50 or more students at each

year level,
perhaps only ten need to be surveyed to obtain a reasonably
ac

curate understanding of student attitudes, needs, and

ideas. This

is a type of stratified sampling procedure. Selections

within each

group might involve further stratification (e.g., by age,

sex, eth

nicity, place of residence) or perhaps by random selection.

If a

need exists to project from the small sample to the

population

(group) the sample represents, it is probably advisable to

utilize a

random sampling procedure, so the probability of the sample

be

ing unlike the overall group can be estimated. This can be

done

rather easily by identifying every member of the group,

assigning

a unique number to each, then utilizing a table of random

num

bers to select the persons to be given the questionnaire.

This ap

proach becomes more important as the population of the

group to

be surveyed increases (Fig. 5-88). Note that a somewhat

different questionnaire may be necessary

for some of the groups surveyed. For instance, if you wish

to survey

users who are not employees, but perhaps frequent or

occasional

visitors or customers, they will not be able to provide the

same
depth or detail of information as a staff member. It is
also possible

to utilize a single survey

instrument with direc

tions to respondents to

skip over certain portions

of the questionnaire, de

pending upon earlier an

swers. Typically, sampling for

programming question

naires involves stratifica

tion of the entire

population of users or po

tential users of the facil

ity to be designed. Thus,

the sam p le is referred to Figure 5-88 Persons to

Survey in Architecture. Dean Associate Dean Administrative
Associate Business Manager Development Officer
Administrative Assistant Receptionist Shop Superintendent
Librarian Archivist Head Custodian Provost Advisory Council
Pres. AIA President Campus Planning Dir. Facilities
Director Facilities Management Director of Architecture
Graduate Program Director Administrative Assistant
Architecture Faculty First year students Second year
students Third year students Fourth year students Fifth
year students First year grad students Second year grad
students Third year grad students Graduate Assistants
Library Visitors Lecture Visitors Gallery Visitors
Director of Planning Administrative Assistant Planning
Faculty First year grad students Second year grad
students Third year grad students Graduate Assistants
Director of Landscape Arch. Administrative Assistant
Landscape Faculty First year grad students Second year
grad students Third year grad students Graduate
Assistants as a stratified sample. The stratification is
usually done with re spect to the role the persons play in
the facility so that all legiti mate needs are accounted
for in the survey. Within each strata, the sample should
be random to ensure that various types of in dividuals
have an equal chance of being represented: young, old,
male, female, minorities, and so on. If it is possible to
identify each member of the population and to assign them
numbers, then a simple random sample can be made using a
table of random numbers. If a random sample is taken for
each subgroup, the sam pling procedure is referred to as a
stratified random sample. If the strata involves only a
few persons, such as the maintenance staff, it may be
possible to question the whole population so that there
will be no need to worry about representation within the
strata. Finally, since the opinions held by some members
of an organiza tion may be considered more important than
those held by other members, for instance, management
versus staff, there is often an agreed or imposed
weighting of some strata. In this case, the sam pling
design might be referred to as a weighted stratified random
sample. If it is not possible to identify each of the
members of a strata, such as expected visitors to the
facility, it might be necessary to use a systematic random
selection procedure, that is, choosing the first
respondent using random selection, then selecting every
tenth (or another number) person to respond to the
questions. The sample would then be referred to as a
systematic stratified ran dom sample. This turns out to be
a relatively complicated proce dure, and there are entire
books on the topic (Rosenbaum 1979). If the organization
is large and/or complex, it would be highly de sirable to
work with professionals in developing the survey. How
ever, if the organization is simple or small, common sense
can go a long way toward developing an adequate plan. Here
again, our earlier discussions of cost of error should not
be forgotten. Bias • Sampling • Questioner • Respondent •
Situation Technique A key problem of survey research is
bias. This problem has been

considered at great length by social scientists involved in

survey

research (Blalock 1960). A brief summary here will help the

reader

understand several of the areas where problems of bias can

de

velop. Persons concerned with the impact of such problems

are ad
vised to consult with people who have spent their lives
developing

the skills necessary to conduct research that avoids these

biases.

S A M P L IN G

If the sample leaves out certain population subgroups or

clearly

admits a disproportionate number of another group, the

results

are likely to be biased toward the interests of the

represented

groups. As already mentioned, however, programming research

is

typically biased toward the interests of the management

group,

since they pay the bill. Other people are surveyed to be

certain

that their legitimate needs are satisfied.

Q U E S T IO N E R

This is the most common bias in programming research. It in

volves such things as leading questions. These are

questions that

look for a certain answer: “Don’t you agree that more

toilet stalls

are needed in the women’s toilet room?” “Most educated

people

now desire a bidet in addition to the normal toilet stool.

What is

your preference?” If a question looks as if it is leading

toward a

certain answer, it probably is not a good one. Another

problem is
vague or confusing questions: “What do you do each day?”
This

question is simply too broad. Classic examples of confusing

and leading questions are found

in the political literature. For example, a recent survey

by a polit

ical action committee asked respondents to rate issues of

impor

tance. One issue was to “Eliminate obsolete [my italics]

federally

funded programs.” It would be unusual for any reasonably

intel

ligent person to answer that we should keep “obsolete”

programs.

Another question asked: “Do you believe everything [my

italics]

you hear or see from the media?” It is hard to imagine many

per

sons saying “yes” or “not decided” to this one. The same

ques

tionnaire asked: “Are you committed to fighting the liberal

bias in

the news media?” (Quayle 1996). No matter how you answer

this

question, you can be counted as agreeing that there

actually is a

“liberal bias” in the news media. Perhaps. The language in

a questionnaire must be absolutely clear to the
respondent, because there is no opportunity to probe or ask
for clarification. The respondent reacts only to what he
or she under stands the question to ask. R E S P O N D E N
T This can be a problem in both interviews and
questionnaires. In this case, the respondent tries to say
what he or she thinks the questioner, or perhaps
management, wants to hear. This is partic ularly true when
the respondent’s answers can be identified as belonging to
the respondent. If this is a problem, it is sometimes
necessary to have the questionnaire returned in an unmarked
en velope. But even with this precaution, a person in a
unique role may easily be identified by their concerns.
Rarely, however, is a question asked in architectural
programming that might cause major problems between
supervisors and subordinates. S IT U A T IO N This can also
be a major source of error in surveys. If the re spondent
is asked to complete a questionnaire when busy, you can be
sure that not much thought will be given to the endeavor,
even if the questionnaire is completed. Or if a work
environment questionnaire is administered away from a
person’s workstation, it is likely to result in guesses
based on poor recollection or visualization. Both the time
and place to administer a question naire should be
carefully chosen. T E C H N IQ U E The way of asking
questions can also introduce bias. As already mentioned,
it is difficult to discover a person’s unique values,
goals, and ideas with any “objective” question in which all
of the possible answers have already been identified.
Multiple choice or checklist questions confine a person’s
answers to those available. The Survey Ultimately, the time
comes to administer the questionnaire—to conduct the
survey. Will it be affordable to have a person admin ister
each of the questionnaires? Will it be possible to send or
de liver the questionnaires to each of the respondents to
complete

and return? If the required sample is large, it may be very

expen

sive to have someone visit every respondent. Indeed, if

this much

time can be made available, perhaps a series of diagnostic

inter

views would be a more appropriate use of available time!

Sometimes arrangements can be made to have all respondents

come to a central place, as with an examination, where

general in

structions can be given to everyone and questioners can be

avail

able to answer specific questions as they occur. This can be

efficient, ensure a reasonably good understanding of the

questions,
and enable the programmer to get the questionnaires back
very

quickly. It does not, however, allow the respondents to

refer to

their own environments to obtain the requested information.

Like

a closed book exam, it requires that the person recall all

of the in

formation requested. Most people are not very good at

recalling

environmental information, so chances are

that answers will be neither reliable nor valid. The most

common procedure, where a

building programming activity is concerned,

is to prepare a cover letter with the signature

of the client, to be sent either to department

heads for distribution, or directly to a prese

lected sample of administrators and employ

ees as appropriate. The letter should briefly

state the purpose of the questionnaire, by

what date it must be completed, and how

and where it must be returned. It is also im

portant to stress the questionnaire’s impor

tance in obtaining a satisfactory building for

the respondent’s particular needs, so respon

dents will have a personal interest in com

pleting the questionnaire (Fig. 5-89). Once returned, the

questionnaires can be
collated as appropriate and then the job of

coding the data onto appropriate data forms

can begin. Whenever possible, this should be

done on computer answer sheets, so that the

entire analysis can be done by computer.

When this is not possible, a carefully pre

planned sheet for manual tabulation can be

used to tabulate and summarize the results.

Once summarized, the format should be Figure 5-89 Cover

Letter. INDUSTRIAL GROUP OF AMERICA 11 EAST EDGE STREET,
CAMBRIDGE, MA 10238 May 17, 1997 Roger Grand, Director of
Development Dear Roger: The enclosed survey from the
architect of the new plant needs to be completed and
returned to the Personnel Office no later than May 24,
1997. It is crucial that you take the necessary time,
consulting appropriate staff, to complete and return the
questionnaire on schedule. We value your continuing
service to the company very much and hope that you are as
excited as we are about the opportunity to greatly improve
our working environment. Sincerely, Charlotte Mead,
President such that the results are readily apparent; that
is, they should make sense to the designer. Otherwise, the
entire survey effort will have been a waste of everyone’s
time. Data Analysis If the questions have been carefully
written to allow ease of coding and an appropriate
sampling plan has been developed and fol lowed, analyzing
the results is a relatively straightforward prob lem.
Clerical staff can be in structed how to code the limited
number of short answer responses. The programmer or
designer can be given the longer open-ended answers to
try to obtain an overall view of the respondents’ answers.
The balance of the answers can be transferred to computer
coding sheets and the data fed to the computer to develop
specific information such as totals, av erages (means),
distributions, and other statistics. For most programming
com missions, simple descriptive statistics such as those
men tioned above are appropriate. If the number of
persons ques tioned is a substantial propor tion of the
total, there is very good reason to believe that they
will be representative, es pecially if they were chosen
randomly. Simply illustrating the results by tabulations
or vi sually with tables, pie charts,
Figure 5-90 Questionnaire Results. or histograms will be
enough to

Credit: Jeffrey Burns, Malcolm Calvin, Mitch Dodge, and

Paul Johnson, 1996. U o f A designer know what is

Liquors Building Program. College of Architecture, The

University of Arizona needed (Fig. 5 -90). Liquor Store
Customer Questionnaire W h a t beat d e s c r ib e s y o u
r liq u o r s to re ? I: close to home 2: near other
businesses 3: on the way 4: visible from a busy street 5:
secluded 6: price selection 8: “easy carding" 9: none of
the above W h a t a ttra c ts y o u m o s t to a liq u o
r s to re ? I: business sign/name window advertisements
clean store front well lighted name of store size of
parking lot employees availability W h a t d a tra c ts
y o u fro m a liq u o r s to re ? □ SeriesS ■ Series? □
Serie$6 ■ S eres 5 □ Series4 □ Senes3 ■ Series2 ■
Series 1 I: busy parking lot 2: window advertisements 3:
dirty store front 4: drive through 5. name of store 6:
size of parking lot 7: employees 8: none o f the above □
1 ■ 2 03 04 ■ 5 06 ■ 7 08 ■ 9 Q Series 1 ■ S e re *2
a Seres 3 O Seres4 ■ S ere» 5 G S eres 6 ■ Series7 □
SeriesS S 4

I :: 0 -4 0 2 4 6 8 10 12 Questions 13% 2 6% 7 8 9 4% 0%
4% Analysis If, on the other hand, the population from
which the samples

were taken is very large in comparison to the samples, it

may be

necessary to test the significance of the results using some

combination of descriptive and inferential statistics. A

very com

mon social science technique is to develop means and

variances

for various distributions of data and to use t-tests,

analysis of

variance, or some other appropriate parametric or

nonparametric

test of significance. If it comes to this, both social

scientists and
statisticians should be involved in the development of the
ques

tionnaire, sampling plan, and statistical analysis. The

discussion

of these research procedures is beyond the scope or intent

of this

text. Those interested in pursuing these approaches should

refer

to such books as Methods in Environmental and Behavioral Re

search (Bechtel et al. 1987).

Cost of Error

It should be added that cost of error is a factor to be

weighed in

the development and analysis of any information gathering

activ

ity (Ackoff 1962). If the information was not gathered at

all,

would there be a cost if the designer was allowed to design

and

construct an inappropriate building? Very likely there

would be

large costs. The various rooms within the building might be

of the

wrong size or shape, so the intended activities could not

take

place within the rooms. The cost of error may involve lost
effi

ciency of production, and thus an overpriced product. Or it

might

involve the cost of a complete remodeling of the building

to make

it usable. The building might project an inappropriate

image to
the community, so that the intended users will not enter.
The

building may let in maximum sun in the hot summer months and

minimum sun in the cold winter months, so the utility costs

would be very high. The building might greatly exceed the

client’s

budget, causing bankruptcy for the client, who might sue

the ar

chitect for damages. Clearly, in the case of no information

gathering, the costs of er

ror can be high. What about the case of minimum information

gathering—the case where the client provides a brief and

the ar

chitect begins to design? In this case, the cost of error

depends on

how good the client is as a programmer. In many cases, the

client

will not be very good. Client programs are often reactions

to in

adequate present facilities. In an effort to oil squeaky

parts, the

client may forget what kind of business he or she is really

in volved in. Clients often have a very poor sense of
size, so they tend to over- or underestimate the sizes of
needed spaces. The client may tend to be overly
conservative or even redundant in what is wanted. Most
laypersons have not been educated on the environmental
possibilities for flexibility, adaptability, incremental
growth, or other areas where an architect has knowledge.
The costs of error can be quite high if laypersons are
left to do their own program ming. They may give up on
program needs, thinking they cannot get everything they
want, when in fact they could with careful programming for
multiple use, growth, and so on. They may also get a
facility that is appropriate for the past when their
organiza tion is moving toward the future. The costs in
such cases are of ten substantial, but difficult to
measure precisely. So what about a program prepared by an
architectural firm in consultation only with the
owner/client? Here again it depends on the programming
qualifications of the architectural firm and how well the
owner/client represents the users. If the architec tural
firm has done similar buildings before, it may be able to
de sign a satisfactory building with very low costs of
error. However, if the client/user is unlike those of
previous commissions by the architect, then some
preconceptions will be inappropriate and the resulting
architecture is likely to impose costs on the client that
could have been avoided. But what if the architectural
programmer has done a careful lit erature review,
conducted extensive diagnostic interviews, and ob served
both the organization and the new site carefully, but has
not administered and analyzed a carefully planned
questionnaire ac cording to a scientific sampling plan?
What will be the cost of error? This depends on the
specific problem. It is, however, the author’s experience
that many master planning and schematic design pro grams
can be developed quite adequately without administering a
questionnaire of any kind. Literature search and review,
interviews, observation, and client/user work sessions
(see Chapter 6) provide sufficient information to convey
an understanding to the designer that allows development
of a building design meeting the needs of clients and
users alike. Very few errors result, and those that do oc
cur are easily remedied through minor furniture
rearrangement or organizational change. Hence, the cost of
error is usually minimized. However, with very new, large,
or complex institutions where change is a constant or is
highly unpredictable, or for facilities

for user groups for whom the architect or perhaps even the

client has had little previous experience, the development

and

administration of a carefully constructed questionnaire may

pre

vent misconceptions developed in the initial interviewing

ses

sions from going forward into the program. If important

issues

that have the potential to affect design cannot be fully

explored
within the framework of interviews and observation, then
broad

distribution of a question

naire will save money in

the long run. Similarly, when a great

deal of factual informa

tion from a large number

of subgroups is needed to

establish the minimum or

even optimal size of a

great number of repetitive

spaces, obtaining this in

formation in a detailed

manner may allow incre

mental savings in terms

of convenience, stress, or

building or furniture costs,

which will be very sub

stantial when totaled.

Here, the time and cost

associated with developing

and administering a ques

tionnaire may be war

ranted. Each situation will

dictate what needs to be

done. The programmer

must be alert to discover

what is appropriate. For ex

ample, organizations such

as the Disciples of Christ

often develop self-report

questionnaires, allowing

individual congregations to figure 5-91 Disciples of

Christ: Questionnaire.

accurately determine their Credjt. Board of Church

Extension of Discip|es of Christ 1990 Strategic Planning &
Building Plan-

facility needs (Fig. 5-91). ning for N e w Congregations.

Permission: Board of Church Extension of Disciples of
Christ 7. Educational Space Requirem ents The projection o
f future numbers o f classes should take into consideration
not only the grow th expected in church school attendance,
but the changing or advancing age o f present and future
class m em bers. Particular attention should be given to
the need for adult classes for entirely new groups o f
young adults which will be expected to co m e into a grow
ing church. New co n grega tions will need to con sider
starting at least one new adult class every year for the
first five years. NEEDED NOW (First Unit) FUTURE/MASTER
PLAN A ge Sq. Ft. Per Pupil A vg. Attend. ♦Space Needed F o
r A vg. Attend. + 2 0 % ♦Space P ro vided A vg. Attend.
Space Needed R ecom m . Students P er R oom ♦♦Infants 3
Ft. Betw'n Cribs 4 -1 0 ♦♦Toddlers 1 2 5 -3 5 4 -1 0 ♦♦N
ursery I 2 25 -3 5 6 -1 0 ♦♦N ursery II 3 2 5 -3 5 8 -1 2
♦♦K ind'grn 4 2 5 -3 5 10 -1 2 ♦♦K ind'grn 5 2 5 -3 5 1 0
-2 0 Grade 1 6 2 0 -3 0 G rade 2 7 2 0 -3 0 G rade 3 8 2 0
-3 0 G rade 4 9 2 0 -3 0 12-2 5 G rade 5 10 2 0 -3 0 G rade
6 11 2 0 -3 0 G rade 7 12 15-25 G rade 8 13 15-25 G rade 9
14 15-2 5 Grade 10 15 15-25 12-2 5 G rade 11 16 15-25 Grade
12 17 15-2 Post High 12 -2 0 Adults I 1 2 -2 0 Adults II '
1 2 -2 0 Adults 111 1 2 -2 0 12-2 5 Adults IV 1 2 -2 0
Adults V 12-20 ♦Space listed does not include restroom s,
storage, stairw ays, hallways, e tc., 2 5% -30% should be
added to total educational space for these areas. The
minimum recommended room size is 3 0 0 square feet. **In
many instances there will be more children in preschool and
nursery rooms during worship than during church school.
Include the number which is the largest attendance if it is
during the worship hour. 2 7 5.5 Site and Climate Analysis
• Site Considerations • Site and Climate Analysis Site and
climate analysis is a part of architectural program ming
that is conducted parallel to the several information
gather ing activities covered in this chapter. It is not
an information gathering method like the others. Rather,
it is a specific applica tion of literature search and
diagnostic observation. It is included in this chapter on
information gathering because of the particular nature of
the application and because it often precedes the devel
opment of the programming matrix covered in the next
chapter. The analysis of site and climate during
architectural program ming is dependent on several
conditions, the foremost being that a site has been
identified and is accessible for analysis. If a single
site has been identified or is already owned by the client,
then conducting a complete site and climate analysis is
essential to the preparation of an architectural program.
If several sites have been identified but none actually
selected or purchased, then the analy sis of each site
might initially be limited to the information neces sary
to make the selection. Indeed, the architectural
programming process may be held aside while a more limited
site suitability study is conducted. Although the
principal human issues, specific user needs, and the space
program for a facility can be studied in the absence of a
specific site, a comprehensive architectural program
covering en vironmental, cultural, technological,
temporal, economic, safety, and aesthetic issues is
usually dependent on the identification of a specific
site. The topography, geology, hydrology, size, exposure,
configuration, views, and vegetation of a site are all
likely to have a significant impact on what will be
designed, so these areas of in formation need to be
developed. The macro- and microclimatic conditions will
have an impact on what functions can occur out doors and
may impact the orientation and configuration of the fa
cilities to be designed. Code and ordinance requirements
and deed restrictions relating to the specific site will
have an impact on de sign, as will the existing community
fabric. Locally available ma terials, construction
techniques, and market conditions are also likely to
affect what can be designed. Even the desired image of a
facility is likely to change from an urban to a suburban to
a rural

site. If the site is on a hill, next to water, between two

existing
buildings, or with major day or nighttime views, these
conditions

will strongly affect how a building should be designed.

Time is

sues are also difficult to address when a site has not been
selected.

Site Considerations • Regional Conditions • Local

Conditions • Site Conditions The analysis of a site for
programming purposes should be both

systematic and comprehensive. It can include more

subjective site

evaluations dealing with the various “moods” or “qualities”

of the

site as experienced by the programming group. If included,

this

would not relieve the building designer of the normal

responsibility

to confirm the program and, hence, to review the factual

site infor

mation and to visit the site to determine if the more

subjective in

formation corresponds to his/her own evaluations. As with

the rest

of the information contained in an architectural program,

the site

and climate data serve only as a beginning point for the

designer.

R E G IO N A L C O N D IT IO N S

Every site is located within a larger regional context. It

may be on

the south slope of a major watershed subject to periodic

flooding

or subterranean water flow. The same topography may result

in
nocturnal weather cycles or periodic weather anomalies. For
in

stance, a location at the midpoint of a southern slope may

create

a generally warmer nighttime condition than a location

either in

the lowest drainage areas or at the top of the sloped area.

The site

may be located near a major geologic fault and be subject

to earth

quakes. If the site is on a broad alluvial fan in a river

basin, the

river could change course during a period of major flooding

and

destroy any improvements. If the site is downwind from a

major

source of air pollution or in the flight pattern of a

military or com

mercial airport, there may be problems with air or noise

pollu

tion, and even the possibility of a disaster threatening

the lives of

the building occupants. Any information of this type

relating to

the region in which the site is located should be developed

and in

cluded in the programming document, because it could have a

major effect on what is designed (McHarg 1969). L O C A L

C O N D IT IO N S The context of the site is also
important. What currently exists near the boundaries of
the site? Are there existing buildings, streets, rivers,
forests, or other important features? What are the likely
future uses? What is the current zoning on all sides of the
property? Does the municipality have a history of making
zoning changes or granting use variances? Or does it have
a history of not deviating from earlier zoning and other
regulatory decisions? Is there an orderly process
available whereby arguments for change can be heard and a
rational decision made? Is the site in a desig nated
zoning district or at its fringes, where change is more
likely? Are the surrounding buildings of a consistent
character and quality to which the proposed fa cility
should conform, contrast, or respond in some fashion?
What ex isting city services or utilities are available
at the site: water, sewer, electrical, gas, tele phone,
trash pickup? Are the services all be neath grade or are
some at grade or above grade? What kind of traffic
passes by the site? Is the major access road divided so
that a median break would be required to gain access to
the site? Are there streetlights and pedes trian
crossings at exist ing corners? Any or all

Figure 5-92 Pedestrian Path System. o f th e s e m a y h

a v e an

Credit: City West, 1987. Downtown Pedestrian Core Path. The

Phoenix Public Arts M aster Plan: Prelim- 'mP^ Ct on design
(Fig.

inary Observation. Permission: Bill Morrish 5-92). 0 C I T

Y W E S T 1987 'Jjti ~-5% & r**>JEC 77D A > f i t ^ /T fa
t t r z fl ^ iy frrZ M IB jt; 11 43_£z/~ 'HJk n&vrjAz i n
frz & C ' fawm/dfL I /tyovftMr M? ^ I /W

W A W to fM r? - - • neft&u Mt?

S IT E C O N D IT IO N S

The conditions of the site itself are of great importance

to the de

signer. The site’s shape and dimensions, primary

orientation and

views, topography and geology, microclimate, flora and

fauna,

natural and built features, and other peculiarities are all

needed

to begin and complete the design. These, like the broader

local

and regional conditions, must be discovered and set forth

in the
architectural programming document so that the programmer
can

understand the context to which the facility requirements

must

relate.

Site and Climate Analysis • Literature Search • Site

Surveys • Photographic Documentation • Other Procedures The
methods and techniques of site and climate analysis dur

ing programming vary depending upon the nature of the

particu

lar problem. Literature search, interviewing, observation,

and

photographic documentation are all used to collect

information

about the site and climate. Engineered site surveys,

hydrological

surveys, and even archeological studies are often required.

De

tailed coverage of site analysis procedures are included in

a num

ber of books specifically addressing site analysis and

planning

(Lynch 1971; Rubenstein 1987). The student of architectural

programming is encouraged to obtain such books and to learn

the

approaches covered. Only a cursory examination of the

various

methods, techniques, and tools of site and climate analysis

will be

provided in the following paragraphs.

L IT E R A T U R E S E A R C H

Much of the important data on regional and local conditions

can

be obtained from existing public documents available in

public li

braries, private bookstores, and the archives of

governmental or

quasi-governmental agencies. Access to these information

sources

varies from place to place but generally is not difficult

to achieve,

because everyone who develops projects in a particular

region or

locality has need for this type of information. U.S.G.S.

topo

graphic maps are readily available in map stores, outdoor

sporting

Figure 5-93 Site Utility Information.

Credit: Fourth Year Design Studio, Professor Poster, 1990.

Salvation

A rm y Hom eless Facility: Program and Site Analysis.

College of Ar

chitecture, The University of Arizona

Figure 5-94 Air Current Diagram.

Credit: Bradley Graham, 1978. Main Library for Flagstaff.

Permission:

School of Architecture, Arizona State University goods

stores, and often in blueprint shops. Watershed
information is often available in local libraries, Army
Corps of Engineers of fices, and within city and county
engineering offices. Climate data can be obtained from
most local or university libraries as well as from the
National Weather Service offices, often located in or near
municipal airport fa cilities. With the advent of a number
of com puter programs dealing with energy efficient
design, data banks on weather are available in association
with energy analysis programs used by architectural and
engineering firms. Maps of existing utilities (water,
sewer, gas, power) and public streets, sidewalks, and
curbs are often available in the engineering or public
works divisions of local municipal ities. Existing
ownerships and legal descrip tions of property, including
easements and deed restrictions, can be found in the
offices of the county recorder or in large real estate
and title insurance offices. In short, there is often a
large body of site and climate infor mation available in
local libraries, archives, and other repositories of
information (Figs. 5-93 and 5-94). SITE S U R V E Y S
The type of topographic and geologic infor mation
contained in public documents such as those described
above are often enough to meet the needs of architectural
program ming, particularly for master planning a site.
However, before proceeding with schematic design, it is
wise to develop more specific site information. An
architectural site sur vey including setting of corner
stakes, locat ing all site features (major outcroppings,
trees, existing structures), and public utili ties (water,
sewer, gas, electricity, telephone, cable, etc.), and
establishing site contours WINDBREAKS HKDUCE WIND CURRENTS.
PART OF TUB AlB CURHBHT IS DIVESTED OVEB THE TOP OF THE
TRESS AND PART OF IT FILTERS THROUGH THE TREES. THE SIZE,
DENSITY, AID SHAPES DETERMINE THE AMOUNT AND QUALITY OF
CONTROL. A BUIE OF THE THUMB TO FOLLOW IN A ROUGH ESTIMATE
IS THAT EVERY 10 FT. UP YOU GAIN A 100 FT. OWT.

Kjry. -ft----- S r t tL &AS MAIN — S * “* “* HAfN

«/PUne.T»».K im * 4-rUB — O -—— 1-lAMMOCt «-i n t rc * .
A -------, [««««! in v c o t cu e vat roM m f c*.t w
............. riA<sn«.-ujsiED piPt

with suitable vertical intervals is

generally a requirement for de

sign. Similarly, it is important to

determine the soil conditions,

including bearing strength and

expansiveness of the soil, be

fore making design decisions.

Although required by the de

signer, the site survey and soil

analysis often are not a direct

part of the architectural pro

gram (Fig. 5-95).

P H O T O G R A P H IC

D O C U M E N T A T IO N

It is also possible to obtain pri

mary information, such as aerial

photographs, of many sites in

municipalities where aerial pho

tography companies operate.

These images are made at vari

ous engineering scales and

show the precise location of ma

jor geographic, geologic, build

ing, and landscape features.

They often are oriented so as to

contain information about topo

graphical conditions, and may

even include contour lines su

perimposed on the photograph.

These are of great value to the

designer and may be included

as folios in an appendix to the

program document. Direct photography of the

site and its immediate context

by the programming group is

also of great value to the de

signer when included in the pro

gram or its appendix (Figs. 5-96

and 5-97). Figure 5-95 Pilgrim Plaza Office: Site Survey.

Credit: Robert Hershberger and Ernest Nickels , Par 3
Studio, 1974. Pilgrim Plaza Office Building Site Survey
Figure 5-96 Aerial Photo: Downtown Tempe. Photo credit:
Landiscor W E ST SOUTH eAST NOEETH Figure 5-97 Composite
NSEW Views. Credit: Bradley Graham, 1977. Main Library for
Flagstaff. Permission: School of Architecture, Arizona
State University

OTHER PROCEDURES

Walking and observing the site and sur

roundings; making comparisons with other

known sites; holding discussions with local

residents about microclimates (weather,

prevailing breezes, etc.), air quality, noise

pollution, flooding, and other potential

problems; sketching base maps; and noting

significant features and views are other

ways of evaluating a site (Figs. 5 -9 8 and

5-99 ). Detailed discussion and representa

tion of these procedures are included in

various books on site analysis. The student

who has not had the opportunity to take a

course on site analysis should review one

or more of these books (Lynch 1 9 7 1 ;

White 1 9 8 3 ; Rubenstein 1987) .

5 .6 Exercises

3. Discover the basic ways that park ing structures work.

Consider a va cant site nearby. What system would work
best?

4. Find where all of the utilities are lo cated servicing

a specific site near your home: water, gas, power, tele
phone, cable.

5. What are the basic exiting require ments for an

auditorium in a type 3 building according to the Uniform
Building Code (UBC)? Figure 5-98 Site Analysis Sketch.
Credit: Line and Space, 1990. Building Program for a New
Elementary School, Sonoita Elementary School District #35.
Permission: Line and Space. Views and Noise Figure 5-99
Site Analysis Sketch. Credit: Arquitectura Ltd, 1988.
Pre-Design Workbook, Verde M ead o w s Recreation Center.
Tucson, Arizona. Permission: Arquitectura Ltd. Winter Winds
Mi| Summer^ -W inds -i_ ' Occ^onaT ~T", bkJI Winds _ light
Noise n V Summer Sun! ^Summer Sun I i View to I yartfe f
cy^Hn (71* 3^01 wall Vievy to. ear.. | =*- \pr<tea£noc*\
I 4-----1! 1 I<7W<51 6. Your client wants a steeply pitched
roof, but is unsure of the material to use. How many
different generic types of roofing material can you find
in the product literature that would be appropriate to
use? Diagnostic Interviewing 1. Choose a partner and an
observer. Then try to sit facing the partner for one
minute without communicating anything! Have the observer
check the time and whether you or your partner
communicated anything. You will find that a minute of
silence is a long time. You will also find that it is
practically impossible not to communi cate! Even if you
say nothing, much will be communicated non-verbally. Ask
the observer what he/she saw. 2. Stay in the same grouping
with two persons playing the roles of interviewer and
interviewee by facing each other at a comfortable
distance. Decide on a current design topic to be
discussed. Then try to use only non-verbal acceptance
skills (nodding, uh-huhs, smiles, openness, eye contact) to
keep the other person talking. Then add verbal acceptance
skills. Have the observer explain what he/she saw. 3.
Switch roles and add two active listening skills
(reflection, clarification). Switch roles again and add
the management skills (amplification and redirection). It
will take some prac tice to become comfortable using all
of these appraisal skills. Practice these skills in private
conversation. Try to get another person to do all of the
talking. You will be amazed at how interesting the person
will find you to be, when he/she does all of the talking!
4. Also practice the diagnosis skills. In succinct phrases,
try to interpret the essence of what you have heard. After
a period on the same general topic, summarize to obtain
some affirma tion that you have captured the interviewee’s
point of view. 5. Plan an interview to include the six
steps outlined in the chapter (introduction, appraisal,
diagnosis, recording, re view, open ending). 6. Following
the above plan, role play a complete interview on an
architectural topic of interest using a three-person group
(interviewer, interviewee, observer). 7. Follow up with two
or three actual interviews for a current project. Bring
along an observer to tell you how well you do.

Diagnostic Observation 1. Tune up your observational

abilities by looking at familiar places, varying focus
from people, to places, to tasks, and to objects. 2.
Conduct a walk-through of a familiar facility with a user
to learn how their perceptions differ from yours. Use a
record ing sheet similar to one of those described to
record your observations, the user’s comments, and your
own thoughts. 3. Take a space inventory of two different
spaces used for the same general purpose, like two faculty
offices or class rooms. Use all of the techniques
described to make the in ventory. Then try to determine
through the use of trace evidence how the rooms have
actually been used. 4. Take a map of a well known public
space and conduct a one-day session mapping the behavior
of all users to see if the conclusions of other
researchers appear to be con firmed. 5. Take a problem in
your environment and plan a systematic observation to
cover all people, places, tasks, and objects over a
certain time period. Vary the scale of your observa tion
from area to room, materials, and furnishings. Set up your
observation to involve counts of various elements at
specified time intervals so that simple descriptive
statistics can be developed and a pie chart or histogram
used to sum marize the findings.

Questionnaires and Surveys 1. Using the 10 steps of

questionnaire preparation, develop a questionnaire to
administer to your colleagues to determine the
human/functional needs for a completely up-to-date de sign
studio. Use each of the first five question types out
lined in the text. 2. Accept the criticism of your peers in
a pretest and recon struct the questionnaire in a logical
order and with more appropriate questions. 3. Identify the
different categories of persons who can provide insights
about your organization, and select a small repre
sentative sample of persons to fill out your questionnaire.
Ackoff, Russell L. 1962. Scientific Method: Optimizing
Applied Research Decisions. New York: Wiley.

________ . 1967. Class lecture in operations research at

the Uni versity of Pennsylvania, Philadelphia, Pa.

AIA Task Force on Aging. 1985. Design For Aging: An

Architect’s Guide. Washington, D.C.: American Institute of
Architects.

American Institute of Architects. 1994. Architectural

Graphic Standards, edited by John Ray Hoke. New York: John
Wiley.

Bardens, Dennis. 1969. Churchill in Parliament. South

Brunswick, N. J.: A. S. Barnes.

Barker, Roger. 1968. Ecological Psychology; Concepts and

Meth ods for Studying the Environment of Human Behavior.
Stan ford, Calif.: Stanford University Press.

Bechtel, Robert, Robert Marans, and William Michelson. 1987.

Methods in Environmental and Behavioral Research. New York:

Van Nostrand Reinhold.

Berdie, Douglas R., John F. Anderson, and Marsha A.

Niebuhr. 1986. Questionnaires: Design and Use. Metuchen,
N.J.: Scare crow Press.

Bertrand, Raymond. 1993. The Role of the Programmer as

Inter preter and Translator. In Professional Practice in
Facility Pro

gramming, edited by Wolfgang F. E. Preiser. New York: Van

Nostrand Reinhold.

Blalock, Hubert M. Jr. 1960. Social Statistics. New York:

Mc Graw-Hill Book Co. Inc.

Blosser, Fred. 1992. Primer on Occupational Safety and

Health.

Washington, D.C.: Bureau of National Affairs.

Board of Church Extension of Disciples of Christ. 1990.

Strategic

Planning and Building Planning for New Congregations. Indi

anapolis, Ind.: Disciples of Christ.

BOCA. 1990. The BOCA National Building Code. Country Club

Hills, 111.: Building Officials and Code Administrators
Interna

tional.

Bradburn, Norman M., Seymour Sudman, and Edward Blair.

1979. Improving Interview Method and Questionnaire Design.
San Francisco: Jossey-Bass.

Bradfield, Valerie J., ed. 1983. Information Sources in

Architec

ture. Boston: Butterworths.

Callender, John, ed. 1982. Time-Saver Standards for

Architectural

Design Data. New York: McGraw-Hill. City of Tucson. 1972.

Tucson Historic Districts: Criteria for Preservation and
Development. Tucson, Arizona: Department of Community
Development, Planning Division. Clark, Roger, and Michael
Pause. 1996. Precedents in Architec ture. New York: Van
Nostrand Reinhold. Collier, John Jr. 1967. Visual
Anthropology: Photography as a Re search Method. New York:
Holt, Rinehart and Winston. Cook, R., and D. Miles. 1978.
Plazas for People: Seattle Federal Building Plaza: A Case
Study. New York: Projects for Public Spaces, Inc. Davis,
Gerald, and Virginia Ayers. 1975. Photographic Recording
of Environment and Behavior. In Behavioral Research Methods
in Environmental Design, edited by William Michelson.
Stroudsburg, Pa.: Dowden, Hutchinson & Ross. Deasy, C. M.,
and Thomas Lasswell. 1985. Designing Places for People. New
York: Whitney Library of Design. De Chiara, Joseph, and
John Hancock Callender, eds. 1973. Time-Saver Standards
for Building Types. New York: McGraw Hill Book Co.
Diercks, Janet E., ed. 1998. Architects’ First Source For
Products. Atlanta, Ga.: Architects’ First Source. Downs,
Roger, and David Stea, eds. 1973. Image and Environ ment;
Cognitive Mapping and Spatial Behavior. Chicago: Al- dine
Pub. Co. France, Kenneth, and Michelle Kish. 1995.
Supportive Interview ing in Human Service Organizations:
Fundamental Skills for Gathering Information and
Encouraging Productive Change. Springfield, 111.: Charles
C. Thomas. Frisch, David, and Susan Frisch. 1998. Metal
Design and Fabri cation. New York: Watson-Guptill
Publications. Harris, David A. 1981. Planning and Designing
the Office Envi ronment. New York: Van Nostrand Reinhold.
Hester, Randolph T. Jr. 1975. Neighborhood Space.
Stroudsburg, Pa.: Dowden, Hutchinson & Ross. International
Conference of Building Officials. 1994. Uniform Building
Code: Administrative, Fire- and Life-Safety, and Field
Inspection Provisions. Volume 1 of Uniform Building Code.
Whittier, Calif.: ICBO. ________ . 1994. Uniform Building
Code. Whittier, Calif.: ICBO. Ittelson, William H., Leanne
G. Rivlin, and Harold M. Proshan- sky. 1970. The Use of
Behavioral Maps in Environmental Psy chology. In
Environmental Psychology: Man and His Physical Setting,
edited by Harold M. Proshansky, William H. Ittleson, and
Leanne G. Rivlin. New York: Holt, Rinehart and Winston.

Kirk, Stephen J., and Kent F. Spreckelmeyer. 1988. Creative

De sign Decisions: A Systematic Approach to Problem
Solving in Ar chitecture. New York: Van Nostrand Reinhold.

Kumlin, Robert R. 1995. Architectural Programming: Creative

Techniques for Design Professionals. New York:
McGraw-Hill.

Lindheim, Rosyln. 1966. Putting Research To Work. AIA

Journal. 66(2), 46-53.

Lynch, Kevin. 1971. Site Planning. Cambridge, Mass.: M.I.T.

Press.

Marans, Robert, and Kent Spreckelmeyer. 1981. Evaluating

Built

Environments: A Behavioral Approach. Ann Arbor: Survey Re

search Center, University of Michigan.

McGraw-Hill Construction Information Group. 1997. Sweet’s

Catalog File. New York: McGraw-Hill.

_________. 1997. Sweet’s General Building & Renovation

Catalog

File. New York: McGraw-Hill.

McHarg, Ian. 1969. Design with Nature. Garden City, N.Y.:

Nat ural History Press.

Moore, Gary, and Reginald Golledge. 1976. Environmental

Knowing: Theories, Research, and Methods. Stroudsburg, Pa.:

Dowden, Hutchinson & Ross.

Palmer, Mickey A. 1981. The Architect’s Guide to Facility

Pro

gramming. New York: Architectural Record Books.

Pastalan, Leon A., and Daniel H. Carson. 1970. Spatial

Behavior

o f Older People. Ann Arbor: Institute of Gerontology,

Univer

sity of Michigan; and Wayne State University.

Pena, William, and John W. Focke. 1969. Problem Seeking: New

Directions in Architectural Programming. Houston, Tex.:

Caudill Rowlett Scott.

Pena, William, Steven Parshall, and Kevin Kelly. 1987.

Problem

Seeking: An Architectural Programming Primer. 3rd ed. Wash

ington, D.C.: AIA Press.

Peponis, John, Craig Zimring, and Yoon Kyung Choi. 1990.

Find

ing the Building in Wayfinding. Environment and Behavior.

22(5): 555-590.

Preiser, Wolfgang F. E., ed. 1978. Facility Programming:

Methods

and Applications. Stroudsburg, Pa.: Dowden, Hutchinson &

Ross.

_________. 1985. Programming the Built Environment. New

York:

Van Nostrand Reinhold. Quayle, Dan. 1996. Election Year

Survey on Politics and the Me dia. Alexandria, Va.: Media
Research Center. Rae, Leslie. 1988. The Skills o f
Interviewing: A Guide for Man agers and Trainers.
Aldershot, Hants.: Gower. Reznikoff, S. C. 1986. Interior
Graphic and Design Standards. New York: Whitney Library of
Design. Ripley, Robert. 1980-85. Classroom lectures and
demonstrations in active listening in the architectural
programming class at Arizona State University, Tempe,
Arizona. Rosenbaum, Sonia. 1979. Quantitative Methods and
Statistics: A Guide to Social Research. Beverly Hills:
Sage Publications. Rubenstein, Harvey M. 1987. A Guide to
Site and Environmental Planning. 3rd ed. New York: Wiley.
Sanoff, Henry. 1977. Methods o f Architectural
Programming. Stroudsburg, Pa.: Dowden, Hutchinson & Ross.
Shalaby, Mostafa. 1988. The Optimum Layout o f Single Story
Manufacturing Areas. Ph.D. diss., The University of
Pennsyl vania, Philadelphia. Siegel, Sidney. 1956.
Nonparametric Statistics for the Behavioral Sciences. New
York: McGraw-Hill. Sommer, Robert. 1974. Tight Spaces; Hard
Architecture and How to Humanize It. Englewood Cliffs,
N.J.: Prentice-Hall. Sullivan, Louis. 1949. The
Autobiography o f an Idea. New York: Peter Smith. Trites,
David, Frank Galbraith Jr., Madelyne Sturdavant, and John
Leckwart. 1970. “Influence of Nursing-Unit Design on the
Activities and Subjective Feelings of Nursing Personnel.”
Environment and Behavior. 2(3): 303-334. Webb, Eugene T.
1981. Nonreactive Measures in the Social Sci ences.
Boston: Houghton Mifflin. Weisberg, Herbert F., Jon A.
Kronsnick, and Bruce D. Bowen. 1996. Introduction to
Survey Research and Data Analysis. Thousand Oaks, Calif.:
Sage Publications. White, Edward T. III. 1983. Site
Analysis: Diagramming Informa tion for Architectural
Design. Tucson, Ariz.: Architectural Media. Whyte, William
H. 1988. The Social Life o f Small Urban Spaces [video
recording]. Los Angeles, Calif.: Direct Cinema Limited.
Wilson, Forrest. 1984. A Graphic Survey o f Perception and
Behavior for the Design Professions. New York: Van
Nostrand Reinhold. Yao, Wimberta. 1987. Literature Search
Steps. Unpublished manuscript. Arizona State University,
Tempe. Zeisel, John. 1981. Inquiry by Design: Tools fo r
Environment- BehaviorResearch. Monterey, Calif.:
Brooks/Cole Publishing Co.
7 Chapter 7: Program Preparation

PROCESS

The contents of this report were developed through a

series of user interviews and Library Administration

reviews held at the offices of Anderson DeBartolo Pan,

Inc. during the weeks of April 14th - 18th and April

21st - 25th. Further work sessions were held during

the week of April 28th - May 2nd with the City of

Tucson Library Planning Consultant, Richard L. Waters;

and the Architect's Space Planning Consultants, David

and Andrea Michaels, to refine the results of the User

Interviews Space Needs Tabulations and to establish

spatial requirements and criteria for a balanced

budget.

Following these work sessions a Preliminary Program

Report containing the results of the Space Needs

Tabulations was developed and reviewed by all parties

involved in the programming process. The Spatial

Needs Summaries included herein have incorporated the

comments and modifications suggested in those

revisions.

Figure 7-7 Typical Methods Section.

Credit: Anderson DeBartolo Pan, Inc. 1986. City o f Tucson

Main Library A rch itectural Pro

gram. Tucson, Arizona. Permission: ADP Marshall

Organization Name, Address, Phone, FAX

Owner/CEO

VP (in charge)

Department Officer 1

Department Officer n

Building Manager

Architect Name, Address, Phone, FAX

Partner (n charge)

Project Programmer

Project Architect

Project Designer

Consultant(s) Name, Address, Phone, FAX

Contact Person(s)

Regulatory Agency, Address, Phone, FAX

Contact Person(s) If the summary appears

to be an adequate reflection

of the overall needs of the

organization, the executive

can accept the program

without spending valuable

time reading through all of

the detail that may be im

portant to subordinates, but

of no special concern to the

executive. The executive can

delegate to others the task of

reviewing detailed informa

tion in specific areas. In the

same way, the executive

summary allows the de

signer to obtain an under

standing of the entire design

problem before digging into

all of the supporting infor

mation necessary to develop

a successful design. Indeed,

it reveals to anyone reading

the document the key issues

to look for as they continue

through the document.

The executive summary typically is only a few pages in

length and

contains information about all program areas. It should

briefly

state: • The organization’s mission/purposes • How the

project will serve these purposes • The principal values or
issues • Specific goals to be achieved • Important
constraints or opportunities • Special user needs • Overall
sizes and relationships • The quality level of materials
and systems • The project schedule • The project budget and
preliminary cost estimates. If it is for a speculative
building, it might also include summaries of market
conditions or financial feasibility studies. These are sim
ply very condensed versions of the sections that follow,
but with emphasis on the overall goals, requirements,
schedule, and costs. The executive statement may also
indicate that some require ments of the program may change
as the design progresses, and, if so, that a change in the
scope of services and compensation may be required. If
such a statement is included in the summary, it gives the
programmer and architect a measure of protection if later
de velopments require extensive changes in the work (Fig.
7-9). It may not be possible to get everyone to sign off
on a dis claimer such as the one shown in the adjoining
executive sum mary; however, it is an excel lent idea.
The preliminary design is in some sense another
restatement of the program, of ten containing compromises
relative to goal accomplish ment, variations from the pro
gram in the actual size or relationship of spaces, and
other characteristics that do not conform exactly to the
orig inal program document. This is to be expected and
should not come as a shock to anyone. It should be
understood by all parties that the program is not
immutable; that more will be learned about the program
dur ing the design process; and that this new knowledge
might

Figure 7-9 Short Executive Summary. necessitate deviations

from the

Credit: M ichael Kummer, 1987. Retail Camera Shop Program.

School of Architecture, Ari- Original p ro g ra m
(Robinson

zona State University an d Weeks 1984).

EXECUTIVE SUMMARX

The following program is an initial understanding of the

primary goals used to develop a small

corrmercial building to accommodate a retail camera store.

The total building square footage of the

retad camera store is expected not to exceed 1200 s.f..

This may allow the possibility for additional

corrmercial retail or office space, depending on the site

size and local codes.

The main issues of this program are to: communicate store

type and image through store front

design, provide a welcome environment and easy access for

the client, provide an open plan with

90-95% of merchandise displayed and the flexibility of

interior spaces to simplify circulation,
provnde adequate interior lighting that will effectivly
display mechandise, be cost effective while in

accordance with local codes.

The proposed site is locate in the Central Commercial

District of downtown Tempe, Arizona, on

the north side of seventh street between Mill Ave. and

Maple Ave.. The site is presently vacant and

rests next to a historical warehouse on the west side and a

single story commercial building on the

east side.

The Owner/Client, Programmer, and Designer understand and

agree that this is a preliminary

program document, and acknowledge that further design

exploration may reveal additional

opportunities or constraints which might necessitate

adjustments in program requirements. If such

adjustments have any major effects on the issues stated in

this program, it may be necessary to

renegotiate fees to reflect the increased scope of

architectural services.

Total Budget: Low $50211.00 Med $71729.00 High $83246.00

Owner/Client_______________________ Date_

Programmer____________________________________________ D
ate_

Architect_______________________________________________
Date_ On the other hand, if the owner changes the project
require

ments substantially after the program has been accepted and

es

pecially after design has commenced, or even when the

building

is at some stage of completion, it should be clearly

understood
that such changes will serve as a basis for the architect
to rene

gotiate fees. A disclaimer in the program, or as part of

the agree

ment for professional services, might help avoid unnecessary

disputes and delays during the design process. This is

especially

important if the client decides that substantial additional

space is

needed or that an upgrade in material or system quality is

essen

tial, but wants both within the original design and

construction

budget. This is not an unusual situation! Clients often

change

their minds as they gradually develop an understanding of

the de

sign implications of the program. Some are also very

forgetful as

to what they had agreed upon earlier. Many clients are

unrealistic

about what they want, compared to what they can afford.

7.5 Values and Goals

After the executive summary should come a section in which

the

information developed in the programming matrix is refined

for

the program document. A direct reproduction of a wall-sized

ma

trix is not possible in an 8 14" x 11” document, so it must

be pre

sented in another way. The author has found that first

presenting

the values and goals in simple phrases or sentences is an

effective

way to bring the designer up-to-date on the crucial issues

to be

dealt with in schematic design. This section can be

followed in

logical order with a design considerations (facts) section

to show

the context in which the values can be expressed and the

goals

met. This section can be followed by an extensive project

require

ments section in which master plan, schematic design, and

design

development requirements can be systematically covered.

Finally,

the ideas generated for the matrix can be presented. The

primary values and goals of the client/user articulated in

the programming matrix should be identified and amplified as

necessary to show the designer what is important to

accomplish

in the design. The importance of this section in setting an

appro

priate framework from which to structure the rest of the

program

and to begin design cannot be overstated. As covered

extensively in Chapters 1 through 3, values and is

sues uncovered in an architectural program will include

several

major areas such as the HECTTEAS areas: human,

environmental, cultural, technological, temporal, economic,
aesthetic, and safety. What is the mission of the
particular institution for which the pro gram is being
prepared? What special considerations should there be for
the human users? Is function a very important considera
tion? Are there users with handicaps or other special
needs? Is it important to communicate a certain image to
the community? Does the community have important urban
design objectives or guidelines which the individual
building must support and en hance? Similarly, there are
often values and goals relating to the natural
environment, to available technology, to time, to eco
nomic conditions, and to aesthetics. The important goals
for the project should be enumerated with each appropriate
value. In value-based programming, the values should be
placed in or der of importance, with specific goals or
objectives listed and dis cussed beside each value
heading. The goals should also be ranked relative to
importance from essential, to important, to desirable, or
some similar listing. Prioritization of values and goals is
of help to the programmer when budget constraints require
reductions in pro gram requirements. It also helps the
designer know where to focus design efforts. It is
important in this section of the program to provide the
de signer with an opportunity to de velop a clear
understanding of what must be accomplished and what would
be desirable to ac complish if various constraints allow.
There is no point in clut tering the designer’s mind with
constraints until a clear under standing of what the
client hopes to accomplish has been attained (Fig. 7-10).

Deaign Goals and Objectives

C h a p t e r 2 of this program contains a detailed list

of design goals

and objectives. Major goals are summarized below: E c o n o

m i c s . M a x i m u m value for investment (best ratio
of quality to cost). Min i m i z e maintenance, repair
and replacement costs. O p e r a t i o n a l E f f i c i e
n c y . E f f i c i e n t layout and flow. Minimize s
taffing requirements. Access for the handicapped. C o n t r
o l . S e c u r i t y an d S a f e t y . E x c e l l e n
t v i s u a l surveillance and physical control. T i m i
n g . O c c u p a n c y by the end of September, 1984.
Maintenance of c u r r e n t operations. A c c o m m o d
a t i o n of long terra development, i n c l u d i n g f
l e x i b l e i n t e r i o r l a y o u t s a nd an
eventual separate commercial crossing point. E n e r g y
and E n v i r o n m e n t . C o m f o r t throughout the
facility with e n e r g y e f f i c i e n c y . S p e c
i a l a t t e n t i o n to canopies and booths. A
dequate, gla r e f r e e light; acoustic controls. I m a g
e a n d E s t h e t i c s . A quality design r eflecting
the dignity, v i g o r an d s t a b i l i t y of the
U.S. government. Response to local climate and culture.
Welcoming. U s e r P e r c e p t i o n an d W a v f i n
d i n g . S e n s i t i v i t y to user/visitor p r o b l
e m s of a c c e s s , i n f o r m a t i o n needs,
communications as well as extreme contrasts of light and
heat. W o r k p l a c e Q u a l i t y . A p l e a s a n t
, comfortable, attractive place to w o r k , w i t h
the ability of workers to control certain aspects of their
e n v i r n o m e n t s .

Figure 7-10 Values and Goals Summary.

Credit: Farbstein/Williams & Associates, Inc., 1983. Border

Station San Luis, Arizona,

Pre-Design Program. United States Government, General

Services Administration, Re

gion 9, San Francisco, Project Number: NAZ01000-Am.

Permission: Jay Farbstein and

Associates 7.6 Design Considerations (facts) • Human

(activities and char acteristics) • Environmental (site
and cli mate) • Cultural (traditions, laws, codes, and
ordinances) • Technical • Other Programmers present the de

sign considerations generated

during the programming process

in a variety of ways. Some pro

grammers, such as William Pena of

CRS, preferred to present them in

the same format as found in the

programming matrix that his firm

uses (Pena et al. 1969, 1977,

1986). The “facts” section of the

program matrix needs only to be

taken down from the wall and re

produced in program format. Gen

erally, however, Pena and other

programmers using the card sys

tem will reduce the card size in the

program and add verbal descrip

tion to make them more under

standable to persons who were not

at the work sessions (Fig. 7-11). By re-presenting the

cards,

this approach avoids the possibil

ity that information will be in

cluded in the programming

document that was not actually

presented to and considered and

accepted by the group during the

work sessions. Programmers us

ing verbal cards or grid paper are

more likely to transcribe the in

formation into a typed format

and, thus, to produce a some

what more dense and informa

tion rich set of facts. This is

particularly true if their intent is

just for schematic design, but for

(Fig. 7-12). (HrninTf L .. CCD "Pt? ce/trcK /s u c m o

eerve&J thb uMvCFS/rr Atro actnB ctMMUNrrr StKppfUS tBe
cemz. ts s&kxated F/tm tub tf.ws/s/ry ey A MFlCZ. STZStr
MS&NS r r w e f tum/J tw t cennndN/ff. & C ID 7HS
(fwmsroKl STKS-T SNOPS F’KWce Tts 0Vir firfiKM- vB wfru
7W fc&ne sgvcd er c&rr&t /‘.'Jo me eteve™ in me m ispw z
acm tjw PFArJ jfappiC.. FORM (Environment) The center,
then is to be located between the university on the south
ond the rowhouse stums and the active community shopping
area on the north. FORM (Environment) However, since the
center w ill be separated from the university by a major
street it may become more closely associated with the
community. FORM (Environment) A very positive force in the
v ic in ity , Lexington Avenue one block to the north, is
an extremely active market area. The Lexington Street
shops provide the only link with the people served by the
center and the only element that w ill draw pedestrian
traffic. Figure 7-11 Facts Page of a CRS Program. Credit:
CRS, 1971. Community M enta l Health and Retardation Center
Program. Per mission: William Pena, HOK 1. Current main
entry is confused with back entry.(Main entry does not
face community. 2. Presently there is only 1 elevator that
is inadequate in speed and accessibility. 3. At this time,
the rear stairwells serve as both a vertical circulation
system and ingress/egress, which causes major conjestion,
and threatens emergency exiting procedures. 4. The
handicapped access is limited to front entry through
gallery and secondary basement entry. Gallery entrance is
locked after 5 pm, and basement entry is locked many times
also, therefore denying handicapped access to elevator. 5.
Currently, students are unaware of other students work
within the different levels of the
college.(Pre-proffession- al included. 6. Existing
information tack boards can only be accessed during
administraion office hours which limits student awareness.
7. Presently, there is only 1 soft drink machine which is
inconveniently located in the basement, and is many times
empty. Figure 7-12 Facts Page of a Text-Based Program.
Credit: David Sandvig, Rob Darney, and Chris Caroselli,
1986. Program fo rthe New A r chitecture Building.
Permission: School of Architecture, Arizona State
University to provide information not design development
as well It is also possible to condense some of the fac
tual information onto charts or graphs to make it easier
to understand and compare (Fig. 7-13). It makes sense to
pre sent the facts that should impact design in a format
similar to the matrix of val ues developed earlier in the
programming process. Typ ically there will be facts
(constraints and opportuni ties) relating to each of the
value areas identified. Human (activities and
characteristics) Often something needs to be said about
the particular nature of the organization and its
activities before specific requirements for spaces and
relationships are set forth. It is most helpful for the
designer to know the organizational structure as well as
the ma jor human functions that

Figure 7-13 Summary Zoning/Issue Chart. the existing and

future fa

Credit: Zachary Burns, Roger Dong, Stacy Kluck, Kean Ong,

and Marc Soloway, 1995. Open-lnn cilities W i l l
accommodate.

Runaway Center Program. College of Architecture, The

University of Arizona Information about the O r
ganization’s mission and goals is also useful. If
particular social relationships are encour aged or
discouraged, this should also be pointed out. Special
needs of the current and prospective users may also be
included. Are very old, very young, handicapped, or other
non-typical peo ple frequent users of the building? If so,
what are their particular characteristics and physical
needs? All of these facts should be

ZONING / ISSUE CHART DAY USE NIGHT USE PUBLIC PRIVATE STAFF
YOUTH

Outdoor Space 0 • •

Storage 0 •

Public Bathroom 0 • •

Youth Bath - Girls • •

Bedroom - Girls • •

Youth Bath - Boys • •

Bedroom - Boys • •

Foyer 0 • •

Director’s Office 0 • •

Counseling 0 • •

Multi - Purpose 0 • •

Laundry 0 • •

Linen Closet 0 • •
Staff Office 0 •

Staff Bath 0 •

Kitchen 0 • •

Pantry 0 •

Dining / Study 0 • •

Day Uses: Youth are permitted in these area between the

hours of 7a.m. and 10p.m.

N igh t U ses: Youth are only permitted in these area

between the hours of 10p.m. and 7a.m.

Public: The activities in these spaces should not interfere

or disrupt the activities in the pnvate spaces

P riv a te : The nature of these spaces demand privacy from

all public spaces

Staff: These spaces are primarily used only by the staff.

The youth are only permitted with permission

Y outh : These spaces are used primarily by the youth with

staff supervision

stated so the designer can

acquire a better under

standing of the design

constraints and opportu

nities relating to the hu

man content of the facility

(Fig. 7-14).

Environmental (site and

climate)

The development of a

good understanding of
the environmental con

text of a design problem

typically or logically be

gins with a description

and appropriate visual il

lustrations of the loca

tion of the project: the

city or region in which

the site is located, its im

mediate environmental

context, the characteris

tics of the site, the cli

mate and microclimate,

and any other informa

tion on sues of the de

sign problem. Typically,

information about a site

is overlaid and annotated

on a plan of the site (Fig.

7-15). Factual information

about local climate con

ditions can be obtained

from the United States

Weather Bureau publica

tions. It is often repre

sented in charts and

diagrams (Fig. 7-16). The university campus poses problems

of negotiating campus life for the elderly. For many, the
complexity of the campus is frustrating. The atmosphere Is
fast paced and impersonal which may intimidate those who
are no longer so mobile. The long dis tances to and from
buildings may be difficult to negotiate. Transportation is
a problem for any student, but in particular for the
senior adult. The traffic congestion, the problem of
finding a parking space, and the long walk to campus
after parking would be discouraging. Because of these
problems, a mini-campus working with the university is
envisioned as an answer to lessen the intimi dating
aspects of the university system. The facility would acco
m modate five major types of users: A. Persons Interested
in continuing their education through a degree or
certificate program. B. Para-professionals: 1. Tra i ned a
d u 1ts wi th valuable skills and ideas to offer others
as counselors and teachers. 2. Senior adults enrolled in
training programs. C. Retired teachers interested in
sharing their teaching abilities and expertise would serve
as an exciting catalyst for all. D. Students with
interests in the study of gerontology would add vitality
and a link to the present youth-oriented society. E.
Support persons such as custodians, administrative pe rs
on nel , etc. Figure 7-14 Human Fact Statements. Credit:
Carmelita Apodaca, Elaine Cesta, Linda Congreve, Marley
Porter, Bob Krikac, and John Jakob, Associate Professor,
1980. Program for Sachel: Senior A du lt Community fo r a
Higher Edu cation Lifestyle, Tempe, Arizona. Permission:
School of Architecture, Arizona State University Figure
7-16 Site Information. Credit: Fourth Year Design Studio,
Professor Poster, 1990. Salvation Arm y Homeless Facility,
Pro gram and Site Analysis. College of Architecture, The
University of Arizona V ie w s from the S ite
u^ecL9ukipiki^ 7 akea. UV-fc Views 1£> KMJUbMJ EXPetL&Wf
k/l£Wt> C > ftX £ O U MtV|e>. V i I ^ ^Anxrfo t> ?xm %
CJpc^ \1E Vcotc I li M £G Aflv£ ! N&'&o I tn m Lf Go?p
views/ r & p K | H t /^ Y tP A p F iO [ V 't e S ‘ te^
^ v^&ui^ /----i»i il ftp

~ jquifli. mrnmmmmmmmmmm

iililliillll i l i l ■■ I 1 m m ■1I B I 1 1E ■ I 1 I ■ ■ 1
I B■ I ■ 1I 1 I ■ 1 ■ I 1i m 1 ■ 1 1 ■ ■ B i n I mm 1 r a 1
wm I n 1 nm 1 EB ■ m s C lim ate Sky Cover, Solar, Wind
Climate 124
Figure 7-16 Climate Information.

Credit: Fourth Year Design Studio, Professor Poster, 1990.

Salvation A rm y Home

less Facility, Program and Site Analysis. College of

Architecture, The University

of Arizona

llJ PARKING AREA DESIGN PLAN TYPICAL DESIGN TREATMENT

Figure 7-17 Screening Requirements.

Credit: Comprehensive Campus Plan, 1988. The University of

Arizona, and the

Arizona Board of Regents. Permission: The University of

Arizona Cultural (traditions, laws, codes, and ordinances)
An explanation of the cultural context of the problem is
also important. What are the community traditions? Are
there particular expectations rela tive to the building
type to be de signed? Is there a community fabric to
which the designer should be sensi tive? Can the project
help the commu nity achieve some of its urban design
objectives? If so, these facts should be pointed out to
give the designer an op portunity to fit the design within
this larger framework. This section should also point out
whether the community has adopted ordinances or special
re view procedures relating to site, build ing, or
landscape appearance. A description of how and where the
de signer can obtain the ordinances and review procedures
should be included in this section along with information
about key or unusual provisions of the ordinances or
procedures. For in stance, some communities and institu
tions have restrictive sign control and landscaping
requirements while oth ers have few or minimal
restrictions. The designer needs to know what the
requirements are before commencing design (Fig. 7-17).
Technical There may also be facts about physical or
technical aspects of the facility which should be pointed
out in the program. Do the occupants or equip ment for
this type of facility typically need closely controlled
temperature or humidity? Are particular materials or CAR
PARKING ^ 9 0 ° 8 'x 1 8 'stall i D * f I I M , § i c !
3|i j O | -.-screen wall |--i : f- jandfccapjed sfrr a I
building ^ \ | SERVICE landscaped island Ih 1111 i
.niiiuijuiiiiniliii.::!.! jo f y iqcTe~path .......... —
«-------ramps — i 1 jo fp e d ;strian path : 'specijal
c'to tsS J I treatm ent gj :l I CVOupl CUA&'I
finishes used in order to meet the requirements of
occupants or

maintenance objectives of the organization? This type of

information

should be included if it is likely to impact upon design

decisions. The programmer must be careful when presenting
facts. There

is a danger of implying that the future solution must be

similar to

the existing when, in fact, the owner would like to

entertain alter

native approaches. It should be made clear to what extent

the

included information relates to the existing facility, to

characteris

tics of other similar facilities, or even to historical

prototypes.

These are not facts about the facility that has yet to be
designed.

If there are physical or technical requirements for the

future facil

ity, they should be set forth in the section on project

requirements.

Other

There could, of course, be design considerations relating

to any of

the other HECTTEAS areas or to any other value areas agreed

on

during programming. There could be facts relating to the

image of

the facility, to signage, even to form or color. There may

be facts

relating to energy conservation and other similar concerns

which

arise during programming. There could be facts relating to

safety,

accessibility, or to any other value area discovered in the

pro

gramming process that constrain or provide opportunities

for de

sign. The above sections on human, environmental, cultural,

and

technical design considerations are only examples of the

types of

information typically covered in the design considerations

section

of the program. It is also appropriate to set forth facts

about budget and time

constraints in the section on design considerations. Many

pro

grammers, however, prefer to discuss facts about budget and

schedule in separate sections of the program, because these

areas

are of such great importance for the successful completion

of a

project. There is also a problem of deciding if such

information

should be a design consideration (fact) or a requirement

(need).

The client’s budget is a fact with which the designer must

be fa

miliar because it sets limits or constraints on what can be

done. It

is also a requirement in the sense that design decisions

must be

made that will keep the cost of the facility within the
stated limits. The same is true for project schedule. There
may be a specific

date when the client must vacate existing facilities. This

is a fact.

But the schedule to vacate may also set a requirement for

when the

new facility must be ready for occupancy. For these reasons

it is

best to include information about budget and schedule in

separate sections of the program to highlight their crucial
importance to the successful completion of the project.
7.7 Project Requirements • Needs • Performance Requirements
(PRs) • Design Requirements (DRs) Project requirements will
vary considerably depending on the nature of the project
under consideration. If the program includes master
planning for the entire site, then there will be a section
on master plan requirements. If it includes programming
for a spe cific building project, the program will list
requirements appro priate for schematic design including
tabular information on space allocation, room
relationships, relationship diagrams, pro ject schedule,
and project cost analysis. If it is a comprehensive
architectural program involving design development, the
program will also include requirements for individual
spaces and for build ing systems. Requirement statements
will be developed from the needs cards or short phrases of
the programming matrix. They will be refined into
performance requirements or design require ments, or
distilled into tabular form showing required space allo
cations, space relationships, project schedule, and project
costs: • Master Planning Requirements - Site Design
(circulation, parking, drainage, retention, utilities) -
Building Layout (overall building relationships, sizes,
loca tion, orientation, future expansion) • Schematic
Design Requirements - Building Design (building
organization, size, orientation, image, growth, change) -
Interior Design (user needs, activities, sizes,
relationships, conditions) - Space Identification and
Square Footage Allocation - Relationship Matrices and
Diagrams • Design Development Requirements - Space Program
Sheets - Building Systems Requirements (materials, systems,
pro cesses) If a program is intended to serve only one of
these design phases, then information relating to the
other phases might be left out of the

document. For instance, if the master planning has already

been ac

complished, perhaps by another design firm, then the program

could focus only on the specific building to be designed.

Elimination

of material from earlier or later sections of the program

would be

appropriate if the purposes of the program were so limited.

Needs

In many poorly developed programs, a simple listing of the

re

quired spaces is the program. The client or novice

programmers

set forth what space they think is needed, without any

systematic

consideration of the institutional purposes to be served,

values to

be expressed, project goals and objectives to be met,

environmen

tal or cultural context, special users, client/user design

ideas, or

any other such considerations. They fail to develop the

context of

values, goals, and facts from which needs should be

derived. This

is unfortunate and confusing to the designer, and tends to

reduce

design to a puzzle-solving exercise, rather than a creative

en

deavor in which design solutions are the result of keen

insight

into the nature of the design problem. On the other hand,

when the preliminary sections of the ar
chitectural program contain complete information on the

client’s and user’s values, goals, and objectives as well

as on

factual constraints and opportunities, the project

requirements

(or needs) section of the program will

be easy to develop and can be lean and

straightforward. It can focus on the re

quired performance and facility needs

without further discussion of the key

issues, explanation of important facts,

or other considerations, because they

will already have been covered. The space needs developed

in the

value-based programming matrix are pre

sented in much the same way as for goals

and facts. Programmers using cards in

the programming matrix will often group

the cards on pages of the program and

augment them with verbal descriptions

(Fig. 7-18). Those using verbal cards or

grid paper are more likely to accumulate

the needs into lists relating to each of

the respective value areas (Fig. 7-19). <rm y (I •<F Figure

7-18 Space Needs Page: Cards. Credit: Brooks & Associates
AIA, Architects and Planners, 1988. Vail M id dle School
Master Plan & Program. Vail School D istrict No. 20. Vail,
A ri zona. Permission: Albanese-Brooks Assoc. PC Plan fo r
community event pa rk ing needs Relocate u t i l i t i e s
to accommodate fu tu re p lus designated ove rflo w area.
Improvements. P ro v id e covered walkways fo r pe de s
tria n P ro v id e s i t e l ig n t in g fo r s e c u
r ity and c om fo rt. com fo rt.

334 Architectural Programming and Predesign Manager It is

worthwhile to consider how need statements can be reformu
lated after the work sessions, be cause how needs are
stated can have an important effect on design. There are
two kinds of needs state ments included in an
architectural program: performance require ments and
design requirements (Duerk 1993). Performance Requirements
(PRs) Performance requirements are statements of how some
aspect of the organization or design should perform. They
are a small step below goals, and in traditional terms
could be referred to as ob jectives—specific ways that a
goal can be met. Performance re quirements can relate to
the building occupants, spaces, sys tems, and materials,
and typi cally are stated in such a way that it is
possible to measure their accomplishment. The mea
surement can be: 1. A simple binary or dichoto- mous
judgment by the de signer, owner, or experts— yes or no,
accomplished or not accomplished. 2. An acceptable range
of values that can be physically mea sured, such as in
inches, decibels, lumens, or degrees. The achievement of a
goal may require accomplishment of one or several
performance requirements.

FORM NEEDS

1 . C om plete s c re e n in g o f p a rk in g fro m W
arner Road.

2 . P a rk in g and p e d e s tr ia n access from both

W arner and P en n in g to n .

3 . O v e rf lo w p a rk in g a t r e t e n t io n p a
n h a n d le .

4. E a r th berms to in t e g r a t e and in s u la t e
b u i ld in g .

5 . South f a c in g windows a re f o r p a s s iv e h
e a tin g and d a y l ig h t in g (Use f ix e d in s u
la te d u n i ts owned by c h u rc h ) .

6 . N o rth fa c in g windows f o r v ie w and d a y l

ig h t in g .

CONTEXT NEEDS
1 . L arg e p a t io f o r 150 s ta n d in g p e o p
le f o r c o f fe e & BBQ?

2 . S m all p a t io f o r 35 p e o p le & BBQ?

3 . A dequate l i g h t in g f o r p a rk in g and p a
t io s .

4. F i l t e r e d l i g h t f o r p a t io s on n o r
th .

5 . E x t e r io r p la c e s f o r t a b le t e n n is
, b a s e b a l l , v o l l e y b a l l .

6 . E x t e r io r p la c e s f o r p re -s c h o o l
and o ld e r c h ild r e n ( in v ie w ) .

7 . Access to t r a s h a t a l l e y .

8 . S h o rt t im e p a rk in g n e a r p re -s c h o o
l f o r drop o f f and p ic k up.

9 . O v e rf lo w p a rk in g in h a n d le o f r e t
e n t io n .

FUNCTION NEEDS A u d ito r iu m /F e llo w s h ip Phase 1 F

u tu re a . A u d ito r iu m /F e llo w s h ip to s ea t
fo r s e rv ic e s 1 25 -1 50 p. 200 -225 p. b. A u d
ito r iu m /F e llo w s h ip to sea t f o r p o tlu c k
s 150 p. 225 p. c . F o y e r /c o u r ty a rd to stand
f o r c o ffe e 125 -150 p. 2 00 -225 p. d. S to rag e
f o r round ta b le s s e a tin g s ix persons 25 t . 38
t . e . S to rag e f o r f o ld in g /s ta c k in g c h
a irs 75 ch. 150 ch. f . Space in a u d ito r iu m f o r
modular s ta g e /r i sers g. Space in a u d ito r iu m
f o r p ia n o , o rgan , a u d io v is u a l c o n t r o
l , a r t h. C o n f e r e n c e /1 ib r a r y /b r id e
/e tc . (See a d m in is tra t io n a re a ) i . K itch
en to serve p o tlu c k s /lu n c h s 5 -6 p. 6 -8 p.
j . R est rooms (M a le /fe m a le ) Code Code k . P ark
in g (c o d e -p ro je c te d ) 3 8 -6 0 sp. 5 7 -1 0 0
sp.

Figure 7-19 Space Needs Page: Text.

Credit: Hershberger Kim Architects, 1982. Valley Unitarian

Universalist Church, A r

ch itectural Program and M aster Plan Study. Chandler,

Arizona. The following are examples of goal statements
followed by per

formance requirements: 1. Goal: To have excellent seating

for theatrical performances. PR: Provide an unobstructed
view of at least three-quarters of the stage from all
seats. PR: Provide sound to each seat at the same level and
qual ity as if the seat were 20 feet from the stage. 2.
Goal: To utilize daylighting strategies to reduce energy
con sumption. PR: Provide 75% of the daytime lighting load
with day- lighting. 3. Goal: To have safe access from
parking and residential units to a commons room. PR:
Provide a minimum illumination level of two foot-can- dles
on the walking surface at exterior circulation ways. PR:
Circulation ways must at all points be visible from at
least two adjacent living units. 4. Goal: To communicate
the bank’s purposes to the public. PR: 95% of passing
motorists must be able to recognize the building as the
First Service Bank. PR: Access points to parking,
drive-through teller, and au tomatic teller must be
evident to passing motorists. Achievement of each of the
above performance requirements

can be measured or estimated. In the first example, it is

possible

to draw sight lines from every seat to determine whether or

not

three-quarters of the stage can be seen. It is also

possible with a

sound system to calculate and to measure (when completed)

if the

same level of sound is being provided at every seat as that

pro

vided to seats 20 feet from the stage. If a certain level

of illumi

nation is required, the foot-candles or lumens can be

calculated

during design using performance data for expected

daylighting

conditions as well as for specific lighting fixtures. The

same is

true for ventilation, heating, cooling, and acoustical

performance. Expected levels of human performance can also
be estimated

during design (and measured after occupancy). If a person

must

be able to reach a certain control switch, anthropometric

data can be used to determine if this will be possible. If
a person must be able to exit from a room in two
alternative directions, this can be observed by inspecting
the drawings. A required image or quality of space or
form, on the other hand, may require professional judgment
to determine if the need will be met. While not as pre
cise as other measures, this still allows appropriate
evaluation be fore proceeding to build a project. Note
that measured accomplishment of the performance re
quirements does not ensure that a goal will be achieved at
the highest level. It only helps to ensure that the goal
will be accom plished, perhaps at a minimum level. For
instance, achieving a goal of “excellent seating”
certainly requires unobstructed sight lines and proper
acoustics. But it also requires comfortable seating and
adequate leg room, good accessibility to the seats, proper
ven tilation and air conditioning, and acoustical and
lighting separa tion from other parts of the building. An
almost endless list of performance requirements would have
to be developed for each and every space to ensure a high
level of goal achievement. It is best to state only those
performance requirements that are consid ered to be unique
or crucial to the proper functioning of a facility. Design
Requirements (DRs) Design requirements, like performance
requirements, are more spe cific and measurable than goal
statements. However, they refer di rectly to the physical
characteristics of the building to be designed, rather
than to the performance of the occupants, spaces, systems,
or materials. All statements, numbers, or diagrams
specifying the size, shape, physical characteristics, and
relationships of various spaces are design requirements.
Specifications of particular furnishings, equipment,
materials, and finishes are also design requirements. In
value-based programming, all needs should be given in terms
that allow accomplishment in the design to be measured in
some way. This is usually easy to do if a certain product
is specified. It is either provided or it is not. A binary
measure (yes, no) or a simple count can be used to
determine if the required number of spaces or pieces of
furnishing or equipment have been provided. It may be
necessary to read a label on the drawing or in the
specifications to determine if a particular piece of
equipment has been provided. Square footage requirements
can be verified by measurement and calculation.
Accomplishment of required relationships can be veri fied
by observation and even measurement of the drawings. Design
requirements for the goal statements listed above illus

trate the difference between performance and design require

ments. The part of the sentence in parentheses indicates the

related performance requirement. 1. Goal: To have excellent

seating for theatrical performances. DR: Offset and vary
the width of seating (to allow persons to see between
persons seated in front of them). DR: Provide a minimum
three-inch rise between rows of seats, and raise the stage
three feet above first row (to allow people to see over
the people seated in front of them). DR: Provide a
distributed electronic sound reinforcement system (to
provide the same level and quality of sound at each seat).
DR: Provide a minimum of 6 ,0 0 0 square feet for the
seat ing area (to provide ample seating for 600 people).
2. Goal: To utilize daylighting strategies to reduce energy
con sumption. DR: Provide a clerestory lighting system (to
provide 75% of daytime lighting load). 3. Goal: To have
safe access from parking and residential units to a
commons room. DR: Provide walk lights at 20 to 30 feet on
center (to provide no less than two foot-candles of light
at the walking surface). DR: Design kitchen window in
housing units to overlook all pathways (to be certain that
circulation ways are visible from no less than two
adjacent living units). 4. Goal: To communicate the bank’s
purposes to the public. DR: Provide free-standing, lighted
signs with minimum four-inch-high letters with name and
logo of the bank at each street frontage and at street
faces of the building (to be certain that 95% of passing
motorists can recognize the building as a branch of First
Service Bank). DR: Provide same color brick, covered teller
canopy, and entrance canopy as currently exist on all
other branch banks (to be certain that 95% of passing
motorists can rec ognize the building as a First Service
Bank, even if they do not see the signs). It is easily
seen from the above illustra tions that design
requirements are actually second order requirements. A
performance requirement is almost always used (explic
itly or implicitly) to arrive at the design re quirement.
For example, a performance requirement to meet the goal “
to produce an excellent auditorium” might be “ that no
light or sound should be introduced into the auditorium
from any adjacent public circu lation area.” If left at
this level, the designer would be free to devise any
system that would ensure that this performance require
ment would be satisfied. On the other hand, experience
with numerous theaters and au ditoriums has led to the
repeated use of vestibules as light and sound locks
between the auditorium and the surrounding circula tion
ways (Fig. 7-20). It may be more likely, therefore, to
require that vestibules be provided (to ensure that light
and sound not penetrate into the auditorium). Another
design requirement for an auditorium might be that the
seating be “fully upholstered theater type seating” or even
that the seating be “fully upholstered theater seating by
Theater Seating Company A .” This might relate to
acoustical performance, audience comfort, accessibility to
interior seats, or to maintenance require ments. A client
may want a specific seat by a particular company and will
settle for nothing less, because in lengthy experience the
client has found no other satisfactory seat and does not
want to take a chance on poor quality seating! This
approach may seem un duly restrictive to a designer who
wishes to select or even to design the seating, but if an
owner group has had previous negative expe rience with
many seating systems and positive results with only one
model, they may not be willing to consider performance
require ments. They will want a design requirement— the
specification of a particular product. Sometimes, however,
it is possible for the pro grammer to convince a client to
define the performance desired and, thus, to allow a more
creative design or selection procedure. In some cases the
client may wish to state only the goal, and let the
designer try to meet it by her/his own creativity, knowl
edge, and experience. The architect can always refer to
recognized AUDITORIUM

VESTIBULE VESTIBULE VESTIBULE VESTIBULE FOYER

Figure 7-20 Vestibules as Light/Sound Locks.

design for guidance

when requirements are

not included in the pro

gram (Fig. 7-21). It is generally best to

provide a combination

of goals, performance

requirements, and de
sign requirements in a

program. This allows

the client, programmer,

and designer to obtain a

better understanding of

the design problem. The

goals allow everyone to

see what the organiza

tion hopes to achieve.

The performance re- Figure 7-21 Auditorium Sight Lines.

q uirem ents provide an Credit: Joseph De Chiara and John

Hancock Callendar, 1973. Time S aver Standards for Building
Types. j . i • r l McGraw Hill Book Co., NY, NY, p. 677.
Permission: McGraw-Hill understanding of how

important aspects of a

facility must work. Design requirements ensure that certain

min

imum needs are satisfied in crucial areas. Together they

help the

programmer make projections of the overall size of the

facility

and estimate the probable construction cost. The programmer

should not seek or develop requirements

where they really do not exist. If the client and users are
looking

to the architect for a creative new way to achieve a goal,

it makes

little sense to set forth a number of strict requirements.

However,

if a particular performance is required, it should be

stated in the
program. If a particular design feature is required, it
also should

be stated in the program. Requirements for a project can

also be expressed in tables con

sisting of lists, associated numbers, and diagrams. These

are effi

cient ways of stating needs, but unlike typical needs

statements,

performance requirements, and design requirements, do not

pro

vide any amplification or justification as to why something

should

be done. They are simply efficient ways to show the overall

size

of spaces and cost of the facility to be designed. The

primary uses

of tabular presentation of needs are covered in sections

7.8, 7.9,

7 .11 , and 7.12. o Two C ro ss A is le s O '

-------------------------N o C ro s s A is le s O n e C
ro s s A is le /anil Three C ro s s A is le s SEAT ING
A N D AISLE A RR ANG EM ENT S : H ea v ily s h a d ed a
r ea s r e p r e s e n t s t a g e a n d s e a t in g
a r ea lo ss e s from c om p a r a t iv e v isua l p o
sit ion in var iou s sy s tem s . C en te r A is le C o
n t in en ta l S id e S e c t io n S tad ium T yp e 7 3
Space Identification and Allocation • Tabular Presentation
• Leadership • Iconic Representation • Building Efficiency
Tabular Presentation In the work session, the spaces
identified as required in the pro gramming matrix are
listed in tabular form on brown sheets, grid sheets, or
another format for everyone to see. This promotes fo cused
group consideration and discussion of the number of re
quired spaces and the appropriate size for each space.
Thus, the square footages are listed to the right of each
of the listed spaces to form a simple table. The same form
is carried into the program document for the convenience
of the designer. Leadership It is common for the programmer
to lead lengthy work session discussions regarding the
number of persons who will be using various spaces, the
activities in which they are likely to engage, and the
type and amount of furnishings and equipment that will be
needed. The programmer will also point out norms or stan
dards for space sizes as found in the literature, in
comparable facilities, and for existing spaces in
facilities of the client/user group. This is done to help
the client/user group come to an un derstanding and
agreement as to what size each space must be to accomplish
the purposes of the organization. Clients and users
generally have little or no idea how big the spaces are
that they use or will need in the future. The programmer
must be the expert in this area. All of the information
gathered during the work session should be recorded by a
member of the programming group as it is brought forth,
because it will be useful in developing the space program
sheets discussed in section 7.10. At this point, however,
it is important to list all of the required spaces and to
record their respective sizes, so that an assessment can
be made of the overall scope of the project.

Iconic Representation

An effective adjunct to listing the square footage of each

required

space with numbers is to illustrate it with small

rectangular fig

ures at the same scale, i.e., at Me” = l'O”. This system is

effective

in showing laypersons the comparative size of spaces. It

can also

be helpful to the designer

during initial analysis of the

design problem. The num

bers may not be as effective

as the illustrations, since

most client/users have little

or no understanding of the

numerical sizes of the

spaces in which they live or

operate, but they can see the

relative differences in the

sizes of various spaces in the

graphic illustrations. Simi

larly, designers are often

more comfortable with iconic

rather than numeric imagery.

If one space looks exces

sively large relative to an

other space, the participants

will be quick to point this

out to the programmer. Because this information

is generally developed in a

tabular form during the

work session(s), as discussed

in Chapter 6 , it is necessary

only to upgrade the presen

tation of the material for the

program document. Simple

word processing combined

with the use of presentation

software will allow the pro

grammer to develop a qual- Space AllocationTab|e.

lty presentation O IS V I a Credit: Architecture 202,

Section 3, Professor Hershberger, 1998. A Program for A
Senior Cen-

information (Fig. 7-22). ter. Permission: College of

Architecture, The University of Arizona Spsce Idenifetfon &
Allocation. ' Large Multi-purpose Room 1500 square feet
Small Multi-purpose Room 600 square feet Craft Room/ Studio
800 square feet Computer Lab/ Lecture 600 square feet Game
room 1000 square feet Courtyard 1800 square feet Restrooms
3 @ 400 square feet Kitchen 500 square feet Private Meeting
Room 120 square feet Library/ Listening Post 600 square
feet Lounge and Reception 600 square feet Paid Staff Office
100 square feet Volunteer Office 100 square feet
Utility/Janitorial and Circulation 30% total area Total
Square Footage (plus 30%): 9,520 square

m bp a b □ mffl 2 5 0 150 Admin.

Control Offices

. , , & Stor.

E H 360

P m n ra m a * O f f ic e s 400 4 50 Snacks Concess. 500

Pubic Staff Toilets Toilets t aoof (sool M ech S to ra a e
f r r r p r n r Divisible Meeting Room & Lounge Lounae

Indoor Athletic Facilities

Revised Space Needs Summary Results of Programming Process.

TOTAL : 50, 9 9 4 60 100

Figure 7-23 Space Allocation Table.

Credit: Brooks & Associates AIA, Architects and Planners,

1985. Design Program and Site

Analysis for M orris K. U dall Regional Park and

Recreational Center. Tucson, Arizona. Per

mission: Albanese-Brooks Assoc. PC

Figure 7-24 Typical Office Standards.

Credit: Martha O'Mara, 1985. The Programming of Office

Interiors in Programming the Built

Environment. Ed. W. F. E. Preiser. New York: Van Nostrand

Reinhold. Permission: Wolfgang
F. E. Preiser This information can also be presented in a
more diagram matic form, rather than in a list with the
areas shown to scale as in the above illustration. The
following illustration shows the effect of a carefully
drawn dia gram as an alternative method of presenting the
space alloca tion information in the pro gram document
(Fig. 7-23). Using either of the above approaches, the
initial space al location sheets from the work sessions
can be reorganized in the quiet of the programmer’s
office. Logical groupings of spaces can be made and tabu
lations of subtotals, efficiency factors, and totals can
be pre pared. It is also possible to de velop more
detailed illustra tions of some of the required spaces.
This is sometimes done for offices, with size variations
and furnishing differences for various personnel, from the
chief executives to the secre tarial staff. If used, the
prelim inary standards developed by the programming group
will need to be reviewed in an exec utive work session to
be cer tain that they are acceptable before being
incorporated into the programming document (Fig. 7-24).
Building Efficiency When all of the required spaces have
been identified and square

Crafts Ceramics Painting Mech.

Arts & Crafts Viewing Area Circulation, Walls, etc. (15% )

5 3 Mech. IS poll Mech. Stor. ?:&W 618QQI Racquetball
Lockers

PRO PO SED O FF IC E STANDARDS D D ALTERNATE E ISO SQ.FT.

ISO SQ.FT. 135 SO. FT. F,G H l,J,K, O SO 90. FT 135 SO. FT.
L.M.N 160 80. FT. 45 SO. FT. A B.C 375 SO. FT. 300 SO. FT.
Am i- JQQK itc h en ChXds A r e a 4501 1100

footages assigned, it is necessary to estimate the amount

of addi

tional square footage that will be required to account for

unpro

grammed space, including circulation spaces, walls,

mechanical

and electrical rooms and chases, janitor’s closets, rest

rooms, and

miscellaneous storage. This amounts to a very substantial

percent

of the building area, and must be figured into the overall

size of the

facility and subsequently to its cost. This is referred to

in program

ming as the “net-to-gross ratio” or “building efficiency”

and varies

significantly for different building types. If it is

accounted for in

correctly, particularly on the low side, it can have a

significant

negative impact on building quality. So, what are some

expected net-to-gross ratios? A warehouse

or simple storage building may have a very high

net-to-gross ra

tio. The assignable area would be the warehouse or storage

space. The unassigned area would include only the exterior

walls, assuming that mechanical equipment could be placed on

the roof, electrical service placed on outside walls, and

janitorial

equipment simply placed within the warehouse area. Even so,

a

50' x 100 ’ building of this type would not have 100

percent effi

ciency because the exterior walls would take up unassigned

space.

Assume for simplicity that the walls were one foot thick
and that

the exterior was exactly 50' x 1 0 0 '—then the

net-to-gross ratio

would be 4 ,704 net square feet divided by 5 ,000 gross

square

feet, a building efficiency of 94 percent. If the building

were larger
or the walls thinner the efficiency would be even higher,
perhaps

95 percent. The “grossing factor”—the percentage difference

be

tween the net and gross square feet—in this case would be 5
or 6

percent (Fig. 7-25). In fact, most simple

warehouses will in

clude an office or two,

at least one restroom,

a janitor’s closet, some

office storage, a recep

tion area, and a short

hallway to connect

them to the ware

house. Interior parti

tions will be required

to create these separa

tions. As a result, the

expected e ffic ie n c y o f Figure 7-25 Basic Warehouse.

8 100’

Figure 7-26 Warehouse with Office Space.

1. Circulation 15-25%

2. Mechanical 05-10%

3. Walls, Partitions, Structure 07-10%

4. Toilets (public) 1.5-2.5%

5. Janitor Closets 0 .21.0%

6. Unassigned Storage 0,3=15% Total 30-50%

Figure 7-27 Unassigned Space Variations

Adapted from: (Pena et al., 1987), 109. Permission:

American In

stitute of Architects and HOK

Administration 55%

Student Center 60%

Science Building 60%

Dormitory 60%

Auditorium 60%

Museum 65%

Library 65%

Academic 65%

Physical Education 70%

Building Services 75%

Figure 7-28 Typical Building Efficiencies

Adapted from: (Pena et al., 1987), 110. Permission:

American In

stitute of Architects and HOK most simple ware houses

would be closer to 85 or 90 percent (Fig. 7-26). For most
building types, the efficiency is not nearly as high as
for a warehouse. Acad emic buildings, for in stance, will
often have an efficiency of be tween 60 and 70 per
cent, and this does not allow for spacious en tryway s,
corridors, or, especially, two- or three-story interior
spaces. Two-story spaces are less efficient than one-story
spaces. Not very surprising, perhaps, but of ten forgotten
by beginning programmers and designers, who try to ignore
that such spaces require higher walls, use space from the
level above, and often require greater circulation and
wall space at the upper level. Arizona State University,
for instance, re quires that all two-story volumes be
counted as one and one half times their actual as
signable square foot area to account for the added costs
related to the decrease in build ing efficiency. A major
public building such as a civic au ditorium or city hall
may have an efficiency as low as 50 percent to allow for
development of major circulation areas, multiple-story
halls, major atriums, or other similarly grand spaces.
The following charts indicate the probable range of
unassigned space and effi ciencies for various building
types (Figs. 7-27 and 7-28). It should be clear at this
point that the grossing factor is, in fact, an educated
guess STO R AG E O FFIC E SEC I CL RECP T 100’ o in

based on experience. It is of great importance to educate

the

client of its reality and importance. As a programmer, it

is bet

ter to err toward the less efficient so that the associated

costs

can be built into the preliminary cost analysis. Clearly,

the cost

of a building can vary 10 to 30 percent or even more based

on

unassigned space. It is better, therefore, to estimate on

the low

side of efficiency and try to determine the relative

importance or

priority of some program requirements, so that if something

must be eliminated or reduced in size to achieve a

satisfactory

design solution, no one will be needlessly surprised or the

de

sign quality unnecessarily compromised. Calculation of

efficiency during programming is rather simple:

net square feet divided by expected efficiency equals gross

square

feet: Net Square Feet _rf. .------------= Gross Square

Feet Efficiency Detailed discussions of this topic are
contained in Pena et al.
(1987) and Kumlin (1995). This author would recommend both

sources as essential reading to programming practitioners

who

need to be aware of the differing ways of counting

efficiency used

throughout the building industry.

7.9 Relationship M atrices and Diagrams • Relationship

Matrices • Relationship Diagrams Understanding
relationships is a very basic and important part

of architectural programming. There are at least three

distinct levels at which relationships

are important. The first is the relationship of activities

within an

organization. The second is the relationship of activities

to objects

or places. The third is the relationship between different

objects

and/or places. All three types of relationships are

important to

the architectural designer. They will be discussed briefly

before

showing how such relationships can be described through the

use

of matrices and diagrams. Does food preparation normally

have a close/essential rela

tionship with eating? What about eating with food

preparation?

Figure 7-29 Person Eating in Bed.

Credit: Carl Okazaki

Clw^JZA cntir

cm In most household situations, the obvious answer would

be “yes” to both questions. What about in a restaurant?
Or what about for a picnic? Or for vending machines? The
an swers to these questions are less clear. Does food
prepara tion have a close/essential re lationship with
sleeping or bathing? Probably not. What about breakfast
in bed? Some people look forward to this luxury. Some
hotels advertise it as a special service to at tract
visitors. People in hospi tals often eat in bed. However,
they usually do not eat while they sleep—unless they are
being fed intravenously. In every case there is a
different relationship between food preparation and the
point of consumption. The program mer must discover the
actual relationships and not make assumptions based on
limited past experience (Fig. 7-29). Maybe a better
question is: “Where are all the places that a person in
this organiza tion eats?” This would be the second
important level of re lationship that should be un
derstood by the designer—the relationship of activities to
objects or places. A particu larly good example of the im
portance of the relationship of activities to objects is
found in the kitchen, where most cooks like to have a
logical, efficient, and timesaving arrangement in or der
to conserve effort (Fig. 7-30). oh «[W v / a CwdVL OH A
IsOtffo'OH of MfAijtJt&troi

m n ^ j ACTIVITY FATTei^ - MfsAL fP£PAftVTVf4 dM

Figure 7-30 Plan of Kitchen Triangle.

Credit: See (Green e ta l 1975), 74. Permission: Michigan

State Housing Development Authority A final type of
relation

ship would be the relation

ship between the different

objects or places. Does the

dining room relate to the

kitchen? Does the kitchen

relate equally or identically

to the dining room? Does

the dining room relate to the

bedroom? Does the bed

room relate to the kitchen?

These rooms do or do not

relate to each other based on

the activities they contain. A

programmer can make rela

tionship diagrams by un

derstanding their individual

relationships (Fig. 7-31). Important relationships

between defined spaces or Figure 7-31 Kitchen Relationship

Diagram,

areas are initially shown on

brown sheets or grid paper during work sessions, as

described in

Chapter 6. However, it is the underlying activity to place

relation

ships that must be understood to define the space

relationships. In fact, the programmer needs to have a good
understanding of

all of the relationships between activities, objects, and

places in

order to know which activities and objects can and should

be sep

arated into distinct spaces or rooms, and which will work

better

in one common area. For example, the arguments continue be

tween the merits of open office arrangements and offices in

sepa

rate rooms. The fact is that some office activities can

occur in the

same space, while other activities must be separated to be

most
effective. What is the nature of separation needed? Visual?
Aural?

Olfactory? Thermal? Perhaps the secretary or even a whole

group

of secretaries and their furnishings and equipment need

only be

visually separated from the circulation space to avoid

distraction

by passersby. Someone who needs to concentrate on a

difficult mental task,

however, may need acoustical separation from everyone else,

to

be able “to hear oneself think!” An officer or manager who

deals

with personnel matters may need both visual and acoustical

sep

aration to provide a higher degree of privacy. Heat

generated by PREPARED FOODS ARE TAKEN TO THE DINNING ROOM,
BREAKFAST NOOK FAMILY ROOM,PATIOS AND DECKS FOR INFORMAL
TO FORMAL DINING FRESH FOOD AND SUPPLIES COME INTO THE
KITCHEN TO BE CLEANED AND STORED IN THE PANTRY AND
REFRIGERATOR DIRTY DINNERWARE AND LEFT OVER FOOD IS
RETURNED TO THE KITCHEN FOR CLEANING, DISPOSAL OR
RE-PROCESSING AND STORAGE TRASH AND GARBAGE ARE RETURNED
TO THE GARAGE TO BE TAKEN OUT TO THE ALLEY OR STREET FOR
PICK-UP DINING PATIOS & DECKS KITCHENPANTRY GARAGE
BREAKFAST- ' FAMILY . ^TArrkaJ f U| 'P t**h |c^ lA4FS

-rt

* JBer-TMtte. 4 v/iel* -z>elX?&z\ a W A • ^ HjRs/K^pe?

^rri^csome computing equipment or perhaps by groups of
peo ple in meetings may necessi tate separate spaces in
order to maintain adequate ther mal control. Noise
generated by copy machines, and the people that use them,
may dictate separation for acousti cal reasons. Whoever
decides spatial relationships must un derstand the
relationships of the activities and objects to be housed
in each of the spaces in order to make appropriate
decisions (Fig. 7-32).

Figure 7-32 Annotated Plan of an Office.

Credit: Arquitectura, 1990. Program for Tucson W ater
Eatside W ater Satellite Operations Fa

cility. Tucson, Arizona. Permission: Arquitectura, Ltd.

RELATIONSHIP MATRIX Gallery V Studio --------—-----Office X

) ) 4 \ ------- ----(oX °A #A Computer Storage Bathroom X y
' Mechanical / 0 Negative relationship O Positive
relationship none Relationship arbitrary

■ A Studio and Art Gallery Program Page 14 ■

I I

Figure 7-33 Simple Relationship Matrix.

Credit: Chris Barta, Kevin Camp, Dan Clavin, and Shauna

Herminghouse, 1992. A Program

fo r the Design o f an A rtis t's Studio and A rt Gallery.

College of A rch itecture, The University

of Arizona Relationship Matrices A system frequently used

to develop and show how vari ous spaces relate is the
rela tionship matrix. In this case, every identified
space is lo cated vertically along one side of the
matrix. Lines at a 45-degree angle to the end of each
identified space extend to provide one cell connect ing
each space to every other space. A simple distinguish
able code can be used to show the nature of the rela
tionship between the spaces (Fig. 7 -33). Preparation of
such a ma trix can be even more helpful if there are a
large number of individual spaces and/or complex
relationships. Each line of cells can be followed

to see how each space relates to every other

space. If large numbers of spaces have no es

sential relationship with most other spaces, the

matrix may reveal some important overall pat

terns of relationships when completed. For in

stance, logical departments or work units might

be revealed by obvious clusters of related

spaces or rooms. However, if the building has a

very large number of individual spaces, use of

the matrix can be mind boggling. It may require

following along with a finger or ruler so as not

to jump from one cell to another, and the over

all effect can be disorienting, owing to the large

number of relationships shown (Figs. 7 -3 4 and

7 -3 5 ). The author has found that most clients find

this type of relationship indicator to be confus

ing. These indicators actually work best if de

veloped in the programmer’s office as a

systematic way of making certain that every

possible spatial relationship has been consid

ered. The matrices can then be useful as a step

toward developing individual space relationship

diagrams that visually show how each space re

lates to other spaces.

Relationship Diagrams

The basic relationship diagram employs small cir

cles or “bubbles,” each of which contains the

name of one of the identified spaces. The bubble

representing the space under consideration is

drawn first, then other spaces relating to it are

indicated in additional bubbles placed near the

first bubble. Typically, only those spaces that

have an important relationship to the first space

are included in the diagram. For instance, in a

house, the living room may not have an essential

relationship to the sleeping areas, kitchen, or

garage, so these spaces would not be included in

a diagram showing relationships to the living Figure 7-34

Simple Relationship Matrix. Credit: Fourth Year Design
Studio w ith Professor Hersh berger, 1986. Gilbert M
unicipa l Complex Program. Gilbert, Arizona. School of
Architecture, Arizona State University Figure 7-35 Complex
Relationship Matrix. Credit: Fourth Year Design Studio w
ith Professor Hersh berger, 1986. Gilbert M unicipa l
Complex Program. Gilbert, Arizona. School of Architecture,
Arizona State University Strong connection Negative
connection Close or accessible Reception—............... —
Offices.............................. Ballroom ........ --
Cafeteria.................. -----Kitchen —...............
Recreation Room....... Crafts Room.............. —Exterior
Area--............... Rest Rooms.....................
Storage/Maintenance-— Nurses Station-----------Staff Rest
Rooms........... Computer Room----...... ADMINISTRATIVE
:SERVICES MATRIX O POSITIVE □ NEUTRAL • NEGATIVE room
(Fig. 7-36). Each of the non-dimensional bubbles
represents a space identified in the pro gram. The center
bubble is the one to which the other spaces are being
related. The relationships between the spaces are
indicated by simple lines. They could also be shown with
different line weights, colors, or other characteristics
to indicate the nature of the relationships. This more
elaborate system works well for buildings for which there
may be a number of different kinds of relationships to
express. The lower diagram shows two types of
relationships (Fig. 7-37). For simple buildings, it may
also be possible to prepare a diagram which, like the
relationship ma trix, shows the interrelationships of all
interior and exterior spaces (Fig. 7-38). However, as the
building becomes more com plex, it is difficult to prepare
such a diagram with-

Figure7-36 Simple Relationship Diagram. . . , . . . . , .

out implying some relationships that may not exist. In this
case, it may be necessary to relate only the established
major zones of the building (Figs. 7-39). When the bubbles
are kept separate, heavy-, medium-, and light-weight
lines can be used as a code to indicate strong, mod
erate, and weak relationships. Or the code can be more
specific and even indicate visual, audi tory, olfactory,
and thermal rela tionships. The code should be clearly
indicated and relate to what the designer needs to know to
provide an adequate en vironment for the activities to be
accommodated. For purposes of architectural

Figure 7-37 Simple Relationship Diagram. programming

relationship dis

credit: Tim Bjella, Randy Jones, and Neil Urban, 1986.

Program for the N ew Arch itec- 8 r a m S S O U e e P *
V e r y S i m p e

ture Building. Permission: School of Architecture, Arizona

State University SO a s not to COrnUSe real relationPATIO
LIVING DINING ENTRY INTERIOR w^ gPACRB AND SHOP 'cO U M Q M
A S > VA VHDUE> AND ^ QAIlggY> MEDIA SERVICES ^mADIKG
DOCfttX AND ; sQUTOOOR Y A K j}> , INDIRECT ADJACENT
DESKIN STUDK)S

ships with circumstantial ones.

This can be ensured if the initial

diagrams are developed for one

space at a time and do not go be

yond its relationships with other

spaces. In other words, the pro

grammer should not begin with

one large diagram in which every

activity/space is related to every

other activity. Unlike the relation

ship matrix, this will distort rela

tionships, because bubbles placed

in close proximity to other bub

bles may appear to be more re

lated when they actually are only

artifacts of a spatially organized

diagramming system (Fig. 7-40). Figure 7-38 Overall

Relationship Diagram. Credit: Sing Kuai Ng, 1987. Program
fo ra Blue Print Shop. Permission: School of Archi
tecture, Arizona State University

Figure 7-39 Zoning Diagram.

Credit: Anderson DeBartolo Pan, Inc, 1986. City o f Tucson

M ain Library Program.

Tucson, Arizona. Permission: ADP Marshall Figure 7-40

Complex Relationship Diagram. Credit: Mark Poppe, Dave
Truman, and Ed Binkley, 1985. A r ch itectu ra l Program
fo r a Real Estate Office. Permission: School of
Architecture, Arizona State University PRINTING AREA
STORAGE j ’ DISPLAY AND SELLING AREA CUSTOMER SERVICE
PARKING ENTRY DIRECT INDIRECT pm jc. 5WP ACCESS pueac £cce&
* S f& IB M U tC E s e h u /c e s L0AOM6AteeAm n u ew & i
0O ILD IH 6-1 SUPPCW A fAWNq (WWriHq) + fzc&r. 4 HMqp.
[A&,. coqpf (W f dfeKTFf ( loMM4£ MrotL.jl rtauj (P) j
rib. frULuF&M With a large or highly inter related
facility, there could be so many overlapping lines be
tween related bubbles that the diagram would become very
complex and confusing. Efforts to reorganize the diagram
to make it less confusing could embody preconceptions
about the final design. Thus, it may be more helpful to
the designer to use a separate diagram for each space,
department, or zone. Sometimes the use of a chart is more
effective in con veying complex zoning infor mation (Fig.
7-41). It is actually quite difficult to devise a clear
and easily un derstood system of diagrams, codes, and
charts to explain all the kinds of relationships which
should be accommo dated in design. Thus, a combi nation
of diagrams, charts, and text is often required. Basic
proximate relations can be il lustrated in a relationship
dia gram and the specific types of sensory separations or
connec tions can be covered beneath the diagram using
short de scriptive phrases. The programmer should avoid
initiating diagrams that have design preconceptions built
into them. However, if a client group insists that a
particular design idea or approach is mandatory, it
certainly makes sense to communicate this to the designer,
so that he/she will at least consider the preconception
during design. The designer always has the prerogative of
challenging such precon ceptions and of trying to convince
the client to accept a different design resolution.
LOCATION CRITERIA

FIRST LEVEL

space entry street campus service daylight view outdoor

hours

Atrium • • • • 24

Hearth • • • o o 24

Copy Center O • o 14

Newsstand • 14

Student Lockers o • X X 24

Student Mailboxes o • • 24

Super Bathrooms X X 24

Student Development O • • • 8

Center Management o • • • 14

Facilities/Event Planning o • • • 8

CAC Desk • o 14

Collegium 5 & 6 o • • • o 24

Conversation Nooks • • • • o 2 4

Center for Leadership o o • o 8

Pathways & Wellness Ctr o o • o 8

Meeting Room o o o o 24

Poster Area o o o 24

ASSU O o • • 24

Student Clubs o o o o 24

Vending Machine Area • 24

Code Hours

• = Extremely Important 8 = 8 am - 5 pm
O = Very Important 14 = 8 am -10 pm

o = Important 24 = all day = No Relationship

X = Negative Relationship

Figure 7-41 Locational Criteria.

Credit and Permission: W alter Moleski, ERG, 1998, Spatial

Organization, University Center,

Seattle University It may be possible and

desirable to develop rela

tionship diagrams in

which whole groups of

spaces are combined, as

with the distinct depart

ments of a large organiza

tion. It is important,

however, not to make

such diagrams until it is

clear from earlier rela

tionship analysis that the

departments or activities

actually exist and should

be maintained as distinct

spatial units. For in

stance, every organiza

tional department of a

major office building may

indicate a need for good

access to photocopying

equipment. Does this

mean that every depart

ment will need to have its

own reproduction space,

or that a single reproduc

tion space should be con

veniently located to all

departments? A good un

derstanding of the orga

nization is necessary to

make such decisions. Figure 7-42 Zoning Relationship

Diagram.

Similarly w o u l d a client Credit: Corky Poster, W.

Kirby Lockard, Chris Evans, Kim Kuykendall, Scott Pask, and
Donna Sink, 1988. . . 9 . University of Arizona Poetry
Center, Building Program and Site analysis. Permission: A
rchitecture want to organize the ad- Laboratory# |nc.

ministrative offices in a

separate department, or

distribute these offices among the various departments?

Only when

activity areas or organizational units are known to be

spatially dis

tinct should overall diagrams be utilized. When such

information is

known, diagrams can be useful in revealing the overall

conceptual

organization appropriate for design (Fig. 7-42). y

fimo&cks\ r^iL~ft » i iT i A^ r y j 1 >s^ ' ( X / /
QJT&zfZ. *7* / ( 'S&C& V ^x11/ / \ 7 1 7 J Performance
Data Space:| Function! Net area: Gallery I Display of Art
I 500 sqf. Relationships: Activities! Occupancy Public
view of art 10 Equipment: Movable partitions Accent
lighting General lighting Critical Factors:

A Studio and Art Gallery Program Must be flexible Issue of

security; needs a view from the gallery 3' to 6' space from
art needed for viewing it 10' minimum ceiling height Page
16

Figure 7-43 Space Program Sheet.

Credit: Chris Barta, Kevin Camp, Dan Clavin, and Shauna

Herminghouse, 1992. A Program for the

Design o f an Artists Studio and A rt Gallery. College of

Architecture, The University of Arizona

O Net SF. , Area Ife'x 18 2&a a f Oite? SUPERINTENDENTS

OFFICE

• Fxiction la r g a e n o u g h I P ac.- •'*"0 tm A

in«ortc Ion 4 _____ __ a a iii/^ ll a a 3 t o 4 Wwc •
Corrmnication :_yaa._ . •Furniture/Equipment l IJCfl f i l
e c a b in e t c r e d e n z a b u l le t in b o a r d

•O ccipants 1 a d m ln la tra (\) c o m p u t e r w o r

k s t a t io n w o rk. t a b le 1(4) chaIra •E lectrical
1 ‘

3.-4 g u e s t

• Environment

carpeting J_ . J_ 10-If. c o a t s . s u p p lie s .

and/cx.___ 2tfl4 ............... l o c k a b le . •S iru c
tira l

a<30Cy_UiaUa_llllth_celLInsula t Ion

o^ci s u s p e n d e d a c o u s t i c a l____

f lo o r . . . . . .___________________

c a l l In g a --------------------------------— I n te r
io r v ie w s t o o t h e r ____

o f f i c e Ar<~A* n a t u r a l l i g h t ___ •
Pkrrtoing masonry bearing malls _ #lnter-rdationship
Dia^am

dtOOr t o c o r r i d o r 4 e x t e r i o r

p iQ C L fo r “ #H V A C " U V A C - c l im a t e c o n
t r o l 3 g u ls h e r * t c a b in e t * xm o lte d e t
e c t o r * I met p l p g s p r in k le r s y s t e m
______

Figure 7-44 Space Program Sheet.

Credit: Arquitectura, 1990. Program for Tucson Water

Eastside Water Satellite Operations Facility.

Tucson, Arizona. Permission: Arquitectura Ltd. 7.10 Space

Program Sheets A very effective way to il lustrate
specific design re quirements for a building is to
include a space pro gram sheet for each identi fied
space. These sheets typically include state ments
regarding the pur pose, the square foot allocations, and
the impor tant relationships for each space. They also
include information about the types and numbers of peo
ple who will use the space; the activities in which
people will be en gaged at various times of the day,
week, and year; furnishing and equipment needs; and any
other re quirements that can help the designer make
decisions about configuration and lay out of the
particular space. Figures 7-43 through 7-46 show space
program sheets from several programming firm and student
projects. As can be seen from the previous illustrations,
space program sheets can have a great deal of variability
in format and content. But their purpose remains es
sentially the same—to pro vide a complete miniature
program for the space cov ered. They are usually preStudio
O tf .c e //) ) ’ Ga,lery /M echJ 0 * ^ S . Computdr

Figure 7-45 Space Program Sheet.

Credit: Kevin Burson and Nicole Halfen, Arch. 202, Section

1, 1998.

Catalina United M ethodist Day School program. College of A

rch itec

ture, The University of Arizona Figure 7-46 Space Program

Sheet. Credit: M ichael Feerer, 1977. Family Services Ward
Environmental/Ar chitectural Programming for Atascadero
State Mental Hospital, A tas cadero, California.
Permission: Michael Feerer
pared in the programmer’s office, based on all of the
information

gathering activities including the client/user work

sessions. The

sheets are then included in the final draft copy of the

program

document, which can be circulated throughout the client’s

orga

nization for review, comment, and correction. The space

program

sheets will be of greatest interest to those most likely to

use the

space, and will be subject to their scrutiny. The results

of review

can be an important fine tuning of project requirements,

which

may save considerable designer time and energy. It is

important

that the designer know about the particular requirements of

each

space even during schematic design. A careful programming

effort

is likely to turn up all of the needed information. B

ivkonm ^/B ehavio ral Intent Design Response : I S g S a s
a r SPACE: 1 ACTIVITY LEVEL: 1 Courtyard/Commons Hiqh src
500" ™ rfa" 5> «P<*ia ll3' the floor. ,re plastered over
and blended into surrounding 1 y are soft, warm and
comfortable to support different surfaces. Access fs
through a non-lockabte door. Users Activities FUNCTION: I
OCCUPANCY: I .. r H S r s T " ----Provide an indoor
activity 45 )- ■ space (commons) and an Surfaces Ambient
Environment (courtyard). A R E A " rioiT«.Hng S S s ^ it^
r r lr 'M L 5000 sq.ft. Furnishings Code and Agency
Requirements EQUIPMENT: I SPATIAL • Outdoor Games such as
Special Requirements & Equipmen Safety and Security —r Z T
T . , , foursquare. R E L A T I O N S H I P S ! •
Child-sized water fountain M 9 ^!i!d j!sn!?r4('d!n' (
Cafeteria >.-------------• Piano \. J f Classes 7 • Sound
sysytem V A J * Stage ( Child ^ \ • Stage Lighting — ■
J L — „ - , .... \ J . (a RdUh ) Location Adjacencies
Potential Design Configurations $T?oo“ m 7 ^ 7 7 ^ cm iiC
A L ^ W w w i F l ^ T / commons ) FACTORS: JL L A J 5
s r l n r i U £ 3 '7-1 I 3 V J L U a L I I —ii *r L
j t * c t t a o J large multi^ X / i W h 7 X 7 7 ■
© PURPOSE / Teach \ ROOM / u . u Lounae J ( Play \
f Kl,chen Areas J m W ^ ^ No Arrow Strona Weak neoative
After receiving the marked-up space program sheets, it may
be necessary to have another work session to sort out the
importance of various suggestions. Here again the decision
makers within the client’s organization will need to
listen to the arguments for addi tional space, equipment,
furnishings, and the like from various di visions of the
organization and decide what they can support or not
support, based on the budget and various other important
is sues set forth in the program.

Fee-b Design ‘Services ng 4 Cored^ ruchon A d d ifkn a l

Services ,*<2bibursc*ble s>

Conduction Si He Development £>ui Id irg 4 F u rn fd rg

s 7.11 budget and Cost Analysis • Owner’s Budget •
Construction Costs • Project Costs • Life Cycle Costs
Owner's Budget If the construction budget is fixed, this
should be stated clearly in the program. If it can vary
depending on the quality and charac ter of the design,
this should also be made known. If market con ditions or
specifics of financing are crucial areas of concern, then
these should be covered in the program or in a companion
docu ment prepared by specialists in these areas. This
should be an in tegral part of programming, so that the
stated requirements will be for a facility that the client
can afford to build. It makes little sense to prepare a
program ignor ing the realities of the client’s bud get.
The budget will almost always be an area of client concern
and will be included as a primary value area (Fig. 7-47).

Preliminary Opinhn of Ffcbuble Corr r^ucHon Cast 2.4,000

1,000 TS/frOO I 6>, %Oo *>00,000 <000,000 4 l<p, 400
total fee^

Cor>ducfbn &tfc^eH fo r D ie

4 0,000 i> ? & o ,o c c > *&aco per «=^Lwre focfr :

Afpioximahely 4 o f c o ^ ro o rc X ) r h phase

Figure 7-47 Budget Card from Matrix.

Credit: Arquitectura, 1988. Pre-Design Workbook, Verde

Meadows Recreation

Center. Tucson, Arizona. Permission: Arquitectura Ltd.

Construction Costs Clients generally have a good idea of
what they can afford to spend on the construction of a new
facility. If not, they will develop this informa tion
early in the programming process as they begin to realize
the

financial implications of what they are trying to achieve.

What

clients likely will not understand is how much building

they can

get for their money. If they are interested in building a

new house,

they probably have been talking with others who have built
new

houses in recent years, or have been looking at prices of

developer

houses in their locality. Unfortunately, this cost

information may

have little relationship with the actual cost of

constructing a new,

custom-designed house. The owner’s figures for custom

housing

may be several years out-of-date and not account for

inflation,

while the figures for developer housing will reflect cost

savings at

tributable to size of operation. In the Tucson metropolitan

area,

for instance, most developer houses were being built for

between

$ 6 0 and $ 7 0 per square foot in

1 99 5 , but custom houses by

architects were running from

$ 9 0 to over $ 2 0 0 per square

foot, depending on the quality

of materials and treatments

specified. The costs of custom

houses also appeared to be in

flating at a greater rate than de

veloper housing. Similarly,

speculative industrial buildings

could not exceed $25 to $ 30

per square foot, or they would

price themselves out of the

market. It was possible to use

only a few highly competitive

building systems and configura

tions to keep the cost in this

range. The same financial real

ity impacts nearly every kind of

building construction activity. Construction cost data for

buildings in the United States is

readily available for most build

ing types. The current versions

of the Means Square Foot Costs

and Marshall Valuation Service

are good examples (Fig. 7-48

through 7-50). These sources Figure 7-48 Means Construction

Cost Sheet C O M M E R C IA L /I N D U S T R IA L IN S T
IT U T IO N A L C o m m o n a d d i t iv e s CABINETS,
Base, door wits, metal LF. Drawer jnits LF. Tall storage
cabinets, open LF, WHk doors LF. Wall, metal 121/2* deep,
open LF. With doors LF. CAB REIS Hardwood Each COUNTERTOPS,
not Incl. base cabinets, add proat S.F. Stainless steel
S.F. FUME HOOD, Not Ind. ductwork LF. Ductwork Hood
GLASSWARE WASHER, Distilled water rinse SEATING Auditorium
chair, all veneer Each Veneer back, padded seat Each
Upholstered, spring seat Each Classroom, movable chair &
desk Set Lecture hall, pedestal type_______________Each Use
Location Factors in Reference Section 785-1700 1575-6025
5225 -19,500 Da script Ian Unit SCost SAFETY EQUIPMENT, Eye
wash, hand held Each 360 Delugs shower Each 193 SINK, One
piece plastic Flask wish, trsastending Each 1500 TABLES,
add resist top, drawers LF. 124 TITRATION UNIT, Four 2000
ml reservoirs Each 5550 ALTERNATE PRICING METHOD: As % of
lab furniture PLUMBING, final connections, simple 10%
Moderately corr.plot 15% Complei 20% Me 150 College,
Laboratory Cort» per «qunra foot af floor
araa___________________________________________ ■ SJ. Area
12000 20000 2*000 37000 48000 87000 68000 MOOO 98000
EXTERIOR W A L L

Commercial/Industrial/

Institutional Section

Table of Contents

Table No. Page

Introduction

Examples

Example 1 ................................................
67

Example 2 .......... 69

Building Types

M.010 Apartment, 1-3 Story..................... 72

M.020 Apartment, 4-7 Story..................... 74

M.030 Apartment, 8-24 Story.................. 76

M.040 Auditorium..................................... 78

M.050 Bank............................................... 80

M.Of 0 Bowling .Alley............................... 82

M.070 Bus Terminal................................. 84

M.080 Car Wash...................................... 86

M.090 Church.......................................... 88

M 100 Club, Country............................... 90

M i l 0 Club, Social................................... 92

M.120 College, Classroom....................... 94

M l 30 College, Dorm., 2-3 Story 96

M.F0 College, Dorm., 4-8 Story 98

M.150 College, Laboratory..................... 100

M.160 College, Student Union.............. 102

M.170 Community Center..................... 104

M.1B0 Courthouse, 1 Story................... 106

M.190 Courthouse, 2-3 Story............... 108

M.200 Factory. 1 Story.......................... 110 Table

No. P age M.210 Factory, 3 stoiy...................... 112
M.220 Fire Station, 1 Story.............. 114 M.230 Fire
Station, 2 Story.............. 116 M.240
Fraternity/Sorority House . . . . 118 M.250 Funeral
Home........................ 120 M.260 Garage, Auto
Sales................. 122 M.270 Garage,
Parking.................... 124 M.280 Garage, Underground
Park... 126 M 290 Garage, Repair...................... 128
M 300 Garage, Service Station........ . . . 130 M.310
Gvmnasium........................... . 132 M 320 Hangar,
Aircraft.................... . .. 134 M.330 Hospital, 2-3
Story................. ... 136 M.340 Hospital, 4-8
Story................. ... 138 M.350 Hotel, 4-7
Story.................... 140 M.360 Hotel, 8-24
Story................... 142 M 370 Ja
il......................................... 144 M.380
Laundromat........................... 146 M.390
Library................................... .. 148 M.400
Medical Office, 1 Story.......... 150 M 410 Medical Office,
2 Story.......... , 1 5 2 M.420 Motel, 1
Story....................... 154 M.430 Motel, 2-3
Story................... ... 156 M.440 Movie
Theatre...................... 158 M.450 Nursing
Home..................... 160 M.460 Office, 2-4
Story................... 162 Table No. Page M.470 Office,
5-10 Story........................ 164 M.480 Office, 11-20
Story...................... 166 M.490 Police
Station............................. 168 M.500 Post
Office.................................. 170 M.510
Racquetball Court...................... 172 M.520
Religious Education................... 174 M.530
Restaurant.................................. 176 M.540
Restaurant, Fast Food................. 178 M.550 Rink,
Hockey/Indoor Soccer 180 M.560 School,
Elementary..................... 182 M.570 School, High, 2-3
Story 184 M.580 School, Jr. High, 2-3 Story 186 M.590
School, Vocational...................... 188 M.600 Store,
Convenience..................... 190 M.610 Store,
Department, 1 Story 192 M.620 Store, Department, 3 Story
194 M,630 Store, Retail.................................
196 M.640 Supermarket............................... 198
M.650 Swimming Pod, Enclosed 200 M.660 Telephone
Exchange................. 202 M.670 Town Hall, 1
Stoty..................... 204 M.680 Town Hall, 2-3
Story................. 206 M.690
Warehouse.................................. 208 M.700
Warehouse, Mini........................ 210 Depreciation
212

Figure 7-49 Means Construction Cost Contents.

From Means Square Foot Costs 1996. Copyright R.S. Means

Co., Inc., Kingston, MA,

617-585-7880, all rights reserved. COLLEGE CLASSROOMS

(CALCULATOR METHOD'.

Figure 7-50 Marshall Evaluator Cost Data Sheet.

Credit: Marshall & Swift, L.P., 1995. Marshall Valuation

Sen/ice. Los Angeles, California:

Marshall & Swift, L.P. Permission: Marshall & Swift, L.P.

can be very useful in architectural programming because
they con tain average costs for various building types.
The most useful ones for programming separate the costs
into high, medium, and low averages; show the kinds of
construction systems that lead to these various averages;
and pro vide factors to modify the costs for particular
regions of the coun try. The programmer can use this
information to project a probable range of construction
costs for the facility even before any design studies
have begun, based on the projected square footage and de
sired quality of materials and sys tems. The ability to do
this with reasonable accuracy is very im portant. If it
appears that the costs will be too high, then the program
can be modified in terms of size, quality, or both. It is
better to confront bud getary problems at this early
stage of the building development process than to keep the
client happy for the moment, suggesting that he/she can
have everything desired, when, in fact, it is evi dent
that the budget is not suffi cient to construct the
building. When this happens no one wins. The programmer
appears incom petent, the designer appears inad equate,
and the owner, belatedly, has to find additional money or
reevaluate the program and de cide which requirements are
re ally important. This is a difficult

CLASS TYPE EXTEHIOR WALLS INTERIOR FINISH A lJ ^K H A N io

u I^ HEAT SqM CaFt. Sq Ft

' E<onlte-1 ' S y . D»U bnck. m«tinna N^aii. tnivntv furwi

Bra da-.voo™ >»ht"° )^ )|na Hoi «"d c«»V S' <SC 50 TT35
413* '6

£ ■tfwtf.M.o.njm.rul » F ^ ^
I'am'n^oZrT)---------------------SdTTd------EH-------«5TT

_______ °W1”_____ W l iwn ^ ‘_______ <»**/****<>ni.tf-ooi

' ' plui0x; ^ *N______ ,i« ,20f»<ii^ ^ '___

g ^ ru ! 7 di^Mi rex, in.ui— ^ — iy ^ a S ) —

oiTT3----t v 8^ 35“ TToefcTi Swml h«in«. fx. bnc*. mww ^
Roiirfl^ hAsd ' iS2Ci 'O’ ' IC'oa _pjnolt. Wo. nghiy
atnin-+iA&_______ cofpot and —y c^DJing Post pAnrbtng »*ty
ito**})_______________ _ ° ^ Woe*, or concrete. iKtme
turn____________ nrg»ooO_____________ ^ _^_________»••
:*q*«3\_____________* _ _____ E ^ i SW 01 b t& ©i H on*
«oi *"d ch-i»o i~ii: O', ’(j ’■"» i778*7" Omri S*««i
o'qMjmtfsmoind(Oisit F'ait* ordrywall. jcouMicMe
Goodru***©** ©o«J ^ n v /)• 7 <r 7?t,o

p, ____ frth ywtif. S'ifci, bit stucco vmyi oon»poKiiHyi

pKiubng.***** <w<¥*f8______ >»
;ron«di______________________
“ Average Wood u*n*'<* m oclurrnj good Pio»le« v G7yNa7
aoousiK trie AJcw*iM«> i»gmng .irx) puit*fwi*o Heal frn-p
*,'/ 1«i A <;*ti

'" (I- . It IWLT1STOWT BUfLDH#GS ^ ^ ^ . Ol* -1 . . .

SfKr**l'- *y*kw. are n0i included Go*< %h0«.W be added

**o«r. P,iflc JO BALCONIES ^

and sometimes bitter and costly

process which may include costs

for extensive redesign and even

of litigation to establish who is

responsible for underestimating

costs. All such situations can be

avoided by early recognition and

resolution of potential bud

getary problems). The LMRector Corporation

publishes a bimonthly maga

zine, Design Cost Data, that

contains similar current infor

mation (Fig. 7-51). Sources such as the ones dis

cussed above can be obtained in

some public and university li

braries, and in the offices of ar

chitects, contractors, and real

estate professionals who use

them on a daily basis to estimate

the costs of projects. They

should be obtained and utilized

by the architectural programmer

to estimate the range of possible

costs for the buildings being

programmed. ARCHITECT FILE UNDER HOLABIRD 8 ROOT

EDUCATIONAL 300 West Adams Street Palos H is , 1 liners
ChicAfiO.IL 60606-5174 CONTRACTOR W.E. O Nell Construction
Co. 2751 N Cyttoum Avenue Chicago. IL 60619 STRUCTURAL H
olablrd A Root 300 West Adame Street Chicago, IL
60606-5174 ELSCTRICAL HoiaWrd 8 Root 300 West Adams Street
Chicago. IL 60606-SI74 MECHANICAL Molebird A R oot 300
West Adams Street Chicago. IL 60006-5 ^74 LANDSCAPE
ARCHITECT Gary R. W eber Associates 615 West Front Street
Whouton. IL 60167 ACOUSTICAL CONSULTANT Verges Acoustics
5209 Lae Avenue Downers Grove. IL 60515 GENERAL
DESCRIPTION Sfft: HfA. NUMBER OF BUUXNaS: Ont. 600 sent «r
o rt*ag« « 150- svsge txsck box theater sesteg cssecty.
311 •*#“* Onvooms at 32 m ts , on* c lit t oor at 59 t t
t n BUtLDING SUES: 8asotro"t «vcl ' 400. trr . HOOT.
42.511; second floor. 30.196: oentheuse. 4 000; total.
S4U07 jtq.jar* BLNLDMG HEIGHT: Base*'"*. 11; NfSt Moor. 1 6
;record *«or. IS. I * to w . Ti'2’ ; penthouse. 18 4’-
total. 75T BASIC CONSTRUCTION TYPC: FOUNDATION: Coreets
spread footings. core#*# ’ouftdsfor w»aa EXTERIOR WALLS:
Prmc*%t ooncrete. brick. cvrtairwaM ROOF: Smote PV
membrane. FLOORS: Taaazio. glass ceramic mosaic tic. wood.
VCT. carpet. INTERIOR WALLS: DtywM. CM J. carannc a « FINE
& PERFORMING ARTS CENTER, MORAINE VALLEY COMMUNITY COLLEGE
Date Bid; Mar 1992* • Construction Period: Apr 1992 to Dec
1993 • Total Square Feet: 84,107 SPECIFICATIONS Bciwts A
c<rw«atc*&. C.S.L Dtvlsrort* (1 through IS) COST % OF COST
SQ.FT COST BfOOING REQUIREMENTS M t? » 0M 1.13 1. GENERAL
REQUIREMENTS x c .m c n ? ? ? 1.165,723 10.42 13.86 1
Ato.TSR i??& 1701 * MASONRY 1.030581 3,21 1225 5 MFTAi.S 1
.1 M IN 13 59 1400 8. WOOD A PLASTICS 229.740 206 2L73 f.
THERMAL S MOtST. PROTECT sn .78* ISO 204 8 QOO“ S4WHDOVYS
863.728 7.72 10.27 9 FINISHES 762227 572 8.94 10
SPECIALTIES _ _ _ 11. EQUIPMENT S94.3*3 531 7.07 12
FURNISHING 13. SP£C!AtCONSTRUCTIONS 14. CONVEYING 0.65 1.13
IS. MCCKANCAl 2.831 202 1334 2653 15. aCCTRICAt t..3&4.«03
12 <32 >538 TOTAL BUSLOING COST T1.1fS.0i0 100% S193.69 t.
CLfiS^ . 5 SLuCUr* ff«*rtng. ! 2 SITE W0R< 47'. \ ' 7 j
IANOSC APIMO A OEFStTE WORK 11 *0 2 7 ; TOTAL PR0JGCTCOST
11.775.294 taofrg. root 19. i Uetal deots 4 frames. spfroai
t)oo*s ontMwees 8 etonefrem . nft:*! mndowi. bardwar*. 1 u
rn a sypjum bo»?o m , » rr*»o, secusvs* trawrwftt.
»a*5«tioon«e c&ro&t »*»covehn$i. 2 Oewntwinf. sxc**al>«n
sjpcob j/sttms. par A surfeorq, jaw9>-*8a a a tanascvpmg
________ UPDATED ESTIMATE TO JANUARY 1997 3152 65 PER
SQUARE FOOT •V. th*n> NJ f«Kk*scM PI*. (. jm . <428 f t* .
X. Mir. *»2; K * . X M»> Figure 7-51 LMRector Design Cost
Data Sheet. Credit: LMRector Corporation. Jan/Feb 1997.
Design Cost Data. Volume 41, Number 1. Permission:
LMRector Corporation.

Project Costs

Many owners and architects

get into trouble by thinking that

the construction cost is the bot

tom line for a building project.

In reality there are other costs which increase the overall

or

project budget well beyond the construction cost. These

costs

include the cost of the land, taxes, and debt retirement

during

construction, and fees for architectural programming,

financial fea

sibility studies, architectural and engineering services,

governmen

tal approvals, and permits. They also include costs for

site surveys

and soils tests, archeological surveys where required,

landscape and interior design services, site and off-site
develop ment, moveable furnishings and equipment,
additional staff to monitor the project, and the
financing costs to secure a mortgage. These and all other
costs associated with the project can add up to an amount
substantially greater than the construction cost. They
must be factored into the cost picture, or the client
could end up with a project

Figure 7-52 Project Cost Estimating Categories costing well

beyond the

Adapted from: (Pena et al., 1987), 115. Permission:

American Institute of Architects and HOK available funds It
is neces sary, therefore, to include all such costs in
the archi tectural program. If the to tal project cost
exceeds the funds available, it will be necessary to
reassess the program to de termine what can be reduced to
bring the project within budget. A project cost estimate
can be developed using the categories shown in Fig. 7-52.
The question, then, is how does the programmer determine
each of the above costs? It is not simple or automatic.
Some of the cost figures are contained in the
aforementioned estimating guides and in the R. S. Means
Company’s Means Estimating Handbook (1990). Others can be
found in Pena et al.’s book Prob lem Seeking (1987) and
Kumlin’s book Architectural Programming (1995). Most other
books on construction cost estimating contain the more
detailed estimating done by contractors and are not us
able at this early stage of the project. It is advisable to
provide a range of estimated costs because many of the
areas of cost are not known at this early stage of a
project. The architect/engineer fees may not have been
estab lished. The building configuration, materials, and
systems have not been established. Where the building is
sited and how it is configured will have a major impact on
site development costs. Costs of fixed and moveable
equipment vary considerably based on quality and quantity
of items purchased. If the site has not al

• Building Cost (gross sq. ft. ¥ sq. ft. cost)

• Fixed Equipment (5% to 25% of A)

• Site Development (5% to 25% of A)

• Total Construction Cost (A + B + C)

• Site Acquisition/Preparation (check with

appraiser/contractor)

• Moveable Equipment (5% to 25% of A)

• Professional Fees (5% to 15% of D)

• Contingencies (5% to 15% of D)

• Administrative Costs (1% to 10% of D)

• Total Project Cost (Add D through J)

ready been acquired, only local realtors and

appraisers will be able to predict the cost of

acquisition. Even then, a property owner may

want considerably more (or less) than market

value for the desired land parcel. Administra

tive costs, while normally one to two percent

of the cost of the project, may reach as high as

15 percent in some institutional settings where

elaborate facilities planning, construction, and

management programs are partially supported

by building projects. The percentage factors for site

development,

equipment and furnishings, architectural fees,

and contingency are likely to vary from one lo

cality to another, with the size of the site, from

one building type to another, and from one ar

chitect to another. At the programming stage it

is possible at least to develop a realistic range

of these costs (Fig. 7-53). The following is an estimate

prepared during programming

for a small high-bay workshop

addition to the College of Archi

tecture at The University of Ari

zona utilizing the above system

of cost estimating. Note the con

siderable differences between the

low, medium, and high estimates

(Fig. 7 -54). Providing for a range of costs

will allow the client to set the

project budget at the level

needed to obtain the quality of

building materials, systems, site

development, furnishings, and

equipment desired. It is very im

portant that the cost estimate be

realistic, and especially not un

reasonably low, so that the de

signer can produce a design of

suitable quality within the bud

get. In this regard, the program Low Med High A. Building

Cost B. Fixed Equipment C. Site Development — — — D.
Construction Cost (A+B+C) — — — E. Site Costs — — — F.
Moveable Equipment G. Professional Fees H. Contingencies J.
Administrative Costs — — — K. Total Project Cost
(D+E+F+G+H+J) Figure 7-53 Project Cost Estimating Form
Adapted from: (Pena et al., 1987), 115. Permission:
American In stitute of Architects and HOK B U I L D I N G
S Q U A R E F O O T A G E Net Square Footage = 6,235 95%
Efficient Gross Square Footage = 6,547 LOW AVERAGE M E D
A V E R A G E H IG H A V E R A G E Building Cost $229,145
$294,615 $392,820 Fixed Equipment 5% $11,457 6% $17,677 7%
$27,497 Site Development 5% $11,457 10% $29,462 20% $78,564
Total Construction $252,059 $341,754 $498,881 Movable
Equipment 10% $22,915 10% $29,462 10% $39,282 Professional
Fees 8% $20,165 10% $34,175 12% $59,866 Contingencies 5%
$12,646 10% $34,175 15% $74,832 Administrative Costs 1%
$2,521 2% $6,835 3% $14,966 T o t a l B u d g e t R e q u
ir e d $310,306 $446,401 $687,827 Figure 7-54 Small Project
Cost Estimate.

4 ] 2 A rch itec tura l Programming and Predesign Manager

might state some caveats explaining that actual de sign
configuration, build ing efficiency, material and system
selection, inflation, and the like will have a sig
nificant impact on costs, so that the final costs to build
the facility may differ from the estimate pro vided in
the program doc ument. A contingency allowance of 5 to 10
per cent of the construction estimate is also advisable
and usual in most sophis ticated programming doc uments
to account for unexpected cost increases (Fig. 7-55). The
ranges for construc tion costs can be found in the Means
and Marshall estimating literature. The estimates for the
other items are gener ally based on firm experience. In
this text we will use the experi ence of CRS as contained
in Pena et al. (1987) to arrive at the possible range of
project costs (Fig. 7-56). In addition to the costs shown
in Fig. 7-56, it may be neces sary to consider the costs
for interim and permanent financing of the project and for
cost escalation should the project sched ule cover a
lengthy time period. These can be added as separate
categories following category “K.” They will be somewhat
like those shown in Fig. 7-57 on the following page. Still
other costs are shown in a project cost budget included in
the competition program for the new architecture building
at Ari zona State University (Fig. 7-58). Note that this
estimate contains a number of the project costs noted
above as well as a number not mentioned. This is to be
expected. Every project will have its par ticular
environment and associated costs. The programmer must make
certain that all of the anticipated costs are included in
the project budget/cost estimate. Appendix

COST ESTIMATE M0@irw @hti(q1 S M B ® 1945 gross sqf High

Medium Low A. Building Cost..........................
116,700 106,975 97,250 B. Fixed
Equipment.................... ...........5,835 4,279 2,917
C. Site Development................... .......... 4,668
3,209 1945 D. Total Construction............... 127,203
114,463 102,112 E. Site Acquisition/Demolition....
............ ...... --------F. Moveable
Equipment.............. 23,340 19,255 15,560 G.
Professional Fees................... 12,720 11,446 10,211
H. Contingencies......................... .......... 8,904
6,867 5,105 1. Administration Costs..............
...........1,272 1,144 1,021 J. Total Budget
Required........ ..$173,439 $142,877 $134,010 A Studio and
Art Gallery Program Page 23

Figure 7-55 Small Project Cost Esimate.

Credit: Chris Barta, Kevin Camp, Dan Clavin, and Shauna

Herminghouse, 1992. Program for a Stu

dio and Art Gallery. College of Architecture, The

University of Arizona

A. Building Cost

Net Area -r Efficiency Ratio = Gross Area

Gross Area x Unit Cost = Building cost

Example:

12,000 Net SF + .60 = 20,000 Gross SF

20,000 Gross SF x $140/SF = $2,800,000

B. Fixed Equipment

Percentage of Line A

Low 5%

Medium 10-15%

High 20%

Very High 30%

Commercial Office .5-7%

Sports Center 5%

Elementary School 6-10%

Secondary School 8-12%

University Academic Bldg. 7%

Civic Center 8%

Housing Project 7-10%

University Average Building 14%

Jail 12-15%

School of Medicine 15%

Hospital 18-20%

University Science Bldg 20%

Civic Auditorium 20-25%

Heavy Industrial Arts 30%

Teaching Dental Laboratory 30%

Church/Synagogue 5-15%

C. Site Development

Percentage of Line A

Low 5%

Medium 10-15%

High 20%

Very High 30%

Urban Site 5%

Elementary School 6-12%

Secondary School 10-15%

Suburban Site 14-15%

Hospital 10-15% Secondary School 20% Special Conditions 30%

(rock excavation, steep slopes, etc.) D. Total Construction
Cost Sum of A + B + C E. Site Acquisition and Preparation
(real estate appraiser, contractor) F. Movable Equipment
Percentage of Line A Low 5% Medium 10-15% High 20%
Elementary School 6-10% Secondary School 8-12% College
10-15% Library 15% Medical Office Bldg. 15% Hospital 18-20%
Vocational School 20% Church/Synagogue 5-10% G.
Professional Fees (including consultants) Percentage of
Line D Varies from 5% to 15% (See Figure 7-71) H.
Contingencies (Percentage of Line D) Low 5% Medium 10% High
15% J. Administrative Costs Percentage of Line D varies
from 1% to 10% K. Total Budget Required Sum ofD + E + F +
G + H + J = K

Figure 7-56 Calculation of Project Costs

Adapted from: (Pena et al., 1987), 104-105. Permission:

American Institute of Architects and HOK

L. Interim Financing Cost

Percentage of Amount Borrowed (1.5% to 2.5% above prime per
year

of construction)

M. Permanent Financing Cost

Percentage of Amount Borrowed (varies from 1% to 2.5% above

prime)

N. Cost Escalation

Percentage of Line K (has varied from under 3% to over 10%)

Figure 7-57 Additional Project Costs. Similarly, a plan in

volving major additions and renovations to an existing
church facility required two separate estimates, because
con struction was to be phased over several years. In
this case, the systems and materials of the new work were
well defined during the consultation so that the construc
tion cost and other project costs could be accurately
estimated (Fig. 7-59). Note that it is possible to be
more precise in a number of ar eas, as the particular
nature of a project becomes evident. For ex ample, the
Means Estimating Handbook has charts showing the average
costs for architectural and engineering fees for a variety
of project types (Figs. 7-60 and 7-61). Life Cycle Costs
If operating or maintenance costs are important
considerations, and they are with most clients, then
performance requirements relating to energy consumption of
the various mechanical and elec trical systems, as well as
heat loss and gain from the building systems, may need to
be spelled out. Likewise, the costs to main tain the
building and systems in proper working order and
projections of their useful lives (how often they will
have to be replaced) may also be important.

D. P re lim inary C o n s tru c tio n B udge t:

Construction Cost

a. New construction (100,000 s.f. gross) $7,600,000

b. Remodelling/Renovation (including connection to existing

building) 90,000

c. Special Fixed equipment (including lecture hall seats,

audio and solar testing eguipment) 400,000

d. Telecommunications distribution 150.000

e. Site development (site preparation) 250,000

f. Utilities extensions 150,000

g. Other 0 S u b to ta l: Construction Cost $ 8,640,000

Miscellaneous

a. Furnishings and equipment: movable 800,000

b. Contingency (4%) 377,600

c. Inflation adjustment (15 mo. x .0042) 594,720

d. Parking replacement (60 spaces x $800) 48,000

e. Telecommunications equipment 100,000

I. Surveys and tests 67,000

g. Move-in costs 15,000

h. Planning overhead 0

1. Fees and competition cost 857.600

j. Other £ S u b to ta l: Miscellaneous $ 2,759,920

PROJECT TOTAL $11,500,000

Figure 7-58 Preliminary Construction Budget.

Credit: Competition Program, 1986. ASU Project #125-2E.

Permission: College of A r

chitecture and Environmental Design, Arizona State

University

Some owners are willing to pay more for the

building initially, if it means that the continu

ing costs of operations and maintenance can be

reduced. In fact, nearly all construction costs

are financed over a period of years, so that

they are covered by the continuing receipts of

the organization. These costs, which are often

fixed, are accompanied for the life of the build

ing with operations and maintenance costs,

which are not fixed. In recent years the opera

tions and maintenance costs have escalated

rapidly to the point where they often exceed

the mortgage costs. If this is an area of con

cern, the owner may wish to spell out a strat

egy whereby the initial costs are increased in

order to reduce the potentially high costs later

on. This activity is referred to as life cycle cost

ing, and can be a very important consideration

in programming. NORTH M INSTER PR ESB YTER IA N CHURCH TU

CSO N A R IZO N A C onsultation by R obert H ershberger,
Ph.D., FAIA O ctober 1, 1995 PROJECT PHASING RECOMMENDATION
PH A SE #1 1. Chancel A dd ition /C a se Organ $ 695,000 2
. Equipm ent Yard $ 10,000 3 . R owley Fellow sh ip Hall $
600,000 4 . Adm in R enovation $ 72,000 5 . Drive Through $
5,000 6 . D rop -o ff/ Founta in $ 5,000 7 . Phase #1 C
onstruction Total $1 , ,3 8 7 ,0 0 0 9 . Prof. Fees (10%
of #7) $ 138,700 1 0 . M oveable Equip /Furn ish (5% of
#7) $ 69 ,350 1 1 . Admin Costs (1% of #7) $ 13,870 1 2 . C
ontingencies (10% of #7) $ 138,700 1 3 . Phase #1 Total
Project Cost $ 1 ,7 4 7 ,6 2 0 PH A SE #2 1. Youth and
Choir B uild ing $ 576,000 2 . E lem entary C lassroom R
enovations $ 92,000 3 . Preschool R enovations $ 108,000 4
. A dult C lassroom R enovations $ 100,000 5 . B alcony R
enovations $ 57,000 6 . New Parking $ 10,000 7 . L an d s c
a p in g $ 30,000 8 . C overed W alks $ 50,000 9 . New
Signs $ 10,000 1 0 . Gate System $ 5,000 1 1 . M em oria l
C ourtyard $ 50,000 1 2 . Phase #2 C onstruction Total $1
,0 8 8 ,0 0 0 1 3 . Prof. Fees (10% of #12) $ 108,800 1 4 .
M oveable Equip/Furnish (5% of #12) $ 60,400 1 5 . Admin
Costs (1% of #12) $ 10,880 1 6 . C ontingencies (10% of
#12) $ 108,800 1 7 . Purchase R es idence $ 200,000 1 8 .
Phase #2 Total Project Cost $ 1 ,5 7 6 ,8 8 0 TO TA L PR O
JEC T COST $ 3 ,3 2 4 ,5 0 0
7.12 Project Schedule

When time is of the essence, a project schedule

is included as a brief separate section of the

program, so that it will not be lost in the text

and possibly be seen as unimportant by the de

signer. This schedule should address every

phase of the project to be most effective—pro

gramming, design, construction, and occu

pancy. If the owner must vacate present

facilities on a specific date, or the building

must be completed by a certain time to meet

bonding or other financial requirements, an

achievable schedule should be set forth indi

cating what the client and architect must ac

complish by a certain time to complete the

design and construction documents on sched

ule. A similar schedule should indicate when

various phases of construction must be com

plete to allow the scheduled occupancy to take

place (Figs. 7-62 and 7-63). Figure 7-59 Project Phasing

Cost Estimate. Architectural Fees lor protect sizes of: Up
to $10,000 15% to $25,000 13% to $100,000 10% to $500,000
8% to $1,000,000 7% The listed lees are approximate for
smaller projects, such as repair work and/or rrmrxtoling
existing structures Figure 7-60 Architectural Fees for
Small Projects. Permission: From Means Estimating Handbook.
Copyright R.S. Means Co., Inc., Kingston, MA,
617-585-7880, all rights reserved. Building Type Total
Project Size in Thousands of Dollars 100 250 500 1.000
2.500 5,000 10.000 Factories, garages, warehouses
repetitive housing 90% 80% 7.0% 6.2% 5.6% 5.3% 4.9%
Apartments, banks, schools, libraries, offices, municipal
buildings 117 10.8 8.5 7.3 6.7 64 6.0 Churches, hospitals,
homes, laboratories, museums, research 14.0 128 119 10.9
9.5 85 7.8 Memorials, monumental work, decorative
furnishings 16.0 14.5 13.1 11.3 100 90 In this figure,
typical percentage fees are tabulated by protect size, for
good professional architectural service Fees may vary from
those listed depending upon the degree of design
difficulty and economic conditions in a particular area
Rates can be interpolated horizontally and vertically
Various portions of the same project requiring different
rates should be adjusted proportionately For alterations,
add 50% to the fee for the first S500.000 of protect cost
and add 25% to the fee for the project cost over S500.000
Architectural fees tabulated above include Engineering Fees
Figure 7-61 Architectural Fees for Larger Projects.
Permission: From Means Estimating Handbook Copyright R.S.
Means Co., Inc., Kingston, MA, 617-585-7880, all rights
reserved. Jan Feb Mar A pril May June Ju ly Aug
miiiimnuiu litimiiiuimi iiiiiuiiiimiii niiiimiiiiiiii
tmmmimii maim ................................ Sept Program
Schematic Design *4-------Program Info. Systems & Animation
Review Design Development Construction Doc.
--------------19 8 9 Jan Feb Mar A p ril May June Ju ly
Aug Sept iMiimminii imiiiiiiuiiiiu itiutMtmmii iiHiiuiiiumt
liiiiuiiiiiiini kiiiiiiiiiiiiiii iiiiihhihuin
iibiiiwiiuiiii hiiiiiiiiiiiiii Oct Nov Dec i Jan
inmiimmtii iiimiiiiiiiiiii iiiuimiiiiNi tiiiiiiniiiii
-*~4Plancheck ► A pproval Construction Bidding

Figure 7-62 Project Schedule.

Credit: Larry Medlin and NBBJ Gresham Larson, 1988. Program

for The Arizona Solar Oasis a t the

Phoenix Civic Plaza. Phoenix, Arizona. Permission: Richard

Larry Medlin, Architect As can be seen from the above two
examples, a pro ject schedule can be shown in different
ways. Probably the most common way is the bar chart as
shown above. If the schedule is very tight, it may be
necessary to prepare a crucial path schedule to ensure
that everything can be accom plished by a certain dead
line. In this case, items that simply must be accom
plished before others can proceed are placed on the
crucial path. Other items that can take place at sev eral
different times or throughout one phase of the project
fall out of the crucial path (Fig. 7-64). Such a tight
schedule can have a profound effect not only on how the
work is processed, but also on the final design character
of the building itself. The designer must carefully
choose sys tems that can be placed in a very systematic
way to avoid unplanned delays in construction. It may be
necessary to fast track a project in order to reduce the
time from be ginning to completion. This process involves
major overlaps of what are normally discrete phases of the
work. For example, it might require initial develop ment
of a master plan program followed by design, development,

Figure 7-63 Project Schedule.

Credit: Arquitectura, 1988. Pre-Design Workbook, Verde

Meadows Recreation Center. Tucson,

Arizona. Permission: Arquitectura Ltd.

Project Schedule 2 , 4 , • • » « » « » » « « « »

\erd4 Mallows Hunter of r -------------------------------- >

f*ecrcz»H?n Center 1| 3| 5| I I I I I I I | M i| li:|lf| I

[Hr I I ffr I )Ht

Consultw ^‘Selection | | | | | |$ | * WorWToK g ||F [~

Coneulfztnte conp,rrmj-cn j ST T cfr Preda^gn \Ajbrhbz?K Ip

Coc:nzma\-io Pe&zp | |

De&gn Ctevddspment- |iS~

c o n & h u c t r r ) C bcurrcnTr? B g gg S g „.

(Drawing 4 <=fe&Pi&.tHor>b) ^ I_I

Building ‘cofet-y &IPI

P -ev iev v 4 A p ra v a l gg jjg | j IT M IN IiTT'1 1

<Zavtehvahc>n 1^111111^^^1

C tc a f& n o y iL>T~

/Wve -m m H * J IrmTtTl 111111 Itttl 111111 ITlr Figure

7-64 Crucial Path Schedule. Credit: Richard C. Maxwell and
David J. Wyckoff, 1993. Interior Programming, Stacking, and
Blocking for Society National Bank. Professional Practice
in Facility Programming. Wolfgang F.E. Preiser, Ed, NY:
Van Nostrand Reinhold. Permission: Van Nostrand Reinhold

and construction of the in

frastructure of roads, utili

ties, and landscaping of a

major project; leaving only

undeveloped sites for con

struction of specific build

ings. While the design of

the master plan is proceed

ing, the programming for

schematic design of specific

facilities will begin. While

the foundations are being

built, the schematic design

of the buildings will be tak

ing place. If the deadline

for completion is tight, con

struction documents for the

foundations and utility ser

vices to the building will be

prepared, even before the

design of the superstruc

ture is complete. Similarly,

the shell of the building

may be under construction

even before design develop

ment programming and de

tailed design of the interior

are complete (Fig. 7-65). The above theoretical ex

ample indicates how the

foundations could be fast

tracked such that when the

rest of construction is bid,

the foundations would al

ready be in place and ready

to receive the superstruc

ture of the building. Clearly, when such a collapsed

process is undertaken, assump

tions must be made about the probable character of yet

unpro

grammed or designed facilities. In the master plan, enough

room

must be left and services provided for the anticipated

buildings. MASTER PLANNING PROGRAMMING SCHEMATIC DESIGN
DESIGN DEVELOPMENT CONSTRUCTION DOCUMENTS GOVERNMENT
APPROVALS BIDDING/NEGOTIATION CONSTRUCTION SITE
PREPARATION SURVEYING/SOILS ANALYSIS FOUNDATION DESIGN
FOUNDATION DOCUMENTS FOUNDATION APPROVALS FOUNDATION
BIDDING FOUNDATION CONSTRUCTION Figure 7-65 Fast-Track
Schedule. 7/1]__________ 3 7'16__________5 Review Current
kataWmh Food Food F acuity
_____________________________________________________ ! I
acidly ^ ~ j 13aeed Upon j 2.200 Penplr 7 7/26 \ 6/2 /
7/11__________ 1 7/te__________ 1 7,^6__________9
7/22__________» 3/5 \ 4 6/9__________ j Schedule j
Coewbicc ; Complete SRS Condjcrt Continue Data uene-atr Imt
al / Kick-off Kick off j Forma A A9 Intern-ewe / Baae
Keadcoun; & J Prenentatior ' ’reaentacip- — “ j Sehedu « '
Baqi- Data develop rrent ' Space Pp-c* “ j | Ince veee
Base Per Repc.-to j ^ 7 j 7/IS 7/26 A/2 »'» X j /
Confirm Soala Refine Space / / y<r Determine Peer Survey
(SRS) / j / Grouping* Forme / 7 nO______' n i T / ' Z
5 7C7 3 7/22 2 7/24_______ / ^ l (NriATE: Obtain & Revtew
Analy/s [ Develop A Refine I Approve ’ Proa rammirw Current
V/orkplfiee | Recommend Corp Space | Ce-p Space A Related
Fum ahinqn Rqmta pe-Pser j Co-p Space Stendarda | Svanda-ds
ServRea Inventory Ouxjpin^t I Standa-da I 7 / h \ . 7/19
7/24 7/29 7/31 3/1 __________ I 7/12________ V Obtain
Petemdne Prawtnja of All Planning “ bora ModuleaASF
Available jier Fir JAN FEB MAR APR MAY JUN SEP DEC

Figure 7-66 Design and Construction Time.

Permission: From M ean s Estimating Handbook. Copyright

R.S. Means Co., Inc., Kingston,

MA, 617-585-7880, all rights reserved. When footings are

constructed before design is complete for the building,
the designers must correctly anticipate the configu
ration and loads of the super structure. Almost
inevitably, this leads to master plans with locations for
discrete building units and to simple buildings with
open, free-span floor areas, which will allow any of the
an ticipated but yet unprogrammed uses to fit reasonably
well. Typ ically this involves both simpli fication of
form and over-sizing of spaces and services. Thus, it
becomes an important influence on the design, having a
profound effect on building form. It also may have an
effect on the project budget, increasing design costs, but
possibly reducing construc tion and financing costs. If
such a tight schedule is mandatory, all of the potential
costs and savings should be given careful atten tion, to
make certain that the job will remain within the project
budget. Relative to construction time requirements, Means
has some helpful guidelines related to the time it takes
to construct several different types of buildings. It also
indicates that design time typ ically runs 25 to 40
percent of construction time (Fig. 7-66). Programmers
should develop an accurate record of time spent on the
various phases of the design and construction process on
every commission so that over a period of time they will be
able to make reasonably accurate predictions as to the
time (and per sonnel resources) that will be necessary to
accomplish each phase of the work. This can be of great
help to the client and architect as they move forward with
a project. 7.13 Design Analysis • Client Ideas • Precedents
• Programmatic Concepts • Design Precepts

Table at left is average construction time in months for

different types of building proiects. Table

at right is the construction time in months for different

size proiects Design time runs 25% to 40%
of construction time.

Type Building__________ Construction Time _______ Project

Value________ Construction Time

Industrial Buildings 12 Months Under $1,400,000 10 Months

Commercial Build ings 15 Months Up to $3,800,000 15 Months

Research & Development 18 Months Up to $19,000,000 21 Months

Institutional Buildings 20 Months Over $ 19.000.000 28

Months

In order to estimate the General Requirements of a

construction proiect. it is necessary to have an

approximate proiect duration time Duration must be

determined because many items, such as

supervision and temporary facilities, are directly time

variable The average durations presented in

this chart will vary depending on such factors as location,

complexity, time of year started, local

economic conditions, materials required, or the need for

the completed proiect. • Design Concepts • Design
Exploration There may also be ideas about an appropriate
design solution

that the client, user, or programmer wants the architect to

con

sider when designing the project. These are not usually

consid

ered requirements for design, simply ideas which have come

up in

the course of the diagnostic interviewing or work sessions.

If they

seem to be good ideas to the client and programmer, they are

probably worth including in the program, not as design

require

ments, but as possible directions for the designer to

explore when
formulating the design solution. The ideas about design
should be kept in a separate concluding

section of the program or in the appendix, for they are a

beginning

of the architectural design process rather than an integral

part of

architectural programming. The fact that design ideas come

for

ward while people are considering the nature of a problem

should

not seem unusual. It is human nature to consider solutions

when

defining problems. It should be recognized, however, that

these

ideas are preconceptions, not design concepts or solutions.

In

deed, as the design problem is explored, it will be found

that some

of the ideas are not at all appropriate and must be

discarded,

while other ideas are very good and can be incorporated

into the

overall design. In any case, ideas that are set forth at

any time

during the programming process should be recorded and summa

rized in this section of the program document.

Client Ideas

The classic case of design ideas being offered during

program

ming, perhaps, is that of the couple who has collected a

whole

scrapbook of ideas from Better Homes and Gardens, Sunset,

and

other magazines that they think are nice and could be

incorpo

rated into the design of their new house. Clients in

corporations,

businesses, and institutions may also have design ideas,

perhaps

based on trade journals or on personal experience with

particu

larly effective or ineffective building arrangements. Some

novice

architects may prefer to ignore such ideas, feeling they

are threats

to the architect’s need for personal design expression, but

many

experienced designers and programmers will encourage the

client

to collect and preserve this material as a data bank of

design

ideas. There is every reason to believe that the persons

who use a facility will have at least some good ideas
about the solution to particu lar aspects of a design
problem. The question is how best to present these ideas
and not have them be come design preconceptions with which
the designer is forced to work. The author feels that to
treat them simply as design ideas rather than design
concepts is the proper approach (Fig. 7 -67). If the ideas
are taken from maga zines or other published docu ments,
they can be photocopied and included with footnotes
crediting the source and indicating why the idea was
considered appropriate for the design solution. If a
client or user recognizes that the programmer has accepted
and recorded their ideas, they are much more likely to be
sympa thetic with the final design solution, even if some
or even most of their ideas were not in corporated into
the design. If the client or user suggestions are given
ver bally, they should be recorded and included in the
programming matrix under the ideas cate gory. If they seem
to be important ideas, the programmer should develop
suitable sketches or precept diagrams to make the ideas
more clear (Fig. 7 -68). Desired images observed by the
program mers in the client’s existing establishment are
shown in Fig. 7 -69 .

Figure 7-68 Design Ideas from Program Matrix. Precedents

Figure 7-67 Magazine Clippings from a Client.

COLLEGE OF ARCHITECTURE AND ENVIRO NM ENTAL DESIGN

EXPANSION (rum* or *«ch rtudent)

B u ild in g A rea r f 's e s u rv e y e*._____

__________________________ ( 116) Mime: (College is i
whole, School of Architecture... 0**1911 Studios)

PROGRAMMING M ATR IX : IDEAS

1. Provide a large formal entry for visitors/public and an

informal, efficient access, for student/faculty.

2. If another elevator is required in the new expansion

facility, it should be of adequate size to accommodate
large scale models, and have direct access from drop-off

3. Create a hierarchy of stairwells distinguishing major

vertical circulation from emergency exits. (A good example
of this is Noble Library.)

4 Locate handicapped access conveniently to elevators.

5 Install lockable display cases adjacent to studios for

viewing of current student work.

6 College could rent out space to manufacturers which would

offset the cost of the additional square footage and
possibly create revenue for student activites.

7 Document the best student work in the form of slides,

microfisch, prints, or originals, so that it can be
displayed and also referenced by students/faculty. It could
possibly be incorporated as a branch of the library.

8. Provide 1 main information tack wall for display of

scholarships, competitions, job opportunities, class
schedules, etc.. Also provide secondary tack boards
throughout circulation paths for advertisement of
activities, lectures, and announcements.

9. Locate soft drinks and vending machines adjacent to

secondary circulation path.
Credit: David Sandvig. Rob Darney, and Chris Caroselli,
1986. Information about similar buildings collected

College of Architecture and Environmental Design Expansion.

&

Permission: School of Architecture, Arizona State

University during the literature review phase of architec

Entry G ate

Decorative Stair

Curved Wall W indow Trim Shaded Patio W indow Trim Curved

Walls Island and Beams Wood Vegas

tural programming should be included in the

appendix. However, particularly relevant fea

tures of these buildings or typological con

stants should be included in the ideas section

of the program for the designer to consider.

The programmer should try to ascertain from

the previous solutions if a cultural norm exists

or if a very logical arrangement has come to

characterize the particular building type, and

whether departures from the norm are likely to

compromise the effectiveness of the design so

lution. In other words, if the logical solution

for a particular building type has already been

demonstrated, the architect’s design task may

not be to rediscover this essential typology, but

rather to adapt it to the particular problem and

site at hand and in such a way as to meet the

goals and satisfy the requirements of the par

ticular program. A contemporary example of this is the L-

shaped corner shopping center that character

izes so many major intersections in developing

areas of the United States. This pattern

recurs ad nauseam, to the point where

nearly everyone wishes something more

unique or creative could be achieved.

Yet, when unique approaches are tried,

they apparently fail to attract the same

intensity of use, so developers return

again and again to the same prototype

(Fig. 7 -70 ). The developers of a shopping center

in Tempe, Arizona, on the other hand,

turned the typical “L” around and cre

ated a successful shopping area with

the parking behind the buildings

rather than in front of them. This ap

proach seems to have worked in this

situation; however, the arrangement

precludes having a back door service

area for the shops, limiting the types of IMAGERY ELEMENTS

Figure 7-69 Design Ideas from Observation Study. Credit:
Robert Osier, Donald Kidder, and Blair Saville, 1985. Pro
gram for DAX Clothing Sotre. Tempe, Arizona. Permission:
School of Architecture, Arizona State University Figure
7-70 L-Shaped Shopping Center. Credit: Anthony Amidei,
Student Assignment, 1993. Permission: College of
Architecture, The University of Arizona S h o p p in g C
en te r B a n k H U N Tl|lG LODGE® T r u m p e t , .
EAR'SKl\’ DECOY i 2 J ‘b r |i c k VLA Shopping Center
########### r

Figure 7-71 Reverse L-Shaped Shopping Center. VehiftnUr .

Attt% Otiirtry PtC^-up * “^ u w r e " Ham CnM>wKwi4y Acttss

Figure 7-72 Community Market Diagram.

Credit: See Silverstein, M urray and Max Jacobson (1985).

Permission: W olf

gang F.E. Preiser shops that can be located in the cen ter
(Fig. 7-71). On the other hand, some architects and other
urbanists long for the pedes trian-oriented shopping
streets and squares that typify cities and villages
throughout Europe and some pre-auto mobile cities and
communities in the United States. Murray Silverstein and
Max Jacobson (1985) make a cogent argument for an
alternative program for a community market (Fig. 7-72).
Other contemporary architects and planners advocating for
a “new urban ism” have made similar pleas for
pedestrian-oriented streets and shop ping areas (Kelbaugh
1989; Katz et al. 1994). Similar arguments for alternative
approaches to many building types are presented in
Alexander et al.’s Pattern Language (1977) and The Oregon
Experiment (1975). Another book, Precedents in
Architecture by Roger Clark (1985), shows diagrams of
various systems for numerous building types. In any case,
a careful literature search should reveal some
alternative patterns or approaches that can be presented
to both the client and the designer for their con
sideration. Programmatic Concepts In Problem Seeking (1969,
1977, 1987) William Pena et al. argued for including
programmatic concepts in the program document. He defined
“programmatic concepts” as those concepts having primarily
organiza tional or operational implications. Figure 7-73
illustrates “integrated” Theater

versus “compartmentalized” as programmatic

concepts. Similar programmatic concept cards can

be used effectively to visually explain many

of the programmatic ideas that are expressed

during the programming process (Fig. 7-74). With many

programmatic concepts there
are important form implications. For example,

in the programs for the expansion of the Col

lege of Architecture and Environmental

Design at Arizona State University and

of the College of Architecture at The

University of Arizona, a marked differ

ence in attitude about the nature of de

sign education resulted in different

programmatic concepts for the arrange

ment of design studios. At Arizona

State University, it was decided that

each design studio should be separate

from the others to allow the students to

secure their computers and other per

sonal equipment in a locked room. At

The University of Arizona, the students

and faculty indicated that they wanted

large, open, even multiple year and

multiple discipline studios to promote

social interaction and collaboration be

tween faculty and students. Security of

individual workstations and equipment

are of secondary importance. TransFigure 7-73 Integrated

versus Compartmentalized. IDENTIFICATION The lib r a r y 's
p u b lic func tion s and se rv ice s should be CLEARLY
IDENTIFIABLE by the patron. CIRCULATION The l ib ra ry
should have e a s ily IDENTIFIABLE MOVEMENT PATHS. The
lib ra ry should be accessib le to a broad range of
people. Figure 7-74 Concept Cards Sheet. Credit: Anderson
DeBartolo Pan, Inc. Architects, 1986. Program for the City
of Tucson Main Library. Tucson, Arizona. Permission: ADP
Marshall

portable and personally owned laptop

computers are encouraged to reduce

the potential for theft in an unsecured

environment. The above differences

are programmatic in nature, but have

very strong formal implications. Such “ideas” can be

expressed in

diagrams to make them more under

standable to the designer than if they were expressed only

in

words (Figs. 7-75 and 7-76). While such programmatic concept

diagrams do not specifically show “how” the studios are to

be de

signed, there are strong formal implications that, if

responded to CIRCULATION

Figure 7-75 Separated Studio Diagram.

Figure 7-76 Integrated Studio Diagram.

Figure 7-77 Precept Drawings.

Credit: Brooks & Associate AIA, Architects and Planners,

1985. Design Pro

gram and Site Analysis for M orris K. Udall Regional

Park and R ecreational Cen

ter. Permission: Albanese-Brooks Assoc. PC by the designer,

will produce very dif ferent designs (and studio
activities). Design Precepts Professor Edward T. White (1 9
7 2 ) de veloped the idea of using precept dia grams of
partial solutions to design problems as a final step in
program ming. When the designer is part of the
programming team, this is a meaningful way to explore the
design impact of various programmatic deci sions before
attempting to develop an overall design concept. Three to
six concept or precept cards can be reduced in size and
shown on one page of the program document (Fig. 7 -77).
Verbal explanations can be added below or to one side. The
re duction is possible because the cards are drawn and
lettered at a large scale so as to be easily seen from 1 0
to 15 feet away in a work session. Note how precepts can be
diagram matic, physical, or even metaphorical in nature
and in how they are pre sented. This does not matter as
long as everyone understands that they are all just
ideas—preconceptions about how the final design might
respond to the design problem. If they are included in
the program document in this way, they give the design
architect the bene fit of all of the ideas uncovered in
the programming process— ideas uncov ered in literature
review, client and user ideas, and programmer distilla
tion of all of these ideas. If everyone understands that
they are only sugges tions, not requirements, the designer
should benefit from the added insights (Figs. 7 -78
through 7-80). behoof , W**® pvrvwtt TM ^ iT lC M <u vxJU
C u l R’UAoe** in t e r a c t io n -hu dcovino °k e h L d
e cud, iN v rw ioH 4© Ue. jjuulity. e \ ^ f^ T H *^ p iiW
ro N .

The f?£CAe*t»* n ^ -e ^ H AUR. , *9UNU<2>HT , F W C E N V

IR O N M E N T \ ****,<- #7 4'VpvwU itxLwJtmt S H A D E .
U> ENHANCE dLeAvrih'ei iV>. -Jkt E N V IR O N M E N T —J-
tztzc?Lice- HC*AT STUDIO P STUDIO P I STUDIO P J STUDIO
CIRCULATION STUDIO STUDIO ( STUDIO

UNDULATE OJALL ALONG MAIN TRAFFIC ARTERIES

AND INSTALL LANDSCAPING TO SCALE DOWN

SITE ENCLOSURE AND PR O V ID E INTEREST

Figure 7-78 Precept Drawing.

Credit: Arquitectura, 1990. Program Document for Pascua

Neighbor

hood Center Growth Master Plan, Tucson Parks and

Recreation, Tuc

son, Arizona. Permission: Arquitectura, Ltd. AQUARIUM

EXHIBITS The Kelp Forest exhibit has two essential
underlying requisites: the surface must be open to receive
direct sunlight and the water must be kept in constant
motion. « to access and should not have Figure 7-80
Precepts from Student Program. Credit: Beri Varol, 1996.
Undergraduate Senior Thesis, The Santa M on ica Aquarium.
College of Architecture, The University of Arizona

Figure 7-79 Precept from Student Program.

Credit: Karin Rosenquist, 1990. Program for the Design of

the Depart

ment of Agriculture Bee Research Laboratory. College of

Architecture,

The University of Arizona H *H 'VlSUAU AeSTHFTlGS

fcl/IUplHGr AS j \ A H jOWEK

Figure 7-81 Climate-Based Design Concept.

Credit: Elisa bet Grajewski, 1992. Sixth S tree t Housing D

evelop

ment, Tucson, Arizona. 5. College of Architecture, The

Univer

sity of Arizona

Figure 7-82 Zoning Diagram/Design Concepts.

Credit: Edward T. White, 1990. Concept Sketches for Graph

ics Workshop. Tucson, Arizona. Permission: Edward T.

White If the designer is a member of the programming team,

it is also possible to begin the develop ment of design
concept diagrams as a conclud ing part of the programming
activity. This serves both as a way to confirm the
efficacy of the program information and as a way for the
client to evaluate if the concept is appropriate for the
client’s particular facilities problem. It can show, as in
the adjacent illustration, how a strongly held value can
have a major impact on architectural form (Fig. 7-81). A
process for creating design concepts has been well
developed by Professor Edward T. White of Florida A&M
University (1990). This analytic approach to developing
design concepts focuses on particular issues. The first
approach begins with the functional concept diagram.
Here, a traditional relationship diagram is gen erated for
the entire building, recognizing from the start that any
holistic diagram will be based on certain organizational
assumptions. Will one entry serve as reception point for
all divisions of the organization or will multiple entries
be pro vided for easier/direct access to each division?
Which will serve the client better? What are the staffing
implications? Should the program be changed to reflect the
new requirements for staffing? Should all of the closed
offices be gath ered in one area and all of the open
offices be placed together in another location? Will this
make functional sense? Will it save money in terms of
structural and or construction costs? Very simple bubble
diagrams are used to ex plore the implications of
functional arrange ments in terms of operations,
efficiencies, construction costs, staffing costs, etc.
First, White develops the overall relationship dia gram.
He then decides on alternative ways that the building
could be zoned. Finally, he derives several design
diagrams based on each of these zoning decisions to see
what their implications are for design (Fig. 7-82). Design
Concepts T h ere w a s t o b e a c e n t r a l c o m
m u n a l o u td o o r spoce o t v a ry in g w id th ,
a s a r e s p o n s e t o o u r g r o u p s u n ify in
g t h e m e ( o n u n d u la t i n g p a t h t h a t w
in d s t h r o u g h a n d o r g a n iz e s t h e e n
t i r e r e d e v e lo p m e n t p l a n ) . This c o m m
u n a l s p a c e w o u ld b e u s e d fo r c i r c u
la t io n a s w e ll a s r e c r e a t io n SUN ANGLE IN
W I N T E R ^ ^SUN ANGLE IN SUMMER m m ThmudURMiw ' *

I ( 1

1 / 11

Vj V

5 ( 1 The zoning relationship diagrams and the result

ing initial design concepts show how effective such

diagramming can be in helping the architect develop

a design concept. The example shows that three dis

tinctly different zoning decisions can be made from

an identical overall relationship diagram, and that

the impact of each approach on the design solution

is likely to be very great. The resulting plans are not

at all similar in shape or aesthetic potential. Grouping of
functions in zones can also be useful

in programming for the reorganization of existing fa

cilities, including related outdoor spaces. In the ad

joining illustration, they were proposed by the

programming/design consultant as a way to solve

programmatic problems (Fig. 7-83). Whether zoning

relationships are appropriate

to include in a program document depends on

whether they represent programmatic decisions by

the client/user, or are, in fact, conceptual ways of

approaching the design. In the latter case, the di

agram definitely should be left out of the require

ments section of the program. It could be included

in the ideas section of the program, where it can

be evaluated by the designer as an idea rather

than as a requirement. Such analytic diagrams do not have

to confine

themselves to functional matters. What if the dia

gram begins with site or context, rather than the

functional program? Where would views, access,

slopes, special site features, and the like suggest

that building entrance, services, or principal

spaces be located? Is there another way that the

site might better accommodate the facility? If cli

mate, especially solar access, were considered,

how would it affect or influence the layout of the

building? What if solar access was considered to

be the most important issue? White (1990) goes on to show

other diagram

matic ways to develop design concepts that pro

duce different formal relationships than the ones

developed from the alternative zoning diagrams,

and which require the designer to handle func

tional relationships in still other ways (Fig. 7-84).

Figure 7-83 Zoning Relationship Diagram. Credit: Robert
Hershberger, Architect, 1982. Consultation for Bellevue
Christian Church, Bellevue, Washington. Figure 7-84 Context
Related Design Concepts. Credit: Edward T. White, 1990.
Concept Sketches for Graphics Workshop, Tucson, Arizona.
Permission: Edward T. White SITE ZONING PLAN SCALE: 1" =
48' NORTH____ I 6. OUTSIDE RECREATION r > 1. WORSHIP &
FELLOWSHIP ^ ^ « A <f 2.ADMINISTRATION'} f l ' . A| i f
& ADULT EDUCATION M PRE-SCHOOL L _ II It EDUCATION I j '
iKbrs -f J S.E. 28th1 !/ i i ! I I 480' | I J I ApUE UAC
CONCEF& What if aesthetic values were to be considered
first? What should such a building look like, in spite of
any functional, site, and climate constraints? This would
require a different diagram and a corresponding change in
functional layout and relationship to site and climate.
What if budget were the most important consid eration—the
client needs a large amount of space, but has very lit
tle money to pay for it? This would have a very serious
effect on form. Such diagrams can begin from any of the
primary values listed earlier in the program (Fig. 7-85).
Design Exploration Clearly, most of the above tech niques
are part of the initial ex ploratory stages of design. If
they are accomplished during programming and the final
program is modified to reflect these early design
findings, it almost takes the program through the initial
schematic phase of design. But it also helps to avoid the
problem of the architect having to explain to the owner
that certain assumptions of the program were either in
error or were unrealistic relative to some of the expressed
values and goals. The author advocates including design
exploration in program ming only when the designer is
involved in the programming process, and even then with
some reservations. There are several very good reasons for
this recommendation. The first reason is that confirmation
of the client’s program typically is the first
responsibility of the architect under the nor mal
owner/architect agreement. It is an activity that the
architect is prepared to do by training and experience. It
is what they ex pect to do at the beginning of a design
problem. Indeed, it is

Figure 7-85 Image Related Design Concepts.

Credit: Edward T. White, 1990. Concept Sketches for

Graphics Workshop, Tucson,

Arizona. Permission: Edward T. White HMi

i i *4 artffa/, £vr/e</ /h itftfw vlt cfpw /m t anS stnji

jw rify */ */& %$viU/y of ItUfjJ

where the value of their extensive education comes into

play in

the resolution of difficult spatial problems. The second

reason is that the design architect may see other

possibilities for problem solution which previous

typologies, or

the client’s, user’s, or programmer’s limited experience,

would

not permit to come forward during programming. If the

program

is based on narrower assumptions than are appropriate given

the

designer’s range of abilities or repertoire of forms, then

the pro

gram could become an obstruction to a creative solution to

the

problem—an impediment rather than an implement for the cre

ation of architecture. Finally, even if the designer is

involved in programming, the

premature fixing of conceptual ways of solving the design

prob

lem may hamper exploration of other alternatives. Indeed,

it may

require the designer to return to the owner to explain why

the ear

lier adopted design strategy is no longer operational. This

is an

awkward and sometimes difficult thing to do. The designer,

in ef

fect, must prove everyone else wrong. The programmer should

not limit options by imposing con

straints which are not inherent in the problem. If the

designer is

not involved in the programming process, it is preferable to

leave all but the most basic design analysis to the

designer, rec

ognizing that such analysis may, indeed, necessitate some

devi

ation from the initial program. As long as the client

understands

and agrees that this is a possibility, it should not be

considered

a problem of programming, but rather an opportunity which

comes from design. The fact is that programming and design

analysis are not re

ally complete until the building is constructed and

occupied. De

sign exploration, schematic design, design development, and

even the ultimate occupancy of the building will uncover new

ideas, opportunities, and constraints which will make some

ob

jectives of the original program difficult to achieve, and

often

will cause clients to change their minds as to the

requirements of

the program. In conclusion, the author would argue that

design analysis is

the responsibility of the designer and should be under

his/her di

rect supervision. On the other hand, it does not mean that

the de

signer must accomplish the design analysis in a completely

singular way. Rather, it is highly desirable for the

designer to so

licit the participation of the clients, users, and

programmers in a common pursuit, as they explore together
the design implications of the entire program, including
all of the design ideas that have come forward during
architectural programming. Responsibility for the quality
of design resides with the de signer. Thus, the designer
must have authority to make the design decisions. 7.14
Appendix There is always some material which is of such
importance that it should not be lost, because it explains
or amplifies some of the information distilled within the
program. This information should not be placed in the main
sections of the program, but can be placed in an appendix
to the program for reference if the need arises. The only
information that should be placed in the body of the
architectural program is that which will have a direct
impact on design decisions. The programmer should keep the
program short and to the point, with essential information
relating to design clearly set forth and organized for
easy retrieval. As stated previ ously, “an ounce of
explanation is worth a ton of description.” Or, to put it
another way, “understanding of the program by the de
signer is inversely related to the amount of material
presented.” Think about these two sayings when considering
the inclusion of material in the program. The appendix
should contain the information obtained from the
literature search, observation studies, interviewing, ques
tionnaire/survey, site analysis, and any other data
developed during the programming process. If the program
is carefully de veloped, the designer may not even need to
refer to the appen dix. However, if there is a need to
look over this information at some point in the design
process, it should be available for ref erence. If the
program is a large one, the author advocates putting the
appendix material in a separate loose-leaf document with
tabs to show where each type of material is located. It
should be on 8 V* x 1 1 " paper so that it can be stored
or filed by the de signer with the other project materials
for ready reference as needed.

Pena, William, and John Focke. 1969. Problem Seeking: New

Di rections in Architectural Programming. Houston, Tex.:
Caudill Rowlett Scott.

Pena, William, William Caudill, and John Focke. 1977.

Problem Seeking: An Architectural Programming Primer.
Boston, Mass.: Cahners Books International.

Pena, William, Steven Parshall, and Kevin Kelly. 1987.

Problem Seeking: An Architectural Programming Primer. 3rd
ed. Wash ington, D.C.: AIA Press.

Rector, Lee. 1997. Design Cost Data. Vol. 41, number 1.

Tampa, Fla.: LMRector Corporation.

Robinson, Julia, and J. Stephen Weeks. 1984. Programming as

Design. Minneapolis: Department of Architecture, University
of Minnesota.

R. S. Means Company. 1990. Means Estimating Handbook.

Kingston, Mass.: R. S. Means Company.

_________. 1996. Means Square Foot Costs: Residential,

Commer cial, Industrial, Institutional. 17th ed. Kingston,
Mass.: R. S. Means Company.

R. S. Means Company. 1996. Means Square Foot Costs:

Residential, Commercial, Industrial, Institutional. 17th
edition. Kingston, Mass.: R. S. Means Company.

Silverstein, Murray, and Max Jacobson. 1985. “Restructuring

the Hidden Program: Toward and Architecture of Social
Change.” In Programming the Built Environment, edited by
Wolfgang F. E. Preiser. New York: Van Nostrand Reinhold.

White, Edward T. III. 1972. Introduction to Architectural

Pro

gramming. Tucson, Ariz.: Architectural Media.

_________. 1990. Workshop with Professor Kirby Lockard.

Col lege of Architecture, The University of Arizona,
Tucson, Ari zona. This page intentionally left blank