Från skiss till vektorgrafik

Transkript

1 En studie om utökat datorstöd för animatörer och illustratörer JONNA OLSSON Examensarbete Stockholm, Sverige 2005 TRITA-NA-E05117

2 Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science Stockholm Royal Institute of Technology SE Stockholm, Sweden Från skiss till vektorgrafik En studie om utökat datorstöd för animatörer och illustratörer JONNA OLSSON TRITA-NA-E05117 Examensarbete i människa-datorinterkation om 20 poäng vid Programmet för medieteknik, Kungliga Tekniska Högskolan år 2005 Handledare på Nada var Björn Eiderbäck Examinator var Lars Kjelldahl

3 en studie om utökat datorstöd för animatörer och illustratörer Sammanfattning Idag sker mycket av arbetet inom illustration och animering med hjälp av dator. Fler och fler delar av arbetsprocessen flyttas till det digitala formatet, och då ofta vektorformat. Dock anser fortfarande många illustratörer och animatörer att den tidiga skissfasen, med papper och penna, är mycket viktig. Att konvertera den initiala blyertskissen till vektorgrafik är ett tröttsamt och tidsödande arbete. Detta exjobb har som syfte att utveckla programvara för att hjälpa illustratörer och animatörer att konvertera sina skisser till vektorgrafik på ett enklare sätt. För utvecklingsprocessen är participatory design vald som metod. I rapporten beskrivs dels den teoretiska bakgrunden till designfilosofin, och dels hur den har använts i detta projekt. Processen har omfattat möten av contextual inquiry-typ, arbete med enkla prototyper, och användarstudier. Resultatet av arbetet, Linetracer, är en applikation för att konvertera skisser till vektorgrafik i ett gränssnitt som bygger på direktmanipulering. De överväganden och beslut som lett fram till gränssnittets utseende, är också diskuterade i rapporten. Dessa vilar både på forskning och på användarnas åsikter. From sketch to vector graphics A study of enhanced computer assistance for animators and illustrators Abstract Today, illustration and animation to a large extent consist of computer-assisted work. More and more of the work is moved to digital format, often vector format. However, many illustrators and animators still consider the early sketch phase, with pencil and paper, very important. To convert the initial pen sketch to vector graphics is a tiresome and time-consuming work. This master s project aims to create a new software, helping illustrators and animators to convert their pen sketches to vector graphics more easily. Participatory design is used as method for the development process. In the thesis the theoretical underpinning of this design philosophy is described, as well as the participatory design process used in this project, consisting of contextual inquiry sessions, rapid prototyping, and user studies. The result of the work is Linetracer, an application for converting pencil sketches to vector graphics with a direct manipulation interface. The considerations and decisions regarding the user interface were based on research and user involvement, and are described in the thesis.

4 Förord I denna rapport beskrivs mitt examensarbete vid Nada, KTH. Arbetet är gjort inom ämnesområdet människa-datorinteraktion. Uppdragsgivare för arbetet var Ola Persson, som arbetar som frilansare inom illustrations- och animationsområdet. Ola har varit ovärderlig i arbetet, tack vare hans kreativitet, kunskap och galna idéer. Det är även han som ritat den fina mangaflickan som använts som exempel i skärmdumparna i rapporten. Projektet att ta fram applikationen Linetracer har skett i samarbete med Johan Kotlinski, vars examensarbete kommer att redovisa de tekniska aspekterna på projektet. Handledare på Nada har varit Björn Eiderbäck. Sist men inte minst, tack alla ni som ställt upp och testat, tyckt till om och hjälpt till med utformningen av Linetracer.

5 Innehållsförteckning 1 Inledning Syfte Avgränsning Rapportens struktur Datorstöd för animering och illustration Befintligt datorstöd Forskning inom området Hur gör man idag? Principer och riktlinjer för användbarhet Participatory design Contextual Inquiry Prototyper Utvärdering Arbetsförlopp för utveckling av Linetracer Contextual Inquiry Iterativt prototypande Designförslag ett Utvärdering Designförslag två Analys och diskussion Hur går vi vidare? Litteraturförteckning... 31

6 1 Inledning Att göra tecknad film kan idag innebära mycket digitalt arbete, då mer och mer av animationsprocessen blir datorstödd. Samma gäller för många slags illustrationer: mer och mer av arbetet kan utföras med hjälp av datorn. Men fortfarande arbetar många illustratörer och animatörer med papper och penna i den inledande skissfasen. Skisserna görs med blyertspenna på papper, och läses därefter in med hjälp av en skanner för att man ska kunna arbeta vidare med dem i datorn. I dagsläget är denna inskanning och bearbetning en omständlig process. Arbetet att konvertera en blyertsskiss till en färdig vektorgrafikbild är både tidsödande och tråkigt. Det finns ett antal program i dagsläget för att stödja animering och illustration. Vi har dock inte hittat något tillgängligt program som stödjer denna del av processen på ett tillfredsställande sätt. För att snabba upp denna icke-kreativa del av att illustrera eller producera tecknad film behövs således ytterligare datorstöd. Exjobbet har utförts i samarbete med Johan Kotlinski. Han har varit ansvarig för det arbete med bildanalys som programmet bygger på, och för själva implementeringen av programmet. För mer information om de underliggande tekniska lösningarna hänvisas således till Kotlinski (kommande). I detta exjobb är fokus istället på de frågor som härrör sig till området människa-datorinteraktion. 1.1 Syfte Syftet med detta exjobb är dels att identifiera och förstå ett behov hos animatörer och illustratörer, och dels att utveckla en användbar applikation för att fylla detta behov. Utvecklingen ska ske i tätt samarbete med de potentiella användarna av den framtida produkten. Därför kommer participatory design användas som övergripande metodtanke. Ett underliggande syfte blir därför att undersöka participatory design som koncept vilka styrkor och svagheter har metoden? 1.2 Avgränsning Detta exjobb kommer enbart att titta på animeringsprocessen ur ett 2D-perspektiv. De olika tekniker och hjälpmedel som finns för 3D-animering kommer inte tas upp över huvud taget. 1 Arbetet är inte heller tänkt att utmynna i en ny komplett animationsstudio. Detta skulle bli ett alldeles för stort och omfattande arbete för ett exjobb. Fokus kommer istället att ligga på just steget från skissande till bild färdig för fortsatt bearbetning i ett vektorbaserat ritprogram. 1 Exempel på 3D-animerade filmer är Toy Story och Monsters, Inc, båda från Pixar Animation Studios. Detta sätt att göra film grundar sig på att man istället för att använda tvådimensionella teckningar bygger upp tredimensionella figurer i datorn, antingen direkt eller genom att man skannar in handgjorda figurer. 1

