Prototyping - faser, typer och potentiell problematik

Prototyping - faser, typer och potentiell problematik Josefin Karlsson KTH Kungliga Tekniska Högskolan CSC Skolan för datavetenskap och kommunikation josefink@kth.se Maria Wikforss KTH Kungliga Tekniska Högskolan CSC Skolan för datavetenskap och kommunikation wikfors@kth.se ABSTRACT Prototyping is an activity within user-centered design and the field of human-computer interaction (HCI). This paper concerns the potentially problematic issue of the transition between early stages of prototyping - when the prototypes usually are imprecise - and later stages - which imply more detailed and advanced prototypes. Through reviews of literature and participation in a HCI-related project, we have found that this is an issue with a few unanswered interrelated questions. Our aim with this article is thereby to stress the understanding of the difficulties associated with the transition and also to suggest some possible approaches. Primarily because we find that making the process of interaction design - and the activity of prototyping in particular - more effective is of great importance for the future development of the work of designers - making the methodologies more usable. We find this to be of relevance to the field of HCI, especially within the interaction design process. Author Keywords Designprocess, gränssnitt, omdesign, prototyp, skiss. ACM Classification Keywords Evaluation/methodology, prototyping, user-centered design. INLEDNING I processen för att designa en digital artefakt ingår, inom den metodik som praktiseras inom människadatorinteraktion (MDI), i regel att man utformar interaktiva versioner av artefakten - prototyper - av olika slag under designprocessens olika skeden [3]. Man inleder generellt prototyparbetet med enkla, oprecisa skisser som ritas för hand på papper och vill vanligtvis landa i en interaktiv, detaljerad mjukvarubaserad prototyp. I den litteratur vi studerat som behandlar detta, är beskrivningar av den problematik som kan uppstå då man i något skede går från en odetaljerad prototyp till en mer precis, någonting som vi har saknat. För oss är det exempelvis inte trivialt i vilket skede man bör byta medium för sin prototyp, hur bytet av medium bör gå till och vad denna övergång kan få för konsekvenser gällande designbeslut. Vi ser heller inte tydligt hur detta korrelerar med graden av detaljrikedom och precision i prototypen. Vad dessa oklarheter kan få för konsekvenser i praktiken har vi även fått uppleva genom deltagande i ett användarcentrerat designprojekt med anknytning till människa-datorinteraktionsområdet. Det som vi intresserat oss för och funderat kring - och som vi syftar till att belysa i denna artikel - är således frågor relaterade till övergången, eller resan, mellan pappersprototyp och mjukvaruprototyp. De frågeställningar som vi kommer att utgå från i vårt resonemang är: Hur detaljerad och precis bör en pappersprototyp vara innan man övergår till att utveckla en mjukvaruprototyp? Bör designbesluten vara fattade innan övergången och är detta ens möjligt? Är det graden av detaljrikedom, snarare än valet av medium, som avgör hur prototypen bör klassificeras? I denna artikel kommer vi att resonera kring ovanstående frågor. Vi gör inledningsvis en genomgång och jämförelse av hur prototyper beskrivs och klassificeras, för att ge bakgrund till detta resonemang. Vi beskriver även hur vi själva upplevt att arbeta med prototyper i ett skarpt projekt, för att fördjupa förståelsen för problematiken. BAKGRUND De källor som vi utgått från har något skilda sätt att beskriva och dela in prototyper för arbetet med design av digitala artefakter. I detta avsnitt gör vi ett försök att ge en överblick över de olika synsätten som presenteras, och samtidigt peka på skillnader och likheter mellan dessa. Prototyper - definitioner och synsätt Preece, Rogers och Sharp beskriver prototyper som en av de fyra hörnstenarna inom interaktionsdesign. De definierar prototyper som:... a limited representation of a design that allows users to interact with it and to explore its suitability (s. 241) [3] och menar att dessa kan utgöras av allt från skisser nedtecknade på papper till komplexa mjukvarubaserade versioner av designförslagen. En annan definition ges av Beaudouin-Lafon och Mackay. De skriver att en prototyp är a concrete representation of an interactive system. (s. 1006) [1]. De ser alltså prototyper 1

