Evaluering av brukskvalitet for et Web-grensesnitt

Transkript

1 Evaluering av brukskvalitet for et Web-grensesnitt

2 Brukergrensesnitt Dørhåndtak - elektronisk kodelås Reflektere hvem som gjør hva Program som gjør det mulig for en bruker å kommunisere med datamaskinen Bestemmer hva brukeren skal se og gjøre Både maskin og bruker påvirker hverandre Optimalisere brukerens mulighet for kontroll Programmet skal nå sitt mål som er å tilfredstille brukeren

3 Et godt grensesnitt medfører at: Feil ikke oppstår og feilfrekvens reduseres Opplæringen kan forenkles Produktivitet og effektivitet øker Brukerne blir fornøyde Systemet kan bli lettere å selge

4 Eksempler på konsekvenser av feil i grensesnitt Three Mile Island, Harrisburgh, Pennsylvania: Ulykke i en kjernefysisk kraftreaktor NSB: Åsta ulykken Fellesdata: Banktjenester borte i en uke Nordlandsbanken: Ett siffer for mye i kontonummeret medførte at kr gikk til feil mottaker Fly: Airbus: Samme format på instrumenter for glidevinkel og høydeforandring Våpensystemer: Manglende informasjon om høyde og hastighet førte til at amerikanerne skjøt ned et Iransk passasjerfly under Golfkrigen i 1991

5 Eksempler på høy brukskvalitet Systemet har høy brukskvalitet når: Brukeren kan ta systemet i bruk straks for å utføre oppgaven tilfredsstillende uten undervisning eller bruk av dokumentasjon Det er lett å lære og huske, er forståelig og både effektivt og tilfredsstillende å bruke Brukeren ikke hindres eller sinkes i å utføre oppgaven tilfredsstillende ved å bruke systemet. Hindringene er en subjektiv opplevelse hos den enkelte bruker

6 Eksempler på lav brukskvalitet Brukeren kan ikke fortsette arbeidet uten hjelp fra en annen person Brukeren føler at systemet oppfører seg sterkt irriterende eller irrasjonelt Der er forsjkell på hva brukeren tror systemet gør og det systemet virkelig gjør Flere brukere opplever samme kritiske hendelse/stopp uavhengig av hverandre

7 Utfordring - Registrere dato Problemstillinger: Forskjellig tegnsetting, f.eks: , 02/03-02, Forkortelser, f.eks: 2/3-02, 02/ , Månedsnavn og tall: 03, mars, Forskjellig rekkefølge: dag-måned-år, måned-dag-år, år-måned-dag Nasjonale standarder forenkler: I Norge er rekkefølgen vanligvis dag-måned-år, og vi forventer å gi inndata som tall. For tegnsetting gjelder mange varianter

8 Feil medfører kostnader Irritasjon Tidstap Tap av data Mister flyt i operasjonene Lavere effektivitet Reduserte muligheter for ansatte til å gjøre en god jobb Misfornøyde kunder Kunder og ansatte velger mindre effektive, men sikrere arbeidsmåter Feil i produkter og tjenester

9 Med og uten feil Når alt virker slik det skal uten feil Arbeidsoperasjoner går fort Grensesnittet blir en del av arbeidet Flyten i arbeidet kan optimaliseres Vi blir tilfredse med systemet I feilsituasjoner: Arbeidsoperasjoner går langsomt Grensesnittet blir et irritasjonsmoment Vi kan miste flyten i arbeidet og gjøre nye feil Vi kan bli misfornøyde med systemet og vurderer andre løsninger

10 Hvor plasseres pålogging? I et system for billettbestilling på nett trenges en sekvens for pålogging. Den kan plasseres enten i: Starten av prosessen Slutten av prosessen når for eksempel betaling skal foregå Hvor bør sekvensen plasseres? Begrunn vurderingen

11 Tilfredse brukere får vi når systemet: Gjør det brukeren forventer Er effektivt Hjelper brukeren til å gjøre en god jobb Det medfører: God reklame for systemet Brukere som er lite villige til å gå over til et nytt system

12 Test og evaluering av brukskvalitet Hensikt: Å fastslå at systemet fungerer slik det skal (T) Å identifisere funksjoner som fungerer dårlig (T) Å vurdere hvor godt de enkelte delene fungerer (E) Metode: Løse arbeidsoppgaver systemet er laget for og evaluere utførelsen Resultat: En liste over funksjoner og deres brukskvalitet

13 Evalueringsspørsmål Hvor lang tid tar det før en bruker: Har god oversikt over funksjonaliteten i systemet? Selv forstår hvordan systemet kan brukes? Oppdager hvilken effekt han har av systemet? Hvor lang tid mener du han bør bruke på dette?

14 Flere spørsmål om evaluering Når du gjør feil, stopp opp Hvorfor gjorde du feilen? Har du gjort samme feilen før? Er det feil i grensesnittet? Kunne feilen vært unngått med et annet system? Når alt fungerer, forsøk å finne ut hvorfor Kan det forbedres ved å gi mer informasjon?

15 Noen eksempler Konsistens Gjør det enklere å lære og å bruke systemet Utforming av skjermbilder, til valg av ikoner og plassering av taster Snarveier for eksperten ALT + eller CTRL + alternativer Makroer Hjelp tilpasset ekspertnivået Vise linker før annen tekst, tekst før bilder i Web grensesnitt

16 Flere eksempler God tilbakemelding Umiddelbar respons på kommando - timeglass Bekreftelse på at operasjon er utført - melding Signal som viser at operasjonen er initiert - slider Manglende tilbakemelding Medfører at brukerne blir usikre på om kommandoen er utført - gjentar ofte kommandoen for sikkerhets skyld - dobbeltregistrering Hva bygger evaluering av et grensesnittet på? Kunnskap om brukernes krav og bakgrunn Egen faglig dyktighet En blanding av begge deler

17 Eksempel på evalueringsspørsmål Er grensesnittet standardisert og konsistent? Finnes det snarveier for eksperten? Gir grensesnittet informative tilbakemeldinger? Kan vi reversere handlinger (angre)? Er det gode feilmeldinger og god feilhåndtering? Er det brukeren eller grensesnittet som har kontrollen? Er neste hendelse selvinnlysende? Er grensesnittet selvforklarende/intuitivt? Slipper du å huske brukssekvenser?