Käytettävyyden arviointimenetelmiä

Transkriptio

1 Käytettävyyden arviointimenetelmiä Anna Kolehmainen Ohjelmistotuotantovälineet-seminaari Helsingin yliopisto Tietojenkäsittelytieteen laitos

2 SISÄLTÖ 1. Johdanto 1 2. Asiantuntija-arviot Heuristinen arvio Kognitiivinen läpikäynti 4 3. Käyttäjätestit Käytettävyystestaus 6 Eettiset asiat käytettävyystestissä 7 Testitehtävät Paritestaus Ryhmäläpikäynti 9 4. Kritiikkiä ja johtopäätöksiä 12 Lähteet 14

3 1 1. Johdanto Käytettävyydellä tarkoitetaan tuotteen sopivuutta sille tarkoitettuihin tehtäviin, sille tarkoitetuilla käyttäjillä. Tuote on käytettävä, jos se auttaa käyttäjää pääsemään tavoitteeseensa tehokkaasti, tuottavasti ja miellyttävästi (ISO 9241, kuva 1). Nielsen (1993) määrittelee käytettävyyden viiden mitattavan ominaisuuden avulla. Ne ovat opittavuus, tehokkuus, muistettavuus, virheiden vähyys ja miellyttävyys. Käytettävyyden arvioinnilla pyritään mittaamaan näitä ominaisuuksia. Käytettävyyden arviointimenetelmät voidaan jakaa ilman käyttäjää (asiantuntijaarviot) ja käyttäjän kanssa tehtäviin (käyttäjätestit). Tässä esitelmässä esitellään asiantuntija-arvioista heuristinen arvio ja kognitiivinen läpikäynti sekä käyttäjätesteistä käytettävyystesti, paritestaus ja ryhmäläpikäynti. Kuva 1Käytettävyyden rakennuspalikat (ISO )

4 2 2. Asiantuntija-arviot Asiantuntija-arviot ovat arvokkaita käytettävyyden arviointimenetelmiä, koska niiden avulla voidaan mitata tuotteen käytettävyyttä hyvin aikaisessa vaiheessa tuotekehitystä. Tällöin useat käytettävyysongelmat tulevat havaituksi aikaisin, jolloin niiden korjaaminen tulee halvemmaksi. Myös itse testit ovat edullisia: niissä ei tarvita valmista prototyyppiä, eikä käyttäjiä. Asiantuntija-arvioilla havaitaan käyttöliittymän potentiaaliset ongelmat. Näistä ongelmista voidaan saada varmistusta käyttäjätesteissä. Menetelmät perustuvat arvioijan tietoihin, taitoihin ja kokemukseen. Arvioijat eivät kuitenkaan korvaa aitoja käyttäjiä. Tästä syystä käytettävyysongelmia todennäköisesti löytyy vielä käytettävyystestissäkin. 2.1 Heuristinen arvio Heuristisessa arvioinnissa arvioidaan käyttöliittymää yleisiä käytettävyyssääntöjä eli heuristiikkoja vasten. Usein apuna käytetään seuraavaa Nielsenin kymmenen säännön listaa: 1. Käytä yksinkertaista ja luonnollista dialogia 2. Käytä käyttäjän omaa kieltä 3. Minimoi käyttäjän muistikuorma 4. Ole johdonmukainen 5. Anna käyttäjälle palautetta 6. Anna selkeät poistumistiet 7. Tarjoa oikopolkuja kokeneille käyttäjille 8. Käytä selkeitä ja havainnollisia virheilmoituksia 9. Vältä virheitä 10. Tarjoa selkeä apu ja dokumentaatio

