Käytettävyys

• Nielsenin käytettävyyssloganit
• Heuristinen arviointi
  • Kymmenen käytettävyys heuristiikkaa
• Käytettävyystesti
  • Paritestaus
  • Ryhmäläpikäynti
• Windows
  • Fittsin laki
• Menut ja dialogit
• WWW-lomakkeet
  • Should I use a drop-down: Four steps for choosing form elements on the web (PDF)
  • Vaihe 1: Sivun päätarkoitus
  • Vaihe 2: Kuusi kysymystä
  • Vaihe 3: Lomakkeen muotoilu
  • Vaihe 4: Lomakkeen esteettömyys
  • Tehtävä: Laadi www-liittymä demoryhmätietojen kysymistä varten
• WWW-sivujen käytettävyys
• Korppi
• linkkejä

Käytettävyys jaetaan yleensä seuraaviin viiteen osaan:

• Opittavuus

  Järjestelmän käyttäminen pitää oppia nopeasti ja helposti

• Tehokkuus

  Järjestelmällä pitää pystyä tehokkaaseen toimintaan

• Muistettavuus

  Järjestelmän käyttämisen pitää olla helposti muistettavissa

• Virheettömyys

  Käyttäjien ei pidä tehdä järjestelmällä useita virheitä

• Miellyttävä

  Käyttäjien täytyy pitää järjestelmästä

Nielsenin käytettävyyssloganit

• Your Best Guess Is Not Good Enough

  Älä ota nokkiisi vaikka joutuisit muuttamaan koko käyttöliittymän käyttäjätestauksen jälkeen.

• The User Is Always Right

  Suunnittelijan asenne ei saa olla: "Käyttäjä on tyhmä kun ei osaa käyttää tätä".

• The User Is Not Always Right
  • Käyttäjät eivät kysyttäessä välttämättä tiedä omaa parastaan.
  • Käyttäjien toiveet eivät ole sama asia kuin käytettävä käyttöliittymä ("Joo! 3D-graffaa, tottakai!")
  • Älä usko mitä käyttäjät muistavat tehneensä vaan seuraa käyttötilanteessa miten he toimivat.
• Users Are Not Designers

  Aloittelijat eivät muokkaa käyttöympäristöään.

• Designers Are Not Users

  Suunnittelija tuntee järjestelmän aivan liian hyvin

• Vice Presidents Are Not Users

  Johtajaksi päästään johtamistaidoilla, ei suunnittelutaidoilla

• Less Is More

  Mitä enemmän ominaisuuksia sitä enemmän päänvaivaa käyttäjälle

• Details Matter

  Oikein muotoiltu lause voi olla ratkaiseva

• Help Doesn't

  Käyttäjävihamielinen ympäristö ei parane avustuksella

Heuristinen arviointi

Heuristisessa arvioinnissa käyttöliittymä tarkistetaan erilaisten käytettävyysperiaatteiden eli heuristiikkojen avulla.

Heuristisen arvioinnin voi toteuttaa jo pelkälle suunnitelmalle tai prototyypille.

Suositeltava arvioijien määrä on kolmesta viiteen. Yksi arvioija ei vielä löydä kaikkia virheitä.

1. Kukin arvioija käy järjestelmän läpi yksinään vähintään kahdesti
2. Kerätään ongelmat yhdeksi listaksi
3. Arvioidaan ongelmien vakavuuss luokittelemalla ongelmat tason mukaan esim. katastrofaalinen, vakava, häiritsevä, vähäinen ja kosmeettinen
4. Keskustellaan parannuksista suunnittelijoiden kanssa

Kymmenen käytettävyys heuristiikkaa

Heuristisessa arvioinnissa käytetään usein Nielsenin kymmenen säännön listaa:

1. Käytä yksinkertaista ja luonnollista dialogia

   Korppilomake ja Selvennetty lomake

2. Käytä käyttäjien omaa kieltä

   Sanastoista voidaan luoda useampi ehdotus joista käyttäjät äänestävät mielestään selkeimmän

3. Minimoi käyttäjän muistikuorma

   Annetaan mallivastauksia tai oletusarvoja ja ollaan johdonmukaisia

