Projektering av användarcentrerade lokaler: ett processmönster för människa-datorinteraktion

Transkript

1 av användarcentrerade lokaler: ett processmönster för människa-datorinteraktion Jonas Murman Kungliga Tekniska Högskolan, I ABSTRACT In this paper, I show that a trimmed version of the traditional Swedish building construction process can inspire companies, active in the human-computer interaction field, to create a new development process that can merge a traditional waterfall methodology with an agile development methodology. I also show some key factors for reducing costs in this purposed process such as using standardized methods and components, experienced specialists and expert networks, as well as a lean and customer-oriented organization. Finally I provide some advice to developers of technical installation systems and smart building materials on how to approach the building construction process. Author Keywords Building construction process, user-centered design, technical installation systems, smart building materials. ACM Classification Keywords H5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous. INTRODUKTION När jag först introducerades till ämnet människadatorinteraktion (MDI) kom jag ofta i kontakt med ord och begrepp som jag kände igen från min arbetsvardag på ett byggkonsultföretag. Uppenbarligen har mjukvaruutvecklare och gränssnittsutvecklare inspirerats av byggprocessens gestaltningsmoment och utifrån detta lånat både begrepp och metoder. Typiska exempel på detta är roller som informationsarkitekt och interaktionsdesigner, men även begrepp som prototyper och skisser. Vidare finns det också en rörelse inom systemutvecklingen som ägnar sig åt design patterns, så kallade designmönster, vars ursprung direkt kan hänföras till en designteori som beskriver Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CHI 2008, April 5 10, 2008, Florence, Italy. Copyright 2008 ACM /08/04 $5.00 typlösningar för statsplanering och arkitektur [1, 2, 3]. Eftersom jag i snart 10 år har arbetat med att rita och utforma användarcentrerade lokaler för musik- och ljudproduktion, fann jag att det skulle vara givande att beskriva design- och byggprocessen för dessa speciella rum genom att använda termer från MDI. Min förhoppning är att denna beskrivning kan hjälpa människor som är verksamma inom MDI att bekanta sig med ett resurs- och kostnadseffektivt processmönster, som kan användas med stor fördel under vissa förutsättningar. Dessutom tror jag också att utvecklare av tekniska installationer eller byggmaterial kan behöva förstå byggprocessen och dess projekteringsskede för att kunna marknadsföra och sälja in sin produkt på rätt sätt. BYGGPROCESSEN För att beskriva den användarcentrerade designprocess jag själv är verksam i, måste jag först beskriva den process som används för större byggprojekt i Sverige [4]. Rent översiktligt liknar denna standardiserade byggprocess den klassiska vattenfallsmodellen, där stegvisa skeenden tar ett projektet från en initial vision, via pappersspecifikationer och produktion till en slutlig artefakt. Flödet för dessa skeenden är både linjärt och standardiserat. Traditionellt kalles de för programskede, projektering, upphandling, produktion och förvaltning (se Figur 1). Programskede Inom programskedet skapas produktbestämningen. Här analyseras och tillvaratas intressenternas kravställningar på byggnationen. Typiska krav och förutsättningar är förutom estetiska och funktionella användarkrav (brukarkrav) även övergripande kvalitetsmål och miljömål. Inom programskedet skapas även projektövergripande Program Upphandling Anbud Figur 1. Den traditionella byggprocessen 1

