DeDU - Marknadens mest användarvänliga programvara?

DeDU - Marknadens mest användarvänliga programvara? Lars Åström February 20, 2007 Master s Thesis in Computing Science, 20 credits Supervisor at CS-UmU: Jan-Erik Moström Examiner: Per Lindström Umeå University Department of Computing Science SE-901 87 UMEÅ SWEDEN

Sammanfattning Denna rapport behandlar användbarhetsutvärderingen av programvaran DeDU. DeDU är en programvara avsedd bland annat för planering av fastighetsskötsel och underhåll. Det grafiska användargränssnittet i programvaran utvärderades med två metoder: användbarhetstester och Heuristic Walkthrough. Ett antal användbarhetsproblem identifierades under denna utvärdering. Resultaten från utvärderingen låg som grund för framtagandet av en interaktiv prototyp. Syftet med prototypen var att visualisera de förbättringar som skulle kunna göras för att öka programvarans användbarhet. Även prototypen utvärderades och resultaten indikerade att denna var lättare att använda än DeDU. Slutsatsen är att god planering och noggranna förberedelser är viktiga när användbarhets utvärderingar ska utföras. En annan slutsats är att det är fördelaktigt att kombinera olika typer av utvärderingsmetoder då dessa hittar olika typer av problem. DeDU - The most user-friendly application on the market? Abstract This master thesis involves the usability evaluation of a software called DeDU. DeDU is a software intended for helping companies in managing the maintenance of their real estate and houses. The graphical user interface of DeDU was evaluated with two methods: usability testing and Heuristic Walkthrough. A number of usability problems were found during the evaluation. The results from the evalutation formed the foundation for an interactive prototype which should visualize usability improvements to be made to the software. The prototype was also evaluated with respect to usability and the results indicated that the prototype was easier to use than DeDU itself. A conclusion is that good planning and thorough preparation are crucial elements when conducting usability evaluations. Another conclusion is that it is a good idea to combine different evaluation methods since they can reveal different kinds of usability problems.

ii

Innehåll 1 Introduktion 1 1.1 Användbarhet................................. 1 1.2 WSP och DeDU............................... 1 1.3 Disposition.................................. 2 2 Uppgift, metoder och mål 5 2.1 Uppgift.................................... 5 2.2 Metoder.................................... 5 2.3 Mål...................................... 5 3 Granskning av användbarhetsutvärderingsmetoder 7 3.1 Automatiska metoder............................ 7 3.1.1 Diskussion om automatiska metoder................ 9 3.2 Empiriska metoder.............................. 9 3.2.1 Användbarhetstester......................... 9 3.2.2 Diskussion om empiriska metoder.................. 11 3.3 Prediktiva metoder.............................. 12 3.3.1 Heuristisk utvärdering........................ 12 3.3.2 Cognitive Walkthrough....................... 14 3.3.3 Heuristic Walkthrough........................ 15 3.3.4 Diskussion om prediktiva metoder................. 16 3.4 Slutsats av litteraturstudie.......................... 17 3.4.1 Tillgängliga resurser......................... 17 3.4.2 Krav på utvärdering......................... 17 3.4.3 Metoderna mot varandra...................... 17 3.4.4 Utsedda metoder........................... 19 4 Användbarhetsutvärdering av DeDU 21 4.1 Genomförande................................ 21 4.1.1 Förstudie och skapande av användarprofil............. 21 4.1.2 Heuristic Walkthrough........................ 22 iii

