Bokningssystem för tvättstuga

Transkript

1 Bokningssystem för tvättstuga Yggdrasil DOKINT Grupp 8 Momentansvarig: Ken Larsson Handledare: Lena Norberg Anna Eriksson David Lindkvist Zeth Lönnroth Soo-Im Pettersson Richard S. Venemyr David Weir

2 Innehållsförteckning 1 Inledning Bakgrund Målgrupp Syfte Mål Utformning av systemet Tillvägagångssätt Plan för genomförande av projekt Bokningssystem - steg Brainstorming Diskussion av idéer Bokningssystem - steg Diskussion med möjliga framtida användare Problemanalys Bokningssystem - steg Framtagning av skissprototyper Skissprototyp Skissprototyp Användartest på skissprototyper Resultat av användartest på Skissprototyp Resultat av användartest på Skissprototyp Seminarium Förkastade förslag Problemanalys Bokningssystem - steg 4 - användarvyer Studier av befintliga system Framtagning av prototyp utvecklad i MS PowerPoint Deltagande observation Genomförande av pilottest och användartester Resultat av användartester Validitet Seminarium Förkastade förslag Problemanalys Bokningssystem - steg 4 administratörsvyer Intervju med fastighetsskötare Framtagning av funktioner för administratör, skissprototyp Användartest på de båda administratörsförslagen Resultat av administratörstest Problemanalys Framtagning av prototyp för administratörsvyer, PowerPoint Bokningssystem - steg Framtagning av prototyp utvecklad i Authorware Deltagande observation Genomförande av pilottest och användartester Resultat av användartester Problemanalys Revidering av prototyp Genomförande av ytterligare användartester Problemanalys... 17

3 9 Bokningssystem - steg Utformning av enkät Pilottest av enkät Slutseminarium Datainsamling Resultat av enkät Problemanalys Prototypens status Framtidsvision Systemmodell för det slutgiltiga systemet Navigering Bokningssystemets vyer Bokningssystemets processer Arbetsuppgifter systemet ska stödja Användbarhetskriterier Reflektioner över användbarhet Litteraturförteckning Bilagor Bilaga 1 - Brainstorming, i Bilaga 2 - Diskussion av idéer, iii Bilaga 3 - Diskussion med ev framtida användare... v Bilaga 4 - Frågor vid framtagning av skissprototyper...vii Bilaga 5 - Skissprototyper...ix Bilaga 6 - Användartest på skissprototyper...xii Bilaga 7 - Kommentarer från seminarium 1, xv Bilaga 8 - Studier av befintliga system...xvii Bilaga 9 - Prototyp PowerPoint...xviii Bilaga 10 - Användartester PowerPoint prototyp...xix Bilaga 11 - Kommentarer från seminarium 2, xxii Bilaga 12 - Användartest administratörsvy, skiss...xxiii Bilaga 13 - Prototyp PowerPoint, administratörsvyer... xxv Bilaga 14 - Prototyp Authorware, version 1...xxvi Bilaga 15 - Användartester prototyp Authorware...xxvii Bilaga 16 - Användartester prototyp ver 2 Authorware... xxx Bilaga 17 - Enkät till seminarium 3, xxxii Bilaga 18 - Resultat av enkät...xxxiv Bilaga 19 - Kommentarer från slutseminarium, xxxv Bilaga 20 - PR-blad...xxxvi

4 DOKINT Grupp Inledning I dokumentet redogörs för arbetsprocessen att ta fram en prototyp för bokning av tvättider. De val som gjorts, beslut som tagits, metoder som använts beskrivs och motiveras. För att utveckla bokningssystemet har en iterativ metod använts. Under varje iteration har olika användartester genomförts och resultatet utvärderats, därefter har nödvändiga förändringar gjorts i bokningssystemet. (Preece et al, 2002). 1.1 Bakgrund Att tvätta hör till de aktiviteter som är mindre roliga, speciellt om det sker i en gemensam tvättstuga. Tvättid ska bokas, tiden memoreras och som om inte det var tillräckligt, man ska komma ihåg att gå dit. Visst vore det praktiskt att kunna få ett meddelande att tvättiden snart börjar och en möjlighet att boka sin tvättid via ett nätverk? Utifrån vår egen frustration över dåligt fungerande bokningssystem ville vi undersöka om vi kunde få fram idéer som skulle kunna råda bot på ovan nämnda problem och göra livet lite enklare för oss som tvättar. För att se om andra upplevde samma problem tillfrågades flera tänkta användare. De flesta vi talade med ville gärna ha möjlighet att boka tvättider hemifrån och även potentiella administratörer tyckte att systemet var mycket intressant. 1.2 Målgrupp Systemets målgrupp är boende i bostadsrättsföreningar och hyresrätter samt styrelser och fastighetsägare. 1.3 Syfte Syftet med systemet är att underlätta bokning av tvättider. Det ska vara möjligt att anpassa systemet utifrån olika tvättstugors nuvarande bokningssystem samt fastighetsägarens önskemål. 1.4 Mål Målet är att skapa en prototyp av ett system som kan användas för bokning av tvättider. Prototypen ska vara testad mot tänkta användare. 1.5 Utformning av systemet Bokningssystemet utvecklas för en terminal som placeras på lämplig plats av hyresvärden. Var denna terminal placeras har ingen betydelse för utformningen av systemets gränssnitt. Eftersom systemet som utvecklas inte ska vara en webbplats utformas det i första hand för en placering där fastighetens nuvarande bokningstavla eller dylikt finns. Det finns dock inget som hindrar att systemet används via ett nätverk t.ex. LAN som möjliggör att användare kan boka tvättpass hemifrån. 1

