Ris och ros för doris en gränssnittsutvärdering av ett röntgenremissystem på Danderyds sjukhus

Ris och ros för doris en gränssnittsutvärdering av ett röntgenremissystem på Danderyds sjukhus Åsa Martinsson TRITA-NA-E04066

NADA Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science 100 44 Stockholm Royal Institute of Technology SE-100 44 Stockholm, Sweden Ris och ros för doris en gränssnittsutvärdering av ett röntgenremissystem på Danderyds sjukhus Åsa Martinsson TRITA-NA-E04066 Examensarbete om 20 poäng inom fristående kurs i datalogi Stockholms universitet år 2004 Handledare på Nada var Henrik Artman Examinator var Yngve Sundblad

Sammanfattning Användbarhet blir alltmer viktigt i ett samhälle där det mesta styrs av datorer. Syftet med detta examensarbete är att ur ett användbarhetsperspektiv utvärdera ett remissdatasystem på Danderyds sjukhus i Stockholm. Datorsystemet doris används för att skicka remisser mellan sjukhusets röntgenavdelning, läkare och övriga personal. Arbetet är avgränsat genom att endast fokusera på den del av gränssnittet som används av personalen som inte arbetar på sjukhusets röntgenavdelning. Vidare avgränsas arbetet genom att endast inkludera läkare från fyra kliniker. Dessa kom att utgöra utvärderingens testgrupp. Som utvärderingsmetod tillämpades intervjuer och olika praktiska tester med användarna. Vid utförandet av ovan nämnda tester ombads läkarna i testgruppen att utföra uppgifter i doris medan deras lösningar noterades av en testhandledare, för att senare utvärderas. Resultatet av examensarbetet visar att det största problemet med doris är att systemet idag är för långsamt. Detta ligger till grund för irritation och stress hos användarna. Vidare visar resultatet att doris gränssnittsproblem till största delen är systemets brist på konsekvens och att dess funktioner omfattas av alltför många steg. Med hänsyn till ovan nämnda resultat har en gränssnittsprototyp utvecklats under examensarbetets gång. Prototypen syftar till att exemplifiera hur ett användbart gränssnitt för doris kan se ut.

Abstract Pros and Cons of doris an usability evaluation of a hospital software system In today s modern society, where the majority of things are computerized, great focus is put on what is referred to as usability. The purpose of this Master s thesis is to perform a usability evaluation on doris, a software computer system presently used at Danderyd s hospital, located in Stockholm. DoRIS is used to send referrals between the hospital s x-ray division, doctors and other staff members within the hospital. The thesis work is limited by focusing exclusively on the part of the user interface used by the hospital staff not working within the x-ray division. Further, the thesis work is limited to include doctors within four of the hospital s divisions. These doctors were included and served as the test group when performing the usability evaluation. For the purpose of this Master s thesis, interviews and several functional tests were conducted with the doctors. During the performance of the functional tests, all users were asked to perform different tasks using doris. All functional tests were monitored by an experimenter. The result of the thesis work shows that the most extensive problem with doris is based on the system s lack of speed. Thus, this is a real source of irritation and stress for all users involved. Furthermore, the results shows that the interface problems are mainly related to the system s lack of consistency and to the fact that its functions are poorly structured, involving too many steps. With respect to these results, a user interface prototype has been developed. The purpose of this prototype is to exemplify of how an interface with higher usability focus could be developed and implemented.

Innehåll 1 Introduktion... 9 1.1 Uppdragsgivare... 10 1.2 Fakta om doris... 10 1.3 Problem... 11 1.4 Syfte... 12 1.5 Avgränsningar... 12 2 Teorier om användbarhet och metoder för utvärdering av system... 13 2.1 Vad är användbarhet?... 13 2.2 Varför användbarhet?... 14 2.3 Modell för traditionell systemutveckling Vattenfallsmodellen... 15 2.3.1 Systemanalys... 16 2.3.2 Kravanalys... 16 2.3.3 Detaljerad design... 16 2.3.4 Programkodning och testning... 16 2.3.5 Integrering och testning... 17 2.3.6 Underhåll... 17 2.3.7 Nya krav på utvecklingsprocessen... 17 2.4 Modeller för användarcentrerad systemutveckling... 17 2.4.1 GUIDE-modellen... 18 2.4.2 Usability Engineering Lifecycle-modellen... 21 2.4.3 Sammanfattning av GUIDE och Usability Engineering Lifecycle... 25 2.5 Hur uppnås användbarhet?... 25 2.6 Metoder för utvärdering av användbarhet... 27 2.6.1 Expertutvärdering... 27 2.6.2 Test med användare... 28 2.6.3 Interaktionstest... 29 2.6.4 Labbtest... 30 2.7 Sammanfattning av utvärderingsmetoderna... 30 3 Utvärderingsmetod... 31 3.1 Förberedelser... 31 3.2 Användningstest med läkare... 32 3.3 Utveckling av nytt gränssnitt... 32

4 Resultat... 33 4.1 Resultat av samtal med systemadministratörer... 33 4.2 Utvärdering av existerande gränssnitt... 33 4.2.1 Sökning efter en patients remisser... 34 4.2.2 Skriva en remiss... 34 4.2.3 Söka efter eget skrivna remisser... 35 4.2.4 För- och nackdelar med doris... 36 4.3 Sammanfattning av utvärderingen... 37 5 Designförslag... 43 6 Utvärdering av designförslag... 47 7 Rekommendationer... 49 8 Resultat... 51 9 Diskussion... 53 Tack... 55 Referenser... 57

