Personlig reflektion över designarbetet. Av Anneli Olsen, ,

Transkript

1 Personlig reflektion över designarbetet Av Anneli Olsen, , 1

2 Inledning Jag tänker här gå igenom våra erfarenheter från utvecklingsprocessen uppdelat i de steg som finns beskrivna i kursen 1. För att göra det hela än mer överskådligt har jag behållit de utvecklingssteg som beskrivs i den stora rapporten så man direkt kan gå tillbaka till denna och jämföra. Analys Användaranalys Eftersom tiden var knapp och jag och min projektmedarbetare inte läste samma utbildning vilket försvårade arbetets schemaläggning beslutade vi oss för att skapa användare utifrån våra fördomar gentemot nöjesparksbesökare. Vi gjorde dock vårt bästa för att täcka in alla upptänkliga besökare och skapade fem olika personas med skilda bakgrunder och åldrar. Vi hade en utländsk kvinna som inte talade svenska som var på semester med familjen i Sverige, en berusad herre som var på firmafest, en kvinna som ingick i ett möhippesällskap, en manlig brandman som var på nöjesparken med sin dotter samt en äldre dam som inte kommit till nöjesparken för att åka utan snarare för att flanera med sin kavaljer. För var och en av dessa hade vi gjort ganska ingående beskrivningar av intressen, ålder, fysiska förutsättningar, livssituation och så vidare. På handledningstillfället presenterade vi dessa personas och frågade om det var okej att använda sig av dem. Att använda sig av personas funkade, men vi hade uppenbarligen tagit oss vatten över huvudet när vi tänkt oss att tillfredsställa samtligas behov vad gäller användarvänlighet. Vi fick skära ner på antalet och det slutade med att vi av de fem bara behöll två som fick stå för alla de användarkrav som ställdes på systemet. Vad gällde de anställda tyckte vi det var överflödigt att skapa personas för dem då vi ansåg att de genom internutbildningar skulle uppnå ungefär samma teknikvana och förmodligen skulle uppleva samma problem i utövandet av sina arbetsuppgifter. Vi genomförde dock en kort, informell observation av ett par biljettförsäljare på Liseberg, men då det inte utfördes under direkt ordnade former kände vi inte att vi kunde ha med det i vår projektrapport. Vi hade dock det vi sett i bakhuvudet då vi skapade vårt system. Vid ett riktigt projekt skulle nog en annan användaranalys varit att föredra exempelvis observationer. Vi diskuterade lite hur man skulle kunna gått till väga om man valt att ha intervjuer på plats på en liknande nöjespark som exempelvis Liseberg och konstaterade att det kanske inte varit helt lyckat eftersom attityden i Göteborg gentemot folk som kommer fram och vill ställa frågor inte är helt positiv. Dessutom är besökarna på nöjesparken där för att roa sig så mycket som möjligt under tiden de är där och har då ingen speciell lust att lägga en del av sin dyrbara tid på att svara på frågor. Särskilt då inte vi kunnat erbjuda någon rimlig ersättning för besväret eftersom vår budget var en aning stram. Hur vi tänkte oss en bättre användaranalys av det anställda finns att läsa i vår projektrapport. 1 Föreläsningsanteckningar , Designmetodik, 2