5 3 Tyypillisessä heuristisessa arviossa arvioidaan paperisia näyttöluonnoksia asiantuntijaryhmässä. Aluksi kukin arvioja tutustuu käyttöliittymään itsenäisesti ja kirjaa ylos havaitsemansa ongelmat. Tämän jälkeen havainnot kootaan yhteen ja löydettyjen ongelmien vakavuutta pohditaan ryhmässä. Ongelmien vakavuutta voidaan ilmaista esimerkiksi seuraavalla asteikolla: 1. katastrofaalinen 2. vakava 3. häiritsevä 4. vähäinen 5. kosmeettinen Tuloksena saadaan lista potentiaalisista käytettävyysongelmista, ongelman vakavuuden mukaan järjestettynä. Koska eri arvioijat löytävät järjestelmästä erilaisia virheitä (kuva 2), tulisi arvioijia olla useita. Nielsenin (1993) mukaan yksi käytettävyysasiantuntija löytää noin 35% käytettävyysongelmista, kolme arvioijaa noin 60% ja viisi arvioijaa noin 75% ongelmista. Suositeltava arviojien määrä on siis 3-5. Useammat arvioijat eivät vaikuta enää merkittävästi arvioinnin tulokseen. Kuva 2Eri arvioijat löytävät erilaisia ongelmia käyttöliittymästä. Nielsen (1994).

6 4 2.2 Kognitiivinen läpikäynti Kognitiivisella läpikäynnillä tutkitaan järjestelmän opittavuutta. Se perustuu teoriaan, jonka mukaan käyttäjä oppii käyttämään tuotetta kokeilemalla (Wharton, C et al. 1994). Päästäkseen tavoitteeseensa, käyttäjä tekee jatkuvasti "suoritussuunnitelmia" sen mukaan, millainen käsitys hänellä on järjestelmästä, ja jokaisen suunnitelman vaiheen (toiminnon) toteutuksen jälkeen tulkitsee järjestelmän tilasta, oliko toiminnon valinta oikea, vai pitääkö suoritussuunnitelmaa muuttaa. (Norman 1988). Kognitiivisessa läpikäynnissä suoritetaan järjestelmään liittyviä tyypillisiä tehtäviä prototyypin avulla "oikean" (= suunnittelijan tarkoittaman) suoritussuunnitelman mukaisesti kohta kohdalta ja kirjataan ylös mahdollisia ongelmia vastaamalla kussakin vaiheessa neljään kysymykseen: 1. Onko käyttäjällä järjestelmän kannalta oikea tavoite? 2. Löytääkö hän järjestelmästä oikean toiminnon? 3. Yhdistääkö hän kyseisen toiminnon tavoitteeseensa? 4. Mikäli oikea toiminto on suoritettu, saako käyttäjä riittävästi palautetta tehtävän etenemisestä? Läpikäynti koostuu viidestä vaiheesta: 1. Esiselvitys 2. Ryhmän kokoaminen 3. Kognitiivinen läpikäynti istunnossa 4. Havaintojen tallentaminen 5. Havaittujen virheiden ja puutteiden korjaaminen Esiselvityksessä pyritään tunnistamaan järjestelmän tyypilliset käyttäjät, heidän järjestelmän käyttökokemuksensa ja tekninen osaamisensa. Esiselvityksessä

7 5 mietitään myös sopivat tehtävät kognitiiviselle läpikäynnille esimerkiksi markkinatutkimuksella. Näille tehtäville suunnitellaan sopiva skenaario taustaksi sekä selvitetään tehtävien suoritussuunnitelma vaiheittain. Kognitiivisen läpikäynnin voi tehdä yksinään tai ryhmässä. Parhaimpia tuloksia saadaan kuitenkin ryhmässä. Läpikäynnissä kaikki arvioijat asettuvat käyttäjän rooliin. Tehtävät käydään läpi ja havainnot tallennetaan esimerkiksi flappitaululle. Lopuksi tehdään korjausehdotuksia havaittuihin puutteisiin. Näitä voidaan korjata esimerkiksi poistamalla tehtäväketjusta turhia vaiheita, parantamalla toimintojen näkyvyyttä ja termistöä sekä lisäämällä selkeää palautetta käyttäjän toiminnoista.

