Web-sivustoihin käytettävät käytettävyystestausmenetelmät

Transkriptio

1 Web-sivustoihin käytettävät käytettävyystestausmenetelmät Oulun yliopisto Tietojenkäsittelytieteiden laitos Luk-tutkielma Jouni Seppo Sakari Rissanen

2 2 Tiivistelmä Tässä Luk-tutkielmassa käsitellään eri käytettävyystestausmenetelmiä ja niiden käyttöä erityisesti web-sivustoilla ja web-järjestelmissä. Tutkielman tavoitteena on selvittää käytettävyystestausprosessiin ja käytettävyyteen liittyviä asioita ja menetelmiä. Tarkoituksena on kirjallisuutta hyödyntäen ottaa selville, mitä eri menetelmiä käytetään käytettävyystestausprosessissa, kun testin kohteena ovat web-sivustot ja webjärjestelmät. Lisäksi tutkielmassa kerrotaan kirjallisuudessa esiintyviä suunnitteluohjeita web-sivustoja luotaessa. Tutkimusmenetelmänä on käytetty kartoittavaa kirjallisuuskatsausta. Tutkimuksen tuloksena löydettiin kolme eri web-sivustoille tehtävää käytettävyystestausmenetelmää: laboratoriotestaus, etänä tehtävä testaus sekä heuristinen evaluointi. Asiasanat Tutkielma, tietojenkäsittelytieteet, käytettävyystestaus, web-käytettävyys, heuristinen evaluointi

3 3 Sisällys Tiivistelmä... 2 Sisällys Johdanto Laboratoriotestaus Testityypit Testauksen tavoitteet ja huolenaiheet Testaajien määrä ja rekrytointi Testien kesto, tehtävät ja testaajien palkitseminen Laboratorioasetelma Laboratoriotestauksen edut ja heikkoudet Paperiprototyypit laboratoriossa Etänä tapahtuva testaus Testaajat Eri lähestymistavat ja OpenWebSurvey User-reported Critical Incident Foorumit Päiväkirjat Heuristinen evaluointi Heuristisen evaluoinnin vahvuudet Heuristisen evaluoinnin heikkoudet Evaluoinnin antamat suuntaviivat suunnittelulle Yhteenveto Pohdinta ja jatkotutkimusaiheet Lähteet... 19

4 4 1. Johdanto Web-sivustojen ja erilaisten web-järjestelmien määrä on kasvanut räjähdysmäisesti viimeisten vuosien aikana. Sivustoiden ja järjestelmien käytettävyyden pitää olla hyvällä tasolla, jotta ne erottuvat suuresta massasta. Käytettävyyttä voidaan parantaa käytettävyystesteillä ja muilla menetelmillä, joilla pyritään parantamaan käytettävyyttä. Web-järjestelmät ovat nykyään erittäin laajoja ja pitkälle kehittyneitä ohjelmistotuotteita, joiden käytettävyys voi määrittää niiden onnistumisen tai epäonnistumisen (Matera, Rizzo ja Carughi, 2006). Web-sivustot ja web-järjestelmät ovat yleensä pieniä yhden hengen projekteja tai sitten suurien firmojen sivustoja. Suurissa firmoissa voi olla kokonainen osasto suunnittelemassa sivustoja, mutta pienemmillä firmoilla ei ole käytettävyysasiantuntijoita apunaan ja monet eivät edes ymmärrä käytettävyyden merkitystä. Monilla ei ole aikaa tai halua tehdä käytettävyystestausta, koska sivusto tai järjestelmä täytyy julkaista nopeasti, jotta saavutetaan etua kilpailijoihin. (Schroeder & Spool 2001). Levi ja Conrad (1997) ovat sitä mieltä, että web-sivustojen laatiminen on kuin tavallinen ohjelmistokehitysprosessi ja sisältää kaikki samat vaiheet. He mainitsevat, että kehityksessä käytetään samoja työkaluja ja metodeja, mitä on käytetty aiemmissakin kehitysprojekteissa. Tämä tarkoittaa, että käytetään jo opittuja asioita. Levi ja Conrad (1997) kertovat, että tavallisesta ohjelmistokehitysprosessista puuttuu käytettävyyskomponentti, joten myös web-sivustoja kehitettäessä käytettävyyttä ei suunnitella. Pelkät hyvät käytettävyysohjeet eivät heidän mielestään riitä vaan tarvitaan jokin prosessi validoimaan käytettävyyttä. Hyvä validoiva prosessi on käytettävyystestausprosessi. Käytettävyystestausprosessista on erilaisia määritelmiä. Levi ja Condar (1997) luonnehtivat käytettävyystestausprosessia prosessiksi, jossa mitataan ihmisen ja tietokoneen välisen vuorovaikutuksen ominaisuudet järjestelmässä ja virheet tunnistetaan korjaamista varten. Dumas ja Redish (1999, s. 22) kirjoittavat, että käytettävyystestauksen tavoite on parantaa testatun tuotteen käytettävyyttä, mutta lisäävät vielä, että tarkoitus on myös parantaa prosessia miten tuotteita suunnitellaan ja kehitetään, jotta samoja ongelmia ei ilmenisi jatkossa. Käytettävyystestauksesta on myös esitetty toisenlaisia näkökulmia. Esimerkiksi Kallepalli ja Tian (2001) ovat sitä mieltä, että käytettävyystestaus testaa ainoastaan käytettävyyttä ja sivustojen näkyvyyttä. Heidän mielestään sen pitäisi mitata enemmän myös luotettavuutta eli toimitetaanko käyttäjälle hänen tarvitsemansa informaatio. Käytettävyydelle on myös omat määritelmänsä. Nielsen (1993, s. 25) esittää käytettävyydelle ainakin seuraavat määritteet: helppo oppia, tehokas käyttää, helppo muistaa, vähän virheitä ja subjektiivisesti miellyttävä. Nielsen (1993, s. 26) muistuttaakin, että käytettävyys ei ole vain yksisuuntainen ominaisuus vaan sillä on ainakin edellä mainitut attribuutit. Dumas ja Redish (1999, s. 3) määrittelevät kirjassaan hyvän käytettävyyden niin, että tuotetta käyttävä käyttäjä voi suorittaa omat tehtävänsä nopeasti ja helposti. Dumas ja Redish (1999, s. 14) esittävät muutamia etuja, joita voidaan saavuttaa keskittymällä enemmän käytettävyyteen. Etuja ovat mm. myynnin parantuminen, yhtiön