iv INNEHÅLL 4.1.3 Användbarhetstester......................... 22 4.2 Resultat.................................... 24 4.2.1 Användarprofil och intervju..................... 24 4.2.2 Utvärdering.............................. 24 4.2.3 Kommentarer från nybörjartestpersoner.............. 30 4.2.4 Intervjuer med erfarna användare.................. 31 4.2.5 Slutsats av utvärdering....................... 31 5 Framtagande av prototyp 33 5.1 Genomförande................................ 33 5.1.1 Avgränsning............................. 33 5.1.2 Identifikation av funktioner..................... 33 5.1.3 Skissarbete.............................. 33 5.1.4 Implementering och utvärdering av prototyp........... 34 5.2 Beskrivning av prototyp och skisser..................... 34 5.2.1 Fastighetsmodulen.......................... 34 5.2.2 Entreprenadmodulen......................... 35 5.2.3 Objektmodulen............................ 41 5.3 Resultat från utvärdering av prototyp................... 43 6 Slutsatser 45 7 Tillkännagivanden 47 Referenser 49 A Användbarhetsproblemen i DeDU 51

Lista över figurer 1.1 Vy över fastighetsmodulen.......................... 3 4.1 Vy över objektsmodulen........................... 25 4.2 Vy över kalendermodulen........................... 26 4.3 Vy över entreprenadmodulen......................... 28 4.4 Vy över rapportmodulen........................... 29 4.5 Vy över fastighetsmodulen.......................... 30 5.1 Vy över prototypens fastighetsmodul. En fastighet är vald........ 36 5.2 Vy över prototypens fastighetsmodul. Ett hus är valt........... 37 5.3 Vy över prototypens entreprenadmodul. Ett hus är valt.......... 38 5.4 Vy över prototypens entreprenadmodul. Första steget för att skapa ny entreprenad................................... 39 5.5 Vy över prototypens entreprenadmodul. En entreprenad är vald..... 40 5.6 Skiss av objektmodulen. Ett hus är valt................... 41 5.7 Skiss av objektmodulen. Ett objekt är valt................. 42 v

vi LISTA ÖVER FIGURER

Lista över tabeller 3.1 Jämförelse av utvärderingsmetoder...................... 17 vii

viii LISTA ÖVER TABELLER

Kapitel 1 Introduktion 1.1 Användbarhet Användarvänlighet är ett ord som används frekvent i dagligt tal när man samtalar om interaktiva artefakter såsom datorprogram eller färddatorer i bilar. Användarvänlighet är dock inte ett väldefinierat begrepp. Det man brukar mena när man säger att någonting ska vara användarvänligt är i själva verket att det ska vara användbart. Det finns ganska många definitioner för användbarhet, bland annat följande ISO-standard: Den grad i vilken specifika användare kan använda en produkt för att uppnå ett specifikt mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt i ett givet sammanhang. I praktiken innebär detta att en produkt ska vara lätt att lära sig att använda för de specifika användarna. Det ska dessutom vara lätt att komma ihåg hur man använder produkten när man väl har lärt sig den. Dessa två kriterier smälter samman till att produkten ska vara lätt att använda. Vidare ska produkten vara säker i den mening att användarna skyddas från oönskade fel som kan tänkas uppkomma och resultera i exempelvis förlust av data. Slutligen ska produkten också vara effektiv och underlätta så mycket som möjligt för användarna i deras arbetsuppgifter. Denna definition av användbarhet är viktig då just användbarhet är centralt för det utförda arbetet. 1.2 WSP och DeDU Detta examensarbete har utförts åt WSP Systems DeDU i Umeå. WSP är ett globalt konsultföretag som verkar inom områdena samhällsbyggnad, hus, industri och miljö. DeDU är WSP Systems egenutvecklade programvara och den första versionen kom redan på 1980-talet. DeDU beskrivs på företagets hemsida som marknadens mest användarvänliga programvara för bland annat planering av fastighetsskötsel och underhåll, hantering av felanmälningar samt bevakning och uppföljning av entreprenader [1]. Till skaran av användare hör kommuner och landsting, fastighetsbolag, entreprenörer och industri- och energibolag. DeDU är uppbyggt av 14 moduler, även kallade fönster, där varje modul har ett eget funktionsområde. Dessa moduler är: Fastighet I denna modul registreras och administreras de fastigheter och hus ett företag äger. En fastighet kan till exempel ses som ett kvarter och innehåller således ett antal hus. Varje hus kan ha ett antal rum och ett antal hyresgäster. 1

