SEPA Heuristinen arviointi

SEPA Heuristinen arviointi Versio Päivämäärä Muokkaaja Kuvaus 1.00 3.12.2005 Markus Kattilamäki Dokumentti luotu 0.50 Kirsi Rönkkö Alustava dokumentti Wikiin

Sisällysluettelo 1 Johdanto... 1 2 Menetelmän käyttö... 2 3 Kokemukset ja muutokset... 3 3.1 Suunnitteluvaihe... 3 3.2 Implementaatio 1... 3 3.3 Implementaatio 2... 4 3.4 Yhteenveto... 4 4 Lähteet... 5 1 Johdanto Heuristisen arvioinnin tarkoitus on kehittää mahdollisimman käyttäjäystävällinen käyttöliittymä tuotteeseen. Heuristisella arvioinnilla voidaan arvioida tuotteen käytettävyyttä jo siinä vaiheessa, kun käyttöliittymä on vasta piirroksia paperilla. Lisäksi heuristisen arvioinnin säännöt antavat paremman pohjan tuotteen tutkimiselle, siten ettei tarvitse turvautua vain mutu-tuntumaan. Heuristisen arvioinnin tarkoituksena on käyttää hyväksi havaittuja ja olemassa olevia sääntöjä eli ns. heuristiikkoja käyttöliittymän arviointiin. Käyttöliittymää arvioidaan näitä sääntöjä vasten, tarkoituksena löytää käyttöliittymästä käytettävyyttä laskevia ominaisuuksia ja tuoda käytettävyyttä ilman varsinaista käyttäjän osallistumista prosessiin. Arviointi tapahtuu yleensä 3-5 henkilön toimesta. Heuristisella arvioinnilla pyritään löytämään erityyppisiä ja yleisiä käytettävyysongelmia. Näitä voivat Riihiahon [3] mukaan olla esimerkiksi vieraiden termien käyttö, epäyhteneväisyydet tai virheet sommittelussa. Heuristisen arvioinnin etu on käyttöliittymän ongelmakohtien löytäminen yksinkertaisesti, nopeasti ja edullisesti. Heuristisen arvioinnin säännöt on kuvattu kattavasti kehittäjän Jakob Nielsenin kirjoittamassa kirjassa Usability Engineering [2]. Nielsenin kirjassa myös kuvataan heuristisen arvioinnin menetelmää. Suomeksi aiheeseen hyvän opastuksen on kirjoittanut Sirpa Riihiaho artikkelissaan Kääytettävyyden arviointi ilman käyttäjiä [3]. Vaikka tässä projektissa keskitymmekin suunnitelmien arviointiin ja parannusehdotuksiin, voi heuristisia sääntöjä käyttää myös suunnittelun tukena. Tämä aihe valittiin muiden aiheiden joukosta, koska aihealue kiinnostaa tekijöitä ja lisäksi haluttiin saada mahdollisimman laadukas tuote aikaiseksi. Käytettävyys on yksi asia, jolla 1