5 maineen parantuminen sekä helpdesk -palvelupyyntöjen väheneminen. Myös Levi ja Conrad (1997) tukevat näitä väitteitä. Heidän mielestä huono käytettävyys voi olla kaupallinen katastrofi. Käytettävyystestaus ja käytettävyyden parantaminen alentaa heidän mielestään loppukäyttäjille annettavan tuen määrää. Heidän mielestään sähköpostikyselyiden ja puhelujen määrä on suoraan kytköksissä tuotteen käytettävyyteen. Jos tuotetta on helppo käyttää, yhteydenottojen määrä vähenee ja näin saavutetaan taloudellista hyötyä. Pearrow (2000, s. 3) on sitä mieltä, että käytettävyyttä ei tarvitse viedä äärimmäisyyksiin. Jos pyritään äärimmäisyyteen, tuloksena voi olla esteettisesti epämiellyttävä sivusto. Hänen mielestä onkin syytä pyrkiä tasapainoon sivuston ulkoasun ja käytettävyyden kanssa. Nielsen (1993, s. 23) puolestaan esittää asian niin, että koneiden ei tarvitse olla ystävällisiä käyttäjille. Käyttäjät haluavat vain, että kone ei estä heidän työntekoaan. Tätä tutkielmaa on lähdetty tekemään seuraavien tutkimuskysymysten pohjalta: mitä eri käytettävyystestausmenetelmiä kirjallisuudessa esitetään web-sivustoiden testaamiseen? Mitkä ovat eri testausmenetelmien hyvät ja huonot puolet? Mitkä ovat eri testausmenetelmien tyypillisimmät piirteet? Pystytäänkö eri menetelmien avulla antamaan suuntaviivoja sivustojen kehittämiseen ja millaisia nämä suuntaviivat ovat? Tutkielma pohjautuu useisiin aiheista tehtyihin teoksiin ja tutkimuksiin. Aineistona on käytetty eri tietokannoista löydettyjä artikkeleita, perinteistä kirjallisuutta sekä wwwlähteitä. Aineiston haussa on käytetty Google scholar hakupalvelua. Tietokannat, joista aineistoa kerättiin olivat ACM, College & Research Libraries ja Springerlink. Aineistoa on haettu tietojenkäsittelytieteiden aihealueelta. Tutkielmassa esitetään kirjallisuudessa kerrottuja erilaisia keinoja käytettävyystestausprosessin luontiin ja eri menetelmiä verrataan hieman myös toisiinsa, mutta tarkoituksena ei ole selvittää, mikä menetelmistä on paras vaan yleisesti esitellä eri menetelmiä. Tarkastelun kohteeksi on otettu laboratoriossa tehtävä käytettävyystestaus, etänä tapahtuva testaus sekä heuristinen evaluointi. Luvussa 2 käydään läpi laboratoriossa tapahtuvaa testausta. Luku 3 puolestaan keskittyy etänä tehtävään testaukseen. Luvussa 4 kerrotaan tarkemmin heuristisesta evaluoinnista ja miten se soveltuu web-käytettävyyteen. Luku 5 on yhteenveto, jossa tarkastellaan tutkielmaa kokonaisuudessaan. Luku 6 on pohdinta osuus, jossa tarkastelen kirjallisuuden tämän hetkistä tilaa ja tarkastellaan onko tutkimuskentässä nähtävissä selkeää aukkoa, joka kaipaisi jatkotutkimusta. 5

6 6 2. Laboratoriotestaus Käytettävyystestauksen tekeminen laboratoriossa on yksi perinteisimmistä testausmuodoista. Se onkin ollut käytössä jo useampia vuosia. Laboratoriotestien tehokkuus löytää ongelmia web-järjestelmistä on näin ollen yleisesti hyväksytty. (Tullis, Fleischman, McNulty, Cianchette & Bergel, 2002.) Laboratoriotestien teko websivustoille ja web-järjestelmille voi antaa sivustojen ja järjestelmien kehittäjille erilaisia vaihtoehtoja käytettävyyden suunnitteluun ja herättää uusia kysymyksiä. (Kantner & Rosenbaum, 1997). Isoilla organisaatioilla onkin usein hyvin varustetut käytettävyyslaboratoriot, joissa työskentelee monia käytettävyyden ammattilaisia. Laboratoriot voivat kuitenkin olla kalliita rakentaa ja varustaa. (Levi & Conrad, 1997.) Yleensä laboratoriot koostuvat kahdesta erillisestä huoneesta. Huoneet erotetaan lasilla, joka estää testaajaa näkemästä tarkkailutilaan. Testitila koostuu tietokoneesta ja lukuisista kameroista sekä mikrofoneista, joiden avulla voidaan tallentaa testaajan liikkeet ja muut toimet. (Hallahan, 2001.) Laboratoriotestauksen arvo piilee sen objektiivisuudessa, mikä tuodaan arviointiprosessiin (Hallahan, 2001). 2.1 Testityypit Rubin (1994, s. 30) esittää käytettävyystesteille neljää erilaista testityyppiä. Tutkivaa testausta tehdään tuotteen kehityskaaren aikaisessa vaiheessa. Käyttäjäryhmät ja tehtävät ovat kuitenkin jo määritetty. Tutkivassa testauksessa testataan suunnittelukonseptien tehokkuutta. Tässä vaiheessa tutkijan ja testaajan välinen kommunikaatio on yleensä runsasta. Seuraava testityyppi minkä Rubin (1994, s. 37) esittää on arvioiva testaus. Arvioivaa testausta pidetään kenties kaikkein tyypillisimpänä testausmuotona. Arvioivassa testauksessa tarkoituksena on, että testaaja tekee testattavalla järjestelmällä tiettyjä tehtäviä. Tässä testaustyypissä pyritään saamaan selville, miten hyvin käyttäjä selviää realistisista tehtävistä ja löytämään puutteita käytettävyydestä. Kolmas testityyppi on vahvistava testaus. (Rubin, 1994, s. 38) Vahvistavaa testausta käytetään yleensä tuotteen kehityskaaren loppuvaiheessa. Tässä testityypissä pyritään saamaan selville täyttääkö tuote asetetut tavoitteet ja miten kokonaisuus toimii eli miten dokumentointi, ohjelmisto ja rauta on integroitu yhteen. Viimeinen eli neljäs testityyppi on vertaileva testaus. (Rubin, 1994, s. 40) Vertailevaa testausta ei ole kiinnitetty mihinkään kehityskaaren vaiheeseen. Vertailevassa testauksessa voidaan verrata esimerkiksi eri käyttöliittymätyyppejä ja tutkia millä olisi suurin potentiaali toimia kohderyhmälle. Vertailevassa testauksessa voidaan tuotetta verrata myös kilpailijoiden tuotteeseen. 2.2 Testauksen tavoitteet ja huolenaiheet Web-sivustoja ja web-järjestelmiä käyttää kirjava käyttäjäkunta, joten kaikkien käyttäjäryhmien kannalta ei käytettävyystestausta voida suorittaa. Ennen testien aloittamista onkin syytä asettaa tavoitteet ja huolenaiheet testeille. Tavoitteiden ja