1 Introduktion På 1970-talet när stordatorer började användas fanns det inga höga krav på användbarhet. Användningen skedde mer på datorernas villkor och det var datorexperter som använde dem. Det kunde vara en och samma person som programmerade och använde systemen. Larsson (2003) skriver att fram till mitten av 80-talet var gränssnitt kommandobaserade. Användaren kommunicerade med datorn med hjälp av kommandon bestående av bokstäver och siffror, som ofta var slumpmässigt utvalda. Användaren var tvungen att komma ihåg dessa kommandon och känna igen dem. Detta stämmer dåligt med människans psykologi. I och med introduktionen av persondatorer ökade kravet på användbarhet. När gemene man på i stort sett varje arbetsplats använder datorer i det dagliga arbetet krävs det att användbarheten är hög. Det ska inte krävas av användarna att de ska vara programmerare för att kunna använda datorsystemen. Det blev en stor förbättring när de grafiska gränssnitten började användas. Gränssnitten underlättar för användarna då de är uppbyggda av bilder, former och färger vilket är bättre anpassat till det mänskliga minnet. Med tiden blev det mer och mer viktigt att datorsystemen var lätta att använda. Nya begrepp infördes som bland annat användarvänlighet (userfriendly) och användbarhet (usability). I denna rapport används endast begreppet användbarhet. I avsnitt 2.1 beskrivs begreppet användbarhet ytterligare. Där beskrivs en produkt som användbar om den är anpassad till dess användare, vilken situation den ska användas och vad produkten ska göra. Det är viktigt att datasystem är användbara. Detta minskar stress och allmän ohälsa hos användarna. Användbara datasystem ger även fördelar för företaget. Ett datasystem som är lättförståeligt minskar kraven på utbildning av personalen och behovet av telefonsupport vilket i sin tur minskar företagets kostnader. Istället minskar de anställdas missnöje, så också personalomsättningen och produktiviteten ökar. Trots att persondatorer har funnits länge och de flesta är medvetna om att det är viktigt med användbarhet upplever inte användarna att datorsystemen är användbara. Detta anses av många vara ett stort problem. En av orsakerna till att nya datorsystem inte utvecklas till tillräckligt användbara system är att i slutet av många projekt då tiden är knapp och nästan alla pengarna spenderade, prioriteras användbarheten bort. Detta är inte ekonomiskt i det långa loppet då låg användbarhet kostar företagen pengar. Ett sätt att undvika tids- och penganöd är att involvera användbarhetsaktiviteter under hela utvecklingsprocessen. 9

Danderyds sjukhus har insett att de anställda inte är nöjda med användbarheten på sjukhusets datorsystem. När det visade sig i en undersökning att användarna av det nya röntgenremissystemet doris (dokumenterat Radiologiskt InformationsSystem) inte alls var nöjda ville de utvärdera gränssnittet ur ett användbarhetsperspektiv för att kunna förbättra systemets design. Med stöd av nämnda nackdelar som visar sig vid dålig användbarhet menar jag att doris brister ur en användbarhetssynpunkt ger en stressad och irriterad personal. Personalen har svårt att se fördelarna med det nya röntgenremissystemet. De tycker att den nya hanteringen av remisser är för omständlig och tar längre tid än det gjorde tidigare då de skrev pappersremisser som skickades till röntgenavdelningen med rörpost. Eftersom designen redan är färdig kommer mitt arbete bestå av att utvärdera doris design och peka på dess för- respektive nackdelar. Vidare kommer arbetet resultera i ett förslag på hur ett användbart gränssnitt för doris kan se ut. 1.1 Uppdragsgivare Danderyds sjukhus är beläget norr om Stockholm. Sjukhuset ägs av landstinget och är ett sjukhus för personer bosatta framförallt i den norra delen av Stockholm. Sjukhuset bedriver både planerad och akut vård och tar varje år emot cirka 160 000 läkarbesök, varav 58 000 är akuta. Totalt har sjukhuset idag cirka 2 500 anställda, ungefär 350 av dessa är läkare. (Källa www.ds.se senast besökt 2004-02-17.) Mycket av sjukhusets verksamhet är datoriserad. Datasystemet Melior har sedan mitten av 1990-talet använts för patientjournaler. Under våren 2003 har ytterligare ett system införts, där provsvar från sjukhusets laboratorium redovisas. Samtidigt har datasystemet doris introducerats för att datorisera hanteringen av sjukhusets röntgenremisser. 1.2 Fakta om doris Som tidigare nämnts, används doris för att skicka röntgenremisser till sjukhusets röntgenavdelning. Efter genomförd röntgenundersökning sparas röntgenläkarens utlåtande och undersökningens bilder i systemet. Med doris kan läkaren skriva en remiss på vilken dator som helst på sjukhuset. När läkaren anser sig vara klar med denna signeras remissen och personalen på röntgenavdelningen kan då ta del av den. Personalen på röntgenavdelningen bokar därefter en tid för undersökning och läkaren samt övrig personal på patientens avdelning kan då ta del av den informationen i doris. 10

DoRIS möjliggör för personalen att följa en remiss under hela processen. Detta möjliggörs genom att remissen tilldelas olika status, vilken anger det skede i vilket remissen befinner sig. När remissen blir skickad från läkaren tilldelas den statusen beställd. Denna status följs av pågående, utförd och så vidare. En schematisering av processen presenteras i figur 1. En remiss skrivs Sparad Ej Skickad Skickad Beställd Utebliven Avbeställd Utförd Pågående Prel Sign Besvarad Sign Figur 1. Egen schematisk bild över doris olika status. När undersökningen är utförd, sparas röntgenbilderna tillsammans med ett utlåtande från röntgenläkaren i doris. Den remitterande läkaren kan efter detta nå denna information på sjukhusets alla datorer. Därmed behöver inte längre röntgenplåtar skickas mellan sjukhusets olika avdelningar. Detta är en stor fördel för de anställda på röntgenavdelningen, då alla bilder inte längre behöver sparas i arkiv. DoRIS erbjuder även fördelar för övriga anställda på sjukhuset. En fördel är att de har tillgång till doris information inom hela sjukhuset och behöver därför inte i normala fall kontakta röntgenläkare. En annan fördel för de anställda är att doris tillåter dem att titta på tidigare resultat från röntgenundersökningar av deras patient. De behöver därför inte kontakta arkivet och be dem skicka informationen. 1.3 Problem Innan doris infördes hade röntgenavdelningen på sjukhuset sedan länge önskat att datorisera hanterandet av röntgenremisser. Tidigare skrev läkarna röntgenremisser på papper för att sedan skicka dem till röntgenavdelningen med intern- eller rörpost, beroende på hur akuta remisserna var. Personalen på röntgenavdelningen bokade därefter tid för röntgenundersökningarna. 11