2 Kapitel 1. Introduktion Entreprenader I entreprenadmodulen kan entreprenader för hus och fastigheter registreras. Entreprenadernas garantitid kan även bevakas. Objekt I denna modul registreras de objekt som förebyggande underhåll (FU), besiktningar och planenligt underhåll (PU) ska utföras på. Objekten ligger i ett hus eller fastighet och kan till exempel bestå av ventilationsaggregat, yttre underhåll eller lekparker. Kalender Kalendern används till att planera när det arbete som hör till objekten ska utföras. Kvittera I denna modul kvitteras det jobb som utförts, till exempel ifall en felanmälan åtgärdats. Rapporter Rapportmodulen används för att ta fram detaljerad information och statistik om olika typer av ärenden. Till exempel kan de mest frekvent förekommande feltyperna för en fastighet tas fram. Ärenden I ärendemodulen registreras ärenden av engångskaraktär, till exempel felanmälningar och garantianmärkningar. Bolag Här registreras bolag och personer som hänvisas till i andra moduler. Nycklar I denna modul registreras och administreras de nycklar bolaget har till utlåning. Nyckelutlåning Denna modul används till att registrera vilka nycklar som lånas ut av bolaget. Beställning Denna modul används till att göra beställningar. Ekonomistyrning Ekonomistyrningsmodulen används till exempel för att registrera projekt, konton och kostnadsställen. Prislista I denna modul kan priser för olika reservdelar och arbeten registreras. Dokumentation Denna modul fungerar som ett dokumentarkiv där alla former av dokument kan lagras. I de flesta moduler läggs data upp i en trädstruktur likt den i utforskaren i Windows. Figur 1.1 ger ett exempel på hur fastighetsmodulen ser ut. 1: Längst upp i figuren finns den sedvanliga menyraden och en rad med knappar för snabbåtkomst till de olika modulerna. 2: Till vänster i figuren återfinns trädstrukturen. 3: Till höger om trädet finns ett område där information om fastigheter och hus presenteras. 4: Nere i det högra hörnet finns en kolumn med knappar som används för att manipulera och lägga till information i modulen. De flesta av modulerna i DeDU följer denna layout. 1.3 Disposition Rapporten börjar med en beskrivning av examensarbetets uppgift och mål samt de metoder som använts. Därefter följer en litteraturstudie vars syfte var att utse de utvärderingsmetoder som skulle användas i arbetet. Sedan beskrivs det praktiska arbetets utförande och de resultat arbetet lett till.

1.3. Disposition 3 Figur 1.1: Vy över fastighetsmodulen.

4 Kapitel 1. Introduktion

Kapitel 2 Uppgift, metoder och mål I detta kapitel redogörs för uppgiften för projektet, de metoder som använts och de mål som skulle uppfyllas. 2.1 Uppgift Den praktiska uppgiften för examensarbetet bestod av två delar. Den första delen gick ut på att ur ett användbarhetsperspektiv analysera och utvärdera det grafiska användargränssnittet hos DeDU med dess ingående moduler. Användbarhetsperspektivet innebär att fokus skulle ligga på användarvänlighet och överskådlighet. Menyer, knappar, ikoner, dialogrutor och andra komponenter skulle analyseras ur ovan nämnda användbarhetsperspektiv för att identifiera potentiella användbarhetsproblem. Den andra delen gick ut på att utreda hur DeDU:s gränssnitt skulle kunna förbättras för att öka användbarheten. Dessa förslag på förbättringar skulle visualiseras i form av skisser och en interaktiv prototyp. Skisserna och prototypen skulle även de utvärderas ur användbarhetssynpunkt för att bekräfta att förslagen skulle kunna leda till ökad användbarhet. 2.2 Metoder De metoder som använts för att utvärdera det grafiska gränssnittet är Heuristic Walkthrough och användbarhetstester. Konceptet för den interaktiva prototypen togs fram med hjälp av skisser. Själva prototypen implementerades i Visual Studio 2005 med C# som programspråk. 2.3 Mål Målet med projektet var att belysa problematiken med att företagets programvara eventuellt har låg användbarhet. Vidare skulle en prototyp tas fram med en högre grad av användbarhet jämfört med samma funktioner i den existerande programvaran. Prototypen skulle gå att implementera ur företagets synpunkt och måste således implementeras i samma miljö som den existerande programvaran. Förhoppningsvis ska företaget kunna använda ideér från prototypen till att förbättra sin programvara. 5

