Utvärdering av prototyp: Frågedatabas av Mårten Cronander. Innehållsförteckning

Transkript

1 1 (6) Mottagare: Åsa Cajander Mårten Cronander Utvärdering av prototyp: Frågedatabas av Mårten Cronander Innehållsförteckning 1 Inledning Ten usability heuristics Severity ratings for usability problems 3 2 Utvärdering Visning av systemets status Koppling mellan systemet och omgivningen/kontexten Användarens kontroll och frihet Standarder Undvik fel Igenkännande Flexibilitet och effektivitet Minimalistisk design Hjälpa användare känna igen, analysera och avhjälpa fel Hjälp och dokumentation 5 3 Sammanfattning och slutkommentar 5

2 2 (6) 1 Inledning Jag har fått till uppgift att utvärdera Mårtens Cronanders designuppgift. Uppgiften består av en prototyp med ett gränssnitt till en frågedatabashanterare som ska hantera frågor och svar kring hur man arbetar med en ny projektmodell i en organisation. Prototypen finns att beskåda på adressen Jag har valt att använda en heuristisk utvärderingsmetod, Jakob Nielsens Ten usability heuristics. Kopplat till utvärderingsmetoden har jag använt en graderingsskala, även denna utvecklad av Jakob Nielsen: Severity ratings for usability problems. Allt om denna metod - och mer därtill - finns att läsa på Här nedan har jag gjort en enkel översättning: 1.1 Ten usability heuristics 1. Visning av systemets status Systemet skall alltid informera användaren om vad som händer genom korrekt återkoppling inom rimlig tid. 2. Koppling mellan systemet och omgivningen/kontexten Systemet skall tala användarens språk, med ord, fraser och koncept användaren känner till. 3. Användarens kontroll och frihet Användare väljer ofta systemfunktioner av misstag och behöver klart markerade nödutgångar för att lämna den felvalda vägen på ett enkelt sätt. Systemet ska stödja Ångra och Gör om. 4. Standarder Användaren ska inte behöva undra över olika ord, situationer eller händelser i systemet betyder samma sak. Följ plattformskonventioner. 5. Undvik fel Ännu bättre än väl utformade felmeddelanden är att utforma designen så att fel undviks. 6. Igenkännande Gör objekt, händelser och val synliga. Användaren ska inte behöva minnas information från det ena stället i systemet till en annan. Användarinstruktioner ska finnas synliga och lättillgängliga när de behövs. 7. Flexibilitet och effektivitet Systemet ska fungera smidigt för både vana användare och nybörjare. För den vane ska genvägar finnas. 8. Minimalistisk design Dialoger ska inte innehålla information som är irrelevant eller sällan använd.

3 3 (6) 9. Hjälpa användare känna igen, analysera och avhjälpa fel. Felmeddelanden ska uttryckas på vanligt språk - inte i kodform - exakt indikera problemet som uppstått och föreslå en konstruktiv lösning på problemet. 10. Hjälp och dokumentation Även om idealet är att systemet är självinstruerande kan det oftast behövas hjälp och dokumentation. All sådan information ska vara enkelt att söka, fokusera på användarens uppgift, lista konkreta åtgärder att utföra och ska inte vara för omfattande. 1.2 Severity ratings for usability problems 2 Utvärdering 0 = Inget problem alls. Bra! 1 = Endast kosmetiskt problem, behöver inte fixas om det inte finns extra tid över. 2 = Mindre användbarhetsproblem, att ordna detta bör ges låg prioritet. 3 = Betydande användbarhetsproblem, viktigt att fixa, bör ges hög prioritet 4 = Katastrof ur användbarhetssynpunkt. Måste bara rättas till innan produkten lanseras. Egen kommentar katastrof är ett starkt uttryck. Inga människoliv står på spel, men felet måste åtgärdas för att programmet ska bli godkänt. 2.1 Visning av systemets status Databasen har som prototyp en så enkel utformning att det är svårt att bedöma vad som händer eller hur lång tid något kommer att ta. Om inte annat bör prototypen utvecklas så att en sådan bedömning kan göras. Gradering: Koppling mellan systemet och omgivningen/kontexten Språket är bra och enkelt. En stor del av den text som kommer visas på skärmen skapas av användarna själva och borde således vara väl anpassat till användarens egen miljö. Gradering: Användarens kontroll och frihet Några Ångra, Rensa eller liknande knappar finns inte. Ett tänkbart dilemma är att det finns de användare som börjar eller testa att fylla i en fråga, men sedan slutar mitt i. Eller kommer på att de svarat någon annan felaktigt. I prototypen finns inga sådana utvägar synliga. Gradering: 4