5 DOKINT Grupp Tillvägagångssätt För att komma fram till vilka arbetsuppgifter systemet bör klara och hur systemet ska utformas har ett flertal metoder använts. En plan utarbetades för genomförandet av projektet. I dokumentet redovisas arbetet i den ordning det utförts och dokumentationen har delats upp efter vår projektplan för att underlätta läsningen. 2.1 Plan för genomförande av projekt Första steget: Inleds med brainstorming och diskussion samt initiala funderingar om vad systemet ska kunna göra. Dessutom görs en grov plan för hur vi tänkt genomföra projektet. Andra steget: Flera informella Quick and Dirty intervjuer med potentiella användare genomförs per telefon och genom direkt kontakt. Tredje steget: Två prototyper av systemet, skisserade på papper, tas fram med hänsyn tagen till resultaten från egen brainstorming och den första omgången användarintervjuer. Skissprototyperna testas sedan på nya potentiella användare genom Quick and Dirty intervjuer. Kommentarer samlas även in från seminarium 1. Fjärde steget: Studium av befintliga system för liknande bokningssystem genomförs. Ytterligare en skissprototyp görs efter utvärdering av tidigare återkoppling. Framtida administratör intervjuas. Administratörsfunktioner utarbetas och testas. En High-fidelity prototyp tas fram med hjälp av applikationsprogrammet MS PowerPoint. Den nya prototypen utformas med hänsyn till resultaten av steg fyra och testas med ytterligare nya användare. Under testet observeras användarna uppföljt av intervjuer om hur de själva upplevde systemet. Prototypen visas upp på seminarium 2 och synpunkter samlas in. Femte steget: Utifrån resultaten från observationerna och intervjuerna på prototypen i MS PowerPoint görs ytterligare en ny High-fidelity prototyp med mer funktionalitet i Authorware. Därefter görs en ny test med testpersoner som inte tillfrågats tidigare. Steg fem itereras med utvärdering och uppdatering av prototyp samt nya användartester. Sjätte steget: Enkät utformas. Prototypen visas upp på seminarium 3 och svaren på enkäten bearbetas. Dokumentationen som skrivits fortlöpande under arbetsprocessen slutförs. 2

6 DOKINT Grupp Bokningssystem - steg 1 Steg 1 inleddes med brainstorming och diskussion samt initiala funderingar om vad systemet skulle kunna göra. Dessutom gjordes en grov plan för hur vi tänkt genomföra projektet. 3.1 Brainstorming Arbetet påbörjades med en 15 minuter lång brainstorming där gruppmedlemmarna förutsättningslöst kom med förslag på hur ett bokningssystem skulle kunna utformas, dess funktioner och vilka de framtida användarna är. På så sätt kunde ett stort antal idéer utifrån en given problemställning genereras. (Löwgren et al, 1998) Det som kom fram under brainstormingen var att systemet kommer att ha två olika typer av användare, dels de som ska boka tvättider och dels hyresvärden eller fastighetsägaren som administrerar systemet. Inmatningsmetoder diskuterades liksom utformningen av terminalen och huruvida den skulle vara fristående eller kopplad till ett nätverk. Något som också resonerades kring var på vilket sätt bokning av tider skulle kunna ske och hur långa tvättpassen bör göras. Förslag på förbättringar jämfört med mekaniska system som kom fram var möjlighet till påminnelser om tvättider, tvättkvoter, bokning av övriga lokaler, enkel felrapportering samt låsning av tvättstuga. I bilaga 1 finns en utförligare version av den brainstorm som genomfördes. 3.2 Diskussion av idéer Direkt efter brainstormingsessionen diskuterade vi vidare på de förslag och idéer som framkommit. Resultatet strukturerades för att komma fram till vilka idéer som var användbara och vilka som inte var aktuella för systemet. Det kom även fram några nya förslag på funktioner under diskussionen. En plan gjordes upp som tidigare nämnts i avsnitt 2.1. En sammanfattning av diskussionen finns nedan och i bilaga 2 finns den i sin helhet. Sammanfattning av diskussionen Bokningen ska ske via en vanlig dator eftersom det är en billig lösning och de flesta har datorvana. System ska vara centralstyrt för att underlätta för hyresvärden att koppla terminalen till ett nätverk. Felmeddelanden kan även tas emot i realtid. Systemet ska kunna vidareutvecklas för bokning via Internet. Det är upp till hyresvärden att bestämma längden på tvättpass eftersom systemet ska klara olika alternativ. Det ska finnas möjlighet att lägga in olika restriktioner och medvetna begränsningar i systemet med hänsyn till tvättstugans användande. En ny idé som kom fram var att det bör finnas möjlighet att ställa sig i en standby-kö för redan bokade tider, om det inte finns en ledig tvättid som passar. Det bör finnas en kölista för att kunna se om fler bokat standby-tid på samma tvättpass. Information om att en bokad tid blivit ledig informeras genom SMS eller liknande. Det kräver att systemet har en funktion där användare registrerar att de påbörjat sin tvättid. Kanske gör det att ingen vill 3

