T-121.110 Käyttäjäkeskeisentuotekehityksen harjoitustyö Osaston palautejärjestelmä Testiraportti ja käyttöliittymän korjaukset

T-121.110 Käyttäjäkeskeisentuotekehityksen harjoitustyö Osaston palautejärjestelmä Testiraportti ja käyttöliittymän korjaukset Ryhmän assistentti Johanna Viitanen Jekku, Tommi von Behr Vesa Luusua Matilda Smeds 51029S 57353N 57357T

Sisällysluettelo 1. Johdanto...1 2. Testien puitteet yleisesti...2 2.1. Testien järjestelyt...2 2.2. Tehtävät...3 2.2.1. Loppukyselyn tekeminen ja julkaisu...3 2.2.2. Jatkuvan avoimen palautteen luonti...3 2.2.3. Tulosten julkaisu...4 2.3. Haastattelu...4 2.4. Testien tallennus ja purku...4 2.5. Käyttöä vaikeuttaneet tekijät...4 2.5.1. Eläytymiskysymys...5 3. Pilottitesti...5 3.1. Pilottitestin valmistelut...5 3.1.1. Testin kulku...5 3.1.2. Ongelmia tehtävien suorittamisessa...6 3.1.2.1. Tee tästä tavallinen kysely -painike...6 3.1.2.2. Kyselyn ja kysymyksen muokkaustilojen yhteyden ymmärtäminen...6 3.1.2.3. Palaute tulosten julkaisusta...7 3.1.2.4. Ohjeet...7 3.2. Järjestelyihin liittyvät ongelmat...7 3.2.1. Osoittimen käyttö...7 3.2.2. Testitilanteen kesto...7 3.3. Paperiprototyyppiin ja testijärjestelyihin tehdyt muutokset...8 4. Varsinaiset testit...9 4.1. Tehtävien onnistuminen ja virheet...9 4.1.1. Virheiden luokittelu...9 4.1.2. Virheet ja niiden analyysi...9 4.1.2.1. Loppukyselyn tekeminen ja julkaisu...9 4.1.2.2. Jatkuvan avoimen palautteen luonti...10 4.1.2.3. Tulosten julkaisu...11 4.2. Haastattelun tulokset...11 4.2.1. Symbolitesti...11 4.2.2. Näkymien ja toimintojen kysely...11 4.3. Käytettävyyskriteerien toteutuminen...11 5. Havaitut käytettävyysongelmat...12 5.1. Testien perusteella...12 5.2. Heuristinen arviointi...13 6. Prototyypin kehittäminen...13 6.1. Tehdyt korjaukset...14 6.2. Mahdolliset ongelmakohdat...22 6.3. Arvio kokonaiskäytettävyydestä...23 6.4. Suositukset jatkotestaamiseen...23 7. Lähteet...25 8. Liitteet...26 8.1. Liite 1: symbolitesti...26 8.2. Liite 2: navigaatiokartta...27

1. Johdanto Tämä raportti on kolmas osasuoritus Käyttäjäkeskeisen tuotekehityksen harjoitustyö - kurssilla. Aiheenamme on osaston palautejärjestelmä, johon suunnittelemme opetushenkilökunnan käyttöön tulevaa osaa. Raportissa käymme ensin läpi testijärjestelyt, jonka jälkeen kerromme pilottitestistä ja siinä ilmenneistä ongelmista, sekä varsinaisissa testeissä ilmenneistä asioista. Käymme myös läpi käyttäjien tekemät virheet ja niiden pohjalta tehdyt muutokset käyttöliittymään - samoin heuristisen arvioinnissa esiin tulleet kohdat. Testeissä käytettiin edellisessä palautuksessa ollutta paperiprotoa, jota testasimme kolmella pääkäyttäjäryhmäämme kuuluvalla henkilöllä. Koska aiemmassa projektin vaiheessa haastattelimme luennoitsijoita ja kyselimme heidän mielipiteitään ja toiveitaan palautejärjestelmästä, päätimme tällä kertaa keskittyä pääassistentteihin. Valintaan vaikutti myös se, että uskoimme nuorempien olevan valmiimpia ja rennompia videolle kuvattavassa testitilanteessa. Tältä osin valintaa voikin pitää hyvänä, sillä testikäyttäjät suhtautuivat tilanteeseen vapautuneesti. Valitsemamme tila oli rauhallinen luokkahuone T-talon alakerrassa. Luokka sopi tarkoituksiimme loistavasti, koska sinne mahtui levittämään proton näkymiä erilliselle pöydälle nopeuttaen proton käsittelijän työtä ja myös videokameralle oli tilaa. Pidimme käyttäjätestit peräkkäisinä päivinä siten, että pilottitesti oli ennen varsinaista testauspäivää. Tämä antoi mahdollisuuden hioa testisuoritusta ja käytimmekin ajan hyödyksi mm. paikkaamalla protosta unohtuneet osiot ja dialogit, joita tosin ei ollut kuin muutama. Paperiprotoa käytimme siis simuloimaan varsinaisen järjestelmän toimintaa ja näkymiä. Hiiren sijasta käyttäjällä oli osoitinlaitteena kynä. Protoa käytettiin niin, että proton pyörittäjä vaihtoi käyttäjän eteen oikean näkymän käyttäjän klikatessa proton linkkejä. Piilossa olevat näkymät olivat esillä toisella pöydällä, jotta paperiproton käyttäjä pystyi valitsemaan nopeasti oikean näkymän. Tavoitteen testeillä oli löytää järjestelmän käyttöliittymästä käyttäjän kannalta hankalat ja epäloogiset kohdat. Erityisesti testasimme kolmea keskeistä toimintoa, joita loppukäyttäjät ensisijaisesti tarvitsevat: loppukyselyn ja avoimen kyselyn tekeminen sekä tulosten julkaisu. Näissä osioissa ilmenikin monia parannuskohtia, joita selvitämme tarkemmin myöhemmin tässä raportissa. Lisäksi halusimme testata valitsemiamme symboleja ja tekstejä. Symbolit koettiin suhteellisen hyviksi, mutta joidenkin nappien osalta tekstit olivat hankalampia. Muistettavuutta emme ehtineet testata alkuperäisestä suunnitelmasta poiketen ajanpuutteen vuoksi. Etukäteen olimme ehkä hieman pessimistisiä paperiproton hyödyllisyyden suhteen. Uskoimme toki siitä olevan apua käyttöliittymän hiomisessa, mutta lopulta testien jälkeen suorastaan yllätyimme kuinka paljon virikkeitä se antoi käyttöliittymän käytettävyyden parantamisen suhteen. Osa näistä olisi toki tullut esiin esimerkiksi perusteellisen heuristisen arvioinnin kautta, mutta tämä oli loppujen lopuksi kattavampi tapa tutkia käytettävyyttä. Aikomamme heuristisen arvioinnin suoritimme vasta testien jälkeen. 1