7 1.3 Rapportens struktur Kapitel två inleds med en översikt av datorstöd för illustration och animation, samt ger en introduktion till forskningen inom området. Nästföljande kapitel ger en kort bakgrund till riktlinjer och principer för hur användbara gränssnitt tas fram. I kapitel fyra beskrivs den metod som använts i arbetet. Kapitel fem beskriver hur metoden har använts för uppgiften. Rapporten avslutas med en analys och diskussion i kapitel sex. I möjligaste mån har jag försökt översätta de engelska uttryck som förekommer inom ämnesområdet till passande svenska uttryck. Ibland har detta inte varit möjligt, då det inte finns bra svenska översättningar som har samma precisa innebörd som den engelska benämningen. I dessa fall har jag valt att behålla det engelska uttrycket. 2 Datorstöd för animering och illustration I detta kapitel beskrivs först vilka programvaror som finns på marknaden för att underlätta arbete med illustration och animation. Det är ett stort område, och därför är det främst de viktigaste programmen som tas upp. Därefter ges en kort översikt av vad forskningen inom datorstöd för illustration och animation handlar om i dagsläget. Det sker mycket forskning inom området, och avsnittet syftar till att ge en inblick i vilka frågeställningar som är aktuella. Kapitlet avslutas med en kort beskrivning av hur arbetssättet kan fungera idag inom det område som är mest aktuellt för denna rapport: skissande och efterföljande konvertering till vektorgrafik. 2.1 Befintligt datorstöd Datorprogram för illustrationsarbete finns det otaliga av. De kan grovt delas upp i program som bygger på pixelgrafik (till exempel Paint och Adobe Photoshop), och program som bygger på vektorgrafik (till exempel Adobe Illustrator). Utbudet av illustrations- och bildbehandlingsprogram är alldeles för stort för att gå igenom i detalj i denna uppsats. Fokus i detta avsnitt ligger istället på att ge en översikt av de program som finns för att stödja animationsprocessen på olika sätt. När det gäller animation, finns det också en mängd programpaket på marknaden. Vissa är tänkta att stödja en i grunden traditionell animationsprocess, och erbjuder datorstöd för inskanning, penseltest, färgseparering, lagerhantering och kameraarbete. Dessa kallas ofta ink and paint systems (Fekete et al 2001), och exempel på sådana är Animation Stand, Retas och CTP Pro. 2 Andra program är så kallade automated in-betweening systems (Fekete et al 2001). Exempel är Animo och Moho. 3 Här kan användaren få hjälp med själva animeringen, genom att programmet gör så kallade in-betweens, användaren 2 För information om dessa programpaket, se gärna de respektive hemsidorna: och 3 Se och för mer information. 2

8 behöver således inte rita varje enskild bild. Programmen bygger på att figurerna är i vektorformat. Ett steg längre går de olika programmen inom ToonBoomfamiljen. Här är det uttryckliga målet att flytta hela animationsprocessen in i datorn, allt från arbetet med storyboarden, till det slutliga ihopsättandet av filmen. För enklare animeringar, när teckningsstilen passar, finns givetvis även Flash, som också bygger på vektorgrafik. Inget av dessa program ger något direkt stöd för att omvandla en skiss till en vektoriserad bild, utan bilden förutsätts ha ritats direkt i programmet, eller i något annat vektorbaserat illustrationsprogram. För de tecknare som använder sig av papper och penna i det inledande skissstadiet, men som ändå vill använda sig av något av de vektorbaserade programmen, antingen för att underlätta framtagandet av en animation eller för att göra en illustration, finns det således ett glapp mellan skissen och vektorbilden. Detta glapp uppkommer eftersom inskanning av skisser resulterar i pixelbilder. I exempelvis Adobe Illustrator finns en inbyggd kalkeringsfunktion, som kan hjälpa till med omvandling från pixelgrafik till vektorgrafik, men denna är främst avsedd för enklare former och linjer. För mer komplicerade former rekommenderar Adobe att man gör kalkeringen manuellt med verktygen Ritstift eller Penna, eller med något program speciellt avsett för denna slags konvertering. 4 De program som finns på marknaden för att konvertera teckningar till vektorgrafik är framför allt Streamline, från Adobe, och Silhouette. 5 Silhouette arbetar, som namnet antyder, med att följa ytterkanter på en bild. Den känner av var gränsen går mellan ytor, och resultatet blir således fält istället för linjer. I Streamline kan man välja om man vill följa ytterkonturer eller om man vill konvertera själva linjerna. När man väljer att konvertera linjer blir resultatet inte alltid tillfredsställande, enligt intervjuer med illustratörer och animatörer. Det bör nämnas att både Streamline och Silhouette arbetar stegvis. Först ställer man in alla parametrar man vill göra konverteringen enligt, därefter utför man kommandot för att konvertera pixelbilden till vektorgrafik. Sedan får man se det färdiga resultatet. Om det är något man inte blev nöjd med, och därför vill ändra i konverteringen, får man ställa om de parametrar man tror gäller, och därefter utföra konverterings-kommandot igen, och se hur det nya resultatet blev. 2.2 Forskning inom området Det pågår mycket forskning om att underlätta och stödja olika delar av animationsprocessen. Exempelvis är Computer-Assisted Auto Coloring (se till exempel Qiu et al 2003) och förfinad och förbättrad in-betweening (se till exempel Di Fiore et al 2001) några av de områden som det forskas på just nu. Sådana tekniker tar för dock givet att figuren som ska färgläggas redan finns i vektorform. I denna uppsats är vi främst intresserade av den första delen av processen för datorstödd animation: hur figuren i vektorformat skapas. De flesta är överens om att det skissande som sker med papper och penna är ovärderligt från ett kreativt perspektiv. Oavsett om det är för att göra en CADritning eller en karaktär till en tecknad film, så är det inledande skissandet, med 4 Se Adobe Illustrator-hjälpen för mer infomation. 5 Se mer information på respektive 3