tuotteen laadukkuutta voidaan mitata. Lisäksi oikeiden käyttäjien hankinta voi olla projektissamme vaikeaa. Menetelmällä pyritään edesauttamaan lopputuotteen käytön sujuvuutta ja mielekkyyttä. 2 Menetelmän käyttö Mitä aikaisemmin heuristiikat otetaan mukaan tuotteen suunnitteluun, sitä paremmat tulokset käytettävyyden suhteen saavutetaan. Siksi ensimmäisen kerran heuristinen arvio tehdään tuotteelle pääarkkitehdin prototyypeille mahdollisimman aikaisessa vaiheessa. Pyrimme aloittamaan heuristisen arvioinnin heti suunnitteluvaiheessa tai ensimmäisen implementaation alussa. Tämän lisäksi käyttöliittymää arvioidaan heuristisesti ensimmäisen implementaation lopussa, jolloin käyttöliittymästä toivottavasti on jo jollakin tasolla toimiva versio. Toisessa implementaatiossa tarkistellaan aiemmin tarkisteltujen käyttöliittymien parannuksia ja uusia käyttöliittymiä. Tarkastelulla pyritään kattamaan kaikki asiakkaalle päätyvät käyttöliittymät: analysaattorin käyttöliittymä, Ilmo-simulaattorin käyttöliittymä ja WWW-sivusto, jolla Valppaan tietoja voi seurata ja muokata. Eri lähteissä suositellaan heuristista arviointia tehtävän 3-5 asiantuntijan voimin. Tässä tapauksessa varsinaisia asiantuntijoita ei ole joten käytetään parhaita saatavilla olevia henkilöitä arvioimaan tuotetta. Käytettävyyttä hieman enemmän kuin pelkän peruskurssin ovat lukeneet ainakin Kirsi ja Markus, joten heidät on valittu arvioijaryhmään. Koska käyttöliittymän tekijät eivät välttämättä ole parhaita mahdollisia arvioijia tuotoksilleen, jätetään pääarkkitehti ja käyttöliittymän toteuttavat kehittäjät arvioijaryhmän ulkopuolelle. Jäljelle pitäisi jäädä ainakin testaaja ja muutama kehittäjä, jotka valitaan arvioijaryhmään. Projektissa käytetään yleisesti hyväksi havaittu tapaa jossa annetaan jokaisen arvioijan tutustua käyttöliittymään ja arvioida se heuristisesti itsekseen. Arvioijan on myös hyvä miettiä kuinka vakava löydetty ongelma on. Riihiahon artikkelista löytyy kuusiportainen arviointiasteikko, mutta yleisemmin tekijät ovat tottuneet käyttämään asteikkona: katastrofaalinen, vakava, vähäinen, kosmeettinen ja ei ongelma. Itsekseen tehtyjen arvioiden jälkeen tulokset ja mahdolliset parannusehdotukset kootaan yhdessä kaikkien arvioijien kesken lopulliseksi arvioksi. Tässä projektissa parannusehdotukset esitetään pääarkkitehdille, joka voi määrittää tarvittavat muutokset kehitettävään tuotteeseen. Mikäli menetelmä ei ole tuttu jollekin arvioijaryhmään valitulle opastukseksi käytetään Riihiahon artikkelia, joka on havainnollinen ja selostaa tarvittavat tiedot suomeksi. Tämän uskotaan riittävän, sillä monet ovat varmasti käyneet myös kurssin Johdatus käyttäjäkeskeiseen tuotekehitykseen, jossa asiaa myös valotetaan. Menetelmän hallitsemisen varmistamiseksi aiheesta pidetään pieni keskustelutuokio vielä ennen varsinaiseen työhön ryhtymistä. 2

Seuraavassa on esitetty käytetyt heuristiikat [3] sekä arvioinnissa käytetyt ongelmien vakavuusluokat. Taulukko 1: Arvioinnissa käytetyt vakavuudet Vakavuudet 1 Katastrofaalinen 2 Vakava 3 Vähäinen 4 Kosmeettinen Taulukko 2Arvioinnissa käytetyt heuristiikat Heuristiikat 1 Käytä yksinkertaista ja luonnollista dialogia 2 Käytä käyttäjien omaa kieltä 3 Minimoi käyttäjän muistikuorma 4 Tee käyttöliittymästä kauttaaltaan yhdenmukainen 5 Anna käyttäjälle palautetta toiminnoista 6 Anna selkeä poistumistapa eri tiloista ja toiminnoista 7 Anna käyttäjälle mahdollisuus käyttää oikopolkuja 8 Anna virhetilanteista selkeät virheilmoitukset 9 Vältä virhetilanteita 10 Anna riittävä ja selkeä apu ja dokumentaatio 3 Kokemukset ja muutokset Kappaleessa on käsitelty menetelmän käyttöä projektin aikana ja esitetty kokemuksia sen käytöstä. Arvioinnin tulokset joihin tässä on viitattu, löytyvät dokumentin lopusta. Tavoitteena on jatkaa menetelmän käyttöä myös projektin viimeisessä vaiheessa tuotteen web-käyttöliittymälle. 3.1 Suunnitteluvaihe Menetelmän käyttöä suunniteltiin ja valmisteltiin projektin ensimmäisessä vaiheessa, koska sopivaa arvioitavaa käyttöliittymää ei ollut saatavilla. Heuristista arviointia ei varsinaisesti käytetty vielä projektin suunnitteluvaiheessa. 3.2 Implementaatio 1 Valpas-projektin analysaattorin käyttöliittymäprototyypille suoritettiin heuristinen arviointi arvioijien toimesta viikolla 46. Käyttöliittymää arvioi Kirsi Rönkkö, Antti Poikela, Markku Huttunen sekä Markus Kattilamäki. Yhteenvetotilaisuus pidettiin 21.11.2005, jolloin arvioijien tulokset käytiin läpi ja niistä tehtiin yhteenveto. Arvioitavana oli javalla toteutettu käyttöliittymän prototyyppi joka ei kuitenkaan sisältänyt vielä toiminnallisuutta. Arvioijat täyttivät löytämänsä virheet valmiille lomakkeelle joka lähetettiin ohjeiden ja aihetta käsittelevän materiaalin kanssa heille ennen arviointia. 3