8 6 3. Käyttäjätestit 3.1 Käytettävyystestaus Käytettävyystesti on yleisin käyttäjätestausmenetelmä. Käytettävyystestissä oikea käyttäjä tuodaan järjestelmän luo ja hänelle annetaan tehtäviä, joita hän yrittää suorittaa järjestelmällä. Testitilanne on kontrolloitu. Testin ohjaaja selittää käyttäjälle testitilanteen, antaa hänelle testitehtävät yksi kerrallaan ja tarvittaessa keskeyttää paikoilleen jääneen tehtävän suorituksen tai vihjeillä ohjaa käyttäjää oikeaan suuntaan. Testiä voidaan monitoroida videoimalla, äänittämällä ja tekemällä käsin muistiinpanoja esimerkiksi näyttökaavioon. Käyttäjää rohkaistaan ajattelemaan ääneen, jotta saadaan paremmin selville, miksi käyttäjä tekee joitakin valintoja tai ei löydä tarvittavaa toimintoa. Järjestelmä voi hyvin olla vasta prototyyppi, jopa paperinen sellainen. Jos käyttäjä tekee jotain, mihin prototyypissä ei ole varauduttu, käyttäjälle selitetään tai näytetään näyttökuvin, miten järjestelmä tällöin toimisi. Testi voidaan suorittaa tähän tarkoitukseen varatussa testilaboratoriossa, mutta myös tarvittaessa luonnollisemmassa ympäristössä. Testilaboratoriossa on kuitenkin usein paremmat monitorointivälineet, kuten kattokamera ja yksipuolinen peililasi kontrollihuoneeseen (ks. kuva 3). Ennen varsinaista käytettävyystestiä on hyvä suorittaa oikean käyttäjän (ei kuitenkaan tulevan testihenkilön) kanssa pilottitesti, jossa voidaan testata testitehtävien järkevyyttä ja proton ja monitorointivälineistön toimivuutta.

9 7 Koska ääneenajattelu hidastaa käyttäjän toimenpiteitä, ei käytettävyystesti sovellu tehokkuuden mittaamiseen. Sensijaan sillä voidaan hyvin mitata opittavuutta, virhetilanteiden määrää ja muistettavuutta. Myös miellyttävyydestä voidaan saadaan jonkinlainen kuva testiin liittyvällä loppuhaastattelulla. Kuva 3Käytettävyyslaboratorio Eettiset asiat käytettävyystestissä Koska käytettävyystestissä on mukana oikeita käyttäjiä on testitilanteessa syytä ottaa huomioon joitakin eettisiä asioita. Testihenkilöt tuntevat suuria suorituspaineita testitilanteessa (Nielsen 1986). Epäonnistumisen pelko on vahva. Myös tarkkailu ja mahdollinen videointi lisäävät paineita. Tämän takia testihenkilölle kannattaa painottaa heti testin alussa, että nyt testataan järjestelmää, ei testihenkilöä. On myös hyvä kertoa, että ohjelmassa on todennäköisesti virheitä (käytettävyysheikkouksia), ja että niitä juuri yritetään tässä löytää. Käyttäjälle kerrotaan myös, että hän voi keskeyttää, tai pitää tauon testistä koska tahansa, ja että testin tulokset ovat luottamukselliset, eivätkä ne tule