3 Uppgiftsanalys Som jag redan nämnt i inledningen missade vi från början den viktiga delen att begränsa oss med hjälp av ett valt perspektiv. Vi såg istället uppgiften ur ett ekonomiskt, miljömässigt, handikappanpassat, statistikmässigt, turistmässigt och, dessutom, tidsmässigt perspektiv. Att därur särskilja vilka huvuduppgifter som skulle utföras av systemet blev förstås mycket svårare än om vi från början bara sett systemet ur ett tidsperspektiv. Istället för att se vad systemet skulle göra såg vi vad det möjligen kunde göra. Under ett handledningstillfälle insåg vi vårt misstag och klippte ner vårt dåvarande arbetsdokument från fem till två sidor. Då vi redan hade börjat på en kravspecifikation blev även denna väldigt nerbantad. Vi gjorde, som även nämns i projektrapporten, en kort observation på nöjesparken Liseberg. Att observera en företeelse man ändå har sett så många gånger förut ur ett nytt perspektiv var väldigt lärorikt. Vi lade märke till små, men viktiga, detaljer man inte tänkt på förut och konstaterade också att bara för att systemet ser ut på ett visst sätt idag behöver inte det betyda att det är det bästa sättet även om det mycket väl kan vara det. Tidigare har man tagit det rätt mycket för givet att system är på ett visst sätt och det är det enda sätt det kan vara på. Att skala ner ett system till dess huvuduppgifter visade att så det inte behöver vara fallet. Eftersom vi valt biljettförsäljare så koncentrerade vi oss mest på biljettförsäljningsprocessen. Kravspecifikation Vi började med en kravspecifikation som var ganska lång, men väldigt diffus. Krav som Det skall vara lätt att använda blandades med Det skall gå snabbt att köpa biljetter. Vi hade ingen inbördes rangordning av kraven eller skrivit dem på ett sådant sätt att det var lätt att avgöra om de var uppfyllda eller ej. Även här kom ett handledningstillfälle väl till pass. Vi gick från handledningen med en mängd frågor besvarade och många åtgärder vi skulle utföra. Vi började med att dela upp kraven i användar- och funktionalitetskrav. Därefter diskuterade vi vilka krav vi tyckte var viktigast och rankade kraven i kravspecifikationen utefter detta. Vi specificerade de krav vi hade kvar efter gallringen så att de var avgörbara och, i de flesta fall, mätbara. När detta var klart hade vi ett dokument att designa utifrån. Dock är dessa krav anpassade för systemet som helhet och inte för de olika delarna av det. Design Vi gjorde en ganska ospecificerad beskrivning av de delar av systemet som inte handlade om biljettförsäljning där den mesta funktionaliteten beskrevs, men bara på konceptnivå. Gränssnittsdesignen lämnade vi åt framtiden. Biljettautomaten gick vi ett par steg längre med. Vi började med att designa konceptet en biljettautomat. Eftersom inte kravspecifikationen är utformad för biljettautomaten specificerade vi här en mer detaljerad specifikation för just den. Även denna är avgörbar och mätbar och stod för funktionalitetsdesignen. Utifrån kravspecifikationen gjorde vi en uppsättning post it-lappar med olika funktionalitet och satte upp på ett A3-papper som fick symbolisera biljettautomaten. Därefter flyttade vi runt lapparna tills vi kände oss nöjda. Då lånade vi någon kompis som fick i uppdrag att köpa några biljetter. Vi hade 3