6 Kapitel 2. Uppgift, metoder och mål

Kapitel 3 Granskning av användbarhetsutvärderingsmetoder För att utröna vilka utvärderingsmetoder som finns tillgängliga samt är mest lämpade för utvärderingen av DeDU:s användargränssnitt har en litteraturstudie utförts. De metoder som studerats har blivit kritiskt granskade med utgångspunkt från de resurser som fanns att tillgå för projektet. Tre huvudkategorier av användbarhetsutvärderingsmetoder har identifierats baserat på de indelningar Nielsen [11] och Preece et al. [4] har gjort: Automatiska metoder Empiriska metoder Prediktiva metoder Nedan följer en generell beskrivning av varje kategori. Ett urval av metoderna inom varje kategori beskrivs mer ingående med avseende på hur de utförs och när de skall utföras. Fördelar och nackdelar med avseende på varje metod kommer även att ges. Till sist kommer en slutsats att dras där den eller de lämpligaste metoderna utses till projektets utvärderingsfaser. 3.1 Automatiska metoder De automatiska metoder som finns tillgängliga för utvärdering av grafiska användargränssnitt fungerar på en rad olika sätt och kan vara mer eller mindre automatiska till sin natur [3]. Man kan urskilja tre nivåer av automatisering: Automatisk inspelning av händelser Dessa metoder lagrar automatiskt tangentbordsoch musaktiviteter tillsammans med andra handlingar en användare utför i ett gränssnitt. Vanligtvis sparas datat till en loggfil som en användbarhetsexpert sedan kan analysera manuellt. Finkornigheten på den lagrade datan varierar från metod till metod. Väldigt detaljerad data medför väldigt stora loggfiler. Metoder för automatisk inspelning är särskilt lämpade att användas under användbarhetstester där handlingar loggas tillsammans med tidpunkten för dessa handlingar [3]. 7

