Ett tydligare System C2

Transkript

1 UPTEC IT09003 Examensarbete 30 hp Januari 2009 Ett tydligare System C2 Användargränssnittsutveckling med stöd av användarcentrerade metoder Niklas Moritz

2

3 Abstract Adding clarity to System C2 - User centered methods aiding user interface development Niklas Moritz Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box Uppsala Telefon: Telefax: Hemsida: User friendly and usable are two words that are often mentioned in the context of marketing new products. By doing so it adds an extra sense of quality to the product. The meaning of these words is therefore something that every product wants. But what is it that makes a product usable and user friendly? What methodology exists for making sure that a product is usable? Does it exist applicable processes to ensure user centered development? These questions together with a practical example are parts of what will be addressed in this report. The thesis was carried out for C2 Management, a company that works with supporting other companies in their work with quality and constant improvements. C2 Management has developed an IT-system, System C2, in order to help their customers to harness ideas from coworkers, customers and suppliers. A prototype has been developed in order to give an example on what changes that can be made in the improvement of System C2's user interface and its usability. In order to assemble the users' requirements and goals field studies was carried out together with a few of C2 Managements customers. The field studies consist of applying a set of usability evaluation methods with user participation. As a result from these field studies three user profiles was created. The users thoughts and actions were also processed down into a set of usability issues to be solved within the suggestions and later the resulting prototype. Handledare: Lars Nilsson Ämnesgranskare: Iordanis Kavathatzopoulos Examinator: Anders Jansson ISSN: , UPTEC IT Tryckt av: Reprocentralen ITC

4

5 Sammanfattning Användarvänlig och användbar är två begrepp som idag används i marknadsföringen av nya produkter. Begrepp som bara genom att nämnas tillsammans med en produkt tillför en indikation dess goda kvalitet. Innebörden av dessa ord är således något åtråvärt, men vad är det som gör en produkt användbar och användarvänlig? Implicerar lättanvänt användbart? Vilka metoder finns för att säkerställa en produkts användbarhet? Finns det applicerbara processer för att säkerställa ett användarcentrerat utvecklingssätt? Dessa frågeställningar tillsammans med ett praktiskt exempel är delar av vad som tas upp i denna uppsats. Examensarbetet genomfördes på företaget C2 Management som jobbar med att stödja andra företags arbete inom kvalitet och Ständiga Förbättringar. C2 Management har genom åren utvecklat ett IT-stöd, System C2, i syfte att hjälpa sina kunder att tillvarata idéer från medarbetare, kunder och leverantörer. Som ett led i att förbättra System C2s användarvänlighet har det utvecklats en prototyp, som även syftar till att visa de, många gånger små, förändringar som kan åstadkomma ett mer användbart system. För att kunna genomföra detta utvecklingsarbete föranleddes prototypen av grundliga studier rörande teorier kring användbarhet, användarcentrerade processer och utvärderingsmetoder med och utan användarmedverkan. Dessa teorier tas således upp i syfte att ge en grundläggande förståelse och definition av användbarhet. Vidare visas vilket tillvägagångssätt som kan tillämpas när användare inkluderas i utvecklingsprocessen samt vilka metoder som lämpar sig bäst i det arbetet. För att samla in användarnas krav och mål har fältstudier hos några av C2 Managements kunder genomförts. Fältstudierna består av tillämpningen av ett antal utvärderingsmetoder med aktiv användarmedverkan. Ur dessa fältstudier har tre användarprofiler tagits fram. Användarprofiler vilka fungerat som ett stöd i utvecklingen av prototypen. Även användarnas synpunkter, fundering och handlingar har kokats ner till ett antal användbarhetsproblem för att redas ut i de förslag som ges och även senare i prototypen som tagits fram. Slutligen diskuteras de metoder som använts i projektet och huruvida de fyllt sitt syfte eller inte och varför vissa metoder varit mer lämpliga än andra. Det tas även upp reflektioner kring resultatet och hur väl det uppfyller uppsatsens syfte och mål. Vidare sker en diskussion kring hur det varit att tillämpa användarcentrerade metoder på ett redan existerande system och hur man kan få igång ett användarcentrerat tankesätt. Diskussionen avslutas med reflektioner kring resultatets validitet och reliabilitet.

6 Innehåll 1 Inledning Bakgrund Syfte Mål Avgränsningar Tolkningsram Användbarhet Användbarhet enligt ISO Användbarhet, en gren av den totala acceptansen Lärbarhet, flexibilitet och stabilitet Alla produkter är användbara Tvinga mig inte att tänka Användarcentrerad design Användarcentrerad design enligt ISO Användarcentrerade processen Peoble Activities Context Technologies Prototyper som ett stöd i utvecklingen Högupplösta prototyper Lågupplösta prototyper Tekniska verktyg Asynchronous Javascript och XML Cascading Style Sheets Analysmetoder Användaranalys Uppgiftsanalys Personas Utvärderingsmetoder Heuristisk Intervjuer Tänka högt Forskningstekniker Induktiv eller deduktiv forskningsansats

7 INNEHÅLL INNEHÅLL Kvalitativ eller kvantitativ studie Validitet och reliabilitet System C2 TM Användningsområde Flödet Övriga funktioner Tekniken Arkitektur Teknisk lösning Anpassningsbarhet Genomförande Förberedelsefas Heuristisk utvärdering Fältstudier Intervjuer Användar- och uppgiftsanalys Tänka högt och observationer Urval Företagskunder Utvärderingsmetoder Framtagande av prototyper Anpassad användarcentrerad process Val av angreppspunkt Deduktiv forskningsansats Kvalitativ studie Resultat Heuristisk utvärdering Skärmdisposition Orientering och navigering Kontroll och feedback Inmatning Fel och hjälp Läsbarhet Färganvändning och utseende Personas Expertanvändaren Medelanvändaren Sällanan-vändaren Klassificering av användbarhetsproblem Prototyp Designbeslut

8 INNEHÅLL INNEHÅLL Prototypen Motivering Prototyp Heuristisk genomgång Designbeslut Prototypen Motivering Diskussion Metodvärdering Resultatdiskussion Användarcentrerad utveckling i verkligheten Börja med att krypa och sedan gå Validitet och reliabilitet A Prototyp 1 67 B System C2s ursprungliga användargränssnitt 78 3

9 Figurer 2.1 Användarcentrerad design enligt ISO Den användarcentrerade processen Poeple Activities Context Technologies Prototyper av olika aspekter Figurerna beskriver Ajax-teknikens tekniska lösning samt vinsten med tekniken Metodklassificering Figuren beskriver förhållandet mellan antal funna användarproblem mot antal utvärderare System C2s processflöde Trelagerarkitektur Jämförelse mellan projektets genomförandeprocess samt Göranssons och Gulliksens användarcentrerade process A.1 Översiktssida A.2 Nytt ärende A.3 Nytt ärende; andra steget A.4 Besluta i ärende A.5 Ska genomföras A.6 Utred A.7 Lägg ned ärende A.8 Klarrapportera ärende A.9 Klarrpportera ärende; andra steget A.10 Följ upp ärende B.1 Översiktssida B.2 Nytt ärende B.3 Besluta i ärende B.4 Klarrapportera ärende

10 Tabeller 2.1 Utvärderingsmetoder Relationen mellan kvalitativa och kvantitativa metoder

11 Kapitel 1 Inledning 1.1 Bakgrund C2 Management AB bildades 1999 av Lars Nilsson, verksam inom området Ständiga Förbättringar 1. Företaget började som ett management- konsultbolag med syfte att hjälpa andra företag att komma igång med arbetet med Ständig Förbättringar. Företaget utvecklade senare ett system i syfte att fungera som ett stöd samt öka effektiviteten i förbättringsarbetet[1]. Systemet kom att kallas System C2 TM2. Förutom ett antal konsulttjänster inom förbättringsledning, seminarier och konferenser inom verksamhetsutveckling och drift av förbättringsarbete så består C2 Managements kärnverksamhet av uppgifter rörande System C2. Systemet är i korta drag ett ärendehanteringssystem med stöd för ett flertal olika ärendetyper med fokus på kvalitets- och förbättringsverksamhet. System C2s drygt användare finns i skrivandets stund såväl inom stora koncerner som mindre bolag, statliga verk, kommuner och övrig offentlig sektor[1]. C2 Management genomför på regelbunden basis kundundersökningar där kunderna får svara på ett antal frågor rörande systemet och dess kvalitet. Kunderna får då gradera frågans innehåll på en tiogradig skala, resultat sammanställs och man arbetar med de delar där ett icke tillfredställt resultat uppnåtts. Vid ett tillfälle ställdes frågan: Hur användarvänligt tycker ni att System C2 är? Eftersom C2 Management marknadsför systemet som ett särskiljt användarvänligt sådant så förefaller sig frågan naturlig. C2 Management blev dock sedermera inte helt nöjd med resultatet. Det var inte på något sätt dåliga siffror, men C2 Management arbetar som sagt med ständiga förbättringar och punkten föreföll hamna bland de sämre resultaten. Man bestämde sig således att göra något åt saken, vilket leder till uppsatsens syfte. 1 Ett begrepp för att beskriva ett företags eller en organisations kontinuerliga arbete med förbättringar 2 För mer information om System C2 se kapitel 3 6

12 1.2. SYFTE KAPITEL 1. INLEDNING 1.2 Syfte Att genom användarcentrerade metoder, tillsammans med C2 Managements kunder, ta fram förslag på en ny användaranpassad design av System C2. Designen ska stödja identifierade uppgifter samt uppfylla de användbarhetsmål vilka ska vara ett resultat av genomförda fältstudier. 1.3 Mål Uppsatsens mål består bland annat av att undersöka vad användbarhet egentligen är. Om det finns någon tydlig definition och/eller beskrivning av vad ett användbart system ska innehålla och hur det ska utformas. Ytterligare ett mål är att undersöka hur en användarcentrerad utvecklingsprocess ser ut och hur den kan tillämpas i vidareutvecklingen av ett befintligt system. Slutligen finns en målsättning att reda ut vilka typer av utvärderingsmetoder som kan appliceras på ett projekt som detta. Vid tillfället att metoderna kan kategoriseras är målsättningen att minst en ur varje kategori ska genomföras. 1.4 Avgränsningar Fokusera på ärendeflödet och dess steg. Ej utvärdera eventuella ekonomiska konsekvenser. Ej ta hänsyn till hur komplext föreslagna förändringars implementeringsarbete blir. Ej ta hänsyn till företagskundernas specifika preferenser. 7

13 Kapitel 2 Tolkningsram 2.1 Användbarhet Idéer och teorier om vilka faktorer som gör ett system användbart eller inte går i sär ibland områdets mest erkända och kunniga individer. Detta medför att det inte finns någon enhetlig teori att utgå ifrån. Alternativet är att vända sig mot ett antal teorier som alla har en hög relevans där teorigrundarna är överens på många delar men går i sär på vissa. För att ge en så bred och nyanserad bild som möjligt presenteras nedan ett antal teorier och synpunkter på vad användbarhet egentligen är[2] Användbarhet enligt ISO Användbarhet är ett begrepp som är svårt att definiera och mäta. När är egentligen ett system användbart? Vad finns det för krav på användbara system? För att räta ut dessa frågetecken har International Organization for Standardization tagit fram en internationell standard vilken definierar användbarhet (ISO [3]). Gulliksen Göransson skriver om denna standard i sin bok Användarcentrerad systemdesign[2]. Författarna presenterat där ett antal utvalda delar ur rapporten som ska definiera begreppet användbarhet: den utsträckning till vilken en specificerad användare kan använda en produkt för att uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i ett givet användningssammanhang Vidare definieras ändamålsenlighet som: noggrannhet och fullständighet med vilken användarna uppnår givna mål Effektivitet definieras som: resursutgång i förhållande till den noggrannhet och fullständighet med vilken användarna uppnår givna mål och tillfredsställelse definieras som: frånvaro av obehag samt positiva attityder vid användningen av en produkt 8

14 2.1. ANVÄNDBARHET KAPITEL 2. TOLKNINGSRAM Slutligen definieras användningssammanhanget som: användare, uppgifter, utrustning (maskinvara, programvara och annan materiell) samt fysisk och social omgivning i vilken produkten används [2] Fördelen med denna definition är att den gör det möjligt att tala om användbarhet grundat på en gemensam grund och utgångspunkt. Den ger även möjlighet att mäta användbarhet. Man kan titta på utförandet av en uppgift i ett visst sammanhang och jämföra resultatet mot samma uppgift utförd i samma sammanhang men i ett annat system. På så sätt går det att avgöra vilken produkt som är mest användbar [2]. Fördelen med ISOs definition av användbarhet är att den definierar användbarhet i ett mycket bredare sammanhang än vad vi kanske gör i dagligt tal. När gemene man talar om användbarhet tänker han eller hon ofta på användargränssnittet och hur pass lätt det är att använda. ISOs definition går ut på ett bredare plan och tar upp tar upp hela användarupplevelsen, allt ifrån systemets funktionalitet till det visuella (användargränssnittet)[3]. Vidare ger ISO en möjlighet att mäta användbarhet samt konkretisera metoder till stöd för utvecklingsprocessen Användbarhet, en gren av den totala acceptansen Nielsens definition av användbarhet skiljer sig från ISO när det kommer till separerbarheten mellan funktionalitet och användbarhet. Nielsen menar att användbarhet endast är en gren i ett träd som står på en grund han kallar acceptans för systemet. Grenen användbarhet går ihop med grenen funktionalitet som tillsammans bildar den nytta användaren ser av systemet. Nyttan är en gren som sträcker sig ut från den reella acceptansen av systemet, där även saker som kostnader, kompatibilitet och tillförlitlighet ingår. Den reella acceptansen bildar tillsammans med den sociala acceptansen den totala acceptansen av systemet och trädet har då nått sin rot. Användbarhetsgrenen kan i sin tur delas in ett antal attribut som kan användas som ett mått på användbarhet[4]. 1. Lärbarhet 2. Effektivitet 3. Hågkomst 4. Fel 5. Tillfredställelse Det ter sig ganska självklart att ett system som är lätt att lära och komma igång med, även efter en tid, ska kunna bidra till ett effektivt och produktivt arbete. Det ter sig heller inte främmande att ett system som kräver omlärning för varje användningstillfälle sällan blir ett användbart system. Finns möjligheten att också förhindra att användaren gör fel och vid de tillfällen felkontroll är omöjlig, låta användaren ångra sina beslut har ribban lagts högt. Uppnås även en känsla av tillfredställelse finns det inga hinder kvar. I utformningen av ett användbart system kan dessa attribut vara ett stöd i utvecklingsprocessen och leda till ett, ur användbarhetssynpunkt, tillfredsställande resultat [4]. 9

15 2.1. ANVÄNDBARHET KAPITEL 2. TOLKNINGSRAM Lärbarhet, flexibilitet och stabilitet En man vid namn Alan Dix har valt att dela in det som beskriver ett användbart system i tre kategorier: Lärbarhet, flexibilitet och stabilitet.hänvisning lärbarheten är där ett mått på hur lätt det är för användaren att nå toppen av vad systemet presterar. Ett system med hög lärbarhet ska vara förutsägbart i den bemärkelsen att användaren vet om konsekvenserna av sitt handlande. Systemet ska även använda sig av användarens tidigare kunskap, erfarenheter och mentala modeller. Uppfylls dessa krav kommer användaren snabbt igång och kan på kortare tid nå tillräcklig kompetens för att slutföra sina uppgifter. Flexibiliteten beskriver de olika sätt användaren kan interagera med systemet. Under kategorin flexibilitet ingår saker som dialoghantering (för att minska kravet på användarens inmatning) systemets stöd för multitrådning (för att låta användaren utföra flera uppgifter parallellt). Det finns en balansgång mellan vad systemet bör utföra för arbete utan inverkan från användaren. Denna balansgång påverkar användarupplevelsen. Till listan av attribut för ett flexibelt system hör även ersättningsbarheten, det vill säga i vilken utsträckning systemet möjliggör alternativa visningsätt för inmatning. Till sist bör även användarens möjlighet att själv anpassa användargränssnittet beaktas. Under kategorin stabilitet ingår attributen observerbarhet, felavhjälpningsförmåga, svarsförmåga samt uppgiftöverensstämmelse. Observerbarheten beror på i vilken grad systemet möjliggör för användaren att se dess tillstånd. Användaren ska även kunna ångra de fel som denne ofrånkomligen kommer att generera. Tidigare nämnda fall tillsammans med den grad systemet interagerar med användaren samt den grad systemet stödjer användaren i hennes uppgifter och i vilken utsträckning uppgifterna är genomförbara utgör systemets övergripande känsla av kontroll Alla produkter är användbara Ryan Singer är verksam inom det erkänt användarinriktade företaget 37Signals 1. Företaget tillhandahåller i första hand ett antal webbapplikationer och har genom dessa fått ett rykte om sig att utveckla speciellt användbara applikationer. Singer, som är en av utvecklarna på 37Signals, talar dock helst inte om användbara produkter och tycker inte att det ska ses som en komplimang. Han menar att alla produkter och mjukvaror är användbara. I stället ska det talas om ett antal nyckelfaktorer som bidrar till en bra och lättanvänd produkt[5]. Till dessa faktorer hör: Tydlighetet. Ett system ska ha sina klara avgränsningar samt visa på en tydlig struktur och uppdelning för att underlätta sökningen av sidan. Lätthet. Ett system som är lätt anstränger inte användarens kognitiva förmåga, vilket innebär att individen inte behöver anstränga sig i användandet. Snabbhet. En snabb respons är viktigt för att bibehålla användarens intresse. Roligt. En viktig faktor för att användaren skall komma tillbaka och fortsätta använda produkten. Bra. En produkt som är bra är per definition något som är lätt att använda. 1 Mer om deras systemutvecklingsfilosofi på: 10

16 2.1. ANVÄNDBARHET KAPITEL 2. TOLKNINGSRAM [5] En del av en bra produkt är att den är lätt att förstå, att den är klar och har ett tydligt och enkelt flöde. Singer anser att det är viktigt att fokusera på användargränssnittet och dess uppbyggnad eftersom det är det som är produkten för konsumenten; det som kunden ser. Ofta har inte kunden någon kontroll på vad som körs i bakgrunden och är heller inte intresserad av hur alla tekniska bitar är lösta. Det kunden bryr sig om är det kunden ser och kan använda. En funktion som inte används trots att den kanske är väldigt bra och tekniskt avancerad, existerar exempelvis inte i produkten. Singer nämner tre huvudsakliga områden för att uppfylla kraven på en bra mjukvara när 37signals designar ett gränssnitt[5][6]: Sidor Flöde Språk Med sidor menas varje enskild vy i applikationen. Det finns ett antal faktorer som måste integreras när fokus läggs på att göra varje sida så användbar som möjligt. Till dessa faktorer hör bland annat ett designande med klarhet och struktur samt ett fokus på varje enskild del av vyn. När man talar om flöde tänker man på den arbetsgång en viss uppgift har och hur väl varje moment är kopplade till varandra. Det ska flyta på när uppgifterna utförs. Alla onödiga moment ska minimeras och flödet ska vara så naturligt som möjligt. Den tredje och väldigt viktiga delen vilken är värd ett extra fokus är systemets språk. Singer menar att det är människor som skall använda systemet och språket bör därför anpassas efter människan och hennes språk. Det handlar om att formulera termer och begrepp som de används i dagligt tal istället för att använda korta beskrivande fraser, vilket vissa system tenderar att göra. Det krävs dock en noggrann utvecklad process när de begrepp som används på sidan tas fram, då det väldigt lätt kan uppstå begreppsförvirring hos användarna om detta görs godtyckligt. [5] Tvinga mig inte att tänka Steve Krug är högt ansedd och respekterad användbarhetsdesigner som arbetat nästan tjugo år med att göra webbsidor med användbara och lättanvända användargränssnitt åt några av världens största IT-företag. Krug har många gånger fått frågan om vad hemligheten bakom att designa användbara webbsidor är och efter sina många år i branschen har Krug kommit fram till en enkel slutsats: tvinga mig inte att tänka. Han menar att så fort användaren kommer till en webbsida ska den vara uppenbar, självklar och självförklarande. Det ska inte uppstå några frågetecken kring hur sidan är utformad att fungera. I regel tycker inte människor om att tänka och fundera över hur saker och ting ska göras. Det faktum att de som utvecklat systemet inte brytt sig tillräckligt för att göra webbsidans komponenter uppenbara får användarens förtroende för sidan och dess innehåll att sjunka till botten. Det kan ibland anses omöjligt att göra viss funktionalitet självklar, speciellt när det kommer till funktioner med hög komplexitet och/eller originalitet. Slutsatsen är att åtminstone göra sidan helt självförklarande. Det är väldigt viktigt att sträva efter detta mål då enkelheten i användandet bidrar till produktens helhet. Att använda webbsidor som inte tvingar oss att fundera på det oviktiga får användandet att kännas enkelt och bekymmersfritt, medan webbsidor som tvingar oss att fundera över saker blir energitömmande och tidskrävande.[7] 11

