Johdanto                 Tiivistelmä       Tutkimusmenetelmät
1. Web-käytettävyys      2. Web-tuotanto   3. CASE-kuvaukset
4. Heuristinen arviointi 5. Raatiarviointi 6. Yhteenveto
7. Käytettävyyden tila   Lähteet           Liitteet

Liite A.1: Heuristisen arvioinnin muistilista - pitkä versio

Ohessa on tutkimuksessa käytetty heuristisen arvioinnin muistilista, jota on sovellettu web-käytettävyyden arviointiin alkuperäisestä Jakob Nielsenin heuristisesta muistilistasta. Alla oleva kymmenkohtainen muistilista on sovellettu Jakob Nielsenin heuristisen arvioinnin muistilistasta (Nielsen, 1994), hyödyntäen Keith Instonen www-palveluiden arviointiin muokattua samaista listaa (Instone, 1997).

Listaa on täydennetty esimerkkikysymyksillä, joiden tarkoituksena on valaista kutakin muistilistan kohtaa, joskaan ei antaa tyhjentävää kuvausta sen tarkoituksesta. Usein muistilistan jokainen otsikko on riittävä kimmoke mahdollisen ongelman tunnistamiseen ja luokitteluun.

Käy pitkä lista läpi huolella ennen kuin aloitat palvelun selailun ja arvioinnin. Ota lyhyempi versio näkyviin joko ruudulle tai paperille tulostettuna arvioinnin ajaksi.

1. Palvelun tilan näkyvyys

Käyttäjän pitäisi aina pystyä nopeasti huomaamaan mikä on palvelun tila ja käyttäjän sijainti palvelussa.

  • Onko palvelu pystyssä (ts. toimiiko se vielä)?
  • Onko palvelu vastaanottanut syötteeni?
  • Mitä seuraavaksi on tapahtumassa?
  • Missä päin palvelua olen?
  • Minne voin mennä seuraavaksi?
  • Olenko menossa oikeaan (haluamaani) suuntaan?

2. Palvelun ja tosielämän vastaavuus

Palvelun pitäisi käyttää tavallisesta elämästä tuttuja termejä, sanontoja ja käsitteitä mieluummin kuin palvelun omaa erikoistermistöä.

  • Onko sanat ja lauserakenteet helposti ymmärrettävissä?
  • Käytetäänkö käsitteitä samassa merkityksessä kuin tosielämässä?
  • Toimivatko metaforat loogisesti?
  • Onko palvelun käyttö ristiriidassa muun maailman toimintaan?

3. Käyttäjän kontrolli ja vapaus

Käyttäjän pitäisi päästä nopeasti ja vaivatta takaisin kunkin vaiheen alkutilaan, tehtyään epätoivotun tai virheellisen valinnan. "Peru" ja "Tee uudestaan" toiminnot ovat suositeltavia. Palvelu ei myöskään saisi tehdä häiritseviä asioita käyttäjän tahtoa vasten tai tältä kysymättä.

  • Joutuuko palvelua navigoimaan turhien hyppyjen kautta (ts. saman voisi tehdä paljon nopeammin pienellä muutoksella)?
  • Joutuuko tietylle sivulle päästäksensä noudattamaan pakollisia ja hankalia reittejä?
  • Pääseekö kotisivulle ja tärkeimmille alasivuille takaisin helposti?
  • Voiko virheellisen syötteen (esim. lomakkeessa) muuttaa vielä lähettämisen jälkeen?
  • Avaako palvelu turhia ikkunoita, estää selainikkunan koon määrittelyn tai pakkosyöttää video- tai äänitiedostoja?

4. Yhteneväisyys ja standardit

Viestien ja toimintojen pitäisi tarkoittaa yhteneväisesti aina samoja asioita (sanoja tai merkityksiä ei saisi vaihtaa lennossa). Olemassa olevia verkko- ja muita standardeja pitäisi hyödyntää yhteneväisyyteen pyrittäessä.

  • Onko nimiä, värejä ja muita tunnisteita käytetty yhtenäisesti kaikilla sivuilla?
  • Onko linkkejä, painikkeita, tunnisteita ja syötekenttiä käytetty yhtenäisesti läpi palvelun?
  • Ovatko navigointipalkit ja painikkeet tutuissa paikoissa?
  • Näyttävätkö linkit, painikkeet ja syötekentät tutuilta (esim. väri ja muoto)?
  • Onko navigointityyli eheä läpi palvelun?
  • Noudatetaanko verkon suositeltuja (de jure) standardeja?
  • Hyödynnetäänkö verkon palveluiden genre-ilmaisua?

5. Virheiden estäminen

Palvelun pitäisi tunnistaa mahdolliset virhetilanteet ja estää niiden toistuminen kertomalla käyttäjälle ennen virheen tapahtumista. Opastus pitäisi olla aina helposti saatavilla ja ymmärrettävissä.

  • Onko kaavakkeissa hyödynnetty virheellisten syötteiden tarkistusta?
  • Annetaanko ongelmallisista syötteistä selkeä ja opastava ilmoitus ajoissa?
  • Onko syöte- ja toimintotilanteissa saatavilla opastus?