4. Tee käyttöliittymästä kauttaaltaan yhdenmukainen
5. Anna käyttäjälle palautetta toiminnoista

   Mitä pitempään toiminto kestää sitä oleellisempaa on antaa jotain palautetta

6. Anna selkeä poistumistapa eri tiloista ja toiminnoista
7. Anna käyttäjälle mahdollisuus käyttää oikopolkuja
8. Anna virhetilanteista selkeät virheilmoitukset

   Älä käytä maailman kuuluisinta virheilmoitusta eli pelkkää BEEEP ääntä.

9. Vältä virhetilanteita

   Anna valmiit vaihtoehdot, pyydä varmistuksia

10. Anna riittävä ja selkeä apu ja dokumentaatio

Näistä säännöistä voidaan edelleen muokata oma räätälöity versio

Lähde: Käytettävyyden arviointi ilman käyttäjiä (PDF)

Käytettävyystesti

Käytettävyystestissä käyttäjä suorittaa määrättyjä tehtäviä arvioitavalla järjestelmällä. Käyttäjä ajattelee ääneen tehtäviä tehdessään.

Ohjaaja seuraa käyttäjän toimintaa ja tekee muistiinpanoja. Jos on tarpeeksi aikaa ja rahaa niin tapahtuma voidaan myös videoida

Yleensä riittää kun testihenkilöitä on 3-5 kappaletta

Paritestaus

Paritestauksessa kaksi käyttäjää tekee tehtäviä yhdessä. Toinen lukee ohjeita ja toinen käyttää järjestelmää. Kummatkin ajattelevat ääneen.

Ryhmäläpikäynti

Ryhmässä on useita käyttäjiä ja pari suunnittelijaa. Kukin ratkoo itsenäisesti tehtävät paperiprototyyppien avulla. Lopuksi keskustellaan ratkaisuista yhdessä.

Lähde: Käytettävyystestauksen muunnelmia (PDF)

Windows

Tarkistuslista hyvälle Windows-käyttöliittymälle:

• Your application installs easily in a minimum number of steps.
• Your application installation does not require the system to restart.
• Users do not have to read a Readme file before using your application.
• User-generated data files are stored by default in the My Documents folder.
• Your application avoids cryptic file names that are visible to users.
• Your application does not create folders outside of the Program Files folder.
• Your application does not write files to the root of the hard disk.
• If your application uses a disk cache, it also registers with the Disk Cleanup utility.
• Your application does not include entries to its Help, Readme, and Uninstall files on the Start menu.
• Your application does not install icons to the Windows desktop without the user's permission.
• If your application is run at startup, it loads without displaying splash screens and dialog boxes.
• Your application does not use the taskbar notification area for status, for launching applications or utilities, or for querying properties. It uses the notification area only to alert the user of an important change.
• Your application appropriately applies the color choices the user selected in Display properties in Control Panel.
• Your application is keyboard accessible.
• Your application works correctly if the user increases the size of the default font.
• Your application supports the standard set of keyboard shortcuts, where applicable.
• Your application's uninstall process leaves no remaining files or registry entries other than files created by the user.
• Your application does not use jargon in its user interface text. Use industry-specific or technical terms only if they are clearly understood by the user.
• Your application adjusts appropriately when the user changes the display resolution as well as for multiple-monitor configurations.

Microsoftin User-centered Design Principles

Fittsin laki

The time to acquire a target is a function of the distance to and size of the target.

Tehtävä

Vastaus

Testaa itsesi

Menut ja dialogit

Tehtävä

Vastaus

Office 2000, Office 2002 ja Open Office 1.1

WWW-lomakkeet

• Ihmiset eivät pidä lomakkeista (vrt. veroilmoitus)
• Lomakkeet ovat pitkiä ja monimutkaisia ja aiheuttavat paljon kognitiivista kuormaa
• Usein lomakkeet eivät ole selkeitä eikä niiden tarkoitusta ole helppo päätellä
• Lomakkeet usein pakottavat käyttäjän vastaamaan kysymyksiin joita nämä eivät pidä oleellisina
• Lomakkeet vievät kontrollin pois käyttäjältä

Should I use a drop-down: Four steps for choosing form elements on the web (PDF)

Vaihtoehdot:

• Drop down box
• Radio button
• Check box
• Input box
• Hyperlinkki

Vaihe 1: Sivun päätarkoitus

