Polisklienten A N N I K A S U N D Q V I S T

Transkript

1 Polisklienten En undersökning hur, med hjälp av användbarhetsanalys, polisens klient för olycksregistrering kan förbättras A N N I K A S U N D Q V I S T Examensarbete Stockholm, Sverige 2007

2 Polisklienten En undersökning hur, med hjälp av användbarhetsanalys, polisens klient för olycksregistrering kan förbättras A N N I K A S U N D Q V I S T Examensarbete i människa-datorinteraktion om 20 poäng vid Magisterprogrammet i människa-datorinteraktion Kungliga Tekniska Högskolan år 2007 Handledare på CSC var Rosa Gudjonsdottir Examinator var Kerstin Severinson Eklundh TRITA-CSC-E 2007:040 ISRN-KTH/CSC/E--07/040--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Polisklienten: En undersökning hur, med hjälp av användbarhetsanalys, polisens klient för olycksregistrering kan förbättras. Sammanfattning Regeringen gav 1996 Vägverket i uppdrag att utveckla ett informationssystem för trafikskador och trafikolyckor i Sverige i syfte att förbättra trafiksäkerheten. Systemet kallas idag för STRADA, och bygger bland annat på uppgifter lämnade från polisen. Polismyndigheten rapporterar från olycksplatsen, om vilka fordon som varit inblandade, rådande vägförhållanden med mera via en inmatningsklient, som kallas polisklienten. En väl fungerande och användbar inmatningsklient ökar kvalitén på data i STRADA, vilket medför att trafiksäkerhetsarbetet blir mer effektivt och resurser sätts in vid rätt tid och på rätt plats. Om riskerna att göra fel i inmatningsprocessen minskar, kan även riskerna att göra fel vid trafiksäkerhetsarbetet reduceras. Uppdraget, som redovisas i uppsatsen, var att undersöka hur polisens inmatningsklient kunde förbättras och göras mer användbar. Jag använde mig av kontextuella intervjuer, low-fi och hi-fi prototyper samt scenario i arbetet. Uppdraget innefattade även utveckling av en mobilprototyp för att visa hur polisen i framtiden kan tänkas registrera information vid en trafikolycka. Prototypen utformades på en Tablet PC, en bärbar dator, och i uppsatsen redovisas det även för vilka metoder och teorier som använts vid utformningen av denna prototyp. Sökord; Användbarhet, STRADA, positionering, prototyp, mobila användargränssnitt

4 The Police Client for road traffic accidents: An evaluation of how, the Swedish Police Client for road traffic accidents can become more usable. Abstract In 1996, with a view to improving road safety, the Swedish Government commissioned the Road Traffic Authority to develop a system to track and report information on road traffic accidents and injuries in Sweden. This system, today called STRADA, is partially based on information provided by the Police. At the scene of an accident the Police authority inputs information on vehicles involved, the present road conditions etcetera via a data input client that is called the Police Client. A well-working and useful data input client increases the quality of data in STRADA, leading to more efficient road safety work and resources being more effectively utilised at the right time and in the right location. If risks for errors during the data input phase are reduced, then, the risks of mistakes occurring during road safety work will also be reduced. The overarching assignment, the results of which are presented in the essay, was to look into how the Polices client could be improved and become more usable. Contextual interviews, Low-Fi and Hi-Fi prototyping and scenarios were used to develop ideas for an improved data input client. The assignment also included the development of a mobile prototype to show how the Police in future will be able to register information at the scene of a road traffic accident. The prototype was developed on a Tablet PC, a laptop, and the essay also describes the work that was done and the theories that were used during the prototype development. Words: Usability, STRADA, positioning, prototype, mobile GUI

5 Förord Jag vill tacka min handledare på KTH Rosa Gudjonsdottir, för kunskap, inspiration och glada skratt. Jag vill även passa på att tacka min handledare på Sweco Position, Katarina Malmberg, för tron på vad användaraspekten kan tillföra i utvecklingsprojekt. Främst vill jag tacka min mamma, Yvonne Sundqvist, för allt stöd under min utbildning. Utan henne hade dessa rader aldrig blivit skrivna. /Annika

6 Innehållsförteckning 1 INLEDNING Bakgrund Problemformulering Syfte Avgränsning Terminologi TEORI OCH METOD ISO-standarder Designprocessen Kontextuella intervjuer Intervjuguide Prototyper Scenarios Etiska Principer STRADA OCH RAPPORTERINGSPROCESSEN Systemuppbyggnad Den befintliga polisklientens utseende TILLVÄGAGÅNGSSÄTT I PROJEKTET Förberedelser Fas 1 och 2 Identifiera användargrupper och intervjuer Fas 3 Design Fas 4 Utvärdering Scenario Etiska aspekter UTVÄRDERING OCH RESULTAT Stationära inmatningsklienten Observation i olycksbussen DESIGNFÖRSLAG/LÖSNINGSFÖRSLAG Designförslaget till den stationära polisklienten Mobilprototyp Vad är en Tablet PC? Valet av hårdvara Gränssnitt för Tablet PC Det mobila gränssnittet REFLEKTION ÖVER ARBETET LITTERATURFÖRTECKNING APPENDIX 1 LISTA PÅ INTERVJUADE PERSONER APPENDIX 2 INTERVJUGUIDE APPENDIX 3 - SCENARIO MOBIL PROTOTYP Figurförteckning FIGUR 1. ISO DESIGNPROCESSEN... 6 FIGUR 2. SYSTEMUPPBYGGNAD FÖR STRADA FIGUR 3. DATUM, TID OCH PLATS I DEN BEFINTLIGA POLISKLIENTEN FIGUR 4. POSITIONERINGSVERKTYG I DEN BEFINTLIGA POLISKLIENTEN

7 FIGUR 5. SKISSVERKTYG I DEN BEFINTLIGA POLISKLIENTEN FIGUR 6. ARBETSPROCESSEN/DESIGNPROCESSEN FIGUR 7. BILD PÅ EN VÄGLÄNK FIGUR 8. NY MENY FÖR DATUM/TID FIGUR 9. FÖRSLAG PÅ POSITIONERINGSMOMENTET DÄR OLYCKSPLATSEN ANGES FIGUR 10. MENY FÖR FRAMSTÄLLNING AV SKISS FIGUR 11. FÖRSLAG PÅ NY MENY FÖR INMATNING AV INFORMATION RÖRANDE VÄG OCH TRAFIKFÖRHÅLLANDEN FIGUR 12. FÖRSLAG PÅ NY MENY FÖR INMATNING AV INFORMATION OM TRAFIKELEMENT FIGUR 13. MENY FÖR INMATNING AV OLYCKSBESKRIVNING FIGUR 14. HUVUDMENYN FÖR POLISKLIENTEN FIGUR 15. POSITIONERING FIGUR 16. IN-ZOOMAD POSITIONERING FIGUR 17. TRAFIKELEMENT FIGUR 18. SKISSVERKTYG... 42

8 1 Inledning 1.1 Bakgrund Regeringen gav 1996 Vägverket i uppdrag att utveckla ett informationssystem för trafikskador och trafikolyckor i Sverige. Systemet döptes så småningom till STRADA, vilket står för Swedish Traffic Accident Data Acquisition, och bygger på uppgifter lämnade från polisen och från Sveriges akutsjukhus. Polismyndigheten rapporterar från olycksplatsen, om vilka fordon som varit inblandade, rådande vägförhållanden med mera via en inmatningsklient som kallas polisklienten. Sjukhusen förser STRADA med information om personskador och tillsammans med informationen från polisen ökar detta kunskapen om trafikolyckor i Sverige på ett sätt som inte varit möjligt tidigare. 1 Syftet med den mer strukturerade informationen, som ska ge en tydligare och mer korrekt bild av trafiksäkerhetsläget, är att minska trafiksäkerhetsproblemen och felprioriteringar i trafiksäkerhetsarbetet. Enligt regeringens beslut ska informationssystemet STRADA: Stödja trafiksäkerhetsarbetet på central, regional och lokal nivå Ge underlag som gör det lättare att ur trafiksäkerhetssynpunkt vidta rätt åtgärder Minimera dubbelarbete och kostnader inom offentlig förvaltning. 2 Utvecklingen av STRADA startade under 1998 och sedan 2003 är den offentliga statistiken över vägtrafikolyckor i Sverige tagen från STRADA. Idag är det Vägverket, som ansvarar för STRADA och för utveckling och uppföljning av systemet. En del i detta viktiga arbete, som Vägverket gör, är även att tillhandahålla korrekt information på ett lättillgängligt sätt till olika instanser i samhället så som exempelvis kommuner och forskare. En väl fungerande inmatningsklient ökar kvalitén på data i STRADA, vilket medför att trafiksäkerhetsarbetet blir mer effektivt och resurser sätts in, där det finns behov för det. Om riskerna att göra fel i inmatningsprocessen minskar, kan även riskerna att göra fel vid trafiksäkerhetsarbetet reduceras. Polisen registrerar cirka olyckor per år i STRADA. Det tar i genomsnitt 15 minuter att registrera en olycka med hjälp av polisklienten, vilket innebär en total arbetsinsats på timmar per åri. 3 En förbättring av användargränssnittet kan medföra att kvalitén på inmatad data i STRADA höjs, om användaren har ett väl fungerande stöd i form av en användbar polisklient, samt tillgång till ett så bra underlagsmaterial som möjligt. Sålunda möter detta regeringens två första krav på informationssystemet. Vidare medför en förbättrad polisklient i STRADA även, att antalet arbetstimmar per år kan minskas, vilket är vad krav nummer tre i regeringens beslut tar upp. 1 Vägverkets hemsida Vägverkets hemsida Muntlig kommunikation, Överordnad ansvarig i Bengtsfors,

9 SWECO Position fick i uppdrag av Vägverket att undersöka, hur polisklienten med tyngdpunkt på skiss- och positioneringsverktyget kunde förbättras och göras mer användbar. Uppdraget innefattade även att bygga en prototyp av en framtida mobil lösning, som polisen ute i fält kan använda i sitt arbete med inrapportering av trafikolyckor. I dagsläget använder polisen ett speciellt formulär för att fylla i rapporter om trafikolyckor, som sedan används som underlag för rapporteringen in i STRADA. SWECO Position är ett IT konsultbolag med orientering mot ett geografiskt informationssystem, GIS. Hantering av kartmaterial, presentation, positionering och analyser är exempel på tjänster, som SWECO Position kan erbjuda. 4 Projektgruppen från SWECO Position bestod av tre personer, två lantmätare och jag, examensarbetare i människa-datorinteraktion, MDI. Uppsatsen är en magisteruppsats i MDI vid Kungliga Tekniska Högskolan och redogör för det arbete, som utförts i uppdraget Vägverket gav SWECO Position januari 2006 och som pågick i fyra månader under vintern/våren Problemformulering Hur kan den befintliga STRADA- klienten göras mer användbar, utifrån ett användarperspektiv? Hur skulle en framtida, användbar, mobil lösning av STRADA utformas? 1.3 Syfte Uppsatsens syfte är att förklara hur arbetet med att göra inmatningsklienten till STRADA mer användbar har fortskridit. I detta arbete inkluderas, förutom ett förbättringsförslag på den befintliga stationära polisklienten till STRADA, även utformningen av en prototyp på hur en framtida mobil STRADA-klient skulle kunna tänkas fungera och se ut. 1.4 Avgränsning Uppsatsen är begränsad till att beskriva arbetet med att undersöka hur, utifrån användarperspektiv, STRADAs polisklient kan förändras för att bli mer användbar. Valet av intervjuade personer har begränsats till de poliskontor och andra aktörer, som varit villiga att ställa upp och som det har varit rimligt att intervjua utifrån ett ekonomiskt/tidsmässigt perspektiv. Vidare har den mobila prototypen avgränsats till att endast illustrera skiss- och positioneringsverktyg, då det största problemet, enligt Vägverket och enligt vår undersökning, med inmatningen skiss- och positioneringsverktyg idag, är dessa två bitar. 1.5 Terminologi I uppsatsen förekommer följande ämnesspecifika uttryck, som bör definieras för att underlätta för läsaren. Vissa ord och deras innebörd behandlas mer ingående i 4 Swecos hemsida