2 dokumentation såsom ekonomiplaner och tidplaner. Konkret utförs en mängd utredningar som sysselsätter en rad olika specialistkonsulter. Arkitekternas designinsatser är ofta gestaltande, dvs. de hålls på en konceptuell och övergripande nivå. Handlingarna som produceras i programskedet utgör beslutsunderlag för byggherren, som bestämmer om projektet skall gå vidare till projekteringen. Syftet med projekteringen är att skapa slutgiltiga bygghandlingar. Därför är det en stor mängd detaljer som måste lösas och koordineras för att byggnaden skall stämma överens med programhandlingens krav och önskemål. Detta innebär att projekteringsskedet är mycket omfattande och komplext. För att underlätta brukar projekteringen delas i ytterligare tre skeden, namngivna enligt deras avslutande handlingar: preliminärhandling, systemhandling och bygghandling. I preliminärhandlingarna fastställs byggnadens estetiska och funktionella gestaltning till en allenarådande, slutlig design. I systemhandlingarna fastställs och integreras byggnadens konstruktioner och tekniska system med den slutgiltiga designen. Kvar återstår bygghandlingarna som utgör det mest omfattande skedet. Här specificeras byggnaden mycket exakt och detaljerat så att byggentreprenörerna kan göra sina kostnadsberäkningar inför upphandlingen. Upphandling I upphandlingsskedet är det vanligt att entreprenörer och underentreprenörer tävlar mot varandra om att få utföra (delar av) produktionen. Vanligen tar de del av speciella förfrågningsunderlag som skapats i projekteringen. Inom produktionen uppförs den fysiska byggnaden. I detta skede engageras en stor mängd yrken och specialister, såsom installatörer, montörer och andra hantverkare. Vanligen kontaktas konsulter (och arkitekter) som varit aktiva i projekteringen om problem eller missförstånd uppstår eller om nya förutsättningar uppkommer. I slutet av produktionen sker uppföljningen, vilket innebär en besiktning av byggnaden och dess tekniska system. sskedet är den avslutande delen av byggprocessen. Eventuella efterkompletteringar eller anpassningar kan också vara nödvändiga, t.ex. om byggfusk upptäcks eller om brukarens behov har förändrats. ANVÄNDARCENTERING I BYGGPROCESSEN Eftersom det är resurs- och tidskrävande att uppföra en byggnad är det mycket kostsamt för användaren att driva igenom stora förändringar efter projekteringsfasen. De detaljrika telefonbokstjocka bygghandlingarna har ofta komplicerade korsvisa referenser, vilket gör de mycket besvärliga att revidera. Dessutom innebär upphandlingsavtal, materialflöden, tidspress och andra beroenden mellan leverantörer och entreprenörer att stora konceptuella förändringar kan vara omöjliga att driva igenom under produktionen. Det är alltså nödvändigt att användare och beställare bevakar sina intressen när de får störst påverkan till minsta kostnad, det vill säga i programskedet och i den tidiga projekteringen (innan systemhandlingen). För att kunna nå en god användarcentrering ligger det på användaren att vara aktiv och bevaka sina intressen, men detta kräver också en lyhörd konsultgrupp och en projektledning som tar sig tid att förstå och underrätta användaren. Även inom byggprocessen finns tendenser till genius design, dvs. att konsulter propagerar alltför starkt för egna övertygelser och lösningar. Vad som är användbart kan alltså skilja stort. En arkitekt kan med sitt designmandat driva igenom en estetetisk lösning som i sig innebär funktionsmässiga problem, precis som tekniska konsulter kan driva igenom tekniska lösningar som innebär estetiska problem. Beroende på beslutsordningen i projektet kan det även vara så att användaren aldrig får vetskap om dessa problem och konflikter. En användarcentrerad byggprocess kräver alltså att användaren är aktiv och engagerad men även att användaren blir informerad. ANVÄNDARCENTERING I MINDRE BYGGPROJEKT Så länge projektering och produktion utförs av någon annan än användaren måste samma förutsättningar gälla för användarcentreringen i ett mindre byggprojekt. Det är alltså viktigt att både användare och berörda konsulter kan enas om funktionalitet och estetik. En aktiv dialog i programskedet och i projekteringen är därför en förutsättning för att styra byggprojektet i rätt riktning. Vidare kan man se att vattenfallsmodellen med dess krav på beskrivande dokumentation är nödvändig att behålla så fort produktionen beror på en extern part som inte varit delaktig i projekteringen. EN ANVÄNDARCENTRERAD LÅGKOSTNADSPROCESS Jag kommer nu att övergå till att beskriva den lågkostnadsprocess som vi använder för att skapa användarcentrerade lokaler för musik- och ljudproduktion. Typiska begränsningar (constraints) som gäller för dessa projekt är att processen inbegriper ett fåtal lokaler, att lokalerna har fördefinierade användningsområden samt att en aktiv användarrepresentant finns tillgänglig. Metodik och organisation För att kunna garantera problemfria och högkvalitativa lokaler till en låg kostnad måste vi ha kontroll och överblick. En platt organisation med hög användarnärhet är en förutsättning för god överblick och förståelse för slutanvändaren. Likaså är det viktigt att forma erfarna specialistnätverk och att eftersträva standardisering för att kunna garantera kvalitet och utförande. Vad gäller specifika designtekniker använder vi främst skissning och prototypbyggande för att fastställa lokalernas utformning och funktion.