8 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder Ett antal mjukvaror för automatisk loggning av användaraktiviteter har utvecklats under årens lopp. Al-Qaimari och McRostie [3] tog 1999 fram KALDI (keyboard/mouse action logger), en mjukvara som via Java loggar händelser och spelar in skärmaktiviteter. En annan mjukvara som stöder automatisk inspelning är ID- CAT (integrated data capture and analysis tool) [3]. IDCAT spelar inte bara in händelser såsom musklick utan filtrerar och klassificerar också dessa till meningsfulla aktiviteter, till exempel att användaren sparat en fil. Användaraktiviteter kan även simuleras som i Kasik och George s metod [3]. Där skapar designern av gränssnittet ett expertspår som representerar en expert som använder gränssnittet. Därefter används en genetisk algoritm tillsammans med expertspåret för att simulera en användare som lär sig funktionerna i gränssnittet genom utforskning. Den simulerade användarens aktiviteter loggas sedan för vidare analys [3]. Automatisk analys Dessa metoder identifierar användbarhetsproblem automatiskt som namnet antyder. En del metoder tar en loggfil från ett användbarhetstest som input till en programvara. Denna beräknar sedan användarens prestation i form av kvantitativa mått [3]. Dessa mått kan innefatta tid för avklarad uppgift, effektivitet, produktivitet och antalet fysiska operatorer för att klara en uppgift. All mjukvara för automatisk analys beräknar dock inte kvantitativa mått på användarnas prestation. Istället kan en uppgiftsbaserad ansats utnyttjas där användarens handlingar jämförs med fördefinierade optimala handlingar [15]. Mönster av ineffektivitet och felaktiga handlingar kan sedan utläsas [3]. Ifall en loggfil från användbarhetstester inte finns att tillgå finns det mjukvara som istället tar en specifikation av ett gränssnitt som input. Mjukvaran beräknar sedan till exempel hur effektivt skärmytan är utnyttjad, komplexiteten hos dialogrutor eller att knappar och menyer är konsekvent placerade [3]. Automatisk kritik Den mest sofistikerade nivån av automatisering identifierar inte bara användbarhetsproblem utan ger också konstruktiv kritik till hur problemen kan lösas [3]. Gemensamt för mjukvaror som representerar denna metod är att de involverar en kunskapsbas innehållande design- och användbarhetsriktlinjer. I de fall komponenter i gränssnittet som bryter mot riktlinjerna uppdagas kan sedan förslag på förbättringar ges. Exempel på mjukvaror är KRI/AG (knowledge-based review of user interface) utvecklad av Löwgren och Nordqvist 1992, eller CHIMES (computer-human interaction models) framtagen av Jiang et al. 1993 som används av NASA [3]. Nedan redogörs för fördelar respektive nackdelar med att använda sig av automatiska metoder. Fördelar Den största fördelen med att använda sig av de automatiska metoderna är att de kan reducera tiden för att utföra en utvärdering [3]. Istället för att logga ett användbarhetstest manuellt kan en automatisk ansats användas för att avsevärt minska arbetsbördan. Genom att använda sig av metoder för automatisk analys och kritik reduceras behovet av användbarhetsexpertis vilket också är en viktig fördel [3]. Som en följd av tidsbesparingen kan också den andel av gränsnittet som utvärderas ökas [3]. Nackdelar En stor nackdel med att använda sig av automatiska metoder för utvärdering är att resultaten inte är kvalitativa. De kan alltså inte säga någonting om vad

3.2. Empiriska metoder 9 riktiga användare föredrar eller missförstår [3]. En annan nackdel är att även fast designers får hjälp med att skapa gränssnitt som följer designriktlinjer är det inte säkert att gränssnitten blir användbara [3]. En nackdel som påverkar den generella applicerbarheten hos de automatiska metoderna är att gränssnitten som skall utvärderas oftast måste vara implementerade i en speciell miljö. Detta gäller ifall ovan nämnda existerande mjukvaror skall användas [3]. Sedan kan graden av automatisering ifrågasättas hos en del metoder. Ibland krävs det en stor arbetsinsats från utvärderarens sida för att lära sig en metod eller för att använda metoden korrekt [3]. 3.1.1 Diskussion om automatiska metoder Det verkar väldigt praktiskt att låta en mjukvara observera och logga till exempel ett användartest. Testledaren kan då inrikta sig på att observera försökspersonerna på en högre abstraktionsnivå och låta mjukvaran spela in alla smådetaljer. Men besparar verkligen en sådan ansats testteamet en massa arbete? Loggfilen som mjukvaran skapar måste ju analyseras efter testen. Om denna fil är alltför detaljerad kanske förtjänsten med att använda mjukvaran går förlorad i analystid. Förvisso kan då kanske fler användbarhetsproblem hittas men problemet består av att hitta gränsen för finkornighet. Om loggfilerna är väldigt stora kan mjukvara för automatisk analys och kritik användas men då har användbarhetsexpertens roll i det hela helt suddats ut. Kan mjukvara verkligen ersätta en mänsklig motsvarighet som dessutom kanske besitter en massa tyst kunskap om hur människor tänker och handlar? Lägg till automatisk simulering av användaraktiviteter och all mänsklig kontakt med den utvärderade programvaran är bortkopplad. Resultatens subjektivitet och kvalitet borde då kunna ifrågasättas. 3.2 Empiriska metoder De empiriska metoderna innefattar att riktiga användare studeras när de arbetar med ett gränssnitt eller programvara. Användarna kan till exempel studeras i deras naturliga miljö, när de utför naturliga arbetsuppgifter, som en typ av fält- eller etnografisk studie [4]. Den person som leder utvärderingen kan antingen delta i användarens naturliga arbete eller studera användarna som en utomstående. En etnografisk studie där testledaren deltar i användarnas arbete som en naturlig medlem i gruppen borde leda till minst påverkan eller bias gentemot användarna. Samtidigt tar en riktig etnografiskstudie väldigt lång tid att utföra. En annan negativ aspekt är att det är svårt på förhand säga vilken data som kommer att samlas in under studien [4]. Detta leder till att metoden inte känns särskilt resurseffektiv för utvärdering av grafiska användargränssnitt och kommer således inte att diskuteras djupare. Den vanligaste empiriska metoden för utvärdering av gränssnitt är användbarhetstester som beskrivs utförligare nedan. 3.2.1 Användbarhetstester Användbarhetstester av grafiska användargränssnitt innebär att en testledare eller en grupp av observatörer studerar hur slutanvändare eller representativa substitut för sådana utför noggrant förberedda uppgifter i en programvara [4][14]. Användbarhetstester kan utföras i alla skeenden i ett projekts livscykel, dock i varierande former och omfattning [14]. Ibland utförs testerna i avancerade laboratorier men detta är inget krav.