17 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM 2.2 Användarcentrerad design Precis som det inte finns någon tydlig definition av vad användbarhet är så finns det inte heller någon definition av vad användarcentrerad systemdesign egentligen innebär. Det finns dock även inom detta område ett flertal teorier och definitioner nedtecknade av några av MDI-områdets experter. Gulliksen och Göransson[2] beskriver sin definition utifrån de tre ord som konstruerar begreppet: användare, centrerad och design. Med användare menas de som systemet konstrueras för och som kommer arbeta med IT-stödet i sitt dagliga arbete. Det finns ofta någon i varje utvecklingsteam som tror sig veta precis vad användarna vill ha, men det finns inget substitut för riktiga användare. Centrerad syftar till på att placera något i mitten och det innebär inte nödvändigtvis användarna måste involveras men utvecklingsarbetet sker alltid med användarna i fokus. Slutligen beskrivs design som ett väldigt vitt begrepp och således krävs en lång beskrivning för att utreda vilken betydelse av design som avses Användarcentrerad design enligt ISO ISO 13407[8] innefattar ett antal riktlinjer för hur den användarcentrerade designprocessen ska utformas. Den beskriver hur införandet av kvalitet kan ske i användandet av interaktiva system genom att tillämpa ett antal steg och metoder som tillsammans bildar det interaktiva systemets livscykel. ISO beskriver fyra olika användarcentrerade aktiviteter som ska inkluderas i utvecklingsprojekt på ett så tidigt stadium som möjligt. Till dessa hör: 1. Förstå och specifiera användarkontexten 2. Specifiera användarkrav samt organisatoriska krav 3. Producera designlösningar 4. Utvärdera designlösningar Figur 2.1: Användarcentrerad design enligt ISO 12

18 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM Första steget handlar om att komma till insikt om vilken typ av användarcentrerad modell som önskas användas i projektet. När det är fastställt fortsätter processen med att ringa in typen av användare och vilka krav de har, men även att ta vara på de organisatoriska krav som finns. Fokus ska inte ligga på funktion utan syftet är att i första hand samla in användbarhetskrav. Dessa användbarhetskrav skall ligga till grund för framtagandet av ett antal användbarhetsmål som senare ligger till grund för de designlösningar som tas fram. Designlösningar som kontinuerligt ska utvärderas av användarna där de får utföra aktiviteter så nära ett verkligt scenario som möjligt. Designaktiviteterna ska utföras iterativt (på nytt) tills det att varje stadium är tillfredsställt. Först då kan cykeln av aktiviteter avslutas.[8] Användarcentrerade processen Gulliksen och Göransson[2] menar att användarcentrerad systemdesign är en process som fokuserar på användare och användbarhet genom hela utvecklingsprocessen. Den här processen kan definieras med hjälp av ett antal nyckelprinciper. Användarfokus. Alla i projektet ska vara insatta i verksamhetens mål, vilka uppgifter och behov som ska vara vägledande i utvecklingsarbetet. Det är viktigt att prioritera vad som är bra för användarna och inte vad som är tekniskt möjligt. Ett bra sätt att behålla ett kontinuerligt fokus på användarna och dess uppgifter är att skapa beskrivningar av typiska användare. Aktiv användarmedverkan i utvecklingen. Användarna bör involveras tidigt i utvecklingsarbetet och följa med kontinuerligt under hela processen. Det är viktigt att veta om skillnaden på domänexperter och systemets verkliga användare. Domänexperter anses vara väl insatta i verksamheten men ej representativa för hela användargruppen och är lämpliga att involveras under hela utvecklingsprojektets gång medan de verkliga användarna endast bör vara involverade vid tillfälliga aktiviteter som utvärderingar. Evolutionär utveckling. De designlösningar som tas fram under projektets gång bör itereras kontinuerligt över de aktiviteter som projektet innehåller. Inkrementell utveckling bör också tillämpas vilket innebär en stegvis utveckling av systemet uppdelat i inkrement som vart och ett leder till verklig användning. Gemensam och delad förståelse. Språket som används i de dokument som tas fram ska ligga så nära användarnas som möjligt. För att ge användarna eller kunden en inblick i utvecklingsarbetet bör detta konkretiseras med hjälp av designpresentationer i form av prototyper med mera. Prototyping. Prototyper bör komma in i processen vid ett tidigt skede och fungera som ett stöd för den kreativa processen. Prototyperna bör i början utformas på en låg nivå till exempel i form av pappersskisser och bara visa på den konceptuella designen för att efterhand gå in mer och mer på detalj. Utvärdera verklig användning. Specificera användbarhetsmål som grundar sig på undersökningar hos verkliga användare. Låt sedan dessa användbarhetsmål ligga till grund för utvärderingen av prototyper. Explicit och uttalade designaktiviteter. Utvecklingsprocessen skall innehålla medvetet planerade designaktiviteter för att inte låta designen uppstå från ingenstans. Användargränssnittet är produkten för 13

19 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM kunden. Tvärdisiplinära team. Utvecklingen ska ledas av effektiva team med en bredd av kompetenser. Tvärvetenskapliga team är viktiga för att försäkra ett effektivt arbetssätt. Användbarhetsförespråkare. En användbarhetsexpert ska integreras tidigt i projektet. Han eller hon kan driva den användarcentrerade processen. Denna person ska fungera som en förespråkare för användarna och systemets användbarhet. Integrerad systemdesign. Alla delar i systemet ska utvecklas parallellt och beroende av varandra. Användargränssnitt och interaktion, hjälpdokumentation, handböcker, utbildning etcetera. Detta måste ske tillsammans med en ansvarig person. Lokalanpassa processerna. Processerna kan behövas anpassas efter organisationen och projektets krav. Organisationen bör själva definiera sin egen designprocess, antingen efter en kommersiell process eller efter en egenutvecklad sådan. En användarcentrerad attityd. En användarcentrerad attityd bör etableras från början i utvecklingsprojektet. Med nyckelprinciperna nämnda ovan i åtanke kan processen för användbarhetsdesign läggas ut som en rad hopkopplade aktiviteter. Dessa aktiviteter är i sin tur grupperade i tre efterföljande huvudfaser: kravanalysen, den evolutionära utvecklingen och slutligen införandet. Den här processen är tänkt att utföras iterativt och tillsammans med andra utvecklingsprocesser och återfinns i figur 2.2. Till en början läggs ett stort fokus på den inledande fasen kravanalys. Denna fas är en viktig del i utvecklingsarbetet då den är grunden projektet står på; att gå tillbaka och omarbeta kravanlysen så fort någon större förändring sker. Även kravanalysen bör vara iterativ eftersom det är vanligt att krav och behov ändras under arbetets gång. Med fastlagda mål och krav på en rimligt hög nivå förs utvecklingsarbetet i rätt riktning. Fokus bör läggas på: verksamhetsmål, användargrupper, användarnas mål, arbetsuppgifter och behov samt ta fram mål som ligger till grund för det fortsatta arbetet. Nästa fas i processen är den evolutionära utvecklingen där det tydligt går att urskilja tre spår, nämligen: Konceptuell design, interaktionsdesign samt detaljerad design. Genom att gå genom dessa spår kommer systemet växa fram och ta en mer detaljerad form. Tanken är dock inte att gå genom spåren sekventiellt utan arbetet bör ske parallellt. Dock är det bra att börja med den övergripande konceptuella designen och gå vidare utifrån den. Den sista och avslutande fasen är införandet, vilket ofta handlar om att introducera systemet i verksamheten och sätta det i drift. Det ska finnas manualer och support att tillgå. Rör det sig om en kommersiell produkt innefattar införandet även produktpaketering och lansering etcetera. Införandet måste ske på ett säkert och kontrollerat sätt. Det går inte att dumpa produkten på kunden och förvänta sig att den kommer att användas. Därför kräver införandet en noggrann planering och bör föras in tidigt i utvecklingsarbetet. 14

20 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM Figur 2.2: Den användarcentrerade processen 15

21 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM Efter varje fas och efter varje spår i den evolutionära utvecklingen ska en användbarhetsguide tas fram. Det är en så kallad style guide som är unikt framtagen för ett specifikt utvecklingsprojekt och ska innehålla de delar av utvecklingen som är viktiga för systemets användbarhet. Gulliksen och Göranson[2] har tagit fram en förteckning på vad de tycker att en användbarhetsguide ska innehålla(sida): Anpassning av den användacentrerade processen Plan för användarmedverkan Övergripande beskrivningar av målsättningar med systemet och dess funktionalitet Användarprofiler och/eller personas Kontextuell uppgiftsanalys Plattform-/tekniska beroenden och begränsningar Användbarhetsmål Designbeslut och kriterier Användningsscenarier Konceptuell design Interaktionsdesign, navigering och informationsstruktur Detaljerad design av användargränssnittet Återkoppling och utvärdering Design-artefakter(förklaring) Planer för användarbarhetsutvärderingar och rapporter Peoble Activities Context Technologies Den interaktiva designprocessen kretsar runt fyra huvudsakliga områden. Områden som i ett interaktivt system har en nära relation. En förutsättning för att designa ett användbart system är att förstå sambandet och relationen mellan dessa fyra områden: Människor(People) Aktiviteter(Activities) Kontext(Context) Teknologier(Technologies) 16

22 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM Relationen återspeglas i alla situationer då en människa använder någon form av teknologi. Detta förhållande kan enkelt illustreras med hjälp av ett exempel från vardagen. Något vi gör regelbundet av olika anledningar är att ta ut pengar från bankomater. Att människan tar ut pengar från bankomaten bildar en aktivitet. Bankomaten befinner sig på gatan vid sidan av en vältrafikerad gågata, vilket symboliserar kontexten där människan utför sin aktivitet och allt detta med hjälp av teknologin bestående av bankomaten. Benyon, Turner och Turner skriver om detta förhållande i sin bok Designing interactive systems[9]. De beskriver bland annat hur de fyra områdena är sammankopplade med varandra likt en cykel som varje designer måste förstå och arbeta efter. Cykeln beskrivs enligt följande: Aktiviteterna utförs inom en kontext, vilket leder till olika krav på teknologin människan interagerar med. Teknologin presenterar sedan ett antal möjligheter som förändrar de framtida aktiviteterna. Figur 2.3: Poeple Activities Context Technologies Vi människor är olika. Vi ställer olika krav, har olika förutsättningar och föredrar olika saker när det kommer till teknologi. Det finns psykologiska skillnader som man måste ta hänsyn till när man designar ett system. Vi har olika bra minne och spatial förmåga. Det finns kulturella och språkliga skillnader. Vi har olika förutsättningar när det kommer till användandet av ett syfte. Vissa är expertanvändare och behärskar de flesta tekniker i interaktionen med tekniken medan andra har det svårare och bara klarar av det mest grundläggande. Det finns en mängd variabler när det kommer till att förstå människan och dess behov. I grund och botten handlar det om att hitta minsta gemensamma nämnare och sedan designa efter dem. När det kommer till att designa system efter de aktiviteter systemet ska stödja finns det ett antal faktorer att tänka på. Först och främst ska fokus läggas på det huvudsakliga syftet hos en aktivitet. Därefter ska det fokuseras på följande egenskaper aktiviteterna har: Tidsaspekter Samarbeten Komplexitet Säkerhetskritiska Sammanhanget 17

23 2.2. ANVÄNDARCENTRERAD DESIGN KAPITEL 2. TOLKNINGSRAM Tidsaspekter innefattar bland annat hur ofta en aktivitet utförs. Saker som utförs ofta måste vara lätta att utföra och innebära så lite kognitivt arbete som möjligt. De uppgifter som utförs mindre frekvent har krav på sig att vara lätta att lära samt att komma ihåg. Många arbetar i miljöer där avbrott sker frekvent. Därför måste designen tillåta avbrott i arbetet och när användaren kommer tillbaka ska det vara möjligt att fortsätta där senaste avbrottet ägt rum. Tidsaspekter innefattar även den responstid ett system har. Ett system med lång responstid får användaren att känna sig försatt i väntan, vilket leder till irritation. Det handlar i grund och botten om att hålla användaren sysselsatt och aktivt arbetande i systemet. Samarbeten är en annan viktig aspekt i de olika aktiviteterna systemet stödjer. Problem med medvetenhet om andra, kommunikation och koordination blir då oerhört viktig. Komplexiteten som ligger i olika uppgifter är självklart skiftande men i de mest komplexa situationer där olika typer av information måste inhämtas, ställs det krav på systemets flexibilitet och möjlighet att låta användaren röra sig fritt i systemet. I säkerhetskritiska moment eller uppgifter är det viktigt att det inte ska vara möjligt att göra oåterkalleliga misstag. Designern måste ha i åtanke att om en användare kan göra fel, så kommer felet att inträffa förr eller senare. Systemet ska designas efter det sammanhang användandet sker. Kontexten kan sammanfattas i tre olika typer, fysiska, sociala och organisatoriska. Den fysiska kontexten har stor påverkan på interaktionen mellan människan och tekniken. Det kan handla om hur ljudnivån, temperaturen och platsen påverkar hur ett tänkt IT-stöd skall fungera. Alla fysiska egenskaper ställer olika krav på utformningen av systemet. Den sociala kontexten där aktiviteten utförs är hur systemet kommunicerar med användaren med hjälp av alla våra sinnen. Hur olika moment beskrivs och hur systemet stödjer användaren i form av hjälpsidor, manualer etcetera. Den organisatoriska kontexten kan beskrivas i hur den nya tekniken påverkar olika led i organisationen vilket resulterar i diverse krav på utformningen av IT-stödet. Den sista och långt ifrån minsta delen i PACT-modellen beskriver tekniken och dess olika delar. Tekniken kan katigoriseras in i ett antal viktiga delar:(sid) Input Output Kommunikation Innehåll Vid designen av ett system kan ett flertal inputmetoder användas. Det kan röra sig om touchscreens, enkla knappsatser, röststyrning, tangentbord etcetera. Vilken metod som väljs beror på mängden av information som ska matas in och vilken typ av data som ska in i systemet. Likt inputen bör outputen väljas med tillförsikt. Det gäller att välja ett eller flera tillvägagångssätt som kan leverera tillräckligt med information och respons utan att trötta ut användarens sinnen. Kommunikationen är en viktig del i tekniken. Som tidigare nämnts är det viktigt att hålla användaren sysselsatt. När detta av olika anledningar inte går, måste det kommuniceras på något sätt, det gäller att visa aktivitet i systemet. Det ställs även krav på innehållet när det kommer till utformning, språk, aktualitet etcetera. En del system ställer mindre krav på innehåll, i vissa fall krävs det inget innehåll, medan andra förväntar sig mycket av innehållet och dess kvalitet. [9] 18

24 2.3. PROTOTYPER SOM ETT STÖD I UTVECKLINGEN KAPITEL 2. TOLKNINGSRAM 2.3 Prototyper som ett stöd i utvecklingen För att konkretisera de krav på systemet som framkommer under användarstudierna används så kallad prototyping, vilket inte ska förväxlas med prototyper av den typen som visar ett första utkast av en färdig produkt. Prototyping handlar istället om att med hjälp av enklare prototyper, i olika steg i den iterativa utvecklingsprocessen, utvärdera detaljer i en viss funktionalitet eller vissa gränssnittsmässiga delar. Trelager-arkitekturen med sina egenskaper: användargränssnitt, logik och data erbjuder ett fokus på olika delar i utformandet av en prototyp beroende på vilken målsättning som finns. Det kan väljas att göra en så kallad vertikal prototyp där fokus ligger på samtliga lager i modellen vilket erbjuder utvärderarna möjligheten till interaktion tillsammans med systemet det tänkta systemet. Vertikala prototyper är tacksamma när det kommer till användarsamverkan eftersom användarna får möjligheten att utföra och testa verkliga arbetsuppgifter. Är önskemålet istället att fokusera på till exempel användargränssnittet kan en så kallad horisontell prototyp användas, vilken bara rör sig i det översta skiktet i trelager-arkitekturen. [2] Prototyper kan tas fram för att fylla en mängd olika syften. Beroende på utformning: om prototypen är vertikal eller horisontal lägger den sig olika nära funktionaliteten, utseende/beteende och implementation. Detta förhållande beskrivs i figuren nedan. De grå punkterna i figuren ska representera olika typer av prototyper och hur de ligger till i förhållande till respektive område. Figur 2.4: Prototyper av olika aspekter Högupplösta prototyper Högupplösta prototyper ligger väldigt nära den slutliga produkten, men kan sakna en del av funktionaliteten. Implementeringen av prototypen går så långt så att det är möjligt att interagera med den. Dessa prototyper har följande egenskaper: Är användbara när tester av de huvudsakliga designelementen utförs (tester kring innehåll, utseende, funktionalitet etcetera). De är ett viktigt steg i att få kundens acceptens då denna prototyp ligger väldigt nära den slutgiltiga produkten. De tas oftast fram i slutfasen av en utvecklingsprocess då de flesta idéer har rotat sig om hur den slutgiltiga produkten ska se ut. 19

25 2.4. TEKNISKA VERKTYG KAPITEL 2. TOLKNINGSRAM Ett problem med den här typen av prototyp är att kunden eller användarna tenderar att se den som den slutliga produkten. Detta ställer höga krav eftersom en funktion som inte fungerar på rätt sätt i ett system, kunden tror är en slutlig produkt tenderar att göra kunden eller användaren missnöjd med prototypen. Detta medför att det krävs både kraft och tid i utvecklingen av en sådan prototyp Lågupplösta prototyper Den vanligaste typen av lågupplösta prototyper är så kallade pappersprototyper, vilket är som namnet förtäljer prototyper eller skisser nedtecknade på papper. Den här typen av prototyper har följande egenskaper: Fokus ligger på de breda underliggande designidéerna som innehåll, form samt struktur. Designade för att produceras med i lika hög frekvens som de kastas. Ska produceras i ett tidigt skede av designprocessen och fungera som ett stöd i utvärderingen av många möjliga designlösningar. Den här typen av prototyper erbjuder utvärderarna möjligheten att hitta designmissar i ett tidigt skede, men ger dock inte lika stor möjlighet att testa funktionaliteten i systemet. [2][9] 2.4 Tekniska verktyg Det finns idag tekniker som underlättar utvecklandet av användbara system. En av de största revolutionerna inom webbutveckling var den dagen Ajax tog sin plats på scenen. Ajax är inget nytt programmeringsspråk eller ett nytt komplext sätt att utforma webbapplikationer. Det är snarare ett sätt att kombinera ett antal redan kända tekniker för att uppdatera webbsidor asynkront (olika tillfällen). Ajax har många fördelar för användarupplevelsen, något som tas upp nedan. ytterligare en teknik som underlättar webbaserade användargränssnitt är Cascading Style Sheets(CSS), ett sätt att separera de grafiska egenskaperna från de innehållsmässiga delarna, vilket är en egenskap som är önskvärd i utvecklandet av användargränssnitt Asynchronous Javascript och XML Traditionella webbapplikationer tenderar att uppfattas som väldigt långsamma då det vid varje tillfälle logiken hos applikationen måste nås krävs kommunikation med webbservern. När operationen är genomförd skickas informationen tillbaka till användaren och sidan laddas om med den nya informationen. Den här typen av lösning medför långa väntetider. Det är således önskvärt att hålla ned kommunikationen med servern, eftersom den påverkar applikationens möjligheter till interaktivitet.[10] Ajax eller Asynkront JavaScript råder bot på detta problem. Tekniken tillåter data, innehåll och design att bli sömlöst sammankopplade. Med Ajax sker uppdateringar och requests i bakgrunden utan att sidan behöver laddas om eller uppdateras. Detta möjliggörs genom JavaScript som binder samman ett antal komponenter vilket är en kombination av XHTML och CSS standardiserad presentation, förändring i sidans grafiska representation genom DOM, datarepresentation med hjälp av standardiserad 20