3 Användarnärhet Med användarnärhet menas en platt organisation där medarbetare har möjlighet till personlig kontakt med användarrepresentanten. På detta sätt underlättas förståelsen för användarens krav på funktion och estetik. Specialistnätverk För att hålla kostnaderna nere i projekteringen och produktionsskedet är det viktigt att främja ett specialistnätverk av experter och erfarna byggentreprenörer. Förutom att en erfaren projekteringsorganisation tar mindre tid och resurser i anspråk blir oförutsedda problem som uppstår under produktionen enklare att reda ut då en erfaren entreprenör ofta har löst liknande problem i tidigare projekt. Standardisering Det är även viktigt att föreskriva standardiserade material och lösningar som både byggentreprenören och användaren kan acceptera. Fördelarna är många med standardlösningar: för det första innebär det att kommunikationen med ovana användare förenklas eftersom det är lättare att acceptera välkända produkter, befintliga lösningar och vanliga byggnadsmaterial; för det andra innebär standardiserade lösningar en mer kostnadseffektiv projekterings- och produktionsprocess, då dokumentation och tekniska lösningar från tidigare projekt kan återanvändas. Dessutom innebär standardlösningar också att estetiska och tekniska prestanda kan garanteras på ett mycket tillfredställande sätt. Skissning I den mest typiska designprocessen är det planlösningen som är viktigast att fastställa, då akustiken i lokalerna och ljudisoleringen mellan lokalerna är som mest beroende av en god planlösning. För att fastställa planlösningen brukar vi och användarrepresentanten iterera olika lösningar genom klassisk skissning under ett par informella möten. Vanligen brukar denna process gå fort, då användaren (efter vår expertinput) snabbt gör sig en bild om vilken planlösning som är den mest optimala. För att underlätta användarens designbeslut brukar vi även skapa en möjligt lösningsrymd genom att visa bilder på tidigare projekt och färdiga designförslag. Prototypbyggande Då det inte är kostnadseffektivt att bygga modeller i skala 1:1 (eller att göra mindre modeller i kartong) använder vi i princip alltid datorbaserade beräkningsverktyg och visualiseringshjälpmedel. Genom erfarenhet har vi upptäckt att det är viktigt att presentera volymmässigt korrekta 3Dmodeller av lokalerna, men att det även är viktigt att behålla ett skissartat utseende på dessa så länge den slutliga designen är obestämd. För trots att vi använder CADverktyg är det kostsamt att göra förändringar även i projekteringens sena produktion. Vi vill därför gärna använda oss av enklare prototyper för design och akustikberäkningar så länge lokalernas design fortfarande modifieras. Upphandling Anbud Figur 2. Modifierad byggprocess Processbeskrivning Den byggprocess vi själva brukar driva genomgår i stort samma skeden som den traditionella byggprocessen, dock ställer vi mindre krav på formalia och dokumentation, vilket brukar fungerar väl så länge projektet är begränsat och har få intressenter. På grund av de lägre formaliakraven kan de ingående skedena löpa i varandra i högre utsträckning (se Figur 2). Detta ger att programskedet vanligen infogas i projekteringen och att vi inom projekteringen inte heller har något systemhandlingsskede, då de tekniska systemen vanligen är få till antalet och installeras först i slutet av produktionen (utanpå det ljudisolerande, akustiska skalet). Den mest användariterativa delen är den initiala projekteringen. Där börjar vi oftast, i likhet med inredningsarkitekternas projekteringsprocess beskriven i [5], med att säkerställa lokalernas funktion och estetik genom täta användarkontakter. När lokalernas planlösning, utseende och tekniska funktioner fastställts påbörjas produktionen av bygghandlingar. Men eftersom vi vill undvika onödig och betungande formalia (i form av tidplaner, aktivitetslistor, verksamhetsbeskrivningar, rumsbeskrivningar m.m.) infogas den mest väsentliga informationen i ett enskilt beskrivande dokument samt i mycket detaljerade planritningar och sektionsritningar. Eftersom dessa ritningar är mycket bildlika och även använder sig av standardlösningar (beskrivna i dokumentationen) tjänar de ofta som förfrågningsunderlag då byggentreprenören utför sina kostnadsberäkningar. Eftersom det är vanligt med praktiska komplikationer under produktionen brukar vi återigen bli iterativa, men nu i vår kontakt med byggentreprenören. Här handlar det oftast om att på kort tid resonera sig fram till lämpliga och rimliga lösningar på oförutsedda händelser. För att säkerställa lokalernas funktionalitet brukar vi även utvärdera dem med diverse tekniska mätmetoder. ETT MÖJLIGT PROCESSMÖNSTER FÖR MDI Med inspiration från design patterns -rörelsen vill jag nu introducera möjligheten att använda denna lågkostnadsprocess som ett processmönster i ett företag som arbetar med utveckling av datorbaserade och interaktiva gränssnitt för externa beställare. Som utgångspunkt tänker jag mig att det berörda projektet delar begränsningar med ovanstående process, dvs. att det är småskaligt, att utvecklingen sker för ett välbeskrivet 3