9 sina fria former och möjligheter att göra om, sudda, rita över och så vidare en nödvändighet för den kreativa processen. De finns många exempel på forskning kring tolkning av skissande. Exempelvis Yu och Cai (2003) presenterar ett system som bygger på att en applikation ska kunna förstå och tolka det användaren ritar. Om man till exempel ritar något som nästan är en cirkel, ska programmet tolka detta som att användaren faktiskt har ritat en cirkel. En sådan applikation är tänkt framför allt att kunna användas som ett första steg när målet är exempelvis en CAD-ritning. Även Sezgin et al (2001) och Gross och Do (1996) är exempel på forskning kring hur skisser ska tolkas olika beroende på kontext. Målet är att låta designers få behålla sin kreativa skissfas, med den osäkerhet och mångtydighet som präglar denna, innan idéerna behöver konkretiseras och formaliseras. Det fysiska skissandet sker i alla dessa fall med hjälp av antingen ritplatta eller mus, och därefter finns en applikation som tar hand om och tolkar det som ritas. På vilket sätt skisserna tolkas beror på kontexten. Det fysiska gränssnittet problematiseras inte i något av dessa arbeten. Användaren antas inte hindras i sin kreativa process för att han/hon är tvungen att skissa med hjälp av ritplatta eller mus, istället för med penna och papper. Alla exempel ovan bygger på att skissandet, det som ritas för hand, ska tolkas och på något sätt så småningom formaliseras. Det är ett önskemål när det gäller ritningar, design av gränssnitt, och så vidare, men det gäller inte för illustrationer och animering. Där vill man ha kvar den kraft och dynamik som de handritade linjerna ger, och vill inte anpassa linjerna till förutbestämda former. För att behålla den levande känslan måste linjerna tolkas så som illustratören eller animatören har valt att rita dem. Sedivys och Johnsons studie (1999) handlade om att utveckla ett alternativ för skisser med papper och penna för just animatörer. Deras lösning byggde på användning av ritplatta kombinerat med en applikation med röststyrda funktioner, för att låta händerna enbart arbeta med det kreativa skissandet. Även Di Fiore och Van Reeth (2002) har som målsättning att underlätta skissande i datorn. Istället för att skapa, bearbeta och korrigera kurvor genom att dra i ankarpunkter, så försöker deras program härma det sätt man ritar på med papper och penna. En linje som fylls i flera gånger tolkas som att den ska bli tjockare, om en linje tecknas starkare en liten bit ifrån den ursprungliga linjen, tolkas detta som att linjen har flyttats. Själva inputen sker med hjälp av antingen ritplatta eller mus. Inget av ovanstående arbeten tar upp skillnaderna i upplevelse mellan det fysiska pappret och pennan jämfört med en ritplatta. Det pågår dock också forskning kring detta. Vad det handlar om är att försöka ersätta den känsla som de fysiska materialen ger med ett fullgott alternativ. Till exempel ger en blyertspenna olika resultat beroende på hur hårt man trycker den mot pappret och i vilken vinkel pennspetsen träffar pappret. Försök att efterlikna denna effekt har till exempel gjorts av Bleser et al (1988) som använde sig av en form av ritplattor. Den resulterande linjen fick olika utseende beroende på vilket tryck och vilken vinkel man applicerade pennan på ritplattan. I framtiden är det mycket möjligt att mer och mer av skissandet kommer ske med hjälp av ritplattor och olika slags applikationer, i takt med att dessa blir både bättre och billigare. Men än så länge är det två saker som gör att papper och penna med all säkerhet kommer att leva kvar under en längre period. För det 4

10 första är ritplattor en investering som privatpersoner och frilansare inte alltid har möjlighet att köpa in direkt. För det andra finns det en förkärlek för papper och penna hos många traditionellt skolade animatörer och illustratörer. De har arbetat med dessa material länge, och är vana vid det. Därmed finns ett glapp, mellan den skissade bilden på ett papper och vektorbilden som behövs för att kunna arbeta vidare med sina teckningar i något av de andra program som kan förenkla arbetsprocessen. 2.3 Hur gör man idag? För de animatörer och illustratörer som i dagsläget arbetar med papper och penna i den inledande skissfasen, men vill få in sina bilder i datorn i vektorgrafikform, finns det ett antal lösningar, även om de är tidskrävande. Generellt kan sägas, att illustratören ofta börjar med en ganska suddig och skräpig skiss i blyerts. Denna blyertsskiss städas upp, eller renritas, med blyerts eller tuschpenna. Resultatet blir en tydlig ren teckning som skannas in. Därefter tas bilden in i Illustrator. Där görs bilden om till vektorgrafik genom manuell kalkering, det vill säga att användaren sitter manuellt och lägger vektorlinjer längs med den ursprungliga teckningens linjer med verktyget Penna eller Ritstift. Detta arbete är tidsödande, och inte heller kreativt till sin natur. Olika animatörer och illustratörer har olika varianter på detta arbetssätt. Vissa tar in bilden i Photoshop efter skanningen, för att öka kontrasterna på skissen och på så sätt underlätta det efterföljande arbetet i Illustrator. Den slutliga kalkeringen i Illustrator sker antingen med mus eller med ritplatta och tillhörande penna, beroende på preferenser och vilken utrustning som finns att tillgå. Vissa använder de specialprogramvaror för konvertering mellan pixelgrafik och vektorgrafik som finns att tillgå, som Streamline och Silhouette. Det beror i hög grad på om den aktuella teckningsstilen passar för det resultat som dessa program ger. För vissa passar den inexakthet och förenkling av linjerna som sker i exempelvis Streamline för den speciella teckningen, medan andra inte alls uppskattar detta. Anledningen till att man gärna vill ha bilden i vektorformat, och inte som pixelgrafik, är många. Dels är det, som diskuterats ovan, ett krav för att kunna använda vissa av de andra programvaror som finns för att underlätta arbetet senare i processen och dels är det de vanliga fördelarna med vektorgrafik: att formatet är skalbart och tar mindre minnesutrymme. Men det finns också rent artistiska fördelar med vektorformatet. Det gör till exempel att det är enkelt att göra alla linjer i bilden lika tjocka, och ge dem samma intensitet. Det gör att materialet genast ser mer professionellt ut, vilket är en fördel om det är det konstnärliga uttrycket man söker. Normalt sett när man skissar med blyerts varierar man hur hårt och intensivt man skissar. Det är inte alltid den skillnaden syns med blotta ögat, men när man tar in bilden i datorn, och börjar manipulera den, till exempel om man binariserar bilden, syns sådana skillnader direkt. Att korrigera detta i en pixelbild är extremt tidsödande. I den traditionella animationsprocessen har man istället använt så kallade tracers för detta arbete. Deras uppgift har varit att sitta och fylla i linjer med samma intensitet och tjocklek på de ursprungliga skisserna innan inskanningen, eller, om det är en odatoriserad process, innan 5