7 huolenaiheiden asettaminen tekee testien suunnittelusta huomattavasti helpompaa. (Dumas & Redish, 1999, s. 110.) Dumas ja Redish (1999, s. 110) ovat sitä mieltä, että tavoitteet voidaan asettaa yksinkertaisesti lauseilla. He antavat esimerkkitavoitteeksi lauseen käyttäjät pystyvät valitsemaan oikean kuvakkeen alle 30 sekunnissa eivätkä he tee enempää kuin yhden virheen. Huolenaiheet pystytään puolestaan ilmoittamaan kysymyksillä. Esimerkiksi pystyykö käyttäjä valitsemaan oikean näppäimen nopeasti ja tarkasti. (Dumas & Redish, 1999, s. 110.) Testaajien määrä ja rekrytointi Testaajien määrästä on keskusteltu jo pitkään. Mikä on sopiva testaajien määrä? Yleisesti on uskottu, että jopa 80% käytettävyyteen liittyvistä ongelmista löydetään jo viidellä testaajalla. Kuitenkin viimeaikaisissa tutkimuksissa on havaittu, että websivujen käytettävyyttä testattaessa tarvitaan enemmän testaajia ja samaa tuotetta testaavat itsenäiset tiimit eivät saakaan samoja tuloksia. (Barnum, Bevan, Cockton, Nielsen, Spool, Wixon, 2003.) Barnum ja muut (2003) ovat käyneet asiasta paneelikeskustelua. Nielsenin mielestä oikea määrä on 3-4 testaajaa, sillä hän on ajattelut asian niin, että viidestä käyttäjästä yksi tai kaksi ei saavukaan testeihin. Eli kun hän puhuu viidestä testistä hän tarkoittaakin kolmea tai neljää. Cocktonin mielestä viisi testaajaa web-testauksessa on riittävä joissain tilanteissa. Hänen mielestään asia on niin, että viiden testin jälkeen uusia virheitä ei löydy ellei ne ole virheitä, jotka löytyvät helposti. Hänen mielestään useammalla testaajalla ongelmien profiili ja taajuus muuttuvat. Barnumin mielestä viisi testaajaa on tarpeeksi, jos alkuperäistä mallia seurataan ja tulokset ymmärretään selkeästi. Wixonin mielestä taas koko testaajien määrän miettiminen on täysin väärä ongelma mietittäväksi vaan pitäisi keskittyä muihin seikkoihin. Spoolin näkemys asiasta on, että suunnittelijoilla on rajallinen määrä aikaa ja resursseja, joten yksikin testaaja tulee olemaan aina parempi kuin ei yhtään. Schroeder ja Spool (2001) tekivät käyttäjätestit neljälle eri web-sivustolle ja huomasivat, että jokainen neljästä sivustosta tarvitsi enemmän kuin viisi testaajaa, jotta yli 85 % virheistä löydettiin. Viidellä testaajalla he löysivät vain keskimäärin 35% virheistä. He ovatkin sitä mieltä, että viisi testaajaa ei ole tarpeeksi web-sivujen testaukseen. Bruun, Gull, Hofmeister ja Stage (2009) käyttivät laboratoriossa tehdyissä käytettävyystesteissä peräti neljääkymmentä eri testaajaa. Brantley, Armstrong, Lewis (2006) on sitä mieltä, että viidellä testaajalla löydetään 80% virheistä ja kahdeksalla testaajalla 90% virheistä. Kaikki virheet eli 100% virheistä löydetään heidän mielestään viidellätoista testaajalla. Dumas ja Redish (1999, s. 136) esittävät kaksi ongelmaa liittyen testaajien valintaan. Ensimmäinen ongelma on, jos testihenkilöt ovat paljon kokeneempia kuin todelliset loppukäyttäjät tulevat olemaan. Näin syntyy valheellinen kuva tuotteesta. Toinen ongelma on, jos testaajilla ei ole niin paljon kokemusta kuin loppukäyttäjillä. Silloin saattaa löytyä enemmän ongelmia kuin on tarvetta. Dumasin ja Redishin mielestä näistä ongelmista ensimmäinen on yleisempi. Laboratoriotestaus voi epäonnistua, jos ei löydetä tarpeellista määrää varteenotettavia testaajia (Baravalle & Lanfranchi, 2003). Tullis ja muut (2002) rekrytoivat omiin käytettävyystesteihinsä testaajat heidän omasta organisaatiosta sisäisen puhelimen kautta. Dumas ja Redish (1999, s. 137) ovat asiasta sitä mieltä, että mikäli tuote on pääasiassa sisäiseen käyttöön, voivat käyttäjät silloin olla saman organisaation työntekijöitä. Bruun kumppaneineen (2009) rekrytoivat

8 käytettävyystesteihinsä sekä miehiä että naisia. Puolilla heistä oli tekninen koulutus ja toisella puoliskolla ei ollut minkäänlaista teknistä koulutusta. Lisäksi testaajilla ei ollut aiempaa tietoa käytettävyystestauksesta Testien kesto, tehtävät ja testaajien palkitseminen Tullis ja muut (2002) pitivät yhden testin pituutena puoltatoista tuntia. He tekivät käytettävyystestejä kahtena peräkkäisenä päivänä. Isoille järjestelmille käytettävyystestejä voidaan tehdä monena päivänä peräkkäin jopa viikkojen ajan. (Dumas & Redish, 1999, s. 101.) Bruun kumppaneineen (2009) tekivät käytettävyystestejä, joiden pituus oli yksi tunti. Tunti sisälsi järjestelmän testaamisen lisäksi myös alku- ja loppuhaastattelun sekä testaajan vaihdon. Myös Brantley kumppaneineen (2006) pitivät testien pituutena yhtä tuntia. He tekivät käytettävyystestejä kahden viikon ajan. Laboratoriotesteissä ei voida testata jokaista järjestelmän tai sivuston toiminnallisuutta, koska se olisi erittäin paljon aikaa vievää toimintaa. Niinpä onkin hyvä tehdä testaajille valmiita tehtäviä. Tehtävien on hyvä olla sellaisia, jotka löytäisivät järjestelmästä tai sivustolta käytettävyysongelmia. (Dumas & Redish, 1999, s. 160.) Tehtävät annetaan käyttäjälle yleensä paperilla, josta testaaja voi lukea tehtävänannon rauhassa (Tullis ja muut, 2002). Myös vieressä istuva tutkija voi lukea tehtävänannon testaajalle (Brantley kumppaneineen, 2006). Baravalle ja Lanfranchi (2003) ovat sitä mieltä, että tehtävien avulla pystytään kontrolloimaan käyttäjän tekemisiä paremmin. Käyttäjät on hyvä palkita jotenkin heidän panoksestaan käytettävyystesteissä. Yleensä palkinnot ovat jotain pieniä lahjoja. Tullis ja muut (2002) antoivat käytettävyystesteihin osallistuneille henkilöille elokuvaliput. Bruun kumppaneineen (2009) puolestaan antoi heidän käytettävyystesteihin osallistuneille testaajille viiniä. Tutkijat voivat käyttää myös pieniä summia rahaa palkkiona osallistumisesta käytettävyystesteihin (McGillis & Toms, 2001). 2.5 Laboratorioasetelma Kuten aiemmin kävi jo ilmi, laboratoriotestauksessa käytetään monia eri välineitä havaitsemaan käyttäjän toimet. Käytettävyyslaboratorio sisältää yleensä monia kameroita. Kamerat olisi hyvä sijoittaa niin, että ne vetävät mahdollisimman vähän huomiota itseensä, sillä ne voivat vaikuttaa testaajan toimiin. (Pearrow, 2000, s. 213). Laboratorioissa käytetään myös monia mikrofoneja, jotta kaikki kommunikointi testaajan ja tutkijoiden välillä tallentuu ja testaajan ääneen ajattelu tallentuu. (Pearrow, 2000, s. 209). 2.6 Laboratoriotestauksen edut ja heikkoudet Kanterin ja Rosenbaumin (1997) mielestä laboratoriotestaus on hyödyllistä silloin, jos täytyy tehdä selkeitä päätöksiä suunnittelun suhteen. Heidän mielestään laboratoriotestit keräävät määrällistä ja mitattavaa dataa, joten testit rakentavat uskottavuutta käytettävyystutkimuksille. Lisäksi he kertovat, että erityisesti yritysjohtajat pitävät laboratoriotesteistä saatavaa mitattavaa dataa rauhoittavana.