Navigointi vai tiedonkeruu?

Tehtävä

Vastaus

Vaihe 2: Kuusi kysymystä

Lomake-elementtejä valittaessa on syytä miettiä seuraavia kysymyksiä:

1. Onko luonnollisempaa kirjoittaa haluttu tieto vai valita se?
2. Tuleeko vastauksiin helposti kirjoitusvirheitä?
3. Pitääkö käyttäjän nähdä vaihtoehdot ymmärtääkseen kysymyksen?
4. Kuinka monta vaihtoehtoa on?
5. Voiko käyttäjä valita useampia kuin yhden?
6. Ovatko vaihtoehdot visuaalisesti erottuvia?

Vaihe 3: Lomakkeen muotoilu

1. Vältä liian montaa erilaista lomake-elementtiä
2. Pidä vaihtoehdot lyhyinä ja helposti luettavina
3. Valitse järkevä järjestys

Vaihe 4: Lomakkeen esteettömyys

1. Älä unohda "Lähetä"-nappulaa jos käytät Javascriptiä lomakkeella
2. Muista lomake-elementeille järkevät name-attribuutit.

Tehtävä: Laadi www-liittymä demoryhmätietojen kysymistä varten

Kurssille luodaan N kappaletta demoryhmiä joista kullakin ryhmillä on X kappaletta demokertoja. Näille kaikille ryhmille pitää kätevästi pystyä syöttämään ryhmän nimi, aika, paikka, ohjaaja ja osallistujien maksimilukumäärä. Usein kunkin ryhmän demopaikka on jokaisella demokerralla sama mutta ei välttämättä aina. Myös ohjaaja ja aika voivat vaihdella ryhmästä tai demokerrasta riippuen. Käyttöliittymässä täytyy pystyä määrittämään yhteisiä tietoja samalla kertaa useammalle ryhmälle tai demokerralle.

Piirrä kalvolle edellätoivottuun tarkoitukseen sopivan www-sivun / sivujen kuvat

WWW-sivujen käytettävyys

Seuraavat tilastot on kerätty Jakob Nielsenin Homepage usability -kirjastossa jossa on tutkittu 50 yrityksen kotisivua (etusivu). Tämän ja muiden tutkimusten perusteella Nielsen on päätynyt suosittelemaan seuraavia ratkaisuja.

• Sivun leveys: Selaimeen mukautuva
• Korkeus: n. kaksi näytöllistä
• Kehykset: älä käytä (n. 4% tutkituista sivuista käytti)
• Logo: Vasen ylänurkka (84%)
• Haku: sivun yläosa (75%). Vähintään 25 merkkiä leveä.
• Navigointi: Vasen reuna tai ylälaita (78%). Ei alasvetovalikkoja! (10%)
• Kuvien viemä ala: 5-15%
• Musiikki: Ei (96%)
• Animaatio: Ei (70%)
• Värit: Mustaa valkoisella (72%/84%)
• Linkit: Alleviivaus/Sininen/purppura (80%/60%/54%)

Korppi

Tehtäviä

Yhteenveto 2002 syksyn Korppi-viilauksista

linkkejä

• Heuristic Evaluation
• Käytettävyyden arviointi ilman käyttäjiä (PDF)
• Käytettävyystestauksen muunnelmia (PDF)
• How to Conduct a Heuristic Evaluation
• HOTmenus (DOC)
• Heuristic Evaluation - A System Checklist
• Topics in Usability
• Standards and Guidelines
• Tem Guidelines for User-Centered Web Design
• Official Guidelines for User Interface Developers and Designers
• Usability standards
• Usable Web
• First Principles
• Maximizing Human Performance
• How Programmes Stole the Web
• Äänestyslomake
• Effective use of forms on websites
• Forms that Work
• Usability and HTML Forms
• Testaamiseen riittää viisikin käyttäjää
• Vältä alasvetovalikoita
• Käyttäjä katsoo ensin tekstiä ja vasta sitten kuvia
• Ei reset- tai cancel-nappia webbiin
• Radiopainikkeissa pitää olla aina jokin oletusvalinta
• Examples
• Bad Human Factors Designs
• Interface Hall of Shame
• X-shame
• Käytettävyysluento syksyltä 2002
• Käytettävyysluento keväältä 2003