Heuristiikkojen käyttö arviointimenetelmänä osoittautui varsin tehokkaaksi menetelmäksi käytettävyysongelmien löytämisessä ja käyttöliittymän parantamisessa. Arvioijat löysivät varsin erilaisia ongelmia, joka lisäsi merkittävästi menetelmän tehokkuutta. Tiettyjä heuristiikkoja käytettiin huomattavasi enemmän osan jäädessä kokonaan pois. Tämä johtui osaltaan prototyypin rajoituksista. Esimerkiksi yksinkertaisen ja luonnollisen dialogin käyttäminen esiintyi varsin useassa parannusehdotuksessa, kun taas heuristiikka joka koskee palautteen antamista käyttäjälle, ei esiintynyt arvioinnissa kertaakaan. Tämä johtui prototyypin toiminnallisuuden puutteesta. Oli myös hyvä että prototyypin osallistuja ei osallistunut itse arviointiin. Kun keskeneräistä käyttöliittymää eli sen prototyyppiä käydään lopuksi yhdessä läpi, tulevat parannusehdotukset paremmin esille ja siitä on helpompi esittää kritiikkiä kun toteuttaja ei ole puolustelemassa kantaansa. Arvioinnissa löydettiin yhteensä 35 virhettä. Näistä 3 oli katastrofaalista virhettä, 12 vakavaa virhettä, 11 vähäistä sekä 9 kosmeettista virhettä. Löydetyt virheet ovat listattu kokonaisuudessaan tämän dokumentin lopussa. Käyttöliittymää korjattiin käyttäjäystävällisemmäksi löydettyjen virheiden perusteella arvioinnin jälkeen. Havaitut virheet olivat luonteeltaan sellaisia että niiden vaatimat korjaukset oli mahdollista toteuttaa. 3.3 Implementaatio 2 Projektin viimeisessä vaiheessa tullaan arvioimaan vielä varsinaista web-käyttöliittymää menetelmällä. Arviointi tulee noudattamaan ensimmäisessä vaiheessa hyväksi todettua rakennetta. Myös arvioijat ovat samat. 3.4 Yhteenveto Kuten tuloksista voidaan huomata, käyttämämme Nielsenin heuristiikat soveltuivat arviointiin melko hyvin. Toisaalta arvioitavan prototyypin toiminnallisuuden puute johti siihen että jotkin heuristiikat jäivät käyttämättä. Menetelmän avulla saimme karsittua hyvin käyttöliittymän käytettävyyteen vaikuttavia ongelmia. Neljän arvioijan virheet olivat samoista säännöistä huolimatta varsin erilaisia. Yhteinen virheiden läpikäynti auttoi virheen korjauksen suunnittelussa ja ideoinnissa. Kokonaisuudessaan käyttämämme arviointimenetelmä oli ennakko-odotusten mukaisesti tehokas ja nopea keino poistaa käytettävyysvirheitä prototyypin tasolla olevasta käyttöliittymästä. 4