26 2.4. TEKNISKA VERKTYG KAPITEL 2. TOLKNINGSRAM XML och XSLT och till sist XMLHttpRequest för dataöverföring.[10] För att ge en bild över skillnaden mellan traditionella webbapplikationer och de som använder sig av AJAX presenteras det i figuren nedan skillnaden i de olika applikationsmodellerna. Den traditionella modellen bygger på att en http request skickas till webbservern som kommunicerar med aktuella processer och bakomliggande system. Resultatet skickas sedan tillbaka i form av HTML och CSS för presentation hos klienten. Ajax skiljer sig genom att modellen innehåller ett bakomliggande lager som sköter alla http requests. Detta lager befinner sig fortfarande hos klienten, vilket möjliggör en dynamisk uppdatering av gränssnittet utan att applikationen måste ladda om eller uppdatera hela sidan. Nyckeln till lösningens syfte ligger helt enkelt i Ajax-motorns möjlighet att interagera med webbservern utan att påverka användargränssnittet och att kommunikationen med servern inte är beroende av en aktiv handling från användaren.[11] För att ytterliga förtydliga vinsten av att använda sig av Ajax-baserade tekniker återfinns figur 2.5(b) nedan som visar hur användaraktiviteten påverkas med hjälp av det på klientsidan mellanliggande lagret. Figuren visar även hur start och stopp i användaraktiviteten elimineras genom att låta Ajaxmotorn ta hand om serverkommunikation samt grafiska förändringar. (a) Skillnaden mellan traditionell och ajaxbaserad webbapplikationsmodeller (b) Användaraktiviteetsjämförelse mellan de olika webbapplikationsmodellerna Figur 2.5: Figurerna beskriver Ajax-teknikens tekniska lösning samt vinsten med tekniken. 21

27 2.5. ANALYSMETODER KAPITEL 2. TOLKNINGSRAM Cascading Style Sheets CSS används tillsammans med HTML för att beskriva en webbsidas utseende. Medan HTML-dokumentet beskriver innehållet är CSS-dokumentets eller stilmallens uppgift att beskriva hur denna information ska grafiskt presenteras för användaren. Dessa stilmallar importeras i början av HTML-dokumentet och innehåller ett antal regler som styr hur sidans element ska se ut. Det finns tre typer av stilmallar som påverkar sidans grafiska utseende, nämligen: webbläsarmallar, användarmallar samt författarmallar. Webbläsarmallen är de standardmallar alla webbläsare använder sig av. Dessa kan variera från webbläsare till webbläsare men har det flesta egenskaper gemensamt. Användarmallar är en typ av mallar som användaren själv applicerar på sidan. Denna mall går före standardmallen men bara för den enskilt aktuelle användaren. Överst i hierarkin av mallar ligger författarmallen som författaren av sidan själv har skapat. Denna mall går före alla andra mallar, dock så används de andra mallarnas egenskaper då ett visst elements egenskaper inte definierats i författarmallen. Det sker alltså en form av seriekoppling av mallar, därav namnet Cascading. [12] Fördelarna med att använda CSS i webbaserade projekt är bland andra: [12] Underlättande av underhåll - Utseendet på flera webbsidor kan beskrivas med hjälp av ett enda CSS-dokument till skillnad från att definiera den grafiska representationen i varje enskilt HTML-dokument. Minska filstorlekar - Genom att plocka bort kod som beskriver utseende från HTML-filerna möjliggörs drastiska minskningar i filernas storlek, laddningstider kan på så sätt hållas ned. Ökad tillgänglighet - Genom välstrukturerad HTML-kod och separata stilmallar underlättas användningen av hjälpmedel som textuppläsare eftersom det möjliggör att användaren endast behöver författa sig med det välstrukturerade innehållet. Olika media - Olika CSS-mallar kan användas beroende av vilken typ av media som presenterar webbsidan. Större typografisk kontroll - CSS möjliggör en större kontroll över samtliga HTML-element. 2.5 Analysmetoder För att förstå vad kunden och användarna av systemet vill ha så är det ett måste att ta reda på vilka typer av användare systemet är ämnat för samt vilka uppgifter användarna ska utföra i systemet. Finns det ingen förståelse för detta kommer produkten vara något som utvecklats av och för dem som programmerat och designat systemet. Utan användarnas inflytande kommer man inte att kunna möta deras krav och förväntningar på ett meningsfullt sätt[2]. Genom att på olika sätt interagera med användarna kan det samlas in information om deras erfarenheter, uppgifter, användningsmiljö och organisation. Syftet är att med hjälp av användarna ta reda på vad det har för uppgifter, hur, varför och när de utför dem. När dessa frågetecken rätats ut kan en diskussion leda till lösningar av eventuella problem samt ge förslag på vad göras bättre i framtida utveckling. [13][9] 22

28 2.5. ANALYSMETODER KAPITEL 2. TOLKNINGSRAM Användaranalys Användaranalysen ska resultera i ett antal användarprofiler som beskriver de olika typer av användare som skall arbeta i systemet. Dessa profiler ska svara på frågor om personers datorvana, ålder, roll i organisationen etc. Användarprofilerna kan sedan delas in i olika användarkategorier som svarar på vilka egenskaper dessa har. Det kan röra sig om graden av vana att utför en viss uppgift, vilken utbildning användarna fått, hur ofta IT-stödet används, i vilken miljö det används, om det rör sig om användare med fysiska hinder och så vidare. [2][9] Det finns olika tillvägagångssätt för att svara på dessa frågeställningar. Det kan bland annat lösas genom enkätundersökningar, intervjuer och observationer. När någon eller några metoder för informationsinsamlingen är valda och genomförda kan det resultera i ett antal designrekommendationer och kravspecifikationer som ska ligga till grund för utvecklingen av systemet. Det finns även andra metoder för att komma åt den här informationen i de fall ingen direkt tillgång till användare finns. Det är dock inget som kommer tas upp mer i detalj i den här rapporten. [2][9] Uppgiftsanalys Syftet med uppgiftsanalysen är att få svar på ett antal frågor om vilka uppgifter som ska utföras i systemet och på vilka sätt dessa uppgifter utförs. Det är viktigt med den här typen av analys för att kunna kartlägga de uppgifter användarna ska utföra i systemet. Nästa steg är att utveckla funktionalitet som stödjer arbetet med de uppgifter som identifierats. Görs inte detta på ett användaranpassat sätt kommer funktionaliteten inte att användas. En risk med att blanda in för mycket funktionalitet i början är att det viktiga och mest nödvändiga funktioner drunknar i de övriga. För att ta reda på vilka uppgifter som ska stödjas bör det genomföras intervjuer och/eller observationsstudier där varje uppgift och deluppgift kartläggs. Resultatet av uppgiftsanalysen tillsammans med användaranalysen blir då ett bra underlag för den fortsatta designprocessen. Efter uppgiftsanalysen är det viktigt att definiera tydliga användbarhetsmål för det utvecklade systemet. Detta för att ha något att sträva mot och ha med sig i den fortsatta utvecklingen. [2][9] Personas Personas är framtagna hypotetiska användare som ska respresentera en typisk användare av systemet och är en produkt av en undersökande process där användarnas mål och behov fastställts. Användargränssnittet ska sedan designas så att användarnas mål kan bli nådda samt behov bli tillfredsställda. Användarnas mål och behov sammanfattas i personas för att underlätta för designers i utformandet av gränssnittet då det ofta är lättare att nå en specifik användares behov till skillnad från en stor grupps. Det rekommenderas att profilera användaren genom att ge denne ett antal tekniska färdigheter för att visa på nivå av teknisk kompetens samt ge användaren ett antal personliga egenskaper. En fingervisning är att försöka hålla ner antalet användarprofiler till mellan tre och fem. 23

29 2.6. UTVÄRDERINGSMETODER KAPITEL 2. TOLKNINGSRAM 2.6 Utvärderingsmetoder För att göra den användarcentrerade utvecklingen meningsfull bör man arbeta utifrån ett antal metoder. Det finns en uppsjö metoder att välja bland och de har olika egenskaper. En metod lämpar sig olika bra beroende på graden av användarmedverkan, tidstillgång och vilket skede i utvecklingsprocessen projektet befinner sig. Adelmein och Reidel har identifierat tre kategorier för klassificering av utvärderingsmetoder. Figuren nedan visar denna klassificering.[14] Figur 2.6: Metodklassificering Tabellen nedan illustrerar vilka metoder som kan tillgås och när det är lämpligt. [14] Användarmedverkan Tidskrav- och insatskrav Klassificering Kognitiv genomgång Medel Subjektiv/empirisk Intervjuer X Medel Subjektiv Fokusgrupper X Medel Subjektiv Tänka högt X Medel Empirisk Observationer X Låg Empirisk Frågeformulär X Hög Subjektiv Scenarios X Medel Empirisk Funktionsbaserad X Hög Empirisk Checklistor Medel Heuristisk Heuristisk Medel Heuristisk Tabell 2.1: Utvärderingsmetoder Detta är bara en handfull av de utvärderingsmetoder som existerar idag. Det kan vara svårt att veta vilken eller vilka metoder som lämpar sig bäst, men det kan bero på följande faktorer: Var i livscykeln projektet befinner sig Uppgiftens karaktäristik 24

30 2.6. UTVÄRDERINGSMETODER KAPITEL 2. TOLKNINGSRAM Användarnas karaktäristik Produkten eller systemet i sig De begränsningar som påverkar projektet Vilken grad av expertis som projektteamet besitter Utvärderingar är viktiga eftersom dessa leder till upptäckten av fel, vilka om de förblir oupptäckta, kan innebära stora ekonomiska konsekvenser längre fram. De bästa typer av utvärderingsmetoder är metoder som involverar användare i processen. Det förefaller sig dock så att det vanligen utförs utvärderingar utan användarnas medverkan. Till detta finns ingen anledning då det alltid finns användare att tillgå. Ett annat vanligt problem är att utvärderingarna endast leder till upptäckten av användbarhetsproblem men inte hittar hur problemen ska lösas. [2] Heuristisk Den vanligaste typen av utvärdering är den så kallade heuristiska utvärderingen, även kallat expertutvärdering. Denna typ av utvärdering består i att ett antal experter på användbarhetsområdet systematiskt går igenom systemets delar efter antal fördefinierade principer, guide lines eller heuristiker för bra design. Användarheuristiker bygger på psykologiska, teoretiska och praktiska erfarenheter insamlade av experter i området.[9] I det flesta fall är det svårt för en ensam utvärderare att utföra den här typen av utvärdering. Det beror på att en person troligtvis inte kommer att kunna ringa in samtliga användbarhetsproblem som existerar i systemet. Det bästa är att involvera flera personer med erfarenheter i området. Det har visat sig att olika utvärderare tenderar att hitta olika typer av användbarhetsproblem. Hur många utvärderare som bör involveras beror på hur väl utvärderingen ska göras, men redan vid fyra stycken hittar gruppen närmare 75 procent av alla användbarhetsproblem (till skillnad från cirka 30 procent som ensam utvärderare). Förhållandet mellan antal problem funna samt antal utvärderare illustreras i figur 2.7.[15] Figur 2.7: Figuren beskriver förhållandet mellan antal funna användarproblem mot antal utvärderare. 25

31 2.6. UTVÄRDERINGSMETODER KAPITEL 2. TOLKNINGSRAM Många användbarhetsproblem är så pass uppenbara att det näst intill blir en omöjlighet att missa dem medan andra problem är sådant de flesta utvärderare missar. Därför kan det krävas flera utvärderare med olika specialiteter för att hitta de mest svåridentifierade problemen. Således krävs det i de flesta fall fler än en enda utvärderare. En fördel med den här typen av utvärdering är att den inte ställer några krav på utvärderarnas förkunskap om själva systemets funktion eller användningsområde. I en heuristisk utvärdering är det utvärderarnas uppgift att utvärdera användargränssnittet och identifiera olika problem eller möjligheter. Den som dokumenterar behöver inte tolka användandet och de handlingar användaren utför för att senare hitta problemen, något som ofta görs i traditionell användarutvärdering. En annan skillnad från traditionell utvärdering är att det finns en större möjlighet att hjälpa utvärderarna med att svara på frågor och ge ledtrådar under utvärderingen, då det inte kan förväntas att de ska kunna hantera systemet fullt ut. Till skillnad från att med riktiga användare, som använder systemet i sitt arbete, där det istället är önskvärt att undvika ge information om hur användandet av systemet ska ske, just för att kunna identifiera problemen. I och med den heuristiska utvärderingen sparas det mycket tid, energi och i förlängningen även pengar. En annan fördel med heuristiska utvärderingar är att de kan utföras på tidiga prototyper av systemet så som pappersskisser eftersom utvärderarna ändå inte är ämnande att använda och utföra uppgifter i systemet. Resultatet av en heuristisk utvärdering ska vara en lista på ett antal användbarhetsproblem. Samtliga problem bör listas så detaljerat som möjligt. Exempelvis om en komponent i designen besitter flera användbarhetsproblem bör alla listas separat och inte samlas under samma användbarhetsproblem. [15] Intervjuer En av de mest effektiva metoder för att samla in användarnas krav och synpunkter är att helt enkelt tala med dem. Det finns olika typer av intervjutekniker att använda sig av, vilka innefattar: Strukturerade intervjuer. Bygger på frågor konstruerade före intervjutillfället som sedan följes strikt genom hela samtalet. Ett sådant upplägg gör att intervjun blir förhållandevis lätt att genomföra, men gör det svårt för den som genomför intervjun att ställa uppföljande frågor på oväntade svar. Semistrukturerade intervjuer. Ett antal frågor eller ämnen som önskas täckas in i intervjun formuleras i förväg innan tillfället och dessa frågor följs upp av frågor och svar. Den här typen av intervju ställer lite större krav på den som håller i samtalet eftersom anteckningar måste föras och genomtänkta följdfrågor måste konstrueras i realtid. Ostrukturerade intervjuer. Den här typen av intervju har, som namnet förtäljer, ingen färdig struktur och inga förberedelser sker före samtalet. [9] Intervjuer är relativt tids- och insatskrävande och kräver därför noggranna förberedelser. Detta för att svaren ska innehålla de svar som önskas och på så sätt undvika att behöva gå tillbaka till respondenten 26

32 2.7. FORSKNINGSTEKNIKER KAPITEL 2. TOLKNINGSRAM vid ett senare tillfälle för att ställa kompletterande frågor. Att använda bandspelare för att spela in intervjutillfället är inte alltid det bästa alternativet då detta kan hemma respondenten [16]. Det har även i undersökningar framkommit att inget av relevans förbises om endast vanliga anteckningar förs ned[13] Tänka högt. Så kallade tänkahögt -metoder innebär att användaren får arbeta och utföra uppgifter i systemet samtidigt som användaren beskriver den interna kognitiva processen, alltså beskriver vad denne tänker varför denne gör på ett visst vis etcetera. Den här typen av metod kan ge mycket hjälpsam information i form av indikationer på användbarhetsproblem. Exempelvis vid tillfällen undersökningsobjektet inte klarar av att utföra en uppgift kan denne komplettera med information om varför denne inte kommer vidare. Det är dock viktigt att ta i beaktande att objektet måste kommentera användandet innebär att den kognitiva processen i viss mån störs. [9] 2.7 Forskningstekniker Induktiv eller deduktiv forskningsansats Man kan tillämpa två huvudsakliga typer av angreppssätt på ett vetenskapligt problem nämligen genom: deduktion eller induktion. Deduktion innebär att man formar hypoteser som avhandlingen ska testa och slutligen leda till ett resultat. Induktion innebär att man utifrån verkligheten sluter sig till mer generella teorier och modeller. [17] Kvalitativ eller kvantitativ studie Beroende av vilka typer av frågor som önskas ställas, typer av svar som förväntas och vilka typer av variabler som spelar in så väljs en passande teknik i de empiriska studierna. Den kvalitativa studieteknikens avsikt är att uttyda och förstå ett eller flera fenomen. Frågor som ställs i samband med en kvalitativ studie innehåller ofta frågeorden: vem, vad, hur, varför, när och var. Svaren förväntas bestå av ord och satser. Variabler som tas i beaktning är av typen: kön, yrke, civilstånd, yrke, utbildningslinje etc. [18] Kvantitativa ansatser syftar ofta till att grovt mäta och förklara ett förhållande. Den insamlade datan som är ett resultat av kvantitativa undersökningar omsätts ofta till siffror och mängder för att ligga till grund för statistiska analyser. Frågorna som ställs i en kvantitativ undersökning är därför anpassade för detta. Frågeställningarna blir därför av en kvantitativ natur, där svaren kan mätas i reella tal. Även variablerna som tas i beaktning är av det slag att de går att mäta med siffror och mängder. Tabell 2.2 synliggör skillnaden mellan metoderna. [18] 27

33 2.7. FORSKNINGSTEKNIKER KAPITEL 2. TOLKNINGSRAM Kvalitativa Kvantitativa Frågor: vem, vad, hur, varför, hur mycket, hur när, var många, hur ofta, i vilken grad Svar som ges: ord och satser reella tal Variabler: Kön, yrke civilstånd, vikt, längd, ålder, hemort, antal, årsinkomst, utbildning, slag av avstånd, kunskapsmängd kunskaper Tabell 2.2: Relationen mellan kvalitativa och kvantitativa metoder Validitet och reliabilitet För att forskningsresultaten ska ha ett vetenskapligt värde ställs särskilda krav på de metoder och tekniker som används i undersökningarna. Metoderna och teknikerna måste vara reliabla och valida för att vara lämpliga i arbetet. Validitet är ett mått som beskriver hur väl något beskriver sanningen. Lägen där det kan uppstå en tvekan kring en förklarings validitet är då forskaren inte undersökt alternativa förklaringar utan endast förlitar sig på en enskild källa [19]. En annan förklaring av validitet är att det verkar som ett mått på hur väl exempelvis en mätmetod speglar verkligheten [16]. Det handlar om att ha klara mått och mätmetoder som är avsatta för att mäta det som önskas mätas och att dessa förhållanden inte förändras för något som ämnas att jämföras med tidigare mätningar. En forskningsstudie kan inte utge sig för att vara valid då: Bara en eller ett fåtal instanser av resultatet påträffats. Endast kriterier eller grunder för att en särskild metod används och inte varför andra inte valts. Grunderna till påståenden eller förklaringar inte är tillgängliga. [19] Reliabiliteten är ett mått på hur mycket tillförlitlighet som kan läggas hos ett mätinstrument eller en måttenhet och hur tillförlitligt resultatet av en mätning är [16]. Ett exempel där resulterande reliabilitet tenderar att bli låg är i kvantitativa undersökningar. Trots att kvantitativa forskare lutar sig mot förtestade mätningar och skalor kan mätningarna nå ett högst otillförlitligt resultat. Detta på grund av att medverkande i kvantitativa undersökningar tenderar att tolka frågorna på olika vis. I kvalitativa undersökningar finns möjligheten, till skillnad från kvantitativa, att säkerställa konsensus och följa upp med följdfrågor. [19]Reliabilitet har alltså att göra med en specifik mätningskvalitet där reliabiliteten är ett mått på vilken grad undersökningen kan återupprepas och samtidigt nå samma resultat. 28

34 Kapitel 3 System C2 TM 3.1 Användningsområde System C2 är ett verktyg för att underlätta och stödja arbetet med ständiga förbättringar, något som varje ISO-certifierat företag har krav på sig att arbeta med. Systemet är därför utformat för att på ett enkelt sätt ge användarna en möjlighet att genom en väl definierad och genomtänkt process driva igenom förbättrings- och kvalitetsfrågor. På så sätt kan effektiviteten i verksamhetsutvecklingen även öka kontinuerligt. Systemet stödjer ett flertal olika ärendetyper som alla till största del följer System C2s flöde. Det finns även möjlighet att ta fram organisationsspecifika företagslösningar för att bättre passa en unik verksamhet. Nedan presenteras några ärendetyper som C2 hjälper företag och organisationer att arbeta med: Förbättringsförslag Avvikelser (ex. produktion, produkt) Reklamationer Kundsynpunkter/medborgarsynpunkter Interna och externa revisionsavvikelser Leverantörsavvikelser Incidenter Olycksfall/tillbud/arbetsskador Support och helpdeskärenden Felanmälningar Projekt 29