7 DOKINT Grupp använda systemet eftersom de tycker att det blir krångligt att använda? Enligt Heckel ska funktioner som bygger upp användarens försvar undvikas (Larsson, 2003). Användaren måste identifiera sig för systemet. Kort känns inte som en bra lösning, det kan komma bort eller sluta att fungera. Men ett kort skulle minska den kognitiva belastningen. Lägenhetsnummer och pinkod som identifiering kräver att användaren kan sitt lägenhetsnummer och kommer ihåg sin kod, vilket gör att det blir två saker att minnas. Däremot underlättar identifiering med pinkod för vidare utveckling mot användande via Internet. Det är viktigt att hitta en balans mellan vad användaren ska utföra och vad systemet borde sköta (Norman, 1988 och Norman, 1993). 4 Bokningssystem - steg 2 Flera informella intervjuer med potentiella användare genomfördes per telefon och genom direkt kontakt. Resultat från intervjuerna utvärderades. 4.1 Diskussion med möjliga framtida användare Efter att ha gått igenom egna idéer diskuterades bokning av tvättider i allmänhet med flera personer som skulle kunna vara systemets framtida användare. Det var män och kvinnor från olika åldersgrupper som tillfrågades och de representerade både studenter och yrkesverksamma. De intervjuade studenterna kom från olika högskolor och övriga var vänner till oss. Efter den allmänna diskussionen ställdes även frågor om några av funktionerna i det tänkta systemet för att se om fler önskade ett interaktivt bokningssystem, och om det därigenom finns en marknad för bokningssystemet. Till intervjuerna användes Quick and Dirty teknik för att snabbt få återkoppling till våra idéer och få uppslag till nya, innan utformningen av skissprototyper påbörjades (Preece et al, 2002). I bilaga 3 redovisas resultaten av diskussionerna med användarna Problemanalys Under intervjuerna gavs olika kommentarer till hur inloggning bör ske samt synpunkter på hur kölista, tvättkvot, tvättpass utformas bäst. De flesta som intervjuades ville gärna ha möjlighet att boka tvättider hemifrån och systemet utvecklas därför för att fungera i ett nätverk. Av de brister som användarna upplevde i sina nuvarande system försökte vi komma fram till vad ett datorbaserat system skulle kunna korrigera. Kommentarer kring användning av magnetkort för identifiering av användare, såsom att det kan krångla och att det brukar ta lång tid att få ett nytt, fick oss att överge tanken på den lösningen. För bokningssystemet beslutades därför att lägenhetsnummer och lösenord ska användas vid inloggning. Efter positiva kommentarer om kölistor behölls den funktionen. Det skulle delvis kunna lösa problemet med att vissa lånar tvättider och drar över på andras tvättpass. 4

8 DOKINT Grupp När det gällde flexibla tvättpass gavs väldigt olika svar. Därför valde vi att undersöka vad fler användare tycker genom att ha kvar den lösningen vid utformningen av den första skissprototypen. 5 Bokningssystem - steg 3 Två prototyper av systemet, skisserade på papper, togs fram med hänsyn tagen till resultat från brainstorming och de första användarintervjuerna. Skissprototyperna testades sedan på nya potentiella användare genom Quick and Dirty intervjuer. Kommentarer samlades även in från seminarium 1. Därefter utvärderades resultaten och egna idéer förkastades eller vidareutvecklades. 5.1 Framtagning av skissprototyper Nästa steg i arbetet var att göra Low-fidelity prototyper i skissform. De är enklare och billigare att producera och modifiera vilket passade vid detta tidiga skede i designutvecklingen (Preece et al, 2002). Vi delade upp oss i grupper för att få fram två helt skilda idéer till hur systemet skulle kunna se ut. Efter att grupperna gjort ett antal skisser över de centrala funktionerna av systemet samlades alla igen för att utvärdera förslagen och revidera skissprototyperna, innan de testades med tänkta användare. Under processen att ta fram två skissprototyper framkom fler frågor och funderingar, dessa frågor redovisas i bilaga Skissprototyp 1 Denna skissprototyp är en vertikal prototyp eftersom fokus lades på ett fåtal funktioner med fler detaljer (Preece et al, 2002). Användaren loggar in med hjälp av lägenhetsnummer och lösenord. Därefter presenteras användaren en kalender indelad i dagar som visas med en vecka per rad. Genom att klicka på önskad dag får användaren en mer detaljerad bild i form av en tidslist under kalendern. I tidslisten syns vilka tider som är bokade och vilket lägenhetsnummer som gjort bokningen. Användaren kan boka tid genom att markera lediga timmar i tidslisten och bekräfta med en bokningsknapp. Bilder och en mer utförlig beskrivning av prototypen finns i bilaga Skissprototyp 2 Skissprototyp 2 är av typen horisontell prototyp eftersom fokus lades på flertalet funktioner och inte lika ingående på detaljnivå (Preece et al, 2002). Här loggar inte användaren in utan möts direkt av en kalender där det går att välja vilken dag man vill boka. Efter att dag valts presenteras ett schema över tillgängliga resurser för denna dag i en ny vy. Där kan antingen de resurser som önskas bokas eller standby-tid på redan bokade resurser reserveras. Först vid bokningens verkställande kräver systemet identifiering. Skissprototypen beskrivs mer utförligt i bilaga 5. 5

9 DOKINT Grupp Användartest på skissprototyper Varje prototypskiss testades på två framtida användare genom Quick and Dirty intervjuer. Därigenom kunde en snabb återkoppling fångas upp i ett tidigt skede på de två skissprototyperna vilket gav en fingervisning av vad användare föredrar i ett bokningssystem. (Preece et al, 2002) Intervjuerna genomfördes med både män och kvinnor i olika åldrar. De tillfrågade var i huvudsak studenter på DSV som inte läser kursen Design och konstruktion av interaktiva system, men även en yrkesverksam person intervjuades. Nedan finns en sammanfattning av intervjuerna och i bilaga 6 redovisas de utförligt. Gemensamt för testpersonerna av de båda prototyperna var att de tyckte det var en mycket bra idé som de gärna skulle vilja se förverkligad Resultat av användartest på Skissprototyp 1 Här följer en kort sammanfattning av några åsikter som framkom vid Quick and Dirty intervjuerna. - Gränssnittet för tidsbokning grötigt, ha ett färre antal veckor i översikt. - Raden som visar bokade tider för en viss dag borde markeras tydligare. - Det är bra att man kan se i smårutorna för varje dag hur mycket som är bokat, men det kan vara svårt att se om det verkligen är fullbokat. - Veckorna bör listas horisontellt istället för vertikalt. - Möjligheten att få kvittens via e-post, SMS eller ICQ är bra. Det finns flera alternativ, t.ex. AOL och MSN [men även åsikten] antalet sätt att få kvittensen på borde begränsas. - Bra idé att ha en personlig sida där man kan ändra sina inställningar, [men även åsikten] personlig profil med inställningar överflödigt. - Det borde gå att se alla sina bokningar i en lista. - Timvis bokning förvirrande men flexibelt. - Borde finnas tydligare sätt att se hur många timmar av sin tvättidskvot som man har förbrukat Resultat av användartest på Skissprototyp 2 Ett sammandrag av vad som framkom vid Quick and Dirty intervjuerna med användare som fick se skissprototyp 2 finns nedan. - Undvik inloggningar på flera ställen i systemet, bara på första sidan, systemet blir enklare att förstå och får en enklare grafisk utformning [men även åsikten] mycket bra att systemet inte kräver inloggning för att titta på hur tvättstugan är bokad. - Förstasidan som visar en hel månad bör skäras ned till två veckor. - Bra att detaljinformationen om respektive dag visas på en ny sida. Ha så lite information som möjligt på varje sida. - Det bör framgå i vyn välj tvättid hur många som står i standby-kö. - Sidan mina bokningar är bra, men det ska finnas en knapp som heter ändra. Om någon vill ändra en tid vill de ha en ändra knapp och inte klicka på en som det står avboka på. - Påminnelsetiden bör om möjligt göras ännu tydligare om att det rör ordinarie tider och inte standby. 6