2. Testien puitteet yleisesti 2.1. Testien järjestelyt Valitsimme testihenkilöiksi kohderyhmäämme kuuluvia pääassistentteja. Testihenkilöt olivat iältään 21-24 vuotta. Kaikilla oli muutama vuosi kokemusta assistentin työstä, ja ensimmäinen tai toinen kerta pääassistenttina meneillään parasta aikaa. Testihenkilöinä oli kaksi miestä ja yksi nainen. Koimme tämän edustavuuden tärkeäksi, vaikka emme tuloksista voineetkaan vetää mitään sukupuoleen liittyviä johtopäätöksiä. Olimme etukäteen varanneet sopivan luokkahuoneen T-talolta testikäyttöön. Kyseinen luokka oli riittävän rauhallinen ja tilava kameroiden ja proton suhteen. Haimme aina kunkin käyttäjän tapaamispaikaksi sovitusta kirjastosta itse testipaikalle. Ryhmämme sisällä jaoimme tehtävät pääpiirteissään siten, että yksi huolehti kamerasta ja äänityksestä, yksi prototyypin pyörittämisestä ja yksi käyttäjän ohjaamisesta sekä muistiinpanojen teosta. Käytännössä roolit kuitenkin sekoittuivat hieman, ja jopa keskustelimme toteuttamiseen liittyvistä kysymyksistä parilla lauseella jopa testin aikana. Tämä ei kuitenkaan tuntunut haittaavan käyttäjiä, jotka olivat varsin uppoutuneita itse prototyyppiin. Päätimme pitää roolit samoina testistä toiseen. Mielestämme jako toimi hyvin, eikä toimivaa järjestelmää suinkaan aina kannata muuttaa. Roolien vaihtaminen olisi lisäksi saattanut aiheuttaa ylimääräistä sähläystä ja sitä kautta vaikuttaa tuloksiin. Kuva 1, kaaviokuva testitilanteen fyysisestä ympäristöstä. Testi kesti pisimmillään noin tunnin. Käyttäjämme osallistuivat siihen kohtuullisen mielellään, mutta pidempään testiin olisi kuitenkin ollut vaikeaa saada sopivia testihenkilöitä jopa ylimääräisten kannustimien, kuten elokuvalippujen avulla. Tietysti nykyisenkin testin kannalta olisi ehkä ollut kohteliasta ja jossain määrin testitilannetta rauhoittavaa tarjota haastateltaville esim. testin alussa kahvia ja pullaa. Emme tätä kuitenkaan kiireiden vuoksi ehtineet järjestää. Testissä ilmi tulleisiin asioihin on saattanut vaikuttaa se fakta, että kaksi testihenkilöistä opiskelee syventäviä opintoja käytettävyydestä joko pää- tai sivuaineena. Kolmannella, pilottikäyttäjällämme, ei sentään ole omaa ammatillista suhdetta käytettävyyteen! Olisi voinut olla hyödyllistä sopia hänen haastattelunsa toiseksi näistä varsinaisista haastatteluista, mutta aikataulujen takia tämä ei ollut mahdollista. Testin aluksi mainitsimme kurssista, ja esittäydyimme testikäyttäjälle. Olimme jo etukäteen kysyneet testihenkilöiltä lupaa kuvata testitilanne joten kenellekään ei tullut yllätyksenä kameran käyttö. Alkuesittelyjen jälkeen selvitimme testattaville ohjeita paperiproton käyttöön. Ts. neuvoimme heitä suhtautumaan proton näkymiin niin kuin ne olisivat 2

tietokoneen näkymiä. Osoitinlaitteena käytimme kynää, joka ehkä erosi käytöltään liikaa tietokoneen hiirestä sillä ohjeista huolimatta testattavat eivät pitäneet sitä kokoaikaa testialustalla. Kun testihenkilöt kokivat olevansa valmiita, kertoi opastaja heille ensimmäisen tehtävän. Tehtävien aikana opastaja neuvoi, mikäli testihenkilö eksyi liian kauaksi oikealta reitiltä. Tämä tapahtui hienovaraisimmillaan siten, että hän muistutti tehtävänannon sanamuodosta. Huomasimme myös testien aikana, että meiltä oli jäänyt toteuttamatta pari aikomaamme dialogia. Näissä kohdissa opastaja kertoi suullisesti dialogien sisältämän tiedon. 2.2. Tehtävät Valitsimme testitehtäviksi kolme tehtävää, jotka kattavat järjestelmän tärkeimmät ja useimmin käytetyt osa-alueet. Tehtävät olivat suhteellisen lyhyitä ja yksinkertaisia, jotta testikäyttäjän keskittyminen tehtävään ei herpaantuisi. 2.2.1. Loppukyselyn tekeminen ja julkaisu Luennoitsijalta on tullut aamulla postia, että kurssille pitäisi saada loppukysely aikaiseksi kurssille T-121.110 ja kiireellä. Osaston palautekoordinaattori kuulemma vaatii, että kysely olisi valmis jo tänään iltapäivällä. Ihan kuin sinulla ei olisi muita kiireitä! Tarkoitus on siis luoda kurssille loppukysely käyttäen valmista loppukyselypohjaa. Tämä tehtävä on kaikkein tärkein, sillä palautejärjestelmää käytetään useimmiten juuri loppupalautekyselyjen luomiseen. Loppukyselypohjan käyttäminen on pakollista, sillä se sisältää kysymykset joista osasto haluaa tietoa. Tehtävässä on kaksi ratkaisutapaa: 1. Sisäänkirjautuminen > Päävalikko > Lisää uusi kysely > Kurssin valinta > Tee loppukysely > Dialogin täyttäminen > (Esikatselu) > Tallenna > Julkaise 2. Sisäänkirjautuminen > Päävalikko > Kyselyjen hallinnointi > Kyselyn muokkaus > Kurssin valinta > Tee loppukysely > Dialogin täyttäminen > (Esikatselu) > Tallenna > Julkaise 2.2.2. Jatkuvan avoimen palautteen luonti Haluat luoda assaroimallesi kurssille T-121.110 kanavan, jolla opiskelijat voivat lähettää jatkuvasti vapaamuotoista palautetta sinulle. Olet kuullut, että se onnistuisi uudella palautejärjestelmällä. Projektin ensimmäisessä vaiheessa kävi ilmi vapaan palautteen tarpeellisuus, sekä opetushenkilökunnan halu saada jatkuvaa palautetta kurssistaan. Tällä tehtävällä pyritään selvittämään, että kyseisen toiminnon tekeminen on järjestelmällä helppoa. Lisäksi tehtävän tarkoitus on selvittää kyselyn luonnin peruskäyttöliittymää, johon testi käyttäjä joutuu tämän tehtävän puitteissa tutustumaan. Tehtävään on kaksi erilaista lähestymistapaa: 1. Sisäänkirjautuminen > Päävalikko > Luo uusi kysymys > Vapaa tekstikenttä > Lisää uuteen kyselyyn > Kurssin valinta > Kyselyn nimi > Kielet > (Esikatselu) > Tallenna > Julkaisupäivät > (Sähköpostia vastauksista) > Julkaise 2. Sisäänkirjautuminen > Päävalikko > Luo uusi kysely > Kurssin valinta > Kyselyn nimi > Lisää kysymys > Vapaa tekstikenttä > Lisää kyselyyn > Kielet > (Esikatselu) > Tallenna > Julkaisupäivät > (Sähköpostia vastauksista) > Julkaise 3