som något som ger möjlighet att föreställa sig hur det slutgiltiga systemet kan komma att se ut. I likhet med synsättet hos Preece et al. - där prototyping räknas till en av hörnstenarna i interaktionsdesign [3] - pekar Westerlund på att prototyper är ett av de viktigaste redskapen för en designer [4]. Detta är något som även Löwgren och Stolterman trycker på då de beskriver skisser som designprocessens kärna [2]. Preece et al. menar vidare att prototyper kan användas för att besvara ett brett spektra av frågor, vilket hjälper designern att välja mellan olika alternativ. De pekar på att man beroende på vilken typ av frågor man vill få besvarade - som ofta hänger samman med vilket skede av processen man befinner sig i - bör välja olika typer av prototyper [3]. Det är ett synsätt som även sköjs hos Beaudouin-Lafon och Mackay som menar att det inte finns en allmän lösning för när under designprocessen en viss typ av prototyp bör användas, utan att detta är något som designern måste ta ställning till i varje steg utifrån den specifika situationen [1]. Samtliga källor anser, som framgår ovan, att prototyper är viktiga för design och designarbete, och i huvudkällorna är man överens om att olika prototyper passar i olika skeden av processen. Återkommande är även synen på prototypernas kommunikativa aspekter - framförallt då det gäller kommunikationen mellan designer och intressent, men även kommunikationen inom designteam och för designerns egna reflektion. De skillnader som, enligt vår uppfattning, finns mellan källornas synsätt på prototyper handlar i princip om vilka indelningar och benämningar som görs för att kategorisera dessa. I nedanstående stycke tittar vi således lite närmare på detta. Typer av prototyper Begreppsmässigt talar Preece et al. om low- och highfidelity-prototyper [3], medan Beaudouin-Lafon och Mackay gör sin motsvarande indelning i on- och off-lineprototyper [1]. Löwgren och Stolterman gör ytterligare en typ av indelning och skiljer mellan icke-dynamiska gränssnittskisser och dynamiska prototyper [2]. Enligt Preece et al. har low-fidelity prototyper låg precision, liten detaljrikedom och produceras ofta i papper, kartong eller liknande. Exempel kan vara storyboards och skisser gjorda för hand. High-fidelity prototyper har enligt Preece et al. hög precision och stor detaljrikedom. De pekar på att dessa ofta byggs i mjukvara och liknar slutprodukten utseendemässigt [3]. Beaudouin-Lafon och Mackay skriver att off-lineprototyper avser sådana prototyper som kan visas oberoende av en dator, såsom skisser på papper, scenarier eller videorepresentationer, medan on-line-prototyper per definition använder digital teknik och kan vara exempelvis interaktiva videorepresentationer, animerade digitala gränssnitt eller prototyper gjorda med utvecklingsverktyg för grafiska användargränssnitt [1]. Löwgren och Stolterman definierar gränssnittskisser som grova beskrivningar av ett system eller del av ett system, ritade på papper, som skapas för att användas som underlag för diskussion. Med dynamiska prototyper syftar de till interaktiva prototyper som antingen är gjorda i papper ( dynamiska pappersprototyper ) eller i digital form ( dynamiska digitala prototyper ) och skapas utifrån en tänkt dialog mellan systemet och användaren [2]. Utöver att göra en uppdelning i low- och high-fidelityprototyper beskriver Preece et al. även att man ofta ställs inför valet att ta fram en prototyp som antingen visar på förslagets bredd eller djup när det gäller funktionalitet. Om man väljer att visa bredd, det vill säga många funktioner men lite detalj, i sin prototyp benämns denna som horisontell, väljer man istället att satsa på djup det vill säga mycket detaljer för några enstaka funktioner, så benämns den istället som vertikal [3]. Beaudouin-Lafon och Mackay beskriver i sin tur prototyper utifrån tre premisser utöver hur de representeras (on-line/off-line). Dessa är: relevans av detaljrikedom (precision), interaktivitet, samt om prototypen är tänkt att användas som en temporär representation eller skapas med syfte att utvecklas till det slutgiltiga systemet (evolution). Gällande prototypingstrategier tar även Beaudouin-Lafon och Mackay upp vertikala och horisontella prototyper, men lägger också till andra möjliga strategier som i princip utgör varianter/kombinationer av dessa [1]. Uppdelningen av prototyper som görs av de olika författarna, i low- och high-fidelity respektive on- och offline, samt gränssnittsskisser och dynamiska prototyper har som nämnts vissa skillnader, men även likheter, enligt vår uppfattning. Där Preece et al. menar att low och high syftar till graden av detaljrikedom i representationen oavsett medium för prototypen, använder Beaudouin-Lafon och Mackay istället termen precision för att beskriva detta. Deras benämning on och off syftar då istället till mediet. Preece et al. indikerar visserligen även de genom sina exempel att low och high ofta är kopplat till vissa typer av medier, men skriver inte detta uttryckligen. Löwgren och Stoltermans indelning i gränssnittsskisser och dynamiska prototyper anser vi främst överensstämmer med uppdelningen hos Beaudouin-Lafon och Mackay eftersom de fokuserar på enskilda tekniker som de kopplar till specifika medier [1,2,3]. Typernas fördelar och nackdelar Preece et al., Beaudouin-Lafon och Mackay och Löwgren och Stolterman har som påvisats ovan något olika sätt att klassificera och dela in prototyper, i vilka vi dock ser några överensstämmande drag. När författarna av respektive verk presenterar för- och nackdelar med de olika typerna av prototyper framträder enligt vår uppfattning dessa drag ytterligare. Preece et al. pekar bland annat på att low-fidelityprototyper har fördelar som att de är billiga att ta fram och lätt kan användas för att utvärdera flertalet koncept. De 2

