C-UPPSATS. Användbarhet i beslutsstödsystemet hos Räddningstjänsten i Piteå

Transkript

1 C-UPPSATS 2009:249 Användbarhet i beslutsstödsystemet hos Räddningstjänsten i Piteå Tomas Berglund Luleå tekniska universitet C-uppsats Psykologi Institutionen för Arbetsvetenskap Avdelningen för Teknisk Psykologi 2009:249 - ISSN: ISRN: LTU-CUPP--09/249--SE

2 Sammanfattning Det är viktigt att tekniska hjälpmedel har hög grad av användbarhet. Speciellt viktigt är det att teknik som används av Räddningstjänsten fungerar bra eftersom det ökar möjligheterna för Räddningstjänsten att klara sitt uppdrag att rädda liv och egendom. När det handlar om användbarhet i system är det viktigt att systemet är lätt att lära och enkelt att använda, vilket bidrar till ökad användningsfrekvens och större tilltro till det. Detta examensarbete innefattar av empiriska undersökningar som syftar till att beskriva de användbarhetsproblem som existerar i beslutsstödsystemet Paratus Mobile System som används vid Räddningstjänsten i Piteå. För att få veta användarnas åsikter om användbarheten och den utbildning de fått för att hantera systemet intervjuades sex användare. Författaren, i rollen som expert, genomförde även en undersökning av systemet med målet att hitta användbarhetsproblem. Denna del av arbetet var viktig eftersom användare och experter delvis hittar olika användbarhetsproblem. Att kombinera dessa två metoder bidrog till att fler användbarhetsproblem hittades jämfört med om endast intervjuer hade genomförts. Resultaten visade att speciellt två användbarhetsproblem hade stor negativ inverkan på användarna. Den ena handlade om dålig och långsam respons vid användning, vilket skapade osäkerhet, och den andra om att kartnavigeringen visade fel färdväg, vilket bidrog till låg tilltro till navigeringsfunktionen. Nyckelord: användbarhet, kognitiv promenad, heuristisk utvärdering, beslutsstödsystem

3 Abstract It is important that technology in use has a high level of usability and especially important is that the systems used by Fire departments have a high level of usability because it increases the chances for Fire departments to fulfil their mission to save lives and property. It is important that the system is easy to learn and easy to use because it will increase the frequency of usage and make the users confident with the system. This thesis consists of an empirical study aiming at describing the existing usability problems in a system used by the Fire department in Piteå called Paratus Mobile System. To find out the users opinion about the usability in the system, and the amount of training they received to operate it, six of the users were interviewed. The author, in the role of an expert, also carried out a study of the system with the aim to find usability problems. This part of the thesis was important because users and experts tend to find various usability problems. Combining these two methods contributed to a larger number of usability problems could be found compared to if only interviews would have been carried out. The results showed that especially two usability problems had a great negative impact on the users. First, poor response created uncertainty among the users and, second, the navigation that some times displayed wrong routs which created low confidence with the navigation system. Key words: usability, cognitive walkthrough, heuristic evaluation

4 Innehållsförteckning INLEDNING... 1 VARFÖR OMRÅDET ÄR VIKTIGT ATT STUDERA... 1 Situationen vid Räddningstjänsten i Piteå... 1 TIDIGARE FORSKNING... 2 SYFTE OCH FRÅGESTÄLLNINGAR... 5 TEORETISK REFERENSRAM... 6 ANVÄNDBARHET... 6 Anpassning... 6 Användarvänlighet... 6 Acceptans... 6 Kompetens... 7 INLÄRNINGSPROCESSER OCH TEORIER OM MINNETS FUNKTIONALITET... 7 GRÄNSSNITT... 7 Gestaltlagarna... 8 TIO OMRÅDEN ATT GRANSKA NÄR ANVÄNDBARHET UNDERSÖKS... 8 Enkla och naturliga dialogrutor... 8 Information som användaren förstår med enkelhet... 9 Minimal belastning på arbetsminnet... 9 Konsekvens... 9 Feedback... 9 Avstängnings- och ångerfunktioner Genvägar Förebygga fel När fel uppstår och hantering av dessa Hjälpresurser METOD FÖRSÖKSPERSONER MATERIAL PMS PROCEDUR AVGRÄNSNINGAR DATABEHANDLING RESULTAT OCH ANALYS FÖRFATTARENS UTVÄRDERING ANVÄNDARNAS ÅSIKTER DISKUSSION EXISTERANDE ANVÄNDBARHETSPROBLEM I PMS UTBILDNING SAAB PERFORMITS ARBETE FRAMTIDEN FÖR PMS RELIABILITET OCH VALIDITET ETISKA ÖVERVÄGANDEN FÖRSLAG PÅ FORTSATTA STUDIER REFERENSER... 27