2.2.3. Tulosten julkaisu Kevät on lopussa ja assaroimasi kurssi T-121.110 on päättynyt. Kurssi on kerännyt loppupalautteessa erinomaisia arvosanoja, joten haluat että opiskelijatkin pääsevät niitä ihailemaan. Tarkoituksena on siis julkaista T.121.110 kurssin tulokset Internetissä. Tässä tehtävässä käyttäjä tutustuu tuloksien hallintaan. Kuten edellä, mahdollisia ratkaisuja on muutama: 1. Sisäänkirjautuminen > Päävalikko > Hae tulokset > Haluttujen ruutujen rastitus > Julkaise 2. Sisäänkirjautuminen > Päävalikko > Kyselyjen hallinta > Tulokset > Haluttujen ruutujen rastitus > Julkaise 2.3. Haastattelu Haastattelu koostui kolmesta osasta. Ensimmäiseksi testihenkilöille esitettiin symbolitesti (Liite 1), josta käyttäjien piti tunnistaa tai arvata kyseisien symbolien käyttötarkoitus ja toiminto, sekä muistaa paikka, jossa kyseinen symboli on mahdollisesti tullut vastaan. Tämän jälkeen testihenkilöille näytettiin näkymiä prototyypistä ja kysyttiin näkymien tarkoitusta ja toimintoja. Näytettävät näkymät valittiin sillä perustella, missä käyttäjillä oli ollut eniten ongelmia. Lisäksi kaikille näytettiin Kyselyiden hallinta -näkymä, johon ei tehtävien puolesta ole välttämättä päädytty missään vaiheessa. Viimeisessä vaiheessa käyttäjiä haastateltiin vapaamuotoisesti lähinnä heidän tekemien virheiden tiimoilta ja pyydettiin heiltä lisäselvitystä ongelmakohtiin. Lisäksi käyttäjien taustatietoja kerättiin hieman sen osalta kuinka paljon kokemusta heillä oli tietokoneista ja erilaisista kurssihallintajärjestelmistä. Haastatteluosuus oli varsin hyödyllinen, sillä testin aikana testattavat olivat ehkä liian uppoutuneita itse testiin, jotta olisivat voineet eritellä kokemuksiaan tarkemmin. 2.4. Testien tallennus ja purku Testit tallennettiin pääosin käyttäen videokameraa. Koska emme olleet varmoja, kuuluuko videokameralla tallennettu ääni tarpeeksi hyvin, nauhoitimme äänen myös ääninauhurilla. Testien lopussa tehty haastattelu tallennettiin kokonaisuudessaan ääninauhurin ja muistiinpanojen avulla. Materiaalin purku tapahtui TML-laboratorion mediariihessä. Videon ääni osoittautui riittäväksi, ja haastatteluosuuksissa tehdyt muistiinpanot osoittautuivat niin kattaviksi, että emme tarvinneet ääninauhoja ollenkaan. Katsoimme läpi testihenkilöiden tehtävät ja jokainen ryhmän jäsen teki muistiinpanoja videosta. Yksi ryhmän jäsen kirjasi ylös käyttäjän hiiren painallukset ja navigoinnin, jotta saisimme selville tehdyt virheet. Kaksi muuta jäsentä keskittyi käyttäjän tärkeiden kommenttien ja ajatusten kirjaamiseen. Alun perin meidän piti purkaa tulokset affiniteettidiagrammi -metodilla, mutta ajanpuutteen vuoksi, kävimme tuloksia läpi ryhmässä verraten muistiinpanoja ja sovimme korjauksista tapauskohtaisesti. 2.5. Käyttöä vaikeuttaneet tekijät Prototyypin käytössä ilmeni muutamia käyttäjän etenemistä vaikeuttavia tekijöitä, joita on vaikea luokitella varsinaisiksi virheiksi. 4

2.5.1. Eläytymiskysymys Testihenkilömme olivat tällä kertaa kaikki pääassistentteja, joilla omat assaroitavat kurssit tuntuivat olevan varsin pinnalla mielessä. Käyttäjillä tuntui olevan vaikeuksia eläytyä väärän kurssin assaroimiseen. Väärällä tarkoitamme sitä, että paperiprotossa simuloitujen kurssien nimet olivat musteella paperiin kiinnitettyjä, ja kaikkien testihenkilöiden kohdalla erinimisiä ja -koodisia kuin heidän oma kurssinsa. On tosin mahdollista, että emme olisi havainneet tätä ongelmana, mikäli oma prototyyppimme olisi ollut intuitiivisemmin käytettävä. On esimerkiksi mahdollista, että käyttäjä joutui keskittymään prototyypin käyttöön niin intensiivisesti, että tehtävään eläytyminen alkoi pätkiä. Toisaalta voidaan myös kysyä, voiko paperiprototyypin käyttökokemus koskaan täysin vastata autenttista kokemusta. Selkeästi vaikeuttavia osa-alueita oli esimerkiksi suoraeditointi, jota ei suoranaisesti pystytä esittämään riittävän hyvin paperiprotossa. Tämän sen vuoksi, että osoitinlaite ei kerro kursorin tapaan, että teksti on editoitavissa. Käytännössä testattava voi kysyä opastajalta, että voiko tätä kohtaa editoida tai kuljettamalla osoitinta kohdan yli, jolloin olisi myös luontevaa kertoa editoitavuudesta. Valitettavasti osoitinlaitteena toiminut kynä ei ollut luonteva kursorin vastine, joten testihenkilöt eivät liikuttaneet sitä kokoaikaa näytöllä. Muita vaikeita kohtia olivat valmiiksi tehdyt mallinäkymät. Näitä oli valmistettu sen vuoksi, että järjestelmässä on paljon dynaamisesti muokkautuvia näkymiä, eikä testattavan henkilön tuotoksia voitu täysin ennustaa. Näissä kohdissa jouduimme erikseen toteamaan, että mitä ylimääräistä henkilö oli näkymään tehnyt (esim. lisäkysymykset). Erityisesti toimivalla esikatselulla olisi voinut olla testihenkilölle apua käyttövarmuutta nostattavana tekijänä. Lisäksi esimerkiksi valintalistojen sisällöstä olimme päättäneet ilmoittaa suullisesti, mutta joissain tapauksissa olisi voinut olla hyväksi mahdollisuus autenttisempaan kokemukseen. 3. Pilottitesti 3.1. Pilottitestin valmistelut Olimme aiemmin varanneet T-talolta luokan testien pitämistä varten kahtena iltapäivänä sekä laitteet samoiksi ajankohdiksi. Pilottitesti ajoittui varsinaisia testejä edeltävälle päivälle, jolloin meille jäi vielä aikaa hioa testijärjestelyjä. Laitteita olimme varanneet paperiproton ja kynäosoittimen lisäksi kameran, jalustan, minidisc-laiteen, sen tarvitseman mikin ja akut, sekä kaksi dv- ja kaksi minidisc-kasettia. Varasimme pilottitestiin valmistautumiseen aikaa n. tunnin, jonka aikana kokosimme laitteet sekä kävimme vielä kerran paperiproton ja tehtävät keskenämme läpi. Teimme lisäksi sekä videokameralle että minidisc-soittimelle pienen koenauhoituksen, jotta voisimme varmasti tietää, että ne todella tallentavat tapahtumat. Kiteyttäen kamerankäyttäjä perehtyi ja varmisti kameran toimivuuden, protonpyörittäjä järjesteli paperilappuja, ja käyttäjän opastaja laittoi minidisc-laitteen kasaan ja leikkeli proton dialogilappusia paremman muotoisiksi. 3.1.1. Testin kulku Sama henkilö, joka oli sopinut testistä koehenkilön kanssa, haki tämän T-talon kirjaston edestä sovittuun aikaan. Kävelymatkan aikana testattava osoitti normaalia sosiaalista kiinnostusta testiin ja siihen kurssiin mihin se liittyi, ja tämä tarjosi hyvän tilaisuuden kertoa nämä tiedot. Luokassa esittelimme käyttäjän ryhmälle ja päinvastoin. Lisäksi varmistimme 5