11 scenerna byggs ihop. Sådant arbete slipper man således om man arbetar med vektorgrafik. Ytterligare en fördel är att automatisk färgläggning blir bättre om man har bilden i vektorformat, eftersom man då får det exakta resultatet som vektorer kan ge, men som man inte kan nå helt och fullt med pixlar. 3 Principer och riktlinjer för användbarhet Enligt Spool et al (1997b) är en allmän sanning när det gäller användbarhet att den programvara användaren tycker bäst om, också är den som användaren upplever som mest användbar. Å andra sidan kan det argumenteras för att även den omvända kausaliteten gäller: användaren tycker om det gränssnitt som han/hon upplever är enkelt och intuitivt att använda. Frågan är hur man når detta mål: ett gränssnitt som blir uppskattat och omtyckt. Det finns några genvägar till att nå ett gränssnitt som en användare uppskattar. Användare kan sägas forma en mental modell av en produkt hur den fungerar och var funktionaliteten finns (Spool et al 1997b). Norman (1990) understryker vikten av att ha en underliggande mental modell som användaren förstår och tycker är logisk. Har inte användaren förstått hur programmet fungerar, och varför det gör som det gör, är det omöjligt för användaren att förutsäga hur det kommer att reagera på användarens handlingar, eller vilka handlingar som kommer att leda till vilka resultat. Detta leder ofrånkomligen till frustration och irritation. För att underlätta förståelsen, och för att möjliggöra designen av ett bra gränssnitt, har olika författare olika förslag på principer och riktlinjer man bör följa. Principer är oftast fundamentala, applicerbara på många områden och dessutom bestående. För att kunna applicera dem i praktiken kan de dock ofta behöva klargöras och förtydligas (Shneiderman och Plaisant 2005). Riktlinjer (eng. guidelines), å andra sidan, är ofta mer smalt fokuserade, och därmed enklare att följa. De kan å sin sida ibland vara alltför snäva i sin tillämpning, och svåra att flytta mellan olika domäner. Det finns en mängd olika riktlinjer i litteraturen kring användbarhet, och det är omöjligt att ta upp alla dessa i denna uppsats. I kapitel 5 refereras ett antal av dessa riktlinjer när de har varit relevanta i avvägningarna kring utformningen av gränssnittet. I detta kapitel visas istället två förslag på principer. Detta är exempel på hur principer för framgångsrik gränssnittsdesign kan se ut, det finns många fler att hämta i litteraturen. I Tabell 1 redogörs för de åtta gyllene regler för gränssnittsdesign som tas upp i Shneiderman och Plaisant (2005). Om dessa åtta gyllene regler följs, är man åtminstone en bit på väg mot ett användbart gränssnitt, enligt författarna. Dix et al (1998) använder sig istället av tre målsättningar för gränssnittet: lärbarhet, flexibilitet och robusthet. Dessa tre kan man sedan dela upp i en mängd olika principer för att stödja dessa målsättningar. I Tabell 2 redogörs för dessa principer som ett bra gränssnitt bör följa. 6

12 Tabell 1. Åtta gyllene regler enligt Shneiderman och Plaisant (2005). Gränssnittsdesignens åtta gyllene regler (Shneiderman och Plaisant 2005) 1. Sträva efter konsekvens. Var konsekvent i hur olika kommandon utförs, använd liknande terminologi i beteckningar, dialoger, menyer och i hjälpen, och ha en konsekvent användning av färg, stora och små bokstäver, typsnitt och så vidare. 2. Skapa universell användbarhet. Inse att olika användare har olika behov, och designa för detta. Nybörjare och experter skiljer sig åt, och behöver därför olika sorters stöd. 3. Ge informativ feedback. Allt användaren gör ska ge någon form av återkoppling. För åtgärder som utförs ofta, kan återkopplingen var anspråkslös, medan mer ovanliga och större åtgärder ska ge mer substantiell återkoppling. 4. Designa så att dialoger får tydliga slut. Olika sekvenser av handlingar bör organiseras så att det finns en tydlig start, mitt, och slut. 5. Förebygg fel. Så långt som möjligt, ska systemet designas så att användare inte kan göra några allvarliga fel. 6. Tillåt enkla sätt att ångra och gå tillbaka. Handlingar bör gå att ångra. Om handlingar går att ångra, förebygger det mycket oro och bekymmer hos användaren. 7. Understöd känslan av kontroll. Användaren vill alltid känna att det är han/hon som kontrollerar programmet, inte tvärtom. 8. Minska belastningen på korttidsminnet. Begränsningarna i människans kapacitet att hantera information gör att gränssnitt bör hållas enkla, rörliga delar av gränssnittet bör hållas till ett minimum, och att man måste ge tillräcklig tid för att träna in koder, sekvenser för att utgöra uppgifter etc. Tabell 2. Principer för gränssnitt enligt Dix et al (1998). Principer för att stödja användbarhet (Dix et al 1998) Förutsägbarhet Hjälp användaren att kunna förutsäga resultatet av hans/hennes handlingar baserat på hans/hennes tidigare handlingar Syntetiserbarhet Hjälp användaren att kunna bedöma effekterna av tidigare handlingar på det nuvarande situationen Förtrogenhet Hur mycket användarens kunskap om och erfarenhet från andra verkliga eller datorbaserade domän som kan appliceras när användaren interagerar med det nya systemet Principer för att stödja lärbarhet Principer för att stödja flexibilitet Principer för att stödja robusthet Generaliserbarhet Konsekvens Initiativ till dialog Flertrådsteknik Flyttning av uppgifter Substituerbarhet Individanpassning Observerbarhet Återhämtning Svarbarhet Överensstämmelse i uppgifter Låt användaren använda sin kunskap om interaktion inom den aktuella applikation eller från andra applikationer till nya liknande situationer Liknande situationer eller målsättningar ska generera liknande beteende Låt användaren slippa onödiga restriktioner i dialogen med systemet Tillåt användaren att utföra flera uppgifter samtidigt Möjlighet att flytta kontrollen av olika uppgifter mellan användare och system, eller låta dem dela på kontrollen av en uppgift Tillåt användaren att godtyckligt välja mellan olika likvärdiga värden för inmatning Möjliggör förändring av gränssnittet beroende på vem användaren är Att det är möjligt för användaren att utvärdera det interna tillståndet i systemet utifrån dess synliga representation Möjlighet för användaren att korrigera fel Att användaren uppfattar att kommunikationen med systemet är tillfredsställande Att användaren anser att systemet stödjer de uppgifter användaren önskar, på ett sätt som användaren förstår. 7

