Scribd Logo
Upload

Welcome to Scribd!

  • Architectural Programm

    Uploaded by

    shivan
    49 views55 pages
    kjhk

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    kjhk

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF or read online from Scribd
    Flag for inappropriate content
    49 views55 pages

    Architectural Programm

    Uploaded by

    shivan
    kjhk

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF or read online from Scribd
    Flag for inappropriate content
    of 55
    Good buildings don tjust happen. They are planned to Iook good and perform well, and come about when good architects: and good clients join in thoughtful, cooperative effort. Programming the requirements of a proposed building is the architect first task, often the most important. ‘There are a few underlying pnnciples that apply to programming — whether the most complex hospital or a simple house. This book concerns these principles. Programming concems five steps: 1 Establish Goals. 2 Collect and analyze Facts. 3 Uncover and test Concepts. 4 Determine Needs. 5 State the Problem. These canseraton (0 design deteminaris) nazate the pes of ifomation needed 0 deine acomorchensive Function Form Economy Time Architectural programming, therefore, involves an organized method of inquiry... five-step process... interacting with four ‘considerations, The Search Programming Design Programming is a process. What kind? Webster spells it out specifically: 'A process leading to the statement of an architectural problem and the requirements to be met in offering a solution. © ‘This process, derived from the definition and referred to as the five-step process, is basic. The word basic"is used ‘advisedly. Since the advent of systematic programming five decades ago, different degrees of sophistication have ‘evolved. But the procedures presented here remain basic to all Back to the definition. Note ‘statement of an architectural problem. "This implies problem solving. Although usually identified with scientific methods. problem solvina is a creative effort There are many different problem-solving methods, but only those few that emphasize goals and concepts (ends and means) can be applied to architectural design problems, H programming is problem see! , then desi is problem solving. ‘These are two distinct processes, requiring different attitudes, even different capabilities. Problem solving is a valid ‘approach to design when, indeed, the design solution responds to the client § design problem. Only after a thorough ‘search for pertinent information can the client s desian problem be started. Seek and vou shall defin Programmers and Designers ‘Who does what? Do designers program? They can, but it takes highly tained architects who are specialized in asking the Fight questions at the night time, who can separate wants from needs, and who have the skills to sort things out Programmers must be objective (to a degree) and analytical, al ease with abstract ideas, and able to evaluate information ‘and identity important factors while postponing irrelevant matenal. Designers cant always do this. Designers generally are subjective, intutive, and facile with physical concepts, and Synthes' e e@ vvvy K * a « »>@ e € ey -IZRE @,2@ * +4 ) nts pss ns op rays nnn mena patty pen ‘separated and identified. In synthesis, he parts are put together to form a coherent design solution. The aiference Between programming and design i the alerence between analysis and synthesis Programming IS analysis. Design IS synthesis. ‘You may not perceive the design process in terms of analysis and synthesis. You may even question problem sohing as ‘an angxoach. You may think ofthe desian process as “Somatonee J think we corive ata solution before we iow what dhe Drobiem . Wesay: “Rf naxt design wi be Round! "without iogtc or analysis. Siviliam Pete ‘a creative effort. Itis. But the creative effort includes similar stages: analysis becomes preparation or exposure, and ‘ynihesis becomes iluminaton or insight. The total design proces Is, indeed, @ creale process. Does programming inhibit creativity? Definitely not! Programming establishes the considerations, the limits, and the possibilties ofthe design problem. (We prefer tonsiderations""o ‘constraints to avord being petulant ) Creativity thrives, ‘when the limits of a problem are known, The Separation Programming Design Programming precedes design just as analysis precedes synthesis. The separation of the two is imperative and prevents tial and-error design alternaiives. Separation is central to an understanding of a rational architectural process, which leads to good buildings and satisfied cliens. ‘The problem-seeking method described in this book requites a distinct separation of programming and design. ‘Most designers love to draw, to make thumbnail skeiches, "as they used to call these drawings. Today, the jargon is conceptual sketches “and schematics. ‘Call them what ‘you will, hey can be serious deterrents in the planning of a successful building if done at the wrong time— before programming or during the programming process. Before the whole problem is defined, solutions can only be partial and Premature. A designer who can wait for a complete, carefully prepared program is like the tailor who doesn f bother 10 measure a customer before starting to cut the cloth. The Interface Programming Design ‘The product of programming is a statement of the problem. Stating the problem is the last step in problem seeking (programming), and its also the first step in problem soiving (design). The problem statement, then, is the interface sn programming and design. It the baton in a relay race. It the handoff from programmer to designer. In any ‘case. the problem statement is one of the most important documents in the chain that is the total oroiect delivery svstem. ‘While many theorists extol the virtues of the problem statement, few practitioners stop to formulate a statement, to verbalize it This programming method requires that you actually write out a clear statement of the problem. Since this statement is the fist step in design as well as the last step in programming, its composition must be the joint effort of the designer and the programmer Briefly, the five steps pose these questions: Goals— What does the client want to achieve, and Why’? Facts— What do we know? What is given? ‘Concepts— How does the client want to achieve the goals? Needs— How much money and space? What level of quality? Problem— What are the significant conditions atfecting the design of the building? What are the general directions the design should take? oeens Procedure 4123@ The five steps, then, ate not inflexibly stict. They usually have no consistent sequence, nor is the information scrupulously ‘accurate. For example, a 10,000-student university, a 300-bed hospital, and a 25-student classroom are only nominal rather than actual sizes. Information sources are not always reliable, and predictive capabiities may be limited ‘The steps and the information, then, do not have the rigor or the accuracy of a mathematical problem. Programming therefore, is a heuristic process and not an algonthm, As such, even good programming cannot guarantee finding the right problem, but it can reduce the amount of quesswork. The method is just as good as the judament of the people involved. The Whole Problem Function | Economy a RK Time Form It important to search for and find the whole prablem. To accomplish this, the problem must be identified in terms of Function, Form, Economy, and Time. Classifying information accordingly simplifies the problem while maintaining 2 ‘comprehensive approach. A wide range of factors makes up the whole problem, but all can be classified in the four areas thal serve later as design considerations. Too lite information leads to a partial statement of the problem and a premature and partial design solution. The appropriate amount of information is broad enough in Four Considerations Function Form Economy Time People Activities Relationships Site Environment Quality Initial budget Operating costs Life cycle costs 10 Past 11 Present 12 Future wor ausluns “Take a closer lok at Function, Form, Econony, and Time. There are tree key words to each consideration. Function inpies whats going 1o happenin the building." concems actives, etaborship of spaces, and people— thar number and characienstes. Key words are (3} people, (2) aelvites, ane (3) eationships Form relates to the site the physical environment (psychological, oo) and the qualty of space and construction. Form i is there now ‘and What wile there. “Key words are (4) st, (6) enviranment, and (6) quality Economy concems the inital budget and qualiy of construction, but also may include consideration of operating and life ‘eyce costs. Key words are (7) ital budget, (8) operating costs, nad (8) fe cycle costs ‘Time has three classifications — past, present, and future— which deal with he influences of history, the inevitability of ‘changes ftom the present, and projections into the future, Key words are (10) past, (11) present, and (12) future Framework Function Form Economy Time Use the four considerations to guide you at each step during programming. By establishing a systematic set of relationships between the steps in problem seeking and these considerations, between process and content, 2 comprehensive approach is assured. The interweaving of steps and considerations forms a framework for information covering the whole problem, All four considerations interact at each step. For example, in the first step when goals are investigated, function goals, form goals, economy goals and time goals should emerge. With each of these having three subcategories, the process. Includes asking twelve pertinent questions regarding goals alone Since the first three steps constilute the main search for information, three times twelve provides the basis for thirty-six pertinent questions. Gonsider these to be key questions. The answers will provide opportunities for further questions. The Information Index on the following pages indicates more than rinely tems in these three steps. Programmers do not have to know everything the client knows, but they should know enough of the client $ aspirations, needs, conditions, and ideas that will influence the design of the building, For this, programmers have to know the right ‘questions to ask, they start with the thirty-six subcategories. The considerations interact in the fourth step to test the economic feasibily of the project, and in the last step, they interact fo state the whole problem. This interaction provides a framework for classifying and documenting information. The classification qualities inherent in this framework are particularly useful in preventing information clogs when dealing with massive quantiles of information. ‘The categories are broad enough to classify the many bits of information gathered during programming without nit-picking and indecision, ‘The framework can be used as 2 checklist for missing information. As such, the orderly display of information on a wall becomes a goad visual scoreboard. One glance at a wall d'splay of graphic analysis material can spot what is missing and needs to be documented. It also provides a format for dialoaue amona the members of the team, Information Index ‘The framework can be extended to serve as an Information Index— a matrix of key words used to seek out appropriate information. These key words are specific enough to cover the scope of major factors and are unversal enough to be: negotiable for different building types. Even if some key words do nat seem to apply in a particular project, its useful to test them to ask a question based on those key words. If the test proves they are applicable, then those key words will ‘encourage a thorough search for information. They may offer a better and quicker understanding of the project. Most key words are ‘evocative words. "They tigger useful information. Charged with emotion as well as meaning, they tend to evoke a response, or even to suggest likely substitutions. ‘An Information Index may be designed to be very specific and tailored to one building type; but as all such checkitsts, it ‘would soon be obsolete. A aeneral character prolonas its usefulness. Information Index Facts TT Function re re Peel ene fonder Activities ‘Hierarchy of values. Comeunity characteristics , peas oa "a ai Security Valve of potential loss. =. Wesco me sees = ae ——— secu = sesneee ron axenies Loa eee = Form em eee = “ Sons tte . Soe tia ae wironment, Community improvements Code survey aa aoa oe mas eee es a ieoeoie — ae i oan ee ee Equipment costs papi Emaar casene Economy a eee a ne ooo oe ore, moss Operating Costs Minenizing f operating costs Energy source costs ieee, Ne ee Le oe Cons even ores peers eee ions ea race Time Seatehéynamdc sceies Space perereters ss ay rae ne = on a Occupancy dave ‘Durations nas Soret Se csan Concepts Needs Problem Tere pong Trea requremns ate asd impor! People groupe By organtation Npevtoranes Fe Acthny grouping By space ype ena Prorey By me = Hierarchy By location Security controls Parking requirements Sequential fow Ouedoor space reparemenss Separated flow Fenctioal aerated ed flow Functional relionshps Commminicatons Trhancements Tae development cons igor form coniders Specalfoundons hat wl ole bald design Enwronmental contol, Envronmental fences oncom Satery Neighbors Home batlotieng concepts ‘On-premis: fixed, ree. group address (Oftpremiz:satline, telecommuting. wiral office (Onertation Bung come SF Aecessioey Bud overall ficiency factor Character Quality controt Con control Badger esate analyse ‘Attnade toward the F Eticent alocation Balance budget budget and is ifr Muletincion versaiy ‘Cash flow analysis the fabric and geonr Merchandsing Energy budget the balding Energy contervation ‘Operating costs ‘Cont reduction Green budding rating Recycing Lie cycle costs Raapebiiey Train Trapheations of ange Tolerance growth on long.ran Convercisity erormance Expansiiy LUnear/concurrene scheduling Tine schedule Phasing Tenelcost schedule Two-Phase Process Program Development [| + + [ ‘Schematic Design Design Development ‘Schematic program and program development provide the information needed at the two successive design phases, going from the general scope to particular details. Programming is a two-phase process related to the two phases of design— schematic design and design development. ‘Schematic design depends on major concepts and needs, which should not be lost in the mass of information unusable in this phase. Designers must have information that clanties major design determinants— those factors that will shape the broad composition of the building. The schematic program must provide this important overall information useful in ‘schematic design However, equally critica is the filtering and the postponing of information that is waa Ug “The amount of information received from a client can be staggering. Donte the flood of information bother you. One trick isto determine when he information wil be most useful im sehemtabe desig orn design development. Ay quant of ent-fuinshed information can be organized for use al the appropiate phase. A programmer needs experience and good |udgment to Know in which phase to use the information — and needs even more experience and judgment to cul vial ‘and relevant information 1 eliminate data clog ‘Yes, people become data clogged with too much unorganized information, which causes confusion and prevents clear conclusions. Data cea paralvzes the thought processes, and 2 mental block against al information develops. Unable to comprehend it, designers may decide to ignore (Fall how up thew hands and say, ‘Don thother me wath all hose facts. Thaw what must do~ TM hat fe wformaton to ‘what | ateady know.” ‘One can assimilate any amount of information as long as its pertinent, meaningful, and well organized for effective use. Large amounts of nghiy erganized material are requred o expand the range of possbiies before 2 New and useful combination of ideas can be generated by the desicner not needed in schematic desian. Give designers only the information they need at the time they need it. Design development is what the words imply: the detailed development of schematic design. Program develooment Provides the specific room details— furniture and equipment requirements, environmental criteria (atmospheric, visual, and acoustic), and service requirements (mechanical and electrical). The second phase of programming may be in progress, ‘when the designer is doing schematic design. It should be pointed out, however, that the programmer, in dealing with an unfamiliar building type and entical functional areas, must seek and collect specific details earlier than normally needed in order to establish adequate and generalized ‘space requirements for schematic desian, Processing and Discarding Programming concems the processing of raw data into useful information. For example, course enrollments ata college ‘are nat useful information —untl they can be manipulated mathematically wath average clase size, penods attended per ‘week, total periods availabe for scheduling, and classroom utilization. Only when the process produces the number and Size of classrooms required does the raw data become useful information Raw data retating to climate anaiysis or soil analysis also becomes meaningful information only when architectural implications are determined. After that s accomplished, the raw data can be discarded or placed in an appendix ofthe program report, where it will not cause data clog. To quote an old saying, ‘Any fool can add, it takes a genius to subtract. “I takes a. ‘Yenius “to discard information as being irrelevant to a design problem or merely too trivial to affect the design one way of another. Although programming 's pimanly conscious analysis, intuton has its place— the sensitivity to know what information will be useful and what ‘should be discarded, The nisin discarding useful information s minimized with expenence. Abstract to the Essence Vv \ ib af ‘Architects are taught to take a holistic view ofthe problem, and even to go beyond the sphere of direct influences to ‘explore other possbiliies. However, going 10 far afeld increases he prospects of relevant information ‘Architects are also taught o bring order out of chaos, to establish an order of importance, to get to the heart ofthe matter. ‘Abstracting —distiing tothe essence must be an essential alent of the programmer. There must be a filtering process ‘that brings out only the major aspects of information. This is especially Uue in artiving atthe statement othe problem “There is always the danger of oversimplifcation in abstracting lo find the essence. Yel the danger of leaving something ‘out can be minimized by analyzing and conecousy inckuding al the complicating factors “There is need o amply in order to view the whole problem, but there is also need to abstract. You amplify and then narow down; you seek the ramifications ofthe infomation gathered, and then tum around to determine the bare Implication k's a continual process. You must be able to see the tees and tne forest not bath at ance but consecutively, ‘rom two diferent points of view. User on Team Users are experts in the use ofthe bulding. They may assume that they know what they want better than anyone else. “They may be rght, of they may ask he architect o a Consultant o fd Gut what they need. Users must be contributing ‘members of the project team. Dealing with users calls fr differen strategies to determine reasonable requirements; nevertheless, the bulking should benefi by intensive user paricpation in the programming process Users are sometimes suspicious that bulking will represent only the architect & self-expression. This concems the familar arqument involving form and function (On the other hand, the architects sometimes suspicious that users are being hosyncrai in thei raquements and that no one else can use the bulking i the future without major remodeling. Usually, architects love to design buildings talor made fo speciic user requirements that provide opportunites for novel designs. Ths is parbcularly tue of alored residences, in which the ownerlusers are drecly responsible for the outcome, Organizations and institutions with stale or dynamic conditions bring up the issue of idiosyncratic versus negotiable requirements. Bu remember, the users “first oncem is how ther needs willbe met when the building is occupied. Ways of Thinking To achieve effective group action, its important to understand how people think. Planning a large, complex building project involves many people of many minds. We are beginning to appreciate the multiplicity of ideas that emerges from the total planning team with i's multiheaded client and multineaded architect: the cient group and the architect group. By definition, each of these groups carries a different set of baggage with distinct needs, values, and objectives indeed, different ways of thinking. This is inevitable. Recognizing the differences is no less important than reconciling them, whether they exist between the client group and the architect group or among individual group members. The greatest differences exist within the architect group. These differences usually emerge in architectural programming, the frst phase Inthe design process. Problem seeking recognizes analysis and synthesis as two different processes calling for two different ways of thinking. To determine an organization § needs related to a proposed building project, senior management generally assigns a ‘group to work with architectural programmers, the first contingent of the architect group. This group might include people from the top to the bottom of the organization chart. If needed, management brings in outside consultants to augment the know-how of the client group. AS to be expected, each participant comes with certain biases and viewpoints that are all valid and important. ee | ees Ree ‘Some people are solution ororted, This kind of thinking secks a soksion before distinguishing the pars ofthe problem ‘Traneqlantng a Castors builing to New Varo vice versa isan example ofthis sppranch toward design thinking ‘Ths kn of thinking led to dominance ofthe Iniratcral Style of building. the same tl, the ste-and lass bulking, ‘asl ferent geographilocaions This hind of tnking also explans the Texas Cape Cod. hese cases, solutions ‘ee eenied Before the problems were solved ‘We contend that problem solving sa valld approach to design: therefore, problem definition should be the fist "epin the design process, Pechaectral design fie mas everyting ses jou cant solve problem unos: you knw ne ee Lee | | | @-@ eS td ag Se Analytical thinking sid tobe base on the lat sce one bean, along wth ose and versal functions. The nat ile hands the aby to synnesize, along wth itutve ana spatal capabiies Tiss way programmers ana designers predominant use one part ef the bran mexe than th oer. It we accop this notion, we can cope with the multiply of thought between programmers and designers. we practice ‘group action, we can put the many ways of thinking to work fo us Analysis is what the exit process of programming i all about Yet some sclutionaranted and intutve pale tend to rest anaysi where the pans are sopratad and etary wetfed ‘Successful programming relies on analysis. Successful design relies on synthesis. The possibly fer ceativty depends onthe unexpected, nietiated arangemert of te Oats 12345 12345 eG Intuition Logical thinkers do weil programming, They use an edery, welldocumented, step-by-step process Intutve thinkers do well when chunks of information are missing. They are scanners. The systematc approach bores ‘hem They sep steps inthe process to reach valudbe insights Ther weakness fs nt secing the nacessty of ‘documentation for ahers. They make poor programmers, bu they een make good designers Programming equies logic ints systematic search fr information. Designers Sh that intuition is important in decing ‘which infomation wil prove most useful. Sinee the design process encompasses programming and design, both logical and intultive thinkers are needed on the planning tear, 1234512345 aa Re “Tne quanutatve aspect of lformation gatneting nprogtamming makes some people expect too much exactness. On the ‘ther hand, the qualiave aspect provides an evecalve ambguly needed for ereatinly.Athough the ite of programming isto evel the problem there no assurance of precson, Thats not all ad. Precision may deter creat sung design Programming s heuristic: steps are not rigorously sequential, and information is hardly ever precise or complete. ‘when the problem is crucial, such as life safety, an algoihmie approach is taken Each step i igorously retraced in its proper sequence and rechecked fore precsin ofthe infomation. Exactude snot neveseary Yr the creation of design ‘Concepts Designers don tpt by the numbers. iy Teas led ‘chtects and engince's thinkin tee dimensions. They perceive ideas in coeret, tangible terms, Abstract thinking Gealing wih ideas generalized fom parcular instances 's vary feu for some of them, particulary thay are trains to Programming needs abstract thinking keeping pats malleable, jellyike, and loose until design synthesizes the phystea! solution [Abstract ideas help o suspend udament and prevent preconceptions until lhe informations gathered and processed ‘Tis amboguty provides that leeway necessary for allemativ design solitons, Many design concep can be derved fom one programmate concept ty sy eo oe rte Programming impos looking ahead, oF feedforward. Programming is tho prelude to design, butt does nol guarantee (ed design Postoccupancy evaluation feedback to may 2 Geaign oro mprove a subsequent progrark Unquestionably, edack's a great device to netune a new design o a utae rogram. Ideally, we should have both feedforward and feedback. The bullding program, as Information feedforward, forms the basis of design. The evaluation, as information feedback, offers refinement of design. Architects are taught to think in predictive terms-—to visualize the way things will bein the future. They must look ahead ‘and, occasionally, use the rear view mirror. In a medical analogy, if programming is diagnosis, post-occupancy evaluation is postmortem! And we learn from both ™ bd 4 . ra I * LS iu een Eee Programming demands cbjectivty We know, of course, tht complete abject is nat possible On tne otherhand we need to face facts squarely te hear what we might not wantfoMear Objective thinking relates tothe realise view offats ‘thot dstorion, but objecivy does not mean sens to socal conditions ‘Yer some people approach programming subjectively — a5 thay would design ‘Subjectty desis with personal prejucces brought othe process [As programmers, when we search fora clear, rational statement ofthe problem, our minds must think objectively “These days we hear lot about the art of architecture as a produc of ski and taste applied to certain popular aesthetic principles. We also hear about the science of atchecture asa product of knowledge that has been tested and verified, Anite activities emphasize intutve, subjective thinking, Scientific activites emphasize logical, objective ‘thinking. Architecture deals with Both, ‘hes causes alot of confusion. The way we cope wth this atinomy iso thnk of arcatects as practicing on the beach ‘ire fo werlds meet= the word of ars andthe word of scence, Artvecs often walk oo far and and forget how 10 ‘Sin, ce sm on fr ext sa ana forget howe walk Neverneless, we love cur beach where the as and sence ‘varia, Sy nature, arctactral deian meat be oven fo both words ee ee “There are four major design consierations function, form, economy, and time. Al four not just one, must be incuced in 2 ralonal design process ad, in some eases, simultaneous But some people work best on a singular approach They focus on one aspect of design Some users ate single-minded ‘about functon, some atchtects are ebsessed wh form, and managers emphasize economy and bme. Site most people Tmt thee thinking to their specaies, this he best argument for an inclusive team vith a Broad range of views ‘Avie mental grasp is needed to account or all pertinent considerations; however, the individual tam member can have ‘a angl track mid davoted solely to is or her specialty Unless empathic to other views to how other specialists ‘think an individual probably wont make a good member ef the team as either a programmer or as a designer. Sa Some people are prone to view the design problem in @ holistic approach. They see the forest Others see the trees; they love the details that make up the whole. Ths isan atomistic approach Some are big picture people conceptual thinkers. Others are detail people wo ike to work in design development orn Intenor design These are opposite ways of tinkang, Programming and design require both ways of thinking. “The team isthe new genius. We want diferent eyes some to see the forest, and others to see the trees. Although iS not absolutly necessary, soaing the forest frst has certain advantages. Ec Reduction Programmers and designers ake on exoard the design protien beyond the sphere of ect influences. They want Sipe aie possbites to be alnciaive Ths egos Storing sais, bua an Teach shoul excess asp ora sa heaven to But sare people ake it heyand he pul ora ina he unvese I becomes a universal problem tht va one ean ‘See uch es sabe A Spansh rover ies, Who gab oo much sqaeaes ie (one people mk at das an the Near ofthe mate, one shoul si he neamationreduchon down tothe scene; honever theres says the danger of versmpienon Inthe serch for be prob programming) 2 ‘he search forte solution (design, bot ine of thinking have We plsce The ck iso deese when ane Should take precedence over the oer aa es ees Complexity in programming can mean to many otueus sep, oe much deta oe Soon to many categories, cbiout rotons obscure gon, mulhesed cri and uncles ems Sore pele ero tension, atin, aed comple. er peo enn the inlet chalnge of smpyng bling turns easerce We advcate he iter ie general tat wth compen and werk toner simply trout ene ea process Overamplteaion oocire rough th tence to concaes ona ange arbect 3 protien fhe enc of a composing ars nantes haps he progam beccnes amp a sigh ‘yay is endangered ut ts poset sve fora simple hat promotes cary an meglity.Fundamantal simply eau 0 Sohieve and requires ciacipined ansivcal skis to divcriminate among staggering moun of rformston Effective Group Action Knowing different ways of thinking gives one a better understanding of inaividuals and how they behave in groups, as well a their distinctive patterns of thinking, perception, and problem solving— specifically, how they intermix in a team endeavor to develop a building program. You can sharpen your perception if you see the other side of the coin. You don t have to like what you see, but remember these points when organizing the programming process 4. The reconciliation of different ways of thinking cannot be made with a middle-of-the-road mentality. Consistently riding the median won t do it. There & a time when intuition must dominate logic and a time when it the other way around; a time for abstract thinking and a time for concrete thinking; and a time to put science over art and a time for the reverse. 2. People think differently because of background and experience. That’ why an intermoxture of distinct individuals is ‘so interesting. Group action aften produces unpredictable results, This may not please thase who try to program with a prejudice— with a building design in mind. But that not playing by the rules. For innovative result, let group action set Its own course sometimes elusive. When a large group of design professionals meet, expect many different points of view, different attitudes, and different opinions that may modify the information itself. ‘4, When in group disagreement, keep cool. Remember there is great value in the interaction of the architect group and the client group. Try to understand the different ways of thinking during the melee. A cool head can tolerate Confusion, Remember that we can leam to cope with many different minds and approaches— how to collaborate with people who think differently 6. Consensus Is difficult, yet itis possible. The problem-seeking method of programming acknowledges the real needs land desires of users. The end result is to reach agreement on how the proposed buildings should respond to those needs and desires. When there are insurmountable disagreements, then, obviously, management must step in. Delay this as long 2s you can, and give group action a chance to take hold. When it does, you may be delightful surpised at the results, Participatory Process Greater clientluser participation generates much more data. This increased involvement also causes more conflicting information. The users are concemed with the hope for greater satisfaction of their needs, the owner is concerned with cost reduction and cost control. Exposure of the owner & and users ‘differences is the first step in reconciliation, Conflicts are often reconciled by the intraduction of human values not previously considered by the cvmer. Participants on the team must communicate and be willing to cooperate with one another. This precludes the prima donna client or the prima donna architect who competes to play every role on the team, so as to make every decision in programming and in desian, Clients have the major responsibilty to be creative in programming, for they are the ones responsible for the operational outcome. Programmers can act as catalysts in seeking new combinations of ideas. They can test new ideas and spawn altematives. Designers must be creative in the design phase, for they are responsible for the physical and psychological environment. Programmers must keep the client from making premature design decisions during programrning. They should raise the lent § appreciation and aspiration for better buildings. In short, programmers should prepare for designers the best possible environment for creativity Background Information (P)1234@ ‘Although the fve-step process is the same for any building type, there may necessarily be a preparatory step. This will depend on the expenence (or inexperience) that the programmer brings to the project. For example, if the project were a ‘schoo! and the programmer had no experience in programming schools, then he or she should develop a background Understanding of schools. The pragrammer should vist similar schools, do library research, and talk to educators and. ‘consultants. He or she would need to understand the jargon of the client and the general nature of the building type. Programmers start with an analytical attitude They approach the project in an organized manner. Their background and ‘expetience relate to the specific type of building. not the preparatory step is required. With proper background information, programmers help the client to determine the number and kinds of consultants and \when they might be most effectively brought into the total desian process, Decision Making Good programming is characterized by timely and sound decision making by the clients— not the programmer. During programming, clients decide what they want to accomplish and how they want to do it. Programmers may have to evaluate ‘the gains and risks in order to stimulate a decision. They must identity for clients those decisions that need to be made. prior to design, Although complete objectivity is not required, programmers must emphasize the client § decisions and not their own, and. their questions should not be based on a preconceived solution. They may stimulate client decisions by spawning options and by testing programmatic cancepts. Programmers may ask, for example, ‘Have centralized kitchen services been considered as opposed to several decentralized kitchens? "Goals and cancepts must be displayed, so that decision ‘makers can understand alternative concepts and evaluate their effect on qoais. Establish Goals Goals are important to designers who want to know the what and wy of things rather than a list of spaces. They won t find inspiration in alist. They will find itn goals. Project goals indicate what the elient wants to achieve, and why. However, goals must be tested for integnty, for usefulness, and for relevance to the architectural design problem. To test them, itis necessary to understand the practical relationship between goals and concepts. If goals indicate what the client wants to achieve, concepts indicate how the client wants to achieve them. In other words, goals are implemented through concepts. Goals are the ends. Concepts, the means. Concepts are ways of achieving goals. The relationship of goals and concepts ts one of congruence. The test for the integrty of goals depends on their congruence with concepts. Practical goals have concepts to implement them. Lip-service goals, on the other hand, have no integrity and should be disregarded. They may well be faithless promises in a public relations publication with no plan to keep them. Regardless cof good intentions, itis not always what the client says but what he or she realy means, Collect and Analyze Facts Facts are important only if they are appropriate. Facts are used to describe the existing conditions of the site, including the physical, legal, climatic, and aesthetic aspects. These facts about the site should be dacumented graphically to be really effective. Other important facts include statistical projections, economic data, and descriptions of the user characteristics. There $ no end to facts. Yet programming must be more than fact finding. ‘The facts (and figures) can become too numerous to promote definite conclusions. Collect only those that might have a bearing on the problem, and organize them into categories. Seek facts that are pertinent to the goals and concepts. Massage these facts and figures so that become useful information. Process them to determine the architectural implicabons, Uncover and Test Concepts Itis critical to understand the difference between programmatic concepts and design concepts, which is very difficult for some people to grasp. Programmatic concepls refer to abstract ideas intended mainly as functional solutions to clients ‘performance problems without regard to the physical response. On the other hand, design concepts refer to concrete ideas intended 2s physical solutions to clients’architectural prablems, this being the physical response. The key to comprehension is that Programmatic cancepts relate to performance problems and design concepts relate to architectural problems. “The difference between programmatic concepts and design concepts is ilustrated in these examples: converibiltyis a programmatic concept, a corresponding design concept is 2 folding door. Shelter is a programmatic concept, a corresponding design concept is a roof Abstract ideas are required. Ideas must be kept in a pliable, vague form until the designer jells them into 2 physical ‘solution. Its really best if desian can wait until all 4. Priority ‘The concept of priority evokes questions regarding the order of importance, such as relative position, size, and social value. This concept reflects how to accomplish a goal based on a ranking of values For example, “To place a higher value on pedestrian traffic than on vehicular traffic ‘may relate to the precedence in traffic flow. OOTO “The concept of hierarchiy is related to 2 goal about the exercise of authority and is exoressed in symbols of authority. For ‘example, the goal Yo maintain the traditional hierarchy of miltary rank may be implemented by the concept of a hierarchy of office sizes. 2. ierarchy 3. Character ‘The concept of characters based on a goal conceming the image the clent wants o project in tems of values and the generic nature ofthe prec 4. Density ‘A goal for efcient land or space use, a goa for high degrees of interaction, ora goal to respond te harsh climate Coritons may ead othe appropriate degree of dens-y— low, medium, or high density. 5. Service Grouping ‘Should services be centralized of decentralized? Test the many services as being best centralized or best decentralized. ‘Should the heating system be centralized or decentralized? The library? And dining? And storage? And many other services? Evaluate the gains and risks to simulate cient decisions. But remember each distinct service will be centralized ‘or decentralized for a definite reason to implement a specific goal SA IY ‘Should activities be integrated or compartmentalized? A family of closely related activities would indicate integration to promote interaction, while the need for some kinds and degrees of privacy or security would indicate [ea] OO OO Al 7. People Grouping Look for concepts derived from the physical, social, and emotional characteristics of people—as individuals. in small Groups, and in large groups. Ifa client wants to preserve the identity of individuals while in a large mass of people, ask What size grouping would implement this goal. Look to the functional organization and not to the organizational chart, Which merely indicates pecking order e 2 O86 8. Home Base Home base is related to the idea of territoriality an easily defined piace where a person can maintain his or her individuality. While this concept applies to a wide range of functional setings— for example, 2 high school or ‘manufacturing plant recently, many organizations have recommended new seltings for office work. These officing Concepts are described in the following pages as on-premise or aft premise work settings, Officing Concepts Fixed Address: “This ancep refers toa weonl work eng where one person i assgned toa workspace. The concept shared “Mires emf for example, 2 anos 2esigns To vo of more poole doo ocapaney Llllll OoOoMo=. 8b. Free Address “This concopafrs to workspaces hata unassigned and shared on 2 first-come, fst serve bass, Hotelng refers tothe "Bbesaton of shared watapacee ons predetmiped sche bo dd 7 Aa Os OO Cox 8c. Group Address “This cancapefrs to a designated roup or tom pace acdgred fo 2

    You might also like