vielä kertaalleen, ettei videointi haittaa käyttäjää. Kamera ja laitteet olivat jo paikoillaan ja testikäyttäjä sai istua hänelle varattuun tuoliin. Selitimme ääneenajattelemisen periaatteen nopeasti harjoituksissa mainitun tekstiviestiesimerkin avulla, sillä se tuntui olevan tarpeen. Varmistimme sisäänkirjautumis-näkymässä vielä käyttäjää opastaen, että klikkaukset ja osoittaminen onnistuvat käyttäjältä. 3.1.2. Ongelmia tehtävien suorittamisessa Pilottitestimme ei onnistunut erityisen hyvin, mikäli mittarina käytetään onnistuneiden tehtävien määrää. Johtuen erittäin huonosta tuloksesta on alla selvitetty tehtäväkohtaisesti ongelmat joita esiintyi ja kappaleessa 3.3 korjaukset jotka teimme prototyyppiin ennen seuraavia testejä. Ensimmäisenä ollut loppukyselytehtävä ei edennyt päätökseensä. Testitilanteessa päätimme olla kiskomatta käyttäjää väkipakolla finaaliin asti, sillä olimme kuitenkin käyneet kaikissa oleellisissa näkymissä yhtä lukuun ottamatta, ja saaneet niistä arvokasta tietoa. Epäonnistumisen syitä on purettu tarkemmin alla. 3.1.2.1. Tee tästä tavallinen kysely -painike Olimme prototyypissämme yrittäneet löytää toimivan kompromissin siihen, miten järjestelmällä olisi sekä helppoa luoda loppukysely, että laajentaa ja kustomoida sitä mukavalla tavalla. Olimme toteuttaneet tämän Tee loppukysely -napilla (Kuva 2), joka muuttuisi Tee tavallinen kysely-napiksi, jos käyttäjä haluaisikin muuttaa mielensä (Kuva 3). Kuva 2: tee loppukysely napin alkuperäinen sijoittelu. Pilottitestissä käyttäjä yhden harhakäynnin Tulokset-osiossa jälkeen pääsi hyvin ohjattuun loppukyselyn-luomistoimintoon asti, mutta tämän jälkeen klikkasi Tee tavallinen kysely - nappia, jolloin koko kysely katosi. Käyttäjä ei ymmärtänyt, että loppukysely oli todella valmis. Tämän lisäksi Tee tavallinen kysely -painike osoittautui aikamoiseksi katastrofiksi, sillä jostain syystä nappi on niin houkutteleva, että sitä on pakko painaa, jolloin koko äsken tehty työ katoaa. Päätimme poistaa Tee tavallinen kysely -napin prototyypistämme kokonaan häiritsevyyden takia. Päätimme myös sijoittaa Tee loppukysely -painikkeen hieman toiseen kohtaan varsinaisia testejä varten. 3.1.2.2. Kyselyn ja kysymyksen muokkaustilojen yhteyden ymmärtäminen Avoimen palautteen luontitehtävä ei myöskään onnistunut pilottitestissä. Käyttäjä ei ymmärtänyt Kyselyn muokkaus -ikkunan toiminnallisuutta. Testihenkilö keksi kyllä painaa 6

plus-painiketta, josta avautui Kysymyksen muokkaus -dialogi. Siellä hän kuitenkin varsin hätäisesti päätteli, ettei avointa palautetta löydy täältäkään. Kysymyksen muokkaus-näkymässä tallenna ja lisää kyselyyn -painikepari hämäsi käyttäjää sikäli, että ennen kokeilemista ei ollut selvää mitä kummastakin tapahtuu. 3.1.2.3. Palaute tulosten julkaisusta Kolmas tehtävä onnistui sikäli, että kyselyn tulokset saatiin julkaistua. Käyttäjä ei kuitenkaan saanut palautetta siitä, että oliko kysely todella julkaistu ja mistä se löytyisi. Käyttäjä haluaisi tositilanteessa itse käydä vielä nettisivulla katsomassa miltä se näyttää, ja onko tietoturvaseikat varmasti huomioitu tarpeeksi hyvin. Lisämainintana julkaisudialogin päivämäärien syöttötapa ei miellyttänyt käyttäjää. Dialogissa oli yksi kenttä, johon päivämäärä syötettäisiin pp.kk.vvvv muotoisena. Käyttäjä toivoi mieluummin erillisiä kenttiä päivälle, kuukaudelle sekä vuosiluvulle. 3.1.2.4. Ohjeet Kävi ilmi että ohjeet olivat liian pitkiä, suhteessa siihen että niitä ei ole jäsennelty millään tavalla. Lopputulos oli se, että käyttäjä joutui lukemaan koko ohjeen läpi, eikä välttämättä silti ollut löytänyt toivomaansa. Uskomme nyt että paria riviä pidemmissä ohjeteksteissä pitää olla väliotsikoita, lihavoituja avainsanoja tai hakusanoja, jotta käyttäjän ei tarvitse lukea koko ohjetta läpi, ellei sitten halua tehdä niin. Ohjeet voisivat sisältää myös kuvakkeiden kuvia selkeyttämään sitä yhteyttä mihin ne liittyvät. Kuvien käyttö on osaltaan myös jäsentelyä, sillä käyttäjä voi poimia haluamansa tiedon ohjeesta myös lukemalla kuvitusta. Erityisempi korjauskohde löytyi Kyselyn muokkaus -ohjeesta, jossa pitää kertoa myös millaisia kyselyitä voi tehdä ja miten. Käyttäjä ei onnistunut yhdistämään tekstikenttäkäsitettä avoimeen palautteeseen. Herää kysymys, riittääkö aiheen selventäminen ohjeessa, vai pitäisikö termi tekstikenttä vaihtaa avoimeksi palautteeksi. Päävalikon sisältämät nimikkeet tuntuivat olevan hyvin nimettyjä, sillä navigointi niiden perusteella onnistui ja auttoi käyttäjää rajaamaan tiettyjä tehtäviä tiettyjen nimikkeiden alle. 3.2. Järjestelyihin liittyvät ongelmat Osa testisuunnitelmassamme hahmottelemista menetelmistä ja toimintatavoista osoittautui epäkäytännöllisiksi tai muista syistä vaikeiksi toteuttaa. 3.2.1. Osoittimen käyttö Olimme suunnitelleet, että testihenkilö pitäisi osoitinvälineensä koko ajan kiinni paperiproton näkymässä. Uskoimme, että tällä tavalla olisimme saaneet enemmän irti käyttäjän hiiren liikkeistä. Pilottitestin aikana osoittautui kuitenkin, että tämä oli liian hankalaa ymmärtää käyttäjälle. Pilottikäyttäjä ei muistanut tai ymmärtänyt annettuja ohjeita osoittimen pöydässä pitämisestä sekuntia kauempaa. Muistutimme muutaman kerran, mutta näimme parhaaksi luopua tästä vaatimuksesta jo ensimmäisen viiden minuutin aikana. Emme yrittäneet vaatia tämän noudattamista enää varsinaisissa testeissä. 3.2.2. Testitilanteen kesto Pilottitestissä huomasimme myös, että aikaa kului huomattavasti enemmän kuin olimme alun perin suunnitelleet. Tämä johtui osittain proton pyörittämisestä ja osittain 7