10 DOKINT Grupp Använd gärna korta förklarande texter på varje skärmbild. - Att slippa inloggning helt och hållet genom att använda en kortlösning eller magnetbricka vore en ännu bättre lösning. - Möjligheten att boka standby-tid positivt. - Funktionen för att avboka tvättider enkel och logisk. - Idén med klotterplank är bra. 5.3 Seminarium 1 De båda skissprototyperna visades även för studenter på kursen Design och konstruktion av interaktiva system. Kommentarerna vi fick under seminariet och från vår bollplanksgrupp redovisas i bilaga Förkastade förslag Baserat på kommentarer från användare, litteraturstudier och eget ställningstagande har nedanstående förslag förkastats: - Bokning med hjälp av knapptelefon. Idén är genomförbar men alldeles för krånglig eftersom all visuell hjälp och stöd inte skulle finnas (Norman, 1988). - Påminnelser i form av ICQ meddelande. Chat-funktioner till datorer kommer och går i alldeles för korta tidsintervall. Ges det stöd för ett system så måste man ge stöd för alla eftersom alla hyresgästerna antagligen inte använder samma system. - Användning av Windows eller Macintosh operativsystem. Alternativen är oväsentliga eftersom det går att utveckla plattformsoberoende. - Fasta tvättider. Denna funktion bör kunna konfigureras av systemadministratören, vi ska inte styra tvättpassens längd. - Magnetkort för identifiering. Denna lösning är inte dålig men till slut valdes idén med lösenord. Det är ett billigare alternativ och användarna slipper ännu ett kort i den redan fulla plånboken. - Nyckelbricka med trådlös överföring. Förkastades av samma anledning som magnetkort. En tänkbar lösning för framtiden är användning av en bricka för inloggning där systemet läser av brickan via trådlös kommunikation för att identifiera användarna. Med bricka slipper användare komma ihåg sitt lösenord vilket är en fördel eftersom att komma ihåg ett lösenord kan bli en kognitiv belastning. Brickans funktioner skulle dessutom kunna utvidgas så att den används som nyckel för att t.ex. komma in i tvättstugan. - Touch Screen är för dyrt då det kan finnas billigare alternativ för inköparen av systemet. 5.5 Problemanalys Utifrån den återkoppling som getts från ovan redovisade användartester och seminarium gjordes följande förändringar och val. Frågan kring hur man kommer in i tvättstugan var något som inte kunde avgöras i detta skede. Hyresvärdar eller fastighetsskötare måste tillfrågas för att höra deras åsikt om det ska vara baserat på ett kortsystem eller inte. 7

11 DOKINT Grupp Ett annat problem var hur inloggning ska ske - med bricka eller med lösenord och användarnamn. Med utgångspunkt från tidigare diskussion som togs upp i avsnitt 3.2, valdes lösenord och användarnamn. Dels för att det ska finnas möjlighet att bokningssystemet i framtiden ska kunna anpassas till en webbapplikation och dels för att enkelt kunna appliceras i en PC-applikation. Konceptet från prototyp 2, att kunna se en helhetsbild av bokningar innan inloggning behålls, eftersom det uppskattades vid användartest. Användare kommenterade även till skissprototyp 1 att det vore bra att få en översikt av tvättiderna utan att behöva logga in. För att det inte ska vara för krångligt begränsas inloggningsmöjligheterna till enbart två vyer. Detta baseras på kommentarer till skissprototyp 2 där användare ansåg att inloggningsmöjligheter i flertalet vyer blev förvirrande. I den nya prototypen finns därför enbart möjligheten till inloggning i vyerna startsida och välj tvättid. På så sätt är det möjligt för användaren att se en mer detaljerad vy av bokningarna innan inloggning. Knapp för att logga ut införs på samtliga vyer. För att det tydligt ska framgå att användaren inte är inloggad finns inga knappar för navigering direkt vid start, utan dessa dyker upp först vid inloggning. Det innebär en mindre kognitiv belastning då det minskar den mängd information användaren ser innan inloggning skett (Preece et al, 2002). När en inloggning väl har gjorts visas inte längre några inloggningsfält i startsida och välj tvättid vyerna. Kalenderlayouten behålls efter användartest men utseendet blir en blandning från de båda skissprototyperna. Dagarna separeras i egna rutor så att de kan fungera som knappar, såsom det såg ut i skissprototyp 2, med förhoppning att det skapar en tydlig perceived affordance (Norman, 1999). Däremot används månad/dag/vecka ramverket från skissprototyp 1 med möjlighet att bläddra upp eller ner mellan veckor med hjälp av pilikoner eftersom det var det förslag som fick mest positiv återkoppling. Dessutom behålls konceptet med att visa kalendern veckovis där den aktuella veckan visas överst som standardinställning. Konceptet från prototyp 1 med att visa redan passerade bokningar behålls, vilket även det är baserat på användares kommentarer. Det är önskvärt för användare att kunna se vem som använt tvättstugan tidigare för att t.ex. kunna meddela att något är kvarglömt. Pilarna för att bläddra mellan dagar eller veckor i startsida och välj tvättid vyerna har placerats i förhållande till vad som kan vara mer naturlig mapping snarare än att försöka tänka att det blir konsekvent mellan vyernas gränssnitt (Norman, 1988). En återkommande fråga var hur navigeringen i systemet skulle ske i den nya prototypen. Ska det ske med fliksystem, menysystem, knappar eller med ett navigeringssystem med ramar såsom i webbapplikationer? Knappar valdes som navigeringssätt för den nya prototypen för att vara konsekvent med övrig design som huvudsakligen utformats med bilder i knappform. Samma knappar återfinns i alla vyerna för att det ska vara enkelt att lära och använda (Preece et al, 2002). Dessutom finns ett statusfält direkt ovanför knapparna där hjälp- och statusmeddelanden visas. Lösningen är en sammanslagning av de båda tidigare 8