13 4 Participatory design Participatory design (PD) är en designfilosofi som ursprungligen kommer från Skandinavien, men som under senare år har blivit inflytelserik även i resten av Europa och i USA (Le Peuple och Scane 2003, Dix et al 1998, Kuhn och Muller, 1993), om än i något förändrad form. 6 Det är en filosofi som omfattar hela utvecklingsprocessen. En exakt definition av vad begreppet egentligen står för är svårt att ge, eftersom detaljerna i beskrivningarna av begreppet varierar mellan olika författare. Men något alla är överens om är grundtanken: att integrera användarna i utvecklingsprocessen. I PD ses användaren inte bara som ett experimentellt subjekt, utan som en aktiv medlem i designgruppen (Blomberg och Henderson 1990; Dix et al 1998). De flesta olika metoder för systemutveckling har med användare i utvecklingen på något sätt, men i PD är det en central och nödvändig del av processen (Le Peuple och Scane, 2003). Muller, en av de ledande forskarna inom PD, beskriver begreppet på följande sätt (Muller 1993, s. 254): Participatory design is a body of practice and theory that emphasizes direct, empowered, collaborative action by users, in concert with software professionals. [ ] Through participatory design, users move out of roles such as observer, approver, knowledge repository, or component of the system and into roles such as peer co-designer, design co-owner, expertise contributor, and selfadvocate. Det yttersta målet med PD är att åstadkomma hög kvalitet på den färdiga produkten (Blomberg och Henderson 1990). Användardeltagande, från ett tidigt stadium, ses som en nödvändighet för att uppnå detta. Kunskap hos utvecklarna om användarnas arbetssätt, och hur de skulle använda en produkt i framtiden, är enligt många författare en nödvändighet för att kunna göra bra produkter (Blomberg och Henderson 1990; Grønbæk et al 1993). Denna kunskap kan utvecklarna bara nå i samarbete med användarna. Det grundläggande argumentet för detta är att det faktiskt är användarna som är experterna på deras eget arbete, och att designerns arbete bara kan bli effektivt om denne får ta del av denna expertis (Dix et al 1998). Dessutom kan introduktionen av ett nytt system bara bli framgångsrikt om de blivande användarna accepterar det, eftersom ett nytt system i de allra flesta fall också innebär förändrade arbetsrutiner (Dix et al 1998). Att få med användarna i processen med att ta fram en ny produkt är således även ur detta perspektiv helt avgörande för det slutliga resultatet. Att få synpunkter direkt från användarna ger mer korrekt information om uppgifterna de egentligen utför, och också en möjlighet för användare att påverka designbeslut. Men framför allt, känslan av deltagande i arbetsprocessen som PD medför kan vara den största enskilda faktorn som leder till att ett system accepteras av användarna (Shneiderman och Plaisant 2005). Det är i slutändan användarna som kommer att skapa nya arbetssätt och rutiner baserat på den nya tekniken, och om de har fått vara med och påverka processen ökar chanserna till acceptans dramatiskt (Blomberg och Henderson 1990). Detta gäller dock framför allt utveckling av produkter riktade till en 6 Se Spinuzzi (2002) för en historisk redogörelse av hur PD-filosofin har förändrats från den skandinaviska grundsynen att processen handlar om demokrati på arbetsplatsen, till den transatlantiska inställningen som är mer inriktad på funktionellt utvecklande. 8

14 specifik organisation. Om målet är att sälja produkten på massmarknaden, är det svårt att se hur alla potentiella kunder skulle kunna vara med och utveckla produkten. En praktisk definition av PD är att filosofin bygger på tre grundpelare. För det första, det grundläggande syftet med metoden är att förbättra arbetsuppgifterna, vilket gör att design och utvärdering alltid blir arbets- eller kontextberoende. För det andra, så karaktäriseras metoden av samarbete. Användaren är en del av designteamet och kan därmed bidra till alla steg i utvecklingen. Slutligen kan metoden sägas vara iterativ. Designen utvärderas och omarbetas under hela förloppet (Blomberg och Henderson 1990; Dix et al 1998). I litteraturen kring PD tas även vissa risker upp. Rubin (1994) tar upp faran med att användarna kan komma allt för nära designteamet. De börjar tänka och reagera som resten av teamet och ger därmed inte det annorlunda och värdefulla användarperspektivet som det är tänkt. Det kan också leda till att användarna, i rädsla för att såra någon av deras nära arbetskamrater, håller inne med viktiga kommentarer och kritik. Shneiderman och Plaisant (2005) nämner också att PD kan göra att utvecklingsprocessen blir längre och mer kostsam än vad den annars hade behövt bli. Det finns också en risk att människor som inte är med i utvecklingsprocessen, eller de vars förslag blir nedröstade, blir fientligt inställda mot produkten. Detta kan i värsta fall leda till attt designers måste kompromissa med vissa designlösningar, för att på så sätt tillfredsställa inkompetenta användares önskemål (Shneiderman och Plaisant 2005). Andra studier har visat att metoden leder till få designinnovationer, och att det kan leda till hög stress i teamet (Le Peuple och Scane 2003). Ett annat praktiskt problem är att PD ofta inte passar in i en organisations befintliga produktutvecklingsprocess, där utvecklingen ofta styrs av detaljerade kravspecifikationer, som godkänns och blir juridiskt bindande dokument. Utvecklingsprocessen måste, för att PD ska kunna användas i praktiken, byta fokus från produkt till process. Kontrakt bör fokusera på att skapa en utvecklingsprocess där både utvecklare och användare deltar, istället för att enbart handla om den färdiga produkten (Grønbæk et al 1993). I praktiken innefattar PD en mängd olika tekniker, exempelvis workshops, hightech-prototyper, low-tech-prototyper, etnografiska metoder, contextual inquiry, iscensättande, och mycket mer. 7 I resten av detta kapitel beskrivs några av dessa tekniker mer ingående. Dock är det viktigt att tillägga, att det inte egentligen är teknikerna i sig som definierar PD. Det viktigaste är grundsynen: en vilja att integrera användarna i utvecklingsprocessen, för att på så sätt ta till vara på deras kunskaper och expertis. 7 För en bra och tydlig genomgång av tekniker som har använts inom PD-fältet, både inom forskning och i industriellt sammanhang, rekommenderas Muller et al (1993). Författarna ger också referenser till vidare läsning om de olika teknikerna. 9