menar även att de lämpar sig för att identifiera krav [3]. Ett liknande resonemang förs av Beaudouin-Lafon och Mackay kring off-line-prototyper. De pekar på att off-lineprototyper har fördelen att de är relativt snabba att åstadkomma, vilket medför att dessa tillåter ett iterativt arbetsätt samt möjlighet att arbeta med parallella designförslag. Detta gör enligt Beaudouin-Lafon och Mackay att man kan utforska designsituationen och prova lösningar, utan att hindras av tekniska begränsningar eller brist på kunskap om ett visst datorverktyg eller programmeringsspråk. Beaudouin-Lafon och Mackay påpekar dock att även off-line prototyper kan vara begränsande i de fall där interaktionen med det slutgiltiga systemet förutsätter en teknisk egenskap som inte går att simulera [1]. Preece et al. lyfter å sin sida bland annat fram nackdelen att low-fidelity-prototyper inte är så användbara efter det att kraven på produkten har fastslagits. De pekar även på att de är begränsade när det kommer till hur bra de fungerar för användartest och att de inte är tillräckligt detaljerade för att specificera kod samt att de inte visar hur navigationen - eller gränssnittets flow - fungerar [3]. När det gäller high-fidelity-prototyper presenterar Preece et al. fördelar som att dessa är helt interaktiva och tydligt definierar navigationen. Andra fördelar som författarna pekar på är att high-fidelity-prototyper känns och ser ut som slutprodukten, att de kan fungera som en typ av specifikation och att de kan användas som ett redskap för att marknadsföra och sälja en idé. En av nackdelarna som Preece et al. beskriver gällande high-fidelity-prototyper är att de är dyra och tidskrävande att utveckla. De pekar även på att en utvecklare som lagt mycket tid på att ta fram ett prototypförslag inte gärna ändrar i detta av den anledningen [3]. Beaudouin-Lafon och Mackay identifierar ungefär samma nackdelar med on-line-prototyper, det vill säga att de är dyra och tidskrävande att skapa, och menar därför att dessa är mest effektiva under den senare delen av designprocessen, då man redan fattat beslut om grundläggande funktionalitet [1]. Som vi redan antytt i avsnittet Typer av prototyper, har Löwgren och Stoltermans beskrivning och uppdelning av prototyper gemensamma drag med de övriga författarnas. Dock har de ett något annorlunda fokus i sitt resonemang och tittar mer på enskilda tekniker. Vi anser att det finns likheter mellan Löwgren och Stoltermans gränssnittsskisser och dynamiska pappersprototyper och de tekniker som Preece et al. samt Beaudouin-Lafon och Mackay menar kan användas för att skapa low-fidelity- respektive off-lineprototyper. Vi anser även att likheter finns mellan Löwgren och Stoltermans dynamiska digitala prototyper och de tekniker som Preece et al. samt Beaudouin-Lafon och Mackay pekar på inom high-fidelity- respektive on-lineprototyper [1,2,3]. Fördelarna som Löwgren och Stolterman ser med gränssnittsskisser är exempelvis att designern med hjälp av dessa kan uttrycka idéer på ett konkret och begripligt sätt. Nackdelar som de för fram är att gränssnittsskisser kan vara omständigt att förändra (rita om) samt att de inte beskriver det tänkta systemets dynamik. En fördel med en dynamisk pappersprototyp är enligt Löwgren och Stolterman att den utformas på ett sätt som gör att den lätt går att manipulera. En nackdel som Löwgren och Stolterman ser med dynamiska pappersprototyper är dock att vissa funktioner kan vara svåra att gestalta i pappersform, vilket kan bli begränsande för designern. En fördel som Löwgren och Stolterman identifierar hos dynamiska digitala prototyper är vidare att de ger möjlighet att skapa en digital version av det tänkta systemet på ett sätt som går snabbare än att implementera designlösningen i den verkliga utvecklingsmiljön. En av nackdelarna som de ser är att den digitala prototypen kommer att sakna egenskaper som finns i det verkliga systemet, men att det ändå finns risk att prototypen uppfattas som slutgiltig och fokus hamnar på specifika detaljer [2]. ANVÄNDNING AV PROTOTYPER I SKARPT PROJEKT Efter att vi nu tittat på hur man i litteraturen behandlar prototyper, ger vi i följande avsnitt ett exempel på hur vi själva använde prototyper under arbetet med ett användarcentrerat designprojekt och resonerar kring de lärdomar och kunskaper vi ackumulerat i och med detta. Beskrivning av projektet Under hösten 2007 har vi deltagit i ett användarcentrerat projekt som genomförts inom ramarna för en kurs i människa-datorinteraktion vid skolan för datavetenskap och kommunikation (CSC) på KTH. Projektet har inneburit att vi tillsammans med fyra andra studenter med olika inriktning på KTH arbetat med omdesign av ett befintligt datorsystem. Detta system - som kortfattat kan beskrivas som ett program för automatiskt testning av programmeringskod, implementerat som ett webbgränssnitt - användes redan vid tidpunkten för projektet i programmeringskurser vid KTH. Projektet utfördes på uppdrag av CSC eftersom man där upplevt att det fanns flera problem med systemets gränssnitt, samt dess funktionalitet vid användning under laborationer inom kurserna. Hur vi arbetade med prototyper Under projektet arbetade vi utifrån de fyra huvudsakliga aktiviteter inom interaktionsdesign som Preece et al. pekar på. Dessa utgörs av att iterativt: identifiera behov och fastställa krav, utveckla alternativa designförslag, bygga interaktiva versioner av dessa förslag och utvärdera designen [3]. Det vi fokuserar på här är den tredje aktiviteten (att bygga interaktiva versioner av designförslagen) som vi nämnt tidigare innebär att ta fram prototyper. I vårt arbete med omdesignen av det befintliga datorsystemets gränssnitt använde vi prototyper på ett sätt som överensstämmer med den uppdelning som görs av Preece et al. i low- respektive high-fidelity-prototyper [3]. Detta innebar i praktiken att vi inledningsvis, med 3

