Tron på den strukturerade byggprocessen som medel att skapa bra byggnader växte sig stark på sextiotalet. Som en naturlig följd av detta efterfrågades också ett strukturerat angreppssätt på byggnadernas utformning. Man sökte analyserade byggnaders funktioner, delade upp dem i kategorier, analyserade de erforderliga förutsättningarna för varje kategori av funktioner för att sedan omsätta detta i olika fysiska byggnadslösningar. Sofistikerade metoder för programmering av byggnader utvecklades som ett svar på dessa behov. Programmering var egentligen ett vagt begrepp som jag så här i backspegeln inser att många, åtminstone inledningsvis, hade diffusa uppfattningar om. Man kan säga att programmet var en handling som i förväg skulle definiera alla ingående kvaliteter och komponenter i byggnaden. Detta skulle helst ske så att det fanns stora friheter att utforma byggnaden utifrån arkitektens konstnärliga idéer utan att de funktionella förutsättningarna motverkades. Om man vill använda en metafor kan man säga att det var en förteckning över byggnadens ingredienser på samma sätt som i ett matrecept, men att det krävdes en arkitekts yrkesskicklighet för att tolka detta i form av ett hus precis som det krävs en skicklig kock för att laga en god måltid av de ingående ingredienserna i receptet.
Det kanske är svårt att numera förstå att dåtidens arkitekter hade så svårt att inse a
tt man faktiskt kunde beskriva en byggnads egenskaper och kvaliteter i ord för att sedan ha det som underlag för utformning. Jag fick min första anställning som arkitekt 1973 delvis på grund av att jag hävdade att jag kunde programmering, något som man förstått var en nödvändighet för kontoret. Eftersom det knappast ansågs vara vare sig särskilt statusfyllt eller arkitektmässigt att ”skriva en byggnad” som man sa så fick jag mycket fria händer och kom att ha ansvar för programmerings- och förprojekteringsarbete i ett antal av kontorets största och mest prestigefyllda projekt, medan flera av mina jämnåriga kamrater, som avsåg att ha en mer traditionell arkitektkarriär, fick nöja sig med att skraffera ritningar, rita rent skisser och framställa perspektiv under överinseende av en äldre ingenjör.[1]
Om man tänker i designteoretiska termer så är det ganska förvånande att det i början var så svårt för arkitekter att inse att man kunde göra en språklig representation av en byggnads kvaliteter och egenskaper, medan det var fullständigt naturligt för dem att man gjorde en tvådimensionell representation av byggnaden på papper. Ritningen ansågs som verklighet och dessutom ett slutresultat av arkitektens möda. Konsten att bygga för att inte tala om att använda byggnaden var av mindre intresse, vilket kanske delvis förklarar varför uppföljning av hur det blev och hur det fungerade inte alltid stått högt upp på arkitekternas lista över nödvändiga aktiviteter.[2]
Vi trodde vid den tiden att programmet var garanten för en god byggnad. Vi menade att det fanns ett direkt kausalt samband mellan ett väl skrivet program och hur byggnaden sedan kom att fungera för sina brukare. Det fanns emellertid lite olika sätt att se på programarbetets roll. Den dominerande amerikanske designteoretikern William Peña[3] som kom att ha ett starkt inflytande på arkitektpraktiken främst i USA men också i Europa hävdade att programarbetet inte var en del av designprocessen. Han menade att man först skrev ett program, vilket förankrades hos beställaren på det sätt som ansågs nödvändigt. Sedan lämnades programmet över till en arkitekt som ritade ett hus med programmet som grund. Det var direkt fel att arkitekter skrev programmet för byggnaden och naturligtvis en omöjlig tanke att programförfattaren skulle öva inflytande över byggnadens konstnärliga gestaltning. I vissa länder, exempelvis Frankrike, fanns regelverk som förbjöd denna sammanblandning mellan rollerna eftersom det skulle kunna förvrida konkurrensen om projekteringsuppdragen om vissa arkitekter kunde påverka, eller hade djupare kunskap om, programmets innehåll.
I Sverige kom vi emellertid att utveckla en annan praxis där inte sällan samma kontor fick ansvar för både program och detaljprojektering. Vi menade att programarbetet var en del av designprocessen och att det ständigt skedde en dialog mellan program och gestaltning.[4] Skissandet användes för att utreda vissa företeelser som sedan kunde läggas fast i programmet medan programmet satte gränser och nivåer för det arkitekterna gestaltade. Ofta var emellertid rollerna uppdelade på så sätt att en arkitekt hade ansvar för programmet och en annan för byggnadens gestaltning. Resultatet av detta gemensamma arbete var ofta ett detaljerat program åtföljt av en relativt detaljerad gestaltning av byggnaden som emellertid inte var den slutgiltiga lösningen utan endast en illustration till vad programmet avsåg.
Den åtskillnad som man gjorde mellan programmering och gestaltning ställde vissa krav på framför allt programförfattaren. Det ansågs fel att programmet styrde byggnadens konstnärliga utformning. Man talade om en strikt åtskillnad mellan funktion och lösning. Funktionen låg på programförfattarens ansvar, men hur det skulle lösas i form av en byggnad genom val av teknik och material var den gestaltande arkitektens uppgift. Så här i efterhand måste jag erkänna att det var en ganska nyttig övning att göra denna strikta åtskillnad, men ibland kunde det ta sig rent fundamentalistiska former och bli smått absurt. I programmet angavs alla mätbara företeelser, samt all utrustning som skulle finnas inklusive installationer och media för att tillfredsställa en viss verksamhet. Vidare angavs alla samband som krävdes mellan verksamheter, samt kapaciteter av olika slag. Det ansågs inte helt korrekt att ange ett rums mått utan det skulle endast anges vad verksamheten krävde för utrymme. Man fick inte ange att ett rum exempelvis skulle vara helkaklat utan fick då skriva ”spolbart i sin helhet”, eftersom det kunde hända att arkitekten valde rostfri helsvetsad plåt av estetiska skäl och då skulle den friheten finnas så länge det uppfyllde kravet på spolbarhet.
Funktion[5] var tidens honnörsord och på en väl definierad funktion följde automatiskt en hög användbarhet (usability). Förklaringen till detta var att usability ansågs vara huvudsakligen en följd av en byggnads fysiska gestaltning, och den kunde man ju kontrollera om man definierat verksamhetens behov i form av funktioner hos byggnaden i programmet. Idag när vi vet att användbarhet också beror på hur tillfredsställd man är med en produkt inser vi att det funktionella inte alltid är användbart och att en produkt inte heller behöver vara funktionell för att vara både tillfredsställande och användbar. Vi behöver bara tänka på olika former av mode för att inse detta.
Nu vore det nog lite förmätet att påstå att vi inte visste bättre på den tiden. Det kanske var så att det kausala sambandet mellan funktion och användbarhet var starkare på 70-talet än det är i dagens snabbt föränderliga upplevelsesamhälle. Jag kastar bara ut tanken nu, men återkommer i ett senare avsnitt med reflektioner kring hur man med hjälp av Maslow’s behovstrappa[6] skulle kunna fundera över olika tiders syn på vad som är användbart och ändamålsenligt.
Nu måste det sägas att synen på programmering och projektering inte var enhetlig vid den här tiden. Eftersom det var ett område i stark utveckling uppstod många olika varianter och tolkningar både av hur det genomfördes, vad det innehöll och vilken nyttan var. För mig var programarbetet från början ett medel att tillsammans med slutanvändarna komma fram till lösningar som skulle fungera väl för deras verksamhet. I de projekt jag genomförde var således kreativt arbete där arkitekter och företagets anställda skissade och byggde modeller tillsammans viktigt. Jag menade att det inte var möjligt att bara ange en kvantitet eller kvalitet i programmet. Det krävdes också att man fick prova sig fram och på så sätt förstå vad det tänkta programkravet innebar i verkligheten. Programhandlingen med åtföljande illustration var då resultatet av detta samarbete men också ett kontrakt mellan arkitekten och slutanvändaren som angav hur byggnaden skulle vara beskaffad.
Programarbete var ett viktigt led i strävan att skapa bra byggnader som var användbara, men inte den enda nyheten under den här tiden. En annan fråga som arkitekterna under 70-talet nödgades intressera sig för var hur man skulle samverka med de anställda som skulle bruka byggnaden man ritade. Nästa avsnitt kommer jag att ägna åt hur metoder för brukarsamverkan utvecklades och då speciellt beröra mina egna erfarenheter.
Det kanske är svårt att numera förstå att dåtidens arkitekter hade så svårt att inse a
tt man faktiskt kunde beskriva en byggnads egenskaper och kvaliteter i ord för att sedan ha det som underlag för utformning. Jag fick min första anställning som arkitekt 1973 delvis på grund av att jag hävdade att jag kunde programmering, något som man förstått var en nödvändighet för kontoret. Eftersom det knappast ansågs vara vare sig särskilt statusfyllt eller arkitektmässigt att ”skriva en byggnad” som man sa så fick jag mycket fria händer och kom att ha ansvar för programmerings- och förprojekteringsarbete i ett antal av kontorets största och mest prestigefyllda projekt, medan flera av mina jämnåriga kamrater, som avsåg att ha en mer traditionell arkitektkarriär, fick nöja sig med att skraffera ritningar, rita rent skisser och framställa perspektiv under överinseende av en äldre ingenjör.[1]Om man tänker i designteoretiska termer så är det ganska förvånande att det i början var så svårt för arkitekter att inse att man kunde göra en språklig representation av en byggnads kvaliteter och egenskaper, medan det var fullständigt naturligt för dem att man gjorde en tvådimensionell representation av byggnaden på papper. Ritningen ansågs som verklighet och dessutom ett slutresultat av arkitektens möda. Konsten att bygga för att inte tala om att använda byggnaden var av mindre intresse, vilket kanske delvis förklarar varför uppföljning av hur det blev och hur det fungerade inte alltid stått högt upp på arkitekternas lista över nödvändiga aktiviteter.[2]
Vi trodde vid den tiden att programmet var garanten för en god byggnad. Vi menade att det fanns ett direkt kausalt samband mellan ett väl skrivet program och hur byggnaden sedan kom att fungera för sina brukare. Det fanns emellertid lite olika sätt att se på programarbetets roll. Den dominerande amerikanske designteoretikern William Peña[3] som kom att ha ett starkt inflytande på arkitektpraktiken främst i USA men också i Europa hävdade att programarbetet inte var en del av designprocessen. Han menade att man först skrev ett program, vilket förankrades hos beställaren på det sätt som ansågs nödvändigt. Sedan lämnades programmet över till en arkitekt som ritade ett hus med programmet som grund. Det var direkt fel att arkitekter skrev programmet för byggnaden och naturligtvis en omöjlig tanke att programförfattaren skulle öva inflytande över byggnadens konstnärliga gestaltning. I vissa länder, exempelvis Frankrike, fanns regelverk som förbjöd denna sammanblandning mellan rollerna eftersom det skulle kunna förvrida konkurrensen om projekteringsuppdragen om vissa arkitekter kunde påverka, eller hade djupare kunskap om, programmets innehåll.
I Sverige kom vi emellertid att utveckla en annan praxis där inte sällan samma kontor fick ansvar för både program och detaljprojektering. Vi menade att programarbetet var en del av designprocessen och att det ständigt skedde en dialog mellan program och gestaltning.[4] Skissandet användes för att utreda vissa företeelser som sedan kunde läggas fast i programmet medan programmet satte gränser och nivåer för det arkitekterna gestaltade. Ofta var emellertid rollerna uppdelade på så sätt att en arkitekt hade ansvar för programmet och en annan för byggnadens gestaltning. Resultatet av detta gemensamma arbete var ofta ett detaljerat program åtföljt av en relativt detaljerad gestaltning av byggnaden som emellertid inte var den slutgiltiga lösningen utan endast en illustration till vad programmet avsåg.
Den åtskillnad som man gjorde mellan programmering och gestaltning ställde vissa krav på framför allt programförfattaren. Det ansågs fel att programmet styrde byggnadens konstnärliga utformning. Man talade om en strikt åtskillnad mellan funktion och lösning. Funktionen låg på programförfattarens ansvar, men hur det skulle lösas i form av en byggnad genom val av teknik och material var den gestaltande arkitektens uppgift. Så här i efterhand måste jag erkänna att det var en ganska nyttig övning att göra denna strikta åtskillnad, men ibland kunde det ta sig rent fundamentalistiska former och bli smått absurt. I programmet angavs alla mätbara företeelser, samt all utrustning som skulle finnas inklusive installationer och media för att tillfredsställa en viss verksamhet. Vidare angavs alla samband som krävdes mellan verksamheter, samt kapaciteter av olika slag. Det ansågs inte helt korrekt att ange ett rums mått utan det skulle endast anges vad verksamheten krävde för utrymme. Man fick inte ange att ett rum exempelvis skulle vara helkaklat utan fick då skriva ”spolbart i sin helhet”, eftersom det kunde hända att arkitekten valde rostfri helsvetsad plåt av estetiska skäl och då skulle den friheten finnas så länge det uppfyllde kravet på spolbarhet.
Funktion[5] var tidens honnörsord och på en väl definierad funktion följde automatiskt en hög användbarhet (usability). Förklaringen till detta var att usability ansågs vara huvudsakligen en följd av en byggnads fysiska gestaltning, och den kunde man ju kontrollera om man definierat verksamhetens behov i form av funktioner hos byggnaden i programmet. Idag när vi vet att användbarhet också beror på hur tillfredsställd man är med en produkt inser vi att det funktionella inte alltid är användbart och att en produkt inte heller behöver vara funktionell för att vara både tillfredsställande och användbar. Vi behöver bara tänka på olika former av mode för att inse detta.
Nu vore det nog lite förmätet att påstå att vi inte visste bättre på den tiden. Det kanske var så att det kausala sambandet mellan funktion och användbarhet var starkare på 70-talet än det är i dagens snabbt föränderliga upplevelsesamhälle. Jag kastar bara ut tanken nu, men återkommer i ett senare avsnitt med reflektioner kring hur man med hjälp av Maslow’s behovstrappa[6] skulle kunna fundera över olika tiders syn på vad som är användbart och ändamålsenligt.
Nu måste det sägas att synen på programmering och projektering inte var enhetlig vid den här tiden. Eftersom det var ett område i stark utveckling uppstod många olika varianter och tolkningar både av hur det genomfördes, vad det innehöll och vilken nyttan var. För mig var programarbetet från början ett medel att tillsammans med slutanvändarna komma fram till lösningar som skulle fungera väl för deras verksamhet. I de projekt jag genomförde var således kreativt arbete där arkitekter och företagets anställda skissade och byggde modeller tillsammans viktigt. Jag menade att det inte var möjligt att bara ange en kvantitet eller kvalitet i programmet. Det krävdes också att man fick prova sig fram och på så sätt förstå vad det tänkta programkravet innebar i verkligheten. Programhandlingen med åtföljande illustration var då resultatet av detta samarbete men också ett kontrakt mellan arkitekten och slutanvändaren som angav hur byggnaden skulle vara beskaffad.
Programarbete var ett viktigt led i strävan att skapa bra byggnader som var användbara, men inte den enda nyheten under den här tiden. En annan fråga som arkitekterna under 70-talet nödgades intressera sig för var hur man skulle samverka med de anställda som skulle bruka byggnaden man ritade. Nästa avsnitt kommer jag att ägna åt hur metoder för brukarsamverkan utvecklades och då speciellt beröra mina egna erfarenheter.
[1] Jag beskriver mina erfarenheter av flera av dess projekt i boken ”Architecture, Technology and Human Factors : Design in a Socio-Technical Context.” Kap. 2. sid. 126-150.
[2] Se vidare Granath 2001: Architecture - Participation of users in design activities.pdf
[3] Peña, William, 1977. Problem Seeking : An Architectural Primer. Boston: Cahners Books.
[4] Detta behandlas mer i detalj i ”Architecture, Technology and Human Factors : Design in a Socio-Technical Context.” Kap. 3.1. sid. 93-99.
[5] För den som vill läsa mer har Keith Alexander och jag skrivit en artikel ”A Theoretical reflection on the Practice of Designing for Usability” där begreppet funktionalitet behandlas.
[6] Se vidare http://sv.wikipedia.org/wiki/Behovshierarki
No comments:
Post a Comment