15 4.1 Contextual Inquiry Contextual inquiry (CI) är en av de tekniker som Muller et al (1993) tar upp i sin översikt av olika metoder inom PD. Metoden tas upp som ett exempel på teknik som kan användas tidigt i utvecklingsprocessen, och där det snarare är designern som deltar i användarens värld, än tvärtom. CI kan sägas vara en kombination av observation, diskussion och rekonstruktion av tidigare händelser (Preece et al 2002). Det är en teknik för att intervjua och observera individuella användare på deras egna arbetsplatser, medan de gör deras vanliga arbetsuppgifter (Dumas och Redish 1999). CI är ett effektivt sätt att samla in information om användbarhetskrav innan något konkret designarbete är påbörjat. 8 CI bygger fyra grundläggande principer: kontext, partnerskap, tolkning och fokus (Preece et al 2002). Metoden fokuserar på kontexten kring produkten. Syftet är att få en förståelse för inte bara hur produkten används, eller hur arbetsprocessen ser ut idag, utan även information om i vilket sammanhang produkten används eller kommer att användas. Designern måste gå till användarens arbetsplats för att se vad som egentligen pågår. Vidare ses den intervjuade inte bara som en källa till information, utan relationen mellan utvecklaren och användaren bygger på partnerskap, där användaren också deltar i produktutvecklingsprocessen. I en traditionell intervju är intervjuaren alltid den som styr och har kontroll, men i CI är tanken att förståelse byggs genom samarbete. Iakttagelserna som görs måste tolkas för att kunna användas i designen. Denna tolkning görs gemensamt av utvecklaren och användaren. Den sista principen, fokus, understryker vikten av att hålla diskussioner och observationer inom gränserna för vad som är relevant för den design som ska utvecklas. 4.2 Prototyper Att testa, utvärdera och utveckla gränssnittet tillsammans med användarna under arbetets gång är en självklar del av en PD-process. Att arbeta med prototyper, det vill säga artefakter som kan simulera vissa, men inte alla, egenskaper i det framtida systemet (definition enligt Dix et al 1998), är ett sätt att åstadkomma detta. Syftet med en prototyp är att få feedback på den design som är gjord (Spool et al 1997a). Att i utvecklingsarbetet arbeta med prototyper är ett relativt snabbt och effektivt sätt för att förmedla åsikter om och krav på funktionalitet mellan utvecklare och användare. Det blir därmed en effektiv teknik för att få användarna involverade i utvecklingsprocessen (Miller-Jacobs 1993). Genom att utvecklarna kan använda prototypen som ett kommunikationsverktyg för att kommunicera sin förståelse för produktens funktionalitet, kan de få snabb och effektiv respons från användarna. Istället för att användaren ska behöva läsa en tjock kravspecifikation i textform, kan de få en direkt förståelse för den planerade funktionaliteten (Miller-Jacobs 1993). Användning av prototyper underlättar således kommunikationen mellan användare och utvecklare. Genom att använda prototyper kan man skapa en iterativ utvecklingsprocess. Poängen är att de krav som finns på ett interaktivt system är omöjliga att göra en komplett specifikation för i början av systemets livscykel. Enda sättet att vara 8 En annan tidig källa om CI är Holtzblatt och Jones (1993). 10

16 säker på vissa egenskaper i den tänkta designen är att bygga dem och testa på användare. Detta kan göras genom att använda prototyper (Dix et al 1998). Prototyper kan delas in i tre olika grupper: de kan vara low-fidelity, medium-fidelity eller high-fidelity (denna indelning används av exempelvis Le Peuple och Scane 2003). Prototyper av low-fidelity-typ innebär exempelvis enkla pappersbaserade skisser eller modeller byggda i kartong för att representera utseende och beteende hos gränssnittet. High-fidelity-prototyper innebär i princip klara datorbaserade program, som låter användaren interagera med det mesta av funktionaliteten i det slutliga systemet. Medium-fidelity-prototyper, slutligen, är vanligtvis datorbaserade simuleringar, som inte är helt interaktiva och bara har en mycket liten del av den slutliga produktens funktionalitet (Le Peuple och Scane 2003). Enligt Dumas och Redish (1999) så bör man, om man har möjlighet, använda så verklighetstrogna prototyper som möjligt. Denna åsikt baseras på en studie av Nielsen (1990, citerad i Dumas och Redish 1999), som visade att man hittade fler problem i ett gränssnitt med hjälp av en high fidelity-prototyp än en pappersprototyp. Å andra sidan tar mer verklighetstrogna prototyper längre tid att utveckla och kräver också en visst mått av expertis i någon av de programvaror som kan användas för att ta fram prototypen (Le Peuple och Scane 2003). Många andra författare framhåller däremot fördelarna med low fidelity-prototyper, speciellt inom den användarcentrerade filosofin (se exempelvis Muller et al 1993; Rubin 1994; Snyder 2003). Att använda sig av sådana prototyper har redan från första början varit en naturlig del i en PD-process (Spinuzzi 2002), de användes redan i det numera klassiska UTOPIA-projektet som inledde den skandinaviska PD-skolan i början av 80-talet (Bødker et al 2000). Low fidelity-prototyper är ett sätt att få feedback på designförslag och idéer innan en enda rad med kod är skriven (Rubin 1994; Snyder 2003). En fördel som ofta framhålls är att ju enklare prototyp, desto snabbare och billigare är den ofta att göra (Rubin 1994; Felciano et al 1995; Spinuzzi 2002; Snyder 2003). En följd av att kunna göra snabba prototyper blir då att det går att ha korta iterationer och testa många olika varianter av utformning (se exempelvis Felciano et al 1995; Snyder 2003). Generellt kan sägas att det är ett snabbt och kostnadseffektivt sätt att arbeta, som ger direkt återkoppling om generella och övergripande aspekter på designen, så som skärmlayout etc. Det bästa sättet att avgöra en lång diskussion inom utvecklingsteamet om vilken av två föreslagna lösningar som är bäst, kan ofta vara att snabbt göra en enkel prototyp och faktiskt testa på en användare (Felciano et al 1995; Snyder 2003). Med enkla prototyper är det lätt att arbeta med snabba iterativa processer, och man kan experimentera med många olika idéer, istället för att satsa på att utvärdera endast en. Enkla prototyper blir ett sätt för användarna och utvecklarna att kommunicera med varandra. Istället för att behöva skriva långa dokument om ett tänkt utseende, som kan vara arbetsamt att läsa och svårt att förstå, visas idéer i en konkret form, som är lätt att omedelbart ta till sig. Det finns indikationer på att prototyper som ser mer färdiga och polerade ut genererar mycket onödig respons (Snyder 2003). När något ser färdigt ut, är det lätt att detaljer i utseendet står ut och fångar användarens uppmärksamhet. Om 11

