WWW-palveluiden ja sovellusten suunnitteluun sopii erittäin hyvin iteratiivinen tuotekehitysprosessi. Iteratiivisessa prosessissa tuotetta tai palvelua kehitetään ja testataan nopeissa sykleissä.
Arviointimenetelmien perusta
käytettävyyden arviointimenetelmät edellyttävät, että sovelluksen käyttäjäryhmät että käyttäjien tehtävät (jobs, tasks) on tunnistettu ja määritelty. Käyttäjäryhmien tunnistaminen tarkoittaa, että palvelun tulevat käyttäjät on jaettu taustansa tai (työ)tehtäviensä perusteella järkeviin ryhmiin.
Käyttäjäryhmien määrittely tarkoittaa, että tärkeimmiksi tunnistettujen käyttäjäryhmien työtehtävät on analysoitu, ja tärkeimpien tehtävien suorittamiseen vaikuttavat käyttäjien ominaisuudet on analysoitu. Tämä määrittelyvaihe on syytä tehdä mahdollisimman aikaisessa vaiheessa, esimerkiksi uuden tuotteen suunnittelussa ennen vaatimusmäärittelyä tai sen kanssa.
Määrittelyvaiheen tulokset voidaan dokumentoida esimerkiksi käyttäjäkuvauksina tai käyttökertomuksina (skenaarioina).
Heuristinen arviointi
Heuristiset säännöt ovat käytettävyystestien ja käytännön kokemusten kautta saatuja nyrkkisääntöjä, jotka kuvailevat käyttöliittymän toivottavia tai epätoivottavia ominaisuuksia.
Käyttöliittymän heuristinen tarkastelu on menetelmä, jossa käyttöliittymän tai koko sovellukset ominaisuuksia verrataan johonkin heuristiseen listaan. Jos käyttöliittymän jokin kohta poikkeaa esitetystä hyvästä ominaisuudesta tai sisältää esitetyn huonon ominaisuuden, tehdään tästä merkintä. Läpikäynnin tuloksena saadaan lista sovelluksen ominaisuuksista, jotka saattavat aiheuttaa käytettävyysongelmia. Hyvä heuristiset ohjeet löytyvät osoitteesta http://www.useit.com/papers/heuristic/heuristic_list.html ja näiden ohjeiden WWW-lisäyksiä: http://www.webreview.com/1997/10_10/strategists/10_10_97_2.shtml.
Navigointikartta
Navigointikartta on verrattavissa palvelusta esitettyyn hierarkkiseen kuvaukseen. Navigointikartassa oleellista on, että jokaisesta esitetystä näkymästä (WWW-sivusta) näytetään sellainen näkymä, kuin käyttäjällä (suurin piirtein) on. Tärkeitä ominaisuuksia ovat elementtien koko- ja etäsyyssuhteet, sekä navigointiin käytettyjen elementtien ulkonäkö ja nimet tai muut merkityksiä välittävät ominaisuudet (koko, värit, muodot, animointi, teksti, positio).
Jokaisen käsitellyn sivun jokaisesta navigointielementistä piirretään nuoli, jonka päässä on kuvaus siitä mitä käyttäjä näkee jos klikkaisi kyseistä elementtiä.
Kartta voidaan piirtää myös osasovelluksesta, esimerkiksi jonkin uuden ominaisuuden käyttöönotosta, ensimmäisestä käyttökerrasta tai usein toistuvasta tehtävästä. Tällöin oletusreitti merkitään hieman tummemmilla nuolilla, ja tarkastelu kiinnitetään mahdollisesti harhaan tai epäsuoralle reitille johtaviin ominaisuuksiin.
Tämän menetelmän käyttäminen edellyttää laatijalta tietoa käyttäjien taustasta, käyttöympäristöstä, tehtävistä joita sovelluksesta tehdään sekä tietoa kognitiivisten seikkojen vaikutuksista.
Käyttäjän huomioonottaminen
Käyttäjien kanssa suoritettavassa testissä on oleellista, että käyttäjille esitetään lopullisen materiaalin näköisiä kuvauksia käyttöliittymästä. Testaustilanteessa käyttäjälle kerrotaan, että tarkoituksena on selvittää miten testattava tuote toimii käyttäjän kannalta. Jos käyttäjää pyydetään tekemään jotain tehtävää prototyypillä tai valmiilla tuotteella, pyydetään käyttäjää ajattelemaan ääneen, eli kertomaan mitä on tekemässä, mitä mieltä on mistäkin kohdasta. Käyttäjää pyydetään myös kertomaan, jos jokin asia on hänen mielestään omituinen tai epäilyttävä.
Käyttäjälle esitettävät testitarinat, kysymykset ja tehtävät esitetään selkeällä yleiskielellä (tai käyttäjän ammattislangilla, jos sen oikeellisuus pystytään etukäteen varmistamaan). Testitarinoissa ja tehtävissä tulee kiinnittää erityistä huomiota siihen, että ei käytetä testattavasta järjestelmästä peräisin olevia nimityksiä (mieluummin vaikkapa synonyymejä) eikä testinohjaajan omaa ammattislangia (useat käyttäjät eivät erota www:tä ja Internetiä toisistaan, eivät tiedä mikä on linkki, tekstikenttä, tietokanta, serveri, proxy, java).
Kun käyttäjälle on esitetty tehtävä, tai häntä on pyydetty tekemään jotain, annetaan hänen tehdä asia rauhassa. Jos käyttäjä ei ajattele luontevasti ääneen, kannattaa häntä pyytää (kerran, ehkä kaksi) tekemään niin, esimerkiksi kysymysten muodossa: “Kerrotko minulle mitä olet tekemässä nyt” Käyttäjän annetaan tehdä se mitä hän on tekemässä vaikuttamatta siihen. Jos käyttäjä kysyy jotain, tai hänelle tulee ylipääsemättömiä ongelmia, autetaan häntä juuri sen verran että hän pääsee ongelmakohdasta eteenpäin. Tehtävän tai tehtävien jälkeen käyttäjältä voidaan kysyä mitä hän piti tuotteesta, onko käyttänyt samanlaisia tai parempia / huonompia tuotteita. Samalla voidaan kysyä asioita, jotka käyttötilanteen aikana jäivät testin ohjaajalle epäselväksi, esimerkiksi olisiko käyttäjä olettanut etsimälleen asialle jonkin toisen nimen, tai minkälaista ilmoitusta hän olisi odottanut järjestelmältä painikkeen painamisen jälkeen. Testitilanteen jälkeen käyttäjää kiitetään osallistumisesta. Jos on mahdollista, voidaan käyttäjälle antaa kiitokseksi käytetystä ajasta esimerkiksi pieni liikelahja.
Prototypisointitavat
Prototyypit jaetaan kahteen ryhmään: Lo-fi ja Hi-fi -prototyypit. Lo-fi prototyypit ovat nopeasti tehtyjä, toiminnallisuutta yleensä sisältämättömiä prototyyppejä. WWW-palvelun tai sovelluksen tapauksessa se tarkoittaisi paperille tulostettua kuvaa sovelluksen ikkunasta, tai sellaista WWW-sivua (HTML-dokumenttia) joka voidaan ladata (määrittelyineen) selaimelle, mutta jota ei varsinaisesti voi käyttää.
Hi-fi prototyypit sisältävät jonkinlaista (simuloitua) toiminnallisuutta, niitä voidaan “käyttää” siinä ympäristössä jossa lopullista tuotetta tullaan käyttämään. WWW- ympäristössä se tarkoittaa esimerkiksi HTML-kuvauskielellä toteutettua käyttöliittymää, jossa testauksen kannalta tärkeimpiä osuuksia voidaan “käyttää”. Toteutuksen ei tarvitse sisältää minkäänlaista dynaamista toiminnallisuutta, se voi perustua tiukalle testitarinalle, jolloin oikean painikkeen klikkaamisen jälkeen ladataan toinen sivu kuin aiemmin.
Lo-fi testeissä saadaan kuvauksia tavoista, joilla käyttäjä toivoisi tai olettaisi sovelluksen toimivan. Tätä tietoa voidaan käyttää joko laatimalla sovellus niin että se vastaa toiveisiin, tai antamalla selkeä palaute ja opastus luultavasti yllättävissä kohdissa.
Sotkettu kuva ja teksti (Lo-fi)
Esimerkiksi uuden WWW-palvelun pääsivua tai paljon käytettyä sivupohjan sommitelmaa voidaan testata, tai erilaisia vaihtoehtoja voidaan vertailla, käyttämällä sotkettua tekstiä ja kuvaa sisältäviä tulosteita.
Tekstin sotkeminen tehdään muuttamalla teksti lukukelvottomaksi vaihtamalla kirjaimia keskenään. Lauseiden pituudet, pisteet, SUURAAKKOSET säilytetään niille lauseopin tai merkityksen kannalta oikeilla paikoillaan, mutta kirjaimet vaihdetaan toisiksi. Kuvia sotketaan niin paljon, että esimerkiksi ihmisiä esittävästä kuvasta voi edelleen todeta sen esittävän ihmisiä, mutta henkilön tunnistaminen kuvasta olisi mahdotonta.
Käyttäjiä pyydetään kertomaan
- millaisen palvelun he arvelevat olevan kyseessä
- mitä asioita he sivulla olettavat olevan
- mitkä asiat mahdollisesti vaikuttavat mihin asioihin.
Tämän jälkeen käyttäjille voidaan esittää (pääkohdittain laadittu) lista sivun sisältämistä osista, ja pyytää käyttäjiä osoittamaan nämä osat sivulta. Esimerkiksi suuren yrityksen Intranet-sivulla komponentit voisivat olla
- muiden oman yrityksen sivukokonaisuuksien välillä liikkuminen
- yhteistyökumppaneiden sivut
- tiedon haku.
Testin suorittamisessa voidaan käyttää esimerkiksi käyttäjää kohti yhtä paperikopiota jolle käyttäjä merkitsee vastauksensa ensimmäisessä vaiheessa mustalla ja toisessa vihreällä kynällä.
Tuloksena saadaan käyttäjien aavistuksia sivun toiminnallisuudesta ja sisällöstä. Nämä aavistukset perustuvat käyttäjien aikaisemmille kokemuksille, ja helpottavat (uudet) palvelun oppimista.
Normaalit paperikopiot (Lo-fi)
Myös tavallisia paperikopioita WWW-järjestelmän sivuista tai niiden suunnitelmista voidaan käyttää testaukseen. Tällöin voidaan testata joko jostain päänäkymästä navigoimista (terminologiaa), tai jotain tärkeää tai usein toistuvaa toimintoketjua. Navigoimisen testaamisessa menetellään kuten yllä. Tässä tapauksessa tietoa saadaan valittujen sanojen sopimisesta käyttäjän tottumuksiin ja tehtäviin, ja huomio keskittyy enemmän sisällön mielenkiintoisuuteen kuin käytettävyyteen.
Tehtävän tekemisessä käyttäjälle kerrotaan taustatarina, joka kuvaa käyttäjälle käyttäjän sanoin missä tilanteessa hän on käyttämässä sovellusta, sekä jonkin asian jota hän haluaa sovelluksen käytöllä saavuttaa. Tämän jälkeen käyttäjälle esitetään yksi sivu kerrallaan näkymiä joita hän saa, ja häntä pyydetään käyttämään paperikopiota kun käyttäisi oikeaa sovellusta (esimerkiksi kirjoittamalla tekstikenttiin kynällä sen mitä muuten kirjoittaisi näppäimistöllä, kertomaan milloin klikkaisi missäkin hiirellä (yksi- vai kaksoisklikkaus), mihin kohtiin liikkuisi nuolinäppäimillä tai tabulaattorilla.
Testauksessa on syytä olla muutamia kopioita tärkeistä näkymistä, jotta voidaan simuloida esimerkiksi mahdolliset virheilmoitukset ja niistä eteneminen.
Tuloksena saadaan kuvauksia siitä, miten käyttäjä olettaisi sovelluksen toimivan, millä tavalla hän täyttäisi kentät (päivämäärät, jokeri- eli korvausmerkit, hakusanat), tietoa oletetuista tavoista ilmoittaa pakollinen tieto.
Dummy-testaus (Hi-fi)
Tärkeitä tehtäviä, navigoimista, palvelusta saatavaa palautetta voidaan testata rakentamalla palvelusta nopea prototyyppi. Prototyypin tulee sisältää samanlaisia muotoilukomentoja kuin valmiin tuotteen koodinkin. Prototyypissä ei tarvitse olla mitään tietokantatoiminnallisuutta, mutta sen tulee käyttäytyä (käyttäjälle) kuin sillä olisi.
Serverin tuottamaa tekstiä voidaan simuloida sopivalla taajuudella animoiduilla kuvilla. Vuorovaikutusta voidaan simuloida siirtymällä tietyn painikkeen painamisen jälkeen uudenlaisiin sivuihin.
Tällaisenkin prototyypin testausta varten laaditaan taustakertomus sekä tehtävä tai tehtäviä. Tyypillisesti prototyypeillä testataan käyttöönoton kannalta tärkeää vaihetta tai toistuvaa toimenpidettä. Testin kohteena voi olla myös navigoiminen.
Testin kulku kannattaa nauhoittaa (jos käytössä on videokamera, kuvataan sillä kuvaruudun tapahtumia). Jos nauhoittaminen ei ole mahdollista, voidaan käyttötilanteesta tehdä muistiinpanoja. Tällöin on syytä varustautua etukäteen tarkastuslistalla johon voidaan nopeasti täydentää parilla sanalla tapahtumat. Tapahtumat on syytä kirjoittaa puhtaaksi heti testitilanteen jälkeen, muuten ne unohtuvat. Jos palvelua käytetään serveriltä, voi klikattujen linkkien nimilistasta (aikajärjestyksessä) olla apua muistamisen kannalta.
Tuloksena saadaan selville tuotteen sopiminen käyttöympäristöön (ruudun koko, värien asetukset, suosittu ikkunakoko), erilaisia käyttötottumuksia, tietoa järjestelmän antaman palautteen riittävyydestä ja ohjaavuudesta. Menetelmä ei anna tietoa vasteajoista, koetusta nopeudesta.
Valmiin tuotteen testaus, toiminnallisen tuotteen testaus
Valmista tuotetta, kilpailijan tuotetta voidaan testata samalla tavalla kuin prototyyppiä.
Valmiin tuotteen testaamisessa voidaan käyttää avoimia kysymyksiä. Ne kuvaavat etenkin kaikille avoimien Internetpalveluiden käyttöä osana laajempaa kokonaisuutta (koko internet). Testit olisi syytä tehdä aina käyttäjän omassa ympäristössä (työpaikalla, kotona), jolloin saadaan näkyville käyttäjälle luonnollisia tiedonhakustrategioita, käyttötapoja ja tottumuksia.
On kuitenkin huolehdittava siitä, että sovelluksen tietokantaan ei jää materiaalia tai merkintöjä, joista voisi olla käyttäjälle jonkinlaista vaivaa tai vahinkoa (tilauksia, merkintöjä käynneistä). WWW-selain kirjanmerkintöineen, vierailtuine linkkeineen ja koko tietokoneen kuvaruutu ovat heijastumaa käyttäjän henkilökohtaisesta työtilasta, joten kaikki kerätty materiaali on säilytettävä luottamuksellisena testin tekijän ja käyttäjän välillä. Tulokset on anonymisoitava riittävän tehokkaasti. Jos käyttäjän intimiteetin säilymistä tai jatkossa tapahtuvan toiminnan miellyttävyyttä käyttäjälle ei voida taata, tulee käyttää paperikopioita. Jennifer Flemingin erinomainen artikkeli testauksen järjestämisestä on osoitteessa http://www.ahref.com/guides/design/199806/0615jef.html.