4 även hela dialogen som kunde dyka upp i displayen på post it-lappar som vi klistrade på display-post it-lappen när någon funktion användes. Vi använde ett quick and dirty tänkahögt-protokoll för att se hur våra användare reagerade. Eftersom det var människor vi kände ganska väl kunde de med att komma med spontana och ibland ganska rättframma kommentarer om vårt system. Det var under ett sådant test vi kom på både ramarna runt funktionerna och delar av texterna på displayen. Vi fick flytta om våra post it-lappar många gånger innan våra vänner/användare tyckte att designen fungerade. Denna tidiga prototyp hade mycket av funktionaliteten, men den var inte speciellt lik den produkt den skulle symbolisera. Därav att vi gjorde en prototyp i PowerPoint. Då en sådan prototyp är ganska tidskrävande jämfört med vår första prototyp implementerades bara ett par funktioner som stödde ett enda användarfall. Även här gjordes användartester som quick and dirty tänka-högt-protokoll. Vad vi fick ut därav hur det tyckte att systemet såg ut och om de förstod hur man använde det. Vi kunde se vilka delar som missförstods och ganska omgående ändra på dessa. Såhär i efterhand kan sägas att jag kanske inte är helt nöjd med alla grafiska designval som gjordes, men då vår design genomfördes hade inte föreläsningen om skärmdesign 2 hållits än och då denna väl var hållen hade vi redan börjat skriva rapporten och hade inte riktigt möjlighet att göra om designen om vi skulle hinna klart med rapporten i tid. Evaluering Vi gjorde viss evaluering under utvecklingsarbetet och då främst under prototypdesignen. Eftersom vi inte kommit längre i utvecklingsarbetet än prototypbygget så kan inte någon riktig slutevaluering, men vi gjorde ändå upp en plan för en sådan. Prototypen är ju inte systemet och det skulle behövas fler och mer avancerade prototyper innan systemet kan anses vara färdigt för produktion. Dessutom är vårat system fortfarande väldigt ospecificerat vad gäller en hel del praktiska saker som robusthet och annan nödvändig funktionalitet som pengahantering och så vidare. Dock är de saker som vi fokuserat på och som är specificerade i kravspecifikationen lösta i vår design. Diskussion Vi valde att se på uppgiften ur ett tidsperspektiv och ha vuxna samt biljettförsäljare som användargrupper. Detta var dock inte det vi utgick ifrån från början. Eftersom vanan vid att arbeta på det sätt som är tänkt att användas i denna kurs var liten i vår grupp började vi i fel ände och nästan fick omarbeta allt vi dittills gjort vid två olika tillfällen. Jag tror dock vi lärde oss mer på att göra fel ett par gånger än om vi lyckats hamna rätt på en gång. Vad vi gjorde var att när vi fick uppgiften gick tankarna direkt mot den tekniska lösningen. Detta var det för oss naturliga sättet att angripa problemet eftersom det är så vi arbetat under de tre tidigare årens ingenjörsutbildning. Det är ju dock inte det lämpligaste sättet att lösa ett problem ur ett användarcentrerat perspektiv så när vi väl insett det fick vi skrota den första veckans arbete och börja om. Att vi började i fel ände blev ett lärorikt problem som följde oss genom hela processen eftersom vi då redan fastnat i en designlösning som vi hade svårt att frigöra oss ifrån. Vårt slutgiltiga designförslag är inte helt olikt vårt första, men grundar sig ändå på användar- och uppgiftsanalysens 2 Föreläsningsanteckningar , Skärmdesign, 4

5 resulterande kravspecifikation. Nästa misstag vi gjorde var att inte specificera oss tillräckligt. När vi gjorde användar- och uppgiftsanalysen såg vi det inte ur ett tidsperspektiv utan alla perspektiv samtidigt. Vi hade en väldigt omfattande kravspecifikation som nog gått att tillfredsställa, men det var ju inte syftet. En del av uppgiften var ju att avgränsa sig med hjälp av ett valt perspektiv. När vi väl insett detta blev det fortsatta arbetet mycket lättare att genomföra. Slutsats Som första projekt någonsin för mig inom denna typ av arbete var det väldigt lärorikt och roligt. Man fick fundera över saker man aldrig tidigare tänkt på som exempelvis varför biljettsystemen ser ut som dom gör idag. I efterhand ser man de misstag man gjorde och konstaterar att, tack vare de erfarenheter man skaffat sig, man förhoppningsvis inte gör om samma misstag vid nästa projekt. Handledningarna var väldigt bra då vi fick mycket nyttig feedback som förde vårt projekt framåt. En sak som dock är svår att göra något åt är det faktum att man alltid gör mycket mer arbete och har många fler tankar än vad som framkommer i ens rapport. Man kan göra ett hur bra arbete som helst, men om man skriver en dålig rapport går inte detta fram ändå. Irriterande men sant. Tyvärr ger inte utbildning jag gått innan detta projekt någon direkt övning i rapportskrivande. Dock gör man ju inte projekten enbart för att få skriva en bra rapport och godkänt på kursen utan snarare för att lära sig något. I skolan får man möjligheten att göra misstag och lära sig av dem utan att det går ut över för många andra och kostar några enorma summor pengar. Jag är ganska nöjd med vårt projekt även om jag känner till dess brister, men jag är än mer nöjd med vår arbetsinsats då vi gjort våra misstag och lärt oss av dem. Och vi har dessutom haft väldigt kul under tiden. 5