10 texten. Aktörer - De personer och instanser, som på något vis, direkt berörs av informationen i STRADA, exempelvis trafiknämnden och kommuner. Användare - I denna uppsats är användare de som jobbar med att registrera olycksrapporter in i STRADA via polisens inmatningsklient, stationär och mobil. Polisklient - Den applikation/ det program, som polisen använder, då de matar in uppgifter i STRADA. GPS - Global Position System, satellitbaserat positionssystem Gränssnitt - Det sätt som användaren och datorn eller maskinen kommunicerar/interagerar med 5 Färddator - Dator inklusive applikation som hjälper en förare att navigera under färd. Brukar finnas i taxibilar. PDA - Personal Digital Assistant är en bärbar dator, som är så liten att den kan hållas i handen vid användning 6 Polisskissen - Den delen i inmatningsklienten där positionering och bilden utförs Prototyp - En enkel modell på ett lösningsförlag till en produkt STRADA - Swedish TRaffic Accident Data Acquisition, databas för trafikolyckor. Tablet PC - Bärbar dator med pekskärm 5 Mayhew, 1999, sid

11 2 Teori och Metod Detta kapitel tar upp en del teorier kring vad användbarhet är och hur ett användarcentrerat arbetssätt bör gå till. Utgångspunkten är designprocessen enligt ISO- standard. Teorier och de metoder, som använts i projektet, redogörs för enligt nedanstående. I kapitlet redogörs det endast för de teorier och metoder som använts i projektet och avslutas med ett kort avsnitt om några etiska principer, som man som undersökare bör ta hänsyn till. 2.1 ISO-standarder Det finns två ISO- standarder, ISO och ISO 13407, som är viktiga för arbete med användbarhet. Den första standarden tar upp användbarhetsbegrepp och den andra definierar designprocessen. Användbarhet är ett ord, som har många olika betydelser, beroende på vem det är, som använder ordet. Den formella definitionen på användbarhet, ISO , är 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: resursåtgå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. Slutligen definieras användningssammanhanget som: användare, uppgifter, utrustning (maskinvara, programvara och annan materiel) samt fysisk och social omgivning i vilken produkten används. 7 Då människa-datorinteraktion härstammar från många olika ämnesområden, bland annat från datalogi, psykologi och ergonomi, finns det inte bara ett sätt att se på vad användbarhet är, vilka mål, som ska uppnås och hur det ska gå till. ISO- standarden ger en bred förklaring och det finns många författare inom MDI, som använder sin egen version av standarden. Nedan följer några exempel på hur olika författare använder sig av begreppet användbarhet. Min personliga uppfattning om användbarhet stämmer bra överens med Preece 8 uppfattning om ämnet, förmodligen för att boken Interaction Design har varit en vanligt förekommande referens under min utbildning. Quesenbery (2004) 9 menar att användbarhet har blivit ett ord för någon typ av idéer om användare, designers, utvecklare och mjukvara. Gemensamt för alla användbarhetsmetoder är att de fokuserar på hela kontexten, att användaren ska klara av sin uppgift, uppnå sina mål och uppnå dessa mål på ett sätt, som stämmer överens med omgivningen. Vidare menar Quesenbury att utveckling av användbara system sker iterativt och att tillvägagångssättet är användarcentrerat, det vill säga att 7 Statskontorets hemsida, Preece, Quesenbery, 2004, sid 4 4

12 under utvecklingen av användbara system bör man sträva efter att förstå användarens mål, uppgifter och krav. Den sista gemensamma punkten är att designen är anpassad för en specifik publik, att systemet tar hänsyn till att människor är komplexa. Quesenbery listar fem aspekter på användbarhet, de fem E:na. 1 Effective; Denna aspekt tar upp om systemet/programmet är användbart genom att hjälpa användaren utföra sina uppgifter. 2 Efficiency; Med vilken hastighet och korrekthet givna arbetsuppgifter kan utföras. 3 Engaging; Hur väl användaren blir engagerad i programmet, det vill säga hur roande, tillfredsställande eller intressant gränssnittet är. Enligt Quesenbery har all mjukvara en känslomässig inverkan på användaren. 4 Error tolerant; Hur väl systemet förhindrar fel och hjälper användaren att korrigera eventuella misstag denne begått. Den riktiga utmaningen är att se hur väl ett system hjälper användaren att korrigera ett fel, när det väl uppstår. 5 Easy to learn; Syftar på hur väl systemet hjälper användaren under arbetet. Vissa uppgifter kan vara enkla att utföra, medan andra kan vara mycket komplexa. Systemet ska ge stöd åt en nybörjare såväl som åt en expert. Alla fem aspekterna är viktiga för att uppnå hög användbarhet i ett system. Hur dessa ska balanseras är dock en organisatorisk fråga beroende på hur den slutgiltiga produkten ska vara, hur organisationen ser ut och vilka människor, som ska använda produkten. För polisen och polisklienten är alla E:na lika viktiga. Mayhew (1999) 10 ger en annan definition på vad användbarhet är och är mer inriktad på kvantitativa metoder. Hon menar att det är mätbara egenskaper i ett gränssnitt, som avgör, hur mycket eller lite användbart systemet är. En mätbar egenskap är hur lätt det är att använda gränssnittet beroende på om du är nybörjare eller expert. En annan dimension är hur lätt det är att använda ett gränssnitt utifrån aspekter som effektivitet och flexibilitet. Vidare menar författaren att för att uppnå användbarhet i en interaktiv produkt, som exempelvis en mjukvara måste vissa behov och krav fastställas och programmet måste anpassas till dessa. Mayhew tar upp fyra faktorer, som påverkar användbarheten 1 Kognitiva, perceptuella och motorisk kapacitet och begränsningar människor generellt har. 2 Speciella och unika karakteristiska drag hos slutanvändarna. 3 Unika karaktärsdrag i användarens psykiska och fysiska arbetsmiljö. 4 Unika karaktärsdrag och behov i användarens arbetsuppgifter, som ska stödjas av systemet. 5 Unika kapaciteter och begränsningar i mjukvaran eller i hårdvaran som den slutgiltiga produkten ska finnas på. Författaren menar att ett användbart system ska öka produktiviteten i ett företag, minska inlärningstiden men även minska risken att data tolkas eller förs in fel i systemet. Alla dessa aspekter medför i slutändan minskade kostnader för företaget. 10 Mayhew, 1999, sid 1-2 5

13 Nästa författare, Preece (2002) 11, menar att syftet med interaktionsdesign är att designa användbara interaktiva produkter. Med användbara menas produkter som är lätta och effektiva att använda, men också en produkt som uppfattas som behaglig att jobba med. 12 För att utveckla ett användbart system krävs en bra modell för hur själva arbetsprocessen bör gå till. ISO standarden är en enkel modell över hur användbarhetsarbete, att designa användbara system, bör utföras. Enligt Jokela 13 ger denna standard inte en heltäckande bild av hur arbetet med att designa användbara system går till. Standarden ger endast en tillfredsställande beskrivning över arbetet med att beskriva användaren och dess miljö men ger en mindre heltäckande hjälp i hur användbarhetsmål uppnås och hur användbarhet utvärderas och mäts. Figur 1. ISO Designprocessen 2.2 Designprocessen Enligt Preece (2002) 14 är första steget i designprocessen att identifiera behov och krav hos användaren. Datorer och datorsystem ska utvecklas till att bli ett stöd för användaren i hennes arbete och utgångspunkten måste då vara användarens arbetsmiljö och sätt att arbeta. 15 Arbetet börjar med att undersöka och lära känna den miljö som användaren arbetar i, det vill säga identifiera olika behov som kan finnas. Exempel på företeelser att studera kan vara den praktiska interaktionen mellan människa och dator, det vill säga studera när en person använder sig av ett datorprogram, men även de sociala strukturer som råder på arbetsplatsen. Syftet är att förstå vilka faktorer som kan påverka hur systemet används, när det slutligen 11 Preece, Preece, 2002, sid 2 13 Jokela, Iivari, Matero & Karakurra, Preece, Gulliksen, 2000, sid 15 6

14 implementeras. Det räcker inte att enbart rita ett flödesschema eller skriva en kravspecifikation över hur det önskade systemet ska fungera utan det är viktigt att den tysta kunskapen, den som är inbyggd i organisationen som de sociala och fysiska förhållandena, också undersöks. Exempel på vanligt formulerade krav kan vara att systemet ska vara enkelt att använda men detta begrepp innebär olika saker för olika personer och organisationer. För en nybörjare kan exempelvis enkel att använda betyda att det finns få funktioner synliga, men tydligt beskrivna på skärmen, samtidigt men för en expert är det enklare att ha alla funktioner synliga på skärmen för att lättare kunna utföra sina arbetsuppgifter. Första steget i designprocessen bör därför inkludera alla aspekter av kunskapsinsamling i syfte att förstå slutanvändaren i ett större sammanhang. Uppgifter som samlas in kan exempelvis vara användarnas kunskapsnivå, utbildning och träning, hur ofta de använder ett visst datorprogram eller vilka arbetsuppgifter de har. 16 En viktig del i detta arbete är att ta användarens behov på allvar och verkligen lyssna på vilka krav som ställs på det nya systemet. Gulliksen (2002) har en annan definition på detta arbete. Han kallar detta arbete för användaranalysen och menar att syftet med denna analys är att definiera olika användargrupper och vilka egenskaper dessa olika grupper har. Användargrupper är kategorier av olika användare som definierats efter olika egenskaper. I det fortsatta arbetet ska de olika användargruppernas önskemål tas hänsyn till. De olika grupperna kan vara mer eller mindre lättdefinierade beroende på vilka egenskaper, som ska definiera grupperna. I vårt arbete baserades de olika användargrupperna på hur ofta användarna rapporterade i polisklienten. Andra egenskaper att identifiera kan vara om användaren är nybörjare eller expert på det arbete som ska undersökas, man eller kvinna eller om de har lite eller mycket datorvana. 17 Det finns andra mer komplexa egenskaper att undersöka och dessa kan vara, hur mycket tid, som användaren kommer att lägga på utbildning i det nya systemet, i vilken kontorsmiljö användaren kommer att jobba med systemet eller vilken akademisk utbildning användaren har. En intressant aspekt över systemets användbarhet kan bero på hur väl användarna accepterar det befintliga systemet, och det kan därför vara betydelsefullt att inkludera denna information i de olika användargrupperna. När olika typer av användargrupper definierats och formats, är nästa steg att göra en uppgiftsanalys. Denna analys ska ge kunskap om vilka uppgifter användaren utför och hur dessa utförs. Frågorna kan enligt Gulliksen vara av typen; 18 1 Varför utför användaren en viss arbetsuppgift? 2 Hur ofta utförs arbetsuppgiften? 3 Samarbetar användaren med någon annan? 4 Vilka andra hjälpmedel behöver användaren för att utföra uppgiften? Uppgiftsanalysens syfte är att kartlägga alla de funktioner systemet måste ha, att tydligt formulera i skrift vilka krav och behov som finns för att användarna ska kunna utföra sitt arbete på ett tillfredsställande sätt. För detta finns det många olika metoder och tekniker att samla in all information. Exempel på detta är workshops, 16 Gulliksen, 2000, sid Gulliksen, 2000, sid Gulliksen, 2000, sid 31 7