5 1 Inledning De senaste årtiondena har Räddningstjänstens användning av olika typer av IT-stöd ökat stadigt. Ju mer de olika teknikerna utvecklats, desto kortare blir deras livscykel (Ljus, 1999). Det har tidigare påvisats att Räddningstjänsten rent generellt varit långsamma att ta till sig ny teknik och när de har börjat använda tekniska system har dessa redan funnits ute på marknaden under lång tid och är med andra ord omoderna (Ljus, 1999). Det har tidigare riktats kritik mot Räddningstjänstens personal angående bristande kunskap om IT (Hessman & Lissborg, 1999). Denna rapport är dock tio år gammal och det är oklart hur utbildningssituationen generellt sett ser ut för räddningspersonal i dagsläget. Det är viktigt att teknik som används har en hög grad av användbarhet inte bara hos Räddningstjänsten utan vid all användning av teknik. Det är dock särskilt viktigt att allt fungerar perfekt när det är Räddningstjänsten som är användaren för att de ska kunna utföra sitt uppdrag på ett effektivt sätt. Varför området är viktigt att studera Att användbarhet är viktigt beror bland annat på att det har visat sig att dålig användbarhet ofta leder till irritation och frustration hos användarna (Jordan, 1998) vilket, i sin tur, kan leda till att säkerheten blir lidande om tekniken används på fel sätt eller inte alls. Användaren kan exempelvis missa viktig information, vilket leder till att felaktiga beslut tas. Ett felaktigt beslut hos Räddningstjänsten kan leda till att räddningsinsatser tar längre tid än nödvändigt, vilket i sin tur kan leda till förlorade liv och förlorad egendom (Jordan, 1998). Olyckor kan inträffa om systemet kräver för mycket uppmärksamhet av användaren när denne egentligen måste ha fokus på någon annan del i processen. Enligt Jordan (1998) finns det flera välkända olyckor som kan härledas till dålig användbarhet i tekniska system. Olyckor som nämns är bland annat kärnkraftsolyckan i Harrisburg 1979 som delvis berodde på att operatören var tvungen att läsa av ett instrument som satt placerat bakom kontrollpanelen. Det var med andra ord svårt för operatören att på ett enkelt sätt utföra sina arbetsuppgifter. Över tid har synen på utvecklingen och användningen av teknik sakta förändrats. Tidigare handlade det ofta om att tekniken inte tillhandahöll tillräckligt många funktioner. Hur funktionerna var utformade var nästintill ointressant. Kravet att system har rätt funktionalitet finns fortfarande kvar, men det har kommit till fler krav bland annat tydligare krav på att systemen ska ha hög grad av användbarhet. Det spelar inte ingen roll om ett system har alla tänkbara funktioner för att lösa en specifik uppgift om systemet inte är användarvänligt. Användbarhet är ingenting som är konstant och som enbart fokuserar på några enstaka, konstanta faktorer. Istället är det kraven för en specifik situation i kombination med dess användare som sätter nivån för vad som krävs för att god användbarhet ska vara uppnådd i det system som används (Allwood, 1998). Situationen vid Räddningstjänsten i Piteå Räddningstjänsten i Piteå använder sedan hösten 2008 ett datorbaserat beslutsstödssystem som heter Paratus Mobile System (PMS) och är utvecklat av SAAB PerformIT. PMS uppgift hos Räddningstjänsten är bland annat att agera som fordonsnavigator och som terminal för att hitta information i RIB, vilket är en informationsdatabas för myndigheter och organisationer som jobbar med skydd mot olyckor (Räddningsverket, 2009). Räddningstjänsten i Piteå har använt detta system i ungefär 6 månader. Per Isaksson, ansvarig för PMS på Räddningstjänsten i Piteå, säger att PMS fortfarande befinner sig i teststadiet och att det även finns planer att implementera fler funktioner i systemet, som exempelvis bättre kontakt med interna system och positionering av andra räddningsfordon som exempelvis andra brandbilar och ambulanser. Det finns även planer att installera en kamera för dokumentation av olycksplatser för

6 2 vidarebefordring till ledningscentral. Med andra ord är ambitionen att göra detta system mer omfattande. Tidigare forskning Inom forskningen om användbarhet finns ett flertal olika undersökningsmetoder och en av dessa kallas heuristisk utvärdering, på engelska Heuristic evaluation (Nielsen, 1993). Denna metod används för att empiriskt undersöka nivån av användbarhet i ett system. Metoden går ut på att en grupp personer undersöker gränssnittet i systemet. Denna grupp består ofta av experter inom området som ska undersökas. Vid granskningen undersöks olika områden som finns på en färdig checklista. Denna lista med områden som undersöks skapas ofta av uppdragsgivaren och baseras på tidigare forskningsresultat och undersökningar av likvärdiga gränssnitt. Vidare har Nielsen & Molichs (1990) forskning visat att enbart experter som utvärderare inte är bra eftersom alla typer av användbarhetsproblem inte går att känna till i förväg. Många problem blir kända först när de riktiga användarna ställer sina egna, ibland mycket specifika, krav på systemen. På grund av dessa faktorer är det viktigt att även en grupp användare av ett system har möjlighet att testa, utvärdera och påverka systemets utformning under utvecklingsarbetet (Nielsen, 1993). Forskning på området har visat att när experter ska skapa listor med vanligt förekommande problem som testarna ska hitta, hittar experter bara en viss typ av problem samtidigt som användare hittar andra typer av problem (Nielsen & Mack 1994). Något som också bör tilläggas är att de problem som användare hittar inte nödvändigtvis endast handlar om de specifika krav de har. Användare hittar även problem som experter missat. När tidigare studier gjorts har användare, precis som experter, upptäckt generella användbarhetsproblem. Slutsatsen som dragits av detta är att det bästa resultatet vid en genomgång av användbarheten i ett system erhålls genom att både involvera experter och användare (Nielsen & Molich, 1990). Vidare har Nielsens (2005a) forskning visat att det inte räcker med en användare för att hitta användbarhetsproblem, men det behövs samtidigt heller inte speciellt många för att hitta de flesta användbarhetsproblemen. Det som dock betonas är att det är bäst om det görs ett brett urval av användare som ska testa systemet då ingen enskild typ av användare är bäst på att hitta alla användbarhetsproblem. I övrigt finns inga speciella riktlinjer som måste följas när en användbarhetsgranskning genomförs. Enligt Nielsen (2005a) letar många som använder metoden främst efter olika typer av standardproblem. Dessa standardproblem har identifierats i tidigare undersökningar av liknande system. Nielsen (2005b) har genom sina studier samlat vanliga användbarhetsproblem till tio större områden. En enskild utvärdering av ett system kan dock även innehålla specifika områden som uppdragsgivaren vill veta mer om. När antalet utvärderare blir fler och fler ökar först antalet hittade brister och problem kraftigt i takt med antalet utvärderare för att sedan vid ca sju utvärderare plana ut. (Figur 1).