Under de två första åren användes doris endast på sjukhusets ortopedklinik. De anställda på ortopedkliniken fick sedan utvärdera systemet och dess rutiner. Efter vissa modifieringar i systemet, till följd av utvärderingen, infördes doris på hela Danderyds sjukhus under våren 2003. Sedan dess har många klagomål på doris framkommit. I en tidigare enkätundersökning om sjukhusets datorsystem, genomförd hösten 2002, visade resultatet att personalen, då framförallt läkarna, var missnöjda med systemen. Systemens användbarhet identifierades då som en av de huvudsakliga orsakerna till missnöje bland de anställda. I enkäten fick de anställda endast gradera systemens användbarhet. Enkätresultatet gav därför inte några konkreta exempel på systemens dåliga användbarhet. På grund av de många klagomål som införandet av doris har medfört är det nu sjukhusets önskan att identifiera problemen med systemet. Genom att åtgärda användbarhetsbristerna är förhoppningen att de anställda ska få en mer positiv attityd gentemot systemet och finna det användbart. 1.4 Syfte Syftet med examensarbetet är att utvärdera doris nuvarande gränssnitt ur ett användbarhetsperspektiv. Resultatet ska sedan användas för att ge förslag till förändringar som gör doris mer användbart. Vidare ska ett designförslag på ett nytt gränssnitt utvecklas och presenteras. 1.5 Avgränsningar För att avgränsa examensarbetet har jag valt att endast fokusera på den del av doris gränssnitt som används för att skriva remisser och nå information om röntgenundersökningars resultat. Därav kommer inte den del av gränssnittet som används av röntgenavdelningens personal beröras av denna rapport. Jag har även beslutat att endast fokusera på sjukhusets läkare som användare av doris. En anledning till avgränsningen är att denna grupp vid tidigare undersökningar har uppvisat det största missnöjet med användbarheten på sjukhusets olika datasystem. En ytterligare anledning till denna avgränsning är att det är läkarna som i det flesta fall skriver remisser och är den grupp användare som använder systemets olika funktioner mest. För att vidare avgränsa antalet användare i utvärderingen, har jag valt åtta läkare från fyra av sjukhusets kliniker; ortopedi, kirurgi, anestesi och medicin. Tanken med detta är att få en indikation på huruvida det är någon skillnad mellan hur klinikerna arbetar med doris eller om skillnaden ligger på individnivå. 12

2 Teorier om användbarhet och metoder för utvärdering av system Detta kapitel beskriver vad användbarhet är och varför det är viktigt med användbarhet. Det beskrivs även hur man uppnår användbarhet i sin design. Vidare kommer några modeller för systemutvecklings beskrivas, för att påvisa skillnaden mellan traditionell systemutveckling och användarcentrerad systemutveckling. 2.1 Vad är användbarhet? Användbarhet är ett relativt nytt begrepp som har börjat användas under de senaste årtiondena. Definitionerna av användbarhet skiljer sig något från varandra men alla syftar till att beskriva användbarhet som en kvalitetsegenskap som beskriver hur väl produkten fungerar i interaktionen mellan människa och dator. Definition av användbarhet enligt ISO (ISO 9241:11): Usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. ISO-definitionen beskriver att lösningen måste anpassas till de personer (specified users) som ska använda produkten, användningssituationen (context of use) och användarnas förväntade nytta (specified goals). Effectiveness betyder i det här fallet noggrannheten med vilken användaren uppnår bestämda mål. Efficiency står för förhållandet mellan de resurser användaren behövt lägga ner på att uppnå ett bestämt mål och den noggrannhet med vilken användaren uppnår det bestämda målet. Slutligen står satisfaction för bekvämligheten och acceptansen av systemet. Nielsen (2003, b) tillämpar ett liknande sätt för att mäta användbarhet, genom att undersöka följande fem kvalitetskomponenter: Learnability Hur enkelt är det för användare att utföra enkla uppgifter första gången de använder produkten? Efficiency När användarna väl lärt sig produkten, hur snabbt kan de utföra uppgifter? Memorability När användarna kommer tillbaka till produkten efter att inte använt den på ett tag, hur snabbt återfår de sin färdighet? Errors Hur många fel gör användarna, hur allvarliga är dessa fel, och hur enkelt kan de reparera dessa fel? Satisfaction Hur tilltalande är det att använda designen? 13

Dix m.fl.(1998) ser användbarhet på ett annat sätt. De identifierar tre principer som definierar användbarhet: Learnability avser den lätthet med vilken nya användare kan börja använda systemet på ett effektivt sätt och uppnå maximal användarnivå. Med en maximal användarnivå menas en nivå där användaren förstår de relevanta delarna av systemet och kan utnyttja det maximalt. Principen inkluderar förutsägbarhet, igenkänning och konsekvens. Flexibility avser de många olika sätt på vilka användare och system kan utbyta information. På hur många olika sätt det kan göras på, att kunna utföra flera uppgifter samtidigt, möjligheten för användaren att bestämma hur saker och ting presenteras osv. Robustness avser bland annat möjligheten för användaren att kunna rätta till fel som begåtts, och till vilken grad systemet kan utföra de uppgifter användaren vill göra och om användaren förstår vad som händer. Det är inte, för denna rapport skull, relevant att beskriva så många olika författares definitioner på användbarhet som möjligt. Det viktiga är att inse att om definitionen eller definitionerna används i utvecklingsarbetet är det större sannolikhet att resultatet blir en produkt med högre användbarhet. Något som är viktigt att notera är att användbarhet är relaterat till en specifik användare som använder en specifik produkt. Enligt ISOdefinitionen är det också viktigt i vilken sammanhang användaren använder produkten. 2.2 Varför användbarhet? I en tid där allt mer datoriseras är användbarhet ett begrepp som blivit allt mer viktigt. Det finns många myter om att användbarhet kräver stora investeringar. Argument mot detta är till exempel om en webbapplikation inte är användbar kommer besökaren, den potentiella kunden, snabbt ge upp och lämna applikationen för att kanske aldrig återvända. På det sättet har nu företaget mist en potentiell kund. Men även i system som användarna är tvungna att använda är det viktigt med användbarhet. Pengar som investeras på användbarhet betalar sig oftast på lång sikt. Det finns många exempel på vad dålig design kan orsaka. Nielsen (2003b) skriver att den tid som användaren spenderar på att fundera över hur datasystemen fungerar eller försöker lösa datorrelaterade problem är tid som arbetsgivaren betalar sina anställda för att inte göra någonting. 14