15 fokusgrupper eller enkätundersökningar, men de vanligaste är strukturerade intervjuer och observationsintervjuer. Omständigheterna kring projektet, tillgång till användare, ekonomi, eller beroende på vad det är som ska designas, påverkar vilken metod som passar bäst. Oberoende av vilken metod som används ska denna del av designprocessen resultera i en kravlista, där alla krav och behov ska finnas samlade. Enligt Preece (2002) 19 bör olika tekniker användas för att få en så bred uppfattning om kontexten som möjligt. Olika metoder tydliggör eller belyser olika sorters krav och behov. Listan som formuleras i uppgiftsanalysen bör också inkludera användbarhetsmål för hela designprocessen. Användbarhetsmål är punkter där just användbarhetsaspekterna, som kan skilja sig från exempelvis en kravspecifikation, som enbart tar upp funktionaliteten, tas upp. Exempel kan vara om hur lång inlärningstiden bör vara, hur lång tid det ska ta för användaren att lösa en viss uppgift och med ett visst antal fel. Den samlade listan över användbarhetsmålen är dock inte något, som är ristat i sten, utan i likhet med hela designprocessen, förändras den ständigt allt eftersom designprocessen fortgår och interaktionsdesigner stöter på nya möjligheter och problem. 20 Enligt Gulliksen (2000) 21 är användarmålen nödvändiga för en iterativ designprocess, eftersom målen indikerar om arbetet går mot rätt håll. Uppnås målen, som ställts upp, på ett tillfredsställande sätt, kan processen komma till ett slut. Tredje steget i designprocessen är att utforma en tänkt lösning på alla funktioner och önskemål, som de första stegen resulterat i. Mycket av arbetet ligger i att designa ett gränssnitt, som är användbart för användaren. Fokus på designen ska inte vara att designa ett snyggt gränssnitt, även om en tilltalande skärm förhöjer upplevelsen av systemet, utan att utforma ett system och gränssnitt, som är effektivt och som uppfyller alla krav från användargrupperna. Arbetet kan delas in i två delar, den begreppsmässiga modellen, som tar upp vilka funktioner som ska finnas med och hur de ska fungera och den fysiska modellen där de mer grafiska detaljerna, så som meny- och ikon- utseende, diskuteras. Den begreppsmässiga modellen ligger till grund för den fysiska men i likhet med övriga steg i designprocessen sker detta arbete iterativt och det är vanligast att olika sorters prototyper används för att utvärdera olika designförslag. Utvärderingen av olika förslag är den sista punkten i designprocessen. Utvärderingen finns till för att testa att användarna kan använda systemet på ett tillfredsställande sätt och att de tycker om det. Beroende på vad det är som ska testas, vem som ska testa och förväntningarna på vad utvärderingen ska generera, finns det olika metoder och tekniker att tillämpa. Utvärderingen ska utformas så att den ger svar på frågor om exempelvis designen eller om användaren har speciella krav som måste tillgodoses. 22 För att, enligt min erfarenhet, en utvärdering ska bli lyckad som möjligt krävs noggrann förberedelse. Det är viktigt att ha ett visst fokus vid utvärderingen och att detta har fastställts innan utvärderingen äger rum, exempelvis bör man fastställa vilka frågor som är viktigaste 19 Preece, 2002, sid Preece, 2002, sid Gulliksen, 2000, sid Preece, 2002, sid 319 8

16 att få besvarat. En annan viktig aspekt är att använda metoder och tekniker som man behärskar eftersom mötet med användaren ska generera så mycket värdefull information som möjligt och inte störas av tekniska eller administrativa problem. En av många metoder för utvärdering är quick and dirty utvärdering, som är ett enkelt, snabbt och informellt sätt att få feedback från användarna och andra intressenter. Quick and dirty -metoden går ut på att ställa frågor direkt om prototypen, på ett informellt och avslappnat sätt. Metoden kan användas när som helst under designprocessen, eftersom den är snabb och okomplicerad, vilket gör det lätt för utvecklaren att använda ute på plats och i systemets naturliga kontext. Dokumentationen av en quick and dirty -utvärdering är informell och har ofta med korta noteringar eller skisser. Tyngdpunkten ligger istället på de snabba reflektionerna den genererar. 23 Det finns även andra sätt att få svar på frågorna som utvärderingen ska bidra till. Exempelvis kan användarna observeras, när de interagerar med systemet eller så kan användarna eller experterna få svara på frågor om systemet. När användarna tillfrågas är det viktigt att de får reflektera fritt över vad som är bra och dåligt, vad de tycker om och vad de ogillar. Det är därför viktigt att utformningen på prototypen är anpassad så att användaren får möjlighet att reflektera och ge svar på de frågor, som behövs bli besvarade. För att summera vad hela designprocessen går ut på är det att med hjälp av olika metoder, som är anpassade efter rådande förhållanden, undersöka och utvärdera hur användarna arbetar. I arbetet som utfördes i detta projekt användes kontextuella intervjuer, olika varianter av prototyper samt ett scenario för att underlätta vid utvecklingen av den mobila prototypen. 2.3 Kontextuella intervjuer Syftet med användarmedverkan är att designa system, som är anpassade efter den riktiga kontexten och verkliga arbetssituationer. Kontextuella intervjuer är ett bra sätt att undersöka användaren och systemet i dess rätta miljö och ger då designern värdefull information för det fortsatta designarbetet. Genom att förstå varje individ I hennes arbetsmiljö kan en helhetsbild över problemområdet formas, den ursprungliga kravbilden breddas och får fler dimensioner/aspekter. Då användaren och designern sitter tillsammans vid datorn kan de tillsammans utarbeta vad systemet ska kunna utföra, hur det ska göra det och vad det är som ska leda fram till de olika handlingarna. 24 Ett sätt att undersöka hur användaren arbetar kan vara att tillämpa lärlingsmodellen i dessa intervjuer. Lärlingsmodellen fungerar som gamla mästare lärlingrelationen, där mästaren besitter all kunskap och förmedlar den till lärlingen, medan arbetet fortgår. Lärlingen i detta fall är designern och användaren, som är expert på sitt eget arbete, tar mästarrollen. Lärlingen följer med, tittar på, när mästaren utför sina uppgifter och stannar upp och ställer frågor, när någonting är oklart eller extra intressant. De observationer som görs bör bekräftas, på något sätt, av mästaren för att säkerhetsställa att lärlingen uppfattat situationen eller situationerna på ett korrekt 23 Preece, 2002, sid Beyer & Holtzblatt,,

17 sätt. Detta görs för att inte designern ska gå därifrån med fel blid av arbetet och vad det är som systemet ska stödja. Ett exempel kan vara att lärlingen upprepar vad mästaren precis gjort. Eventuella missförstånd kan då upptäckas. Fördelar med lärlingsmodellen är att det inte krävs någon förkunskap av designern/lärlingen och inga förberedelser av mästaren, som bara utför sitt vanliga arbete. Det är just användaren som är experten på sitt eget arbete och därför får designern expertutlåtande på vad det är systemet ska stödja. Användaren är ofta inte expert på att tala om sitt arbete men på detta sätt kan mästaren tala om sitt arbete medan det utförs, vilket kan vara enklare. Lärlingen bör under tiden som observationen äger rum vara uppmärksam på strukturer inom organisationen. Fördelarna med att använda detta sätt i projektet var att polisens arbete innefattar mycket ny teminologi och inbyggd kunskap om exempelvis trafikregler och denna kunskap skulle ta lång tid att sätta sig in i vilket gjorde att intervjuerna tog karaktären av lärlingsmodellen. 2.4 Intervjuguide Under kontextuella intervjuer då designern följer användarens jobb, är det användaren, som visar vad den anser är viktigt. Beroende på vilken position eller vilka arbetsuppgifter användaren har prioriteras olika saker och beroende på vem som tillfrågas är vissa aspekter av arbetet viktigare än andra. Det är därför viktigt att designern är väl medveten om vad det är som ska undersökas och kan styra intervjun med sådana frågor, som är relevanta att veta för det som ska designas. Har designern ett tydligt fokus underlättar detta att ta in mer relevant information, då fokus ger designern ett ramverk att utgå ifrån och koncentrera sig på under intervjun. 25 Intervjutillfället inleds med att designern presenterar sig själv och berättar om i vilket syfte intervjun görs och vilka villkor som respondenten har, exempelvis att informationen kommer att behandlas konfidentiellt och att det är användarens arbete, som är i fokus och inte personen i sig. Vid detta tillfälle ber man även om ett godkännande att spela in intervjun om så är fallet. Sedan får respondenten presentera sig själv, sin position och sina arbetsuppgifter. Denna inledande fas är ett tillfälle för alla att lära känna varandra och känna sig mer bekväma i situationen. Innan den verkliga kontextuella intervjun sätter igång är det viktigt att man förklarar för respondenten hur resten av intervjun ska gå till, att designen följer användaren under hennes arbete och avbryter och ställer frågor om någonting är oklart. Det är viktigt att tydliggöra att det är arbetet i sig som är intressant, att det inte handlar om prestation, utan att verkligen se hur användaren jobbar. Under huvuddelen av intervjun, då arbetet studeras, är det viktigt att diskussionen är så konkret som möjligt genom att få användaren att förklara verkliga situationer istället för att sväva ut i abstrakta förklaringar. Under intervjun förs anteckningar, och alla händelser dokumenteras. Intervjun avslutas med att allmänt summera vad som iakttagits och respondenter, får en chans att lägga till något eller korrigera eventuella missuppfattningar Beyer & Holtzblatt, 1998, sid Beyer & Holtzblatt,1998, sid