7 3 Figur 1. Grafisk representation av förhållandet mellan antalet fel som hittats och antalet utvärderare. (Efter Nielsen, 2005a). Enligt Nielsen (2005a) har flera oberoende forskningsprojekt visat att om en enskild användare gör en utvärdering av ett system upptäcks ungefär 35% av alla användbarhetsproblem i det undersökta systemet. Eftersom olika användare upptäcker olika fel ökar antalet hittade fel och brister med antalet utvärderare. Redan vid ungefär sju utvärderare ökar inte antalet hittade fel och brister i samma takt som tidigare utan kurvan planar ut (Figur 1) och dessa sju upptäcker då tillsammans ca 75% av alla brister. Självklart upptäcks fler problem om fler deltar i undersökningarna, men för att exempelvis nå upp till en nivå där ungefär 90% av fel och brister hittas behövs ungefär dubbelt så många användare som vid en nivå på 75% hittade fel. Att hitta dessa 15% av alla användbarhetsproblem kostar med andra ord en hel del i både tid och pengar. Denna kostnad är en av de faktorer som bidrar till att många system är långt ifrån perfekta ur ett användbarhetsperspektiv. Det är helt enkelt för dyrt och tidskrävande för tillverkaren att genomföra användbarhetsundersökningar i den omfattningen att systemen får en hög nivå av användbarhet. Det finns även forskning om vilka faktorer som generellt sett är viktigast, och först bör vara uppfyllda, för att användarna ska uppleva ett datorsystem som lättanvänt. Rubin (1994) har sammanställt resultaten i fem större faktorer. Den första handlar om vad som prioriteras under utvecklingsarbetet. Det bästa är om systemet utvecklas utifrån de mänskliga begränsningarna och inte tvärtom. Till detta kommer även att människors förmågor inte är statiska. Förmågorna utvecklas med tiden, allt eftersom interaktionen med systemet fortgår. Det optimala är att även systemet som används också utvecklas i samma takt som användarna så att samspelet mellan människa och maskin fortsätter att fungera så bra som möjligt. Att systemet ska kunna utvecklas med användarna går exempelvis att lösa genom att skapa olika typer av genvägar för användarna, det vill säga alternativa och snabbare sätt att lösa uppgifter. Exempel på detta kan handla om tangentbordskombinationer för att aktivera funktioner istället för att enbart klicka runt i menyer. Genvägarna bidrar till att erfarna användare kan använda systemet snabbare samtidigt som nybörjare inte har svårt att använda det i och med att de fortfarande har möjlighet att använda den långa vägen för att uppnå samma mål. Den andra faktorn handlar om att fler och fler vanliga användare blir användare av avancerad teknik i vardagen. Detta innebär att förkunskaperna hos nya användare ökar ju längre tiden går i och med att de använder avancerad teknik i sin vardag. Det bästa för användbarheten är således att systemet kan anpassas efter den enskilde användarens förkunskaper. Det har dock visat sig att utvecklingen har varit dålig på att anpassa sig till detta. Den tredje faktorn handlar om att det

8 4 många gånger är betydligt svårare att utveckla ett system än vad utvecklarna initialt tror. Det kan handla om olika typer av krav som inte finns med när ramarna för systemet sätts upp och om viktiga funktioner som saknas. Det är helt enkelt svårt att i utvecklingsfasen känna till behov som kommer att finnas i slutändan. Den fjärde faktorn handlar om att samspelet mellan olika utvecklingsgrupper som arbetar med olika delar av ett system har dålig kommunikation sinsemellan, vilket kan få till följd att exempelvis manualer inte beskriver funktioner som programmerarna har tillverkat på rätt sätt. Manualen riskerar att förbli oläst eftersom den är svårbegriplig. Den femte och sista faktorn handlar om skillnaden mellan den tekniska utvecklingen, programkoden och den grafiska utformningen. Det är svårt för en programmerare att vara expert på både programmering och utveckling av grafiska gränssnitt. Det bästa för användbarheten är om dessa två faktorer skiljs åt i utvecklingsarbetet. Nielsen & Molich (1990) har försökt fastställa de viktigaste komponenterna i själva gränssnittet mellan datorsystemet och användare som bör vara uppfyllda för att de senare ska uppfatta gränssnittet som användarvänligt. Som grund för sin undersökning valde Nielsen & Molich (1990) att själva hitta fel i systemet som försökspersonerna skulle utvärdera. Forskarna tänkte sig att de fel som de skulle hitta skulle komma att vara samma fel som forskarna själva tidigare hade hittat i den utvärdering som de hade gjort. Försökspersonerna som deltog i experimentet var inte experter på vilka faktorer som påverkar användbarhet. Vid försöket använde forskarna sig av tio större områden som har visat sig vara viktiga för användbarheten. Dessa tio områden var: Enkla och naturliga dialogrutor Information på en nivå som användaren förstår med enkelhet Minimal belastning på användarens arbetsminne Konsekvens Ge feedback Tydligt markerade avstängnings- och ångerfunktioner Genvägar för erfarna användare Förebyggande av fel Hantering av fel som uppstår Manualers och instruktioners utformning Det visade sig att det inte vara en enkel uppgift att reda ut vad som var användbarhetsproblem eftersom det fanns en stor spridning av vilka typer av problem som upptäcktes av de olika försökspersonerna. Många fel som i förväg var kända och tillhörde de områden som var i fokus i undersökningen upptäcktes aldrig av försökspersonerna samtidigt som de hittade fel som forskarna aldrig hade tänkt på. Detta fick till följd att delar av forskarnas forskningsmetod fick omarbetas. Detta visar att det är svårt att få en ordentlig överblick över vad som bör prioriteras när ett datasystem genomgår olika tester för kartläggning av användbarhetsproblem. Som utvecklare och forskningsledare gäller det att inte enbart begränsa sig till sin personliga uppfattning eller tidigare forskning om vad som ska klassas som användbarhetsproblem och inte. Det gäller också att inte tänka enkelspårigt när det handlar om vem som ska testa och utvärdera systemet i fråga. Det viktiga är att det inte enbart är experter eller enbart vanliga användare som testar. Det finns även exempel som visar att användares åsikter inte är de bästa ur ett användbarhetsperspektiv. Nielsen (1993) nämner en grupp telefonister som blev tillfrågade om de ansåg att de headset de använde fungerade bra och om de hade någonting att anmärka på dem. Ingen hade något negativt att säga om headseten. Vikten på en del av headseten sänktes därefter utan att meddela telefonisterna detta och det visade sig att telefonisterna föredrog att använda de headset som hade lägst vikt. Med detta som utgångspunkt menar Nielsen (1993) att det som användare kan