utgångspunkt i idéer till designlösningar som vi brainstormat fram utifrån studier av designsituationen, gjorde enkla skisser i papper av de delar av systemet där vi ville göra de största förändringarna. Denna första prototyp var mycket begränsad, men utformad på ett sätt som gjorde att vi kunde demonstrera hur interaktionen med det omdesignade gränssnittet kunde komma att fungera för vissa utvalda funktioner. Arbetet med att skapa denna prototyp fyllde i sig en funktion i vår designprocess, eftersom detta hjälpte oss att konkretisera de idéer vi kommit fram till och gav oss ett lättöverskådligt underlag för diskussion kring dessa - en aspekt som vi nämnt tas upp i litteraturen. Prototypen fungerade även bra för att förklara och diskutera våra idéer med användare, men var däremot både för grund och för snäv för att kunna användas för testning av den övergripande funktionaliteten. I nästa steg av vår process valde vi, utifrån respons på lowfidelity-prototypen och vår analys av responsen, att direkt gå vidare till att utforma en high-fidelity-prototyp, som inom ramarna för kursen var tänkt att utvecklas i någon mjukvara för animering/interaktion såsom Macromedia Director eller motsvarande. Vi bestämde oss för att vi ville skapa high-fidelity-prototypen med datorprogrammet Adobe Dreamweaver, som används just för att konstruera webbgränssnitt. Detta för att komma nära känslan i det verkliga systemet, vilket enligt Preece et al. är en av fördelarna med just high-fidelity-prototyper [3]. En annan anledning till att vi valde att använda Adobe Dreamweaver var att detta är ett program som några i gruppen arbetat med tidigare och därför kände sig relativt bekväma med. Vi antog att detta skulle göra att vi kunde spara tid, som annars hade gått åt till att lära sig en för oss ny programvara, och istället använda denna tid till att utveckla idéer för innehåll och funktionalitet i gränssnittsförslaget. Då vi påbörjade arbetet med high-fidelity-prototypen insåg vi dock att det var många delar av gränssnittet som vi ännu inte fattat konkreta beslut om. Detta gjorde att vi ställdes inför ett dilemma, där vi i stunden uppfattade det som att vi hade två alternativ för vårt fortsatta arbete. De alternativ vi valde mellan var att antingen börja arbeta med den digitala highfidelity-prototypen direkt som vi planerat och därmed tvingas fatta grundläggande designbeslut under själva skapandet av denna, eller att fortsätta arbeta med papper och penna och på så sätt få en tydligare grund inför vår övergång till digital form. Vi beslutade oss för att snabbt göra ytterligare en prototyp i papper, men där vi till skillnad från den tidigare använde oss av både en horisontell och vertikal approach. Denna kan i det närmaste betraktas som en analog form av high-fidelity-prototyp eller en off-lineprototyp med hög grad av precision. Eftersom vi arbetade mot en deadline fanns vid denna tidpunkt i projektet inte tid för att testa den nya pappersprototypen på användare. Den användes därför endast som underlag för oss själva, vid implementationen av prototypen i Adobe Dreamweaver. Resultatet av arbetet med implementationen blev till slut en interaktiv prototyp av webbgränssnitten med både bredd och djup, mycket tack vare dessa förberedelser. Trots förberedelserna fick dock många beslut tas on the fly under implementationen. Den digitala high-fidelity-prototypen testade vi sedan på användare varefter vi gjorde smärre justeringar. Arbetet med Adobe Dreamweaver hade dock visat sig vara mer komplicerat och ta längre tid än vi beräknat, vilket gjorde att vi drog oss för att göra större förändringar i highfidelity-prototypen när den väl var klar, vilket liknar det som Preece et al. pekar på gällande utvecklarnas (o)vilja att förändra high-fidelity-prototyper [3], som vi tagit upp i avsnittet Typernas fördelar och nackdelar. Så länge man inte betraktar vår high-fidelity-prototyp som början till ett färdigt gränssnitt att bygga vidare på, behöver dock detta enligt vår uppfattning inte betraktas som ett stort problem, eftersom vi dokumenterade den respons vi fick genom användartesterna och på så sätt kunde redogöra för eventuella brister och potentiella förslag till förbättringar i den slutgiltiga prototypen. Erfarenheter från projektarbetet Då vi efter slutförandet av projektet såg tillbaka på vår arbetsprocess var den del som vi ansåg hade fungerat sämst just övergången från low-fidelity- till high-fidelity-prototyp, eller kanske egentligen övergången mellan en oprecis pappersprototyp till mer detaljerad mjukvaruprototyp. Eftersom vi koncentrerat oss på att konkretisera specifika delar av gränssnittet i vår första prototyp utgjorde denna ett tunt underlag för att skapa den typ av detaljerade, interaktiva, datorbaserade prototyp som vi ville åstadkomma genom vår high-fidelity-prototyp. En aspekt som ytterligare försvårade övergången till digital form var att vår tidiga prototyp inte visade på det tänka gränssnittets helhet och flow, det vill säga hur de olika delarna var tänkta att hänga samman. Detta är något som Preece et al. framhåller som en nackdel med low-fidelity-prototyper, vilket vi nämnde i avsnittet Typernas fördelar och nackdelar. Vi kunde identifiera flera problem i vårt arbetssätt, men ingen konkret eller definitiv lösning till hur vi borde ha gått tillväga. Ett sätt att betrakta anledningen till att vi fick problem när vi skulle skapa high-fidelity-prototypen, är att vi på en gång - direkt från vår första pappersprototyp - förutom att gå över till digital form, också försökte göra denna både bredare och djupare än den första. Naturligtvis hade en idé kunnat vara att göra en betydligt enklare digital prototyp som, liksom vår första pappersprototyp, var mer koncentrerad till ett fåtal specifika funktioner i systemet (vertikal), och inte fullt så bred (horisontell) - för att sedan eventuellt arbeta vidare på denna. Men då vi direkt såg att det fanns behov av att visa på bredd, hade kanske ett ännu bättre sätt för vår del varit att tidigare börja arbeta med mer detaljerade pappersprototyper. Beaudouin-Lafon och Mackay hävdar visserligen att det i vissa situationer kan vara mer effektivt att iterera den digitala prototypen flera gånger, än att göra off-line-prototyper i papper med hög precision [1]. Vi hann 4