18 2.5 Prototyper Det finns många olika sätt att visa och utvärdera en produkt innan den anses som en färdig slutprodukt. En prototyp, oavsett med vilken teknik den är utformad, tillåter berörda personer att få en uppfattning om den framtida produkten. Prototypen är inte enbart något som går att testa och utvärdera utan en prototyp fungerar även som ett diskussionsunderlag mellan olika aktörer, som har olika intressen av och kunskaper om, hur den framtida produkten ska fungera. En prototyp fungerar som ett kommunikationsverktyg mellan olika aktörer som använder sig av olika ordförråd när de ska beskriva olika funktioner eller beteenden. Prototypen ger extra stöd åt den verbala kommunikationen eftersom aktörerna kan peka och visa på prototypen samtidigt som de talar om den. 27 Ett sätt att dela in olika prototyper är i Low-Fidelity (Lo-Fi) och High-Fidelity (Hi-Fi) prototyper, ett annat ord är offline- och online- prototyper. 28 Lo-Fi är prototyper, som är gjorda av enkla och billiga material som exempelvis papper och är därför enkla att göra om, förändra eller kasta, om något inte är bra. Exempel på Lo-Fi prototyper kan vara storyboarding eller skisser. En skiss är en väldigt enkel Lo-Fi prototyp, som innefattar papper och penna. Ett sådant sätt att arbeta eller att förklara något är mer inbjudande att komma med egna infallsvinklar och förslag. En skiss är enkel, snabb och arbetsbördan för att framställa en skiss behöver inte vara krävande, vilket kan ha den positiva effekten att en person känner sig mer inbjuden, mindre rädd att göra fel, att föreslå egna idéer och lösningar. En prototyp är en idé, som någon annan skapat och som skaparen vill ha synpunkter/feedback på, ett objekt, som man kan kommentera och diskutera kring. Det är lättare att ifrågasätta något där arbetsinsatsen bakom är mindre än något som har krävt mycket arbete. Skisser kan hjälpa till att förklara något, som är svårt att beskriva verbalt. Skisser behöver inte tas på så stort allvar och därför kan de generera fler idéer och fler radikala idéer, just på grund av att de går att slänga eller kan ersättas.syftet med en pappersprototyp är att ge snabb feedback på designen, medan produkten fortfarande är under utveckling. 29 I Hi-Fi prototyping används material och tekniker, som är mer likt den slutliga produkten. Fördelarna med en sådan prototyp är, att den är funktionell och kan användas vid tester och utvärdering av produkten. Exempel på Hi-Fi prototyping kan vara en prototyp utvecklad i en mjukvara som exempelvis MS Director eller Visual Basic. Ett problem med Hi-Fi prototyper är att de kan verka så avancerade och färdiggjorda att det kan, för användaren, verka skrämmande att fråga eller kritisera. Det kan även vara så, att man inte vill kritisera något, som någon har lagt ner mycket tid på att utveckla. Även om en pappersskiss kanske har tagit lika lång tid att göra, så är det lättare att kritisera den än något på datorn. Fördelarna med Hi-Fi prototyper är att den i större grad liknar den slutgiltiga produkten, vilket kan underlätta för användaren under en utvärdering. Nackdelarna kan vara att användaren fokuserar på fel saker, som exempelvis färgsättning eller att en knapp är något felplacerad. Det är viktigt att vara lyhörd, när prototypen utvärderas, då designern själv har en 27 Beaudouin-Lafon & Mackay, 2003, sid Preece, 2002, sid 241; Beaudouin-Lafon & Mackay, 2003, sid

19 förförståelse om vad som kan vara problem men att användaren upplever prototypen på ett annat sätt. Man bör inte försöka bekräfta sina egna förslag utan att ta till sig så mycket som möjligt av feedback på prototypen. En väl förberedd utvärdering och en genomarbetad prototyp kan underlätta insamlingen av synpunkter, eftersom ett mer seriöst upplägg får användaren att förhoppningsvis lägga ner mer tid och tanke åt prototypen. I vissa fall, exempelvis med quick and dirty prototypen, är det dock just den spontana reaktionen designern är ute efter. Det viktigaste att tänka på är att anpassa prototypen till den rådande kontexten. Även om det är en enkel pappersprototyp så måste den vara väl genomtänkt och uppfylla sitt syfte. En väl förberedd utvärdering av prototypen minimerar även risker som att försöka hjälpa användaren under utvärderingen, då det blir lättare att hoppa in och försöka förklara detaljer, som inte är genomtänkta. En utvärdering på en prototyp som inte är väl förberedd löper risken att bara ta upp de funktioner/idéer, som designern söker bekräftelse på och kan då lätt glömma bort att utvärdera andra delar av prototypen, eftersom designern inte behärskar hela prototypen. Det är lättare för användaren att komma med åsikter och påverka den slutgiltiga produkten, om det finns redan något att kommentera eller reflektera kring. En prototyp, oberoende av vilken typ av prototyp det är, låter användaren interagera med det tänkta systemet, vilket då möjliggör för användaren att förstå hur det slutgiltiga systemet kan tänkas fungera i den rätta miljön och med de önskade arbetsuppgifterna. Prototypen gör det lättare för designern och användaren att diskutera olika problem och lösningsförslag, eftersom det ger en bra utgångspunkt för diskussion. Det är lättare att förklara vad man menar om man har ett fysiskt föremål att peka på. Prototypen behöver inte endast ses som ett kommunikationsverktyg mellan designern, användaren och andra intressenter utan också som ett verktyg för designern själv. Genom att utforma prototypen tvingas designern att själv reflektera över sina idéer och tankar. När designen får se sina skisser framför sig kan designen te sig annorlunda än när den bara existerar i tankarna. Problem som lätt går att glömma i fantasins värld blir tydliga och andra lösningar kan bli aktuella. Vidare kan olika alternativa lösningar jämföras med varandra, oklarheter kan redas ut och nya lösningsförslag kan generas. 30 Gulliksen (2000) menar att prototyping möjliggör följande: 31 1 Utforska nya lösningar 2 Prova funktionalitet 3 Hitta krav 4 Träna kreativitet; möjlighet att lära sig att bli bättre 5 Hitta svagheter 6 Testa prestanda, utseende etc. 7 Prova sekvenser av kommandon Beroende på typen av system som ska utvecklas och beroende på var man befinner sig i design- (utvecklingsprocessen)processen ser prototypmetoderna och teknikerna olika ut. Det viktiga är, att prototypen visar det som ska testas och diskuteras Löwgren & Stolterman, 2004, sid 39; Preece, 2002, sid Gulliksen, 2000, sid Preece, 2002, sid 247; Gulliksen, 2000, sid 41 12

20 2.6 Scenarios Syftet med scenarios är att beskriva en möjlig framtid och hur olika alternativa systemlösningar skulle kunna tänkas se ut. Inom området för människadatorinteraktion används scenario för att visa på användbarheten med systemet och hur användbarheten ska kunna öka. Vanliga användningsområden för scenarios, är analyser på användarbruk, framtida användarbruk samt utformandet av utbildningsmaterial. Ett scenario är en beskrivning och innehåller fyra komponenter, aktörer, bakgrundsinformation om aktörerna och antaganden om omgivningen, aktörernas mål och krav samt arbets- och uppgiftsflöden. 33 Designern kan skriva olika typer av scenarios beroende på projektets kontext, vilken fas projektet befinner sig i eller vilken aspekt av systemet som ska behandlas. Scenarios kan användas som huvudmetod under ett utvecklingsarbete eller som ett komplement till andra metoder för att täcka områden, där andra metoder är otillräckliga. 34 Enligt Go och Carroll (2004) 35 hjälper scenariobaserad utveckling till med att involvera användaren, eftersom det är riktiga fall som ska testas, underlättar kommunikationen mellan aktörerna samt hjälper till att illustrera framtida okända arbetsuppgifter för användarna. Scenarios underlättar att sammanställa det fortsatta utvecklingsmaterialet och fungerar även bra som brainstormingunderlag i arbetet att planera, eftersom scenarios kan visa upp olika alternativ och kan på så vis påverka planering och beslutsfattandet. Fördelarna med scenarios är bland annat att de belyser dolda (oväntade) problem, som kan uppstå i ett befintligt eller framtida system. När ett scenario skrivs tvingas designern, i likhet med prototyparbetet, att tänka på vad och hur användaren handlar och hur systemet ska fungera utifrån denna användare och kontext. Det är således ett sätt att fokusera på riktiga eller påhittade händelser, vilket tvingar designern att arbeta med detaljer och på den faktiska miljön runt omkring den framtida lösningen Etiska Principer Enligt HSFR finns det ett antal regler som bör följas för att en intervju ska vara etiskt korrekt. Reglerna kan delas upp fyra kategorier och innebär följande; Informationskravet: Regeln säger att alla deltagare ska informeras om deras uppgift i projektet. Undersökningens syfte och en beskrivning av undersökningens utförande, samt vilka villkor, som gäller och att det är frivilligt att delta (att deltagaren får avbryta medverkan när hon/han vill). Det är viktigt att eventuella risker och obehag, som undersökningen kan innebära, redovisas, då detta tillsammans med undersökningens syfte kan påverka deltagandet. Respondenterna ska informeras om vad materialet från intervjun ska användas till. Samtyckeskravet: Deltagarna har själva rätt att bestämma över sin medverkan. Regeln säger att forskaren alltid ska få samtycke av deltagaren och att hon själv har rätt att bestämma om, hur länge och på vilka villkor hon ska delta. Deltagaren ska kunna avbryta sin medverkan utan negativa konsekvenser för henne. Hon får försöka motivera deltagaren att fortsätta sin medverkan, men får aldrig försöka med negativa 33 Go & Carroll, 2004, sid Carroll, Rosson & McInerney, 2003, sid Go & Carroll, 2004, sid Go & Carroll, 2004, sid 45 13

21 påtryckningar eller påverkan. Forskaren får inte heller sätta sig i någon maktposition till deltagaren. Därför ska undersökningen i så stor utsträckning som möjligt utformas så att enskilda individer inte ska gå att identifiera. Det är inte alltid detta går, men då ska samtliga etiska principer följas, så att deltagaren inte känner sig tvingad på något sätt, utan deltagaren vill medverka för att kunna bidra med sin kunskap. Konfidentialitetskravet: Innebär att den insamlade informationen inte ska spridas hur som helst samt att respondenterna inte ska kunna pekas ut om informationen sprids vidare. Nyttjandekravet: Den information forskaren får tillträde till ska handskas med försiktighet och om uppgifterna vidarebefordras måste forskaren ta det ansvar, som informationen kräver. Sista principen ska skydda deltagaren för att uppgifter om denne inte ska användas till andra beslutsfattanden och åtgärder utan deltagarens medgivande. 37 Dessa etiska aspekter togs i beaktande i största möjliga utsträckning när intervjuerna utfördes och då det insamlade materialet behandlades. 37 Etik HSFR,

22 3 STRADA och rapporteringsprocessen För att lättare kunna läsa uppsatsen och följa resultatet och designbesluten i projektet innehåller detta kapitel en beskrivning av hur STRADA är uppbyggt och hur rapporteringsprocessen hos polisen går till. 3.1 Systemuppbyggnad Systemuppbyggnad RMV db Krypterad överföring Vägverket All information behandlas och förvaras i krypterad form SIKA Officiell statistik STRADA db 2 avidentifierad Obduktions - rapporter STRADA db 1 Djupstudie db uttag Vx djupstudier Krypterad överföring Uttagsklient Kommun, VV m.fl Sjukhus Polis Lokal rapportklient med db, med alla icke klara rapporter Figur 2. Systemuppbyggnad för STRADA 38 Bilden visar hur hela STRADA-systemet är uppbyggt och vilka aktörer som är kopplade till trafiksäkerhetsarbetet. Bilden visar att både polisen och sjukhusen registrerar i STRADA men de olika myndigheternas inmatningsklienter ser olika ut. Rapporteringskedjan hos polisens efter det att en trafikolycka inträffat kan förklara på nedanstående sätt; Polis Registrator Vägverket Trafiknämnden & Kommuner Trafikanter Polisens registrering av olyckor i STRADA sker idag i två steg. På olycksplatsen fyller de ansvariga poliserna i blanketten Informationsunderlag vägtrafikolycka. I blanketten finns fält för att ange all den information, som senare skall registreras i STRADA. Blanketten lämnas sedan till en registrator, som använder polisklienten för att föra in informationen i STRADAdatabasen. En registrator kan vara polisen själv men också en annan polis eller en civilanställd. Majoriteten av alla registratorer är 38 Bild från SWECO 15