9 5 vara svårt att i alla situationer uttala sig om vad som kan göras bättre för att höja användbarheten. Enligt Terence, Hartson, & Williges (2003) finns många mjukvaror med låg användbarhet trots att fokus på användbarhet har ökat de senaste åren. Orsakerna till detta är att utvecklare använder felaktiga och ineffektiva metoder för att testa och utvärdera tekniska system och dessas gränssnitt. Ordentliga utvärderingar av gränssnitt anses ofta var alldeles för dyra och många gånger är det svårt att genomföra dem under utvecklingsarbetet. Enligt Jacobsen & Bonnie (1998) har det gjorts få studier om hur varje enskild utvärderares utvärdering påverkar den sammantagna bilden av användbarheten i ett system. Nielsen och Molichs (1994) studie är en av de få studier som fokuserat på den enskilde utvärderaren och hur denne påverkar bedömningen av användbarheten. Det finns även en studie genomförd av Jacobsen & Bonnie (1998) inriktad på vilken effekt bedömaren av systemet har för andelen hittade användbarhetsproblem. I denna studie användes en annan typ av utvärderingsmetod för användbarhetsproblem, nämligen en så kallad kognitiv promenad (Cognitive walkthrough). Denna metod innebär att utvärderaren utför olika uppgifter i systemet och samtidigt förklarar sitt handlande för den person som leder undersökningsprocessen. Den stora fördelen med detta sätt att utvärdera användbarhet är att det erhålls relevanta kvalitativa data. Den uttalade informationen går att knyta ihop med utvärderarens handlingar (Hom, 1998; Rubin, 1994) De resultat Jacobsen & Bonnie (1998) kom fram till överensstämmer i stora delar med Nielsen & Molichs (1990) resultat, det vill säga att olika utvärderare delvis hittar samma fel och att varje enskild utvärderare även hittar fel som inte hittas av andra utvärderare. För att hitta 75% av användbarhetsproblem behövdes även i detta experiment cirka 5-6 deltagare. Syfte och frågeställningar Syftet med detta examensarbete är att undersöka vilka existerande problem Räddningstjänsten i Piteå har med sitt IT-baserade beslutstödsystem PMS. Följande frågeställningar avses besvaras: Vilka användbarhetsproblem upplever användarna av PMS att systemet har? Vilka användbarhetsproblem baserat på tidigare forskning hittas i systemet av en expert? Anser användarna att de har tillräckligt med kunskap för att hantera PMS? Vad gör systemtillverkaren för att underlätta användbarheten?

10 6 Teoretisk referensram Det finns flera olika psykologiska processer som är kopplade till användbarhet i tekniska system. Det handlar bland annat om på vilket sätt information presenteras för att användaren ska kunna hantera den utan att tappa eller förvränga någon del av den. En hög nivå av användbarhet innebär exempelvis att systemet på ett bra sätt är anpassat till människans kognitiva förmågor. Användbarhet Enligt Jordan (1998) kan begreppet användbarhet definieras som ett mått på hur enkel en produkt är att använda. Att människor upplever samma system på olika sätt beror bland annat på tidigare erfarenheter, kulturella skillnader och ålder. Användbarhet är dock ett begrepp som inbegriper många olika aspekter. Enligt Allwood (1998) kan användbarhet delas in i fyra olika undergrupper: anpassning, användarvänlighet, acceptans och kompetens. Anpassning Anpassning innebär att systemet är byggt utifrån den uppgift som ska lösas. Vid utveckling av system kan det ibland vara svårt att i förväg veta alla specifika krav som kommer att krävas av systemet. Anpassning till användarna måste göras. Det handlar bland annat om att systemet helst ska kommunicera på användarnas modersmål för att undvika att det uppstår språkliga missförstånd. Systemet bör använda en nivå i språket som användarna behärskar. I övrigt bör även systemet gå att anpassa till användarnas egna behov. Det kan exempelvis handla om hur mycket information som presenteras och hanteras av användaren (Allwood, 1998). Användarvänlighet En aspekt av användarvänlighet är att systemet är åtkomligt. Det är med andra ord negativt om systemet blir otillgängligt på grund av bortfall av elektricitet. Systemet bör inte ha långa responstider eftersom det fördröjer andra processer som är beroende av systemet. De krav som ett system ställer på användaren får inte vara högre än den mentala kapacitet människan besitter (Allwood, 1998). Det finns ett antal riktlinjer som bör följas i utvecklingsarbetet av ett system. Bland annat bör informationsmängden som presenteras för användaren inte överskrida den mängd information som kan hållas samtidigt i användarens arbetsminne, det vill säga ca fem av varandra oberoende enheter (Allwood, 1998). Vad som menas med enheter beror på vilket system och vilken situation det handlar om. Vad som ingår i en enhet varierar beroende på hur information presenteras. En bra presentationsform underlättar för användaren att gruppera informationen. Viktigt att komma ihåg är att varje användare är unik trots att det finns mycket gemensamt mellan olika användare. En teknisk lösning som passar utvecklaren och/eller experter behöver inte passa för de slutliga användarna. Detta gör att det är viktigt att ett system delvis är flexibelt, dvs. att den enskilde användaren kan anpassa det till sina behov och krav. När problem trots allt uppstår bör hjälp av olika typer finnas tillgängligt på ett snabbt och enkelt sätt. Det kan handla om kollegor, manualer eller telefonsupport. Acceptans Användaren av systemet måste ha en positiv inställning till, och vilja att lära sig, ett system, annars är risken stor att denne aldrig börjar använda det eller inte använder systemet fullt ut som det var tänkt när det installerades. Detta anses ofta vara en parentes i forskningen om användbarhet men det har visats att acceptansen hos användarna har stor inverkan på den upplevda användbarheten (Allwood, 1998).

11 7 Kompetens Kompetens handlar om huruvida användarna har rätt utbildning för att hantera systemet, rent generellt är utbildningen sämre än vad som vore önskvärt för att användarna ska kunna använda systemet på ett bra sätt (Allwood, 1998). Inlärningsprocesser och teorier om minnets funktionalitet Det finns två olika typer av mänskliga minnessystem som samverkar när användaren interagerar med ett system. Den kunskap användaren har finns lagrat i långtidsminnet och den begränsade mängd information användaren har i medvetandet är sparat i korttidsminnet. Information som finns sparat i korttidsminnet glöms bort, ibland efter enbart några sekunder (Groome, 1999). Prestationer kan delas in i olika typer. Enligt Löwgren (1993) finns det rutinprestationer och beslutsbaserade prestationer. Rutinprestationer är de prestationer som enbart baseras på minnen, träning och tidigare erfarenheter, det vill säga ju mer användaren tränar desto mer lär användaren sig hur systemet fungerar och kan styra det snabbare. Beslutsbaserade prestationer används när användaren inte har tidigare erfarenheter eller träning på den specifika situationen, då försöker användaren istället tillämpa liknande erfarenheter från tidigare situationer på den nya situationen. I dessa beslutssituationer blir det bäst resultat om den nya situationen liknar andra liknade tidigare upplevda situationer. Exempelvis om användaren ska använda en viss funktion i ett datasystem underlättar det om funktionen liknar tidigare använda likartade funktioner. Båda dessa typer av beslutssituationer påverkas av både korttids- och långtidsminnet. Det handlar om ett samspel där tidigare kunskap transporteras från långtidsminnet till korttidsminnet och sedan används i den aktuella situationen. Ny kunskap som skapas i en situation går andra vägen via korttidsminnet till långtidsminnet, där det lagras för att sedan kunna användas när användaren återkommer till samma situation (Allwood, 1998). Denna process ställer alltså krav på att det är lätt att ta till sig den utbildning som ges om ett system. Det är även viktigt att användaren kan lära sig nya saker vid användningen av systemet. Det måste gå att lära sig lite åt gången så att informationen kan mellanlagras i korttidsminnet innan det sedan lagras i långtidsminnet. Det finns många faktorer som påverkar människors beteende varav en av de viktigaste är verklighetsuppfattningen (Allwood 1998). Verklighetsuppfattningen har sin utgångspunkt i en kombination av egenuppfattning och krav och mål, men även av yttre faktorer som människan inte har eller kan ha full kontroll över. När en människa upplever verkligheten pågår ett ständigt utbyte av tidigare erfarenheter i minnet samtidigt som nya intryck lagras. Gränssnitt I ett människa-maskin-system syftar gränssnittet på den del som kommunicerar mellan användaren och systemet. Det är genom gränssnittet som systemet presenterar information till användaren via exempelvis en dataskärm eller högtalare. Den information som presenteras når sedan användarens medvetande som utifrån tidigare erfarenheter och eventuell annan information tar beslut om vad som måste göras i systemet för att fortsätta processen. Användaren reglerar systemet via knappar och reglage och den inmatade informationen behandlas sedan av systemet som presenterar ny information för användaren. På detta sätt går sedan informationen runt och processen går vidare (Allwood, 1998). Det är således viktigt att alla delar i denna interaktion fungerar så bra som det bara är möjligt eftersom det leder till att det systemet ska utföra då går snabbare. De beslut som ska tas utifrån den information som presenteras av systemet måste vara enkel att tolka för användaren, samtidigt som det ska vara enkelt för användaren att mata in mer information till systemet.