Shneiderman (1998) skriver att användarnas tilltro till systemet är ömtålig. Om användaren upplever ett enda fel i sökresultaten eller får oväntade resultat kan det resultera i att användaren känner misstro till systemet under en lång tid framöver. Ottersten & Berntsson (2002) anser att om en produkt som ska användas för att effektivisera arbetet måste produkten upplevas som effektiv av användaren. Ottersten & Berndtsson (2002) förklarar vidare att system som inte är användbara gör att vissa uppgifter tar onödigt lång tid att utföra. Ett icke användbart system skapar stress och allmän ohälsa hos personalen. Kalén (1997) i sin tur skriver att företag som använder system med låg användbarhet kan råka ut för finansiella förluster, stressade och missnöjda anställda, vilket kan leda till minskad produktivitet och hög personalomsättning. Kalén beskriver också vilka fördelar hög användbarhet medför. Det minskar kraven på utbildning och telefonsupport, vilket minskar kostnaderna. En produkt som är lättförstådd och som användarna lär sig fort ökar istället produktiviteten och kostar mindre än en produkt som kräver mycket tid för inlärning. Shneiderman (1998) skriver att sedan tidigt 1980-tal har användbarhetstestning ökat markant. Detta är ett tecken på att det numera fokuseras mer på användarna under systemutvecklingen. Shneiderman menar att i början av ett projekt finns den goda viljan att involvera användbarhetstester i designen men allteftersom tidspressen ökar och budgeten mindre prioriteras användbarheten bort. Men i de projekt som utför användbarhetstester ses stora skillnader. Testerna ger designern instruktioner och värdefull feedback som gör att dessa projekt i större utsträckning blir klara i tid och dessutom till minskade kostnader. Nielsen (2003a) skriver att ungefär tio procent av budgeten bör investeras i användbarhet. Detta kan tyckas dyrt, men Nielsens argument för detta är att investeringen garanterar att de resterande 90% av budgeten investeras på rätt sätt. Användbarhet är något som verkligen är värt att investera i. Det kommer att resultera i färre kostnader på sikt, mindre stressad och bättre mående personal. För att visa likheter och skillnader på traditionell systemutveckling och användarcentrerad systemutveckling följer här två avsnitt som beskriver olika modeller som används vid systemutveckling. 2.3 Modell för traditionell systemutveckling Vattenfallsmodellen Vattenfallsmodellen brukar framställas grafiskt som ett vattenfall, där varje del i modellen naturligt leder till nästa, vilket visas i figur 2. Dix m.fl. (1998) beskriver vattenfallsmodellen i sin bok Human-Computer Interaction. Den fortsatta beskrivningen av modellen är hämtad därifrån. 15

Systemanalys Kravanalys Design Kodning Testning Underhåll Figur 2. Illustration av Vattenfallsmodellen. 2.3.1 Systemanalys I systemanalysfasen försöker designern och beställaren arbeta fram vad de vill att systemet ska kunna utföra. Det är alltså inte hur det ska utföras som ska beskrivas i denna fas, utan vad. För detta måste information insamlas om arbetsmiljön i vilken den slutgiltiga produkten ska användas, vilka personer produkten kommer att påverka och vilka andra system som den ska samverka med och som på så sätt kommer att påverka den nya produkten. 2.3.2 Kravanalys Nästa steg är nu att koncentrera sig på hur systemet ska utföra de förväntade uppgifterna. Kravanalysfasen syftar till att ta reda på vilka komponenter som behövs i systemet, vilka komponenter som gör vad, vilka som är beroende av varandra och om det finns några komponenter som måste dela resurser. 2.3.3 Detaljerad design Kravanalysen delar upp systemet i olika komponenter som möjliggör att de utvecklas var och en för sig för att senare bli integrerade. Om de olika komponenterna inte redan är utvecklade måste en detaljerad beskrivning över hur de ska utvecklas skrivas. Beskrivningen är en förfining av de olika komponenternas beskrivning i kravanalysspecifikationen. För det mesta finns det olika sätt att utveckla de olika komponenterna. Oftast väljs då det sätt som tillgodoser flest icke-funktionella krav. Det är viktigt att hålla reda på vilka beslut som har gjorts och varför. 2.3.4 Programkodning och testning Designen för varje komponent ska ha utformats så att det är möjligt att implementera den i något exekverbart programmeringsspråk. Efter att varje komponent är färdigimplementerad kan den testas så att den uppfyller dessa krav. 16

2.3.5 Integrering och testning När tillräckligt många komponenter är implementerade och individuellt testade ska dessa integreras, enligt beskrivningen i kravspecifikationen. Efter detta testas det sammansatta systemet för att försäkra att det har rätt beteende. Det är också möjligt att göra tester tillsammans med beställaren för att försäkra att systemet uppfyller dennes krav. Det är bara efter ett godkännande av hela det integrerade systemet som det slutligen levereras till kunden. Det kan också vara nödvändigt att jämföra den färdiga produkten gentemot krav som kommer från någon utomstående myndighet eller liknande. 2.3.6 Underhåll Allt jobb som utförs på systemet efter att det lämnats till kunden, tills dess att det har gått så lång tid att en ny version av systemet kräver en totalt omgjord design eller att det avvecklas helt, anses vara underhåll. Därför utgör underhåll den största delen under ett systems livstid. Underhåll innebär korrigeringar av fel i systemet som upptäcks efter att det lämnats till kunden och omarbetning av systemet för att tillgodose behov som inte upptäcktes under de tidigare designfaserna. Därför ger underhållet feedback till alla de andra delarna av livscykeln. 2.3.7 Nya krav på utvecklingsprocessen Modeller som vattenfallsmodellen uppstod på 1960- och 1970-talet då det fanns krav på struktur i utvecklingsprocessen av stora datorsystem. De flesta av dessa system användes för att behandla företagsdata. De var inte särskilt interaktiva och därför var inte användbarhetsproblem relevanta. Under slutet av 1970-talet utvecklades persondatorerna, som blev en stor succé, med datorsystem som var mer interaktiva än de hade varit förut. Med dessa ökade således kraven på användbarhet. Psykologiska teorier menar att för att kunna testa användbarheten på en produkt måste produkten iakttas under användning av riktiga användare. Sedan ska förändringar för att förbättra användbarheten utföras och sedan ska gränssnittet utvärderas igen. I denna iterativa process kommer modeller som vattenfallsmodellen till korta. Därför har det med tiden utvecklats andra modeller för att tillgodose behovet med en iterativ designprocess. 2.4 Modeller för användarcentrerad systemutveckling Där traditionella utvecklingsmetoder, likt vattenfallsmodellen, kommer till korta finns det andra modeller som kan erbjuda en annorlunda infallsvinkel. För att visa hur dessa användarcentrerade modeller fungerar kommer två olika modeller för användarcentrerad systemutveckling, GUIDE och Usability Engineering Lifescycle, beskrivas. 17