10 8 esimerkiksi esimiehen tietoon. Testin monitorointitavat on myös hyvä selvittää käyttäjälle. Testihuoneessa kannattaa olla mahdollisimman vähän henkilöitä paikalla. Kaikki häiriöt ja keskeytyksen on eliminoitava - esimerkiksi testihuoneen oveen on hyvä laittaa lappu "testi käynnissä". Käyttäjälle ei saa ikinä nauraa, häntä ei saa hoputtaa, eikä neuvoa. Kuitenkin, jos käyttäjä tuntuu jäävän paikoilleen tehtävän suorituksessa, ohjaaja voi sopivin vihjein ohjata häntä oikeaan suuntaan. Jos testitehtävä ei sittenkään onnistu, siirrytään seuraavaan tehtävään nolaamatta käyttäjää. Missään vaiheessa ei käyttäjälle saa tulla tunne, että hän on tyhmä tehdessään virheitä. Käyttäjää ei kannata myöskään kutsua esimerkiksi koekaniiniksi, koska hänhän ei ole tässä testattavana. Testin ilmapiirin pitäisi olla rento, puitteet kodikkaat ja tarjolla virvokkeita ja pikkupurtavaa. Pieni "smalltalk" ennen testiä ja testin jälkeen on myös omiaan rentouttamaan käyttäjää. Testitehtävät Testitehtävien tulisi olla selkeästi järjestelmälle tyypillisiä käyttäjän tavoitteita. Tehtävissä ei pitäisi olla teknistä tai muuten käyttäjälle tuntematonta termistöä. Lisäksi ensimmäisen testitehtävän pitäisi olla niin helppo, että käyttäjä varmasti suoriutuu siitä, jotta onnistumisen kokemus antaisi testin alkuun itsevarmuutta. Esimerkki huonosta testitehtävästä: Tehtävä on suunniteltu ensimmäiseksi testitehtäväksi vahtimestareille tarkoitetun hissien seurantaohjelman testaukseen. "Siirry konfiguraatiomoodiin ja tee siellä seuraavat asetukset:" Perässä on annettuna tarvittavat asetukset.

11 9 Käyttäjän tavoite ei voi olla asetusten muuttaminen tai johonkin moodiin siirtyminen. Nämä ovat vain tehtävän suorituksen vaiheita (vaikka saattavat liittyä johonkin olennaiseenkin tämän järjestelmän tehtävään). Lisäksi tehtävässä on paljastettu, miten se suoritetaan. Testaaminen tällä tehtävällä mittaa siten hyvin huonosti järjestelmän käytettävyyttä. Tehtävän termistö on myös väärä. Testitehtävien pitäisi olla käyttäjän omaa luonnollista kieltä tai hänen ammattitermistöään. Tämä termistö saattaa olla käyttäjälle täysin käsittämätön. Esimerkki hyvästä testitehtävästä samalle järjestelmälle: "Toisessa kerroksessa tehdään remonttia. Estä hissin pysähtyminen siellä." Nyt tehtävän tavoite on realistinen, ja tekninen termistö on poistettu. Tämä on tosin liian vaikea tehtävä ensimmäiseksi testitehtäväksi. 3.2 Paritestaus Paritestaus (Riihiaho 2000a) on tavallisen käytettävyystestin muunnelma. Siinä testitehtäviä suoritetaan pareittain. Paritestauksessa ääneen ajattelu on tehostunut, koska työpari yrittää yhteistyössä suorittaa tehtäviä tai ääneen ajattelun korvaa luonnollinen neuvottelu ja ideoiden vaihto. 3.3 Ryhmäläpikäynti Ryhmäläpikäynti yhdistää asiantuntija-arvioiden ja käyttäjätestien ominaisuuksia (Riihiaho 2000b). Siinä käyttäjät, suunnittelijat ja käytettävyyden asiantuntijat suorittavat tehtäviä järjestelmän paperikuvien avulla. Arvioijat kirjoittavat paperikuviin kunkin suoritusvaiheen kohdalle, mitä siinä tekisivät (kuva 4).

12 10 Kuva 4Ryhmäläpikäynti kirjaston www-hakulomakkeelle (Riihiaho 2000b) Kaikki ryhmäläpikäynnin osallistujat samaistuvat käyttäjän rooliin. Tehtävät suoritetaan itsenäisesti. Läpikäynnin jälkeen ryhmä keskustelee tekemistään ratkaisuista. Ryhmäläpikäyntiä voi tehdä jo tuotekehityksen alkuvaiheessa, koska siinä ei tarvita toimivaa protoa. Jos proto jo on, sitä voidaan esitellä istunnon alussa, jotta arvioijat saisivat paremman käsityksen järjestelmästä. Ryhmäläpikäynti soveltuu parhaiten opittavuuden mittaamiseen. Sen arvokkainta antia on siinä syntyvä keskustelu, koska siihen osallistuu keskenään erilaisen näkökulman järjestelmään omaavia arvoijia. Suunnittelijat voivat tilaisuudessa ehdottaa uusia muutoksia järjestelmään ja saada niistä käyttäjiltä heti palautetta.