4 4 (6) Ett relaterat problem till ovanstående är att det förmodligen vartefter just kommer bli ett antal tomma eller sporadiskt ifylla nonsensposter. Dvs. frågelistan kommer bli onödigt lång med tomma frågor. Dessa måste kunna rensas bort av någon databasmoderator eller motsvarande. Gradering: Standarder Knapparna är stramt och standardmässigt utformade. Bra!! På bilden Läs svar och läs fråga är dock placeringen av knapparna gjorda både över fråglistan och till höger om den. Jag misstänker att de till höger placerade knapparna är kopplade till just en specifik fråga, men utformningen gör att det är svårt att vara säker på det. För att få veta skulle jag förmodligen som användare testa genom trial and error och se vad som händer. På läs fråga finns det också två ex av knappen Läs svar. Vilken knapp ska användaren välja? Det framgår inte. Gradering = Undvik fel De fel som kan uppstå är troligen av den karaktären som tas upp under punkt 2.3 Det framgår inte av prototypen om eller hur några felmeddelanden ska visas. Prototypen bör kompletteras. Gradering = Igenkännande Några användarinstruktioner finns inte tillgängliga i prototypen. Jag antar att det är meningen att programmet ska vara så intuitivt och enkelt att det är självinstruerande. Jag tycker också prototypen visar att så kommer bli fallet designen är enkel och lättfattlig. Förutsätter man att användaren har en viss grundläggande datorvana bör användandet av programmet inte bli svårt. Gradering = 2 Förklaringar till vad programmet gör och kanske döpa programmet till något enkelt (och käckt?) som syns på varje skärmbild borde införas. Detta för att användaren ska veta vilken applikation hon/han har öppen på skärmen. Som det är nu är applikationen helt anonym. Förmodligen kan man tänka sig att användaren har programmet öppet tillsammans med ett antal andra applikationer. Dvs. 1 av 5 öppna fönster på skärmen. Alternativt är applikationen inbyggd i ett webbgränssnitt på en portal/active desktop tillsammans med annat börsnoteringar, mail, personaliserade nyheter etc. etc. Gradering = Flexibilitet och effektivitet Programmet verkar vara så enkelt i sin utformning och är tänkt att användas på ett sådant sätt att graderingen nybörjare/van användare inte behövs.

5 5 (6) Vad som helt saknas är en sökfunktion och kategorisering/gruppering av frågorna som kan bli välbehövligt när fråge- och svarsmängderna ökar över tid. Ponera att en organisation har 500 anställda och 300 av dessa väljer att ställa endast en fråga i systemet. Det blir en väldigt många frågor, kanske en hel del dessutom behandlar liknande problem. Det blir då ohållbart att ha en lång frågelista där man bläddrar bland frågorna. Gradering = Minimalistisk design Programmet är ett föredömligt exempel på ett system som precis har med det nödvändiga för att lösa uppgiften och inget mer. Inga onödiga ord eller distraherande grafik. 2.9 Hjälpa användare känna igen, analysera och avhjälpa fel Här ger inte prototypen någon vägledning om hur eventuella felmeddelanden är tänkta att vara utformade, bör som tidigare nämnts åtgärdas eller kommenteras i prototypen. Gradering = Hjälp och dokumentation Som tidigare nämnts finns det inte angivet någon manual eller instruktion om hur man ska använda systemet. Med de korrigeringar som föreslagits här ovan bör inte detta behövas. Frågedatabasen är ju i sig ett komplement till en annan manual och är tänkt som ett enkelt och lättanvänt redskap. Eventuella redskap och instruktioner för programmet bör i sådana fall finnas i dokumentationen över själva projektmodellen. 3 Sammanfattning och slutkommentar Jag tycker att Mårtens ansats med ett enkelt, intuitivt och minimalistiskt gränssnitt är helt rätt. Programmet kommer bli liten men viktig komplettering till lanseringen av ett nytt arbetssätt och projektmodell i en organisation. Då det gäller grafik och utformning kan man ju tänka sig att i ett senare skede lägga på samma grafiska program som förmodligen kommer användas för projektmodellen i stort. En tanke som slagit mig är att egentligen skulle man kunna bygga ihop de olika skärmbilderna och valen till en sammanhållen bild på ett mer tydligt sätt i prototypen. Eftersom jag själv arbetat med webben som medium tänker jag genast i banorna att ta bort en del av knapparna typ läs fråga och göra texten hyperlänkad i stället. Det blir lite otympligt att klicka läs fråga om och om igen kanske användaren dessutom vill klicka upp och öppna flera frågor samtidigt?

6 6 (6) En annan tanke som har mer med kontexten runt programmet att göra är att det förmodligen behövs någon typ av ämneskunnig moderator till den här typen av frågedatabas. Den personen/personerna skulle dels fungera som expertpanel och ge korrekta svar på användarnas frågor, dels rensa ut rent felaktiga svar och dubblettsvar/-frågor. Dessutom skulle de kunna börja strukturera och sammanföra frågorna när mängden börjar bli ohanterlig.