23 civilanställda 39. I några fall sitter poliser och registratorer i samma lokaler och har en nära kontakt med polisen som varit ute vid olyckan men i andra fall skickas pappersrapporterna iväg till en annan ort, där registreringen sker. Samtliga trafikolyckor i Västa Götaland registreras exempelvis i Bengtsfors men det vanligaste sättet är att polisen och registratorn sitter på samma kontor 40. STRADA är utvecklat av AeroTech och de sköter idag även förvaltningen av systemet. AeroTech har utvecklat algoritmen som ligger bakom olyckstypsklassificeringen, som är en viktig del i hanteringen av data för att bygga säkrare vägar. Olyckstypsklassificeringen, som sker automatiskt utifrån vad registreraren har matat in för data, ligger till grund för många av Vägverkets analyser kring arbetet att göra Sveriges vägar säkrare. 3.2 Den befintliga polisklientens utseende Polisklienten består utav fem olika moment, datum, position, väg/trafik, trafikelement och olycksbeskrivning. På bilden nedan visas de som de fem röda runda lampor, som ska behandlas. När ett moment är påbörjat lyser lampan gult och när hela momentet är korrekt ifyllt lyser lampan grönt. Det är inte nödvändigt att fylla i momenten i en viss ordning. Däremot finns det information, som endast går att fylla i om man fyllt i andra uppgifter tidigare, ett exempel på detta är att det krävs att en bil är registrerad innan förare och passagerare registreras. Figur 3. Datum, tid och plats i den befintliga polisklienten. Figur 3 visar även hur momentet datum, tid och plats ser ut. Uppgifter som ska fyllas i är om var och när olyckan inträffade och även administrativ information som diarienummer och när rapporten senast är ändrad. 39 Muntlig kommunikation VV, STRADAsamordnare, Muntlig kommunikation, VV, Beställare,

24 Figur 4. Positioneringsverktyg i den befintliga polisklienten. Positionering och olycksskissmomenten innehåller många funktioner och det var Vägverkets önskan med projektet att titta extra noga på hur dessa båda moment skulle kunna göras bättre. Sidan visar hur användaren kan söka efter olika vägnamn, orter eller genom x och y koordinater. Det finns även funktioner för att lägga till en väg, utfart, om den saknas i kartmaterialet. Under kartan finns en horisontell rad med knappar vars funktioner tillåter hantering av kartan, exempelvis in och ut zoomningsknapp. Figur 5. Skissverktyg i den befintliga polisklienten. Skissmomentet innebär att användaren först lokaliserar olycksplatsen och sedan ritar upp, med hjälp av färdiga symboler, hur det såg ut på olycksplatsen. 17

25 4 Tillvägagångssätt i projektet Uppgiften från Vägverket var att genomföra en förstudie, som ger förslag på hur polisens inmatningsklient till STRADA kan förbättras. Syftet med förbättringsförslagen är dels att höja kvalitén på de data, som läggs in i STRADA och dels att göra olycksregistreringen effektivare. I följande kapitel finns en redogörelse för hur arbetet med förbättring av inmatningsklienten har gått till. Praktiskt har arbetet med den stationära och den mobila lösningen skett parallellt och under besöken på polisstationen i Malmö har diskussioner om den mobila prototypen ägt rum. Identifiera Identifiera önskemål från önskemål VV från VV Definiera olika användare utifrån hur inmatningsklienten används Få feedback på de nya designförslagen. Bengtsfors och Malmö Levererad mobilprototyp Intervjuer Stockholm, Bengtsfors och Malmö; 2 iterationer Diskutera, skissa och designa förbättrad design; 2 iterationer Figur 6. Arbetsprocessen/Designprocessen 4.1 Förberedelser Designprocessen första fas är att förstå vad det är den slutgiltiga produkten ska göra och i vilken miljö den ska finnas i. Arbetet innefattar att fastställa kraven från användarna, i det här fallet de som registrerar i polisklienten och de instanser, Vägverket, Trafiknämnden samt polisen som kommer att påverkas av det slutgiltiga systemet. Arbetet inleddes med att ta reda på vad det var Vägverket ville ha hjälp med och utifrån diskussioner med personer med god kännedom om polisklienten och STRADA, och dess befintliga problem, utarbetades en projektplan. Från SWECOs och min, sida var ett av kraven att få tillgång till användare, det vill säga möjlighet att få träffa poliser och andra personer som registrerar trafikolyckor. En kopia av polisklienten införskaffades i syfte att bekanta oss med applikationen före det första mötet med användaren. Anledningen till att vi ville känna igen klienten var för att kunna ställa frågor direkt om användarens arbete istället för hur programmet fungerade då registreringen innebär att användaren har kunskap om trafiktermer och trafikregler, som inte är självklar för en utomstående. 18

26 Vägverket, hade uttryckt ett missnöje över användbarheten med skissmomentet och för att förstå, vad det var för problem, bekantade vi oss med polisklienten för att sedan kunna fokusera mer på detaljer kring arbetet med skiss- och positioneringsmomenten. Vid den första intervjun med användare, som ägde rum i Stockholm, uttrycktes även andra problem förutom skissverktyget vilket därför resulterade i att det fortsatta arbetet inkluderade även andra användbarhetsaspekter än enbart skiss- och positioneringsmomentent. 4.2 Fas 1 och 2 Identifiera användargrupper och intervjuer Första steget i designprocessen är att identifiera och prioritera olika användargrupper, vilket även skedde i detta projekt. Vi fick hjälp av Vägverket att hitta olika typer av användare och poliskontor, där hanteringen av olycksrapporten skilde sig åt. Önskemålet var att få träffa några experter, personer som använder inmatningsklienten ofta och har stor erfarenhet av att registrera trafikolyckor men även att få träffa några sällananvändare, användare som tillbringar endast några få timmar i veckan med att registrera. Vägverket uppgav tre olika platser för oss att besöka och som skilde sig åt i hanteringen av olycksrapporteringen. Poliskontoren som rekommenderades och som besöktes var Stockholm, Bengtsfors samt Malmö. För en fullständig lista över personer som intervjuades se appendix 1. I Stockholm intervjuades en anställd som på heltid registrerar olycksrapporter i STRADA. Denna typ av användare klassades som expertanvändare, på grund av att användaren arbetade med polisklienten dagligen och flera timmar varje dag. Vid Stockholmskontoret fanns även en person som var nybörjare på att registrera i polisklienten och vi passade på att intervjua även henne, då det var intressant att veta vilka problem en nybörjare kan ha med polisklienten. Intervjuerna var intressanta eftersom det framgick att expertanvändaren hade vant sig vid att använda polisklienten och påpekade därför inga större problem hon hade inte eller många synpunkter om den, mer än att visa hur hon arbetade. Nybörjaren hade betydligt fler kommentarer till, som hon tyckte, ologiska knappar och arbetsflöden. Inmatningsklienten är ett verktyg som används i det dagliga arbetet på poliskontoren. Utifrån ett användbarhetsperspektiv, behöver inte klienten vara anpassad till nybörjare eftersom den typen av användare inte förekommer ofta, då användarna till största del är rutinerade användare. Intervjun med nybörjaranvändaren gav oss ändå nyttig kunskap och uppmärksammade detaljer som de mer rutinerade användarna inte längre reflekterar över. I Östergötland sköts all inmatning i STRADA, för hela länet, i Bengtsfors av några personer. Intressant är att användarna sitter långt från poliserna som rapporterar från olycksplatsen och har ingen eller väldigt lite direktkontakt med dessa poliser. Användarna i Bengtsfors ägnar endast ett par timmar i veckan åt att registrera i STRADA. Användarna i Malmö intervjuades, eftersom kontoret har den enda trafikolycksbussen i landet. Poliserna där är experter på att ta hand om trafikolyckor, vilket gör att inmatningsprocessen även där skiljer sig från de andra berörda kontoren. Malmökontoret skiljer sig från de övriga kontoren i den aspekten att avståndet mellan polis och användare är litet, det vill säga polisen och användaren sitter i samma lokaler och ibland kan även polisen som varit närvarande vid 19

27 olycksplatsen själv sköta inmatningen i STRADA. Sättet Malmökontoret rapporterar, det vill säga det korta avståndet mellan polis och registrator, är det som är dominerande för resten av landet 41. Efter att ha identifierat olika typer av användare kunde intervjuer förberedas och det fortsatta arbetet planeras, som exempelvis möten och resor till de olika poliskontoren.för att få en bättre förståelse vad och hur data i STRADA används, intervjuades även två personer på Trafiknämnden i Stockholm och även personal från Vägverket, som arbetar med STRADA. En intervjuguide upprättades och finns att läsa i appendix 2. Intervjufrågorna utformades efter litteraturen och med hjälp av min handledare. Frågorna gjordes om en gång från att vara generella frågor till att innehålla mer specifika frågor om specifika arbetsuppgifter. Detta gjordes på inrådan av min handledare i syfte att kunna tyda mina egna anteckningar, att i efterhand lättare kunna förstå vad som observerats i de olika menyerna. Enligt henne kan en generell intervjuguide, med allt för öppna frågor, göra det är svårt att i efterhand veta vad som diskuterats och vilka synpunkter, som tillhörde vilka delar. 42 Frågorna hjälper även som stöd under intervjuerna eftersom de satte de mest intressanta delarna i fokus. Varje intervju började med att användaren fick presentera sig och vilka arbetsuppgifter de hade. I Malmö och Bengtsfors inleddes mötena med en allmän diskussion om STRADA och hur arbetet generellt sköttes med rapporteringsprocessen och inmatningsklienten. Denna del av intervjun användes för att bilda en uppfattning om vilka attityder, som fanns över inmatningsklienten men också för att kartlägga hur rapporteringsprocessen, från trafikolycksplatsen till det att all information hamnat i STRADA, på varje polisstation gick till. Intervjun övergick därefter till att studera användaren under rapporteringsprocessen och ägde rum framför den dator och på den plats, där användaren normalt utför sin inmatning. Användaren ombads att beskriva, vad de gjorde och även reflektera över saker, som hon uppfattade som bra eller dåliga med inmatningsklienten. För att inte missa några viktiga synpunkter kompletterades studien av frågor från intervjuguiden. Sista delen i intervjuguiden innehöll frågor som användes för att få användaren att summera och att knyta ihop arbetet men även för att ge användaren ett tillfälle att tillägga något de ansåg vara viktigt att få med som inte kommit med tidigare. Efter varje intervju sammanställdes ett dokument över kommentarer, positiva så väl som negativa, som behandlats under intervjutillfällena, allmänna åsikter om STRADA, problemområden och även uttryckta förbättringsförslag. Detta dokument skickades sedan till de olika personerna, som deltagit, som en möjlighet för dem att korrigera eventuella missförstånd eller ta bort eller rätta till någon information. I Malmö finns Sveriges enda olycksbuss. Det är en buss som är utrustad att hantera olika typer av trafikolyckor och andra problem, som kan uppstå i trafiken. Poliserna som arbetar med olycksbussen är specialister på att hantera olika olyckor och är därför vana att fylla i informationsunderlaget till Vägtrafikolyckor. På Malmökontoret arbetade poliserna och rapportörerna sida vid sida vilket, innebär att poliserna vid detta kontor kände till inmatningsklienten och dess syfte. 41 Muntlig kommunikation, VV, STRADAsamordnare, Muntlig kommunikation, Handledare,