6. Tunnistaminen mieluummin kuin muistaminen

Asioiden, toimintojen ja vaihtoehtojen pitäisi olla näkyvissä käyttöliittymässä. Käyttöliittymän painikkeiden ja syötteiden pitäisi liittyä palvelun toimintoihin loogisesti, niin että näiden vastaavuus on pääteltävissä helposti. Käyttäjää ei saisi pakottaa muistamaan asioita ruudulta toiselle siirryttäessä.

  • Ovatko tärkeimmät toiminnot näkyvissä aina niin, että niiden sijaintia toisella sivulla ei tarvitse muistaa?
  • Ovatko kaikki toimintoja aikaansaavat käyttöliittymäelementit merkitty niin, että ne ymmärtää painikkeiksi (tai syötekentiksi, tms.)?
  • Ovatko käyttöliittymän elementit sijoitettu niin, että niiden riippuvuus ja suhde muihin ruudun elementteihin on selvä?
  • Voiko käyttäjä edetä sivulta toiselle, ilman että hänen täytyy muistaa ulkoa aikaisemmilla sivuilla näkemäänsä tietoa?
  • Onko palvelun (ja sivun) URL pääteltävissä helpohkosti palvelun sisällöstä tai tarjoajasta?

7. Käytön joustavuus ja tehokkuus

Käytön pitäisi olla joustavaa ja tehokasta sekä aloitteleville että edistyneille käyttäjille. Palvelun pitäisi tarjota pikavalintoja ja personointia usein käytettyihin toimintoihin. Käytön pitäisi olla myös joustavaa ja tehokasta käyttäjän laitteistosta ja yhteydestä riippumatta.

  • Ovatko yleisimmät toiminnot aina käytettävissä ja näkyvillä?
  • Voiko monimutkaista tai laajasisältöistä liittymää muokata yksinkertaisemmaksi tarpeidensa mukaan?
  • Skaalautuuko palvelu eri näytöille, selainversioille, kirjasintyypeille, väreille, konetyypeille, käyttöjärjestelmille ja yhteysnopeuksille?
  • Hankaloittavatko kehykset linkittämistä, selaamista tai tulostamista?
  • Voiko usein käytettyihin sivuihin linkittää helposti?
  • Voiko dynaamisesti tuotetut sivut saada helposti ladattua uudestaan (esim. kyselyt)?
  • Onko pääsivulla käytetty meta-viittoja hakukonetulosten parantamiseksi?
  • Onko monimutkaisista käyttöliittymistä tarjolla yksinkertaistettu versio aloittelijoille?

8. Esteettinen ja minimalistinen design

Ruudulla pitäisi olla ne elementit, jotka ilmaisevat halutun tiedon, toiminnot, tunnelman ja tyylin, ei enempää. Ilmaisun ei pitäisi olla vaikeasti ymmärrettävää (ellei se ole palvelun kantava idea).

  • Onko ruudulla käytetty rajoitetusti värisävyjä, valööriarvoja ja värikoodauksia (n. 1-3)?
  • Onko kirjasintyyppejä ja kokoja käytetty rajoitetusti (n. 1-3)?
  • Onko tyhjää tilaa hyödynnetty selkeyttämään näyttöjä?
  • Kiinnittyykö huomio tärkeimpiin elementteihin ensin?
  • Hallitseeko yksi (tai useampi) elementti koko näyttöä ja sen navigointia muiden kustannuksella?
  • Onko teksti sopivan mittaista, tyylistä ja kokoista ruudulta luettavaksi?

9. Virhetilanteiden tunnistaminen, ilmoittaminen ja korjaaminen

Virheilmoitusten pitäisi kertoa selkokielellä mitä tapahtui, miksi näin kävi, miten asia voidaan korjata ja kuinka se voidaan välttää ensi kerralla.

  • Onko virheilmoitus ymmärrettävissä?
  • Selviääkö virheilmoituksesta mitä tapahtui, miksi ja miten korjata/välttää tilanne?
  • Ovatko virheilmoitukset kohteliaita ja välttävät syyttelyä?
  • Ovatko korjaavat toimintaohjeet helposti seurattavissa?

10. Opastus ja ohjeistus

Vaikka käytön pitäisi tapahtua ilman opastusta ja ohjeita, ovat ne usein välttämättömiä käyttäjille. Näiden pitäisi olla helposti saatavilla, nopeasti etsittävissä, toimintaan ohjaavia, käyttötilannetta tukevia ja riittävän lyhyitä.

  • Annetaanko opastusta automaattisesti vaikeissa paikoissa?
  • Ovatko ohjeet aina saatavilla?
  • Ovatko ohjeet ja opastus tilanne- tai sivukohtaisia?
  • Ovatko ohjeet helposti ymmärrettävissä ja vaiheet toteutettavissa?
  • Ovatko ohjeet lyhyitä (lyhyisiin, mutta järkeviin kokonaisuuksiin pilkottuja)?

 