virheklikkauksista ja testattavien halusta kokeilla eri toimintoja. Totesimmekin, että emme ajan puitteissa ehtisi tehdä aikomaamme muistitestiä. (Ts. pyytää käyttäjää testin jälkeen muistelemaan reittiä, jota käytti eri tehtävissä.) Olimme nimittäin sopineet testattavien kanssa tunnin pituisesta testikerrasta. Tätä pidempi aika ei käytännössä oikein voinut olla, sillä se olisi alkanut karsimaan liikaa sopivia testihenkilöitä. Myös testattavien jaksaminen olisi tullut eteen. Pitkä testitilanne olisi voinut stressata ja heijastua testiin. 3.3. Paperiprototyyppiin ja testijärjestelyihin tehdyt muutokset Testissä huomasimme eroavaisuuksia eri testitehtävissä käytetyissä nimissä ja kurssikoodeissa. Korjasimme ne yhden mukaisiksi kaikkien tehtävien osalta, jotta käyttäjien olisi helpompi eläytyä tilanteeseen. Päätimme toteuttaa korjaukset myös vakavimmiksi kokemiimme ongelmiin prototyyppinäkymissä, oman parhaan osaamisemme mukaan. Esimerkiksi Kyselyn muokkaus -näkymän parannusyritys osoittautuu myöhemmin kaikkea muuta kuin ideaaliseksi. Selkeyttääksemme Kyselyn muokkaus näkymää, muutimme sitä seuraavalla tavalla varsinaisia testejä varten: Kuva 3: varsinaisissa käyttäjätesteissä käytetty kyselynmuokkausnäkymä. (Vrt. kuva 2) 8

Lisäsimme myös prototyyppiin tulosten julkaisua seuraavan palautedialogin, joka näyttää tältä: Kuva 4: julkaisudialogi. 4. Varsinaiset testit Pilottitestin jälkeen suoritimme kaksi varsinaista testiä käyttäen kappaleessa 3.3 selvitettyjä muutoksia. Tässä kappaleessa on raportoitu testien tulokset, sekä eritelty käyttäjien tekemät virheet, joista johdetaan käyttöliittymäongelmat kappaleessa 5. 4.1. Tehtävien onnistuminen ja virheet Kummatkin käyttäjät onnistuivat suorittamaan kaikki tehtävät ilman meidän ohjausta. Tästä huolimatta kahdessa ensimmäisessä tehtävässä oli hyvin paljon ongelmia. Seuraavassa kappaleessa on esitetty testisuunnitelman mukainen virheluokittelu ja kappaleessa 4.1.2 on esitetty käyttäjien virheet tehtäväkohtaisesti tämän luokittelun mukaan. 4.1.1. Virheiden luokittelu Testisuunnitelman mukaan virheet luokiteltiin seuraavasti: 1. Käyttäjä ei selviä tehtävästä ilman meidän ohjausta. 2. Käyttäjä luulee tehtävän olevan suoritettu vaikka se ei ole. 3. Käyttäjä tekee virheklikkauksen, joka johtaa väärään näkymään. 4. Käyttäjä tekee virheklikkauksen, joka ei vie pois näkymästä. 5. Käyttäjä ei selviä tehtävästä ilman prototyypistä löytyviä ohjeita Virheet, jotka eivät sijoitu mihinkään näistä kategorioista, luokiteltiin testisuunnitelman mukaan tapauskohtaisesti välille 1-3. Huomattavaa on, että yllä kuvattu luokittelu on osaltaan epäonnistunut, sillä käyttäjien tekemistä virheistä ainoastaan puolet pystyttiin luokittelemaan yllä olevin perustein. 4.1.2. Virheet ja niiden analyysi Virheet on merkattu seuraavassa järjestyksessä: ensiksi virheen numero, tämän jälkeen [virheen luokiteltu vakavuus] ja lopuksi virheen kuvaus ja vaikutus käyttäjään. 4.1.2.1. Loppukyselyn tekeminen ja julkaisu 1. [3] Käyttäjä onnistuu siirtymään Lisää loppukyselyn kysymykset napin kautta loppukyselydialogiin ilman virheitä, vaikka ihmetteleekin eikö järjestelmällä voi tehdä muita kuin loppukyselyitä. Tämä voidaan laskea virheeksi, sillä käyttäjä ei selvästi ole tietoinen järjestelmän toiminnasta. Tämä on erittäin vakava ongelma, 9

kuten toisessa tehtävässä havaittiin. Kummatkin käyttäjät törmäsivät tähän ongelmaan. 2. [4] Loppukyselydialogissa käyttäjä ei huomaa, että määrittelyrivejä voi muokata suoraan, vaan poistaa ensiksi rivin ja sen jälkeen lisää uuden rivin. Virhe ei ole vakava, mutta se hidastaa käyttäjän työskentelyä jonkin verran. 3. [4] Käyttäjä ei tajua, että loppukyselydialogi kysyy kurssin tietoja lisätäkseen automaattisesti tarvittavat kysymykset kyselyyn. Käyttäjä selaa dialogin loppuun asti ja huomatessaan Lisää kyselyyn napin tajuaa tilanteen. Virhe on turhauttava käyttäjälle, sillä hän ei heti tajua miksi häneltä kysytään kysymyksiä kurssista. 4. [4] Kysymyksen tehtyään käyttäjä ei tiedä pitäisikö hänen painaa Tallenna vai Lisää kyselyyn. Käyttäjä valitsee Tallenna napin, mutta tajuaa sen olevan väärä valinta ja painaa tämän jälkeen Lisää kyselyyn nappia. Virhe ei ole vakava, sillä se voidaan korjata yhdellä napin painalluksella, ja mitään tietoja ei menetetä. 4.1.2.2. Jatkuvan avoimen palautteen luonti 5. [2] Käyttäjä ei tiedä mistä lisäisi kysymyksen kyselyyn ja harhailee kyselyn muokkaus -näkymässä kokeillen mm. kansio -nappia ja + -nappia, tietämättä mitä tehdä. Lopulta käyttäjä kuitenkin tajuaa, että + -nappi on oikea vaihtoehto. Tämä on erittäin vakava ongelma, sillä tällaisissa tilanteissa käyttäjä turhautuu helposti ja saattaa jättää leikin kesken. Lisäksi se, että käyttäjä käy oikeassa kohdassa, mutta ei tiedä sitä, kertoo siitä että järjestelmä on erittäin sekava. 6. [3] Käyttäjä ei ymmärrä kysymyksen luonti -dialogissa sitä, minne kysymystä oikeastaan ollaan luomassa ja poistuu näkymästä. Samantyyppinen ongelma kuin kohdassa 5, käyttäjä ei tajua kysymys- ja kyselynäkymien yhteyttä. Ongelma on vakava, sillä käyttäjän täytyy tietää koko ajan missä mennään jotta luottamus järjestelmään voisi kehittyä. 7. [4] Käyttäjä luulee, että kysymyksen luonti -dialogissa Tallenna -nappi tallentaa kysymyksen omalle koneelle. Tämä ei ole kovin vakava ongelma, sillä painettuaan Tallenna -nappia käyttäjä huomaa, että kyseessä on järjestelmän sisäinen tallennus. Tilasta voi myös palata yhdellä painalluksella pois ja tietoja ei menetetä. 8. [2] Kyselyn muokkaus -näkymässä käyttäjä ei ymmärrä miten luodaan tavallinen kysely, vaan ihmettelee lisää loppukyselyn kysymykset nappia. Kun tämä nappi peitetään käyttäjä ymmärtää olevansa luomassa tavallista kyselyä. Tämä on erittäin suuri ongelma, sillä käyttäjän pitäisi olla koko ajan tietoinen siitä mitä ollaan tekemässä. 9. [4] Käyttäjä ei muista valita oikeaa kurssia ennen kuin yrittää tallentaa kyselyä. Virhe ei ole vakava, sillä lopullisessa versiossa pakolliset kentät joita ei ole täytetty merkitään erottuvasti punaisella korostuksella. Paperiprotossa tätä ei simuloitu. 10. [4] Kysymyksen tehtyään käyttäjä ei tiedä pitäisikö hänen painaa Tallenna vai Lisää kyselyyn. Käyttäjä valitsee Tallenna napin, mutta tajuaa sen olevan väärä valinta ja painaa tämän jälkeen Lisää kyselyyn nappia. Virhe ei ole vakava, sillä se voidaan korjata yhdellä napin painalluksella, ja mitään tietoja ei menetetä. 10