28 Observationen ägde rum under en eftermiddag, då jag fick följa med två poliser i olycksbussen. Syftet med observationen var att få en förståelse för hur trafikpolisens arbete ute i fält ser ut. För att kunna göra en användbar mobil prototyp var det viktigt att ha kunskap om hur arbetsförhållandena var, vilka maskiner och metoder som användes i arbetet samt även passa på att ta reda på vad som skulle vara önskvärt i en mobil inmatningsklient. Förhoppningarna var även att få en inblick i vilka attityder som fanns till att använda sig utav datorer i arbetet, och speciellt vilken attityd poliserna hade till att använda en inmatningsklient ute i fält. Observationen utfördes i bussen, utan några färdigskrivna frågor, och anteckningar utfördes löpande under hela observationen. Olycksbussen är unik och representerar inte en generell bild över hur vanliga trafikpoliser arbetar men dessa poliser är experter på att rapportera om olyckor och har stor kunskap om hur olyckor inträffar och vilka faktorer som kan påverka en olycka. Därför var dessa polisers kunskap mycket värdefull för utformningen av prototypen. Fördelen med att få tillhandahållet namn på användare var att vi inte behövde lägga ner mycket arbete på att identifiera och söka upp olika användare, som annars kan ta mycket arbete att få användare att ställa upp. Nackdelen var att dessa poliskontor var nära knutna till arbetet med STRADA, det vill säga att dessa kontor hade under någon tidsperiod varit involverade i Vägverkets utveckling av inmatningsklienten, och detta kan ge ett annat resultat än om användaren befinner sig på ett kontor, som inte har samma attityd till inmatningsklienten. Ett system där användarna får vara delaktiga i utvecklingen accepteras lättare/snabbare av organisationen. Systemet designas för användarna utifrån deras önskemål, vilket gör att designen blir mer lätt använd och ger ett större stöd deras arbete. Det vill säga de personer som varit inblandade i utvecklingen av inmatningsklienten kan ha högre acceptansnivå, och därför inte uppleva användbarhetsproblemen på samma sätt som andra användare Fas 3 Design Det är viktigt att ta hänsyn till användarna i designen, att hela designen utgår ifrån deras behov, krav och förväntningar. 44 I designfasen ska de idéer och behov, som mötena med användarna och aktörerna givit, övergå till ett eller många designförslag. Efter det att samtliga kontor besökts, och både användare och aktörer blivit intervjuade började arbetet med att sammanställa alla behov, idéer och intryck. Projektgruppen samlades för att diskutera och analysera våra intryck. Resultaten av det första mötet var en lista med funktioner, som kunde förbättras samt en lista med oklarheter som vi vände oss till Vägverket med. På detta första mötet diskuterades allmänt om våra intryck från mötena med användarna och det visade sig att vi alla hade en snarlik bild av vilka problem som fanns. Efter det första mötet ägde även ett kort möte med Vägverket rum, där frågorna vi hade, besvarades. Vid detta möte framkom det att Vägverket ville att den mobila prototypen skulle vara utvecklad för en bärbar dator, eftersom polisens framtida arbetssätt ute i fält är tänkt att hjälpas av bärbara datorer. 43 ROI; 2002, sid Gulliksen, 2000, sid 15 21

29 Vid det andra mötet med Vägverket hade många frågetecken rätats ut och själva designprocessen satte igång. Alternativ på lösningar skissades upp och som hjälp till designarbetet användes utskrivna skärmdumpar på den befintliga inmatningsklienten. De största problemen, som identifierats, var att hitta en bättre lösning på positionerings- och skissverktyget, vilket vi redan hade fått indikationer på. Då inmatningsklienten varit i bruk under fem år, är den väl inarbetad och uppmaningen från Vägverket och från användarna var att inte göra alltför stora förändringar. Grundtanken bakom lösningsförlaget blev därför att försöka bibehålla så mycket av den befintliga designen och funktionaliteten som möjligt och endast ta bort eller lägga till element som underlättade arbetet för användarna. Det övergripande förbättringsförslaget var att göra arbetsflödet smidigare, att minimera hoppandet mellan olika moment, då vi upptäckte att användarna nästan uteslutande använde sig av TAB-tangenten. Därför samlas exempelvis uppgifter om olyckans positionering på ett ställe istället och att uppgifterna som är obligatoriska och vanligt förekommande kommer före de mindre vanliga uppgifterna som ska endast fylls i ibland. Arbetet med att diskutera och skissa på olika lösningsförslag skedde vid tre möten totalt och de handgjorda skisserna ritades sedan upp i Visual Studio. Det fanns två anledningar till att skisserna ritades i Visual Studio. Den ena för att användarna lättare skulle kunna relatera till sin vanliga arbetssituation, det vill säga, användaren skulle fokusera på funktionerna istället för på upplägget. Den andra anledningen var att uppfattas som professionell inför kunden och visa upp ett snyggare resultat än handgjorda skisser. Ett avstämningsmöte med Vägverket ägde rum efter det att förbättringsförslagen utarbetats. Vid detta möte uttryckte Vägverket att de ville att fokus skulle ligga på att utveckla den mobila klienten och därför upphörde arbetet med den stationära klienten efter endast en utvärdering och korrigering. Designlösningen för den mobila prototypen utarbetades med det stationära lösningsförslaget som bakgrund och med de intryck och den kunskap som samlades in under observationen i olycksbussen. Den mobila prototypen utvecklades för att visa hur skiss- och positioneringsverktyget skulle kunna se ut. Gränssnittet för den mobila lösningen skissades upp på papper av mig och lösningsförslagen diskuterades sedan med en utvecklare på SWECO Position, som då utvecklade prototypen i Visual Studio. 4.4 Fas 4 Utvärdering Utvärdering är ett tillfälle för användaren att testa och kommentera de nya designlösningarna. Det är även ett tillfälle för designern att ställa frågor, som uppstått under designarbetet, men även rätta till eventuella missförstånd som syns i prototypen. När vårt lösningsförslag på den stationära polisklienten var ritat i Visual Studio började utvärderingen. Malmökontoret besöktes och där fick de utvärdera designförslagen. Malmökontoret var det enda kontoret, som besöktes för utvärdering. Två användare hos Malmöpolisen togs i anspråk för utvärdering och designförslagen visades upp på en bärbar dator, för att demonstrera hur den nya inmatningsklienten skulle kunna se ut. Utvärderingen övergick sedan till skärmdumpar på designen, som skrivits ut på papper. Dessa användes för att underlätta för användarna att lättare kunna peka och rita sina kommentarer. Vid detta tillfälle berättade en person, att de 22

30 inte var intresserade av polisklienten, eftersom polisen själv arbetade på en egen inmatningsklient, vilket var information som de precis hade tagit del av. På grund av denna kunskap hade användarna tappat lite av intresset för utvärderingen av polisklienten och feedbacken på designen blev därför lidande. På grund av resurser, tid och resekostnader, begränsades utvärderingen till en träff med Malmökontoret och även om de andra kontoren fick chans att kommentera lösningsförslagen fick vi ingen respons. Önskvärt vore att även få träffa användarna från Bengtsfors och Stockholm för en utvärdering, eftersom deras önskemål och krav i intervjuerna skilde sig något från Malmökontoret, vilket skulle kunna ge andra synpunkter på lösningsförslagen. Utskrivna skärmdumpar skickades via post till Stockholm och kontoret i Bengtsfors för kommentarer men ingen av användarna där valde att kommentera lösningsförslagen. Förmodligen för att de hade fått samma information som Malmökontoret, att det skulle komma en ny inmatningsklient som polisen utvecklat. Kommentarerna från utvärderingen i Malmö resulterade dock i några förändringar i förbättringsförslagen. Under hela designprocessen hade vi kontakt med de STRADA-ansvariga på Vägverket, som jobbat med förbättringar kring STRADA i många år. Dessa personer hade god kunskap om vilka problem som finns i STRADA idag, dels från insamlade användarsynpunkter men även från vilka krav Vägverket och andra myndigheter ställer på informationen från STRADA. Kommentarerna från utvärderingarna från Malmökontoret och synpunkterna från avstämningsmötet sammanställdes och en ny designlösning gjordes och det är dessa designförslag som redovisas för i kapitel Scenario I arbetet med den mobila prototypen användes ett scenario av tre anledningar. Den första och främsta anledningen till att ett scenario användes var för att få struktur på designarbetet. Scenariot underlättade att fokusera på en sak åt gången istället för att börja tänka på andra tänkbara situationer. Ett av problemen jag stötte på när designen för den mobila prototypen skulle utformas var att hitta en början på designen. Det fanns många olika idéer i mitt huvud att jag upplevde det svårt att få någon struktur på designarbetet, därför skissade jag till slut upp ett scenario/arbetsflöde som jag kunde följa och utveckla designförslagen utifrån. Det andra skälet till att använda scenario var för att underlätta kommunikationen med utvecklaren, att lättare kunna förklara för honom hur jag ville att prototypen skulle fungera. Detta underlättade i hans arbete också, att förstå vad det var han gjorde för något, då han inte hade någon djupare kännedom om den bakomliggande polisklienten. Den sista orsaken till att scenario användes var för att kunna vara förberedd, när prototypen visades upp för kunden. En väl fungerande demonstration av ett scenario, uppfattas som mer professionellt och tilltalande än att endast visa upp bilder av en prototyp. Användaren får en än bättre förståelse för produkten om hon får interagera med den. Prototypen var endast utvecklad till att följa ett scenario där två bilar krockar i en korsning. Användaren får söka upp platsen och därefter rita ut hur bilarna krockade. Jag visade upp prototypen och lät sedan kunden prova på själv genom att följa instruktioner om vilka steg, som hon skulle utföra. Hela scenariot finns att läsa i appendix 3 och det var samma scenario som användes i utvecklingsarbetet. 23

31 4.6 Etiska aspekter I enlighet med de etiska principerna informerades alla respondenter om sina rättigheter och villkor för intervjun. Respondenterna fick veta syftet med intervjun och att det var frivilligt att delta och intervjun kunde avbrytas om de så önskade. Det finns dock ett frågetecken över hur etiskt korrekta intervjuerna var, eftersom respondenterna i Bengtsfors och Stockholm inte blev informerade om det fortsatta arbetet med den mobila prototypen. Frågor kring en mobil framtida lösning skulle kunna verka avskräckande eftersom en framtida mobil inmatningsklient skulle bortrationalisera registratorns arbetsuppgift. För att vara säker på att det som antecknades under observationen var korrekt skickades en individuell sammanfattning till respektive respondent, för att ge dem möjlighet att korrigera eventuella missuppfattningar. 24