35 3.2. FLÖDET KAPITEL 3. SYSTEM C2 TM De flesta ärendetypers funktionalitet i systemet har utvecklats genom C2 Managements affärsmodell att låta kunderna driva utvecklingen av system C2. Det är alltså upp till varje enskild kund vid det tillfälle utveckling måste ske för att exempelvis anpassa systemet efter sin egen organisation, att finansiera utvecklingen. Utvecklade komponenter eller funktionalitet ska sedan, i enlighet med affärsmodellen, vid efterfrågan från övriga kunder tillhandahållas utan någon extra kostnad. I och med denna modell kan alla kunder dra nytta av utveckling som finansierats av andra, vilket driver hela systemet framåt med och för alla kunder. De företagskunder som är drivande i utvecklingen får även en känsla av ägandeskap, vilket leder till en lojalitet till produkten. 3.2 Flödet C2 följer ett naturligt flöde som grundar sig på PDCA-cykeln och dess fyra steg: planera, gör, studera och lär. I planeringsfasen definieras problemet och de bakomliggande orsakerna. Det tas även fram lämpliga lösningar på problemet. I efterföljande steg genomförs de lösningar som tagits fram i föregående steg. Studerandefasen består i sin tur av genomgångar av de åtgärder som tagits fram för att kontrollera om åtgärderna lett till önskad förbättring. Det slutgiltiga steget består i att dra lärdomar av resultatet.[20] System C2 omsätter PDCA-cykeln i en enkel process bestående av fyra huvudsakliga steg. Utifrån detta flöde kan det härledas ett processflöde som beskrivs i figur 3.1: Nytt Besluta Göra Följa upp 30

36 3.2. FLÖDET KAPITEL 3. SYSTEM C2 TM Figur 3.1: System C2s processflöde 31

37 3.2. FLÖDET KAPITEL 3. SYSTEM C2 TM Som tidigare nämnts så tillhandahåller System C2 ett flertal olika ärendetyper framtagna och utvecklade för att passa varje individuell organisations förbättringsarbete. Det merparten av ärendetyperna har gemensamt, och som även är något C2 Management strävat efter, är att de alla följer samma grundläggande flöde, med vissa avvikande variationer. De flesta ärenden ser alltså ut på det sätt som illustreras i figur 3.1. Nytt ärende En användare börjar med att registrera ett nytt ärende i systemet. Man gör detta genom att välja nytt ärende och tas sedan till sidan för registrering av nya ärenden med någon ärendetyp som grundinställning. Det finns som redan nämnts ett flertal olika typer av ärenden med skillnaden i mängden och typen av obligatorisk inmatning. Det kan röra sig om allt ifrån långa formulär med flertalet inmatningsfält (exempelvis registrering av arbetsskada) till kortare formulär (exempelvis registrering av ärende gällande kundsynpunkt) där endast ett fåtal inmatningsfält existerar. Sedan väljer inlämnaren antingen vem ärendet ska gå till för beslut eller så sker ett automatiskt urval beroende på vilket område man valt och vilken målvakt 1 som står vid respektive område. Det finns även ett antal övriga funktioner i det här steget, funktioner som antingen kan vara aktiva eller inte. Det kan röra sig om möjligheten att sprida information om ärendet till andra eller möjligheten att göra en gruppinlämning, att välja redan genomfört eller redan beslutat med mera. Möjligheterna och variationerna är många. Besluta När inlämnaren anser sig färdig med ärendet skickas det till beslutaren för beslut. Vid detta skede får beslutande person ett e-postmeddelande med en medföljande länk som tar honom/henne direkt till beslutsteget i det aktuella ärendet. Här står beslutaren inför ett antal val. De primära valen består i att genomföra, lägga ned eller utreda, till det sekundära valen hör bland annat: senarelägga, vidarebefordra, ändra ärende, kommentera. När beslutaren väl valt något av ovanstående primära alternativ, och även vissa av de sekundära alternativen, fyller denne i en kommentar för att beskriva beslutet. Väljer beslutaren att genomföra ärendet fyller denne även i vilket datum det ska vara genomfört och av vem ärendet ska genomföras. Nedläggning Vid valet nedläggning motiverar vanligen beslutaren beslutet, men möjligheten att sprida ärendet till andra finns också här. Annars går endast ett e-postmeddelande med information om beslutet till inlämnaren och ärendet stängs. Utredning Vid utredning får utredande person ett e-postmeddelande innehållande information om ärendet som ska utredas. När utredande person är klar med sin utredning går ärendet tillbaka till den person som beslutat om utredningen. Genomförande Även vid detta skede av processen får den nu ärende- eller genomförandeansvarige ett e-postmeddelande med detaljer om ärendet samt en direktlänk till rätt steg i flödet för det aktuella ärendet där ärendet 1 Person som är avsedd att hantera ärenden som placerats under en given kategori. 32

38 3.3. ÖVRIGA FUNKTIONER KAPITEL 3. SYSTEM C2 TM beskrivs och ärendeansvarig kan välja bland ett antal alternativ där det primära är klarrapportera ärende vid slutfört uppdrag och där de sekundära alternativen består av: senarelägga, vidarebefordra, ändra ärende, kommentera och så vidare. Vid en klarrapportering fyller genomförandeansvarige i en kommentar och låter ärendet gå tillbaka till uppföljning. Uppföljning Uppföljningen genomförs i normalfallet av inlämnaren då inlämnaren är känd, vilket fallet inte alltid är, exempelvis vid kundsynpunkter. Det finns även fall där både inlämnare och beslutare följer upp och även att endast beslutare eller endast genomförare. Personer som berörs av uppföljning får hursomhelst även i detta steg ett e-postmeddelande med vad som hänt i ärendet och en länk som ska ta dem till uppföljningssteget. När uppföljaren sedan väl är inne i ärendet ska ett beslut tas som kan variera beroende av konfiguration, men i normalfallet består det av två alternativ, nämligen svaret på frågan om det blivit bättre: ja eller nej. Vid ett ja stängs ärendet och man tas tillbaka till översiktsidan. Vid ett nej går antingen ärendet tillbaka till beslutssteget eller så stängs ärendet utan åtgärd. 3.3 Övriga funktioner Till System C2 hör även ett antal andra funktioner som underlättar arbetet med och hanteringen av den ärendemängd som kan genereras i en stor organisation. Man kan med dessa verktyg ta hand om den information systemet tillhandahåller. Till dessa funktioner och verktyg hör: Arkiv - Arkivet innehåller egentligen en avancerad sökmotor som letar reda på ärenden med hjälp av frågor, utformade efter ett givet urval, till databasen och presenterar sedan urvalet i form av en lista ordnad på ett givet vis. Statistik - Statistikhanteringen bygger egentligen på samma typ av teknik som arkiv använder sig av. Rapporter - Innehåller ett antal fördefinierade sökningar i databasen som kan presenteras på olika vis. Administration - Administrationen finns till för att låta de användare med rätt behörighet bland annat lägga till och ändra inställningar bland användare. Till administrationen hör också bland annat möjligheten att ta ut listor samt ändra systeminställningar. 3.4 Tekniken System C2 är och har tidigare varit ett organiskt växande system vilket gått från plattform till plattform. Till en början utvecklades systemet för att köras i Lotus notes vilket är en applikation som i första hand stöder e-post, snabbmeddelanden och kalenderfunktion men även har stöd för att bygga databaser, vilket var något som drogs nytta av. Man gick sedan vidare till att köra systemet som en lokal applikation parallellt med framtagningen av ett nytt sätt att använda systemet. Man utvecklade möjligheten att köra applikationen helt som en webbapplikation på ett antal fjärrplacerade servrar i syfte att underlätta service, support, tillgänglighet etcetera. 33

39 3.4. TEKNIKEN KAPITEL 3. SYSTEM C2 TM Arkitektur Systemet är uppbyggt efter en lagerarkitektur där databasen, logiken samt användargränssnitt är uppdelade i tre separata lager. Detta medför ett antal fördelar så som ökad prestanda, flexibilitet, skalbarhet och återanvändbarhet. Möjligheten att distribuera processorkraft och resursanvändning blir stor och det faktum att varje lager blir utbytbart och kan ersättas med annan teknik utan modifiering i de andra lagren är en klar fördel. Den största vinsten för utvecklingen av System C2 finner man i att denna struktur medför en skalbarhet något som är en vital egenskap i ett organiskt växande system. Figur 3.2: Trelagerarkitektur Det översta lagret i modellen representerar användargränssnittet med de funktioner som det tillhandahåller, alltså det som presenteras för användaren samt den direkta interaktion användaren har med systemet. Översta lagret har transparenta kopplingar till mellanlagret som tillhandahåller processhanteringen i systemet, en viktig del i hanteringen av multipla klienter. Med en centraliserad processorkraft och hantering ökas möjligheten till administrering och uppdatering genom den lokaliserade systemfunktionaliteten. Det tredje lagret, databaslagret, tillhandahåller databashantering så som strukturering och sökning av data. Databasen är helt transparent för processorlagret och har dynamiskt antal kopplingar till mellanlagret beroende på antal förfrågningar efter data från användaren. Idealbilden är att inga direkta kopplingar mellan första och tredje lagret (databas och användargränssnitt) finns utan att allt går genom mellanlagret. Det har dock visat sig inte fungera fullt ut i praktiken, vilket har medfört att vissa genvägar mellan lagren idag måste finnas Teknisk lösning Systemet består av ett antal webbservrar där alla kunder har sina egna databaser för datalagring samt en applikation som använder sig av CGI-protokollet, vilket är ett sätt för en extern applikation att kommunicera med en webbserver. I standardfallet får webbservern en request via http att visa en output. Det kan antingen vara en fil på servern eller ett kommando som ska exekveras(köras) i en applikation, generera en output som sedan ska presenteras. CGI definerar en standard för hur information och kommandon skickas mellan applikation och server. I System C2 skickas information av tre typer till applikationen. FROM CMD SID 34

40 3.4. TEKNIKEN KAPITEL 3. SYSTEM C2 TM När användaren genererar en request till servern skickas dels ett FROM-meddelande som talar om varifrån(vilken sida) användaren kommer ifrån dels ett CMD-meddelande som innehåller de kommandon som ska utföras i applikationen och till sist ett sessions-id(sid) Som talar om vilken session användaren står. FROM och SID jämförs med varandra som en extra säkerhetsåtgärd i bekräftandet att användaren verkligen kommer från där denne påstår sig komma ifrån. Om FROM och SID stämmer överens tar applikationen emot informationen som kontrollerar rättigheterna hos användaren och i de fall där de kommandon som skickas passar inom ramen för vad användaren får göra, exekveras kommandon som skickats. En output genereras och skickas tillbaka till webbservern, som i sin tur vidarebefordrar den genererade outputen för tolkning hos klienten. Detta gäller logikdelen i systemet, som även hämtar och lagrar data i databasen beroende på vilken handling som ska utföras. Vad det gäller klientdelen eller användargränssnittet och det översta lagret i tre-lager-arkitekturen så byggs dessa upp med hjälp av så kallade HTT-filer som i grund och botten är ett antal villkorssatser. Beroende på vilka inställningar kunden har valt och beroende på hur HTT-filen är konfigurerad genereras html- och javascriptskod för tolkning hos klienten Anpassningsbarhet System C2 har ett stort krav på anpassningsbarhet från sina många kunder. Dessa krav är inte uttalande, men för att kunna tillfredsställa alla kunders olika behov är det ett måste med ett flexibelt och anpassningsbart system. När systemet exekveras startar inläsningen av de så kallade INI-filerna eller initieringsfilerna. Dessa filer innehåller varje kunds unika preferenser hur systemet ska presenteras. Det finns ett antal typer av INI-filer samt en så kallad HLP-fil eller hjälpfil. Alla INI-filer har en speciell hierarki för att avgöra vilka inställningar som ska gå före vilka. Initieringsfilen som befinner sig överst i hierarkin innehåller inställningar för enheter, alltså inställningar som är enhetsspecifika och gäller för alla som ingår i enheten. Nästa fil i hierarkin är den kundspecifika filen där inställningar specifika för kunden samt att i slutet av denna fil görs ett inkluderingsanrop som pekar på början av en standard INI-fil där inställningar som alla kunder har lagras. En annan typ av INI-fil finns till för att anpassa texter som visas på sidan. Slutligen läses även den så kallade HLP-filen in vilken är en fil innehållande texter som visas i hjälp-dialogerna som presenteras för användaren vid förandet av muspekaren över särskilda objekt med popup-egenskaper aktiverat. 35

41 Kapitel 4 Genomförande Kapitlet innehåller detaljer rörande hela projektets genomförande, allt från förberedande studier till vetenskapliga angreppssätt. Metoderna som används under projektet genomsyras av de teorier och den metodik som tas upp i kapitel Förberedelsefas Som ett inledande steg gjordes en litteraturstudie inom Människa-datorinteraktion, användbarhet, forskningsmetodik samt uppsatsskrivning. Detta gjordes för att få en fördjupad kunskap om teorierna inom området människa-datorinteraktion samt grundläggande kunskaper inom forskningsmetodik och uppsatsskrivning. Litteraturstudien genomfördes med stöd från diverse biblioteksresurser, artikeldatabaser samt internetkällor. Med tanke på företaget C2 Management ABs typ och inriktning krävdes även en fördjupande kunskap om företagets arbete och affärsidé, då det inte funnits någon som helst förkunskap i området. För att erhålla nödvändig grundkunskap genomfördes ett antal samtal med företagsrepresentanter, läsning av litteratur, deltagande i flertalet seminarier inom kvalitets- och förbättringsverksamhet. Seminarierna gav även en bra möjlighet att få en första kontakt med System C2s användare och en inblick i vad dessa användare har för krav och önskemål i sitt arbete med förbättringar. Vidare gjordes en djupdykning i System C2 för att få kunskap kring systemet; allt från övergripande funktionalitet till detaljer kring systemarkitektur och tekniska lösningar. Information kring den övergripande funktionaliteten inhämtades från informanter på C2 Management, medan information angående teknisk lösning inhämtats från en representant från det företag som står för System C2s utveckling. 4.2 Heuristisk utvärdering För att fastställa och ringa in befintliga användbarhetsproblem i dagens implementation av System C2 har bland annat en så kallad heuristisk utvärdering genomförts. Valet av antal utvärderare gjordes efter Nielsens riktlinjer och forskningsbaserade rekommendationer, där det har fastställts att uppemot 75 procent av alla användbarhetsproblem identifieras med hjälp av fyra utvärderar eller mer. Fler än 36

42 4.3. FÄLTSTUDIER KAPITEL 4. GENOMFÖRANDE fyra till fem utvärderare tillför inte tillräckligt med kunskap mätt i identifierade problem jämfört mot kostnad. Med den här informationen som grund genomfördes utvärderingen med hjälp av fyra personer med erfarenheter från området människa och datorinteraktion. I hopp om att komma åt samtliga typer av användbarhets problem valdes utvärderarna efter personlighet och bakgrund för att uppnå en så mångfacetterad bild av systemet som möjligt.[15] Varje utvärderare tilldelades vid starten av utvärderingen varsitt dokument innehållande ett antal heuristiker i syfte att vara ett stöd i arbetet med utvärderingen. Heuristikerna som valdes var Nielsens tio användarheuristiker vilka är ett antal grovt övergripande riktlinjer som ger stort tolkningsutrymme och användes för just det specifika syftet: att hitta övergripande problem i designen sett från ett användarperspektiv. För att även fånga upp de användbarhetsproblem som ligger på ett mer detaljerat plan användes Designheuristiker 2005 vilka är ett antal riktlinjer beskrivna med en större detaljrikedom. I de fall där andra heuristiker går att applicera på systemet uppmuntrades utvärderarna att ta dessa i beaktning och även framföra dessa åsikter.[21][22][23] Utvärderingen började med att utvärderingsförrättaren gick igenom systemet steg för steg och beskrev dess olika delar, funktionalitet och syfte, allt med fokus på ärendeflödet och dess olika steg. Det lades även en del fokus på att beskriva användarna och användargrupperna, vars arbete systemet stödjer. Genomgången syftade till att ge en bakgrund kring systemets användande och funktionalitet för att på ett mer relevant sätt kunna ge feedback om systemets eventuella problem. Vidare fick var och en sätta sig ned och individuellt inspektera systemets användargränssnitt, detta för att minimera individernas ömsesidiga påverkan, hålla ned färgning av varandras åsikter och funderingar. När alla utvärderare slutfört den individuella utvärderingen samlades samtliga för att diskutera genom vad var och en funnit för användbarhetsproblem. Genomgången av gränssnittet skedde först en gång för att ge en övergripande bild i hopp om att ringa in de övergripande problemen, och även en andra gång för att granska varje del och komponent av systemet i detalj. Diskussionen var helt öppen samtidigt som utvärderingsförrättaren förde ned relevanta åsikter. Diskussionen utgick hela tiden från systemets användargränssnitt där utvärderarna systematiskt gick genom varje del av gränssnittet med heuristikerna som diskussionsunderlag. Utvärderingen resulterade slutligen i ett antal punkter där designen brutit mot de fördefinierade heuristikerna, punkterna kategoriserades under Bengt Sandblads designheuristikers[23] olika kategorier. 4.3 Fältstudier För att samla in användarnas krav och mål samt få en djupare förståelse för dem genomfördes fältstudier ute på ett antal företag valda efter ett antal specifika kriterier. Dessa fältstudier bestod av intervjuer, observationer samt tillfällen för respondenterna att tänka högt och simultant utföra uppgifter i systemet Intervjuer För att avgöra vilken typ av informanter som skulle användas vid varje intervjutillfälle började arbetet med att bestämma vilken arbetsaktivitet som i första hand skulle representeras i prototypen. För att bestämma aktiviteterna eller uppgifterna ställdes ett antal frågor: 37

43 4.3. FÄLTSTUDIER KAPITEL 4. GENOMFÖRANDE 1. Vilken är arbetsaktiviteten prototypen ska stödja? 2. Hur passar detta arbete in i kundens arbetsliv? 3. Vilka andra är med i arbetet för att få det att fungera? Med vilka sker ett samarbete? 4. Vilka tar fram informationen som krävs för att arbetet ska genomföras? 5. Vilka är nyckeluppgifterna dessa människor genomför som prototypen ska stödja? Svaret på dessa frågor visade på intervjuförrättarens nuvarande kunskap om arbetsgruppen och avgjorde även vilka typer av respondenter som valdes ut. Eftersom det sedan tidigare valts ett fokus på ärendeflödet och dess steg valdes ett antal användare ur tre huvudsakliga användargrupper med olika kunskapsnivå och användarfrekvens som alla har direkt kontakt med ärendeflödet. För att komma i kontakt med användare ur varje användargrupp användes ett antal nyckelinformanter som även stod som kontaktpersoner till C2 Management. Önskemål om vilka typer av respondenter framfördes och kontaktpersonerna tog sedan kontakt med lämpliga användare för ändamålet. Dessa valde att ställa upp frivilligt på intervjuer och i vissa fall även tänka-högt-sessioner. Det avtalades sedan en tid med respektive kontaktperson för enstaka eller flertalet intervjuer. Varje intervjutillfälle inleddes med en kort presentation av vem som skulle leda intervjun och med en presentation av projektets fokus, varför det är viktigt och slutligen hur respondenten kan dra egen nytta av intervjun. När ett antal praktiska angelägenheter retts ut, så som tidsåtgång och inspelning, kunde intervjun äga rum. Ett antal öppningsfrågor ställdes till stöd för uppgifts- och användaranalysen. Vidare genomfördes en semistrukturerad intervju med ett antal förberedda frågor eller ämnen som diskussionen kretsade kring.[13] Användar- och uppgiftsanalys Användar- och uppgiftsanalysen togs fram genom de intervjuer och fältstudier som genomförts under arbetets gång, där en del av intervjuns frågor kretsade kring vilka användarna var samt respektive användares egenskaper. Uppgiftsanalysens underlag kommer från de observationer, intervjuer och tänkahögt-sessioner vilka genomförts under fältstudierna. För att åstadkomma en användaranalys bestod, som sagt, varje intervju av en del med frågor för att ringa in respektive intervjuobjekts egenskaper. Det ställdes frågor kring respektive användares datorvana, ålder och roll i organisationen. Intervjuerna behandlade även frågor kring arbetsmiljö, utbildningsnivå, både vad det gäller akademisk nivå samt aktuell utbildningsnivå i systemet. Frågornas svar resulterade sedan i en del av användarprofilerna eller de personas som skapats i ett senare skede. Uppgiftsanalysen grundade sig huvudsakligen på tänka-högt-metoden där respektive användare, i utförandet av olika uppgifter, uppmanades att tänka högt och beskriva vad de gör och varför det tar den specifika typen av beslut. Sessionen resulterade slutligen i en analys där varje uppgift och deluppgift kartlades för att ge en överblick över systemets krav på uppgiftsstöd. Även den här analysen är en del av användarprofilerna som skapats i ett senare skede. 38