2.4.1 GUIDE-modellen Redmond-Pyle & Moore (1995) har utvecklat en modell för användarcentrerad design som de kallar GUIDE (Graphical User Interface Design and Evaluation). Modellen inför inga nya begrepp i användbarhetsteorin utan sammanfattar endast modeller som redan används i de olika delarna av designprocessen och som anses vara god gränssnittsdesign. Som en bakgrund till modellen beskriver Redmond-Pyle & Moore ett par enklare modeller för gränssnittsdesign som kommer återges nedan. 2.4.1.1 Naiv gränssnittsdesign Naiv gränssnittsdesign är den enklaste designprocessen som går ut på att skapa ett gränssnitt. Det är dock svårt att skapa ett bra gränssnitt på endast ett försök. 2.4.1.2 Iterativ design med prototyper Den mest erkända metoden för att lösa problemet med gränssnittsdesign är att införa en prototypslinga. Slingan gå ut på att en prototyp framställs, utvärderas och modifieras till en ny prototyp som utvärderas och modifieras på nytt vilket visas i figur 3. Vissa designers hävdar att det enda som krävs för att designen ska bli användbar, är att utvärdera prototyper. Redmond-Pyle & Moore menar att prototyputvärdering inte alltid är den bästa lösningen. Om inte målet med designen är välformulerat kan prototyputvärdering lätt leda till att produkten släpps för tidigt och de initiella grundkraven kan glömmas bort. Designa gränssnitt Bygga prototyp Färdigt gränssnitt Figur 3. Iterativ design med prototyper. 2.4.1.3 Usability engineering På 1980-talet intogs en mer ingenjörsmässig inställning till utvecklingen av användargränssnitt. Usability engineering-modellen går inledningsvis ut på att sätta upp användarkrav på den slutgiltiga produkten. Därefter skapas ett användargränssnitt som senare utvärderas gentemot användarkraven. Modellen beskrivs i figur 4. Modellens styrka är att användbarhetsmålen blir tydligare. Detta tvingar designern att ställa följande frågor, där svaret på sista frågan ger ett effektivt slutkriterium på den iterativa designprocessen: Hur användbar måste designen vara? För vem gör designen? Hur mäter jag användbarhet, för att avgöra om designen är tillräckligt användbar? 18

Användbarhetskrav Designa gränssnitt Bygga prototyp Utvärdera gränssnitt Färdigt gränssnitt Figur 4. Usability Engineering. 2.4.1.4 Användbarhet med uppgiftsanalys Problemet med usability engineering är att modellen inte ger några riktlinjer för hur ett bra första designförslag ska tas fram. Därför vänder sig Redmond-Pyle & Moore till användbarhetskoncepten. Det gäller att studera användarnas arbetsuppgifter, i vilken ordning de utförs och vilken information som måste vara tillgänglig i varje steg. Detta är en utmärkt förberedelse inför designen av det användargränssnitt som ska stödja användarnas arbetsuppgifter. Därför utökas modellen med en uppgiftsanalys innan designen av gränssnittet påbörjas. Eftersom Redmond-Pyle & Moore tycker att designen av gränssnitt, byggandet av prototyp och utvärderingen ibland överlappar har dessa faser lagts närmare varandra vilket visas i figur 5. Användbarhetskrav Uppgiftsanalys Designa gränssnitt Bygga prototyp Utvärdera gränssnitt Färdigt gränssnitt Figur 5. Användbarhet med uppgiftsanalys. 2.4.1.5 Konsekvens genom standard I användargränssnitt är det viktigt med konsekvens. Ett konsekvent användargränssnitt är lättare att lära sig för användaren. För att se till att användargränssnittet blir konsekvent kan man använda sig av en application style guide. Guiden är oftast baserad på industristandarder, om det finns sådana, men den specialiseras för det aktuella gränssnittet. Observera att style guiden ska skrivas med användarkraven i åtanke. Feedback från utvärderingen av prototypen kommer att jämföras med style guiden. Om style guiden inte håller för användarkraven måste den förändras. 19

2.4.1.6 Mentala modeller Efter att ha undersökt vad användarna gör så återstår endast att ta hänsyn till vad användaren tänker. GUIDE använder sig av mentala modeller. Norman (2000) beskriver att mentala modeller är de modeller människor har om sig själva, andra, omgivningen och om de saker de samverkar med. Människor formar sina mentala modeller genom erfarenhet, träning och instruktioner. Ett datorsystems mentala modell formas i första hand av tolkningen av användarens uppfattningar om systemets handlingar och visuella struktur. Norman kallar den visuella delen av systemet system image. När system imagen är osammanhängande eller fel i sammanhanget medför det användaren svårigheter. Om system imagen är ofullständig eller motsägelsefull, blir det stora problem. När det gäller design av användargränssnitt måste tre olika aspekter av mentala modeller urskiljas: design model, user s model och system image. Designmodellen är vad designern hade för modell av systemet under utvecklingen. Användarmodellen är den modell användaren utvecklar för att förklara hur systemet fungerar. Det ideala är om dessa två modeller är likvärdiga. Därför är det viktigt för designern att tala med användarna och ta reda på användarens modell av systemet. Å andra sidan är det viktigt att designern startar med en design model som är funktionell, lätt att lära och användbar. Vidare måste designern se till att systemet visar detta i sin system image. 2.4.1.7 Den kompletta GUIDE-modellen Nu är hela GUIDE-modellen beskriven. Nedan följer en kort beskrivning av varje steg i modellen. Hur de olika stegen förhåller sig till varandra visas i figur 6. Definiera användare och användbarhetskrav. Produktens användare ska definieras. I denna fas ska också användbarhetskraven definieras, några användbarhetskrav är generella för alla användare, medan andra är kopplade till typen av användare. Modellera användarnas arbetsuppgifter. Syftet med denna fas är att förstå vilka arbetsuppgifter användarna har och hur de utförs. Detta för att kunna förstå hur det nya systemet ska kunna förbättra användarnas situation. Modellera användarobjekt. Målet med denna fas är att se till att användaren får en korrekt mental modell av systemet genom att ta reda på vilka objekt användaren tror att det finns i systemet. Definiera en style guide. Syftet med denna fas är att få användargränssnittet stilmässigt konsekvent. För detta skapas ett dokument där stilen på knappar, text med mera beskrivs. Dokumentet utformas med hjälp av universella riktlinjer och användarkraven. 20