9 Laboratoriotesteillä on myös psykologinen vaikutus. Yleensä oikean loppukäyttäjän kohtaamat ongelmat sivustoa käytettäessä on vakuuttavampia kuin esimerkiksi käytettävyysasiantuntijan mielipiteet. (Kanter & Rosenbaum, 1997.) Kanter ja Rosenbaum (1997) pitävät laboratoriotestauksen heikkoutena sitä, että websivustoja katsotaan enemmän ja nopeammin kuin tavallisia sovelluksia. Vaikka käytettävyyttä pystytään nopeammin muuttamaan niin motivaatio testeille voi olla kuitenkin alhaisempi, koska sivustoja muutetaan nopeassa tahdissa. Vaikka laboratoriossa tehtävät käytettävyystestit pidettäisiin pienimuotoisina niin ne vaativat kuitenkin enemmän resursseja ja aikaa kuin esimerkiksi heuristinen evaluointi. Lisäksi lyhyellä aikavälillä on vaikeaa saada luotettavaa dataa. (Kantner & Rosenbaum, 1997.) Paperiprototyypit laboratoriossa Käytettävyyttä voidaan testata laboratorio-olosuhteissa myös käyttäen paperiprototyyppejä. Gradyn (2000) mielestä paperiprototyyppien käyttäminen on tehokasta, edullista ja niiden avulla voidaan säästää aikaa. Grady (2000) muistuttaa, että nykyään sivuja ei testata ennen kuin ne ovat valmiina. Lisäksi paperiprototyyppien etuna on, että niitä voidaan käyttää lähes missä tahansa. Testaajan on helpompi arvostella paperiprototyyppiä kuin valmista sivua. Paperiprototyyppien käyttäminen ei vaadi suuria teknisiä taitoja. (Grady, 2000.) Gradyn (2000) tehdessä käytettävyystestejä paperiprototyypeillä opastettiin testaajia ajattelemaan, että sormi on hiiri, jolla voi klikata mitä tahansa haluamaansa kohtaa. Lisäksi klikatessa täytyi kertoa, mitä oletti seuraavaksi tapahtuvan. Grady (2000) kertoo, että testien jälkeen paperiprototyyppejä on helppo muuttaa. Lisäksi hän muistuttaa, että suunnittelijat eivät puolusta omia näkemyksiään niin helposti ja testaajat uskaltavat kritisoida tehtyjä ratkaisuja paremmin, joten tilanne on eduksi molemmille osapuolille.

10 10 3. Etänä tapahtuva testaus Laboratoriotestaus ei ole ainoa vaihtoehto tehdä käytettävyystestausta. Etenkin webjärjestelmiä testattaessa on kehitetty uusia testausmuotoja. Yksi syy uusien testausmuotojen kehittämiseen on perinteisen laboratoriotestauksen kalleus. Sekä itse testitilat, että henkilöstö, saattavat maksaa erittäin paljon. Toinen syy uusien testausmuotojen kehittämiseen liittyy testaajiin. Laboratoriotestauksessa ei voida käyttää kovinkaan montaa testaajaa, koska kustannukset nousevat ja testaamiseen käytettävä aika on rajallinen. Etänä tehtävä testaus mahdollistaa siis useampien testaajien käyttämisen. Lisäksi käyttäjät voivat suorittaa testit missä tahansa, kunhan heillä on vain pääsy web-sivustolle. (Tullis ja muut, 2002.) Baravellen ja Lanfranchin (2003) mielestä etänä tehtävä käytettävyystestaus antaa tutkijoille mahdollisuuden evaluoida web-sivustojen käytettävyyttä etäkäyttäjien avulla. Monissa etänä tehtävissä käytettävyystestauksissa käyttäjä joutuu kuitenkin asentamaan jonkin erillisen sovelluksen koneelleen. Heidän mielestään suurin etu etänä tehtävällä käytettävyystestauksella on suurempi testaajien määrä ja pienemmät kustannukset yhtä testaajaa kohden. He kuitenkin muistuttavat, että etänä tehtävän käytettävyystestauksen tehokkuudesta väitellään edelleen, sillä etänä tehtävien testien ongelmana on pidetty tutkijoiden ja testaajien välistä kommunikaation puutetta. Bruun kumppaneineen, (2009) jakavat etänä tapahtuvan testauksen kahteen eri kategoriaan: synkroniseen ja asynkroniseen. Synkronisella metodilla he tarkoittavat, että testaaja ja tutkijat voivat olla fyysisesti eri paikoissa, mutta heidän täytyy olla ajallisesti läsnä yhtä aikaa. Testaajien toimet voidaan lähettää esimerkiksi videoyhteyksillä fyysisesti täysin eri paikkaan, mutta tämä vaatii tutkijoiden reaaliaikaisen läsnäolon, jotta he voivat kontrolloida testiä. Synkroninen metodi vaatii kuitenkin lähes yhtä paljon resursseja kuin perinteinen laboratoriotestaus. Asynkronisella metodilla Bruun kumppaneineen (2009) tarkoittavat metodia, jossa testaajat ja tutkijat voivat olla sekä fyysisesti että ajallisesti erillään. Testaajien ei siis tarvitse olla reaaliaikaisesti läsnä, kun testaajat työskentelevät järjestelmän kanssa. 3.1 Testaajat Yksi suuri ero etänä tapahtuvassa testauksessa perinteiseen laboratoriotestaukseen on suurempi testaajien määrä. Tullis ja muut (2002) suorittivat etänä kaksi eri käytettävyystestiä. Ensimmäisessä testissä he testasivat web-järjestelmää, jonka kautta organisaation työntekijöillä oli mahdollisuus tarkastella omia etujaan, palkkojaan, eläkkeitään ja muita henkilökohtaisia tietojaan. Testeihin he rekrytoivat työntekijöitä omasta firmastaan. Rekrytointi tapahtui täysin sattumanvaraisesti sähköpostia käyttäen. Käytettävyystestiin päätti osallistua 38 testaajaa, joista 29 suoritti testit loppuun saakka. Toisessa käytettävyystestauksessa Tullis ja muut (2002) testauttivat testaajillaan websivuston prototyyppiä. Tähän käytettävyystestiin osallistui kaiken kaikkiaan 108 testaajaa, joista 88 suoritti testin loppuun saakka.