44 4.4. URVAL KAPITEL 4. GENOMFÖRANDE Tänka högt och observationer Ett antal av intervjuerna genomfördes med så kallade tänka högt -sessioner där respondenten fick i uppdrag att utföra ett antal uppgifter i systemet samtidigt som denne talade om vad hon gör och varför hon gör det. Allt för att ge en bild över hur användarna verkligen arbetar med systemet och vilka funktioner som används och inte används. Sessionen började med att granska den enskilde användarens översiktssida där möjligheten att fritt kommentera vilka delar som används, förståelsen för ikoner, symboler och färger. Vidare ombeddes vederbörande respondent skapa ett nytt ärende med sig själv som beslutare. Varje steg gicks sedan successivt genom del för del. Vid särskiljt intressanta tagna beslut eller andra avvikande beteenden kompletterades dokumentationen med svar på frågor som: Varför gör du det? Hur gör du det? Varför inte så här? Blir det ibland fel när du gör så? Vad händer om det blir fel? Tänka högt-tillfället tog sig form av en blandning mellan intervju, observation och handlandebeskrivning. Samtidigt som verksamheten fortskred spelades både ljud och datorns skrivbord in för senare analys. Analysen genomfördes för varje enskild respondent och sammanfattades under ett antal användbarhetsproblem. 4.4 Urval System C2 har en stor mängd användare hos ett stort antal företagskunder. Att ordna en intervju med samtliga kunder inom ett så pass tidsbegränsat projekt som detta sågs som en omöjlighet och ett urval bland företagen var därför ett måste. Det existerar även ett antal utvärderingsmetoder vid utvärdering av befintliga system, ett urval bland dessa metoder ansågs därför också ofrånkomligt Företagskunder Gulliksen Göransson[2] skriver om ett antal riktlinjer för urval av användare. Enligt dessa riktlinjer önskas ett slumpmässigt och stratifierat urval. Engagerade användare med social kompetens som kan få med sig gruppen i arbetet är en förutsättning. Urvalet kan även baseras på representanter av olika användargrupper så deras krav inte går till spillo under arbetets gång. Medverkan måste vara frivillig samt kunna ske anonymt. De skriver även om att utföra lämplighetsprövning utav olika kandidater, något som dock kommer att bortses ifrån på grund av tids- och resursbrist. Tillit läggs istället hos de kontaktspersonernas förmåga att plocka ut användare som passar det givna urvalet. Urvalet skal bestå av användare i olika nivåer i så väl beslutsfattandet som i användarfrekvensen av systemet. 39

45 4.5. FRAMTAGANDE AV PROTOTYPER KAPITEL 4. GENOMFÖRANDE För att avgöra vilka specifika företag som ska bistå med respondenter har det tagits fram, i diskussion med Lars Nilsson från C2 Management, ett antal företag som uppfyller nedan listade kriterier. Företaget ska: 1. Vara drivande i utvecklingsarbetet av System C2. 2. Inneha engagerade och kunniga kontaktpersoner. 3. Använda specifika ärendetyper som följer System C2s flöde. 4. Kunna tillhandahålla användare med olika kunskapsnivå samt frekvens i arbetet med systemet som verktyg. Kriterium nummer ett måste uppfyllas då det är dessa företag som är villiga att finansiera eventuella utvecklingskostnader för de förbättringar som tas fram i projektet. Nummer två är relevant för att säkerställa kvaliteten i intervjuerna samt att dessa företag troligtvis har lättare att se den egna vinningen med intervjuerna. Det uppfyller även Gulliksen och Göranssons konstaterande med engagerade användare. Kriterium nummer tre är fastställt med anledning av projektets huvudsakliga fokus. Slutligen har kriterium nummer fyra tagits fram för att underlätta arbetet med att hitta användare från samtliga skilda användargrupper Utvärderingsmetoder Som tidigare nämnts finns det idag ett antal utvärderingsmetoder med olika egenskaper. I hopp om att ringa in samtliga användbarhetsproblem har ett antal olika utvärderingsmetoder används i arbetet. Alla med olika karaktäristik och indelning i Adelmeins och Reidels klassificering av utvärderingsmetoder[14]. För att infria inställningen att använda någon/några metod/metoder i varje kategori har en heuristisk, en subjektiv samt en empirisk metod valts, både med och utan användarmedverkan. 4.5 Framtagande av prototyper I arbetet med att ta fram en ny prototyp av System C2 har ett användarcentrerat arbetssätt tillämpats. Ett arbetssätt som grundar sig på den internationella standarden ISO 13407[8]. Nedan beskrivs på vilket sätt denna modell/process anpassats för att passa projektet Anpassad användarcentrerad process Projektet har alltså utgått från ISO och har i största möjliga mån följt varje steg i cykeln. Det slutgiltiga steget har dock inte ännu uppnåtts på grund av diverse faktorer, där den huvudsakliga faktorn varit tidsbrist. För att göra det möjligt att arbeta efter denna standard har en användarcentrerad process nedtecknad av Göransson Gulliksen[2] tillämpats. I och med att processen är anpassad efter ett helt nystartat projekt och att den är anpassad efter utvecklingsteam har ett antal anpassningar varit nödvändiga. Även tidsaspekter har spelat in när det kommit till att anpassa processen. 40

46 4.5. FRAMTAGANDE AV PROTOTYPER KAPITEL 4. GENOMFÖRANDE Under arbetet med framtagandet av prototypen har det endast utförts två iterationer, som ett direkt resultat av tidsbristen som råder i ett projekt som detta, vilket kan ses som en nackdel. Processen har även anpassats i den mån att varje steg i processen inte genomförts utan prioriterats bort för att ge utrymme åt mer kritiska delar. I figur 4.1(a) visas vilket steg i processen arbetet med prototyperna avslutats. (a) De steg i den användarcentrerade processen vilka projektet genomfört (b) Fullständiga användarcentrerade processen Figur 4.1: Jämförelse mellan projektets genomförandeprocess samt Göranssons och Gulliksens användarcentrerade process. I enlighet med Göranssons och Gulliksens[2] beskrivning av den användarcentrerade processen inleddes arbetet med en fullständig kravanalys där det bland annat ingick bakgrundsstudier bestående av medverkan vid flertalet seminarier, föreläsningar och kunddagar, allt i hopp om att förstå verksamheten bättre. I kravanalysen ingick även de fältstudier som utförts ute hos företagskunder och de från fältstudierna framtagna användarprofilerna. Tillsammans låg dessa delar till grund för ett antal användbarhetsmål framtagna i syfte som stöd för fortsatt utvecklingsarbete. Med användbarhetsmålen som grund påbörjades den evolutionära utvecklingen. Där togs en konceptuell design fram och den ledde senare till en första prototyp i form av en detaljerad digital pappersdesign. Denna prototyp utsattes sedan för en heuristisk utvärdering för att komma åt de användbarhetsproblem som fortfarande fanns kvar. Prototypen korrigerades i nästa steg där extra tonvikt lades på interaktionsdesignen, där det ur utvärderingar och utveckling trädde fram en ytterligare prototyp. Vid det här stadiet avstannade utvecklingen av ytterligare prototyper på grund av tidsbrist. 41

47 4.6. VAL AV ANGREPPSPUNKT KAPITEL 4. GENOMFÖRANDE 4.6 Val av angreppspunkt För att styra arbetet mot en önskad riktning och samtidigt kontrollera innehållet, har ett antal forskningstekniker tillämpats. Forskningsteknikerna består av en vetenskaplig del: induktiv forskningsansats, samt en metodisk del: Kvalitativ ansats. Detta för att klargöra efter vilka premisser som studien kommer att genomföras Deduktiv forskningsansats För denna uppsats har en deduktiv forskningsansats tillämpats, detta för att i största möjliga mån exkludera förutfattade meningar bland annat om vilka användbarhetsproblem som finns idag. Alltså har inga hypoteser i ämnet skapats utan istället sluts en litteraturstudie, för att kartlägga de teorier som finns i ämnet, till de empiriska studier som genomförts under arbetets genomförande Kvalitativ studie Ett mål med uppsatsen är att kartlägga de användbarhetsproblem som finns i System C2 idag. Kartläggnigen ska inte endast ske genom heuristiska utvärderingar utan även genom empiriska studier bland aktiva användare. Således har ett val mellan kvalitativ eller kvantitativ studie gjorts, vilket resulterat i beslutet att endast ett kvalitativt angreppssätt tillämpats då detta passat bäst för det aktuella syftet. 42

48 Kapitel 5 Resultat 5.1 Heuristisk utvärdering Skärmdisposition Utnyttjandet av fixerade och välplanerade positioner är av skiftande kvalitet. På översiktssidan nyttjas den yta man har att tillgå på ett bra sätt då den fylls ut av information och lämnar inget outnyttjat utrymme. Eftersom sidan är anpassad efter att visas med så pass låg upplösning som 640 pixlar i bredd kan sidorna uppfattas som att innehålla mycket tomt utrymme. Utrymmet som blir över vid högre upplösningar skulle kunna utnyttjas till någon form av funktionalitet eller innehåll. Det finns dock delar av systemet som inte utnyttjar stora delar av skärmen, till dessa hör bl.a. Rapporter och Arkiv. I exempelvis arkivet finns det ingen anledning att inte ha maximerade listor och även visa verktygsfältet för att anpassa listan. Om anpassad lista ska visas från början beror på om den används ofta. Om det inte hör till vanligheten att den används bör det läggas mindre fokus på den dialogen och istället koppla den till tabellen för att visa att den påverkar utritandet av tabellen och inget annat. Rapportmodulen visar också på bristfälligt utnyttjande av utrymme. Modulen skulle kunna kompletteras med hjälpdialoger eller liknande. Vidare disponerar varje steg i flödet sidorna väl. Något som är en direkt konsekvens av tekniken som ligger bakom utritandet av grafiken 1. Markerandet av viktiga delar samt att definiera separerade huvudområden görs i viss mån, men inte tillräckligt tydligt. På översiktssidan visas varje enskild tabell tydligt avskilda från varandra. Det är dock inte tillräckligt klart vilken tabell som beskriver vilka ärenden. Texter med mindre relevans och ramar i tabellerna medför ett brus, vilket gör det ansträngande för användarna att urskilja det viktiga. Menyn på vänstersidan är tydligt avgränsad och vilken del som är avsatt för navigering råder det inget tvivel om. Tittar man på sidan för att skapa nya ärenden är den indelad i tre huvuddelar där den första delen representerar själva beskrivningen av ärendet samt förslag på lösning. Andra delen visar de alternativ och val som är kopplade till ärendetypen och tredje alternativet de verkställande alternativ som finns att tillgå. Dessa tre delar separeras med hjälp av horisontella avgränsare. Dessa avgränsare tillför inget av nytta till användarupplevelsen, snarare tvärtom. Det är inte tillräckligt med utrymme mellan innehåll och avgränsare vilket gör att det perceptuella (upplevda) bruset ökar och 1 För mer information om den tekniska lösningen, se sektion

49 5.1. HEURISTISK UTVÄRDERING KAPITEL 5. RESULTAT gör sökningen av sidan svårare. Här bör man jobba med att införa mer luft eller utrymme och satsa på tydligare avgränsare med rubriker. De fält som inte är satta som obligatoriska kan minimeras och samlas under en enskild del som kan expanderas vid behov. Mycket av avgränsningsproblematiken kommer tillbaka i nästa steg i flödet, nämligen beslutsteget. Även här byggs gränssnittet upp med ett antal delar, en valdel för att bestämma vilket beslutet är, en del för att föra in kommentarer, en för att skicka formulär, två icke-interaktiva delar som beskriver ärendet samt en historikdel med vad som hänt hittills i ärendet. Bristerna ligger som tidigare nämnts i luften eller utrymmet mellan avgränsningar, men här finner man även ett större användbarhetsproblem i hur ärendet presenteras. Det är inte tillräckligt tydligt vilka delar som är interaktiva och förväntar sig någon form av input detta en direkt konsekvens av hur ärendet ritas ut på skärmen. Det är viktigt att se skillnaden mellan ren information och de delar som förväntar sig någon form av interaktion tillsammans med användaren. En lösning är att arbeta med färger och presentera informationen på ett annorlunda sätt. Även att plocka bort onödiga detaljer och lägga mindre fokus på oviktiga delar. Den här problematiken återkommer i övriga steg i flödet och bör behandlas på samma sätt i följande steg för att skapa en kontinuitet i användandet. Något som också bör ses över är hur figuren som presenterar flödet placeras. Det naturliga för människan är att söka sidan uppifrån vänster hörn och röra sig diagonalt nedåt mot nedre högra hörn. Det resulterar i att ovana användare som inte är medvetna om figuren och dess funktion missar den helt. Det råder ingen tvekan om att det är en väldigt bra figur med en användbar funktionalitet för att visa var man är i ärendet, det anses därför oerhört angeläget att placera figuren på ett sådant sätt den uppfattas Orientering och navigering Största identifierade användbarhetsproblemet när det kommer till orientering är att det inte visas tillräckligt tydligt var man befinner sig, både när man befinner sig i ett ärende samt när man utnyttjar någon av de övriga funktionerna. Det bör vara tydligare var man kommer ifrån och hur man tar sig tillbaka. Detta kan lösas med hjälp av så kallade brödsmulor 2 vilka visas i en lista varje steg man tagit i navigeringen. Orienteringsproblemet vid ärendehanteringen är att sidornas rubriker är satta till rubriken på ärendet det gället. Det är inte nödvändigtvis fel att göra på det sättet men på grund av att figuren som beskriver ärendeflödet lätt förbises(se sektion 5.1.1) tappar man greppet om vad det är man förväntas göra. Antingen visar man var man är i ärendet på ett tydligare sätt eller så fortsätter man med att beskriva det med hjälp av figuren men omarbetar den och dess position för att förtydliga meningen med den. I omarbetningen bör man även väva in någon form av indikation om var man hamnar i nästa steg. En förklaring av detta visas i dialoger när man väl verkställt en förändring i ett ärende men användaren bör vara medveten om vad som ska hända i nästa steg redan när denne befinner sig i steget före. För att låta användaren hela tiden vara medveten om var denne befinner sig i sidstrukturen bör det visas var man befinner sig både på översiktsplanet men även det detaljerade planet. Användaren bör aldrig tappa greppet om hur denne hittar tillbaka och, när denne befinner sig inom en huvuddel, hur man hittar till en annan huvuddel. För att tillfredställa dessa behov kan man införa så kallade globala 2 Användandet av brödsmulor är ett sätt att visa användaren var denne kommer från, hur långt ner i sidans trädstruktur användaren befinner sig samt möjligheten att navigera tillbaka i sina egna spår 44

50 5.1. HEURISTISK UTVÄRDERING KAPITEL 5. RESULTAT menyer där huvuddelarna är presenterade och för varje del ha en mer detaljerad meny med alternativ för just den huvuddelen. Det bör läggas en tonvikt på att visa om det finns mer information att tillgå, även när den inte är synlig vid det aktuella tillfället. Det här problemet blir aktuellt vid exempelvis popup-dialogerna, där ytterligare information om bland annat ärenden presenteras. Nuvarande indikation består av att muspekaren ändrar utseende i form av ett frågetecken. Det är en bra indikation, men i vissa fall kanske det ska visas trots att inte muspekaren förs över området. Som en konsekvens av att dessa popuper är så pass vanligt förekommande bör ett övervägande göras om det är lämpligt med en tydligare indikation, då vinsten blir för liten jämfört med röran sådana indikationer medför. Vid de tillfällen det blir väldigt många ärenden på översiktssidan som det kan bli för vissa och vid de tillfällen ärenden blir väldigt långa beroende på ärendets omfattning eller historikens längd bör man fundera på att införa flikar eller bläddring för de olika delarna, detta för att i största möjliga mån undvika att tvinga användaren att skrolla. Det är mer ansträngande för användaren att behöva skrolla upp och ned i en sida till skillnad från att bläddra genom delarna, detta resonemang kan befästas med hjälp av Fitt s lag som matematiskt beskriver förhållandet mellan antal klick och musrörelser och tidsåtgång Kontroll och feedback Kontroll och feedback är en oerhört viktig aspekt när det kommer till användbara interaktiva system, för att helt enkelt låta användaren få känslan av interaktivitet och trygghet i vad man gör. Så fort systemet utför något som händer utanför användarens kontroll eller vetskap tappar denne snabbt känslan av trygghet och kontroll vilket gör att man finner användarupplevelsen mindre bra. Återkopplingen i System C2 är god i många fall. Den består bland annat av en indikationsruta med en förklarande text som visar att sidan hämtas när användaren valt att navigera vidare. Ett annat exempel på återkoppling från systemet är när man i ärendehanteringen väljer att skicka in ett formulär. Då framträder ett popupfönster med en förklarande text som beskriver vad som hänt i ärendet och var det skickats. Dessa exempel visar att återkopplingen sker i systemet. Frågan är snarare om det visas på rätt eller fullständigt sätt. Indikatorn som visar hur nya sidor hämtas bör kanske ha någon form av animation som visar att systemet verkligen arbetar och inte låst sig. I webbaserade applikationer kan man inte styra animationer på det sättet (med undantag av vissa tekniska lösningar), den fortsätter animera trots fast systemet är låst, men det faktum att användare tar med sig erfarenheter från tidigare användning av andra system gör att det kan vara meningsfullt med animeringen. Vid tillfällen när stora mängder data måste hämtas från databasen kan situationer där sidan visas helt blank under längre tid uppstå. Det ger intrycket av ett långsamt svarande system. En lösning på den problematiken är att först ladda grafiken och hämta listor dynamiskt. Det bör även alltid visas beräknad väntetid, vilket i det här fallet inte är direkt görbart då väntetiden är beroende av så många variabler. Sedan bör det även tänkas över om det är rätt att använda sig av popupdialoger för att förmedla att registreringar i ärenden har skett. Med popupdialoger tvingar man användaren att aktivt agera för att kunna fortsätta att arbeta i systemet. Något som för vana användare kan innebära ett irritationsmoment och resultera i att man aldrig läser informationen utan endast klickar bort dialogen. Istället kan man på något sätt 45

51 5.1. HEURISTISK UTVÄRDERING KAPITEL 5. RESULTAT visa samma information i sidan man tas till, vilket i det här fallet är översiktssidan. För att ytterligare ge användaren kontroll över sitt användande ska man se till att det inte är systemet som styr användaren utan tvärtom. Det här förhållandet tar sig form exempelvis när man är befinner sig i ett ärende och av någon anledning vill lämna ärendet utan att informationen man matat in ska försvinna så måste möjligheten till detta finnas. Även när man skapat ett ärende och är på väg att lämna in ska möjligheten att förhandsgranska finnas. Det ökar känslan av kontroll och användaren kan få ett kvitto på vad denne är på väg att verkställa. Det ska även vara möjligt att utföra de uppgifter man befattar sig med i systemet på olika sätt. Vi människor tenderar att utarbeta olika metoder för arbetet och det är något man måste tillåta. Det får dock inte resultera i att det blir tveksamheter i hur man ska utföra uppgiften bara för att det finns många sätt att göra det på. Det är en balansgång där man måste väga fördelar mot nackdelar för de olika arbetssätten. I System C2 finns möjligheten på vissa ställen att utföra en uppgift på olika sätt, men i vissa fall är detta inte möjligt och man får då tillämpa då det enda möjliga sättet att utföra sin uppgift Inmatning Inmatningsdelen vid skapandet av nya ärenden har ett bristfälligt stöd för tangentbordstryckningar. Eftersom det är många idag som arbetar endast med tangentbordet för att öka hastigheten i utförandet av uppgifter är det viktigt att ha stöd för tangentbordsnavigering och att det följer det naturliga inmatningsflödet. För att hoppa mellan olika komponenter på sidan används tab och i kombination med andra tangenter bör man kunna fylla i hela formuläret. Nu stannar tab-navigeringen någonstans i mitten av formuläret och användaren måste övergå till att använda sig av musrörelser och musklick (detta gäller dock endast vissa webbläsare). För att lösa den problematiken samt att tillåta användaren att använda sig av kortkommandon kan man inför så kallade acceleratorer. Det är när användaren måste blanda tangenttryckningar samt musrörelser som arbetet uppfattas mödosamt. Det finns även ett antal standardkommandon för olika typer av händelser. Man bör följa den standarden så långt som det går. System C2 har lyckats hålla ned behovet av inmatning till en hanterlig nivå med hjälp av checkboxar och rullistor. Man har även i användandet av dessa komponenter sett till att de hamnar efter inmatning från tangentbord, vilket håller ned antalet växlingar mellan tangentbord och mus. Det är även ett konsekvent användande av checkboxar, där flera alternativ kan väljas samt radioknappar där endast ett alternativ av en grupp ska vara möjligt. Vid vissa tillfällen används dock checkboxar för att visa fler alternativ. Det kan vara värt att fundera över om det är rätt att använda boxarna i det syftet eller om man ska hitta en alternativ lösning. En viktig del när man tittar på inmatning är att det blir tydligt för användaren vad som är mottagligt för inmatning av någon form, vilket det i vissa fall inte är i System C2. Ett bra exempel är hur ärendet presenteras för användaren i beslutssteget samt i alla efterföljande steg. Här har man valt att presentera den inmatande informationen i inputfält men inaktiverat funktionaliteten, vilket gör det förvirrande dels om det förväntas någon form av inmatning i de aktuella fälten och dels i de fall användaren vill ändra i ett ärende. Detta exemplifieras i fältet för interna dialogen samt förbättring- 46