12 8 Detta informationsutbyte underlättas om systemet följer de så kallade gestaltlagarna som är ett resultat av Wertheimers och Köhlers forskning refererade av Groome, (1999). Gestaltlagarna När vi människor ser saker, exempelvis en dataskärm med funktionsknappar, tenderar vi att se mönster och göra grupperingar av informationen. Vanligt är att gruppera och isolera objekt som liknar varandra till färg, form och/eller avstånd till varandra. Vid utformning av en kontrollpanel bör dessa Gestaltlagar följas eftersom det underlättar för användaren att hitta funktioner och att interagera med kontrollpanelen. Det vill säga knappar och reglage som hör ihop bör grupperas och placeras nära i relation till varandra. Figur 2 visar effekten av perceptionen och människans tolkning. Många ser inte tolv helt fristående fyrkanter i denna figur, utan ett mönster av fyrkanter, vilket, i sin tur, leder till slutsatsen att färgerna har något med kopplingen mellan fyrkanterna att göra. De knappar som har samma färg upplevs höra ihop (Groome, 1999). Figur 2. Exempel på gestaltpsykologins lagar. Ser du tolv fristående fyrkanter i olika färger eller ser du ett mönster med knappar i olika färger? (Efter Groome, 1999). Tio områden att granska när användbarhet undersöks Det finns flera olika typer av tester för att undersöka användbarheten i ett system. En metod kallas heuristisk utvärdering och den utgår ifrån att en grupp av experter eller användare gör en utvärdering av användbarheten i ett datorsystem. Ofta räcker det med 5-7 utvärderare för att hitta ca 75% av användbarhetsproblemen i systemen. Nielsen (1993) har sammanställt tio områden som bör ingå i en granskning av användbarheten: Enkla och naturliga dialogrutor Alla typer av dialogrutor med textbaserad information bör vara enkelt utformade utan inblandning av tekniska termer som kan vara svåra för användaren att förstå. Ju mer text meddelandet innehåller desto mer måste användarna lära sig om systemet. Endast den absolut nödvändigaste informationen bör presenteras för användaren. Information bör även presenteras så att den uppfyller Gestaltlagarna, dvs. information som hör samman bör presenteras tillsammans (Nielsen, 1993). Storleken på texten måste göra den läsbar och typsnittet får inte vara svårläst. Ett bra användargränssnitt indikeras också av att funktioner som används mer frekvent är mer lättåtkomliga jämfört med funktioner som används sällan. Likartade funktioner bör grupperas eftersom det underlättar när användaren ska leta reda på var i gränssnitten som funktionerna återfinns (Allwood, 1998).

13 9 Information som användaren förstår med enkelhet Information bör presenteras på ett enkelt sätt. Det bästa är om informationen presenteras på användarnas modersmål eftersom det ökar läshastigheten och tiden det tar att förstå meddelanden. Ett enkelt språk minskar även risken för misstolkningar. Den som programmerar in texten bör även känna till den specifika terminologi som används av användarna för systemet. Det kan vara ord som är svåra att förstå för allmänheten, men för användarna är de många gånger vardagliga utryck som underlättar och snabbar på förståelsen (Nielsen, 1993; Allwood, 1998). Enligt Jordan (1998) är det viktigt att systemet ger användaren så mycket kontroll som möjligt. Ett av de vanligaste problemen som bryter mot denna princip är att ett system återgår till normalläge efter en förutbestämd tid om användaren låter systemet stå orört. Att en användare inte interagerar med ett system betyder emellertid inte nödvändigtvis att användaren är klar. Det kan lika väl betyda att användaren har kört fast, gjort något fel och söker support. Om systemet under denna tid nollställer kan det leda till frustration hos användaren eftersom denne måste leta sig tillbaka till det tidigare läget en extra gång. Andra typer av användarkontroll handlar om att ha möjlighet att ställa in sitt system och dess gränssnitt efter personliga behov, som exempelvis ljusstyrka, stolhöjd, etc. Minimal belastning på arbetsminnet Det är stor skillnad på den mängd information som kan hanteras av en människa och av ett datorsystem. Detta får till följd att mycket information inte bör presenteras på en och samma gång. Ska information matas in är det bra om systemet beskriver i vilken form den ska matas in (Nielsen, 1993). Om det exempelvis handlar om att mata in personnummer är det bäst om systemet meddelar hur många siffror som förväntas, om det behövs bindestreck mellan datum och kontrollsiffror och så vidare. Ett annat sätt att minska belastningen på arbetsminnet handlar om att de förväntningar användaren har på funktionaliteten i systemet stämmer överens med andra system som användaren har erfarenhet av. Det handlar exempelvis om att något med röd färg signalerar varning och att det med grön signalerar att det är okej. Dessa typer av normer har olika spridning i olika kulturer. Ett bra exempel är hur strömbrytare bör ställas för påslag respektive avslag av elströmmen. I vissa kulturer betyder upp påslag i andra betyder upp avslag (Jordan, 1998). Konsekvens Att systemet är konsekvent är en viktig faktor när det handlar om att uppnå användbarhet. För användaren är det viktigt att ett kommando har samma namn och betyder samma sak överallt där det förekommer i systemet. Det är även viktigt att knappar som återfinns i flera olika dialogrutor återfinns på samma ställe i dialogrutorna för att underlätta igenkännandet hos användaren. Om systemet är konsekvent bidrar det till att risken att användarna känner osäkerhet när de använder systemet minskar betydligt (Nielsen, 1993). När användarna exempelvis lärt sig att hitta hjälpfunktionen på ett ställa i menyerna bör den därefter alltid gå att återfinna på samma ställe. Olika ord och begrepp bör ha samma definition om de återfinns på olika ställen i programmet (Jordan, 1998). Feedback Att som användare få feedback från ett system har visat sig vara viktigt (Jordan, 1998). Ges endast feedback när fel uppstår är det oftast för sent (Nielsen, 1993). Det är viktigt att användaren hela tiden vet i vilket läge systemet befinner sig. Avsaknad av feedback leder till osäkerhet. Bra feedback behöver inte handla om en massa information som ges till användaren, ett timglas som visas när en åtgärd tar tid att utföra räcker långt. När det handlar om att en funktion aktiveras har det visat sig viktigt att feedback ges inom ett visst tidsintervall från det att