13 11 Suunnittelijat taas voivat selventää käyttäjille järjestelmän toimintaa ja näin saada vihjeitä käyttöohjeiden laadintaa varten.

14 12 4. Kritiikkiä ja johtopäätöksiä On hyvä, että käytettävyysarvioita tehdään, mutta käyttävyystestaus ei voi koskaan korvata käyttöliittymäsuunnittelua (Cooper 1998) Käytettävyystestaus tilataan valitettavan usein liian myöhäisessä vaiheessa tuotekehitystä. Yrityksessä voi olla uutena, jalona tavoitteena saada tuotteisiin käytettävyyttä, mutta sen sijaan, että panostettaisiin kunnolliseen, tavoitelähtöiseen käyttöliittymäsuunnitteluun, tilataan toteutusvaiheen lopuksi käytettävyystesti. Tällöin, valitettavasti, käytettävyystestin tulokset ehtivät harvoin vaikuttaa lopullisen tuotteen käytettävyyteen, koska valmis tuote täytyy saada nopeasti luovutuskuntoon. Vielä tänään ohjelmistoyrityksissä panostetaan liian vähän tai ei lainkaan käytettävyyteen systeemityöprosessin aikana. Käytettävyyden huomioonottaminen on harvoin edes kuvattu tuossa prosessissa. Käytettävyys jää siis usein teknisten suunnittelijoiden ja toteuttajien harteille. Cooperin mukaan käytettävyystestin arvokkain anti tuleekin, kun ohjelmoijat istutetaan peililasin taakse seuraamaan testitilannetta (Cooper 1999). Ohjelmoijat saattavat tällöin jopa ruveta epäilemään, että käyttäjät ovat henkisesti jälkeenjääneitä heidän taistellessaan tuloksetta ohjelmoijien käyttöliittymäratkaisujen kanssa. Ohjelmistotuotantoprosessiin oikein ajoitetulla käytettävyyden arvioinnilla voi kuitenkin olla tärkeä merkitys tuotteen käytettävyyteen. Useinhan monet käytettävyysongelmat voidaan eliminoida asiantuntija-arvioilla jo aikaisessa vaiheessa. Käyttäjätesteissa taas saadaan aidon loppukäyttäjän "arvio" järjestelmästä, jolloin voidaan löytää vielä asiantuntija-arvioissa löytymättömiä virheitä. Tämäkin voidaan tehdä jo prototyypistä, jopa paperisesta sellaisesta. Ja

15 13 tietenkin, mitä aikaisemmassa vaiheessa ongelmat ja virheet havaitaan, sitä "edullisempaa" ne on korjata.

16 14 Lähteet Cooper, A. (1995) About Face. IDG books. Cooper, A. (1999) Nörttien valtakunta. Suomen Atk-kustannus. ISO/DIS :1996, Ergonomic requirements for office work with visual display terminals (VTDs) - Part 11: Guidance on usability. Nielsen, J. (1993) Usability Engineering. Academic Press. Nielsen, J. (1994) Enhancing the Explanatory Power of Usability Heuristics. Human Factors in Computing Systems, CHI 94 Conference Proceedings, Norman, D (1988) The psychology of everyday things. Basic Books. Riihiaho, Sirpa (2000a) Experiences with Usability Evaluation Methods. Lisensiaattityö, Teknillinen korkeakoulu, Espoo. Riihiaho, Sirpa (2000b) Käytettävyystestauksen muunnelmia Wharton, C et al. (1994) The cognitive walkthrough method: A practitioner s guide. Teoksessa Nielsen, J. & Mack R.L. (toim.) Usability inspection methods. John Wiley & Sons, Inc. s