4 användningsområde och att en aktiv användarrepresentant finns närvarande. Processformen kräver alltså att det går att utnyttja en liknande metodik och organisation som beskrivits ovanför. Detta innebär en kundnära och platt organisation och att det går att använda sig av erfarna specialister i såväl projekteringen som produktionen. I kundmöten används skisser och prototyper för att säkerställa en användarcentrerad och användbar design. Dessutom är det noga att standardiserade lösningar, metoder och komponenter främjas, då det blir lättare att säkerställa funktionalitet och låga produktionskostnader. Vad gäller projekteringen anser jag att målet skall vara att ta fram beskrivande bygghandlingar i form av en välfungerande fullskaleprototyp. Denna prototyp fungerar därefter som en mall för produktionen. Här finns alltså en skillnad mellan byggprocessen och MDI-processen, eftersom det ofta går att utveckla en mjukvaruprototyp på samma plattform som den slutliga produkten. Detta innebär att steget mellan prototyp och produktion inte är lika tydligt och abrupt som byggprocessens åtskillnad på bygghandling och byggnad. Inom MDI är det därför möjligt att projekteringsskedet och produktionsskedet överlappar varandra i högre grad. Dock finns det en risk med detta att man hamnar i ett kostsamt och evigt prototypstadie, den s.k. eviga betan (perpetual beta). Detta stadium vill jag dock frångå, då själva syftet med denna process är att lämna över drift och vidareutveckling till användaren när produktionen har avslutats. Inom produktionen ser jag ingenting som hindrar att den utförs med utvecklingstekniker som Agile, Scrum eller extreme Programming. Likaså kan även prototyperna framtas med hjälp av dessa processer, även om de snarare borde vara kollage av standardlösningar. Återigen skiljer sig MDI-processen från byggprocessen då produktionen kan ske in-house istället för hos en extern part. Upphandlingsskedet blir därmed onödigt, samtidigt som kraven på omfattande dokumentation och formalia blir mindre, vilket i sin tur ger en ännu mer komprimerad utvecklingsprocess (se Figur 3). Eftersom de stora vinsterna i ett konsultföretag ligger i att sälja tidigare arbete om och om igen, vill jag betona vikten av att bygga upp en dokumentbank av rationella metoder, standardlösningar och typprojekt. Fördelen med att skapa en sådan kunskapsbank är att kostnader och intäkter blir lättare att förutsäga. Dessutom är det ett sätt för Figur 3. Byggprocessen tolkad som en MDI-process med in-house -produktion kunskapsintensiva tjänsteföretag att göra sig mindre sårbara för personalomsättningar. För att summera vill jag vara tydlig med att påpeka att detta processmönster inte är tänkt att vara en universell metod för all utveckling inom MDI. Konsekvensen av de ovannämnda förutsättningarna och den starka betoningen på standardisering innebär att processen är som bäst lämpad för ett moget och konsekvent vardagsarbete där man utvecklar en väl definierad standardprodukt för en väl definierad användare och att man därutöver inte är ansvarig för systemdriften och vidareutvecklingen när produkten har nått förvaltningsskedet. Typiska exempel på sådana beställningar kan vara ett företag som behöver hjälp med att skapa en specialdesignad datorapplikation, en webbsida eller ett skräddarsytt gränssnitt till en affärssystemmodul som arbetar mot en (intern) databas. SMARTA MATERIAL I BYGGPROCESSEN För den som utvecklar smarta byggmaterial eller tekniska system som liknar de som beskrivs i [6] kan det vara till stor nytta att förstå hur byggprocessen fungerar. Framförallt är det grundläggande att förstå att det är i programskedet och i projekteringen som alla materialval, ytskikt och tekniska system väljs och fastställs. För en utvecklare av smarta byggmaterial eller produkter som kräver tekniska stödsystem är det alltså som mest effektivt att göra sin produkt medveten hos dem som är verksamma inom byggprocessens tidiga skeenden, dvs. arkitekter, konsulter och beställare. Har produkten estetiska kvaliteter är det i regel arkitekter och beställare som är mest intressanta att uppvakta. Har produkten tekniska kvaliteter är det i regel mest verksamt att uppvakta konsulter med specialistkompetens inom området, speciellt om produkten löser ett känt problem inom det tekniska fältet. Oavsett vem som uppvaktas är det mycket viktigt att produkten har ett namn som är lätt att komma ihåg och är relevant för produkten. Vidare behöver produkten även goda stödsystem i form av professionella ordersystem och produktidentifierande nummer som minimerar eventuella misstag i föreskrivande dokumentation (som att fel produkt eller fel kvantitet föreskrivs). Likafullt är det viktigt att leverantörer och tillverkare av produkten kan hålla utlovade leveranstider för att inte försena produktionen. För att öka uppmärksamheten kring produkten är det vanligaste tillvägagångssättet att använda ambulerande försäljare med personlig kundkontakt, eller att använda sig av eventform där någon slags seminarieverksamhet kombineras med produktinformation. Även mässnärvaro och permanenta utställningshallar är metoder som ofta används. Som producent av byggmaterial eller tekniska installationer är det alltså viktigt att kunna visa att produkten utgör ett professionellt, verkligt och kostnadseffektivt alternativ. Förutom att visa att den används av andra och är det också en konkurrensfördel om det går att bevisa att den är lätt att

