Noen empiriske unders

1
Noen empiriske undersøkelser.

• Jakob Nielsen 1994
• Brukbarhetstest av 5 store nettsteder i USA.
• Jared Spool, 1997
• Brukbarhetstest av 9 store nettsteder i USA
• Molich Gram, 1998
• Brukbarhetstest av 9 store danske nettsteder
• IBM-Austin, 1998
• Brukbarhetstest av 4 nettbutikker

2
Jakob Nielsen 1994

• Brukbarhetstest av 5 store nettsteder i USA.
• Problemer observert
• Sidene er for komplekse. Finner ikke informasjon.
• Oversiktsdiagrammer mangler. Går seg bort.
• Brukere mister tålmodigheten og går raskt videre.
• Tregt nett.
• Ny test i 1997
• Overraskende lite hadde forandret seg i forhold
  til de problemene som brukerne opplevde.

3
Jared Spool, 1997

• Brukbarhetstest av 9 store nettsteder i USA
• Funn
• De fleste brukere er på jakt etter informasjon.
• De må meget ofte gi opp.
• Grafisk design er uviktig i forhold til
  brukbarhet. (Ingen signifikant korrelasjon
  grafikk/brukbarhet!)
• Tekstlenker er vitale.
• Struktur og innhold kan ikke skilles.

4
Molich Gram, 1998

• Brukbarhetstest av 9 store danske nettsteder
• Funn
• I snitt ca. 10 kritiske problemer pr. sted.
• Ca. 50 andre problemer pr. sted.
• Grafikken var fin, men brukbarheten lav.
• Nettstedene var ikke tilpasset brukernes
  forståelse (for eksempel bruk av faguttrykk fra
  finans i en Internett-Bank).
• Informasjonen var vanskelig å finne.

5
IBM-Austin, 1998

• Brukbarhetstest av 4 nettbutikker
• Funn
• Store problemer med handlekurven
• (31 trodde de hadde kjøpt noe de ikke hadde
  kjøpt).
• Innlogging vanskelig
• Vanskelig navigasjon
• Vanskelig å finne varer (kategorisering, søk)

6
Sjekklister for brukbarhet

• Jacob Nielsens 10 punkts liste
• Basert på gjennomgang av systemer
• Finnes www.useit.com
• Bruce Tognazzinis First Principles
• 17 prinsipper/punkter
• Finnes på www.asktog.com
• Don Normans prinsipper
• fra Design of Everyday Things
• Disse B. Laurel i NielsenNorman Group

7
Jacob Nielsens 10 punkter

• Visibility of system status
• Match between system and the real world
• User control and freedom
• Consistency and standards
• Error prevention
• Recognition rather than recall
• Flexibility and efficiency of use
• Aesthetic and minimalist design
• Help users recognize, diagnose, and recover from
  errors
• Help and documentation

8
Visibility of system status

• The system should always keep users informed
  about what is going on, through appropriate
  feedback within reasonable time.

9
Match between system and the real world

• The system should speak the users' language, with
  words, phrases and concepts familiar to the user,
  rather than system-oriented terms.
• Follow real-world conventions, making
  information appear in a natural and logical
  order.

10
User control and freedom

• Users often choose system functions by mistake
  and will need a clearly marked "emergency exit"
  to leave the unwanted state without having to go
  through an extended dialogue.
• Support undo and redo.

11
Consistency and standards

• Users should not have to wonder whether different
  words, situations, or actions mean the same
  thing.
• Follow platform conventions.

12
Error prevention

• Even better than good error messages is a careful
  design which prevents a problem from occurring in
  the first place.

13
Recognition rather than recall

• Make objects, actions, and options visible.
• The user should not have to remember information
  from one part of the dialogue to another.
• Instructions for use of the system should be
  visible or easily retrievable whenever
  appropriate.

14
Flexibility and efficiency of use

• Accelerators -- unseen by the novice user -- may
  often speed up the interaction for the expert
  user such that the system can cater to both
  inexperienced and experienced users.
• Allow users to tailor frequent actions.

15
Aesthetic and minimalist design

• Dialogues should not contain information which is
  irrelevant or rarely needed.
• Every extra unit of information in a dialogue
  competes with the relevant units of information
  and diminishes their relative visibility.

16
Error recovery

• Help users recognize, diagnose, and recover from
  errors.
• Error messages should be expressed in plain
  language (no codes), precisely indicate the
  problem, and constructively suggest a solution.

17
Help and documentation

• Even though it is better if the system can be
  used without documentation, it may be necessary
  to provide help and documentation.
• Any such information should be easy to search,
  focused on the user's task, list concrete steps
  to be carried out, and not be too large.

18
Bruce Tognazzini

• Anticipation
• Autonomy
• Color Blindness
• Consistency
• Defaults
• Efficiency of the User
• Explorable Interfaces
• Fitts's Law
• Human-Interface Objects

• Latency Reduction
• Learnability
• Limit Tradeoffs
• Metaphors
• Protect the User's Work
• Readability
• Track State
• Visible Interfaces

19
Anticipation

• Prøv å forutsi hva brukeren trenger.
• Ikke forvent at brukeren skal kunne finne
  informasjon og verktøy uten hjelp.

20
Autonomy

• La brukeren ha kontrollen.
• Gi feedback som gjør at brukeren føler at han/hun
  har kontroll.

21
Color Blindness

• Fargeblindhet er ganske utbredt.
• Bruk ikke farge som eneste måte å indikere noe på.

22
Consistency

• Vær konsistent i ordbruk, ikonbruk, oppførsel,
  struktur.
• Både innen applikasjon/tjeneste, produktpakke,
  firma, og plattform.

23
Defaults

• Ikke bruk ordet default. Bruk heller
  Standard, Vanlig oppsett el.l.
• La det være lett å forandre et oppsett

24
Efficiency of the User

• Gjør brukeren effektiv, ikke programmet.
• Et godt program gjør brukeren effektiv.

25
Explorable Interfaces

• La det være lett å utforske et grensesnitt.
• Hjelp til navigasjon.
• Oversiktlig struktur.
• Alltid info om hvor man befinner seg i
  strukturen, og hvordan man kommer tilbake og
  videre.

26
Fitts's Law

• La ting som hører sammen ligge nær hverandre.
• Reduser behov for musebevegelser.
• Bruk store knapper på viktige ting.

27
Human-Interface Objects

• Vær nøye med valg av de objektene brukeren skal
  se (dokumenter, mapper,,,)
• Dette er ofte forskjellig fra objekter i den
  underliggende databasen/systemet.
• (Se metafor, konseptuell modell, mental modell)

28
Latency Reduction

• Unngå at brukeren må vente.
• La flere ting kunne skje samtidig.
• Gi alltid feedback.
• Indiker hvor langtid noe tar (Process bars)

29
Learnability

• Lav terskel
• Høyt tak
• Ikke nødvendigvis motsetning med brukbarhet.

30
Metaphors

• Gode metaforer forenkler læring.
• Må brukes med vett.

31
Protect Users Work

• Brukere må aldri miste data!

32
Readability

• Tekst må kunne leses.
• Riktig bruk av font
• Riktig bruk av størrelse.
• Riktig bruk av farger og kontraster.

33
Track state

• Ta vare på informasjon om hva brukeren har gjort
  / har vært.
• Gjør dette tilgjengelig for brukeren.

34
Visible Interfaces

• Gjør alle valg synlig.
• Vis strukturen til systemet.
• Ingen skjulte tilstander (hidden states)
• WYSIWYG