Heuristisen arvioinnin muistilista - lyhyt versio

1. Palvelun tilan näkyvyys

Käyttäjän pitäisi aina pystyä nopeasti huomaamaan mikä on palvelun tila ja käyttäjän sijainti palvelussa.

2. Palvelun ja tosielämän vastaavuus

Palvelun pitäisi käyttää tavallisesta elämästä tuttuja termejä, sanontoja ja käsitteitä mieluummin kuin palvelun omaa erikoistermistöä.

3. Käyttäjän kontrolli ja vapaus

Käyttäjän pitäisi päästä nopeasti ja vaivatta takaisin kunkin vaiheen alkutilaan, tehtyään epätoivotun tai virheellisen valinnan. "Peru" ja "Tee uudestaan" toiminnot ovat suositeltavia. Palvelu ei myöskään saisi tehdä häiritseviä asioita käyttäjän tahtoa vasten tai tältä kysymättä.

4. Yhteneväisyys ja standardit

Viestien ja toimintojen pitäisi tarkoittaa yhteneväisesti aina samoja asioita (sanoja tai merkityksiä ei saisi vaihtaa lennossa). Olemassa olevia verkko- ja muita standardeja pitäisi hyödyntää yhteneväisyyden maksimoimisessa.

5. Virheiden estäminen

Palvelun pitäisi tunnistaa mahdolliset virhetilanteet ja estää niiden toistuminen kertomalla käyttäjälle ennen virheen tapahtumista. Opastus pitäisi olla aina helposti saatavilla ja ymmärrettävissä.

6. Tunnistaminen mieluummin kuin muistaminen

Asioiden, toimintojen ja vaihtoehtojen pitäisi olla näkyvissä käyttöliittymässä. Käyttöliittymän painikkeiden ja syötteiden pitäisi liittyä palvelun toimintoihin loogisesti, niin että näiden vastaavuus on pääteltävissä helposti. Käyttäjää ei saisi pakottaa muistamaan asioita ruudulta toiselle siirryttäessä.

7. Käytön joustavuus ja tehokkuus

Käytön pitäisi olla joustavaa ja tehokasta sekä aloitteleville että edistyneille käyttäjille. Palvelun pitäisi tarjota pikavalintoja ja personointia usein käytettyihin toimintoihin. Käytön pitäisi olla myös joustavaa ja tehokasta käyttäjän laitteistosta ja yhteydestä riippumatta.

8. Esteettinen ja minimalistinen design

Ruudulla pitäisi olla ne elementit, jotka ilmaisevat halutun tiedon, toiminnot, tunnelman ja tyylin, ei enempää. Ilmaisun ei pitäisi olla vaikeasti ymmärrettävää (ellei se ole palvelun kantava idea).

9. Virhetilanteiden tunnistaminen, ilmoittaminen ja korjaaminen

Virheilmoitusten pitäisi kertoa selkokielellä mitä tapahtui, miksi näin kävi, miten asia voidaan korjata ja kuinka se voidaan välttää ensi kerralla.

10. Opastus ja ohjeistus

Vaikka käytön pitäisi tapahtua ilman opastusta ja ohjeita, ovat ne usein välttämättömiä käyttäjille. Näiden pitäisi olla helposti saatavilla, nopeasti etsittävissä, toimintaan ohjaavia, käyttötilannetta tukevia ja riittävän lyhyitä.

 

Vakavuusluokitus

Jokainen arvioinnissa löydetty ongelma luokitellaan vakavuusasteikolla, joka kertoo asiantuntijan mielipiteen käytettävyysongelman vakavuudesta. Ongelman vakavuuden luokitus pitäisi nojata ainakin seuraavaan neljään seikkaan:
  • Esiintymistiheys: kuinka usein potentiaaliseen ongelmatilanteeseen törmää? (usein/harvoin)
  • Vaikutukset käyttäjälle: onko ongelmatilanteesta helppo vai vaikea selvitä? (vaikea/helppo)
  • Toistuvuus: Onko ongelma helposti ohitettavissa, kun sen on kerran tunnistanut, vai vaivaako se jatkuvasti? (toistuva/ohitettava)
  • Markkinavaikutukset: tekeekö virhe palvelusta markkinoilla merkittävästi huonomman tai jopa käyttökelvottoman? (merkittävästi heikompi/ei vaikutusta)

 

Vakavuusluokka ilmaistaan numeroilla nollasta neljään seuraavasti:

  • 0 = En pidä ongelmaa käytettävyysongelmana
  • 1 = Kosmeettinen ongelma: korjataan kun ehditään
  • 2 = Pieni käytettävyysongelma: vaikeuttaa käyttö, korjataan
  • 3 = Suuri käytettvyysongelma: vaikeuttaa merkittävästi, korjataan heti
  • 4 = Katastrofaalinen ongelma: lähes käyttökelvoton palvelu, julkistusta täytyy (olisi täytynyt) lykätä kunnes virhe on korjattu

Sisällysluettelo

Kirjallisuus        Liite A2: Lyhyt muistilista