5 integrera med befintlig infrastruktur och att använda i befintliga produktionsorganisationer. För att underlätta för aktörerna inom projekteringen är det även viktigt att det är enkelt att få tag på varuprover och beskrivande information. Traditionellt har företag använt sig av fysiska varukataloger - men då dagens projekteringsdokumentation oftast använder sig av webbaserade dokumenthanteringssystem är det lika nödvändigt att komplettera den klassiska katalogen med en lättnavigerad hemsida där tekniska data och annan nödvändig information finns tillgänglig i standardiserade filformat (vanligen i DWG-, DXF- och PDF-format). SAMMANFATTNING Syftet med denna artikel är att visa att den traditionella byggprocessen och en modifierad version av denna process kan inspirera företag som är verksamma inom människadatorinteraktion att utveckla nya designprocesser som kombinerar traditionell vattenfallsutveckling med iterativa utvecklingsmodeller. I artikeln har jag också tagit upp några typiska faktorer som kan minska kostnaden i en sådan specialiserad process. Avslutningsvis har jag också delat med mig av ett par råd för den som är intresserad av att introducera smarta byggmaterial eller produkter med tekniska stödsystem i större byggprojekt. TACK Jag vill främst tacka kursledningen för MDIfortsättningskurs 2008 som lärt mig att betrakta både byggoch designprocessen på ett nytt, kraftfullt och mer reflektivt sätt än vad jag tidigare har gjort. Dessutom vill jag även passa på att tacka min mycket generöse chef för att han även tillåtit mig att skriva delar av denna artikel på (betald) arbetstid! KÄLLOR 1. Alexander, C., Ishikawa, S., Silverstein, M. A Pattern Language. New York: Oxford University Press (1977). 2. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional (1994). 3. hcipatterns.org 4. Nordstrand, U. Byggprocessen. Liber (2000). 5. Eiserman, M. av inredning. Svensk byggtjänst (2003). 6. Vallgårda, A., Redström, J. Computational Composites. Proc. CHI 2007, ACM Press (2007),