32 5 Utvärdering och resultat Besöken på de olika poliskontoren,trafiknämnden och kontakten med Vägverket gav oss information om vilka moment och funktioner, som användarna var nöjda med, vilka funktioner som var värda att behålla, men även vilka moment som ställer till problem och skapar irritation hos användarna. I följande kapitel redovisas först de resultat från mötena där den stationära polisklienten behandlades och därefter följer en redogörelse från intervjun från observationen i olycksbussen. 5.1 Stationära inmatningsklienten Idag använder 70 personer polisklienten för att registrera olyckor i STRADA. Några användare arbetar flera timmar varje dag med att registrera olyckor, medan andra användare registrerar olyckor vid enstaka tillfällen. 45 Majoriteten av användarna ägnar någon eller några timmar i veckan till att registrera olyckor. Därför bör användargränssnittet till polisklienten vara anpassat till samtliga typer av användare. Det skall dels vara tillräckligt enkelt för att de personer, som sällan arbetar med polisklienten att förstå, hur olyckor registreras på rätt sätt samtidigt som de som använder polisklienten ofta behöver ha ett effektivt användargränssnitt. Dagens polisklient innehåller fem olika moment Datum, tid och plats, Position/Skiss, Väg/Trafik, Trafikelement och Olycksbeskrivning. Ett problem med menyerna är att innehållet inte alltid är anpassat efter den ordningsföljd, som informationen registreras, vilket gör att arbetsflödet allmänt uppfattats som hackigt. Registreringen sker utifrån polisens inlämnade rapport från olycksplatsen, där informationen följer en viss ordning. I dagsläget tvingas användaren växla mellan de olika momenten istället för att fylla i ett moment fullständigt och därefter gå vidare till nästa. Användarna uttryckte en önskan att polisrapporten och polisklienten följde samma ordningsföljd. Ett exempel på hur arbetsflödet väckte irritation var att informationen om olyckans position inte är samlad på ett ställe utan finns utspritt i Datum, tid och plats och i Position/Skiss. Användarna ifrågasatte även ifall all information var nödvändig att fylla i, då vissa begrepp/fenomen inte längre existerar. Enligt Vägverket finns det många uppgifter, som är inaktuella och som ska uppdateras eller tas bort. 46 Då denna typ av information kräver stor kunskap om trafikarbete och STRADA i allmänhet, inkluderades inte dessa uppdateringar i detta projekt. En detalj som observerades var att expertanvändarna använde TAB-tangenten genom hela rapporteringsprocessen. En förbättring skulle vara att TAB-lägena följde arbetsflödet bättre. Vid registreringen av olyckor i polisklienten ägnas merparten av tiden till att framställa den skiss, som illustrerar olyckan. Samtidigt upplever de, som använder information i STRADA för att analysera olyckor, att olycksskissen ofta innehåller alltför lite detaljer för att ge en tydlig bild av olyckan. För att olycksskissen skall bli tydligare, och samtidigt underlätta för användarna vid registrering, innehåller lösningsförslaget en mer detaljerad och aktuell bakgrundskarta. En bättre karta underlättar för användarna som inte sett den verkliga olycksplatsen att hitta den exakta positionen, exempelvis ett övergångsställe, och det finns ytterligare detaljer som exempelvis 45 Muntlig kommunikation, VV, STRADAsamordnare, Muntlig kommunikation, VV, STRADAsamordnare,

33 trafikljus eller väglinjer markerade, som underlättar vid detaljbeskrivningen av olyckan. Idag söker användaren upp positionen i en karta och väljer sedan att skapa ett skissunderlag, där själva olyckshändelsen ska illustreras. Detta moment, där användaren hoppar från en karta till en mindre detaljerad bakgrundskiss är onödig. Vi föreslår att användaren istället letar upp positionen och zoomar in till önskat läge i kartan. Skissen kan då ritas direkt på kartunderlaget, och risken för att skissen bli felaktig eller feltolkas minimeras. Under intervjuerna framkom det även att användarna upplevde koppling av väglänkar, det vill säga markeringen av berörda vägar och färdriktning, som problematiskt. En väglänk visas som ett tunt sträck i mitten av en väg, se figur 7. Det moment, där de inblandade fordonen kopplas till länkar i vägnätet, upplevdes som motsägelsefullt och svårt att förstå. Då till exempel en motorväg representeras av två väglänkar, en för vardera körriktning, kan en bil i vissa fall tvingas, på grund av datatekniska problem, kopplas till fel länk på motorvägen för att olyckan skall kunna registreras. Det ser då ut som om bilen färdades mot trafiken, när den i själva verket befann sig på rätt länk. Det vore naturligtvis en fördel om kopplingen kunde göras till rätt länk. Under projektets gång förbättrades just denna funktion och vid det andra mötet hos Malmöpolisen visade det sig att problemet var löst. Figur 7. Bild på en väglänk När användarna skulle skissa upp olyckan observerades att flera användare lade ner mycket tid åt att få kartan inzoomad till1:400. Detta förklarades med att de tidigare fått instruktioner på att kartan skulle vara inzoomad till 1:400 för att ritsymbolerna och trafikelementen skulle passa i storlek. Ett av de stora problemen var att i dagens polisklient finns ingen funktion som automatiskt sparar data som lagts in. Detta uppfattades som mycket frustrerande av användarna eftersom användarna ibland lägger ner mycket möda på att skissa olyckan. Ibland händer det dessutom att systemet hänger sig, när en 26

34 olycksregistrering sänds till den centrala databasen för arkivering. All information, som har lagts in, går då förlorad och olyckan får registreras om på nytt. Vissa av användarna sparade rapporten med jämna mellanrum för att undvika att arbetet går förlorat. Lösningen på problemet borde vara att arbete sparas automatiskt och kontinuerligt av polisklienten, vilket minimerar risken för att stora arbetsinsatser går förlorade. Det är även viktigt utifrån ett användarperspektiv att användaren inte blir alltför irriterade på klienten, eftersom detta ökar risken för att rapporteringen blir fel eftersom användaren inte vill lägga ner mer tid på att göra om den förlorade rapporten. Det finns dock ett problem och det är att polisklienten är baserad på en programvara som inte längre utvecklas. Det går därför inte att lösa detta problem med dagens arkitektur, eftersom det är svårt att göra stora förändringar då programmeringskoden och algoritmen för olycksklassificeringen inte går att förändra alltför mycket. Kunskapen om detta problem är dock något som kan användas i den mobila lösningen. Den skiss över olyckan, som framställs i polisklienten innehåller ofta alltför lite information. För att skapa en bättre olycksskiss bör det kartunderlag, som används som underlag vara så detaljerat som möjligt. En lösning kan vara att kommunerna tillhandahåller detaljerad kartinformation. Vilken information som kan tillhandahållas varierar från kommun till kommun. De flesta kommuner kan dock tillhandahålla detaljerade kartor, som innehåller gator, byggnader, träd, staket osv. Under intervjuerna framkom det även att när användarna har fyllt i alla uppgifter och ska godkänna rapporten med den olycksklassificering som genererats, står det endast en kod vilken olyckstyp som genererats. Under en intervju, hämtade en av användare ett papper med förklaringar till olyckskoden från en bokhylla. På frågan om de skulle vilja ha denna information i klienten svarade hon ja. Samma användare uttryckte önskemål att ha mer hjälpinformation överlag i klienten. Trafikolycksrapporterna som lämnas in efter en olycka är idag av skiftande kvalité. Anledningen till detta tror man kan bero på att poliserna inte förstår syftet med att fylla i dem ordenligt. Informationsspridning om syftet med STRADA bland poliser skulle kunna höja kvalitén på de handskrivna rapporterna, uppgiften kan ses som mindre viktig ute på en verklig olycksplats. I dagsläget ska den vakthavande polisen ha det övergripande ansvaret att rapporten är korrekt ifylld, men det händer, trots detta, att rapporter som kommer in är ofullständiga eller slarvigt ifyllda. En mobil lösning där polisen själv kan se framför sig vilken och hur mycket information som krävs för en fullständig rapport skulle kunna förbättra kvalitén på data i STRADA. 5.2 Observation i olycksbussen När arbetet med den stationära polisklienten ansågs vara klart, från kundens sida, övergick arbetet till att designa en framtida mobil prototyp. Observationen i olycksbussen inleddes med en allmän diskussion om vad de berörda poliserna ansåg om att i framtiden använda sig av en dator vid rapporteringsprocessen. Det framkom att de upplevde datorer som lite skrämmande och ville helst inte behöva använda dem för mycket. En av poliserna förklarade att de trodde att de yngre poliserna, som är vana att använda mobiltelefoner och liknande utrustning, förmodligen kommer att kunna ta till sig den nya teknologin bättre. Respondenterna trodde, att de yngre poliserna förmodligen kommer att tycka att 27

35 jobbet med att registrera olyckor blir roligare, om de har häftig utrustning till hjälp att utföra uppgiften. Under observationen i olycksbussen kunde jag se att poliserna använder en bärbar dator i sitt dagliga arbete. Datorn används framförallt för att kontrollera status, exempelvis körförbud, för bilar i trafiken. För detta krävs internetuppkoppling och vid besöket i bussen var vi tvungna att stanna bussen i tjugo minuter för att all utrustning skulle fungera och datorn kunde kopplas upp mot polisens egna nätverk. Problemet med uppkopplingen berodde på att datorutrustningen, som polisen använde, var vanliga sladdar, som låg huller om buller i bussen. Det tjugo minuter långa avbrottet, på grund av svårigheterna att få datorns uppkoppling att fungera ordentligt, skapade en viss irritation hos poliserna men när kontakten väl var upprättad flöt arbetet på. Bussen var inredd som ett minikontor med skrivbord, stolar, skrivare och bokhylla med olika typer av formulär, som används i polisens arbete. Polisen i passagerarsätet hade den uppkopplade bärbara datorn i sitt knä, medan bussen körde och polisen utförde sitt arbete. Vid ett tillfälle uttryckte en av poliserna en önskan att bussen skull utrustas med en färddator, då de ibland upplevde det svårt att hitta vägen. All form av kommunikation med andra poliser eller poliskontor skedde med internradio eller via mobiltelefon. De summerade intrycken av observationen i olycksbussen var att poliserna initialt är rädda för att använda ny utrustning och teknologi men att de i själva verket använder sig av många olika typer av högteknologiska hjälpmedel i sitt arbete utan att reflektera över det. En mobil dator där polisen själv kan registrera olycksinformation i fält kommer säkert att tas emot olika från person till person. Vissa poliser kommer att tycka att det är ett bra verktyg, som underlättar olycksrapporteringen och andra kommer att tycka att den mobila datorn är komplicerad och gör olycksrapporteringen än mer betungande. Bäst kvalité på informationen i STRADA fås förmodligen med en kombination av dagens arbetssätt och en mobil dator. En mobil klient utvecklas för att användas av de poliser, som rapporterar mycket information till STRADA och som är positiva till att arbeta med ny teknik. De poliser, som endast sällan rapporterar olyckor eller som är tveksamma till att använda en mobil klient, kan fortsätta att arbeta enligt dagens system. En stor fördel med en mobil klient är att polisen direkt kan se, vilken information som redan finns tillgänglig om olycksplatsen och vilken information, som behöver kompletteras eller eventuellt korrigeras. Den mobila klienten skulle även kunna utformas så att den hjälper till med att säkerhetskolla hela rapporten, så att samtliga uppgifter har registrerats. Intrycket, jag fick från observationen, vilket också bekräftades av poliserna, var att den bästa lösningen för dem vore en diktafon eller taligenkänningsmaskin. Taligenkänning skulle vara det bästa alternativet för poliser ute i fält, som inte vill ägna sig åt pappersarbete. I en diskussion med beställaren från Vägverket avfärdades denna idé eftersom de menade att Polismyndigheten inte skulle acceptera en sådan lösning. Därför fortsatte arbetet med att göra en lösning på en bärbar dator eftersom det är det polisen använder idag. 28

36 6 Designförslag/Lösningsförslag Designlösningarna som presenteras i detta kapitel bygger på information som samlats in vid mötena med användarna, STRADA-samordnare och från litteratur om design av användbara interaktiva produkter. Designförslagen som presenteras för den stationära polisklienten har genomgått två iterationer. Den mobila prototypen utvecklades och implementerades på en Tablet PC. Kapitlet avslutas med en redogörelse för vad en Tablet PC är och vilka aspekter som bör tas i beaktande, när ett gränssnitt designas för den. 6.1 Designförslaget till den stationära polisklienten Designförslagen till den stationära polisklienten är en vidareutveckling av dagens polisklient och består av samma fem moment Datum/Tid, Olycksposition/Skiss, Väg/Trafik, Trafikelement och Olycksbeskrivning. Datum/Tid Figur 8. Ny meny för Datum/Tid. I Datum/Tid har vi valt att samla inmatning av allmän, grundläggande information. Informationen matas in på i stort sett samma sätt som idag. De olika fälten fungerar på följande sätt: Län Kommun Datum Tid Diarienr Väljs i rullgardinsmeny på samma sätt som idag. Väljs i rullgardinsmeny på samma sätt som idag. Fungerar på samma sätt som idag. Fungerar på samma sätt som idag. Fungerar i stort sett som idag men siffrorna fylls på ifrån vänster för att undvika att operatören behöver stega med piltangenterna. Uppgiftslämnare Fungerar på samma sätt som idag. Det är dock möjligt att markera rutan Okänd istället för att skriva in texten okänd. Idag ges dock 29