12 DOKINT Grupp prototyperna. Knapparna för navigering är placerade i horisontell riktning längs ned i vyn för att det utrymmesmässigt fick bäst plats där. Statusraden behålls eftersom det framgick att användare tyckte att det var bra att ha och eftersom det blir för grötigt att ange hjälptext mitt bland de övriga delarna i gränssnittet. Nytt i prototypen är en titelrad som placerades längst upp och ska visas i alla vyerna med antingen Ej inloggad eller Inloggad som lägenhetsnr A312 samt ange dagens datum och tid såsom Fredagen den 14 oktober 09:43. Detta infördes efter ett gemensamt beslut för att göra det enkelt för användaren att se inloggningsstatus och för att lätt kunna visa tid och datum oberoende vilken vy användaren tittar på. Kvottiden ska vara inställbar på antal timmar och tidsperiod (såsom vecka eller månad - t.ex. tim/månad). Administratören bör vara den som ska göra denna inställning. Att ha tvättpass som är endast en timme långa är inte lämpligt i prototypen eftersom många personer hakat upp sig på den detaljen istället för att kommentera hur bokningen fungerar. Välj tvättid vyn behålls från prototyp 2 då det framgår från användares kommentarer att det ska vara möjligt att välja maskingrupp. Det går inte att välja maskingrupp i skissprototyp 1 och det visade sig bli grötigt när detta på försök implementeras i skissprototypen. Att visa tvättkvot grafiskt behålls från prototyp 1 men med den skillnaden att den visar tvättkvot per vecka eller månad beroende på hur administratören valt för inställningar. Den omarbetas också efter kommentarer från användare. Boka standby-tid vyn behålls från prototyp 2. Användare ansåg att det var en bra funktion att kunna boka standby-tider. Funktionen för att kunna frigöra resterande tvättid av en pågående bokad tvättid behålls från prototyp 2. Den är knuten till standby-tider för att det ska finnas en nytta med just denna funktion. Antalet sätt att få kvittens/påminnelse begränsas men alternativ att bli uppringd av en datorröst införs efter idé från användare. Vyn mina bokningar från prototyp 2 behålls, men mina inställningar används kanske inte lika ofta som mina bokningar och därför har dessa funktioner delats upp i två olika vyer i nya prototypen. Vyn tvättstugeforum/felanmälan behålls från prototyp 2 men i två separata vyer, forum och felanmälan. Dels för att en kombinerad knapp (Tvättstugeforum/Felrapportering) var en otympligt lång knapp och dels för att det faktiskt är två olika funktioner. Det kanske inte är intressant att se alla felrapporter varje gång forumet används. Gränssnitt bör vara enkelt utformade och visuellt tydliga, dessutom bör information overload undvikas för att minimera användarnas frustration (Preece et al, 2002). 9

13 DOKINT Grupp Bokningssystem - steg 4 - användarvyer Studium av befintliga system för liknande bokningssystem genomfördes. Ytterligare en skissprototyp togs fram. En High-fidelity prototyp utvecklades med hjälp av MS PowerPoint. Den nya prototypen utformades med hänsyn till resultatet av steg fyra. Ytterligare nya användare testade prototypen. Utvecklingen av administratörsvyerna skedde parallellt med framtagningen av användarvyerna. Eftersom de olika momenten sammanföll blir processen svår att följa för de respektive delarna. Steg fyra delas därför upp för att underlätta läsning av dokumentationen. 6.1 Studier av befintliga system För att hitta fler infallsvinklar studerade vi ett befintligt system för att se vad som redan har gjorts. Därigenom kunde andra lösningar upptäckas än de som redan framkommit. För att inte påverkas för mycket av det som redan utvecklats studerades andra system efter det att skissprototyperna tagits fram och testats på både användare samt vid seminarium 1. Hur det studerade systemet fungerar beskrivs i bilaga Framtagning av prototyp utvecklad i MS PowerPoint Baserat på kommentarer som samlats in vid seminarium 1 där återkoppling på skissprototyperna mottogs och redan tidigare insamlade kommentarer från intervjuer av användare, utformades en High-fidelity prototyp. Detta för att få en känsla hur produkten uppför sig på riktigt (Preece et al, 2003). I avsnitt 5.4 Förkastade förslag och 5.5 Problemanalys beskrivs vilka förändringar vi valde att göra. Den nya prototypen skissades först upp på papper och utvecklades därefter i MS PowerPoint. Bilder från prototypen finns i bilaga 9. Den nya versionen blev i stort sett en sammanslagning av de funktioner som ansågs vara bäst från de två tidigare skissprototyperna. Vi anser att det finns en risk med att sammanfoga de bägge skissprototyperna eftersom en bra funktion kan bli sämre i en sammanslagen lösning. Bra lösningar i en tidigare skissprototyp kanske inte blir lika bra i det nya kontextuella sammanhang som den sammanslagna prototypen medför. Detta är något som måste testas mot användare för att få mer underlag att utgå ifrån. 6.3 Deltagande observation Nästa steg i utvecklingen av bokningssystemet var att testa de viktigaste delarna av systemet. Målet med testen var att upptäcka detaljer och egenskaper som annars kan vara svåra att hitta. Genom testerna erhölls en tydligare bild över om vi hade förstått användarnas önskemål på rätt sätt, om gränssnittet var enkelt att förstå och hur väl systemet löste arbetsuppgifterna. En prototyp utvecklad i MS PowerPoint testades genom deltagande observation (eng. contextual inquiry). Det är en kombination av observation, diskussion och rekonstruktion av tidigare händelser där utvecklaren och användaren samarbetar (Preece et al, 2002). 10

