Heuristinen arviointi

Transkriptio

1 Teknillinen Korkeakoulu T Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Heuristinen arviointi Ryhmä Rajoitteiset Mitro Kuha Versio Päivämäärä Tekijä Muutokset Mitro Kuha Dokumentin siirtäminen dokumenttipohjaan.

2 Sisällysluettelo 1 Johdanto Heuristisen arvioinnin hyödyt... 1 Heuristisen arvioinnin kulku Järjestelmän läpikäynti yksittäin Ongelmien keruu... 2.Ongelmien vakavuuden arviointi Keskustelu ja ideointi Nielsenin heuristiikat Yksinkertainen ja luonnollinen dialogi Käytä käyttäjien omaa kieltä....minimoi käyttäjän muistikuorma... 4.Tee käyttöliittymästä 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 Anna virhetilanteista selkeät virheilmoitukset Vältä virhetilanteita Anna riittävä ja selkeä apu ja dokumentaatio Soveltamissuunnitelma ja tavoitteet Paperiversion heuristinen arviointi Valmiille järjestelmälle suoritettava heuristinen arviointi Tuloksia Yhteenveto Lähteet... 8

3 1 Johdanto Heuristiikka oppi ongelmanratkaisun menetelmistä, keksimistaito Heuristinen keksimään, oivaltamaan johtava, yrityksen ja erehdyksen kautta etenevä Heuristinen arviointi on tietokoneohjelmistojen ja verkkosivustojen kehityksessä käytettävä menetelmä, jonka avulla voidaan löytää arvioitavan järjestelmän yleisiä käytettävyysongelmia jo tuotekehityksen alkuvaiheessa. Heuristisessa arvioinnissa tarkastetaan käyttöliittymän eri osat vertaamalla niitä heuristiikkoihin eli käytettävyysperiaatteisiin. Muistilistat voivat sisältää yleisiä sunnitteluohjeita tai vain tiettyä tuotetta koskemaan tarkoitettuja käytettävyysohjeita. Arviointiin ei tarvita valmista ja toimivaa järjestelmää, vaan heuristinen arviointi voidaan tehdä vaikka käyttöliittymän paperiprototyypille. Arviointi voidaan siis tehdä jo varhaisessa tuotekehityksen vaiheessa ja siten ehkäistä käyttöliittymän virheitä jo ennen varsinaisen käyttöliittymän koodaamista. Heuristinen arviointi on nopea, yksinkertainen ja edullinen tapa etsiä käyttöliittymän virheitä ja ongelmakohtia. Heuristinen arviointi ei korvaa käyttäjän kanssa suoritettavia testejä, sillä se ei ota kantaa järjestelmän sopivuuteen aiottuun tehtävään, eli järjestelmän toimivuuteen. Heuristinen arviointi on menetelmä muun kehitystyön tueksi ja sen tarkoitus on vähentää käytettävyysvirheitä mahdollisimman aikaisessa vaiheessa. Heuristisella arvioinnilla löytyviä käyttöliittymän ongelmia ovat esimerkiksi vieraat termit, epäyhteneväisyydet järjestelmän sanastossa, näyttöjen sommittelun virheet, sekä tekstikenttien epäjohdonmukainen sommittelu ja järjestys 2 Heuristisen arvioinnin hyödyt Arvioinnin tehokkuus riippuu sen tekijöiden käytettävyyskokemuksesta ja siitä, kuinka hyvin he tuntevat tutkittavan järjestelmän ja sen käyttötarkoituksen. Paras tulos saadaan käytettävyyden ja sovellusalueen asiantuntijaa käyttämällä. Hyvään tulokseen päästään myös, kun käytettävyysasioita tuntematon suunnittelija arvioi järjestelmää muistilistojen avulla. Jokainen ajoissa havaittu ja korjattu ongelma helpottaa järjestelmän kehittämistyötä jatkossa. Arvioijia olisi hyvä olla useampia, sillä eri ihmiset löytävät järjestelmästä erilaisia virheitä. Tutkimuksissa on todettu, että yksi arvioija löytää n. 5% virheistä, kolme n. 60% ja viisi n. 75% ongelmista. Kolmesta viiteen arvioitsijaa on siis hyvä määrä tekemään heuristista arviota. Yli viiden arvioijan käyttämisen tuoma hyöty ei enää vastaa arviointiin kulutettuja lisäresursseja. Heuristisen arvioinnin kulku Heuristisen arvioinnin kulku voidaan jakaa neljään eri vaiheeseen: järjestelmän läpikäymiseen yksittäin, ongelmien keruuseen, ongelmien vakavuuden arvioimiseen sekä keskusteluun ja ideointiin ongelmista. 1