17 man inte är i de slutliga stadierna av designen, eller speciellt vill ha återkoppling på frågor som rör utseendet, är kommentarer om val av färg, typsnitt, och missar i vänsterjusteringen inte särskilt värdefulla. Ruffare prototyper, däremot, visar tydligt att utseendet inte är klart, och hjälper därmed användaren att koncentrera sig på frågeställningar kring funktionalitet och andra grundläggande koncept. Felciano et al (1995) framhåller å andra sidan fördelen med att ha en prototyp som ser snygg och professionell ut. Detta gör enligt författarna att testdeltagarna tar uppgifterna seriöst, och förstår att det är på riktigt. Ytterligare en nackdel med de mer avancerade prototyp-verktyg som finns, där man har möjlighet att specificera utseendet (till exempel typsnitt, färger och skuggning) är att det är lätt att fastna och lägga ned onödig tid på gränssnittets utseende (Snyder 2003). Om utseendet sedan förändras (vilket det enligt författaren så gott som alltid görs), har all denna tid varit fullständigt bortkastad. En skissad pappersprototyp hjälper till att hålla fokus borta från utseende och detaljer. En sådan low-fidelity prototyp är inte ens tänkt att se färdig ut, och gör därmed att det blir enklare att koncentrera sig på de substantiella frågorna. Vidare, så kan en ofärdig design generera mer konstruktiv och kreativ respons (Snyder 2003). En ofärdig design kan ha en dramatisk effekt på hur användarna reagerar när de ombeds ha åsikter om designförslag etc. Om en användare ställs inför en snyggt och polerat gränssnittsförslag, som till och med har delar av funktionaliteten implementerad, är risken stor att de omedvetet har svårt att kritisera det. Det verkar som att användaren då tror att utvecklarna har lagt ned mycket tid, engagemang och prestige i förslaget, och då skulle kritik kunna innebära att användaren sårar utvecklarnas känslor. Med en prototyp implementerad i exempelvis pappersform, är det uppenbart att förslaget fortfarande befinner sig på skisstadiet, och därmed är det lättare för användaren att kritisera och komma med radikala idéer (Felciano et al 1995; Snyder 2003). Enkla prototyper uppmuntrar på så sätt kreativiteten, både hos användarna och hos utvecklarna. Ett konkret sätt att implementera en low fidelity-prototyp är att använda sig av papper. Med en bred definition, kan pappersprototyper sägas vara ett sätt att generera idéer, designa, skapa, testa och kommunicera kring gränssnitt. Något mer precist, kan användning av pappersprototyper sägas vara en variant av användbarhetstestande, där representativa användare interagerar med pappersversioner av ett gränssnitt. Detta gränssnitt styrs av en människa som leker dator, och låter pappersversionen av gränssnittet reagera på användarens beteende (Snyder 2003). Framför allt är pappersprototyper lättare att framställa än andra slags prototyper, vilket gör att man mycket enkelt kan förändra funktionalitet och utseende på sina pappersskisser (Spool et al 1997a; Felciano et al 1995; Snyder 2003). Använder man mycket enkla modeller kan till och med prototypen förändras under testet, av testdeltagaren eller av designern, vilket gör att även testdeltagaren blir aktiv i designprocessen (Spinuzzi 2002; Snyder 2003). Det finns dock potentiella problem i ett gränssnitt som tester med pappersprototyper inte kommer att hitta. Ett exempel kan vara en liten detalj i gränssnittet som förändras. I verkligheten kan denna förändring vara så liten att användaren har problem med att se den. Men i en pappersprototyp gör den 12

18 personliga datorn uppdateringen i gränssnittet, något som därmed blir omöjligt att missa (Snyder 2003). Ytterligare ett problem som kan vara svårt att identifiera med hjälp av en pappersprototyp är olika svårigheter i användningen av mus eller tangentbord, eftersom dessa inmatningsverktyg normalt inte används i testerna (Snyder 2003). Givetvis är även potentiella problem med långa svarstider omöjliga att förutse i en pappersprototyp (Snyder 2003). De problem som rör grundläggande koncept och terminologi är det dock stor chans att man hittar med hjälp av en pappersprototyp. Även problem som rör navigering och arbetsflöde har stor chans att uppmärksammas i tester med en pappersprototyp (Snyder 2003). Men den största styrkan med pappersprototyper är att man på ett tidigt stadium har ett effektivt sätt att kommunicera med användaren kring kraven på funktionalitet, och grundläggande frågor som skärmlayout och så vidare (Snyder 2003). Felciano et al (1995) nämner dock att testdeltagare kan känna sig obekväma med att använda pappersprototyper. Det kan upplevas som lite fånigt att behöva låtsas att massa papperslappar föreställer en fungerande produkt. 4.3 Utvärdering En produkt behöver utvärderas med jämna mellanrum under utvecklingens gång. Det är det enda sättet att få reda på om produkten verkligen uppfyller användarnas behov och önskemål, och också ett sätt att upptäcka eventuella svårigheter och problem i gränssnittet. Det finns två grundläggande typer av utvärdering med användare: dels kan testerna utföras i laboratoriemiljö, så kallade laboratoriestudier, och dels kan testerna utföras i fält, hos användaren (Dix et al 1998). Det finns för- och nackdelar med båda dessa metoder. Generellt kan sägas att laboratorietester är bra när man vill testa produkter där den riktiga miljön är svår eller omöjlig att testa i (till exempel för system som ska användas på rymdskepp), om man har några få men väl definierade uppgifter som ska utföras, eller om man vill jämföra olika lösningar i en kontrollerad miljö. Studier i fält, å andra sidan, har sin styrka i det faktum att användaren faktiskt befinner sig i den miljö där produkten så småningom är tänkt att användas (Dix et al 1998). För att nå ett bra och rättvisande resultat med utvärderingen är det kritiskt att testerna utförs på användare som i så hög grad som möjligt motsvarar de framtida riktiga användarna. Om deltagarna i användartesterna inte i största möjliga mån representerar riktiga användare, så får man inte svar på frågan vad som egentligen kommer hända när produkten tas emot av de riktiga användarna (Dumas och Redish 1999). Eller, som Rubin (1994, s. 119) uttrycker det: After all, your test results will only be valid if the people you test are typical end users of the product, or as close to that criterion as possible. If you test the wrong people, it does not matter how much effort you put into the rest of the test preparation. Your results will be questionable and of limited value. En vanlig teknik när man gör användartester är att använda sig av så kallad tänka högt -teknik (Rubin 1994; Dix et al 1998; Preece et al 2002). Detta innebär att man uppmanar användaren att hela tiden tänka högt, det vill säga berätta hur de tänker när de utför en uppgift. Det finns många fördelar med denna teknik. Användarna har en möjlighet att direkt berätta om hur de upplever 13