11 Eri lähestymistavat ja OpenWebSurvey Baravalle ja Lanfranchi (2003) esittää kolme lähestymistapaa koskien etänä tehtävää käytettävyystestausta. Ne ovat web-selain, web-sivusto ja proxy. Web-selain lähestymistapa tarkoittaa, että käyttäjä joutuu käyttämään testaukseen erikoisvalmisteista ohjelmistoa selatakseen web-sivustoa. Erikoisvalmisteinen ohjelmisto on yleensä erikoisselain. Tämän lähestymistavan heikkous on kuitenkin se, että käyttäjä joutuu asentamaan itse ohjelmiston, mikä vie aikaa ja voi olla kokemattomille testaajille vaikeaa. Web-sivusto -lähestymistavassa ajatuksena on, että sivustolle asennetaan sovellus, jonka tarkoituksena on monitoroida käyttäjän tekemisiä. Tämä kuitenkin tarkoittaa, että testauksen järjestäjillä pitäisi olla täysi pääsy web-sivuston lähdekoodiin, mikä monesti muodostuu ongelmaksi, sillä harva kehittäjä päästää tutkijoita muokkaamaan websivustoaan. (Baravalle & Lanfranchi, 2003.) Proxy -lähestymistapa perustuu asiakkaan ja palvelimen välissä olevaan sovellukseen, mikä monitoroi käyttäjän navigointia. Tämän lähestymistavan suurin etu on, että tutkijoiden ei tarvitse muokata sivustoa ja päästä näin käsiksi sivuston lähdekoodiin. Lisäksi käyttäjän ei tarvitse asentaa itse mitään erillistä sovellusta. Baravalle ja Lanfranchi (2003) kehittivät proxyyn perustuvan järjestelmän, joka mahdollistaa datan tallennuksen, varastoinnin, jaon sekä prosessoinnin. Sen nimeksi tuli OpenWebSurvey. OpenWebSurveyn hyödyllisyys tulee parhaiten esiin tehtäessä kyselyitä, joissa testaajan pitää etsiä esimerkiksi tekstiä web-sivustolta. Järjestelmän avulla on mahdollisuus tutkia käyttäjän löytämä vastaus sekä vastauksen löytymiseen käytetty tapa. Järjestelmä tallentaa dataa testaukseen osallistuvan etäkäyttäjän ympäristöstä ja käytettävän järjestelmän ominaisuuksista. Se tallentaa mm. web-selaimen nimen ja version, käyttöjärjestelmän tiedot ja käytettävän kielen. Lisäksi se tallentaa käyttäjän tekemät hiiren liikkeet ja painallukset. OpenWebSurvey toimii kuten tavallinen välityspalvelin web-palvelimen ja asiakkaan välissä. Järjestelmä pyytää webpalvelimelta web-sivun, jonka jälkeen järjestelmä muokkaa sivua ja lähettää sen takaisin asiakkaalle kuvan 1 mukaisesti. (Baravalle & Lanfranchi, 2003.) Kuva 1. OpenWebSurvey:n toiminta mukaillen Baravallen ja Lanfranchin alkuperäistä kuvaa. (Baravalle & Lanfranchi, 2003). Testin alussa järjestelmä antaa testaajalle uniikin koodin ja tallentaa yleistä dataa käyttäjän ympäristöstä kuten käytetyn selaimen nimen ja version sekä käyttöjärjestelmän. Seuraava tapahtuma on yhteydenotto web-palvelimelle ja web-sivun haku. Tämän jälkeen linkit kirjoitetaan uudelleen. Viimeisessä vaiheessa käyttäjälle tarjotaan sivu, jonka linkit on muokattu osoittamaan OpenWebSurvey palvelimelle uusia sivupyyntöjä varten. Mikä tahansa käyttäjän seuraama linkki kulkee OpenWebSurveyn kautta. Kaikki linkit siis automaattisesti uudelleen kirjoitetaan, jotta käyttäjä voi jatkaa proxyn käyttöä. (Baravalle & Lanfranchi, 2003.)

12 User-reported Critical Incident User-reported Critical Incident eli UCI on yksi etänä tapahtuvan testauksen testausmuodoista. UCI:n pääasiallinen voima on itse testaajissa. Testausmuodon idea on, että testaajat raportoivat itse löytämistään käytettävyysongelmista. Tämän pitäisi vapauttaa tutkijat testien järjestämisestä ja tulosten raportoinnista. On huomattu, että testaajat kykenevät ilmoittamaan kohtaamistaan ongelmista. (Bruun kumppaneineen, 2009.) Jäsentämätön ongelmien raportointi perustuu ideaan, jossa testaajat tekevät muistiinpanoja tehtävien teon aikana ilmenneistä ongelmista. Tutkimuksissa on käynyt ilmi, että testaajat pystyvät löytämään noin 66% ongelmista, jotka käytettävyysasiantuntijat löytävät. (Bruun kumppaneineen, 2009.) Bruun kumppaneineen (2009) teettivät käytettävyystestit sähköpostijärjestelmälle, jossa testaajille annettiin yhdeksän tehtävää. Aluksi he suorittivat käytettävyystestit perinteisesti laboratoriossa, jotta he saisivat vertailukohdan testeilleen. He käyttivät menetelmää, jossa he ohjeistivat testaajia ilmoittamaan sekä isoista että pienistä käytettävyysongelmista välittömästi. Tämä tapahtui web-sivustolla olevan lomakkeen avulla. Lomakkeella heiltä kysyttiin seuraavia asioita: Mitä tehtävää he olivat suorittamassa ongelman ilmetessä. Mikä on ikkunan nimi, jossa kyseinen ongelma sijaitsee. Mitä he olivat tekemässä kun ongelma ilmeni. Kuvailemaan mitä he odottivat järjestelmän tekevän juuri ennen kuin kyseinen ongelma ilmeni. Mahdollisimman yksityiskohtaisesti kuvailemaan ongelmaa ja miksi he luulevat sen tapahtuneen. Kuvailemaan mitä he tekivät päästäkseen pois kyseisestä ongelmasta. Olivatko he kykeneviä palautumaan kyseisestä ongelmasta. Tekivätkö he lisää virheitä ja tapahtuivatko samat virheet uudestaan. Kertomaan ongelman vakavuuden. Testaajia pyydettiin myös ottamaan talteen tehtäviin käytetty aika ja lähettämään se tutkijoille. Bruun kumppaneineen (2009) kuitenkin huomasivat testit analysoituaan, että perinteisellä laboratoriotestauksella löydettiin enemmän käytettävyysongelmia. 3.4 Foorumit Testaajat käyttävät erilaisia foorumeita keskustellakseen käytettävyysongelmista. Tutkijat eivät kuitenkaan erityisemmin kannusta testaajia raportoimaan käytettävyysongelmia foorumeille. Testaajat kuitenkin lähettävät yksityiskohtaista palautetta käytettävyyteen liittyen. (Bruun ja muut, 2009.) Bruun ja muut (2009) käyttivät foorumia testatessaan samaista sähköpostijärjestelmää, johon he käyttivät UCI-menetelmää. Aluksi testaajia pyydettiin asentamaan kyseinen

13 järjestelmä, jonka jälkeen heitä pyydettiin ottamaan muistiinpanoja mahdollisesti esiintyvistä käytettävyysongelmista ja niiden vakavuudesta sekä tallentamaan tehtäviin kulunut aika. Tehtävien suorittamisen jälkeen testaajien piti poistaa sovellus, jotta pitkäaikaista järjestelmän käyttöä ei tulisi. Kun tehtävät oli suoritettu, testaajia pyydettiin lähettämään löytyneet käytettävyysongelmat muiden testaajien nähtäväksi foorumille. Jos kyseinen käytettävyysongelma oli jo lähetetty foorumille jonkun muun testaajan toimesta, heitä pyydettiin kommentoimaan sitä. Foorumi menetelmän avulla ei löydetty kuitenkaan niin paljon käytettävyysongelmia kuin perinteisellä laboratoriotestauksella Päiväkirjat Bruun kumppaneineen (2009) esittelevät tutkimuksessaan myös päiväkirjojen käytön etänä tehtävässä käytettävyystestauksessa. Päiväkirjoja käytetään yleensä pitkäaikaiseen testaamiseen. Tämän menetelmän käytöstä on vähän tietoa ja sen hyödyllisyydestäkään ei ole kovin paljoa tietoa. Bruun kumppaneineen (2009) käyttivät menetelmää niin, että he antoivat testaajille viisi päivää aikaa kirjoittaa havaintoja ja niiden vakavuuksia päiväkirjaan sekä tehtäviin kulunut aika. Ensimmäisenä päivänä kaikille testaajille annettiin samat yhdeksän tehtävää. Heitä pyydettiin suorittamaan nämä tehtävät välittömästi ensimmäisen päivän aikana ja lähettämään ne tutkijoille. Seuraavina päivinä testaajille lähetettiin lisätehtäviä, jotka pyydettiin suorittamaan kyseisen päivän aikana. Lisätehtävät olivat alkuperäisten tehtävien kaltaisia. Koko menetelmän tarkoituksena oli saada aikaan pitkäaikainen käyttö järjestelmän parissa ja, että käyttäjät tekisivät päiväkirjaan merkintöjä päivittäin. Päiväkirjamenetelmän avulla ei myöskään löydetty niin paljon käytettävyysongelmia kuin laboratoriotestauksella.