4.1.2.3. Tulosten julkaisu Tässä tehtävässä ei tapahtunut virheitä. 4.2. Haastattelun tulokset Tässä kappaleessa keskitytään antamaan tulokset lähinnä symbolitestistä ja näkymien ja niiden toimintojen kyselemisestä. Tehtävien läpikäynti on sivuutettu, sillä niiden tulokset on jo esitettynä yllä, virheiden yhteydessä. Haastattelussa ilmi tulleet kommentit oli testisuunnitelman mukaan tarkoitus järjestellä ja priorisoida, mutta koska tämä olisi vienyt liikaa aikaa, esitämme tässä vain käyttäjien mielipiteet, jotka eivät ole jo esillä ylhäällä olevien virheiden yhteydessä. 4.2.1. Symbolitesti Symbolitesti piti sisällään suurimman osan prototyypin ja järjestelmän tärkeimmistä symboleista, joista osa oli tullut käyttäjille vastaan jo testitehtävien aikana. Kaikki käyttäjät selviytyivät symbolitestistä hyvin ja vastasivat kaikkiin symboleihin oikein. Ainoastaan virheen symboli tulkittiin kahteen kertaan väärin. Sen epäiltiin kuvaavan tilaa, jossa käyttäjä on tehnyt jotain kiellettyä. 4.2.2. Näkymien ja toimintojen kysely Testikäyttäjät tunnistivat hyvin esitetyt näkymät ja niissä olevat toiminnot. Etenkin Kyselyiden hallinta -näkymä oli erityisen selkeä käyttäjien mielestä. Eniten kummastusta herätti Kyselyn muokkaus näkymä, ja lisää loppukyselyn kysymykset toiminto. Tehtävien suorittamisen jälkeen, testihenkilöt osasivat kuitenkin selittää nämäkin toiminnot. Kritiikkiä saivat myös järjestelmään tehdyt ohjeet, jotka olivat käyttäjien mielestä liian pitkät (vaikka ne olivat vain noin 15 riviä). Lisäksi niistä ei löytynyt tarpeellista tietoa. 4.3. Käytettävyyskriteerien toteutuminen Testisuunnitelmassa asetettiin järjestelmälle kolme käytettävyyskriteeriä silmälläpitäen järjestelmän kolmea tärkeää ominaisuutta: intuitiivisuutta, opittavuutta ja luotettavuutta. Seuraavassa on tarkasteltuna kunkin kriteerin täyttymistä. I. Tavoitteena on intuitiivisuuden osalta, että 2/3 testattavista osaa arvata haastattelun aikana esitettyihin tiedusteluihin symbolien toiminnasta 90 prosenttisesti oikein, ilman kokeilua. Haastatteluiden aikana tehtyjen symbolitestien tulosten perusteella (kappale 4.2.1) tämä kriteeri saavutettiin. II. Tavoitteena on, että kaikki vastaajat tietävät yhden käyttökerran jälkeen tehdyssä pistokokeessa kaikkien kysyttyjen symbolien, nappien ja dialogien tehtävän. Lisäksi kahden käyttäjästä kolmesta tulee muistaa vähintään kahden tehtävän ratkaisu kolmesta. Eli muistaa polku jota pitkin ratkaisuun päästiin. Tehtävien ratkaisuihin johtavia polkuja ei kysytty (Kappale 3.2.2). Sitä vastoin eri nappien ja näkymien tehtäviä ja toimintoja kysyttiin ja näihin käyttäjät osasivat vastata oikein. Kriteeri siis saavutettiin. 11

III. Tavoitteena virhetilanteiden osalta on, että 2/3 testattavista ei saa minkäänlaisia virheilmoituksia. Tosin testaustilanteen ja paperiprototyypin vuoksi on huomattava, että pakolliset kentät saattavat unohtua tilanteesta johtuen. Tämä käytettävyyskriteeri oli erittäin huonosti aseteltu, sillä käytännössä prototyyppimme ei voinut päätyä tilanteeseen, jossa käyttäjälle olisi näytetty virheilmoitus. Prototyypissä oli kuitenkin mahdollista, että käyttäjä ei päässyt etenemään jos oli unohtanut pakolliset kentät. Näin tapahtui ainoastaan yhdessä tilanteessa, joten kriteeriä voidaan pitää saavutettuna. 5. Havaitut käytettävyysongelmat Käyttäjätestien ja heuristisen läpikäynnin perusteella järjestelmästä löydettiin useita erittäin vakaviakin käytettävyysongelmia. Ensiksi on listattu testien perusteella löydetyt ongelmat ja tämän jälkeen esitetään heuristiikalla löydetyt. 5.1. Testien perusteella Alla on esitetty käyttäjätestien perusteella ilmi tulleet ongelmat ja niiden luokittelu ja vaikutukset kriittisimmästä alkaen. A. Kyselyn muokkaus näkymän epäselvyys. Tämä on vuorovaikutukseen ja ymmärrettävyyteen liittyvä ongelma. Käyttäjä ei tiedä tarkalleen minkälaista kyselyä on tekemässä, eikä osaa yhdistää yksittäisen kysymyksen luontia kyselyn muokkaus näkymään. Käyttäjä ei osaa luoda uutta kysymystä kyselyyn ilman harhailua ja pohtimista tai käyttäjälle ei ole selvä minne luotu kysymys menee. Tämä ongelma liittyy virheisiin 1,5,6 ja 8. Ongelma on käyttäjän kannalta erittäin ärsyttävä, sillä käyttäjä ei tiedä mitä hän on tekemässä ja saattaa päätyä harhailemaan järjestelmän eri näkymissä. Jos ajatellaan kyselyn tekoa, niin kyseinen tehtävä saattaa jäädä suorittamatta tämän virheen takia. B. Kysymyksen tallennus toiminto Tämä on käsitteellinen ongelma. Käyttäjä ei tiedä mitä tallenna tarkoittaa annetussa yhteydessä (kysymyksen muokkaus dialogissa). Käyttäjä saattaa luulla, että tallentaminen tallentaa kysymyksen kyselyyn tai että kyseinen kysymys tallennetaan myöhempää käyttöä varten omalle koneelle. Tämä ongelma liittyy virheisiin 4,7 ja 10. Ongelma aiheuttaa käyttäjälle päänvaivaa, mutta ei ole vakava, sillä kerran kokeiltuaan käyttäjä tajuaa toiminnon. Toisaalta toiminnon epäselvyys estää luottamuksen syntymistä järjestelmään, ja ärsyttää käyttäjää. Käyttäjä voi olla myös haluton kokeilemaan toimintoa, jota ei täysin ymmärrä, sillä pelkää menettävänsä jotain tietoa. C. Loppukyselydialogin tarkoituksen epäselvyys Tämä ongelma on käsitteellinen. Käyttäjä ei ole varma miksi loppukyselydialogi kysyy kysymyksiä käyttäjän kurssista. Virhe 3. Ongelma ei ole suuri, sillä käyttäjän käytyä dialogi läpi, selviää sen tarkoitus. Käyttäjälle tämä kuitenkin on turhauttavaa, sillä hän joutuu vastailemaan kysymyksiin tietämättä mihin hänen antamiaan tietoja käytetään. 12