52 5.1. HEURISTISK UTVÄRDERING KAPITEL 5. RESULTAT sområde. Även hur man presenterar ärendet vad det gäller rubrik, problem och lösning riskerar att uppfattas som ett inmatningsfält, då det inte är helt tydligt att det endast är tabellceller. Som lösning på problemet bör man fundera på hur ärendet presenteras och försöka få bort inaktiva inmatningsfält Fel och hjälp Den hjälp som finns tillgänglig genom popuper samt hjälpdokumentation anses fungera väl. Ibland kan det dock vara lite oklart vad man förväntas göra och den hjälp som finns att tillgå måste användas. Helst ska dessa tillfällen vara obefintliga, då målet måste vara att systemet ska vara självförklarande. Så om det är ett frekvent återkommande användande av hjälpdokumentation bör man se över designen om det är något man kan göra där för att få systemet mer självförklarande. Vid de få tillfällen användaren kan göra fel och i den mån systemet kan upptäcka felet genereras felmeddelanden. Dessa meddelanden förklarar på ett bra sätt vad felet är och vad det kan bero på. Vid valideringen av formulär visas en popup-dialog som förklarar vilket fält som inte uppfyller kraven som ställts. Det faktum att valideringen sker innan formuläret skickats in är en bra sak. Det är dock så att vid de tillfällen användaren missat att mata in information på flera obligatoriska fält så ges inte information om detta förrän de andra felen är korrigerade. Det beror på att det endast ett fält i taget valideras och användaren tvingas skicka in formuläret efter varje korrigering. En lösning på det problemet är att validera alla fält varje gång och presentera en lista med alla de fält som inte gått igenom Läsbarhet Läsbarheten i System C2 är av skiftande kvalitet, ibland är den tillräcklig, ibland inte tillräckligt bra. På översiktssidan kan man se ett bra exempel på gruppering där man har grupperat in ärenden i olika typer av kategorier för att ge en snabb överblick bland de ärenden som har något med användaren att göra. Här sker även gruppering av klart före datum samt avslutande datum etcetera i kolumner med hjälp av tabeller, vilket är bra. Det ger en överblick och möjlighet för användaren att snabbt skanna genom sina ärenden utifrån olika preferenser. Bristen på betoning av det som är viktigt och förmågan att förminska vikten av det som inte är kritiskt att veta kan göra att användaren uppfattar systemet som rörigt. Det finns många exempel på detta i systemet. Ett sådant är hur man jobbar med kontraster, något som är det absolut viktigaste uttrycksmedlet i den grafiska designen. På översiktssidan eller som det i systemet kallas Min Sida så har man valt att färga rubriken min sida i en ljusblå färg. Trots att rubriken är stor så är det första som fångar ögat den svartfärgade texten som talar om vem användaren är samt vilka nivåer man tillhör, detta på grund av den högre kontrasten. Nu kanske man ser att man är på sin sida med hjälp av igenkännande men det här upprepas på andra sidor. Även rubrikerna ovan tabellerna som visar ärenden har samma problem. Här visas rubriken i en lägre kontrast än det som står direkt under i fet svart stil nämligen urval, vilket är något som inte bör vara viktigare än rubriken. Urvalet bör man ge en lägre kontrast och kanske placera på en annan position. Problemet med kontraster och på andra sätt markera det viktiga och förminska det mindre viktiga är genomgående för hela systemet. 47

53 5.2. PERSONAS KAPITEL 5. RESULTAT Som nämnts tidigare påverkas läsbarheten negativt av hur ärenden presenteras i flödet. Alla ramar och avskiljare bör göras om för att presentera texten på ett tydligare sätt. Just nu presenteras informationen rakt upp och ned och det existerar inga tydliga avgränsningar och grupperingar och man ser inte vilken information som hör till vilken. Detta bör dock kunna avhjälpas med ett fåtal enkla grepp, då systemets funktionalitet inte påverkas Färganvändning och utseende Färganvändningen hålls på en bra nivå då den för det mesta används för att förmedla ett budskap. Ett exempel är när man har ärenden som är försenade markeras datumfältet med en stark färg åt det rödare hållet, något som fångar ögat och uppmärksamheten direkt vilket bör vara syftet. Det finns egentligen inte mycket att invända mot hur färger används, förutom att de i vissa fall förminskar kontrasten där det inte bör göras. Det man kan tänkas ändra på är att använda mer harmoniska färger hos bakgrunderna i systemet. Det vita skenet kan nämligen bli ansträngande i längden. För att förtydliga skulle man även kunna tänka sig att markera statusen på ärenden med hjälp av färger. Annars används färger med förstånd. Man har även skapat ett subjektivt utseende i systemet. Det kan göras mycket för att minska rörigheten bland de objekt och komponenter som bygger upp systemets sidor hur man ska göra detta har föreslagits i tidigare resonemang. Man bör även eftersträva en balans i systemets uppbyggnad och komponenter något man lyckats med till viss mån. 5.2 Personas Expertanvändaren Experten är en man eller kvinna mellan år gammal och för enkelhetens skull kallar vi experten för Annika. Hon är väl insatt i förbättringsarbete och vad System C2 innebär för det arbetet. Hon har även goda kunskaper i användandet av System C2 och alla dess funktioner. Experten kan ta fram statistik och rapporter, vilket är något som görs ofta men det tenderar ibland att innebära svårigheter i att få fram precis det Annika vill komma åt. Annika fungerar ofta som ett stöd åt sina medarbetare i användandet av System C2, en person man går till när det uppstår problem. Hon är även ofta kontaktpersonen mot supporten hos C2 Management och har därför bra kontakt med företaget som ligger bakom systemet. Uppgifter Ta fram olika typer av statistik från systemet. Ha en överblick över användandet i systemet. Söka efter ärenden som ligger inom organisationen. Ta fram rapporter. Administrera systemet. Skapa, besluta, klarrapportera samt följa upp ärenden i System C2 48

54 5.2. PERSONAS KAPITEL 5. RESULTAT Använda System C2 som ett stöd i det dagliga arbetet Mål Att ändra inställningen till System C2 till en mer positiv sådan bland medarbetarna. Att få dem att se nyttan med systemet. Att ta fram statistik på ett lättare sätt. Att söka i arkivet på ett mer intuitivt sätt. På samma sätt ta fram rapporter ur systemet. Få ut rapporter hur användandet av System C2 ser ut, vilka funktioner som används och vilka som inte gör det. Göra ärendeflödet och dess innevarande steg mer intuitiva Medelanvändaren Medelanvändaren är en man eller kvinna, år gammal, som är van att arbeta i System C2. Vi kan kalla denne för Bosse. Bosse jobbar med System C2 dagligen och är därför väl insatt och kan de uppgifter som han utför i systemet väldigt bra. Det är dock ett begränsat användande av de övriga funktioner som finns i systemet. Framtagandet av rapporter och statistik är inte något som hör till det vardagliga arbetet och är därför två saker som av Bosse anser svårhanterligt. Bosse har synpunkter på vissa delar av systemet som kan göras bättre och andra som kanske inte är nödvändiga men i och med sitt begränsade användande inte riktigt kan avgöra om dess vara eller icke vara. Uppgifter Mål Skapa, besluta, klarrapportera samt följa upp ärenden i System C2 Använda System C2 som stöd i det dagliga arbetet. Att ha koll på ärenden som ligger hos andra personer men under sig i organisationen. I viss mån ta fram rapporter och statistik samt söka i arkiv. Det ska vara lättare och mer intuitivt att utföra sina uppgifter. Minska felen i hanteringen av ärenden. Att på ett lätt sätt utöka sitt användande av systemet. Ärendehanteringen ska gå fort och problemfritt Ärendehanteringen ska innehålla få steg samt vara okomplicerad. 49

55 5.2. PERSONAS KAPITEL 5. RESULTAT Sällan-användaren Sällan-användaren tillhör den största gruppen av användare och innefattar båda kön i alla åldrar. Dessa sträcker sig från feriearbetare till höga chefer. För enkelhetens skull sammanfattar vi den här typen av användare under pseudonymen Lars som är en mellanchef med verksamhetsansvar. Lars får ärenden från sina medarbetare som han sedan antingen ska besluta, genomföra eller följa upp. Lars skapar även ibland egna ärenden antingen för egen handläggning eller för någon annan att hantera. Lars kommer nästan aldrig i kontakt med att hantera statistik och rapporter, dock behöver han kunna se de ärenden som ligger hos andra men under honom i organisationen. Lars vill att användandet ska var okomplicerat och inte ta mycket tid av det dagliga arbetet. Han har generellt sett lite negativ inställning till System C2, inte på grund av systemet i sig utan mer på grund av det extra arbetsmoment som det medför. Uppgifter Mål Skapa, klarrapportera, göra samt följa upp ärenden i System C2 Använda System C2 som stöd i det dagliga arbetet Det ska vara lätt förstår var man befinner sig, vad man förväntas göra samt att se vad konsekvenserna i användandet blir Kunna se nyttan med användandet av systemet Ärendehanteringen ska gå snabbt och vara problemfri Ärendehanteringen skall innehålla få steg samt vara okomplicerad Klassificering av användbarhetsproblem Under intervjuerna har ett antal användbarhetsproblem identifierats. Nedan har dessa problem sammanfattats under fem rubriker för att uppnå en kategorisering bland typen av problem. Det är dessa punkter som enligt användarna hindrar dem att tillfredsställa sina behov och uppnå sina mål med användandet av System C2. Alla punkter som tas upp nedan är sådant som flertalet användare påpekat. Således har det inte givits utrymme för enskilda individers åsikter då dessa inte bekräftats av andra. Grafisk design Uppföljare - Det kan ibland vara oklart vem det är som följer upp ärendet, vilket leder till att användaren får en känsla av bristande kontroll. Man bör därför på något vis presentera vem eller vilka som ska följa upp ärendet. En lösning skulle kunna vara att erbjuda förhandsgranskning av ärenden innan de skickas iväg eller att på något annat tydligare sätt ge återkoppling hos vem ärendet hamnar. Bekräftelse - Vid vissa tillfällen upplever användarna att det ges lite bristfällig feedback eller bekräftelse på vad som händer i användandet av systemet. Det bör visas tydligare vilka ändringar som gjorts och hur hanteringen av olika ärenden påverkar mig som användare. Vad jag gjort samt 50

56 5.2. PERSONAS KAPITEL 5. RESULTAT till vem ärendet går och hur denne kommer att se ärendet. Feedbacken får dock inte vara ett hinder i arbetet utan ges på ett sådant sätt att det hjälper och inte stjälper mig i mitt arbete. Begrepp - Ibland är begreppen som används lite svåra och otydligt formulerade, de stämmer inte alltid överens med vad man är van vid från tidigare erfarenheter från andra liknande system. Det är viktigt att begreppen inta kan misstolkas, speciellt i stora organisationer med en blandad publik och blandad erfarenhet av datorer och liknande system. Kanske bör begreppsanvändningen anpassas efter organisationen och vad de använder systemet till. Exempelvis har förvirring uppstått i hur man använder begreppet skicka när ett ärende skapats, där det i vissa organisationer passar bättre med begrepp som registrera. Då ett ärende ska klarrapporteras ombedes användaren även här att skicka in ärendet, där det kanske skulle vara tydligare att använda klarrapportera istället. I övrigt tenderar språkanvändningen att bli lite stel och systemlik, ett språk som inte alla förstår. Man får helt enkelt inte glömma att det är människor som ska använda systemet och språket bör därför anpassas för dem. Historiken - Historiken är väldigt bra och en nödvändig funktion i ärendehanteringen. Det finns dock en del i historikdelen som kan förändras för att leda till en förbättring. Det kan till exempel vara svårt att urskilja informationen och få en överblick över ärendet, detta mest på grund av att det ibland blir rörigt med all information, information som inte alltid bör klassas som primär och stjäl därför uppmärksamhet från det viktiga. Det har även uttryckts önskemål om att göra ärendebeskrivningen och historiken mer enhetlig och samhörande för att få ett tydligare flöde i presentationen av ärendet. Det finns ingen direkt anledning att särskilja delarna eftersom att läsa historiken nästan alltid är nödvändigt för att hantera ett ärende. Informationspresentation - Stora ärenden eller ärenden som hanterats av många personer tenderar att innehålla mycket information där allt presenteras på skärmen med lika stort krav på uppmärksamhet från användaren. Detta som leder till att det blir svårt att processa allting för att sedan ta ett beslut. Skärmbilden tenderar att bli rörig och det blir svårt att urskilja vad som är viktigt för mig just nu. En tydligare uppdelning av viktiga delar och det som är mindre viktigt för att göra gränssnittet tydligare efterfrågas. Formulär - För vissa användare och i vissa moduler, speciellt där mycket och olika former av inmatning krävs, kan formulärens utritning leda till ett inkonsekvent utseende. Det ter sig även så att vissa fält är förskjutna jämfört med andra, detta och det inkonsekventa utseendet leder till att inmatningsdelen upplevs rörig och svåranvänd. Det måste bli tydligare struktur och rakare linjer i utritningen av formulärdelarna. Informationsdesign Flödet - Det råder många frågetecken kring flödet, hur flödet ser ut och fungerar, var i flödet man befinner sig och vad nästa steg blir. För många är figuren som beskriver ärendeflödet inte tillräckligt tydlig. Det kan vara svårt att avgöra om det som figuren illustrerar är de steg i flödet som redan är genomförda eller för det steg man befinner sig just nu. Figuren måste göras tydligare och placeras på ett sådant vis att den uppfattas av användaren. Flödet måste även på andra vis visas på ett tydligt sätt eftersom det är kritiskt att veta var i flödet man befinner sig. Det är även det som talar om var man är just nu och vad man förväntas göra nästa steg. 51

57 5.2. PERSONAS KAPITEL 5. RESULTAT Ärendemottagare - Det råder en osäkerhet om till vem ärenden jag skickar går. Detta problem uppstår främst då en mottagargrupp är satt att ta hand om ärendet. Det finns möjlighet att se vem eller vilka som är ansvariga för gruppen men det visas inte tillräckligt tydligt. Som en lösning på detta problem föreslås även här en förhandsgranskningsfunktion, som tydliggör dessa bitar. Var är jag? En bit som hör ihop med ärendeflödet och hur det beskrivs är det faktum att användarna inte direkt vet var man är och vad man förväntas göra. Just nu får användarna ett e-brev till inboxen innehållande en länk som tar användaren till ett ärende där man ges kunskap angående typ, härkomst och annan information om ärendet. Ofta lägger man bara en kommentar och anser sig klar. Man vet helt enkelt inte vad man ska göra. Användarna ställer sig frågor som: Är det bara information om något? Ska jag göra något med det här? Nästa steg? Vid hanteringen av ärenden frågar sig vissa användare vad som händer i nästa steg och vad jag som användare förväntas göra i det steget eller om man är helt färdig med ärendet. Förslagsvis presenteras den här informationen när ärendet skickas in och i förhandsgranskningen. Det skulle också kunna vara en lösning att visa det på något sätt på den sida hanteringen av ärendet sker. Hjälpsidorna - Ibland är de lite kryptiska och det man vill få svar på får man inte svar på och de stämmer inte alltid med verkligheten utan det ser olika ut. Ett förslag är att vid olika gränssnittsdelar som kan väntas väcka frågetecken hos användare presentera en hjälpikon som är kopplad till rätt del av hjälpdokumentationen. Har jag gjort rätt? - Det råder en osäkerhet kring om man gjort rätt i ärendet och vad man ska fylla i vilken ger en känsla av osäkerhet och otrygghet. Det kan vara ett utbildningsmässigt problem eller så förklaras det inte tillräckligt bra i systemet. Vilka ärenden ligger under mig? - Cheferna har ibland problem att se vilka ärenden som ligger under dem och deras underordnade chefer. Eftersom det är nödvändigt för överordnande att ha koll på sina medarbetare så anses det viktigt med en tydlig sådan funktion. Funktionen bör presenteras som en ytterligare en tabell på översiktssidan, där man enkelt ska kunna se vilka ärenden som ligger hos andra under mig. E-brev - Vid de tillfällen ett e-brev kommer till en sällananvändare uppfattar denna e-brevet som något förvirrande. Vissa uppfattar det till och med som skräppost och ignorerar det fullkomligt. När användaren till slut öppnar e-brevet presenteras inte tillräckligt med information om ärendet och breven kan ibland uppfattas som något kryptiska. Att skicka ut tydligare e-postmeddelanden i rubrik och beskrivning bör därför prioriteras. Kontroll vid utredning - När saker läggs på utredning kan det vara svårt att förstå att det kommer tillbaka till personen som skickat iväg ärendet. Det har återigen med att presentera för användarna vad som händer i nästa steg och när man väl får ärendet visa på ett tydligt sätt varifrån det kommer och varför man får det. Fel - Det kan ibland vara svårt att upptäcka att man gjort fel. Speciellt vid de tillfällen systemet inte kan avgöra om ett felaktigt val eller inmatning har gjorts. En lösning på detta kan kanske 52

58 5.2. PERSONAS KAPITEL 5. RESULTAT vara svårt att ta fram då det inte kan avgöras av systemet. Det är därför extra viktigt att visa för användarna vad man är på väg att göra i ett ärende och ge tillbaka kontrollen över ärendet. Interaktionsdesign Obligatoriska fält - Det kan vara en bra idé att sätta fler fält till att vara obligatoriska för att få in mer information om ärenden. Detta eftersom det inte finns någon fastställd standard för hur namngivning av ärenden ska sättas, något som medför en problematik i sökning efter vissa ärendetyper. Finns möjligheten att då istället söka efter fler sökord för att begränsa urvalet som presenteras är fler obligatoriska fält eftertraktat. Även det faktum att vissa fält som bör vara obligatoriska inte är det resulterar i att ärenden hamnar fel eller att för lite information presenteras. Flödeshantering - När det är inlämnaren som ska ta beslut, genomföra och följa upp måste man manuellt gå genom varje steg i flödet. Det kan ibland uppfattas som flera onödiga moment i arbetet. Det är därför eftertraktat med en funktion som tillåter inlämnaren att hoppa över alla eller några steg i flödet. Om funktionen redan finns måste den på ett tydligare sätt visas för användarna. Dålig kontroll - Man känner att man inte riktigt har kontroll på vad man skickar iväg och var ärendet hamnar. Eftersom systemet är så pass flexibelt och anpassningsbart med många funktioner som både kan vara på och av, uppstår det en osäkerhet om vad som egentligen händer i bakgrunden. Någon typ av förhandsgranskning, där man tydligt ser vart ärendet skickas och vad som skickas, skulle därför vara önskvärd. Spridning - Spridningen av ärenden är krånglig och många lyckas göra fel antingen genom att sprida på fel sätt eller att inte sprida alls. Som lösning på problemet är en bättre funktion för att hantera spridning önskvärt. Det som bör lösas är att undvika fönster som döljer viss nödvändig information och att det krävs flertalet klick utan bekräftelse på vad som händer. Så är det i viss mån idag Ändra ärendet - I vissa fall är det nödvändigt att på ett enkelt och snabbt sätt ändra i ett ärende. Det kan röra sig om att korrigera ett misstag eller addera ytterligare information till ärendet. Det förekommer dock att det inte alltid är intuitivt hur jag som användare åstadkommer denna förändring. Det är inte klart i alla ärendesteg hur jag tar mig tillbaka för att ändra i ett ärende. Det måste finnas möjlighet att var man än står med ett klick ändra ett ärendes innehåll. Rapporter - Framtagandet av rapporter från systemet uppfattas som krångligt och saknar vissa önskvärda funktioner och eftersom det är en vanligt förekommande verktyg som är i allra högsta grad nödvändigt bör extra vikt läggas på att ta fram ett enkelt och lättanvänt sökverktyg. Sökinställningar - Sökningar efter olika ärenden och urval kan vara en krånglig och tidskrävande process för att få det precis som man vill ha det presenteras, därför vore det bra med en funktion för att kunna spara sökinställningar i framtagningen av statistik, rapporter och urval bland ärenden. 53