Designa användargränssnitt. I denna fas görs ett förslag till användargränssnitt som stöder användarkraven, stämmer överens med style guiden och som mäter användbarhetskraven. Efter att ha byggt och utvärderat gränssnittets prototyp startar denna fas om på nytt. På så sätt bildas en iterativ process för att finna ett användargränssnitt som följer alla uppsatta krav. Bygg prototyp. Av den specificerade designen bygger man en prototyp för att kunna utvärdera designens användbarhet och hur väl den uppfyller uppgiftsanalysen, objektanalysen och style guiden. Utvärdera användargränssnitt. Utvärderingen av prototypen görs enligt användbarhetskraven som definierades i början av processen. Återkoppling sker till designstadiet och en ny design görs om prototypen inte lever upp till de ställda kraven. Definiera användare och användbarhetskrav Modellera arbetsuppgifter Definiera style guide Modellera användarobjekt Designa gränssnitt Bygga gränssnittsprototyp Utvärdera gränssnitt Figur 6. GUIDE-modellen. Färdigt gränssnitt 2.4.2 Usability Engineering Lifecycle-modellen Nielsen (1993) beskriver en annan modell för användarcentrerad design som han kallar Usability Engineering Lifecycle. Följande beskrivning av modellen kommer från Nielsen (1993) om inte annat anges. Usability Engineering Lifecycle består, precis som GUIDE-modellen av olika faser. Det är inte alltid möjligt att utföra alla faser i alla projekt. Hög användbarhet kan ändå uppnås genom noggrant urval av delar i modellen. Faserna behöver inte genomgås i ordning, men den första fasen är alltid att lära känna användaren. De olika faserna beskrivs nedan. 21

2.4.2.1 Lära känna användaren Det första steget i användbarhetsprocessen är att studera de förväntade användarna och nyttan av den kommande produkten. Individuella egenskaper hos användarna och dess varierande arbetsuppgifter är de två faktorer som har störst inverkan på användbarheten. Därför bör dessa studeras ingående. I fasen ingår att: Studera de olika användarkaraktärerna. Det är nödvändigt att veta vilken typ av människor som ska använda systemet. I vissa fall vet man exakt vilka användarna är och i andra fall kan de bestå av hela befolkningen. Det är viktigt att veta användarnas kunskaper inom vissa områden så att gränssnittet kan anpassas efter dessa. Vidare är det viktigt att inse att begreppet användare inkluderar alla som blir påverkade av systemet; de som ska installera och underhålla systemet systemadministratörer och självklart de som sitter vi tangentbordet. Göra en uppgiftsanalys. Användarnas arbetssituation ska undersökas, hur de utför uppgiften idag och hur de hanterar exceptionella omständigheter eller kriser. Göra en funktionell analys. Ett nytt datasystem ska inte designas för att utföra arbetsuppgifter på samma sätt som de alltid har utförts. Teknologin som saknades förut kanske omöjliggjorde att uppgiften utfördes på ett annat sätt. Om teknologin nu finns kan uppgiften möjligen lösas på ett bättre sätt. Därför är det viktigt att inte bara analysera hur användaren löser uppgiften, utan vilken underliggande funktionell anledning uppgiften har. Vad är det som verkligen behöver utföras? Vilka lösningar kan, och kanske bör, förändras? Fundera på hur användarna kommer att förändras. Under användningen av systemet förändras användaren och kommer använda systemet på ett annat sätt. Den vanligaste förändringen är att användarna går från att vara nybörjare på systemet till att bli vana användare. Då förändras deras krav på systemet, de vill använda kortkommandon och liknande. 2.4.2.2 Konkurrensanalys Prototyper spelar en viktig roll i utvecklingsprocessen. De konkurrerande systemen är de bästa prototyperna som finns att tillgå. De är redan utvecklade och kan därför enkelt testas. Utvärderingarna kan ge idéer och förslag till den egna designen. Målet måste alltid vara att göra saker bättre, inte att kopiera de existerande system. 22