D. Ohjeiden epäselvyys Tämä on ongelma vaikuttaa järjestelmän ymmärrettävyyttä. Käyttäjät pitivät ohjeita liian pitkinä, eikä niistä löytynyt hyödyllistä tietoa. Virhe 11. Ongelma on vakava, sillä siinä vaiheessa kun käyttäjä turvautuu ohjeisiin, ollaan menty jo väärään suuntaan. Ohjeiden pitäisi pystyä ohjaamaan käyttäjä takaisin reitille. Käyttäjä turhautuu helposti jos ei löydä haluamaan tietoa nopeasti ohjeista, eikä ehkä jaksa lukea kaikkia ohjeita läpi. E. Muokattavien kenttien selvyys Tämä on vuorovaikutustapaan liittyvä ongelma. Käyttäjä ei tajua, että joitain kenttiä voi muokata painamalla niiden kohdalla hiiren nappia. Tämä ongelma liittyy virheeseen 2. Ongelma ei ole vakava, sillä se todennäköisesti korjaantuu kun järjestelmä siirretään tietokoneelle. Silloin muokattavat kentät ovat kaikille tuttuja tekstikenttiä, jolloin varmasti tajuaa että kyseistä kenttää voi muokata. Myös kursorin vaihtuminen auttaa asiaa. 5.2. Heuristinen arviointi Testien jälkeen kävimme läpi jokaisen käyttöliittymän näkymän ja dialogin. Niistä tutkimme, että kuinka hyvin ne toteuttavat Nielsenin heuristisia sääntöjä. Seuraavassa on listattuna heuristiikalla löydetyt ongelmat (ilman suurempaa järjestystä). F. Yhtenäisyys Havaitsimme käyttöliittymän olevan hieman epäyhtenäinen nappien sijoittelun ja symbolien käytön osalta Nielsenin 4. säännön pohjalta. G. Palaute Järjestelmä ei anna tarpeeksi palautetta käyttäjälle tulosten julkaisusta ja kyselyn tallentamisesta, jotta käyttäjä tietäisi koko ajan mitä on tapahtumassa ja mitä järjestelmä tekee (Nielsenin 5. sääntö). H. Yleisesti käytetyt toiminnot Päävalikon linkkien järjestys on epälooginen, sillä yleisesti käytetyt toiminnot eivät löydy ensimmäisenä (Nielsen 7) I. Ohjeiden pituus ja epäselvyys Ohjeet eivät sisällä minkäänlaisia väliotsikoita tai avainsanoja, jotka helpottaisivat tiedon etsintää pitkästä tekstistä (Nielsen 10) Näiden lisäksi heuristisessa läpikäynnissä ilmeni joitain pieniä asioita, joita voisi tehdä paremmin. Ne on mainittu tehtyjen korjausten yhteydessä kappaleessa 7. 6. Prototyypin kehittäminen Tässä kappaleessa esitetään prototyypin näkymiä ennen ja jälkeen korjausten. Korjaukset on tehty kappaleessa 5 esitettyjen käytettävyysongelmien parantamiseksi ja niihin viitataan kyseisen ongelman kirjaimella. 13

6.1. Tehdyt korjaukset Päävalikossa päätimme järjestää osiot uudelleen sen mukaan, mitkä niistä ovat eniten käytössä (H). Myös linkkejä on selvennetty ja ne eroavat nyt paremmin väliotsikoista. Suurin muutos tähän näkymään on se, että Luo uusi kysely toiminto ei siirrä käyttäjää enää suoraa kyselyn muokkaukseen vaan dialogiin, jossa kysytään käyttäjältä millaisen kyselyn hän haluaa tehdä. Vastauksesta riippuen järjestelmä luo kyselyyn automaattisesti valmiita kysymyksiä ja säätää avautumis- ja sulkeutumispäivien oletusarvot oikeiksi. Suurempi syy tämän dialogin tekemiseen oli kuitenkin kyselyn muokkaus näkymän selkeyttäminen, josta myöhemmin lisää. Kuva 5: Päävalikko ennen testejä. Kuva 6: Päävalikko testien ja heuristisen arvioinnin jälkeen. 14

Kuva 7: Luo uusi kysely -dialogi. 15

Osaston loppukyselyyn vaatimien kysymysten generointiin tarkoitettu dialogi sekoittui helposti kysymyksen muokkauksen kanssa (osittain A). Tämän vuoksi vaihdoimme otsikkopalkin väritystä. Vaihdoimme myös nimeä, koska nimi ei auennut testikäyttäjille. Loppukysely wizardiin päädyimme, koska kyseinen termi on varmasti tuttu pääkäyttäjäryhmällemme erilaisten tietokonepohjaisten käyttöliittymien kautta. Lisäksi päätimme liittää dialogiin etusivun, jossa lyhyesti kerrotaan, mitä tässä dialogissa tehdään (C). Kuva 8: loppukysely wizard ennen testejä. Kuva 9: loppukysely wizard testien ja heuristisen arvioinnin jälkeen. 16

Korjasimme kyselyiden hallinta -näkymän roskakorit vastaamaan kyselypohjassa esiintyviä punaisia miinus nappeja (F). Lisäksi päätimme lisätä nappeja varten oman dialogin, jossa varoitetaan poistotapahtumasta Windows-käyttöjärjestelmästä tuttuun tapaan OK-/Peruuta dialogilla (G). Kuva 10 kyselyiden hallinta ennen testejä. Kuva 11: kyselyiden hallinta testien ja heuristisen arvioinnin jälkeen. 17

Kyselyn muokkaukseen teimme eniten muutoksia (kaikki muutokset liittyvät kohtaan A). Erityisen hankala oli jo aiemmin mainittu Tee loppukysely / Tee tavallinen kysely nappi, josta päätimme luopua kokonaan. Tämän sijaan kyselyn tyypin valinta tehdään dialogin avulla (kuva 7) heti kyselyn luonnin valitsemisen jälkeen, jo ennen kuin käyttäjä tulee kyselyn muokkaus näkymään. Tällöin käyttäjä tietää selvästi mitä kyselyä on tekemässä ja näkymä selkiytyy. Päätimme lisäksi poistaa kansio kuvakkeen vielä selkeyttääksemme näkymää. Nyt kysymysvaraston pääsee ainoastaan kysymys dialogista. Näkymää selkeytettiin myös lisäämällä Kysymykset väliotsikko ja siihen väritetyn pohjan kysymyksiä varten. Kysymykset järjesteltiin uudelleen sillä tavalla, että + -napit ja - -napit erottuvat selvästi (kuvassa ei näy - -nappeja, mutta ne ovat samalla tasolla + -nappien kanssa). Lisäksi kysymyksistä joita ei voi poistaa poistettiin - -nappäimet kokonaan sen sijaan, että ne olisi harmaita. Lisäsimme myös väritetyn otsikkopalkin kysymyksiin, jonka kohdalla kursorin olisi tarkoitus muuttua kädeksi. Tämä voisi helpottaa käyttäjiä huomaamaan kysymysten siirtomahdollisuus hiirellä vetämällä (Drag n Drop). Heuristisen arvion perusteella myös Tallenna, Peruuta ja Esikatselu napit muutettiin vastaamaan muualla järjestelmässä käytettyä sijoittelua (F) Kuva 12: kyselyn muokkaus ennen testejä. 18

Kuva 13: kyselyn muokkaus testien ja heuristisen arvioinnin jälkeen. 19

Kysymyksen muokkaus dialogissa oli kaikilla käyttäjillä ongelmana Tallenna ja Lisää kyselyyn nappien toiminta. Tätä selkeytimme uudella asettelulla ja nappien nimeämisellä (B, F). Muutimme myös tämän dialogin otsaketta, jotta käyttäjät eivät lukisi sitä kiireessä väärin eli kyselyn muokkauksena (A). Kuva 14: Kysymyksen muokkaus ennen testejä. Kuva 15: Kysymyksen muokkaus testien jälkeen. 20