14 14 4. Heuristinen evaluointi Web-sivustoille voidaan tehdä myös heuristista evaluointia. Heuristinen evaluointi on metodi, jossa yleensä pieni ryhmä käytettävyysalan asiantuntijoita tutkivat käyttöliittymää ja etsivät siitä virheitä, jotka rikkovat hyvän käytettävyyden periaatteita. Borges, Morales ja Rodriguez (1996) ovat sitä mieltä, että heuristinen evaluointi on hyväksi, sillä huono käytettävyys lisää turhaa liikennettä internetissä, heikentää tiedon etsimistä ja tuhlaa käyttäjän aikaa. (Dumas & Redish, 1999, s. 65.) Sutcliffe (2002) esittää artikkelissaan kaksi erilaista lähestymistapaa web-sivustoille tehtävään heuristiseen evaluointiin. Ensimmäisessä lähestymistavassa käyttäjiä tarkkaillaan heidän käyttäessä sivustoa. Toisessa lähestymistavassa asiantuntijat vertaavat käytettävyyttä yleisiin heuristiikkoihin. Matera kumppaneineen (2006) kertovat, että yleensä asiantuntijat käyvät järjestelmän lävitse ainakin kahdesti. Heidän mielestään ensimmäisellä kerralla järjestelmä silmäillään lävitse ja otetaan siihen tuntumaa. Toisella kerralla keskitytään yksityiskohtaisemmin ongelmiin ja verrataan suunnittelua heuristiikkoihin. Pohjana heuristiselle evaluoinnille käytetään monesti Nielsenin ja Molichin (1990) heuristiikkoja. Seuraavat heuristiikat ovat suomennoksia Nielsenin ja Molichin (1990) alkuperäisistä: 1. Helppo ja luonnollinen dialogi. 2. Käytä käyttäjän kieltä. 3. Minimoi käyttäjän muistikuorma. 4. Ole johdonmukainen. 5. Tarjoa palautetta. 6. Tarjoa selkeästi merkityt poistumiset. 7. Tarjoa oikopolkuja. 8. Käytä hyviä virheilmoituksia. 9. Ehkäise virheitä. Heuristisen evaluoinnin tekoon web-sivustoille käytettävyysasiantuntijalla täytyy olla tiedossa tiettyä taustainformaatiota. Arvioijan pitää tietää sivuston tai järjestelmän tarkoitus, mahdollisten käyttäjien profiilit sekä tyypillisimmät skenaariot käyttäjille, jotka käyvät sivustolla. Nämä tiedot ovat tärkeitä mitä tahansa tuotetta testattaessa, mutta niiden tärkeys korostuu etenkin web-sivustoja testattaessa. (Kantner & Rosenbaum, 1997.) Kantner ja Rosenbaum (1997) ovat sitä mieltä, että kahden tai useamman asiantuntijan tekemät heuristiset evaluoinnit voivat löytää suuren osan käytettävyysongelmista sivustolla. Heidän mielestään kaksi evaluoijaa löytävät noin 50% ongelmista ja kolme evaluoijaa noin 60% ongelmista. Tarvitaan kuitenkin entistä enemmän evaluoijia, mitä suuremmille prosenttiluvuille mennään, sillä 90% ongelmista löydetään vasta viidellätoista evaluoijalla. Useampi evaluoija löytää toki enemmän ongelmia, mutta he

15 myös pystyvät paremmin osoittamaan niiden vakavuuden. Useamman evaluoijan käyttäminen vaatii kuitenkin enemmän resursseja ja vie enemmän aikaa Heuristisen evaluoinnin vahvuudet Kantner ja Rosenbaum (1997) kertovat muutamia syitä, joiden vuoksi heuristinen evaluointi on kannattavaa web-sivustoille. Heidän mielestään heuristinen evaluointi on arvokasta silloin, jos aikaa on vähän ja resurssit ovat alhaiset. Parhaimmat evaluoijat pystyvät tuottamaan lyhyessäkin ajassa korkeatasoista jälkeä. Heuristisella evaluoinnilla voidaan löytää monia parannuksia käytettävyyteen ennen tuotteen julkaisua. Kantnerin ja Rosenbaumin (1997) mielestä heuristinen evaluointi on kannattavaa etenkin, jos kehitystiimi on avoin uusille ideoille. Kantnerin ja Rosenbaumin (1997) mielestä heuristinen evaluointi kasvattaa myös laboratoriotestauksen arvoa. Heuristisen evaluoinnin avulla voidaan poistaa kaikista selkeimmät ongelmat ja laboratoriotestauksessa voidaan keskittyä vaikeammin löydettäviin ongelmiin. Heidän mielestään ilman heuristista evaluointia laboratoriotestaukseen osallistuvat testaajat saattavat kuluttaa ajan samaan selkeään käytettävyysongelmaan ja muita tärkeitä ongelmia jää löytämättä. 4.2 Heuristisen evaluoinnin heikkoudet Heuristisella evaluoinnilla on myös heikkoutensa. Heuristisen evaluoinnin heikkous on, että evaluoijat eivät yleensä ole evaluoinnin kohteena olevan web-sivuston tyypillisimpiä käyttäjiä vaan yrittävät jäljitellä käyttäjiä. (Kantner & Rosenbaum, 1997.) Kantnerin ja Rosenbaumin (1997) mielestä todelliset käyttäjät monesti yllättävät tutkijat. Käyttäjillä saattaa ilmetä ongelmia, joita kehittäjät eivät oleta esiintyvän ja he saattavat selvitä helposti tilanteista, joissa oletetaan syntyvän ongelmia. Toinen heikkous on, että evaluointi ei löydä kaikkia pääkäyttäjäryhmiä ja näin ollen voi jäädä selvittämättä, mihin ongelmaan törmätään kaikista eniten. Lisäksi Kantner ja Rosenbaum (1997) muistuttavat, että evaluoinnin taso riippuu täysin evaluoijan kokemuksesta ja osaamisesta. Usein uusia web-sivuja luotaessa kehittäjillä on omat mielipiteensä sivuton ulkonäöstä. Evaluoinnin tekijöiden antamat parannusehdotukset voidaan kokea vain uusiksi mielipiteiksi, joten kehittäjät eivät välttämättä ota niitä tarpeeksi vakavasti. (Kantner & Rosenbaum, 1997.) 4.3 Evaluoinnin antamat suuntaviivat suunnittelulle Heuristisen evaluoinnin avulla on löydetty tiettyjä suuntaviivoja web-sivujen kehitykseen. Borges kumppaneineen (1996) tekivät heuristiset evaluoinnit kolmella evaluoijalla. Evaluointien kohteena olivat yliopistojen tietoarkistojen web-sivut. He valitsivat sattumanvaraisesti kymmenen sivua yli tuhannen sivun joukosta. Heuristisessa evaluoinnissa he löysivät kirjavan joukon käytettävyysongelmia ja näiden ongelmien perusteella he tekivät tiettyjä suuntaviivoja, joiden avulla web-sivustoista saataisiin käyttäjäystävällisempiä. Borges kumppaneineen (1996) antavat seuraavat suuntaviivat web-sivujen kehitykseen:

16 16 1. Otsikot eivät saisi olla yli 25% sivun kirjaisin koosta. 2. Ylä- ja alatunnisteet pitäisi erottua selvästi itse sivun rungosta. 3. Linkkien nimet pitäisi olla lyhyitä ja antaa vihje sivusta mihin ne osoittavat. 4. Pitäisi välttää lisäämästä selittäviä huomautuksia tekstimuodossa oleviin linkkeihin. 5. Pitäisi välttää linkkimaniaa. Eli tekemästä linkkiä aina kun avainsana mainitaan sivulla. 6. Täytyy varmistaa, että linkit osoittavat olemassa oleville sivuille. 7. Linkki-ikoneilla pitäisi olla erityispiirre sivusta, johon ne linkittyvät. 8. Ylläpidä samankaltaisuutta ikonien käytössä. Samaa ikonia pitäisi käyttää samaan tarkoitukseen. 9. Värit pitäisi valita niin, että sivut voidaan näyttää selkeästi. 10. Sivuille on suotavaa lisätä päivämäärä, jolloin sivua on viimeksi muokattu. Lisäksi voidaan lisätä sivua ylläpitävän henkilön sähköpostiosoite sekä alatunnisteeseen sivun URL-osoite. Pelkkien etusivujen luomiseen Borges ja muut (1996) antavat seuraavanlaisia suunnitteluohjeita. 1. Heti ylätunnisteen alle olisi hyvä laittaa tietoa laitoksesta ja pitää tiedon määrä minimissä. 2. Sivulla ei saisi olla liian paljon linkkejä. 3. Sivujen pitäisi olla lyhyitä. 4. Linkkien pitäisi ensisijaisesti olla pääsy tietoihin ja tekstimuotoinen tieto olisi hyvä sijoittaa muille sivuille. 5. Linkit olisi hyvä järjestellä tärkeyden mukaan. 6. Linkit tietoihin tai muihin arkistoihin olisi hyvä sijoittaa toiselle sivulle. 7. Laajempi ja hyvin koottu määrä linkkejä voidaan sijoittaa toiselle sivulle, jotta pääsy tietoihin nopeutuu. Borgesin ja kumppaneiden (1996) antamat suuntaviivat vaikuttavat selkeiltä ja niitä noudattamalla sivustosta saa varmasti selkeän. Ohjeet eivät välttämättä sovellu kaikkiin sivustoihin, koska sivustot ovat kaikki erilaisia. Esimerkiksi sivujen lyhyenä pitäminen voi tuottaa ongelmia, jos tietoa joudutaan laittamaan sivulle paljon. Silloin olisi hyvä miettiä miten tieto pystyttäisiin jakamaan järkevästi osiin. Heuristisen evaluoinnin avulla voidaan siis nopeasti ja resursseja säästämällä saada aikaan tietoja käytettävyysongelmista. Ongelmien löytämisen avulla voidaan tehdä tiettyjä suuntaviivoja sivujen luontia varten. Borgesin ja kumppaneiden (1996) mielestä tulevaisuudessa olisi kuitenkin syytä evaluoida laajempia määriä sivuja, jotta ohjeista saataisiin vielä tarkempia.

17 17 5. Yhteenveto Käytettävyyteen panostetaan nykyään enemmän ja käytettävyyden parantamiseksi tehdään koko ajan lisää tutkimuksia. Käytettävyys onkin yksi tärkeä ominaisuus miten kilpailijoista voidaan erottautua. Erityisesti webissä käytettävyyden asema korostuu ja käytettävyyden hyvällä suunnittelulla voidaan saada suuria etuja. Web-sivustot kyetään nykyään rakentamaan ja saamaan käyttäjien näkyville nopeasti. Käytettävyyden täytyy olla alusta alkaen hyvää, sillä webissä kilpailijoiden tarjoamat palvelut ovat vain muutaman hiiren painalluksen päässä. Huonolla käytettävyydellä voidaan menettää paljon käyttäjiä. Käytettävyyden tutkimiseen web-sivustoilla on kehitetty useita eri menetelmiä. Jos palaamme johdannossa esitettyihin alkuperäisiin tutkimuskysymyksiin, kirjallisuudesta löytyy ainakin kolme suurta käytettävyystestausmenetelmää, joiden avulla käytettävyyttä pyritään testaamaan. Laboratoriossa tehtävillä käytettävyystesteillä pyritään loppukäyttäjien avulla etsimään web-sivustoilla olevia käytettävyysongelmia. Loppukäyttäjät voivat testata myös paperiprototyyppejä, jolloin varsinaiseen lopputuotteeseen voidaan tehdä vielä muutoksia. Eri testaustyyppejä on neljä erilaista: tutkiva testaus, arvioiva testaus, vahvistava testaus ja vertaileva testaus. Laboratoriotestauksen eduiksi kirjallisuus esitti sen, että laboratoriotesteistä saatava informaatio on luotettavaa ja niiden avulla voidaan tehdä selkeitä päätöksiä suunnittelun suhteen. Haittoina puolestaan pidetään sitä, että laboratoriotestit vievät aikaa ja muita resursseja. Käytettävyyttä voidaan testata myös etänä tehtävällä testauksella. Tässä testausmenetelmässä tarkoituksena on, että havainnoijat ja testaajat ovat fyysisesti eri paikoissa ja havainnoijien ei tarvitse olla reaaliajassa seuraamassa testausta. Lisäksi testit voidaan suorittaa mihin vuorokauden aikaan tahansa. Etänä tehtävissä käytettävyystesteissä voidaan käyttää modifioituja selaimia, sekä erilaisia päiväkirjoja ja foorumeja. Kirjallisuudessa oli selkeästi nähtävissä, että etänä tapahtuvan testauksen etuna pidetään resurssien säästämistä. Lisäksi testaajien lukumäärä on suurempi kuin perinteisessä laboratoriotestauksessa. Huonona puolena puolestaan mainittiin testaajien ja tutkijoiden välisen kommunikaation puute. Heuristisessa evaluoinnissa tarkoituksena on käytettävyyden tutkiminen käytettävyysasiantuntijan toimesta. Asiantuntija käy läpi käyttöliittymää ja tutkii rikkooko jokin osa siinä jotain käytettävyysheuristiikkaa. Heuristiset evaluoinnit ovat nopea tapa saada testattua käytettävyyttä. Heuristisen evaluoinnin vahvuudet ovat resurssien säästämisessä ja evaluoinnin avulla voidaan löytää selkeät käytettävyysongelmat esimerkiksi ennen laboratoriotestejä. Haitoiksi puolestaan mainittiin, että evaluoija ei välttämättä kuulu testattavan sivuston tyypilliseen käyttäjäryhmään. Heuristisessa evaluoinnissa löydettyjen käytettävyysongelmien avulla on web-sivujen kehitykseen pystytty luomaan tiettyjä ohjeita ja suuntaviivoja. Käytettävyyttä voidaan siis tutkia monella eri keinolla ja tässä tutkielmassa niistä käytiin läpi kolme tunnetuinta. Käytettävyyden tutkiminen on kuitenkin tärkeää ja tulevaisuudessa sen tutkimiseen saatetaan kehittää uusia menetelmiä. Hallahankin (2001) on todennut, että ilman käytettävyystestausta on vaara tehdä pahoja suunnitteluvirheitä.