37 det här fältet ofta värdet okänd, eftersom det som regel är omöjligt att tyda namnet på den polis som har signerat Informationsunderlaget. Om uppgiften är viktig behöver blanketten informationsunderlag ges en ruta, där polisen textar sitt namn. Reg. Datum Senast ändrad Registrator Fungerar på samma sätt som idag, dvs. när rapporten började registreras Samma som tidigare, information om när rapporten senast ändrades. Den inloggade registratorns namn fylls i, inget förändrat. Utelämnade fält i Tid/Datum Vid intervjuer med olika användare av polisklienten har behovet av vissa fält ifrågasatts. Utifrån de här synpunkterna har bland annat följande fält tagits bort: Myndighetskod Förekommer i idag i momentet: Datum, tid, plats. Om informationen avser platsen där olyckan skett kan den beräknas när olyckan getts en position. Om den däremot avser vilken myndighet, som den polis som tagit hand om olyckan tillhör, bör den kanske vara kvar. Olyckstyp Förekommer i idag i momentet: Datum, tid, plats. Olyckstypen beräknas och godkänns, när olyckan registreras, det vill säga olyckstypen godkänns sist i arbetsprocessen. Olycksposition / Skiss Figur 9. Förslag på positioneringsmomentet där olycksplatsen anges. I den befintliga klienten ska användaren fylla i gatunamn för olyckan i momentet Datum/Tid, all information om olycksplatsen har denna designlösning samlats under Olycksposition/Skiss istället. 30

38 I detta förslag har den tidigare separata polisskisskartan tagits bort. Istället ska användaren få en uppfattning att de ritar direkt i kartan. En ram i kartan visar det område, som kommer att klippas ut och fungera som skissunderlag. Ramen kan flyttas och det är möjligt att zooma in eller ut för att skissen skall täcka ett lämpligt område. Vyn för positionering visas i figur 9 och vyn för skissverktyget visas i figur 10. Zoom-funktioner Knapparna som ligger horisontellt nere till vänster (Figur 9). Hela kartan: Panorera Zooma in Zooma ut Fungerar på samma sätt som idag. Zoomar ut tills hela kartan visas. Fungerar på samma sätt som idag. Genom att dra och släppa panoreras kartan Det är möjligt att klicka en gång i kartan och få in-zoomning kring den markerade punkten eller att markera en rektangel som visar den yta man skall zooma till. Det är möjligt att klicka en gång i kartan och få ut-zoomning kring den markerade punkten eller markera en rektangel som visar hur stor ut-zoomning, som skall göras. 1:400 Ny knapp som skall underlätta zoomning till 1:400. Klickar på positionen i kartan så zoomas kartan in till 1:400 med den valda positionen i centrum. Mätavstånd Identifiera Fungerar på samma sätt som idag, mäter avståndet mellan två punkter i kartan. Gör det möjligt att peka på ett objekt för att visa attributinformation, exempelvis gatunamn. Positionering Innehåller verktyg för att söka fram olyckspositionen, positionera olyckan samt göra en olycksplatsbeskrivning (Figur 9). Väg/Gata/Ort Fält (A & B)där det är möjligt att skriva in olika textsträngar för sökning. I en rullgardinsmeny visas de alternativ, som motsvarar aktuell textsträng. Texterna är begränsade till aktuell kommun. Det är även möjligt att söka på adress, dvs. gatunamn och nummer men även landmärken. Returtangent ger sökning, Tab hoppar till nästa fält. Fälten A och B har ytterligare en funktion. När de länkar, där olyckan har skett har markerats i skiss-menyn, visas namnen på de markerade samt kringliggande länkar i fälten A och B. I en rullgardinsmeny är det nu möjligt att välja namnet på väg A respektive B. 31

39 X, Y Möjlighet att ange olyckans position genom X-och Y-koordinater från GPS, istället för att ange ett vägnamn. Sök Olycksplats Position Osäker position Utför sökning. Sökning zoomar så att hela det sökta objektet finns med i bilden eller så att vi får en zoomning på 1:400. Om GPSkoordinater finns positioneras olyckan omedelbart utifrån dessa. Fungerar på samma sätt som idag men är flyttad från momentet Datum,Tid,Plats. Knapp som ger markör för att positionera olyckan. Om koordinater finns positioneras olyckan utifrån dessa. Det är sedan möjligt att flytta positionen om så önskas, vilket var ett önskemål från användarna. Runt olyckans position läggs en rektangel som visar det område som kommer att klippas ut för att bli en skiss. Rektangeln kan sedan flyttas utan att det påverkar olyckans position. När användaren vill rita en skiss men inte vet exakt var olyckan inträffade och vill då visa att positioneringen är osäker. Framställning av skiss Figur 10. Meny för framställning av skiss. Trafikelement Lägg till väg Menyn ser ut som idag. Numrering av trafikelement utförs dock automatiskt, vilket innebär att den tidigare funktionen Ange unikt trafikelementsnummer försvinner. När ett trafikelement har valts kommer omedelbart en rullgardinsmeny, där det är möjligt att välja trafikelementstyp. I övrigt fungerar placeringen av trafikelement som tidigare. Fungerar på samma sätt som idag. Tillåter användaren att lägga till en väg som saknas i kartan. Denna funktion skulle dock bli 32

40 överflödig om kartorna uppdaterades ofta, till att innehålla aktuell kartdata. Ta bort Färg Ritsymboler Tar bort aktuellt element. Tillåter användaren att byta färg på trafikelementen. Fungerar på samma sätt som idag. En drop-downlista för att välja färg Fungerar på samma sätt som idag. Med undantag att de ritsymboler som används oftast placeras överst i listan, för att bli mer lättillgängliga. Se nedan för kommentarer om ritfunktioner. Övriga synpunkter på hantering av ritsymboler Användarna upplevde det svårt att markera trafikelementen i den befintliga klienten. Därför bör ritsymbolerna kunna hanteras på samma sätt som i t.ex. Word eller PowerPoint. Då symbolen är markerad finns 8 punkter, som kan användas för att förstora eller förminska samt en punkt för att rotera. Det skall vara möjligt att radera en symbol med hjälp av Delete- knappen eller genom att högerklicka och välja radera. Vidare skall den symbol, som är vald, ges en avvikande färg. Det skall även vara möjligt att kopiera och klistra in ritsymboler (Ctrl C Ctrl V) I nedre högra hörnet finns en tabell, som visar de tillagda trafikelementen i skissen. När ett objekt i skissen har markerats för att editeras är det även markerat i tabellen. Om ett annat trafikelement ska editeras finns det två möjligheter att markera detta, antingen genom att klicka på elementet i kartan eller att klicka på det i tabellen. Varje trafikelement i bilden skall ha en unik färg i bilden och samma färg ska användas i tabellen. Väg och Trafik Figur 11. Förslag på ny meny för inmatning av information rörande väg och trafikförhållanden. I figur 11 visas ett förslag på en ny meny för inmatning av uppgifter om Väg och Trafik förhållanden. Menyn ser i stort sett ut som idag med förändringen att det är möjligt att välja flera alternativ i Väderleksförhållanden och Väglag. Fälten där vägarna A & B fylls i sker automatiskt då de följer automatiskt med från momentet då olyckspositionen kopplas till väglänkar, vilket sker i position/skissmomentet. Den 33

41 största förändringen är att ordningsföljden av de olika fälten har ändrats för att vara bättre anpassade till polisernas pappersrapport. Trafikelement Figur 12. Förslag på ny meny för inmatning av information om trafikelement. Momentet Trafikelement har förändrats för att vara bättre anpassat till arbetsflödet. De fält, som är obligatoriska att fylla i, placeras först i menyn och de fält som endast fylls i ibland placeras vid sidan. TAB-tangenten stegar först mellan de obligatoriska fälten, och sedan följer de fält som endast behöver fyllas i för speciella fordon eller olyckor. Nationalitet anges i två fält i menyn, dels för bilen och dels för de personer som färdades med bilen. Rullgardinsmenyerna för de här båda fälten skall fungera på samma sätt så att länder visas i bokstavsordning. Tidigare hade de båda gardinerna olika rangordning på länderna. Olycksbeskrivning Figur 13. Meny för inmatning av olycksbeskrivning. 34

42 I momentet Olycksbeskrivning har en speciell ruta för registrators kommentarer lagts till. Om olycksplatsbeskrivningen i underlaget är bristfällig kan registratorn tolka trafikmålsanteckningarna för att ge en mer detaljerad beskrivning. Detta är dock inte någon objektiv information och bör skiljas från den egentliga olycksplatsbeskrivningen genom att placeras i ett separat fönster. Jag anser efter det att jag observerat användarna att tolkning sker i så stor utsträckning att det måste finnas möjlighet för användaren att kommentera rapporten. Huvudmeny Figur 14. Huvudmenyn för polisklienten Huvudmenyn för polisklienten (figur 14) har i stort sett samma utseende som idag. I övre högra hörnet har ett fält för informationstexter tillkommit. I dagens polisklient finns flera tomma fält, där informationstexter kan visas i de olika menyerna. Syftet med att informationstexter visas i ett fält i huvudmenyn är att ge användaren en bättre överblick och kontinuitet i arbetet. 6.2 Mobilprototyp Vid intervjuer med personer, som arbetar med att analysera olycksinformation i STRADA, har det även framkommit synpunkter på att skissen från polisen innehåller för få geografiska detaljer för att det skall vara möjligt att få en tydlig bild av vad som hänt. Detta är förståeligt. Det är svårt för polisen att på ett blankt papper rita en kartskiss, som innehåller alla de detaljer, som behövs för att få en förståelse för hur en olycka har skett, speciellt i komplicerade trafikmiljöer. Poliserna i fält vet, att polisskissen skapas utifrån ett kartunderlag, men de vet inte alltid vilken detaljnivå kartunderlaget för den aktuella olycksplatsen innehåller. Det finns en risk att de tar med för få detaljer i den kartskiss de ritar, eftersom de antar att kartunderlaget i polisklienten innehåller den information, som behövs. Kvalitén på de skisser, som ritas av polisen, skulle förmodligen förbättras väsentligt om polisen själv kunde se kartan och vilka detaljer den innehåller. Detta skulle vara möjligt om polisen fick tillgång till en fältanpassad polisklient, det vill säga en bärbar dator med den anpassade polisklienten på. Polisen får då tillgång till kartor över olycksplatsen och behöver endast rita in uppgifter om själva olyckan samt de detaljer som saknas i kartunderlaget. Att hitta olyckans position skulle underlättas genom att en GPS integreras i den mobila datorn. Dagens arbetssätt, där polisen fyller i en blankett, som sedan tolkas av en registrator och förs in i STRADA, innebär även en risk för feltolkningar. Dessa feltolkningar skulle minimeras om polisen har tillgång till en mobil version av polisklienten och kan lägga in information i STRADA direkt vid olyckstillfället. Det finns på så sätt möjlighet för en jämförelse och korrigering mellan den verkliga olyckan och skissen. Efter diskussioner med Vägverket, Polisen och en hårdvaruleverantör fattades beslutet att den bästa mobila lösningen skulle vara en bärbar dator med pekskärm, dvs. en Tablet PC. 35