10 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder Enkla testmiljöer såsom ett avskärmat rum utrustat med en dator och möjligtvis en videokamera duger ifall resurserna är knappa [14]. Målet med användartester är att upptäcka användbarhetsproblem i den testade programvaran. Detta går till så att olika kriterier mäts under testets gång. Dessa kriterier kan innefatta tiden det tar att utföra en uppgift, hur många fel användaren gör vid försök att lösa en uppgift eller ifall användaren överhuvudtaget klarar av att lösa uppgiften utan hjälp [4]. Det är viktigt att upplysa testpersonen om att det inte är själva personens förmåga som mäts under testet utan det grafiska gränssnittets förmåga att underlätta interaktionen mellan människa och programvara [4]. All interaktion mellan användaren och gränssnittet spelas in för senare analys [4]. För att få ut så mycket information som möjligt från användaren och för att få en bild över hur denne tänker vid problemlösningen kan tänka högt tekniken användas [6]. Denna teknik går ut på att användaren säger högt allt de tänker på och försöker göra med gränssnittet. Efter avslutat test är det vanligt att användaren uppmanas att fylla i ett frågeformulär för att samla in ytterligare data [14]. När det kommer till hur många personer som skall delta i ett test så är det oftast ju fler desto bättre. För små urval leder till icke statistiskt säkerställda resultat ifall användbarhetstestet ingår i ett vetenskapligt experiment [14]. Försök indikerar dock att 4-5 testpersoner hittar cirka 80 procent av användbarhetsproblemen i en produkt [14]. När önskat antal användare testats analyseras all data och slutsatser dras. Förhoppningsvis leder dessa slutsatser till användbara designimplikationer. Enligt Rubin [14] bör en detaljerad testplan tas fram innan testerna börjar. Testplanen skall ligga som en formell grund för hur, när, var och varför testerna utförs. Följande punkter kan anses nödvändiga i en testplan: Syfte Det övergripande syftet för att användbarhetstester skall utföras. Detta syfte skall vara på en hög abstraktionsnivå, ett exempel kan vara att det kommit in klagomål på en ny modul i programvaran. Problempåståenden Ett problempåstående skall specifiera vad som skall testas och de frågor som ska besvaras. Påståendet skall vara så detaljerat som möjligt eftersom det helt enkelt beskriver det man hoppas få ut av användbarhetstestet. Vanligtvis består en testplan av flera problempåståenden. Ett exempel på problempåstående kan vara: hittar användarna till accessoaravdelningen på företagets websida? Användarprofil Under denna sektion skall profilen hos slutanvändarna av produkten beskrivas. Detta för att sedan kunna använda testpersoner med liknande erfarenheter för själva användbarhetstestet. Vikten av att använda testpersoner som representerar slutanvändare är stor, resultatet av testen kan annars ifrågasättas. Att ta fram en användarprofil bör vara ett av de första stegen i en produktutvecklingsprocess men ibland kan det vara svårt för testledaren att få tag i en väldokumenterad sådan hos företaget i fråga. I dessa fall kan en rundringning till kunderna vara nödvändig. Exempel på information att ta med i en användarprofil kan vara ålder, kön, utbildning och datorvana. Testdesign Testdesignen eller metoden skall behandla hur hela testet skall utföras. Denna beskrivning skall innefatta allt från hur testpersonerna skall välkomnas och förberedas inför testet till hur användarna skall utfrågas och belönas i slutet av testet. Denna punkt skall vara tillräckligt detaljerad så att någon utomstående skall kunna förvänta sig vilket resultat testet kommer att ge. En annan motivering till hög detaljnivå är att testet skall gå att återupprepa.