14 DOKINT Grupp Genomförande av pilottest och användartester För att inte riskera att missa intressanta kommentarer eller problem som observeras under testerna deltog tre utvecklare. Testet administrerades av en person som även skötte kontakten med användaren. En annan utvecklare agerade systemet och kompletterade med kommentarer vad systemet skulle ha gjort när användaren utforskade funktioner i prototypen som inte fanns implementerade. Ytterligare en utvecklare hade som enda uppgift att föra anteckningar. Innan testet påbörjades genomförde utvecklarna en grov pilottest av systemet. På så sätt säkerställdes det att prototypen fungerade som det var tänkt och inte uppvisade onödiga fel som hade förbisetts vid konstruktion. Utvecklarna som skulle genomföra testet kunde därigenom även bekanta sig med sina respektive roller inför de riktiga testerna. Tre personer som skulle kunna vara framtida användare och som inte sett systemet tidigare fick testa prototypen. Varje intervju började med att användaren informerades om målet med testet, hur lång tid det skulle ta och hur resultatet skulle användas. Därefter gavs testpersonen en kort introduktion till systemets utformning och placering, för att testpersonen skulle förstå systemets omgivning (eng. context). Testpersonen fick sedan i uppgift att genomföra en bokning av tvättid utifrån ett tänkt scenario att personen håller på att tvätta och ska boka en ny tvättid. Under testet observerades användaren och instruerades att tänka högt (Preece et al, 2002). Allt testpersonen kommenterade under utvärderingen av prototypen samt de frågor testpersonen ställde antecknades. Följande frågor ställdes efter att respektive test genomförts. - Kön - Åldersgrupp? (<25, 26-35, >35) - Hur stor datorvana har du på en skala från ett till fem, där 1 är lite och 5 mycket? - Hur bokar du din tvättid idag? - Är systemets navigation enkel att förstå? - Är terminologin som används lättbegriplig? - Har systemet en konsekvent utformning? - Vad tycker du om färgerna? - Vad gillade du med systemet? - Vad gillade du inte med systemet? - Var det någon del av systemet svår att förstå? - Hur kan systemet bli bättre? - Har du använt liknande system tidigare? Resultatet av de tre genomförda observationerna med efterföljande intervju redovisas i bilaga

15 DOKINT Grupp Resultat av användartester Bokningssystemet använder många begrepp som verkar vara svåra att förstå såsom standby, frigör tvättid, kvottid och ordinarie tvättid. Vissa delar av systemet var inte konsekvent, såsom knapparna för att boka tvättider och standby-tider. För att boka standby-tid kommer man till en annan vy och det visade sig vara förvirrande. Standby, frigöra tvättid, och kvottidskoncepten var bra enligt användarna men svåra att förstå hur de fungerar i systemet. Det som uppstått här är vad Norman menar med att exekverings- och evalueringsklyftan är för stor (eng. Gulf of execution och Gulf of evaluation). (Norman, 1988) Alla användare tolkade kalenderdagarna som klickbara, vilket bekräftade vår förhoppning om perceived affordance, och översikten för bokningar utnyttjades innan de loggade in. Hjälptexterna som visades i prototypen lästes i princip inte alls, dock önskades att hjälptext visades när pekdonet är över ett objekt i systemet. Färgkoderna för egen bokning och andras bokningar tolkades såsom det var tänkt Validitet En vedertagen metod kallad deltagande observation, med noggrant valda intervjufrågor, har följts för att få reda hur systemets interaktion med användare fungerar. Med tanke på antalet försökspersoner som användes i observationerna och metoden som använts är det insamlade data kvalitativt. (Preece et al, 2002) 6.4 Seminarium 2 Prototypen utvecklad i PowerPoint visades upp vid ett nytt seminarium för övriga studenter på kursen. Både prototypens användarvyer och administratörsvyer visades upp. Hur administratörsvyerna utvecklades beskrivs i kapitel 7. De synpunkter som kom fram under seminariet och från vår bollplanksgrupp redovisas i bilaga 11. Kommentarer gavs om att det borde göras användartester på äldre och personer utan datorvana. Det efterlystes även tydligare information om var systemet kommer att befinna sig vilket kommer att tydliggöras i dokumentationen. Vissa benämningar som ordinarie tvättid kan missförstås och bör förtydligas. Positiv återkoppling gavs på funktionen boka standby-tid. 6.5 Förkastade förslag Fler förslag som har förkastats under arbetet: - Att förhindra att användare lånar tvättider förkastas eftersom det förmodligen innebär att systemet måste vara knutet till någon form av låsningsmekanism till tvättstugan. - Att förhindra obehörigas tillgång till tvättstuga förkastas eftersom detta inte anses vara något som bokningssystemet ska lösa. 12