4 1. Järjestelmän läpikäynti yksittäin Kunkin arvioijan tulisi käydä järjestelmä läpi yksin. Jos järjestelmä on niin laaja, että sitä ei ehdi käymään läpi muutamassa tunnissa, valitaan vain osa järjestelmästä arvioitavaksi kerrallaan. Järjestelmä voidaan käydä läpi näyttö näytöltä verraten niitä heuristiikkoihin tai käymällä kaikki näytöt läpi kuhunkin heuristiikkaan verraten. Jos järjestelmä sisältää jotain erityissanastoa, jota arvioija ei hallitse, arvioinnissa tulisi olla mukana joku kyseisen alueen erikoisasiantuntija. 2. Ongelmien keruu Arviointi-istunnon tuloksena syntyy lista havaituista ongelmista ja perustelut siitä, miksi ne ovat ongelmia. Kukin arvioija voi laatia oman listansa tai arvioinnissa voi olla mukana ongelmat muistiin kirjaava havainnoija.. Ongelmien vakavuuden arviointi Ongelmista kerätään lopuksi yksi lista. Ongelmat luokitellaan niiden vakavuuden mukaisesti tärkeysjärjestykseen esimerkiksi käyttämällä seuraavaa asteikkoa: katastrofaalinen vakava häiritsevä vähäinen kosmeettinen Ryhmittely kannattaa tehdä vasta varsinaisten arviointien jälkeen. Vakavuuden arviointi voidaan tehdä ryhmässä tai yksittäin. 4. Keskustelu ja ideointi Kun tärkeysjärjestykseen järjestetty ongelmalista on saatu valmiiksi, arvioinnin suorittanut ryhmä kokoontuu keskustelemaan tuloksista ja luomaan parannusehdotuksia. Keskustelussa olisi hyvä olla mukana arvioinnin tekijöiden lisäksi myös järjestelmän suunnitteluun osallistuva henkilö. Ongelmien lisäksi keskustelussa voidaan tuoda esille järjestelmän hyviä puolia ja uusia ehdotuksia järjestelmän käyttöliittymän kehittämiseksi. 4 Nielsenin heuristiikat Tunnetuin käyttöliittymien heuristiseen arviointiin liittyvistä heuristisista listoista lienee Nielsenin heuristiikat. Nielsenin heuristiikat on kymmenen kohdan lista tunnetuista ja tunnustetuista hyvän käyttöliittymän määrittävistä ominaisuuksista. Nielsenin heuristiikkoja voidaan sellaisenaan käyttää apuna käyttöliittymän heuristista arviointia tehtäessä. 1. Yksinkertainen ja luonnollinen dialogi Käyttöliittymän tulee olla mahdollisimman yksinkertainen ja siinä tulee olla vain tarvittavat elementit, eikä mitään ylimääräistä. Sellaiset toiminnot, joita tarvitaan vain harvoin, tulee sijoittaa erilliseen ikkunaan tai valikon taakse. Käyttäjä löytää 2