59 5.2. PERSONAS KAPITEL 5. RESULTAT Egna inställningar - Ett uttryckt behov om individuell anpassningsbarhet av översikt sidan finns idag för att göra sin egen del av systemet mer personlig och anpassad efter sina individuella arbetsuppgifter. Laddnignstid - Ibland är laddningstiderna väldigt långa vilket gör att man uppfattar systemet som segt som i sin tur leder till att man ser användandet som jobbigt och tidskrävande. Exportera - Exportering till excel-dokument är idag en välanvänd funktion med många fördelar. Nackdelen är att den inte alltid blir så bra och ibland helt oanvändbar. Det uppfattas som tråkigt, då det är en potentiellt oerhört bra funktion. Ytterligare utveckling i genereringen av excel-dokument efterfrågas. Spara rapporter - Det finns ett behov av att kunna spara rapporter eller snarare spara konfigurationer som ligger till grund för att ta fram rapporterna. Det måste dock gå att ta bort dessa konfigurationer när de inte längre önskas. Organisatoriska samt utbildningsmässiga problem. Utbildning - Den utbildning som givits har glömts bort av användarna som resultat av lågfrekvent användning och det faktum att vissa inte får någon utbildning alls. Detta problem för därför med sig hårda krav på systemets självklarhet och lärbarhet. Det måste helt enkelt gå att använda systemet utan någon grundläggande utbildning. Ärendeägare - Ärendet måste få en ägare eller en ansvarig person annars tenderar de att aldrig bli slutförda. Det är ingen som tar tag i ärendet och i brist på personligt ansvar uppstår en brist på något ansvar överhuvudtaget. Lösningen på problem är att varje beslutargrupp har en person som får det yttersta ansvaret för ärendet och får se till att det aktuella ärendesteget genomförs. Avslutande av ärenden - Vissa ärendetyper tenderar att skvalpa runt i systemet utan att bli slutförda. Ett problem som kanske inte har med systemet i sig att göra, förutom vissa konfigurationsmöjligheter, utan är snarare en fråga i hur organisationen valt att hantera sina ärenden och även på grund av ärendets typ. Öppenhet - Ärendena kan kännas lite för öppna med att det är många som kan gå in och ändra i ärendena. Det kan dock vara en tanke med att ha det så pass öppet som det är idag, men i vissa fall önskas ärenden hållas konfidentiella. Hantering av tidsramar - Det upplevs som man inte vet när ärendenas olika steg skall vara klara. Man hanterar tidsinställningen på ett dåligt sätt. Ärenden tenderar att skjutas upp när inte tidsmålen kan nås. Detta beror mycket på inställningen man har till typen av ärenden System C2 där lösningen ligger i tydliga riktlinjer i när och hur ett utökande av tidsramar accepteras från organisation och ledning. Osäkerhet - Det råder en osäkerhet med arbetet i System C2, mycket på grund av den, för många, låga användningsfrekvensen. Det är ett problem det är svårt att göra något åt förutom att det ställer krav på systemets användarvänlighet. 54

60 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT Ser inte nyttan - Användarna har svårt att se nyttan med systemet, vilket gör användandet oönskat. Man tycker att man har tillräckligt med system att arbeta i redan System C2 förutan. Detta lägger därför extra stort ansvar på de kontaktpersoner som arbetar mot C2 Management och organisation med ledning i övrigt att förmedla nyttan med användandet. Rubriker i ärenden - Det bör finnas riktlinjer på hur man döper eller sätter rubriker på ärenden för att underlätta sökning och kategorisering. 5.3 Prototyp 1 Första prototypen i framtagandet av nytt designförslag grundar sig på lågupplösta pappersprototyper som vidare digitaliserats för att ge en tydligare bild av komponenter och designmässiga beslut. Prototypen är framtagen i syfte att testa utseende samt beteende och har därför ingen implementerad funktionalitet utan lutar sig helt åt en grafisk representation. Detta medför att prototypen bör klassas som horisontell eftersom den fokuserar på översta lagret i tre-lager-arkitekturen Designbeslut För att göra designarbetet lättare och för att försäkra sig om att fokus hamnar på väl definierade delar har ett antal designbeslut tagits. Dessa beslut ska ligga till grund för designens utformning samt följas upp vid slutfört arbete. Designbesluten som tagits grundar sig i teorin samt resultatet från empiriska undersökningar Fokus läggs på sällan-användare - För att ge prototypen ett tydligt fokus har extra hänsyn tagits till en specifik persona, nämligen sällananvändare. Detta beslut har fattats eftersom det är denna grupp som är i störst behov av ett lättanvänt och användarvänligt system. Det är även denna typ av användare som tenderar att fallera vid flest situationer på grund av bristfällig användning. Gruppen står även för den största kvantiteten av användare vilket medför ett stort behov av uppfyllda krav Endast visa på ärendeflödet och dess olika steg - Som en konsekvens av att fokus lagts på sällananvändare ska prototypen endast visa på de delar som den användargruppen kommer i huvudsaklig kontakt med, vilket är ärendeflödets olika steg Tydlighet i varje enskild vy - För att säkerställa ett användarvänligt system i samtliga delar av systemets ärendeflöde ska ett särskilt fokus läggas på varje enskild sida eller vy. Detta för att, i normalfallet, sätts sallanvändaren in i ärendet vid ett godtyckligt steg i flödet. Något som ställer ett särskilt krav på enkelhet, tydlighet, struktur samt fokus på varje enskild komponent av användargränssnittet Göra ett mer naturligt flöde i varje enskild steg i ärendeflödet - Något som varje användargrupp bör dra nytta av är ett naturligare flöde i ärendestegen, där flödet ska utformas mer efter hur uppgifterna utförs och följa stegen i kronologisk anpassad ordning. Flödet i applikationens ärendehanteringssteg får ej vara inkonsekvent eller otydligt utan ska alltid vara intuitivt och grunda sig på tidigare erfarenheter. 1.5 Systemet ska vara självförklarande - Vid de fall där det som förväntas av användarna inte är självklart ska åtminstone systemet vara självförklarande. 1.6 Följa fördefinierade heuristiker samt riktlinjer - Föredefinierade heuristiker, riktlinjer och 55

61 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT principer framtagna av experter inom området för användbarhet ger ett rätt grundläggande tankemönster i utformningen av gränssnittet och ska därför ligga till grund för det. 1.7 Ska inte visa på någon förändring i befintlig funktionalitet - Eftersom inte tillräcklig information och kunskap om samtliga användargrupper och typer erhållits ska inget av funktionaliteten i systemet förändras. Eftersom konsekvenser av eventuell förändring kan innebära att användargrupperna inte kan utföra sina uppgifter på ett korrekt sätt Prototypen Precis som System C2s ursprungliga design grundar sig den nyframtagna designen på ett flöde i fyra steg. Flödet har brutits upp i nio stycken vyer, till skillnad från tidigare sju. Utanför ärendeflödet har även ett förslag på en översiktssida tagits fram på grund av dess frekventa kontakt med användarna. Systemet har getts en ny övergripande design i form av färgval och struktur. Alla sidor har nu tillgång till en global meny för att möjliggöra en snabb navigering mellan systemets huvudsektioner. Menysystemet har även delats in i en så kallad hjälpmeny, vilken har givits mindre utrymme och separerats från övrig menyfunktionalitet eftersom den består av mindre frekvent använda menyalternativ. Färganvändandet har tonats ned något och en mer diskret färgskala har använts. Inne i ärendehanteringen illustreras vilket steg användaren befinner sig i ärendeflödet genom en figur belägen i vänsterkolumnen. Översiktssidan innehåller ett antal tabeller beroende på användarens preferenser. Tabellerna är sorterbara genom rubrikerna på varje kolumn. Vid oläst ärende markeras det med fetstilt och vid andra attribut hos ärende så som försenat eller bifogad fil markeras det med ikoner jämte ärendenamnet. Översiktssidan har även kompletterats med så kallade hjälpdelar, vilket är avgränsade och rubricerade delar som ska finnas till som stöd och hjälp för användaren. Vid valet att skapa nytt ärende tas användaren till en sida med ett antal alternativ för att bestämma typen hos ärendet användaren vill skapa. Efter valet ges användaren två tydliga alternativ: avbryt och fortsätt. Även i denna vy finns det så kallade hjälpdelar som en guide genom varje val. När beslutet att gå vidare är fattat tas användaren till sidan med övriga formulär för det givna ärendet kräver. Användaren ombedes först att fylla i beslutare och detaljer angående beslutet. Detaljerna består i val om att sprida information och valet att lämna in som grupp. Det ges även en möjlighet att välja redan beslutat eller redan genomfört. Vid valet av att sprida eller lämna in som grupp visas ytterligare fält med hjälp av JavaScript. Fält med möjlighet att addera personer och/eller grupp att sprida till. Sökfunktionen använder sig av AJAX-tekniken för att hämta information från databasen, vilket medför att sidan inte behöver ladda om och ifylld formulärdata består. Vid val av redan beslutat eller redan genomfört ändras rubriken hos beslutsfältet till respektive val samt att fältet gulmarkeras och användaren får fylla i fältet. Andra delen i formuläret är själva ärendebeskrivningen, vilken ombeder användaren att fylla i rubrik, problem samt förslag på lösning. Det ges även en möjlighet att bifoga filer under problemformuleringen. Vid aktivering av bifoga fil visas det även här ytterligare fält för filhantering. Vill användaren addera mer än en fil görs detta enkelt genom att lägga till ytterligare fil. Slutliga delen av formuläret består av en övrigtsektion där övrig information tillhörande ärendet matas in. Det kan vara ett godtyckligt antal fält i den här delen, detta för att varje organisation ofta har grundutförandet till en början men kan behöva komplettera ärendet med organisationsspecifik data. Slutligen ges användaren 56

62 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT möjligheten till fyra olika alternativ: föregående, avbryt, förhandsgranska samt slutför. Föregående tar användaren tillbaka till föregående steg nämligen val av ärende. Avbryt avbryter ärendet och tar användaren tillbaka till ärendeöversikten. Förhandsgranska tillåter användaren att se till vem ärendet går samt hur ärendet ser ut för denne. Slutför registrerar ärendet i databasen och vidtar lämpliga åtgärder. Beslutsstegets vy börjar med en presentation av ärendets lösning och problem samtidigt som figuren i vänsterspalten tagit ett ytterligare steg i flödet. Detaljerna för ärendet är minimerade och visas genom att användaren klickar på detaljerad information. Vid valet att visa detaljerad visas en dold del av sidan innehållande saker som datum, ärendenummer etcetera. Historikkomponenten har kommentarsfältet för samtliga händelser till en början minimerat förutom senaste aktivitet där kommentaren visas. Användaren kan sedan efter behov maximera valfritt fält för att läsa om en specifik händelse. Det finns även valet att maximera hela tabellen i de fall där beslutaren måste läsa genom hela historikflödet. Beslutaren tar till sist sitt beslut där denne kan välja mellan ett antal primära beslut och vid de fall inget av de beslut som visas kan fattas kan användaren välja ytterligare val för att få fram fler alternativ som senarelägg eller vidarebefordra. Användaren väljer sedan att gå vidare till nästa del eller att avbryta beslutet. Väljer användaren att genomföra ärendet tas denne till delen för genomförande, där ett antal delar ska fyllas i. Vilka delar och hur valen sker är olika från kund till kund, men i exempelgränssnittet ombedes användaren att fylla i information angående person som ska genomföra ärendet samt person som skall följa upp ärendet. Finns inte alternativet med i listan kan en sökning göras, vilket medför ett extra sökfält där användaren börjar fylla i namnet som kontinuerligt kompletteras med alternativ med hjälp av XMLHttp-requests till servern. När önskat namn är valt konfirmeras detta med en knapp: välj. Vidare fyller användaren i tid då ärendet skall vara genomfört samt en kommentar rörande aktuellt beslut. Vill användaren se information om ärendet finns möjligheten ett klick, där ifrån i de minimerade delarna visa ärende och visa historik. Slutligen finns återigen alternativen slutför, förhandsgranska, avbryt samt föregående. Ärendestegen lägg ned samt utred följer samma typ av gränssnitt som ska genomföras. Skillnaden ligger endast i att vissa komponenter plockats bort. Under utredning tillsätts endast en utredare och ingen uppföljare. Under nedläggning ombedes användaren att endast fylla i en kommentar angående ärendet för att sedan verkställa beslut. Det är även skillnad i utritningen av figuren som illustrerar vilket steg i flödet användaren står. Vid klarrapportering presenteras ärendets beskrivning samt förslag på lösning följt av en minimerad historiklista. Figuren, för att förklara ärendet, har fyllts på med ett ytterligare steg och en lokal meny med ytterligare alternativ presenteras över figuren i vänsterspalten. När användaren läst genom ärendet och förstått att en klarrapportering skall ske klickas nästa för att ta användaren till nästa steg där denne förväntas fylla information om datum då ärendet genomförts samt en kommentar angående genomförandet. Alternativet att se ärendeinformation samt historik finns i minimerade listor som visas efter behov genom att klicka på visa ärende samt visa historik. Till sist när alternativet är klarrapporterat går det till uppföljning där berörda personer får ärendet till sig och presenteras ärendeinformation samt historik och ges även möjligheten att se detaljerad 57

63 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT information i ett förinställt minimerat läge. Ärendeflödesfiguren har fyllts på med ytterligare ett steg och en lokal meny med alternativa handlingar lägger sig över figuren. När användaren läst genom ärendet ställs denne inför ett val: blev det bättre, ja eller nej. Väljer användaren ja stängs ärendet och användaren tas tillbaka till översikssidan. Väljes däremot nej kommer ytterligare alternativ upp för att ta beslut om det ska stängas eller gå tillbaka för beslut. Det finns även här olika kombinationer och funktionalitet beroende på olika kunders krav och behov Motivering Vid utformningen av den grafiska designen har tankegångarna hela tiden varit tydlighet. Tydlighet i alla steg och i alla komponenter, tydlighet i övergripande delar samt i detalj. För att uppnå det har så mycket detaljer som möjligt skalats bort för att ge intrycket av klara gränssnitt. För att ge det som behöver hävas fram möjligheten att göra det tonas vissa komponenter med mindre relevans ned. Ett exempel på detta är urvalet över ärenden som visas i tabellerna på översiktssidan. Det är information man i vissa fall har tillgång till, men det är information som för det flesta användare är mindre intressant. Det finns därför ingen anledning att låta den komponenten ha så hög kontrast, vilket stjäl uppmärksamhet, som i det ursprungliga systemet. Prototypen tar även hänsyn till att de flesta idag använder en upplösning med minst 1024 pixlar i bredd 3, detta genom att införa hjälpdelar i sidan. Hjälpdelarna kan, vid de fall upplösningen når under en viss gräns, tas bort eller placeras på ett alternativt ställe med hjälp av JavaScript. Hjälpdelarna finns där för de användare som känner sig väldigt ovana att arbeta i systemet som ett försök att göra det systemet självförklarande. Färganvändningen har tonats ned och fokus har istället lagts på kontraster för att kommunicera relevans och fånga uppmärksamhet. Vid de få tillfällen färgsättning används är det för att kommunicera ett budskap och inte för något direkt estetiskt syfte. Övergripande färgskalan är grå med blå färg för att markera klickbarhet. Navigationsstrukturen är uppbyggd på det sätt den är för att ge användaren en uppfattning om var man befinner sig både på översiktsplanet men även i det detaljerade planet. Det åstadkommer prototypen genom att ha en global meny samt en föränderlig meny kopplad till varje enskild vy. Den globala menyn visar var man befinner sig genom att ha samma bakgrundsfärg som huvudsidan samt att skiljelinjen under fliken tas bort. För att sedan se var man befinner sig i den lokala menyn markeras detta med en pil på rubrikens vänstra sida. Indelningen av menyalternativen är beroende av dess egenskaper. Huvudsakliga sektioner i systemet har placerats i den globala menyn medan de alternativ som är specifika för varje sida placeras i den lokala menyn. I Hjälp-menyn har de mindre frekventa alternativen placerats eftersom de inte bör ha lika mycket utrymme som de vanligaste alternativen. Det blir på så sätt mer naturlig uppdelning mellan menyalternativen, vilket ger större möjlighet att hitta rätt. Figuren som visar ärendeflödet är en del i att tydliggöra var man befinner sig i det, eftersom det inte kan illustreras i navigationsstrukturen. Figurens position är ett resultat av att det under användarstudierna framkommit att figuren inte uppmärksammas av alla användare. En bidragande orsak kan just vara objektets position. Figuren hade i systemet en fix position och var alltid visuellt tillgänglig, vilket medförde att användarna sållade bort informationen den ger. Tanken med den nya designen på 3 Statistik hämtad från: display.asp (Senast besökt: ) 58

64 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT figuren är att det inte ska vara möjligt att missa den, vilket är åstadkommet med hjälp av en föränderlig figur samt att den endast visas när man hanterar ett ärende. Detta förstärks med färglaggda figurer för de steg i flödet som är genomförda. Det har lagts mycket fokus på att göra figuren extra tydlig då det under användarstudierna framkommit att flödet ibland kan vara svårt att förstå samt att det inte är tydligt vad man förväntas göra och vad som händer i nästa steg. Figuren är inte helt självförklarande och mer arbete för att förtydliga figuren och dess betydelse är en prioriterad punkt. Översiktssidans design är på många sätt väldigt lik den System C2s ursprungliga design. Det som skiljer sidorna åt är valet av grafiska element. Att ha ramar tillsammans med rubriker för de olika delarna på sidan är för att på ett tydligt sätt gruppera in delarna och visa vad som hör till vad. Kontraster används för att markera relevans och låta användaren se rätt saker. En sorteringsfunktion i har lagts till för varje kolumn i tabellerna vilket görs med hjälp klickbart tabellhuvud. Olästa ärenden markeras med fetstil och bör därför rikta användarens uppmärksamhet mot olästa. Ikoner för att visa på olika attribut ett ärende äger placeras vid sidan av ärendet precis som i det ursprungliga systemet. Skillnaden är att alla ikoner förses med en popup-text med förklaring av betydelsen samt att en hjälpdel statiskt presenterar betydelsen av alla typer av ikoner. Indelningen av ärenden i tabellerna har skalats ner för att minska bruset och låta ärenderubriken träda fram tydligare. Separeringen mellan ärenden sker endast genom horisontella streck med låg kontrast. Varje kolumns element delas in i en osynlig horisontell linje för att underlätta sökningen i tabellen. Som tidigare nämnts har urvalet givits en lägre kontrast på grund av dess relativa irrelevans. Även vetskapen om vem som är inloggad och under vilka enheter användaren ligger har tonats ned och placerats utanför det sökningsområdet, detta på grund av att man ofta redan vet vem man är inloggad som och att det därför inte finns någon anledning att visa det tydligare. Det finns i vissa fall hos vissa kunder där det är viktigt att veta vilken behörighet man är inloggad med, det är då lämpligt att kommunicera detta med ett lämpligt färgval. Valet att dela in skapandet av nytt ärende i två sidor är gjort för att tydliggöra de alternativ man har samt att göra användaren medveten om att det är ett aktivt val. Det är något som även ger användaren en känsla av kontroll och medvetenhet om vad man faktiskt gör. Det finns inte heller någon anledning att bestämma åt användaren vilken typ av ärende som ska registreras. En nackdel med uppdelning är att den uppfattas som ett extra steg i att skapa nytt ärende, något som kan vara ett pris värt att betala. Vidare ges användaren valen att avbryta eller gå vidare till nästa steg. Dessa val görs genom att klicka på två tydliga knappar som har separerats från varandra på grund av deras särskilda funktion. Särskild vikt har lagts på att göra knapparna tydliga eftersom det under användarstudien framkommit att det i ursprungliga systemet kan vara svårt att hitta hur man går vidare. Nästa del i skapandet av nytt ärende börjar med att användaren uppmanas att fylla i beslutare och andra tillval eftersom många användare hade synpunkter på att ärenden tenderar att hamna hos fel person, lägger man då större vikt hos beslutare kan det resultera i att man tänker ett steg extra till vem ärendet bör gå. Det finns även en tanke om att låta ärendet se ut mer som ett skapande av ett e-post, i vilka fall mottagaren nästan alltid väljs först. Genom att låta ärendeskapandets beteende likna e-post skapande låter man användarnas mentala modeller och tidigare erfarenheter komma fram, något som underlättar systemets lärbarhet. Gruppinlämning, sprid information, redan genomfört samt redan beslutat placeras tillsammans med valet av beslutare eftersom alternativen påverkar mottagaren av ärendet på ett eller annat sätt. Efter att huvudinformationen(rubrik, problem samt lösning) för 59