14 10 användaren aktiverat funktionen. Det finns några kritiska tidsgränser för feedback som vid passering utan feedback gör användaren mer och mer osäker på om systemet verkligen har registrerat den valda funktionen. Tidsgränserna är enligt Nielsen (1993): 0.1 Sekunder Efter 0.1 sekunder börjar användaren tveka på om systemet verkligen registrerat knapptryckningen. Systemet upplevs ha en fördröjning om responsen dröjer längre än så här. I detta tidsintervall räcker det att resultatet presenteras till användaren. 1.0 Sekunder Användare tenderar att inte vilja vänta längre än 1.0 sekund på respons från systemet. Även till detta tidsintervall räcker det med att resultatet presenteras för användaren. 10 Sekunder Mer än tio sekunder leder till att användaren slutar fokusera på systemet om all typ av feedback uteblir. För att förhindra detta kan systemet presentera information för användaren när processen beräknas vara klar. Ett annat vanligt problem med respons ifrån datorsystem är att det går så fort att användaren inte hinner ta till sig informationen. Det handlar alltså om att information måste presenteras på rätt sätt för att användarna ska kunna hantera den. Informationen måste kunna delas upp i flera enheter. Avstängnings- och ångerfunktioner Användare vill inte känna sig vilse bland menyer och funktioner i ett system. För att öka känslan av att användaren har full kontroll på det system han/hon använder är det viktigt att det är enkelt för användaren att ångra val som gjorts om de senare visar sig vara felaktiga. En viktig del i detta är att meddelanden och dialogrutor som visas för användaren har en tydligt markerad knapp för avstängning (Nielsen, 1993). Genvägar När användaren har lärt sig systemet, speciellt om det handlar om ett komplext system som används mycket, är det en klar fördel om användaren har möjlighet att använda snabbare sätt att aktivera funktioner exempelvis via kortkommandon styrda ifrån tangentbordet. Det ökar användningshastigheten samtidigt som känslan av kontroll ökar (Nielsen, 1993). Förebygga fel Systemet bör kunna förebygga att fel uppstår exempelvis genom att systemet ställer frågor när användaren är på väg att aktivera funktioner som inte går att ångra. Ett annat sätt att förebygga fel och felhantering uppnås genom att inte ha olika lägen, modes, eftersom det kan bidra till att användaren inte vet i vilket mode systemet är i för tillfället. Att inte användaren vet vilket mode systemet är i kan medföra att användaren blir osäker eller inte alls vet hur systemet fungerar i det specifika modet. Att förebygga fel handlar också om att endast ha ett namn för en funktion och inte ha olika namn för samma funktion på olika ställen i gränssnittet (Nielsen, 1993). Att systemet får användaren att känna sig ha full kontroll över systemet är en viktig faktor för att förebygga felhantering. Antalet felhanteringar sjunker kraftigt om användaren har kontroll över systemet jämfört med de system där användarna uppger att de inte upplever att de har kontroll (Jordan, 1998).

15 11 När fel uppstår och hantering av dessa Fel kommer alltid att inträffa och svårtolkade fel är en av de mest negativa faktorerna för användbarhet. Det är viktigt att felmeddelanden är utformade så att användaren enkelt kan ta dem till sig och förstå vad de betyder. Meddelanden ska ha ett enkelt språk utan felkoder vilka bara insatta tekniker kan tolka. Användaren bör kunna förstå meddelandet utan att behöva använda sig av en instruktionsbok. Detta innebär att felmeddelanden bör innehålla information om vad som har blivit fel på ett så tydligt sätt som möjligt. Meddelandet bör även innehålla information hur användaren kan göra för att avhjälpa problemen (Nielsen, 1993). Oavsett hur bra ett system är utformat kommer användare någon gång att göra fel och då är det viktigt att systemet klarar av att hantera detta och på ett enkelt sätt förklara för användaren vad det är som blivit fel. Det är bäst om användaren så snabbt som möjligt efter att något har blivit fel informeras om detta. Det är även viktigt att felmeddelanden förklarar vad som blivit fel och eventuellt ger förslag på vad användaren bör göra för att åtgärda felet. En viktig funktion för att kunna åtgärda fel är möjligheten att ångra inmatade kommandon (Jordan, 1998). Hjälpresurser Ofta läser inte användare instruktionsböcker. Detta beror inte nödvändigtvis på att böckerna är dåligt utformade. Ofta beror det på avsaknad av intresse och att användare tror att de kommer att vara mer produktiva om de använder systemet direkt istället för att grundligt lära sig det via manualen (Nielsen, 1993). När en användare behöver hjälp finns det ofta flera olika sätt förutom instruktionsboken att söka hjälp på. Olika hjälpresurser har olika inverkan på användaren. Beroende på vilken användare det är som har problem och vilken typ av problem det handlar om söks ofta hjälp på olika ställen (Figur 3). Figur 3. Illustrering av på vilka olika sätt en användare kan söka hjälp när systemet inte fungerar som användaren tänkt sig (Efter Jordan, 1998). De allra flesta användare vänder sig först och främst till kollegor och IT-ansvariga på företaget då det anses vara enkelt och bekvämt. Det har också visat sig att det är viktigt att lokala IT-experter själva använder systemet i sitt arbete på samma sätt som övriga användare för att kunna hålla sig uppdaterade på hur användare upplever systemet. Om experten blir för mycket expert kan det vara svårt för denne att bemöta användare på deras nivå när de behöver hjälp (Jordan, 1998). Först när kollegors kunskap om problemet inte räcker till vänder sig användaren till manualer. Det finns ett flertal olika nivåer på manualer allt från handböcker som förklarar de mest grundläggande funktionerna och hur systemet fungerar till den mer ingående systemdokumentationen som går in på djupet och beskriver allt i detalj. En tunnare enklare användarhandbok är enklare att hitta i för den ovana eller ointresserade användaren samtidigt som den avancerade användaren kan gå in på djupet i den mer avancerade systemdokumentationen (Jordan 1998). Att göra instruktionerna lättillgängliga handlar bland annat om att inte göra stycken med text för långa, men vad som anses som lagom varierar mellan olika system så det finns inga fasta gränser (Allwood, 1998).