5 yksinkertaisesta käyttöliittymästä nopeasti haluamansa toiminnon. Käyttöliittymä on luonnollinen silloin, jos esille tuodut käyttöliittymäelementit ja niiden ryhmittely tukevat käyttäjän työtä. Käyttäjälle tulee tarjota selkeä etenemistapa tehtäviensä tekoon. 2. Käytä käyttäjien omaa kieltä Käyttöliittymän pitäisi olla käyttäjän omalla äidinkielellä tehty ja sen sanaston tulisi olla käyttäjän omaa ammattisanastoa. Käyttöliittymän viestit tulisi esittää selkeästi ja käyttäjän kannalta ajateltuna. Käyttöliittymän perusosissa, valikoissa ja painikkeissa tulee käyttää käyttöjärjestelmän vakiintunutta termistöä, ellei poikkeuksiin ole painavaa syytä.. Minimoi käyttäjän muistikuorma Käyttäjän muistikuorman tulee olla mahdollisimman kevyt, eli käyttöliittymän ei pitäisi edellyttää asioiden ulkoa muistamista. Ihminen on toisaalta hyvä tunnistamaan asioita ja esimerkiksi tiedosta avatessaan hän tunnistaa yleensä oikean tiedoston, jos tiedostojen nimet näytetään.valikkoilla voidaan tarjota ohjelman käyttöön tarvittavat komennot siten, että käyttäjän ei tarvitse muistaa esimerkiksi monimutkaisia tekstipohjaisia komentoja. 4. Tee käyttöliittymästä yhdenmukainen Komentojen ja valintojen tulee toimia johdonmukaisesti käyttöliittymän kaikissa osissa. Tietojärjestelmissä pitäisi noudattaa totuttuja käytäntöjä. Yhdenmukaisuus tarkoittaa myös käyttöliittymänosien sijoittelua. Eri näyttöjen ja näkymien pitäisi muistuttaa toisiaan ja kontrollien olla samoilla paikoilla läpi järjestelmän. Käyttäjät ovat voineet tottua järjestelmään vuosien kuluessa ja odottavat uusien versioiden vastaavan toiminnoiltaan vanhoja. Jos käyttöliittymässä ei ole huomattavia ongelmia, eri versioiden välille ei välttämättä kannata muutoksia käyttöliittymään. Joissakin tapauksissa yhdenmukaisuus voi olla jopa tärkeämpää kuin käytettävyys. 5. Anna käyttäjälle palautetta toiminnoista Käyttäjän pitää saada palautetta kaikista tekemistään komennoista ja valinnoista, jotta hän saa tiedon siitä, että tietokone on todellakin tehnyt halutun toimenpiteen. Mikäli mitään palautetta ei tule, käyttäjä voi luulla, että toimenpide on epäonnistunut ja saattaa suotta toistaa jo tehdyn toimenpiteen. Järjestelmän tulisi kertoa virhetilanteiden lisäksi myös kaikista muista toiminnoistaan. Mikäli toiminnon suorittaminen kestää kauan, myös siitä pitäisi informoida käyttäjää. Toimenpiteeseen kulutettu ja siihen vielä kuluva aika voidaan esittää numeerisesti, graafisesti tai molemmilla tavoilla yhtä aikaa. 6. Anna selkeä poistumistapa eri tiloista ja toiminnoista Käyttäjälle pitäisi antaa mahdollisuus perua tekemiään toimenpiteitä esimerkiksi Kumoa tai Peruuta -komennoilla. Tällöin käyttäjä uskaltaa kokeilla järjestelmällä