3.2. Empiriska metoder 11 Uppgifter Här skall de uppgifter testpersonerna uppmanas utföra i testet redogöras för. Uppgifterna skall återspegla de uppgifter riktiga användare förväntas använda programvaran till. En beskrivning av när eller hur en uppgift är löst är viktigt att ha fördefinierat innan testet påbörjas för att underlätta bedömningen av en testpersons resultat. En övre tidsgräns för hur länge en testperson får hålla på med en uppgift är också viktig för att undvika alltför utdragna tester. Testmiljö och utrustning Den miljö och den utrustning som krävs för att utföra testet skall specificeras i denna punkt. Är produkten tänkt att användas i en speciell miljö, till exempel i en skogsmaskin i arbete, kan det vara en idé att simulera en sådan miljö för ett rättvisande test. Testledarens roll Här skall testledarens roll och beteende gentemot testpersonerna redogöras för. Skall testledaren hjälpa testpersonerna med uppgifterna? Skall testledaren enbart observera testpersonerna? Beroende på hur formellt testet är har testledaren olika roller. Kriterier att mäta Här redogörs tydligt för vilka kriterier som skall mätas under testets gång. Nedan följer ett antal positiva respektive negativa aspekter på användbarhetstestning. Fördelar Användbarhetstestnings absolut mest positiva attribut är det faktum att testpersoner som representerar riktiga användare studeras. Detta leder till att problem som troligtvis skulle påverka slutanvändarna i sitt dagliga arbete uppdagas [5]. Vidare har jämförelser med andra utvärderingsmetoder, till exempel heuristisk utvärdering, visat att användbarhetstestning hittar fler allvarliga och återkommande problem och färre problem med låg-prioritet [13]. En annan fördel med att ha utfört användbarhetstester är att det är lättare att övertyga programvaruutvecklarna att det verkligen existerar designproblem i gränssnittet [5]. Nackdelar Att utföra ett användbarhetstest kan vara väldigt kostsamt i fråga om pengar och tid [11, 13]. Således är kostnaden den största nackdelen med användbarhetstester. Ett användbarhetstest kräver också ett kunnigt testteam eller en kunnig testledare, helst skall den som utför testet vara en användbarhetsexpert [13]. Vidare har försök visat att användbarhetstestning ibland missar allvarliga problem som andra metoder hittar [13, 11]. 3.2.2 Diskussion om empiriska metoder De empiriska metoderna torde vara oslagbara när det gäller att leverera trovärdiga resultat och kommentarer rörande en mjukvara. Det är trots allt riktiga användare som har riktiga problem som studeras. Att försökspersonerna dessutom kan komma med konstruktiva förslag kan bespara den som utvecklar en programvara mycket arbete. Har man bara tillräckligt med tid på sig för att planera och utföra användbarhetstester är de ett självklart val. Dock måste man tänka på att det kan vara problematiskt att hitta lämpliga förökspersoner. Ifall yrkesverksamma personer skall användas som testdeltagare måste det antagligen finnas tillräckliga ekonomiska tillgångar i projektet för att ersätta dessa för förlorad arbetstid till exempel. Att enbart förlita sig på användbarhetstestning kan visa sig vara ett misstag ifall så många användbarhetsproblem som möjligt skall identifieras. Eftersom metoden ibland missar problem som andra