16 DOKINT Grupp Problemanalys Till nästa prototyp ska otydligheten med standby, frigöra tvättid, och kvottid koncepten åtgärdas för att minska exekverings- och evalueringsklyftan. Begreppen att boka standby och frigöra tvättid visar sig genomgående i användartesterna vara svårförstådda vid första anblick, men gillades efter kort beskrivning. Det behövs möjligtvis andra namn till dessa begrepp. Metaforen (standby) är kanske för starkt kopplad till andra domäner den är känd i. Detta medför enligt Nelson att användaren hindras att förstå vad denne egentligen kan utföra (Preece et al, 2002). Viss begreppsförvirring råder även om vad "ordinarie tvättid" är, menar en del användare i testerna. Till nästa version ändras begreppen boka standby till boka köplats och frigör tvättid till tvättat färdigt. Eftersom användare inte förstår betydelsen av de olika färgerna i tvättkvoten så bör istället endast en färg användas. På startsidans knappar ska markeringarna som motsvarar bokade tider förändras så att det blir tydligare koppling till hur det ser ut i vyn välj tvättid. Av användartesterna framgår att en funktion i systemet bör läggas till så att hjälptext dyker upp i statusraden när pekdon är över ett objekt. Tipstexter förbättras och andra benämningar i systemet ses över efter kommentarer från användare. Återkoppling vid bokning förbättras. Användarna efterfrågar också tydliga bekräftelser på att tänkt operation verkligen är genomförd. Buggar i prototypen ska rättas till nästa version. En bugg som upptäckts under användartester är en blå ruta som avser att visa en egen bokning. Rutan visas redan innan någon användare loggat in. 7 Bokningssystem - steg 4 administratörsvyer För att ta reda på vilka funktioner en hyresvärd vill ha intervjuades en framtida administratör. Två olika skissprototyper togs fram och testades. Resultatet utvärderades och en prototyp i PowerPoint utvecklades. Prototypen på hela bokningssystemet visades sedan upp på seminarium 2 och synpunkter samlades in. Utvecklingen av administratörsvyerna skedde parallellt med framtagningen av användarvyerna. Eftersom de olika momenten sammanföll blir processen svår att följa för de respektive delarna. Steg fyra delas därför upp för att underlätta läsning av dokumentationen. 7.1 Intervju med fastighetsskötare Alla intressenter bör kartläggas och tas hänsyn till vid utveckling av ett system (Preece et al, 2002). Idéerna kring bokningssystemet måste därför även förankras med potentiella kunder, de framtida administratörerna av systemet. Inköpare av systemet skulle kunna vara fastighetsägare eller styrelser i bostadsrättsföreningar. 13

17 DOKINT Grupp För att även få in synpunkter från denna viktiga grupp användare intervjuades en fastighetsskötare från en bostadsrättsförening. Vid intervjutillfället fanns endast en mycket grov skiss på hur en framtida administratörsvy skulle kunna se ut och användaren tillfrågades i huvudsak om systemets huvudfunktioner. Fastighetsskötare: - En pekskärm skulle vara bra - men dyrt. - Är det så att torktiden är förskjuten i förhållande till tvättid? - Namngivning på de olika maskinerna ska vara tydlig, det behöver inte vara namn utan går lika bra med nr. - Tvättkvot bör finnas, men under t.ex. sommaren när nästan ingen är hemma, måste det vara möjligt att tvätta även om tvättkvoten är slut. På så sätt utnyttjas tvättstugan även om många är borta. - Speciell stor tvättkvot till barnfamiljer blir kanske extra mycket administration, men kan vara bra att möjligheten finns. (Känner till ett ställe där en maskin är speciellt till för nödfall.) - Generellt ett mycket intressant system. Att användare ska kunna boka hemifrån låter mycket bra. - Verkar vara ett enkelt och intuitivt gränssnitt. - Systemet måste vara mycket driftsäkert, får inte sluta fungera! - Max utnyttjande med hjälp av standby tvätt är mycket bra. 7.2 Framtagning av funktioner för administratör, skissprototyp Konfigureringsinställningar för fastighetsskötare och hyresvärd fanns inte med i de tidigare skissprototyperna och därför togs det fram två förslag på administratörsvyer i form av grova Low-fidelity skissprototyper. Skisserna gjordes genom att gruppen först diskuterade vilka funktioner som skulle vara bra att ha. Efter den inledande diskussionen skissades två separata förslag upp. Förslag 1: Det första skissförslaget har en enda vy med alla inställningar som administratören kan göra i systemet. Förslag 2: I det andra skissförslaget är alla inställningar grupperade i flera delvyer: start, bokningar och användarinställningar. Båda förslagen kräver att administratören loggar in. Inställningarna skiljer sig åt layoutmässigt men inte innehållsmässigt Användartest på de båda administratörsförslagen Ett användartest genomfördes med en person som är ordförande i en bostadsrättsförening. Testpersonen fick först fritt komma med egna tankar kring ett bokningssystem utan att ha blivit presenterad våra skissprototyper. Därefter fick testanvändaren se pappersskisserna till den version som togs fram för utvecklingen av prototypen i MS PowerPoint. Testpersonen fick komma med kommentarer till prototypen. Slutligen visades även de två skissförslagen på administratörsvyer och testanvändarens kommentarer på dessa noterades. 14

18 DOKINT Grupp Resultat av administratörstest I bilaga 12 finns hela resultatet av administratörstesten, men här följer en kort sammanfattning av vad som framkom. Tre viktiga egenskaper som systemet måste ha är att det ska vara säkrare genom att användaren ska veta att den bokade tiden gäller och ingen ska kunna fiffla med den. Det ska vara billigt och även enklare, testpersonen tyckte absolut att användarna ska kunna boka elektroniskt via ett nätverk eller via webben. Standby-tid verkar vara en bra funktion enligt testpersonen men han ansåg att tvättstugeforum och mina inställningar var överflödigt för deras behov. Felanmälningar var en bra funktion eftersom det är bra att ha fel-loggar att gå tillbaka till, för att se historiken över åtgärdade fel för att kunna beräkna driftskostnader. Som administratör ska det inte vara krångligare. Det ska gå snabbt och enkelt att hantera samt ha få inställningar att tänka på. Bara viktiga funktioner som att lägga in användare, bestämma tvättperioder och kvottider är intressanta. Styrelsens är mer intresserade av kostnader - vad kostar tvättstugan? Önskemål var att systemet skulle kunna mäta elförbrukning, vattenförbrukning och hur ofta maskinerna repareras samt få reda på nästa service datum Problemanalys För att skapa enlighet och få en uniform känsla med övriga systemet ska administratörsvyerna utformas med samma gränssnitt som användarvyerna enligt Nielsen och Sano (artikelsamling, 2003). Av användartestet framkom att vyerna inte bör vara för stora utan delas upp för att slippa använda skrollfunktionen. Enkelhet och minimalism bör efterstävas då tillfrågade administratörer önskar detta p.g.a. hög arbetsbelastning på andra områden. 7.3 Framtagning av prototyp för administratörsvyer, PowerPoint Utifrån kommentarerna från användartestet på de båda skissförslagen för administratörsvyerna samt från den första intervjun med en fastighetsskötare (se avsnitt 7.1), utformades en ny prototyp för administratörsvyn i MS PowerPoint. Den nya prototypen var delvis en kombination av de två tidigare skissförslagen med vissa ändringar och nytillägg (se bilaga 13). 8 Bokningssystem - steg 5 Utifrån resultaten från observationerna och intervjuerna på prototypen i MS PowerPoint gjordes ytterligare en High-fidelity prototyp med mer funktionalitet i Authorware. Därefter gjordes en ny test med testpersoner som inte hade tillfrågats tidigare. Steg fem itereras med utvärdering och uppdatering av prototypen samt nya användartester. 8.1 Framtagning av prototyp utvecklad i Authorware Efter att ha utvärderat resultaten från de tidigare intervjuerna och användartesterna diskuterades vilka förändringar som skulle göras i systemet (se avsnitt 6.3.3). Därefter utvecklades en High-fidelity prototyp i Authorware för att skapa en tydligare känsla av funktionalitet och komma närmare hur den färdiga produkten kan se ut (Preece et al, 2002). Bilder från prototypen finns i bilaga

