Evaluering av grensesnitt Slik vi ofte oppfatter systemet
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 å tilfredsstille brukeren
To skumle grensesnitt
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
Eksempler på konsekvenser av dårlige grensesnitt Three Mile Island, Harrisburg, Pennsylvania: Ulykke i en kjernefysisk kraftreaktor NSB: Åsta ulykken to tog kolliderte Fellesdata: Banktjenester borte i en uke Nordlandsbanken: Ett siffer for mye i kontonummeret medførte at kr. 500.000 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 USA skjøt ned et Iransk passasjerfly under Golfkrigen i 1991
Utfordring - Registrere dato Problemstillinger: Forskjellig tegnsetting, f.eks: 02.03.02, 02/03-02, Forkortelser, f.eks: 2/3-02, 02/03-2002, 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
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
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
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
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
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?
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?
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
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
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?