12 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder metoder kan identifiera är det nog säkrast att kombinera användbarhetstester med andra metoder. Detta är dessutom en av de få frågor som olika experter inom användbarhet verkligen kan komma överens om. 3.3 Prediktiva metoder Till denna kategori räknas de metoder som experter eller programvaruutvecklare använder sig av för att förutse användbarhetsproblem i en produkt. Teoretiska modeller för att till exempel förutspå tiden det tar att utföra olika kommandon i en mjukvara räknas också till de prediktiva metoderna. Gemensamt för dessa metoder är att de inte involverar riktiga användare i någon större skala [4]. Nedan presenteras två av de vanligast förekommande metoderna för att förutse användbarhetsproblem samt en utmanare. 3.3.1 Heuristisk utvärdering Heuristisk utvärdering är en utvärderingsmetod framtagen av Jakob Nielsen med kollegor [9]. Metoden går ut på att ett antal personer individuellt fritt utforskar ett användargränssnitt för att bedöma hur väl gränssnittet överensstämmer med förbestämda användbarhetsprinciper [9, 16]. Ifall det uppdagas att en komponent i gränssnittet bryter mot principerna antecknas var komponenten finns och vilken eller vilka principer den bryter mot [12]. Gränssnittet skall gås igenom minst två gånger. I den första genomgången ligger fokus på att få en känsla för interaktionsflödet i gränssnittet samt dess omfång. När en överblick över hur komponenterna tillsammans utgör gränssnittet erhållits, ligger fokus i den andra genomgången på att hitta användbarhetsproblem för de specifika komponenterna [9]. Det som gett metoden dess namn är just användbarhetsprinciperna som kallas för heuristiker, tumregler, när de används i utvärderingssyfte [4]. Försök har visat att enbart en person som utvärderar inte gör särskilt bra ifrån sig med denna metod. En ensam utvärderare hittar oftast inte mer än 20 till 50 procent av alla användbarhetsproblem i ett gränssnitt [12, 8, 10]. Ovan nämnda försök har även visat att olika utvärderare hittar olika användbarhetsproblem. Detta leder till att ett flertal utvärderingar måste utföras av olika personer för att öka metodens effektivitet. Alla unika användbarhetsproblem sammanställs därefter. Man har kommit fram till att fem utvärderare hittar ungefär 75 procent av alla användbarhetsproblem i ett gränssnitt [8]. Att använda sig av fler än fem utvärderare är oftast inte nödvändigt då detta inte ger någon nämnvärd informationsökning [9]. Förutom antalet personer som utvärderar har även expertisen hos varje person inverkan på utvärderingsresultatet. Specialister inom användbarhet har visat sig mer dugliga att utföra denna metod än personer utan specialistkompetens [8]. Vidare gör så kallade dubbla experter allra bäst ifrån sig, dessa personer är inte bara experter inom användbarhet utan även inom den domän som programvaran används [8]. En annan faktor som påverkar resultatet är de heuristiker som används. Olika typer av programvaror eller elektroniska apparater kräver olika heuristiker anpassade efter typ av programvara eller apparat. Nedan redogörs för Jakob Nielsens tio heuristiker erhållna från en empirisk studie av 249 användbarhetsproblem [7]: Synlighet av systemets status Systemet skall alltid ge återkoppling till användaren vad som pågår, återkopplingen skall ske inom rimlig tid.