16 12 Metod Försökspersoner Sex användare av PMS deltog i intervjuerna. Deltagarna var alla män anställda på Räddningstjänsten i Piteå. De hade mellan 15 och 37 års erfarenhet av arbete inom Räddningstjänsten. Deras arbetstitel var insatsledare. Material Som utgångspunkt för användbarhetsundersökningarna, både intervjuerna och författarens granskning, användes Nielsens (1993) tio områden som härstammar från 249 problem som har visat sig försämra användbarheten (Bilaga 3): Enkla och naturliga dialogrutor Information som användaren förstår med enkelhet Minimal belastning på arbetsminnet Konsekvens Feedback Avstängnings- och ångerfunktioner Genvägar Förebyggande av fel Hantering av fel som uppstår Hjälpresurser PMS Beslutsstödsystemet PMS har funnits i sex år. I utvecklingsarbetet ingår tillverkaren SAAB PerformITs egen personal i kombination med experter ifrån olika områden. De användare som är med och testar och har möjlighet att ge feedback i utvecklingsarbetet är inte helt slumpmässigt utvalda utifrån hela populationen av användare. Det handlar istället om ett selektivt urval där huvudkriteriet är att testarna, enligt Rune Järpsten på SAAB PerformIT, ska ha domänkunskap i aktuell fråga. Beroende på vilken typ av test som genomförs är PMS även ibland med i riktiga räddningsinsatser under utvecklingsarbetet. Detta är dock inte nödvändigt utan det är tjänstgörande insatsledare som är med som bestämmer i vilken omfattning PMS ska vara med i räddningsinsatsen. PMS är ett så kallat standardsystem, vilket innebär att det ser likadant ut var det än förekommer. Det finns dock möjlighet att göra lokala anpassningar av systemet. Det finns ingen standardiserad monteringsanvisning, det är fritt fram för varje enskild Räddningstjänst att själv välja hur datorn ska placeras i fordonet. Räddningstjänsterna får dock information om lagar och ergonomi. Personal ifrån SAAB PerformIT håller en utbildning för personalen vid varje Räddningstjänst som köper in PMS. Denna utbildning tar en dag. Via supporten och träffar med användarna erhålls feedback. Även redan installerade system förändras om förändringarna berör det som ingår i standardapplikationen och ungefär två till tre gånger om året kommer det nya versioner av programvaran till PMS. Procedur Efter att ha läst en kortare instruktionsbok om PMS fick författaren i ett inledande skede av arbetets gång en kortare presentation av systemet av Per Isaksson, ansvarig för systemet vid Räddningstjänsten i Piteå, för att få förståelse hur systemet fungerar. Enskilda halvstrukturerade intervjuer genomfördes med sex användare av PMS. Alla intervjuer genomfördes i Räddningstjänstens lokaler i Piteå dagtid på deltagarnas ordinarie

17 13 arbetstid. Försökspersonerna hade innan intervjuerna inte sett frågorna utan informerades enbart om att frågorna skulle handla om deras inställning till PMS och om hur de upplever att det går att använda. Alla godkände att intervjuerna spelades in, vilket bidrog till senare ordagrann nedskrivning av intervjuerna på papper. Försökspersonerna var även informerade om att deras deltagande var helt anonymt och att inspelningen endast var till för att författaren efteråt skulle kunna göra en mer exakt analys och att inspelningarna förstörs när arbetet avslutats. Eftersom intervjuerna var halvstrukturerade var det vid varje intervju möjligt att ställa följdfrågor som inte finns med i intervjumallen (Bilaga 1). Efter intervjuerna genomförde författaren en egen utvärdering av PMS. Utvärdering gick till så att ansvarig för systemet på Räddningstjänsten i Piteå, ännu en gång, kort visade de olika delarna av PMS och hur de fungerade i olika lägen. Sedan simulerades ett larm som författaren skulle hantera i PMS. Samtidigt som larmet hanterades prickades de olika punkterna i listan med Nielsens (1993) tio områden av (Bilaga 3). Denna genomgång genomfördes när brandbilen stod parkerad i garaget, vilket fick till följd att vissa delar av PMS inte kunde granskas lika ingående som övriga delar. Bland annat begränsades granskningen av navigeringsstödet eftersom det används fullt ut endast när brandbilen körs i trafik. Detta påverkade dock inte möjligheten för författaren att få en överblick av både placering av skärm och tangentbord och själva funktionaliteten i större delen av PMS. Frågor besvarades även av Rune Järpsten på SAAB PerformIT, ansvarig för utvecklingen av PMS. Frågorna och svaren skickades via E-post (Bilaga 2). Avgränsningar Arbetet avgränsades till att endast undersöka hur PMS fungerar vid Räddningstjänsten i Piteå. Via detta datorsystem är det även möjligt att starta upp andra externa datorsystem, bland annat RIB som är en kunskapsdatabas för hantering av exempelvis farligt gods. Hur bra användbarheten är i RIB eller andra systemet som används via samma dator som PMS behandlas inte i detta arbete trots att de använder sig av samma datorskärm. Arbetet avgränsades vidare till endast de sex intervjuade användarna på Räddningstjänsten i kombination med författarens genomgång av PMS och till att endast beskriva de eventuella användbarhetsproblem som uppdagades. Några exakta förslag på hur eventuella problem ska åtgärdas kommer inte att ges. Enbart den dataskärm som används av den som styr PMS hanterades. Databehandling Enligt Miles & Hubermans (1994) arbetssätt för kvalitativ analys, som efter att intervjuerna nertecknats ordagrant genomfördes i två steg. Första steget innebar kodning av intervjuerna för att plocka ut teman i form av meningar, uttryck och ord som hade betydelse för att kunna besvara examensarbetets frågeställningar. Steg två i analysen var att jämföra de utplockade delarna från intervjuerna med varandra. Jämförelsen gjordes för att få bättre överblick och möjlighet att hitta gemensam information ifrån användarna. Resultat och analys Författarens utvärdering PMS status upplevdes ej visas tydligt hela tiden. Bland annat visades inga textbaserade meddelanden om PMS tappade kontakten med Internet som levererades via Mobitexnätet som är en typ av mobiltelefonnät med täckning över hela Sverige anpassat för datatrafik för exempelvis Räddningstjänster (Dialect, 2009). Kontakten med nätet indikerades med en liten rund symbol med en bokstav i vänstra nedre hörnet på skärmen som växlade färg (Figur 4).