Tulokset-näkymässä päätimme poistaa kokonaan Näytä-napin ja muuttaa Tallenna-napin tekstin. Uusi teksti on Tallenna omalle koneelle, joka kertoo toiminnasta huomattavasti enemmän. Tulosten näyttäminen muutettiin niin, että näkymä muuttuu heti, kun kyseisiä checkboxeja tai tekstejä painaa. Tätä ei varsinaisesti huomattu käyttäjä testeissä (käyttäjät osasivat käyttää napillista versiota oikein) vaan heuristisen arvioinnin puolella. Kuva 16: Tulokset-näkymä ennen testejä. Kuva 17: Tulokset-näkymä testien jälkeen. 21

Kyselyn tallennus ja julkaisu -dialogia muutimme niin, että päivämäärien kysely on eritelty kahden tai neljän numeron kokoisiin tekstikenttiin. Näissä kursori siirtyisi automaattisesti seuraavaan boxiin päivämäärää kirjoitettaessa. Eriyttämisen hyvä puoli on helpompi hahmotettavuus, kun ei tarvitsisi muistaa erotinmerkkien käyttöä. Kuva 18: Kyselyn tallennus ja julkaisu -näkymä ennen testejä. Kuva 19: Kyselyn tallennus ja julkaisu -näkymä testien jälkeen. Lisäksi muutimme ohjeita siten, että lisäsimme niihin väliotsikot helpottamaan ja nopeuttamaan oikean tiedon löytymistä (I). 6.2. Mahdolliset ongelmakohdat Testin kulkua haittasi esikatselunäkymän kuvituksen puuttuminen. Kuvittelimme, että esikatselunäkymän sisältö enemmänkin hämäisi testihenkilöä kuin valaisisi tilannetta, sillä se ei kuitenkaan vastaisi täysin käyttäjän tekemiä valintoja. Nyt kuitenkin vaikuttaa siltä, että olimme väärässä. Vaikuttaa siltä, että prototyyppien kaikkien näkymien pitäisi olla sisällöltään viimeisteltyjä. Se, että kerromme mitä jossakin näkymässä näkyisi, ei vastaa testihenkilön omaa havaintoa. Kyselypohjan geneerisyys haittasi myös testiin eläytymistä. Testihenkilön oli vaikea mieltää kysymyspohjaan ilmestyneet kysymykset samoiksi kysymyksiksi, jotka oli juuri itse 22

lisännyt - koska tekstit eivät olleet täysin vastaavat. Tätä on kuitenkin erittäin vaikea korjata. Myös käyttäjän tausta vaikutti testiin, jos hän assaroi parhaillaan jotain tiettyä kurssia, tämän kurssin unohtaminen testin ajaksi tuntui olevan ylivoimaista. Pitäisikö jokaista käyttäjää varten olla etukäteen kustomoitu kysymyspohja? Ongelmakohta on myös tekemämme muutokset. Kurssin puitteissa emme voi suorittaa paperiprotovaihetta oikeaoppisesti eli iteroimalla käyttäjätestien ja muutosten välillä. Vaihtoehdoksi jää ainoastaan oma heuristinen arviointi siitä, millainen prototyypin käytettävyys olisi muutosten jälkeen. Jonkin verran testin kulkuun vaikutti myös se, että olimme tekemässä testiä ensimmäistä kertaa. Emme muun muassa osanneet varautua testin vaatimaan aikaan. Jouduimmekin tämän vuoksi poistamaan yhden aikomistamme testaustavoista (käytettyjen näkymäpolkujen muisteleminen). Onkin aiheellista otaksua, että joitain osa-alueita jäi pimentoon hapuilevien järjestelyjen takia. Tähän kategoriaan kuuluu myös se tosiasia, että kaksi testattavista oli lopulta opintojensa vuoksi käytettävyyteen ja käyttöliittymiin perehtyneitä opiskelijoita. Tosin, haastateltavia valitessa meillä tuli vastaan kurssin ja sopivien haastateltavien aikatauluongelmat. Käytännössä siis tekemiemme muutosten soveltuminen järjestelmään vaatisi iteratiivista panostusta testailun osalta ja mahdollisesti asiantuntijoilla suoritettua heuristista arviointia kokonaiskuvan saamiseksi. 6.3. Arvio kokonaiskäytettävyydestä Prototyypin kokonaiskäytettävyyden arvioimiseen meillä oli siis pohjana kolme käyttäjätestiä. Testit kokonaisuudessaan tuntuivat sujuvan, suuri ongelma oli tosin Kyselyn muokkaus näkymässä (kuva 3) oleva Tee loppukysely -nappi. Testien perusteella teimme protoon muutoksia (mm. Tee loppukysely -napin poisto), joiden uskoimme helpottavan järjestelmän käyttöä kokonaisuutena. Täyttä varmuutta muutosten onnistumisesta emme tietenkään voi saada, mutta mm. Nielsenin heurististen sääntöjen valossa tuntuisi uusi prototyyppi kattavan kaikki kohdat enemmän tai vähemmän menestyksekkäästi. Nielsenin säännöistä olikin erityisesti apua juuri kokonaisuuden hahmottamisessa nappien asemoinnissa, palautedialogien tekemisessä sekä muissa yleisissä linjavedoissa. Tällä hetkellä prototyyppi noudattaa mielestämme yhtenäistä linjaa erilaisten symbolien ja asemointien suhteen. Siinä pitäisi olla myös karsittu ylimääräiseltä tuntuvia osioita vähemmäksi, jotta käyttäjän fokusta voitaisiin paremmin ohjata näkymissä ja siten selkeyttää tehtäväpolkujen rakennetta. Yleisesti voisikin sanoa, että häiritseviä elementtejä on vähennetty ja erilaisten nappien yms. sijoittelua yhtenäistetty, kokonaiskäytettävyyden parantamiseksi. Käyttäjien pitäisi nyt pystyä suoriutumaan omin neuvoin eteentulevista käyttötarpeista. Tarvitaan kuitenkin lisää testejä, että varmuudella voitaisiin todeta tämän väitteen toteutuminen. 6.4. Suositukset jatkotestaamiseen Paperiprototyypin pitää olla riittävän viimeistelty. Liika yksityiskohtaisuus ei ole tarpeen, mutta mitä vähemmän voi jättää selittämisen varaan, sen parempi käyttäjän keskittymisen kannalta. Olisi myös hyvä tehdä jokaisesta linkistä vähintään yksinäkymä eteenpäin siitä huolimatta, että testaisi vain tietyn toiminnon helppoutta. Kyseessä olevan prototyypin kohdalla olisi vielä hyvä testata Kyselypohjaan tekemiämme muutoksia eli kyselyn valintadialogin käyttöä ja kysymysten luomista. (Muutimme hieman 23

luotujen kysymysten ja Luo kysymys -napin asemointia, jotta niiden tehtävä kävisi paremmin selville.) Myös muistettavuutta olisi syytä testata paremmin. Näistä testeistä jouduimme ne poistamaan ajanpuutteen vuoksi (Kappale 3.2.2) Testeistä puuttui myös täysin kysymysvaraston käyttötestit, ja vaikka olemme määritelleet ne muistuttamaan Windows-käyttöjärjestelmästä tuttuja vastaavia toimintoja, voi toiminnon käyttöympäristö asettaa toisenlaisia, ennakoimattomia odotuksia. 24

7. Lähteet Kurssin opetusmonisteet. 25

8. Liitteet 8.1. Liite 1: symbolitesti 26

8.2. Liite 2: navigaatiokartta 27

28