4 Lähteet [1] Faulkner, X. 2000, Usability Engineering. Basingstoke, Palgrave. [2] Nielsen, J. 1993, Usability Engineering. Boston, Academic Press. [3] Riihiaho, S. 1998, Käytettävyyden arvioiminen ilman käyttäjää. http://www.soberit.hut.fi/t-121/t-121.5600/asiantuntija-arviot.pdf 5

Liite 1: Arviointi lomake Vakavuudet Heuristiikat 1 Katastrofaalinen 1 Käytä yksinkertaista ja luonnollista dialogia 2 Vakava 2 Käytä käyttäjien omaa kieltä 3 Vähäinen 3 Minimoi käyttäjän muistikuorma 4 Kosmeettinen 4 Tee käyttöliittymästä kauttaaltaan yhdenmukainen 5 Anna käyttäjälle palautetta toiminnoista 6 Anna selkeä poistumistapa eri tiloista ja toiminnoista 7 Anna käyttäjälle mahdollisuus käyttää oikopolkuja 8 Anna virhetilanteista selkeät virheilmoitukset 9 Vältä virhetilanteita 10 Anna riittävä ja selkeä apu ja dokumentaatio ID Vakavuus Ongelma Heuristiikat Parannusehdotus 6

Liite 2: Analysaattorin käyttöliittymästä löytyneet ongelmat ID Vakavuus Ongelma Heuristiikat Parannusehdotus H01 1 Miten kerrotaan mistä tiedot luetaan? Tai jos se on avaa, niin miten erotellaan simulaattorin ja valppaan tiedot? Tarvitseeko ohjelmalle edes kertoa, että kumpaa tieto edustaa? 1 Olisi hyvä, jos ohjelma osaisi päätellä asian. H02 1 Ei ole mitään käsitystä mitä eri väriviivat tarkoittavat H03 1 Liittyvätkö alanreunan tekstit valppaaseen vain simulaattoreihin? H04 2 Väriviivat ja eri laitteiden nimet sotkevat toisiaan H05 2 Kun ikkunaan ei mahdu kaikki näytettävä tieto ei viivojen tarkoitus ole selkeä. Kellon ajat jäävät piiloon vierityksen taakse. H06 2 Voiko tulokset tallentaa johonkin? Nyt käyttäjä voi joutua odottamaan kohtuuttoman pitkään, jos samat tiedot pitäisi analysoida joka kerta uudestaan H07 2 Tietojen näkyminen vaatii suunnattoman suuren resoluution. Ei voida olettaa, että kaikilla käyttäjillä on suuri resoluutioinen näyttö 2, 10 Jos värillä, koolla tai suunnalla on väliä, tulisi se selittää pikaisesti 1, 3, 9, 10 Pitäisikö tiedot alhaalla ryhmitellä Valppaan ja simulaattorien mukaan ja sitten kaikki yhteensä. Lisätään otsikot. 1 1, 10 Skaalataan ikkunan koon mukaan ja lisätään aikatiedot myös taulukon päälle. 3, 10 Tiedot olisi hyvä voida tallentaa analysoidut tiedot. Mahdollisesti tiedon voisi myös tallentaa niin, että se olisi fiksu myös tekstitiedostona 1 Skaalataan kuvaa H08 2 Ohjeet puuttuvat 10 Ohjeistusta lisää ainakin valikkoon. Lisäksi tooltipit voisivat toimia H09 2 Miten voi lisätä, poistaa tai vaihtaa tietoja, joita analysoidaan ilman, että vaihtaa kaikkia? Vai tuleeko kaikki luetella kerralla? H10 2 Mistään ei tiedä minkä lokin on avannut H11 2 Käyttäjä haluaa nähdä virheellisten viestien suhteen onnistuneista, tämä ei ole tarpeeksi erottuva tieto, jos löytyy 3, 6, 7, 9, 10 Lisätään lisää, poista ja vaihda painikkeet tai vastaavat toiminnot 3 Lokitiedostoista voisi näyttää miltä aikaväliltä ne ovat. Aukiolevista lokeista voisi olla erillinen dialogi ja paneli näytöllä. 1,3 Lisätään informaatiota esim. linjapollausviestien onnistumisprosentti 7

