Käytettävyystestaus

Käytettävyystestaus on tutkimusmenetelmä, jossa todelliset tai edustavat käyttäjät yrittävät suorittaa tiettyjä tehtäviä käyttämällä tuotetta, prototyyppiä tai verkkosivustoa, samalla kun tarkkailija kirjaa ylös, missä he onnistuvat, missä heillä on vaikeuksia ja miten he kuvailevat kokemustaan, tyypillisesti ajattelemalla ääneen työskennellessään. Toisin kuin kyselyt tai analytiikka, jotka raportoivat, mitä käyttäjät tekivät tai sanoivat jälkikäteen, käytettävyystestaus tarkkailee käyttäytymistä suoraan ja kontekstissa, mikä tekee siitä yhden suorimmista tavoista tunnistaa, onko käyttöliittymä todella helppo ymmärtää ja käyttää, eikä sitä vain oleta rakentaneen tiimin olevan sellainen.

Menetelmällä on merkitystä, koska käyttöliittymäongelmat, jotka ovat näkymättömiä niiden suunnittelijoille, ovat usein ilmeisiä ensikertalaisille. Tätä kuilua selitetään usein tiedon kirouksella, jossa tuotteeseen syvällisesti perehtyneet suunnittelijat ja sidosryhmät kamppailevat uuden käyttäjän välittömästi kohtaamien monitulkintaisten asioiden havaitsemisen kanssa. Laajasti siteeratut käytettävyystutkimukset ovat osoittaneet, että jopa viiden osallistujan testaaminen paljastaa tyypillisesti suuren enemmistön, usein mainittuna noin 85 prosenttia, tietyssä käyttöliittymässä esiintyvistä käytettävyysongelmista. Siksi käytettävyystestaus suoritetaan yleensä pienillä, iteratiivisilla osallistujakierroksilla laajojen tutkimusten sijaan, jolloin tiimit voivat testata, korjata ja testata uudelleen nopeasti sen sijaan, että odottaisivat suuren otoksen keräämistä ennen muutosten tekemistä.

Käytettävyystestausta suoritetaan useissa eri muodoissa: moderoitu testaus, jossa fasilitaattori opastaa osallistujaa tehtävien läpi reaaliajassa joko henkilökohtaisesti tai videon välityksellä ja voi esittää jatkokysymyksiä hämmentävien hetkien selventämiseksi; moderoimaton etätestaus, jossa osallistujat suorittavat tehtäviä itsenäisesti testausalustalla, ja heidän näyttönsä ja äänensä tallennetaan myöhempää tarkastelua varten. Tämä tarjoaa nopeamman ja edullisemman tiedonkeruun, mutta ei pysty analysoimaan reaktioita hetkessä; ja sissitestaus, epävirallinen ja edullinen lähestymistapa, jossa kerätään nopeaa palautetta saatavilla olevilta osallistujilta, kuten kollegoilta tai ohikulkijoilta, mikä on hyödyllistä varhaisessa vaiheessa validoinnissa, kun täydellistä tutkimusta ei vielä tarvita. Testitilaisuudet on tyypillisesti rakennettu tiettyjen, realististen tehtäväskenaarioiden ympärille avoimen tutkimisen sijaan, ja onnistumista arvioidaan mittareilla, kuten tehtävän suoritusaste, tehtävään käytetty aika, virheiden määrä ja osallistujan subjektiivinen helppokäyttöisyysluokitus, joka usein kerätään standardoidulla välineellä, kuten järjestelmän käytettävyysasteikolla.

Yleinen väärinkäsitys on, että käytettävyystestaus ja A/B-testaus palvelevat samaa tarkoitusta, vaikka ne itse asiassa vastaavat eri kysymyksiin eri vaiheissa: käytettävyystestaus tunnistaa, miksi käyttäjät kamppailevat käyttöliittymän kanssa ennen kuin se on rakennettu tai julkaistu laajasti, tyypillisesti prototyypin tai jo julkaistun, mutta validoimattoman suunnittelun pohjalta, kun taas A/B-testaus mittaa, mikä useista jo rakennetuista varianteista toimii paremmin skaalautuvasti, kun liikennettä on saatavilla. Yleinen sudenkuoppa käytettävyystestauksessa itsessään on sellaisten osallistujien rekrytointi, jotka eivät edusta todellista kohdeyleisöä, kuten yritysohjelmiston työnkulun testaaminen osallistujien kanssa, jotka eivät tunne taustalla olevaa liiketoimintaprosessia. Tämä tuottaa harhaanjohtavia kitkapisteitä, joita ei ilmenisi aitojen kohdekäyttäjien kanssa. Toinen yleinen virhe, joka heikentää havaintojen pätevyyttä, on osallistujien johdattaminen vinkeillä tai ehdotuksilla istunnon aikana sen sijaan, että heidän annettaisiin kamppailla itse ja heitä tarkkailtaisiin rehellisesti.

CRO:n sisällä ja UX Konsultointitehtävissä käytettävyystestausta käytetään usein sekä diagnostiikkaan, jotta ymmärrettäisiin, miksi olemassa oleva työnkulku toimii heikosti, että validointiin ennen uudelleensuunnittelun laajaa julkaisua. Testataan uutta prototyyppiä pienellä edustavien käyttäjien ryhmällä merkittävien käytettävyysongelmien havaitsemiseksi ennen kehitys- ja testausresurssien osoittamista täydelliseen A/B-testiin. Käytettävyystestauksen tulokset syntetisoidaan tyypillisesti priorisoituun ongelmaluetteloon, joka usein luokitellaan vakavuuden ja osallistujien kohtaaman ongelman mukaan. Tämä luettelo syötetään sitten suoraan suunnittelumuutoksiin tai kokeiluhypoteeseihin, jotka muodostavat asiakkaan laajemman optimointisuunnitelman.

Konkreettinen esimerkki havainnollistaa menetelmän tehokkuutta: viiden osallistujan kanssa uudelleensuunniteltua tiliasetussivua testaava tiimi saattaa havaita, että neljä viidestä ei löydä vaihtoehtoa ilmoitusasetustensa muuttamiseksi, vaan kukin itsenäisesti etsii samasta väärästä kohdasta käyttöliittymässä. Tämä yksittäinen, erittäin johdonmukainen havainto, joka saatiin pienestä ja edullisesta testauskierroksesta, on tyypillisesti riittävä peruste asetuksen siirtämiselle ennen julkaisua ilman, että tarvitaan suurempaa ja aikaa vievämpää tutkimusta sen vahvistamiseksi, minkä on jo havaittu epäonnistuvan luotettavasti ja toistuvasti lähes kaikilla testatuilla osallistujilla.