18 14 Figur 4. Hur kontakt med Mobitexnätet och signalstyrka indikeras i PMS. L indikerar kontakt, grönt betyder att kontakt finns, rött att kontakt inte finns och M indikerar täckningen för Mobitexnätet (PerformIT, 2003). I den korta användarmanualen stod det inte förklarat vad bokstäverna L och M betyder och betydelsen var inte självklar. Däremot stod det att L indikerar att kontakt finns och M hur stark signalen är, men kopplingen bokstav och funktion var inte självklar. Återkopplingen vid aktivering av olika funktioner var inte heller speciellt tydlig. Aktiveringen av funktioner tog ibland tid men indikerades inte på skärmen via exempelvis ett textbaserat meddelande, ett timglas eller liknande Tidigare forskning har visat att det många gånger räcker att ett timglas visas för att användaren ska förstå att systemet arbetar (Nielsen, 1993). Det mest bristfälliga var att det inte kom någon respons när SOS-alarm tog emot kvittensen när ett ärende (larm) hade kvitterats. Däremot var det möjligt att via systeminställningsfunktionerna köra ett test mot SOS-alarm för att se att kontakten fungerade. Test av anslutningen var dock inget som en vanlig användare behövde känna till. Funktionstesterna var endast avsedda för den systemansvarige. Tangentbordet som fanns tillgängligt på skärmen hade stora brister när det handlade om kopplingen mellan system och verklighet. Det allra tydligaste var att utformningen inte följde den standard som finns för tangentbord när det gäller placeringen av tangenter. Mellanslag satt inte i mitten längst ner på tangentbordet utan var placerad på vänster sida där Caps lock normalt sitter (Figur 5). Detta fick till följd att det tog längre tid att skriva in text via detta tangentbord jämfört med ett vanligt tangentbord.

19 15 Figur 5. Tangentbordslayouten för det virtuella tangentbordet i PMS (PerformIT, 2003). Att ångra sig och avbryta för att byta funktioner var enkelt och på denna punkt följde PMS delvis generella standards. Det fanns en knapp uppe till höger i de flesta dialogrutor som används för att stänga dem. Dock var dessa knappar inte konsekventa i och med att knapparna ibland visar texten Avbryt medan de i andra dialogfönster endast visar ett X (Figur 6). Det vore bättre om endast en av beteckningarna användes över allt i PMS. Det var svårt att se mönstret för vilken typ av symbol det skulle letas efter i de olika dialogrutorna, vilket dock förmodligen är något användaren lär sig. Olika beteckningar var inget som underlättade inlärningsprocessen. Det positiva var dock att oavsett beteckning var placeringen av knappen alltid på samma ställe, nämligen längst upp höger. Figur 6. Två olika dialogrutor, i den ena stängs dialogrutan genom att klicka X i andra klickar man Avbryt (PerformIT, 2003). Det fanns exempel på olika funktioner som återfanns på olika platser i PMS med samma namn som gjorde helt olika saker. Exempel på detta var ett så kallat Dag/natt -läge. På ett ställe där denna funktion återfanns betydde den inställning för ljusstyrkan på skärmen och på ett annat att färgerna på skärmen förändrades, dvs. färgskalan gick över till en svartgrön skala som

20 16 ska vara lättare att se när det är mörkt jämfört med den normala färgskalan som visar alla färger (Figur 7). PMS förebyggde på ett effektivt sätt att användaren riskerar att göra fel. Detta genom att dölja de funktionsknappar som för tillfället inte gick att använda (Figur 7). Figur 7. Gruppering av funktionsknappar i PMS. Notera att den funktionsknapp som inte går att använda för tillfället är dold (PerformIT, 2003). När det handlade om placering och gruppering av knappar var PMS enkelt uppbyggt. Knapparna längst ner på skärmen var färgkodade beroende på funktion (Figur 7). Om knapparna var blå betydde det att de var funktionsknappar och var de guldfärgade betydde det att de var olika systemlägesknappar. Dessa var alltid synliga längst ner i mitten på skärmen. De blå funktionsknapparna byttes ut beroende på vilket systemläge som var valt. Det var lätt att se vilket systemläge som var aktiverat eftersom knappen för valt systemläge såg ut att vara intryckt i förhållande till övriga systemlägesknappar. Alla blå funktionsknappar hade dock svårt att fullt ut nå upp till målet igenkänning före minne beroende på att många av funktionsknapparna innehöll svårtolkade förkortningar som exempelvis Disp. Radio. Det fanns inga genvägar för att snabba på användningen av PMS, men samtidigt gick det inte att navigera så långt från startläget att genvägar skulle underlätta arbetet märkbart. Ofta visades precis den information och de funktionsknappar som behövdes vid ett visst tillfälle. Det fanns dock undantag i systemmenyn, men detta var dock en meny som användaren inte behövde använda speciellt ofta. Om en omstart av PMS behövde göras fanns det dock alldeles för många knappar att välja mellan för att det skulle vara enkelt att göra det. Som Figur 8 visar innehöll systemmenyn totalt 28 knappar, men som vanlig användare kunde bara ett fåtal av knapparna användas. De övriga funktionsknapparna var till för systemadministratören och var därför lösenordsskyddade. Knappar i systemmenyn var alltså otillgängliga men synliga. Detta stör och försvårar när användaren ska hitta de tillgängliga knapparna. Figur 8. Systemmenyn och alla dess knappar. Många knappar har användaren inte tillgång till (PerformIT, 2003).