65 5.3. PROTOTYP 1 KAPITEL 5. RESULTAT ärendet är ifyllt placeras övrig information under rubriken övrigt eftersom det i detta läge är mycket organisationsspecifikt som visas och att den funktionalitet som finns där inte kan bestämmas på förhand. Grupperingen av valen vad man sedan vill göra med ärendet är precis som i föregående steg beroende av relativ relevans. Föregående samt avbryt ingår under samma typ av beteende; man ångrar ett val. Förhandsgranskning samt slutför ligger närmare varandra i beteende och placeras därför tillsammans. Förhandsgranskningsalternativet är en funktion framtaget för att tillfredsställa användarnas behov av möjligheten att se hos vem eller vilka ärendet hamnar hos och vad mottagaren kommer att se när denna öppnar ärendet för beslut. Beslutsstegets olika delar har arrangerats annorlunda i jämförelse med tidigare utformning, detta för att få ett naturligare flöde i beslutssteget. Användarstudierna visade också det faktum att man inledningsvis läser ärendet följt av historiken och till sist fattar sitt beslut. Beslutet att dela in beslutsdelen i två delar kommer från att man i så stor utsträckning som möjligt vill separera inmatning samt statisk information och även göra användarna uppmärksamma på skillnaden mellan besluten. Ärendebeskrivningen har flyttats ut från de ramar där den tidigare presenterades. Detta för ge texten utrymmet till skillnad från ramen runt omkring. Beskrivningen har även givits en lätt grå bakgrund i ett försök att särskilja statisk text från komponenter som kan interageras med. Detaljerna har gömts undan för att det inte alltid är relevant för beslutet att visa dessa. Skulle man välja att visa detaljerad information riskerar användaren att drunkna i detaljer och tappa fokus, vilket leder till att ärendet uppfattas jobbigt att hantera. Det är också ett steg i att göra tydliga och rena vyer med så lite detaljer som möjligt. Designbeslutet för historikdelen grundar sig i att den många gånger kan bli väldigt lång och att det blir otydligt vad som har hänt i varje steg. Tanken är att ikonen bredvid datumet för händelsen ska indikera vilken typ av händelse det gäller. Valet att minimera samtlig historik förutom senaste aktivitet beror på att det beslutet oftast grundar sig på senaste aktivitet samt att det ger en snabb överblick över ärendet. Vill man sedan veta mer i detalj vad som hänt vid varje händelse kan man maximera endast den delen. Detta beteende håller ned längden på historiken vilket medför en reducering i skrollning av sidan, vilket är något som är åtråvärt. Att i beslutsdelen välja att gömma undan vissa alternativ är på grund av att det är sekundära alternativ och inte något man vill väga lika tungt som de primära alternativen. Vidare bygger knapplaceringarna på tidigare resonemang. Oberoende av vilket beslut som fattas tas användaren till ett formulär som bygger på samma designprinciper. Genomförandedelen skiljer sig från ursprungliga systemet i inmatningsflödet för att åstadkomma ett naturligare handlingssätt. Tanken är att alla sidor ska ha en uppifrån- och ned ansats, alltså uppgiften användaren genomför genomförs uppifrån och ned. Skillnaden är ligger i att användaren väljer vem som genomför samt vem som följer upp ärendet i en följd. Ärendebeskrivningen samt historiken är i utred-, lägg-ned- samt genomförsteget minimerad eftersom användaren läst ärendet i föregående steg och behöver i de flesta fall inte läsa det igen, men i de fall där det är nödvändigt finns möjligheten utan att gå tillbaka till föregående steg. Även klarrapporteringens flöde är förändrat eftersom det naturliga är att man läser ärendet innan man hanterar det så kommer presenteras ärendet innan val kan göras. Det faktum att klarrapporteringen är indelad i två steg har i enda syfte att användaren ska tvingas att göra ett aktvit val. Historiken är här minimerad eftersom det inte alltid är intressant att veta vad som hänt tidigare i ärendet för att rapportera det genomfört. Nästa steg i klarrapporterainge har också minimerad ärendeinformation 60

66 5.4. PROTOTYP 2 KAPITEL 5. RESULTAT samt historik av samma anledning som tidigare nämnt. Uppföljnigsstegets designprincip bygger på samma principer som klarrapporteringen med skillnad i avseendet att informationsdelen presenteras tillsammans med inmatningsdelen 5.4 Prototyp 2 Den första prototypen fångar in och hittar en lösning på de allra flesta användbarhetsproblem som kommit fram genom genomförda fältstudier och heuristiska genomgångar. Ska man dock följa den användarcentrerade designprocessen framtagen till ISO så ska designlösningar utvärderas och om samtliga användarkraven inte är uppfyllda ska ett ytterligare ett varv i cykeln fullföljas. Således har en utvärdering av prototypen ägt rum för att klargöra om något eller några krav inte tillfredsställs. Vidare har nya designlösningar tagits fram för att täppa till de hål i tidigare design som identifierats Heuristisk genomgång Översiktssidans designbrister efter första prototypen består i ett antal grafiska komponenter som behöver förtydligas. Bland annat bör det införas ikoner för att förtydliga flikmenyns olika alternativ. Det råder även brister i hur nya och/eller olästa ärenden presenteras för användarna då det endast markeras genom att fetmarkera texten i ärenderubriken. Det bör även här införas en ikon för att förtydliga ett oläst ärende då det är vitalt för användarna att alla ärenden gås igenom. Det bör även adderas ytterligare interaktivitet till min sida i form av manipulering bland ärenden (alltså genom checkboxar, markera ärenden och vidare utföra en handling på samtliga markerade ärenden). Som tidigare nämnts bör mer tanke och arbete läggas kring utformandet av den beskrivande figuren. De brister som påvisas är den oklarhet som råder om figuren markerar det steg användaren står i just nu eller om det vid det aktuella stegets slutförande kommer nå det steg som är markerat i figuren. Figuren beskriver PDCA-cykeln[20] och dess steg omformulerat för att passa ett ärendehanteringssystem. Frågan är dock om inte ett steg i figuren bör bytas ut. Steget som berörs är göra då detta beskriver en process utanför systemet till skillnad från de andra stegen som beskriver en aktiv handling i systemet. Den andra stora förändringen som bör genomföras inför kommande prototyp är ärendebeskrivningen och hur den är kopplad med historiken. Dessa två komponenter i sidan bör hänga ihop mer. Det bör vara en sömlös koppling mellan dessa, då det inte finns något egenvärde i att bryta upp dem. Även vissa detaljer i historiken bör skalas bort eller döljas för att inte medför ett negativt brus Designbeslut 2.1 Designa efter tidigare tagna designbeslut - Den nya designen ska vara utformad efter de designbeslut som tagits vid ett tidigare skede för prototyp 1. Detta för att behålla fokus och avgränsning mot den del av systemet som användarna i huvudsakligen kommer i kontakt med. 2.2 Utveckla funktionalitet - Prototyp 2 ska lägga mer fokus på funktionalitet då detta inte varit prioriterat i tidigare prototyp. Prototypen ska alltså visa på de funktionella delarna samt hur de förbättrar användbarheten. 61

67 5.4. PROTOTYP 2 KAPITEL 5. RESULTAT 2.3 Fokus på utvärderingens resultat - Det ska läggas ett fokus på de användarproblem som kommit fram under utvärderingen av prototyp 1. Som nämnts tidigare är målet att förbättra existerande prototyp därav detta fokus Prototypen Prototyp 2 har, till skillnad från prototyp 1, utrustats med ikoner på flikarna i den globala menyn. Det har även adderats ikoner till ärendelistorna för olästa ärenden samt möjligheten att markera ärenden genom checkboxar för att sedan applicera ett alternativ på flera markerade ärenden. Ärendelistorna har även fått beteendet att vid fallet då ett ärende är oläst får bakgrunden en grönaktig färg, lästa ärenden gul färg och försenade ärenden har utrustats en röd färg samt en ikon som indikation. Figuren som beskriver i vilket stadium ett ärende befinner sig har ett utseende då man befinner sig aktivt i ett givet skede samt en annan indikation då det givna steget är genomfört. Steget göra i figuren har bytts ut till klarrapportera. Ärendebeskrivningen har kopplats samman med historiken och detaljer i historiken har gömts undan med valet att utvidga detaljer om så önskas. Hela ärendebeskrvningen samt historiken har omformats till att följa ett kronologiskt flöde likt en e-postkonversation Motivering Ikonernas placering på flikarna i den globala menyn syftar till att göra menyn och dess val tydligare och lättare att hitta snabbt, samt underlätta inlärningen kring vad de olika alternativen innehåller. Likaså är syftet med bakgrundsfärgskiftningarna i ärendelistorna att underlätta för användarna att snabbt kunna hitta och förstå vad som ska prioriteras. Figurens förändringar är en konsekvens av att det råder en tvetydighet i vad dess olika steg betyder. Med olika utseenden på genomfört steg och aktivt steg bör denna tvetydighet kunna suddas ut. Beslutet att ändra göra till klarrapportera är taget för att alla steg i figueren skall representera en aktiv handling i systemet till skillnad från en process utanför systemet som det var i det ursprungliga systemet samt i prototyp 1. Förändringen i ärendebeskrivningen och historiken är ett grepp för att underlätta genomläsningen av ärendet. Eftersom det under intervjuer med användare framkommit att historiken nästan alltid är något man måste läsa igenom efter att man läst ärendebeskrivningen så bör en kronologisk följd av historik efter ärendet vara ett naturligt sätt att läsa ärendet. Eftersom inte all information i historiken är primär har en del av den skalats bort för att åstadkomma ett renare och tydligare gränssnitt. 62

68 Kapitel 6 Diskussion Vid ett arbete av denna omfattning, utnyttjande av flertalet metoder, tillämpning av ett antal teorier så bör det alltid ske en kritisk granskning till hur dessa har använts och hur väl resultatet stämmer med uppsatsens ursprungliga syfte. Således tas detta upp i följande kapitel, som inleds med en metoddiskussion, som innefattar reflektioner rörande metodval. Vidare diskuteras resultatet vad det gäller uppfyllt syfte samt utredda mål. Slutligen tas detaljer rörande uppsatsens validitet och reliabilitet upp. 6.1 Metodvärdering Redan innan planeringen inför fältstudien ägt rum bestämdes det att minst en utvärdering i varje utvärderingskategori (se sektion 2.6) skulle genomföras. Detta för att jag som genomfört projektet inte gjort något liknande tidigare och därmed inte heller hade någon kunskap om vilken typ av metod som lämpar sig bäst i ett projekt som detta. Metoderna som slutligen valdes för fältstudierna var en subjektiv (intervjuer) samt en empirisk ( Tänka högt ) metod. Att genomföra intervjuer blev att naturligt val då de inte ställer så stora tidsmässiga krav som exempelvis frågeformulär som även tenderar att ha låg reliabilitet då det ges ett stort tolkningsutrymmme i den typen av utvärderingsmetod. Dock hände det att jag som intervjuare ställde en del ledande frågor för att bekräfta ett påstående från en tidigare respondent. Detta gjordes naturligtvis omedvetet, men uppdagades under genomgången av materialet. En annan reflektion som gjordes tidigt i fältstudierna var att det underlättar med flera medarbetare vid utförandet av intervjuerna. Nu skötte jag intervjun simultant med dokumentationen, vilket kan ha sänkt kvaliteten på intervjun något. Jag anser dock att intervjuer var det rätta valet av subjektiv utvärderingsmetod då dessa gav utrymme för uppföljande frågor och svar. Tänka högt -metoden genomfördes som ett led i en intervju. Den kombinerades även med observationer i användandet av applikationen. Detta visade sig vara väldigt bra för att ringa in de problem användarna var omedvetna om. Metoden gav ovärderlig insikt om hur applikationen används av just sällananvändaren då de mer erfarna användarna ofta använder applikationen på rätt sätt. Jag tror att de flesta empiriska metoder som utförs på verkliga användare hittar samma typer av problem, eftersom en handling ofta säger mer om den verkliga situationen. Det som är fördelen med Tänka högt -metoden är att det ges svar på varför användaren gör som den gör vid det specifika tillfället handlingen sker, till skillnad från att exempelvis bara observera en användare där möjligheten att få 63

69 6.2. RESULTATDISKUSSION KAPITEL 6. DISKUSSION en förklaring till ett visst handlande inte finns. Den heuristiska utvärderingen var också värdefull eftersom det gav en helt objektiv bild av systemet. Något som gav insikter man varit blind för tidigare. Valet att använda en heuristisk utvärdering som heuristisk metod berodde på dess anpassningsbarhet efter ett redan existerande system. Systemet skulle även kunna utvärderas efter ett antal checklistor men enligt mig passat detta bättre för ett system under uppbyggnadsfasen. Detta eftersom det är så svart eller vitt och att det inte ger utrymme för individuell anpassning. Ett flertal andra utvärderingsmetoder var uppe för diskussion och även i vissa fall även för genomförande. Dessa lades dock senare ned på grund av tidsbrist, tillämpbarhet eller relevans. Det genomfördes bland annat kognitiva genomgångar bland personer som inte kommit i kontakt med System C2 tidigare. Resultatet ansågs dock inte relevant eftersom dessa personer inte haft någon kunskap i arbetet med vad System C2 är ämnat att stödja. 6.2 Resultatdiskussion Det huvudsakliga syftet med uppsatsen löd: Att genom användarcentrerade metoder, tillsammans med C2 Managements kunder, ta fram förslag på en ny användaranpassad design av System C2. Designen ska stödja identifierade uppgifter samt uppfylla de användbarhetsmål vilka ska vara ett resultat av genomförda fältstudier. I projektets genomförande har det tillämpats användarcentrerade metoder både för utvärdering samt i framtagandet av prototyper. Det har varit ett kontinuerligt samarbete med C2 Managements kunder och System C2s användare. Ett samarbete som varit ett led i tillämpningen av de användarcentrerade metoderna. Från detta samarbete har ett antal prototyper som stödjer de uppgifter som identifierats i samband med utförda fältstudier trädit fram. I och med detta konstaterande anses projektet uppfylla det tidigare fastställda syftet. Således anses även projektet, och med det examensarbetet, vara lyckat. Målet att beskriva vad användbarhet egentligen är uppfylls genom den teorigenomgång som genomfördes. Teorigenomgången ger en nyanserad bild över flertalet teorier och åsikter från många av MDIområdets stora och små aktörer (vissa mer åt det teoretiska hållet medan andra åt det mer praktiskt tillämpbara). Det fanns även en mål att undersöka hur en användarcentrerad process kan tillämpas och hur den kan anpassas efter redan existerande system. Även detta mål nåddes och diskuteras närmare i sektion Rapporten tar även upp de utvärderingsmetoder som kan tillämpas på ett projekt som detta, där alla metoder är tillämpbara ur ett användbarhetsperspektiv. Målen med uppsatsen kan även de anses vara uppfyllda Användarcentrerad utveckling i verkligheten En iaktagelse jag gjorde tidigt under arbetets gång, vid inledande litteraturstudie, var att nästan alla användarcentrerade metoder som finns att tillgå är anpassade efter annu ej existerande system. 64

70 6.3. BÖRJA MED ATT KRYPA OCH SEDAN GÅ KAPITEL 6. DISKUSSION Metoderna beskriver hela systemutvecklingsprocessen från början till slut. Jag kände därför en avsaknad bland användarcentrerade metoder som är direkt applicerbara på ett färdigutvecklat system i behov av vidareutveckling. Det finns idag oerhört många system som utvecklats genom en traditionell utvecklingsprocess helt utan användarmedverkan. System som mycket väl fyller sitt syfte, men i många fall kan vara svårhanterliga, komplicerade och föråldrade. Alla med en fullkomlig avsaknad av användarvänlighet och behov av en användarcentrerad vidareutveckling. Jag efterslyser klara och tydliga metoder och processer för att underlätta arbetet för utvecklare och projektledare som vill tillämpa ett användarcentrerat utvecklingssätt. I mitt arbete med System C2 följdes de riktlinjer för användarcentrerad design som tagits fram i ISO 13407[8]. En cykel som mycket väl går att applicera på redan existarande systems vidareutveckling. Vidare tillämpades Gulliksens och Göranssons[2] användarcentrerade process, som är mer anpassad efter icke-existerande system. Således krävde denna process en del modifikation, dels för att passa systemets aktuella status och dels för att jag ensam utförde projektet. Det är många steg som inte behöver genomföras samt en del steg som kanske saknas. 6.3 Börja med att krypa och sedan gå Jag tror att det viktigaste för dem som funderar på att utveckla sin produkt att bli mer användarvänlig är att börja i en ände, inte slå på stora trumman direkt, utan börja med ändra sitt tankesätt kring systemets utveckling. Vilka är det som ska använda systemet? Är det jag som utvecklare eller jag som systemansvarig som ska vara den primära användaren av systemet? Jag såg många gånger i mitt arbete hos C2 Management hur kunder beställde utvecklingar av funktioner till systemet för stora summor. Dessa funktioner var inte alltid var vitala utan bara bra att ha. Det kunde vara kunder som har användare med problem att lämna in ett enkelt förbättringsärende. Frågan är om det inte är dessa användare vi ska lyssna på innan nästa steg tas? Det är de som faktiskt använder eller vill använda systemet som bör få sina röster hörd. Det behöver inte vara några dramatiska förändringar. Börja med enkätundersökningar och fortsätt med fokusgrupper eller liknande. När detta behärskas, fortsätt då vidare från det, steg för steg. Jag tror att tiden och kostnaden för att tillämpa användarcentrerade metoder, med allt det innebär, betalar igen sig i förlängningen. 6.4 Validitet och reliabilitet För att säkerställa validiteten i de intervjuer som genomförts har det inte givits utrymme för enskilda individers åsikter då dessa inte bekräftats av andra användare. Även de gånger två olika respondenter givit två motsägande påståenden har dessa bortsetts ifrån. Det har även tillämpats fler än en utvärderingsmetod i kravanalysen. Det avändbarhetsproblem som påträffats i samtliga utvärderingar väger tyngre än de som bara funnits i enstaka. Till den teori och empiri som projektet grundar sig på finns även skriftliga och muntliga källor redovisade. För att åstadkomma så hög reliabilitet som möjligt i uppsatsens resultat gjordes ett noga övervägande i val av utvärderingsmetoder. Exempelvis fanns det till en början planer att genomföra enkätundersökningar. Dessa planer lades senare ned på grund av undersöknings risk att ge icke reliabla resultat. 65

71 6.4. VALIDITET OCH RELIABILITET KAPITEL 6. DISKUSSION Att på annat sätt säkerställa reliabiliteten är svårt då de kvalitativa undersökningarna eftersom de till viss mån färgats av mina egna synpunkter. En konsekvens av att jag inte heller haft någon medarbetare att diskutera idéer och förslag med. Detta gäller dock huvudsakligen prototypkapitlen då tolkningar av resultatet är en förutsättning. 66

72 Bilaga A Prototyp 1 67

73 BILAGA A. PROTOTYP 1 Figur A.1: Översiktssida 68

74 BILAGA A. PROTOTYP 1 Figur A.2: Nytt ärende 69

75 BILAGA A. PROTOTYP 1 Figur A.3: Nytt ärende; andra steget 70

76 BILAGA A. PROTOTYP 1 Figur A.4: Besluta i ärende 71

77 BILAGA A. PROTOTYP 1 Figur A.5: Ska genomföras 72

78 BILAGA A. PROTOTYP 1 Figur A.6: Utred 73

79 BILAGA A. PROTOTYP 1 Figur A.7: Lägg ned ärende 74

80 BILAGA A. PROTOTYP 1 Figur A.8: Klarrapportera ärende 75

81 BILAGA A. PROTOTYP 1 Figur A.9: Klarrpportera ärende; andra steget 76

82 BILAGA A. PROTOTYP 1 Figur A.10: Följ upp ärende 77

83 Bilaga B System C2s ursprungliga användargränssnitt 78

84 BILAGA B. SYSTEM C2S URSPRUNGLIGA ANVÄNDARGRÄNSSNITT Figur B.1: Översiktssida 79