6 erilaisia asioita ja voi oppia uusia käyttötapoja. Mikäli jokin toimenpide on lopullinen, esimerkiksi tiedoston poisto, käyttäjältä pitäisi kysyä vielä varmistus toimenpiteelle. 7. Anna käyttäjälle mahdollisuus käyttää oikopolkuja Kun käyttäjä on tutustunut järjestelmään, hän haluaa yleensä hyödyntää sitä mahdollisimman tehokkaasti ja nopeasti. Erilaiset oikopolut ja näppäinyhdistelmien käyttö usein käytettyjen toimintojen suorittamiseksi nopeuttavat yleensä järjestelmän käyttöä ja tehostavat työskentelyä. Oikopulkujen ei pitäisi olla ainoa tapa käskyn suorittamiseksi, vaan kaikkien komentojen tulee löytyä myös valikkojen kautta. Valikoissa voidaan esittää myös käskyn oikopolku, jolloin käyttäjän on helppo oppia oikopolut usein käyttämilleen toiminnoille. 8. Anna virhetilanteista selkeät virheilmoitukset Järjestelmän tulisi antaa mahdollisimman selkeä virheilmoitus virhetilanteessa. Ilmoituksen tulee olla tarkka ja käyttäjän ymmärtämällä kielellä ja sanastolla. Virheilmoituksen tulee olla kohtelias, eikä käyttäjää saa haukkua tai syyllistää virheestä. Ilmoituksen olisi hyvä myös ohjata käyttäjää korjaamaan virheen. Virheen ammattisanastoa sisältävät tekniset yksityiskohdat näytetään vain erikseen pyydettäessä. 9. Vältä virhetilanteita Hyviäkin virheilmoituksia parempi on se, että virheitä pyritään mahdollisuuksien mukaan välttämään. Komennot ja tiedostojen nimet voidaan antaa valikoissa, joilloin vältetään turhat kirjoitusvirheet. Käyttäjiltä pitää myös pyytää varmistus sellaisille komennoille, joita ei pystytä perumaan, kuten tiedoston poistolle tai ylikirjoittamiselle. 10.Anna riittävä ja selkeä apu ja dokumentaatio Järjestelmää pitäisi pystyä käyttämään ilman erillisiä ohjeita. Tämä on harvoin mahdollista monimutkaisten järjestelmien ollessa kyseessä. Käyttäjälle voidaan antaa tietoa ja ohjeita kulloiseenkin tilaan ja toimintaan sovitetuilla ohjeilla. Käyttäjä saa siis tietoa juuri siitä ongelmasta, joka hänellä on käsillä. Myös ohjeissa tulee muistaa käyttää käyttäjien ymmärtämää kieltä ja sanastoa. 5 Soveltamissuunnitelma ja tavoitteet Ryhmän Rajoitteiset ohjelmatyöprojektin, Lmodelsin, painopiste on järjestelmän sisäisellä toiminnalla ja käyttöliittymän osuus projektista on suhteellisen pieni. Käyttöliittymässä on kuitenkin useita näyttöjä ja sen verran toiminnallisuutta, että heuristisella arvioinnilla voidaan saavuttaa muitakin hyötyjä kuin menetelmän ryhmäläisille tutuksi tekeminen. Heuristista arviointia on tarkoitus soveltaa järjestelmään kahdesti projektin aikana, käyttöliittymän paperiprotolle ja valmiille, toimivalle järjestelmälle. 1. Paperiversion heuristinen arviointi Käyttöliittymän paperiprotolle suoritetaan heuristinen arviointi esiteltyjen Nielsenin 4

