I detta avsnitt presenteras framtagandet av en konceptskiss, en mid-fi prototyp och en heuristisk utvärdering på prototypen.
4.4.1. Konceptskiss
En konceptskiss utvecklades innan prototypen. Konceptskissen bestod av en grov överblick utav gränssnittet till prototypen. Målet med konceptskissen var att se hur alla riktlinjer som identifierats utifrån enkäten och litteraturstudien kunde bemötas via en design.
Figur 6. Konceptskiss inför framtagandet av prototyp.
Konceptskissen bestod utav en grov överblick av gränssnittet samt information kring vad varje ruta skulle innehålla. Genom att anteckna ner vad varje ruta hade för syfte till designen kunde prototyputvecklandet snabbas på. Det skapades endast en konceptskiss då tiden inte räckte till för utvecklandet av flera olika prototyper. Nackdelen med att det endast gjordes en konceptskiss var att det fanns flera outforskade möjligheter att bemöta användarens behov samt designriktlinjer framtagna ur litteraturstudien. I konceptskissen inkluderades inte hur design av förklaringar kan ta form; det var något som inkorporerades i prototyputvecklingen.
4.4.2. Framtagande av prototyp
Utifrån konceptskissen skapades en prototyp (se figur 7) i gränssnittsdesignprogrammet Figma1. Figmas huvudsakliga syfte är att möjliggöra skapandet av interaktiva gränssnitt men har även flera olika användningsfall som UX-design, grafisk design och wireframing. Med hjälp utav Figma skapades en mid-fi prototyp som möjliggjorde interaktion med prototypen, d.v.s att testdeltagare skulle kunna använda prototypen som om det vore i deras egna vardag.
Figur 7. Första iterationen av prototypen.
Då ett resultat från enkätundersökningen i förstudien visade stora skillnader mellan användarnas behov av antingen enkla eller mer detaljerade förklaringar, skapades två versioner av samma prototyp. Dessa versioner var identiska med avseende på gränssnittet samt innehöll samma typ av information utöver själva förklaringen. Skillnaderna mellan förklaringarna baserades enbart på hur pass utförlig förklaringen var; till exempel kunde och samma förklaring formuleras såsom “MAP hos patienten underskrider riktvärdet med
14,29% vilket tyder på organsvikt.” eller “MAP hos patienten ligger på 60 vilket är under riktvärdet.”. Syftet med att implementera två olika versioner av prototypen var således för att
kunna samla in deltagarnas åsikter kring hur pass utförlig en förklaring bör vara.
Prototypen genomgick två iterationer, en från den heuristiska utvärderingen och en från pilottestet. Iterationerna genomfördes med syfte att förbättra prototypen utefter identifierade brister som påvisats under den heuristiska utvärderingen samt pilottestet för att sedan möjliggöra bättre användarupplevelsetester.
4.4.3. Heuristisk utvärdering av prototyp
Den heuristiska utvärderingen utfördes 3 dagar efter att prototypen ansågs vara färdig. Eftersom utvärderingen genomfördes av författaren av denna rapport var det lämpligt att vänta med den heuristiska utvärderingen för att minska risken för hemmablindhet. Utvärderingen följde Nielsens (1994) 10 heuristiker och varje heuristik utvärderades var för sig. Eftersom heuristikerna framförallt fokuserar på användargränssnittets användbarhet
testades inte båda versionerna av prototypen då skillnaden mellan versionerna inte var en del av gränssnittet. Alltså var det inte väsentligt vilken prototyp som utvärderades.
Utvärderingen genomfördes digitalt och alla brister som framkom under utvärderingen antecknades direkt vid fynd. Totalt tog utvärderingen 1 timme att genomföra. Samtliga anteckningar organiserades med hjälp av färgkoder (Grön, gul och röd) som indikerade vilken allvarlighetsgrad bristen klassades som (Wilson, 2013). Genom att strukturera färgkoderna på detta sättet kunde även en prioriteringslista skapas för att lösa de användarupplevelsebrister som påkommits under utvärderingen; d.v.s. om möjligheten fanns kunde röda brister prioriteras och så vidare.
4.4.4. Delresultat heuristisk utvärdering
Utvärderingen identifierade tre gröna, en gul och två röda problem. De tre gröna bristerna som identifierades klassades som gröna då de inte ansågs påverka användarupplevelsen men kunde leda till ett störande moment för den slutliga användaren. Bristerna noterades under heuristikerna (2) Matchning mellan system och verkligheten (en. match between systems and the real world), (6) Igenkänning istället för hågkomst (en. Recognition rather than recall) och (7) Flexibilitet och effektivitet vid användning (en. Flexibility and efficiency of use). Den första bristen som identifierades var framförallt att det inte var självklart om prototypen talade användarens språk, detta berodde på att utvärderaren inte delar vokabulär med användargruppen; språkaspekten blev därför något som studerades närmare under användarupplevelsetesten. Den andra bristen var att det saknades en överblicksvy som inkluderade anamnesen vid första anblick; däremot var det oklart hur detta kan ändras då det är viktigt att endast väsentlig information presenteras på prototypens landningssida för att undvika en överbelastning av användarens kognitiva förmåga. Den sista gröna bristen var att det saknades självklara genvägar för expertanvändare av verktyget, användaren kan alltså inte snabba på användningen av verktyget; däremot ansågs inte denna brist som särskilt allvarlig då en genererad slutsats finns tillgänglig för alla typer av användare oavsett om hen är nybörjare eller expert.
De gula bristerna som identifierades var under heuristik (1) Synlighet av systemstatus (en. Visibility of system status). Bristen var att det enkelt skapades missförstånd över vad som användaren kunde interagera med. Till exempel delade biomarkörerna färg med sepsis vitalparametrar vilket gjorde det svårt att tyda vad som var en knapp eller inte. Färgen kunde i sig indikera att användaren kan interagera med biomarkörerna också, trots att den funktionen inte finns tillgänglig (se figur 8).
Figur 8. Exempel på var misstolkning kan ske.
Slutligen identifierades två röda brister under heuristikerna (5) Felförebyggande (en. Error prevention) och (9) Hjälp användare, känna igen, diagnostisera och reparera fel (en. Help users, recognize, diagnose, and recover from errors). Eftersom prototypen inte är fullständig fanns felmeddelanden inte tillgängliga att utvärdera vilket heuristik 5 och 9 uppmärksammade. Däremot bestod dessa heuristiker som viktiga punkter för vidareutveckling av prototypen, eftersom verktyget är ämnat för sjukvårdspersonal är det ytterst viktigt att verktyget vid eventuella fel uppnår en hög standard för just dessa heuristiker. Huruvida detta kan uppnås blir dock svårt att diskutera då problemen kanske blir aktuella vid skapandet av en high-fidelity prototyp.