18 18 6. Pohdinta ja jatkotutkimusaiheet Tämän tutkielman tarkoituksena oli tutkia kirjallisuusselvityksen avulla eri käytettävyystutkimusmenetelmiä, kun testauksen kohteena ovat web-sivustot ja webjärjestelmät. Tutkielmassa keskityttiin kolmeen menetelmään, joita ovat laboratoriossa tehtävät käytettävyystestit, etänä tehtävä testaus sekä heuristinen evaluointi. Tutkimuksen teko osoitti, että aiheesta löytyi materiaalia kiitettävä määrä. Etenkin laboratoriossa tehtävästä testauksesta löytyi materiaalia helposti, mutta pelkästään websivujen testaukseen keskittyvää materiaalia oli vaikeampi löytää. Etänä tehtävästä testauksesta olisi voinut löytyä materiaalia enemmänkin. Tutkimuksen teko toi esille myös sen, että tutkimuksissa voitaisiin keskittyä enemmän etänä tehtävään testaukseen, sillä siinä on erittäin paljon potentiaalia nousta hyväksi käytettävyystestausmenetelmäksi. Esimerkiksi päiväkirjojen käytöstä testausmenetelmänä olisi mielenkiintoista saada lisää tietoa. On kuitenkin ymmärrettävää, että esimerkiksi päiväkirjojen käyttö on vähäistä, koska se vaatii aikaa ja yleensä web-sisältöjä luodaan nopeasti. Heuristisesta evaluoinnista löytyi myös tietoa, mutta siinäkin ongelmaksi muodostui, että materiaali keskittyi yleisesti heuristiseen evaluointiin ja web-sivujen evaluointiin keskittyvää materiaalia oli vaikeampi löytää. Heuristista evaluointia kuitenkin käytetään web-sisältöjen arviointiin, joten tulevaisuudessa tähän tutkimusalueeseen kyllä voisi keskittyä enemmänkin. Yleisesti tutkimuksen teko osoitti, että etänä tehtävässä testauksessa ja heuristisen evaluoinnin käytössä on nähtävissä pieni aukko tutkimuskentässä. Johdannossa kerroin kirjallisuudessa mainittuja etuja, joita voidaan saavuttaa eri käytettävyystestausmenetelmillä. Tutkimuksen perusteella voidaan todeta, että yhtiöiden olisi siis syytä panostaa käytettävyyteen entistä enemmän, sillä siitä olisi pelkästään hyötyä sekä käyttäjille että yhtiölle itselleen. Tutkielman perusteella voidaan myös kyseenalaistaa onko perinteinen laboratoriotestaus paras vaihtoehto testata web-sivustoja vai pystyykö jokin muu menetelmä tuomaan parempia tuloksia. Esimerkiksi Kanter ja Rosenbaum (1997) pitivät laboratoriotestauksen heikkoutena sitä, että se vie aikaa ja web-sivustoja kuitenkin täytyy muuttaa nopeassa tahdissa. Pystyttäisiinkö esimerkiksi etänä tapahtuvaa testausta käyttämään niin, että sivut julkaistaisiin ja foorumeita, päiväkirjoja sekä muita menetelmiä apuna käyttäen parannettaisiin käytettävyyttä tarvittaessa. Tässä voi suureksi ongelmaksi muodostua se, että käytettävyyden ollessa alunperinkin huono, ei käyttäjä usko sen välttämättä parantuvan jatkossakaan. Käytettävyys on kuitenkin mielenkiintoinen ja monimuotoinen tieteenala, johon ei ole vain yhtä näkökulmaa. Tulevaisuudessa tulen keskittymään johonkin käytettävyyteen liittyvään alueeseen tulevassa pro gradu -tutkielmassani.

19 19 Lähteet Baravalle, A., & Lanfranchi V. (2003). Remote web usability testing. Behavior research methods, instruments, & computers, 35(3), Barnum, C., Bevan, N., Cockton, G., Nielsen, J., Spool, J., & Wixon, D. (2003). The "Magic number 5": is it enough for web testing? In Proceedings of the 1st European UPA Conference on European Usability Professionals Association Conference, Borges, J. A., Morales, I., & Rodriguez, N. J. (1996). Guidelines for designing usable world wide web pages. In Proceedings of the Conference on Human Factors in Computing Systems, Volume 2, Brantley, S., Armstrong, A., & Lewis, K. (2006). Usability testing of a customizable library web portal. College & Research libraries, 67(2), Bruun, A., Gull, P., Hofmeister, L., Stage, J. (2009) Let your users do the testing: A comparison of three remote asynchronous usability testing methods. In Proceedings of the 27 th international conference on Human factors in computing systems (CHI 09) Dumas, J., & Redish, J. (1999). A practical guide to usability testing, Exeter, UK: Intellect books. Grady, M. (2000). Web site design: a case study in usability testing using paper prototypes. Proceedings of IEEE professional communication society international professional communication conference and Proceedings of the 18th annual ACM international conference on Computer documentation: technology & teamwork, Hallahan, K., (2001). Improving public relations web sites through usability research. Public relations review, 27, Kallepalli, C., & Tian, J. (2001). Measuring and Modeling Usage and Reliability for Statistical Web Testing, IEEE Transactions on Software Engineering, 27(11), Kantner, L., & Rosenbaum, S. (1997). Usability studies of www sites: heuristic evaluation vs. laboratory testing. Proceedings of the 15th annual international conference on Computer documentation, Levi, M., & Conrad, F. (1997). Usability Testing of World Wide Web Sites. Lainattu , saatavilla: ty+testing,+web+usability,+web-based+testing&hl=fi&as_sdt=2000

20 Matera, M., Rizzo, F., & Carughi G. (2006). Web Usability: Principles and Evaluation Methods. Web Engineering, McGillis, L., & Toms, E. (2001). Usability of the academic library web site: Implications for design. College & Research libraries, 62(4), Nielsen, J. (1993). Usability engineering, San Diego, CA, USA: Academic Press. Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), Pearrow, M. (2000). Web site usability handbook, Rockland, Massachusetts, USA: Charles river media, inc. Rubin, J. (1994). Handbook of usability testing: How to Plan, Design, and Conduct Effective Tests, New York, USA: John Wiley & Sons, Inc. Schroeder, W., & Spool, J. (2001). Testing web sites: five users in nowhere near enough, CHI 01 extended abstracts on Human factors in computing systems, Sutcliffe, A. (2002). Assessing the reliability of heuristic evaluation for website attractiveness and usability, In Proceedings HICSS-35 Hawaii International Conference on System Science, Tullis, T., Fleischman S., McNulty, M., Cianchette, C., & Bergel, M. (2002). An Empirical Comparison of Lab and Remote Usability Testing of Web Sites. Usability Professionals Association Conference.