2.4.2.3 Användbarhetsmål I denna fas bestäms vad som är viktigt ur användbarhetssynpunkt i just detta system. Ett exempel på detta är om systemet ofta får nya användare är det viktigt att det är lättlärt, eller om systemet används sällan behöver det ha hög memorerbarhet. Det är också viktigt att ställa krav på den slutgiltiga designen. Om systemet ersätter ett gammalt system, så bör det vara bättre på många funktioner. Till exempel om det gjordes i genomsnitt 4,5 fel per timme i det gamla systemet, är det optimala att inga fel begås i det nya systemet. Målet kan vara att det endast ska göras två fel per timme i det nya systemet. 2.4.2.4 Parallell design Det är oftast en god idé att använda parallell design och låta flera designers utveckla enskilda preliminära lösningar. Målet med detta är att undersöka flera designalternativ innan man bestämmer sig för ett som man går vidare med i designprocessen. Det är viktigt att utvecklarna arbetar oberoende av varandra så att de preliminära lösningarna blir så olika som möjligt. Sedan kan det bästa från varje design användas för att vidare utveckla några olika designförslag. 2.4.2.5 Deltagande design Även om man genomfört fasen lära känna användaren i början av processen kan man inte känna användarna så väl att man kan svara på varje fråga som kommer upp under designarbetet. I stället för att gissa sig fram till svaren ska utvecklarna ha tillgång till en grupp representativa användare för sådana frågor. 2.4.2.6 Koordinering av hela gränssnittet Att ett gränssnitt är konsekvent är ett av de viktigaste användbarhetskriterierna och ska finnas i all media som bildar gränssnittet, inte bara det som syns på skärmen utan även dokumentation och kurser med mera. När uppdateringar av ett system görs måste det kontrolleras att dessa är konsekventa gentemot det ursprungliga systemet. För att uppnå konsekvens är det tvunget att ha en gränssnittskoordinator som för varje projekt koordinerar de olika delarna i gränssnittet. Detta kan göras genom att beskriva de olika standarder som ska användas i en styleguide eller att återanvända kod. Genom att återanvända gränssnittskod kommer delarna att likna varandra. 2.4.2.7 Riktlinjer och heuristisk utvärdering Det ska finnas riktlinjer för hur gränssnittsdesignen ska utföras. Allmänna riktlinjer existerar och används i alla användargränssnitt och kategorispecifika riktlinjer som är beroende på vilket typ av gränssnitt som utvecklas. Slutligen finns det också riktlinjer som är specifika för just det system som utvecklas. 23

Riktlinjerna används sedan som bakgrund när en heuristisk utvärdering utförs. Denna typ av utvärdering utförs av en eller fler utvecklare, där dessa går genom en lista med riktlinjer och principer för att se om användargränssnittet uppfyller dessa. 2.4.2.8 Prototyp En fullskalig implementation bör inte startas för tidigt i processen. Istället bör den föregås av utvärdering av prototyper till gränssnittet. Dessa prototyper kan utvecklas mycket fortare och billigare samt kan förändras många gånger tills användbarhetsmålen är uppnådda. 2.4.2.9 Gränssnittsutvärdering För utvärdering av gränssnitt finns det flera olika metoder. Oavsett vilken metod man väljer kommer problem att uppmärksammas och det är inte säkert att alla kan rättas till. Problemen bör därför prioriteras efter hur stor påverkan de har på användbarheten av systemet. 2.4.2.10 Återkoppling från användning När ett system är implementerat och i användning är det viktigt att samla information inför nästa version och för nya framtida produkter. På samma sätt som redan konkurrerande existerande system var de bästa prototyperna i den första konkurrensanalysfasen kan ett nyss släppt system vara en prototyp för framtida produkter. I detta skede finns det möjlighet att studera prototypen i en normal användningsmiljö. Dessa värdefulla data kan insamlas genom att låta användaren använda en testmiljö under tiden hon/han studeras. Figur 7 visar hur de olika faserna förhåller sig till varandra. Lär känna användaren Återkoppling från användning Parallell design Konkurrensanalys Användbarhetsmål Gränssnittsutvärdering Deltagande design Prototyp Koordinering av hela gränssnittet Utvärdering Figur 7. Usability Engineering Lifecycle (fritt efter Nielsen, 1993). 24

2.4.3 Sammanfattning av GUIDE och Usability Engineering Lifecycle Även om modellerna är olika finns det många likheter i deras faser. Båda modellerna fokuserar på vikten av att ta reda på vilka användarna till systemet är, deras färdigheter, arbetsuppgifter och arbetsmiljö. Det är också viktigt att syftet med systemet är klart och dess krav på funktionalitet och användbarhet. När prototyper ska byggas skiljer de sig åt. I Usability Engineering Lifecycle ska flera designförslag tas fram av olika utvecklare, för att sedan välja ett par stycken för att vidareutveckla till prototyper. GUIDE-modellen förespråkar att med hjälp av användbarhetskraven utveckla en första prototyp. Sedan startar en iterativ process i båda modellerna där prototypen utvärderas på olika sätt för att den ska förbättras tills den uppfyller alla funktionella och användbarhetskrav. I vattenfallsmodellen saknas helt kontakten med användarna. Det är endast designern och beställaren av systemet som kommer fram till vad systemet ska kunna. Det skrivs en kravspecifikation men den innehåller mestadels funktionella krav. Användbarhet tillhör de ickefunktionella kraven. I vattenfallsmodellen saknas möjligheten till iteration under utvecklingen av systemet, Det är just iterationen som karakteriserar användarcentrerad design. Det förväntas inte att det ska utvecklas ett perfekt gränssnitt på första försöket, tvärtom. Med hjälp av iterationen blir det möjligt att gå tillbaka och ändra, flera gånger om det skulle behövas. 2.5 Hur uppnås användbarhet? För att designen ska vara användbar är det i första hand viktigt att blanda in användarna i designarbetet. Det gäller att veta vilka som ska använda den slutgiltiga produkten så att man kan ha dem i åtanke och utgå från deras erfarenheter samt kunskaper under hela designprocessen. Ottersten & Berntsson (2002) skriver om vikten av att engagera kunder och användare i designarbetet. De hävdar att många misslyckade IT-projekt beror på att kunder och användare inte engagerats tillräckligt i designprocessen. Ett sätt att väva in användbarheten i utvecklingen av produkten är deltagande design. Detta beskrivs av Löwgren & Stolteman (1998) som att användarna och designer lär sig av varandra. Det betyder att inte endast användaren ska integreras i designarbetet utan designern ska även delta i användnings- och arbetssituationerna. Det är viktigt att designern bejakar användarnas arbetsformer vid utformandet av designprocessen. Designern måste inse att han/hon är en del i ett sammanhang och måste ta hänsyn till det under designprocessen. 25