dock aldrig bli så bekväma med den programvara som vi använde oss av, att en sådan mängd förändringar av prototypen, hade varit praktiskt genomförbara - något som vi tror är vanligt inom denna typ av projekt. DISKUSSION De tre frågeställningar som vi formulerade i inledningen till denna text och som vi syftade till att besvara var: hur detaljerad och precis en pappersprototyp bör vara innan man övergår till att utveckla en mjukvaruprototyp, om designbesluten bör vara fattade innan denna övergång och om detta är möjligt, samt om det är graden av detaljrikedom, snarare än valet av medium, som avgör hur en prototyp bör klassificeras. Det finns inget enkelt svar på frågan om hur detaljerad och precis en pappersprototyp bör vara innan man övergår till att utveckla en mjukvaruprototyp. Däremot har vi genom våra studier av litteratur kring prototyper, tillsammans med erfarenheter från vårt projektarbete, kommit till flera insikter angående detta. Först och främst handlar det inte endast om en övergång från papper till digital form utan är snarare en fråga om övergång från mindre detaljerad eller på andra sätt mindre omfattande prototyp till en mycket detaljerad eller omfattande dito - en slutsats som faktiskt besvarar vår tredje frågeställning. Vidare har vi kommit fram till att graden av precision som krävs i de tidiga prototyperna innan övergången från ett medium till ett annat avgörs av hur pass detaljerad man vill att den slutgiltiga prototypen ska vara. Vår andra frågeställning, som handlade om ifall man bör ha fattat designbesluten innan övergången mellan en pappersprototyp till en mjukvaruprototyp, är även denna beroende av den specifika situationen. Som Beaudouin- Lafon och Mackay skriver kan skapandet av en prototyp betraktas som en metod för att göra val mellan alternativa designlösningar och fatta designbeslut [1]. Med detta synsätt blir själva skapandeprocessen ett sätt att alstra idéer till lösningar, vilket enligt vår uppfattning implicerar att det kanske är mer eller mindre omöjligt eller snarare orätt att försöka fatta alla designbeslut innan skapandet av mjukvaruprototypen. Dock förklarar Beaudouin-Lafon och Mackay, som vi beskrivit i avsnittet Typernas fördelar och nackdelar, att on-line-prototyper genom att de är dyra och tidskrävande att skapa, lämpar sig bäst för den sena delen av designprocessen, då man redan fattat beslut om grundläggande funktionalitet [1]. Vår slutsats är att arbetet med mjukvaruprototyper är och måste få vara en designprocess i sig, men då detta ofta är förbundet med tekniska komplikationer, och kan kräva mycket resurser i form av tid och pengar, anser vi att det kan vara en god idé att grunda väl inför detta genom att gradvis under designprocessen utveckla allt mer precisa pappersprototyper. När det gäller vår tredje frågeställning, angående klassificeringen av prototyper, är vår slutsats att det bör vara graden av precision mer än valet av medium som ligger i fokus. I den litteratur som vi studerat är det också ofta detta som ligger till grund för klassificeringarna - men då de exempel som presenteras i litteraturen istället ofta riktar fokus till valet av medium, upplever vi det som att just detta, i motsats till vår uppfattning, spelar en ganska stor roll för den klassificering som de olika författarna gör. Vi menar alltså att man i arbetet med att ta fram prototyper bör se till att gradvis öka precisionen i sina prototyper - oavsett vilket medium man arbetar med - för att undvika att man plötsligt befinner sig i ett skede där man samtidigt både måste byta medium och öka graden av detalj och precision i sin prototyp. Detta eftersom man då kan hamna i en pressad situation där designbesluten - och i förlängningen de framtida användarna av omdesignen - blir lidande. ACKNOWLEDGMENTS Vi vill tacka samtliga medverkande i projektet Kattis som genomfördes under kursen Människa-datorinteraktion, fortsättingskurs vid CSC, KTH, hösten 2007. REFERENCES 1. Beaudouin-Lafon, M. and Mackay, W.E. Prototyping Development and Tools. In J.A. Jacko and A. Sears (Red.), Handbook of Human- Computer Interaction. NY, Lawrence Erlbaum Associates, 2002, 1006-1031 (Revised edition 2007). 2. Löwgren, J. & Stolterman, E. Design av informationsteknik - materialet utan egenskaper. Lund: Studentlitteratur, 2004. 3. Preece, J., Rogers, Y., Sharp, H. Interaction Design - beyond human-computer interaction, John Wiley & Sons, NY, USA 2002. 4. Westerlund, B. Design space conceptual tool grasping the design process, in proceedings for Nordes, the Nordic Design Research Conference, In the Making (2005). 5