Noen empiriske undersøkelser.

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 Nielsen’s 10 punkts liste • Basert på gjennomgang av systemer • Finnes www.useit.com • Bruce Tognazzini’s ”First Principles” • 17 ”prinsipper”/punkter • Finnes på www.asktog.com • Don Norman’s prinsipper • fra ”Design of Everyday Things” • Disse + B. Laurel i NielsenNorman Group

7. Jacob Nielsen’s 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 User’s 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