Det finns många verktyg för att utvärdera användbarheten hos en produkt. Ottersten & Berndtsson (2002) förklarar att det kan vara svårt att utvärdera en produkt innan den har börjat användas. Men man kan försöka arbeta processorienterat när det gäller användbarhet och tänka i termer av användbarhet under utvecklingen av produkten. Ottersten & Berndtsson skriver att det är viktigt att ta hänsyn till; Det mänskliga systemet, Det sammanhang där produkten ska användas och Den nytta som produkten förväntas ge. Ett annat sätt att säkerställa att designen blir användbar är att arbeta produktegenskapsorienterat och tillämpa några av de många riktlinjer som finns om utvecklingsarbete. Ett exempel är The Eight Golden Rules of Interface Design: (Shneiderman 1998) Strive for consistency. Det är viktigt att designen är konsekvent Detta kan vara svårt då det finns många olika sätt att vara konsekvent på. Samma terminologi ska användas i menyer, knappar och liknande genom hela designen. Färger, fonter, layout, versaler med mera är saker som också bör vara konsekventa. Enable frequent users to use shortcuts. Ju mer användaren använder produkten ökar behovet av att minska antalet steg som behövs innan hon når sitt mål. Förkortningar, specialtangenter och gömda kommandon är sådant som uppskattas av frekventa användare. Snabb reaktionstid och snabb visningstid hos systemet är också uppskattat av användaren. Offer informative feedback. Vad än användaren gör ska systemet ge feedback. För de handlingar som sker ofta behövs ingen utförlig feedback, men däremot för handlingar som sker sällan behövs en allt mer öppen feedback. Design dialogs to yield closure.varje följd av funktioner ska grupperas till grupper med början, mitt och slut. När användaren får feedback om att en funktionsföljd är färdig känner hon/han tillfredsställelse och lättnad. Användaren kan då släppa tanken på den funktionsföljden och börja fokusera på nästa. Offer error prevention and simple error handling. I största möjliga mån ska systemet designas så att det hindrar användaren att utföra allvarliga fel. Om användaren ändå gör fel ska systemet upptäcka det och erbjuda lätta och specifika instruktioner för att reparera felet. Permit easy reversal of actions. I största möjliga mån ska användaren ha möjlighet att ångra sina handlingar i systemet. Det minskar användarens oro eftersom hon vet att fel kan göras ogjorda. Detta uppmuntrar användaren till att utforska systemet. 26

Support internal locus of control. Vana användare vill känna att de bestämmer över systemet och systemet svarar på deras handlingar. Överraskande handlingar från systemet med mera orsakar oro och otillfredsställelse hos användaren. Reduce short-term memory load. Begränsningen av det mänskliga korttidsminnet gör att det som visas i systemet bör vara enkelt. Lite information på fler sidor är att föredra framför mycket information på få. Användaren ska lätt ha tillgång till förkortningar, koder och annan information som krävs för att använda systemet. 2.6 Metoder för utvärdering av användbarhet Detta avsnitt beskriver olika metoder som kan användas för att utvärdera datorsystems användbarhet. Användbarhetstester kan utföras under hela designprocessen. Olika metoder lämpar sig bäst i olika sammanhang. 2.6.1 Expertutvärdering Otterstam & Berntsson (2002) beskriver en expertutvärdering på följande sätt: Gränssnittet ses över med avseende på hur syn, minne och tanke fungerar hos människan samt hur gränssnittet borde vara utformat därefter. Syftet med en expertutvärdering är att med en liten insats hitta många användbarhetsproblem. Efter expertutvärderingen finns gränssnittets brister och möjliga åtgärder till dessa beskrivna. Det som framför allt uppmärksammas i en expertutvärdering är bristande konsekvens, otydlighet eller förvirrande interaktion, hur väl produkten är utformad för att stödja människans informationsbearbetning och hur väl förslagen följer gängse standarder. I denna typ av utvärdering observeras endast de brister som en expert kan upptäcka. Ytterligare brister upptäcks inte förrän produkten är i användning. Därför bör expertutvärderingar användas i tidigare skede i processen, när användargränssnittet endast finns i pappersform eller när projektet helt eller delvis finns i körbar form. Dock kan en expertutvärdering även läggas in i slutet av projekt för att få någon typ av användbarhetsaktivitet. Shneiderman (1998) beskriver de negativa aspekterna med en expertutvärdering. Det krävs att det finns en expert som inte är involverad i projektet. Även för en expert kan det vara svårt att förstå gränssnittets designprocess första gången han/hon kommer i kontakt med det. Eftersom experten kanske inte har tillgång till kravspecifikation är det lämpligast om experten endast pålyser de delar han/hon tycker bör tas upp för diskussion. Sedan är det upp till designern att avgöra hur förändringen bör genomföras. 27

Shneiderman beskriver flera olika typer av expertutvärderingar: Heuristic evaluation. Experten använder sig av en lista med riktlinjer, som till exempel The Eight Golden Rules (se avsnitt 2.5), vid utförandet av utvärderingen. Guidelines review. Gränssnittet kontrolleras gentemot organisationens riktlinjer eller liknande dokument. Eftersom sådana riktlinjer kan innehålla tusentals delar kan detta arbete vara tidsomfattande, allt beroende på systemets storlek. Consistency inspection. Experten ser till att datorsystemets design är konsekvent, inom terminologi, färg, layout, in- och utmatningsformat i gränssnittet så väl som i träningsmaterialet och systemets hjälpfunktion. Cognitive walkthrough. Experten simulerar användarnas väg genom gränssnittet genom att utföra typiska uppgifter. Experten startar med uppgifter som utförs ofta, även mer ovanliga uppgifter ska ses över. Som en del av utvärderingen ingår att experten simulerar en dag i användarens liv. Formal usability inspection. Experterna håller ett rättegångsliknande möte där gränssnittet presenteras och dess för- och nackdelar diskuteras. 2.6.2 Test med användare Ett test med användare kan utföras i stort sett under hela projektets gång enligt Ottersten & Berntsson (2002). Det krävs att åtminstone en pappersprototyp finns att utvärdera. Beroende på vad som ska testas krävs det att olika delar är klara. Om upplevelsen av produkten ska utvärderas är det bra om så många detaljer som möjligt är klara. Däremot, om det är en del av funktionaliteten som ska utvärderas räcker det förmodligen med en färdig pappersprototyp. Ett test med användare går ut på att dessa får uppgifter att lösa och de uppmanas att tänka högt när de löser dem. Användarnas sätt att lösa uppgifterna studeras och eventuella fel eller svårigheter noteras. Enligt Shneiderman (1998) är viktigt att poängtera för användarna att det inte är de som utvärderas utan gränssnittet och mjukvaran. Vidare menar Shneiderman att vid dessa sessioner blir det en informell atmosfär som ofta leder till spontana förslag till förbättringar av systemet. 28