19 uppgifterna och gränssnittet, istället för att försöka komma ihåg sina känslor och tankar i en intervju senare, efter själva testet. Tekniken kan också göra det lättare för vissa testdeltagare att koncentrera sig och fokusera på uppgiften (Rubin 1994). Men, som både Rubin (1994) och Snyder (2003) påpekar, så kan det kännas onaturligt för många att hela tiden högt säga vad de tänker. Snyder rekommenderar istället att man hela tiden pratar med användaren under testet, för att få höra vad denna tänker och tycker. Hon ger dock också några råd på vägen. För det första, så ska testledaren gärna uppmuntra frågor från testdeltagaren, men inte svara på dem. Däremot måste testledaren ändå bekräfta att denna har hört deltagarens fråga (se även Rubin 1994). För det andra, så är det viktigt att testledaren hela tiden använder testdeltagarens vokabulär, och inte frestas att använda den korrekta terminologin och därmed råka tipsa om hur systemet ska användas. För att nå målet med en naturlig dialog är det vidare bra om testledaren ställer många öppna frågor, som uppmuntrar testdeltagaren att berätta detaljerat, och inte bara svara ja eller nej (se även Rubin 1994). Sist men inte minst, så påpekar författaren att det är viktigt att lyssna på även ickeartikulerade kommentarer: yttranden som hmm, aha, ojdå, och äsch representerar ofta toppen av ett kognitivt isberg (Snyder 2003, s. 181, min översättning). Dumas och Redish (1999) förespråkar en teknik som de kallar active intervention. Denna teknik kan sägas vara en utveckling av tänka högt -tekniken, och bygger på att testledaren under testets gång frågar deltagaren om varför denne gör som den gör. Varför använder deltagaren ett visst menyval, hur tolkar användaren menystrukturen, och så vidare. Denna teknik kan hjälpa testledaren att skapa sig en god förståelse för hur användarens mentala modeller växer fram under användningen av produkten. Hur många deltagare man bör ha i ett användbarhetstest är en fråga som är livligt debatterad i litteraturen kring användbarhetstester. Nielsen och Molich (1990, citerade i Dumas och Redish 1999) kom i en studie fram till att bara knappt hälften av alla stora användbarhetsproblem hittades med tre deltagare. Virzi (1992, citerad i Dumas och Redish 1999), å andra sidan, hävdar att erfarenhet visar att man kan hitta de allra flesta stora problemen i en produkt i ett användbarhetstest med relativt få deltagare. Med fyra till fem deltagare hittas enligt honom 80 procent av användbarhetsproblemen i ett gränssnitt. Med tio deltagare stiger siffran till 90 procent, men ännu fler deltagare gör knappt någon nytta alls, enligt Virzi. I en senare studie har Nielsen och Landauer (1993, citerad i Snyder 2003) kommit fram till att kurvan för antal upptäckta problem i ett gränssnitt börjar flacka ut efter fem eller sex testdeltagare. Snyder (2003) anser att hon i sina tester brukar kunna upptäcka mönstret i de problem och frågeställningar användarna har efter tre till fyra testdeltagare, och rekommenderar fyra till sex testdeltagare för de flesta användbarhetstest. I detta sammanhang understryker många författare vikten av att skilja på användbarhetstester och forskningsstudier. I det senare fallet försöker man få fram statistiskt säkerställda resultat om ett specifikt fenomen. I ett användbarhetstest, å andra sidan, är fokus snarare att med hjälp av tillgängliga resurser, som expertkunskap, kvalitativa resultat, kvantitativa iakttagelse, deltagarnas kommentarer och så vidare, lyckas identifiera de problem en framtida användare troligen kommer få med gränssnittet (Dumas och Redish 1999). 14

20 Ett praktiskt problem med användartester är att hitta deltagare. Som vi ovan konstaterat, är det mycket viktigt att ha testdeltagare som på ett bra sätt representerar de framtida användarna av produkten. Dumas och Redish (1999) ger tre förslag på hur man kan hitta testdeltagare som uppfyller önskemålen. Ett sätt kan vara att använda speciella företag, specialiserade på att hitta personer som uppfyller vissa kravprofiler. Ett annat kan vara att annonsera på lämpliga ställen, exempelvis lokalpress eller fackpress. Ett tredje sätt att hitta lämpliga testdeltagare är att försöka använda sitt eget nätverk. Detta är den klart billigaste metoden, men medför också vissa problem. Författarna tar upp tre fallgropar man kan hamna i när man använder testdeltagare från sitt personliga nätverk. För det första kan det vara så att dessa personer delar testledarens/utvecklarens jargong, utan att någon av dem ens är medveten om detta. För det andra, personliga relationer kan göra det svårare för testdeltagaren att kritisera produkten. Det är ofta svårare att bedöma och klandra en produkt när man är rädd att såra en personlig väns känslor. Sist, men inte minst, finns det en risk att man genom att använda sina personliga kontakter glömmer bort att testdeltagaren ska representera de framtida användarna, och istället använder sig av de vänner som är lättast att få tag på. 5 Arbetsförlopp för utveckling av Linetracer Efter att ha undersökt marknaden för att se vilka befintliga produkter som fanns, bestämde vi oss för att koncentrera oss på målgruppen frilansare och mindre bolag, som inte har råd att köpa in kompletta animationsstudios, utan behöver enklare och billigare lösningar för sina behov. I följande avsnitt beskrivs hur arbetet att ta fram Linetracer, som arbetsnamnet för applikationen blev, har gått till. 5.1 Contextual Inquiry Det första steget var ett antal intervjuer/observationer/diskussioner, från och med nu kallade möten, av contextual inquiry-typ. Fyra individer, alla professionellt eller semi-professionellt aktiva som animatörer eller illustratörer deltog. Syftet med detta steg i processen var att få en ökad förståelse för detta specifika domän och hur processerna inom det ser ut, samt att ta reda på krav och förväntningar på ett blivande system redan innan den faktiska utvecklingen hade börjat. I linje med teorin bakom contextual inquiry (CI) utfördes dessa fyra möten på användarnas arbetsplatser, i den mån det var möjligt (i ett fall var detta inte möjligt, då tog mötet plats i en kafeteria istället). Anledningen är att man vill se kontexten kring den framtida produkten. Att vara på användarens arbetsplats visade sig vara mycket givande. Vid mer än ett tillfälle kom samtalet in på exempelvis ett speciellt teckningsmanér, och då kunde användaren snabbt hämta en teckning från en kollega för att visa vad som menades. Det gjorde det också möjligt att diskutera och visa arbetsprocessen på riktigt, utförd på det sätt och med de hjälpmedel som faktiskt används. 15