19 DOKINT Grupp Deltagande observation En prototyp utvecklad i Authorware testades genom deltagande observation. Målet med testen var att upptäcka om våra förändringar förbättrade användarens upplevelse av systemet och att hitta detaljer och egenskaper som annars kan vara svåra att hitta. Testerna utfördes även för att se om gränssnittet är enkelt att förstå och hur väl systemet löser arbetsuppgifterna Genomförande av pilottest och användartester Pilottestet och användartesterna på prototypen utfördes enligt samma mall som de tidigare PowerPoint-testerna (se avsnitt 6.3.1). Fem utvecklare administrerade testerna för att ännu bättre fånga upp testpersonernas kommentarer och interaktion med prototypen. Tyvärr var alla testanvändare män med stor eller medelstor datorvana. Eftersom testerna utfördes på skolan var det svårt att hitta ett representativt urval användare Resultat av användartester Användarna hade lätt att förstå hur systemet skulle användas. Vi fick en del kritik på användningen av färgerna som representerar de tider som är bokade av andra och den egna lägenheten. En av de tre tänkta användarna försökte boka en tid och missade helt att trycka på registrera bokning. Vid tillfället efter upptäckte denna försöksperson dock själv misstaget. En av försökspersonerna dubbelklickade på allt genom hela försöket, men bara vid ett tillfälle skapade detta problem, då han gick vidare till en tredje vy utan att förstå varför. Vi fick en hel del små tips om hur systemet med enkla medel skulle kunna bli lättare att förstå. I bilaga 15 finns resultatet av användartesterna i sin helhet Problemanalys Åtgärder som krävs till nästa version av prototypen är att förbättra hur kvottiden presenteras i gränssnittet, lägga till möjligheten att ångra där användaren lätt kan göra misstag och ytterligare förtydliga svåra begrepp. Återkopplingen till användarna förbättras genom användning av pop-up fönster som både informerar om vad som kan utföras och ger möjlighet att ångra. Trots att vi hade tänkt att namngivning av maskingrupper var upp till hyresvärden beslutades ändå att ändra på maskingruppernas namn i prototypen. En användare missförstod benämningen av maskingrupper med bokstavsbeteckning A + B och kopplade det till de lägenhetsbeteckningar vi valt i prototypen som alla börjar på en bokstav. Sådana missförstånd försvårar testningen av prototypen eftersom användaren fokuserar på administrativa funktioner, vilket vi inte var ute efter att testa denna gång. 16

20 DOKINT Grupp Revidering av prototyp Utifrån problemanalysen omarbetades Authorwareprototypen för att anpassas ännu bättre till användarnas krav. Några upptäckta buggar i systemet rättades också till. De framträdande förändringarna som gjordes var följande: - Den grafiska representationen av kvottid får konsekvent utseende i alla vyer där den förekommer. - Begreppet tvättkvot ändras till förbrukad tvättkvot. - Startsida ändras till kalender eftersom det framkom att minst en användare endast tog en chansning för att komma till denna vy. - Möjlighet att kunna ångra infördes både för tvättat färdigt i kalender vyn och för avboka i mina bokningar vyn. - Maskingruppnamnen ändrades så att det inte uppstår förvirring med den tänkta funktionaliteten i prototypen. - Veckonummer infördes på de vyer där datum presenteras för att skapa tydligare sammanhang. - En uppdatera knapp läggs också till i mina inställningar vyn. 8.4 Genomförande av ytterligare användartester Att iterera under utvecklingsarbetet är viktigt och därför utfördes nya användartester efter uppdateringen av prototypen. Den omarbetade versionen av Authorware prototypen testades på två personer. Efter att scenariot förklarats fick personerna fritt använda programmet De två testpersonerna valdes främst för att de representerade en betydligt äldre generation jämfört med de personer som tidigare testat prototyperna. En av testpersonerna är i 60-års ålder och den andre strax över 40. Valet av äldre testpersoner gjordes avsiktligt för att undersöka om det är någon skillnad i hur de uppfattar bokningssystemet. Eftersom alla åldrar förekommer i hyresrätter och bostadsrätter bör eventuella skillnader i uppfattningar tas hänsyn till. Resultatet i sin helhet redovisas i bilaga Problemanalys I användartesten framgick att den ena testpersonen hade svårt att förstå hur bokning utfördes i systemet, men att personen trodde det skulle gå att förstå när denne blivit mer insatt i systemet. Båda användarna tyckte att terminologin var enkelt att begripa och var positiva till bokningssystemet i sin helhet. De hade båda kommentarer om vad som kunde förbättras på olika delar av systemet. Intressant var att även dessa två testpersoner inte valde att använda hjälpfunktionen utan tittade på hjälpvyn allra sist. 17