7 heuristiikkojen mukaisesti ennen dynaamisen html-version tekemistä. Tavoitteena on löytää ja poistaa käyttöliittymään pesiytyneitä ongelmia ja vähentää siten myöhäisempää korjaustarvetta. Heuristinen arviointi suoritetaan esitetystä menetelmästä poiketen siinä suhteessa, että käyttöliittymästä etsitään heuristiikkojen vastaisia ominaisuuksia ryhmässä sen sijaan, että kukin arvioija kävisi käyttöliittymää yksin läpi. Arvioinnin jälkeen on tarkoitus käydä vapaata keskustelua käyttöliittymän ja sen toiminnallisuuden parantamiseksi. Muutosehdotuksista varmistetaan, että ne eivät riko käytettyjä heuristisia sääntöjä. Ensimmäinen heuristinen arviointi suoritetaan toisen iteraatiokierroksen aikana. ennen dynaamisen weppiversion laatimista käydään läpi ryhmässä, ei yksittäin vapaata keskustelua ja ehdotuksia ulkoasun ja kälin parantamiseksi 2. Valmiille järjestelmälle suoritettava heuristinen arviointi Toinen heuristinen arviointi suoritetaan valmiille ja toimivalle järjestelmälle. Järjestelmä käydään läpi heuristisen arvioinnin mukaisesti järjestelmää tietokoneella käyttäen. Tässä vaiheessa pyritään löytämään ensimmäisessä heuristisessa arvioinnissa järjestelmään jääneitä käyttöliittymävirheitä, sekä tarkistamaan, että käyttöliittymään tehdyt muutokset ovat todella heuristiikkojen mukaisia. Myös toinen heuristinen arviointi tehdään kolmen henkilön ryhmässä. Järjestelmän käyttöliittymään saattaa tulla vielä muutoksia arvioinnin perusteella, mutta toisen arvioinnin varsinainen tarkoitus on vain varmistua käyttöliittymän selkeydestä ja toimivuudesta. Mikäli muutosehdotuksia tulee, niiden toteutustarve mietitään huolellisesti. 6 Tuloksia Ensimmäisessä, paperiversiolle tehdyssä heuristisessa arvioinnissa löydettiin taulukossa 1 esitetyt käyttöliittymän virheet ja käytettävyysongelmat. Arvioinnissa käsiteltiin paperiproton näytöt yksi kerrallaan ja kirjattiin jokaisen virheen kohdalta näytön numero, käytettävyysongelman kuvaus, rikottu heuristiikka (vrt. Kappale 4), ongelman vakavuus asteikolla 1-5, jossa 5 on vakavin luokka, sekä parannusehdotus ongelman korjaamiseksi. Heuristisen arvioinnin jälkeisessä keskustelussa pohdittiin käyttöliittymän yleisilmettä ja kuinka sitä voitaisiin parantaa. Keskustelussa todettiin käyttöliittymän täyttävän projektin tavoitteet käyttöliittymän osalta, sillä www-käyttöliittymä tehdään vain testi- ja demokäyttöön. Keskustelussa todettiin myös, että käyttöliittymästä saisi näyttävämmän ja paremman näköisen lisäämällä värejä ja grafiikkaa. Todettiin myös, että somistaminen ei ole järjestelmän toiminnan ja käytettävyyden kannalta oleellinen asia. 5

8 Näyttö Ongelma Heuristiikat Vakavuus Parannusehdotus 1 Linearisointia ei ole selitetty, 10 2 Lisätään selitys 1,2,,4 2 Sivun nimi piilossa oikeassa reunassa Mallin nimeäminen on valinnaista, tätä ei kerrota käyttäjälle 2 1,2 2 Siirretään vasemmalle & isommalla Lisätään tieto valinnaisuudesta 1,2,,4 Turhia linkkejä näkyvissä 1,9 4 Poistetaan turhat linkit Ei tietoa, missä muodossa ratkaistava malli on Valid ei anna selkeää kuvaa arvostaan Ei tarpeeksi tietoa sivulla tapahtuvasta toiminnasta 5 5 Lisätään tieto 1,2,10,5 5 Ei virheilmoituksia Ei palautetta pitkään kestävästä ratkaisusta Ei tietoa, mihin taulukon termit liittyvät Muutetaan nimi kuvaavammaksi, esim. Feasible Lisätään tietoa mallin tilasta ja siitä, mitä sille tehdään Annetaan virheilmoitus virheellisestä mallista 5 2 Annetaan väliaikatietoja 4 Lisätään help-sivulle kuva solver-sivusta Teksteissä kirjoitus- ja Korjataan kirjoitusvirheet asiavirheitä Taulukko 1. Ensimmäisen Heuristisen arvioinnin tulokset. Ensimmäisessä arvioinnissa löytyneistä yhdestätoista käytettävyysongelmasta korjattiin seitsemän. Kaikkia löytyneitä ongelmia ei korjattu siksi, että järjestemän testikäyttöliittymä on tosiaankin vain rajatun ja aiheesta jo hyvin perillä olevan joukon käyttöön sekä osa ongelmakohdista on esitetty asiakkaan haluamassa muodossa. Suunnitellusta poiketen toisen Heuristisen arvioinnin suoritti projektin vertaisryhmä Mupe vertaistestauksena. Vertaisryhmä löysi arvioinnissaan neljä käytettävyysongelmaa, joista osa oli edellämainittuja järjestelmän luonteesta riippuvia ja siksi korjaamatta jätettyjä ja osa dynaamiseen web-versioon liittyviä virheitä, jotka paperiprotoa testatessa eivät luonnollisesti tulleet esille. Toisen Heuristisen arvioinnin tulokset on esitelty taulukossa 2. 6