H12 2 Voiko valita pienemmän aikavälin analysoinnille, kuin lokien tiedot? 1, 10 Annetaan mahdollisuus määrittää aikaväli, jolta analysointi määritetään H13 2 Osaako analysaattori valittaa siitä, ettei tiedot ole samoilta aikajanoilta H14 2 Selviääkö analysaattori tilanteesta, jossa valpas on käynyt alhaalla? Tällöin valppaalta on kaksi tiedostoa luettavana? H15 2 Käyttäjä voisi arvostaa myös tietoa keskimääräisestä linjavian korjaantumisajasta 3, 9 Jos tiedostoissa ei ole valitulta aikaväliltä tietoa, niin tämä tulisi kertoa käyttäjälle 3 Analysaattori voisi hvyäksyä myös valppaalle useamman lokitiedoston, jos halutaan tehdä pidemmän aikavälin analysointia H16 3 Kellon ajat eivät ole viivan kohdalla 1, 4 H17 3 Voiko laitteiden nimiä vaihtaa 1, 10 Tietojen lukemisen yhteydessä voisi jostain? Mistä ne asetataan? määrittellä myös laitteen nimen? H18 3 Mitä tarkoittaa suorita? 2, 10 Vertaa / tee analysointi H19 3 Alareunan boxin tekstejä on vaikea 1, 3 huomata H20 3 Minkälaista palautetta käyttäjä saa, kun tietojen analysoidaan (ei ilmeisesti tapahdu hetkessä) 5 Progress bar mukaan H21 3 Oikopulut eivät vastaa konventioita 1, 7 Ctrl + o ja ctrl + q H22 3 Alareunan tiedot ovat klimpissä, 1 Kolumnien väliin enemmän tilaa eivät erotutoisistaan H23 3 Toimintojen löytäminen hankalaa, aluksi ei huomaa valikoiden olemassa oloa 1, 3 1, 4, 10 Yleisimmät toiminnot voisi sijoittaa nappuloina näytölle H24 3 Aikaskaala ei ole yhdenmukainen 4 Aika pitäisi vaihtua tasaisin välein H25 3 Akselien aikavälit ovat kovin suuria, ei välttämättä saa selvää, koska viesti lähetetty. 1, 3 Lisätään mahdollisuus aikajana tihentämiseen ja skaalaamiseen. Tai viestin tiedot näytetään kun valitaan viestiä vastaava viiva. H26 3 Teksti oli kovin pientä 1 Tekstin voisi isontaa hieman H27 4 Alun aikatiedot eivät ole aseteltu samalla tavalla kuin lopun aikatiedot. 4 H28 4 Lokin alku/loppu on turhaa tietoa 1 Poistetaan turha teksti H29 4 Valikoissa vain yksi toiminne, sama 1 Joku vain yksi menu tai sitten kuin valikon otsikko painikkeiksi ohjelmaan. H30 4 Log tai logi ei ole suomea 2 Loki H31 4 Onnistumisprosentissa ei ole %- 2, 10 Lisätään 5-merkki merkkiä H32 4 Luvut eivät oikein erotu tesktin seasta alareunan tekstissä 1 Taulukkomainen esitys tai korostus numeroihin 8

H33 4 Linjapollaus ei välttämättä suomea 2 linjakysely? H34 4 Lokin aloitus- ja lopetusajan tarkkuus erilainen kuin akseleissa H35 4 Kello on turhaa tietoa päivämäärässä 4 Kumpaankin sekunnit tai kummastakin sekunnit pois 1 Poistetaan kello sana 9