9 Näyttö Ongelma Heuristiikat Vakavuus Parannusehdotus 4,4 Jos desimaalit erotellaan pilkulla pisteen sijaan oikelta näyttävä syöte ei toimi Mallin testaamiseen asennuksen varmistamiseksi ei ole ohjetta Jos lähettää mallin samalla tiedostosta sekä copypastella järjestelmä ei kerro kumpaa käytetään Harhaan johtava virheilmoitus oikealta näyttävällä syötteellä (ylimääräinen välilyönti) Kenttien nimet melko epäinformatiivisia Taulukko 2. Toisen Heuristisen arvioinnin tulokset. 1, 2, , Lisätään syötteelle esiprosessointi Lisätään ohje ja esimerkkimalli Lisätään tieto siitä, kumpaa mallia käytetään Parannetaan virheilmoituksia ja lisätään esiparsinta Kentän nimestä linkki oikeaan help-sivun kohtaan Osa löydetyistä ongelmista on päällekkäisiä aikaisemmin todettujen kanssa ja johtuvat aiheen teknisestä vaativuudesta. Järjestelmän käyttäjältä edellytetään jonkinasteista perehtymistä aiheeseen, jotta hän voi ylipäätään tehdä järjestelmällä mitään hyödyllistä. Kuten vertaisryhmä totesi testiraportissaan: Lmodels vaikuttaa toimivan hyvin ja täyttää asiakkaan tarpeet. Käyttöliittymä vaati kunnollisen tutustumisen ohjelman ideaan, eivätkä käytetyt termit aukea maallikolle. Käyttöliittymä on kuitenkin tarkoitettu vain palvelinkomponentin esittelemiseen ja käyttäjänä on asiakas tai Rajoitteiset-ryhmän jäsen, joten käyttöliittymä täyttää tehtävänsä hyvin. 7 Yhteenveto Heuristinen arviointi vaikuttaa olevan käyttökelpoinen ja toimiva menetelmä käyttöliittymän arviointiin. Koska mitään absoluuttista totuutta hyvän käyttöliittymän ominaisuuksille ei ole olemassa ja koska eri ihmiset kokevat kulttuuri- ja kokemustaustansa vuoksierilaiset asiat merkittävinä, on hyvä, että on menetelmiä, joilla voidaan löytää useimmille sopiva kompromissiratkaisu. Heuristisen arvioinnin erityisvahvuus on mielestäni se, että arviointi voidaan suorittaa jo hyvin varhaisessa vaiheessa olevalle käyttöliittymälle ennen varsinaisen toiminnallisuuden rakentamista. Heuristiseen arviointiin kuluva aika on varsin kohtuullinen ja se lienee kannattava investointi sekä kehitysvaiheessa virheiden aikaisemmin havaitsemiseksi että myöhemmin valmiin tuotteen paremman käytettävyyden kannalta. Henkilökohtaisesti pidän Heuristista arviointia toimivana ja hyvänä menetelmänä käyttöliittymäkehityksessä ja aion käyttää sitä myös jatkossa. 7

10 8 Lähteet Jakob Nielsen on Usability and Web Design Käytettävyyden arviointi ilman käyttäjiä, Sirpa Riihiaho Suomen kielen sivistyssanakirja, Timo Nurmi, Ilkka Rekiaro, Päivi Rekiaro, Gummerus