Käytettävyystestauksella on ansaitsematon maine kalliista ja hitaasta. Kun ihmiset kuulevat "käyttäjätutkimusta", he kuvittelevat ykssuuntaisen peilin, moderaattorin leijallaan ja kahden viikon aikataulu. Tämä version testaus olemassa ja sillä on käyttöään — mutta se ei ole versio, jota useimmat tuottimet tarvitsevat eniten aikaa.
Versio, jota useimmat tiimit tarvitsevat, on yksinkertaisempi: viisi käyttäjää, Figma-prototyypin tai valmistelun ympäristö, videosoitto ja 45 minuuttia istunto. Hyvin tehdyn avulla tämä paljastaa enemmistön vakavista käytettävyysongelmista ennen toimittamista. Jatkuvasti tehdyn — jopa kerran sprintin — se tuottaa tuotteen laadun kumulatiivisen parantamisen, jota analytiikka ei voi toistaa.
Näin sitä käytetään alusta.
Viisi osallistujaa on oikea numero useimmille käytettävyystestille. Jakob Nielsenin tutkimus osoitti, että viisi käyttäjää paljastaa noin 85% käytettävyysongelmista, jolla on pienenevä tuotto sen jälkeen. Kolmen istunnon johtaminen viidestä käyttäjästä suunnitteluprosessin eri kohdissa on arvokkaampaa kuin yksi istunto viidellätoista.
Rekrytoinnin kriteerit ovat tärkeämpiä kuin numero. Käytettävyystesti viiden henkilön kanssa, jotka vastaavat tiiviisti kohdepersonaasi, paljastaa todelliset ongelmat. Testaus viidellätoista henkilöllä, jotka eivät vastaa, tuottaa melua. Määritä kaksi tai kolme seulontakriteerit — rooli, käytön konteksti, teknisen mukavuuden taso — ja pidä niihin.
Nopein rekrytointipolku useimmille tiimeille on sähköpostilla olemassa olevien käyttäjien kanssa, jotka ovat antaneet yhteydenottoluvun. Tarjoa vaatimaton kannustin — 20 £ lahjakortti riittää 45 minuutin istunnoksi. Tavoitteena on ajoittaa istunnot saman viikon kuluessa; mitä pidempi väli rekrytoinnin ja testauksen välillä, sitä korkeampi peruutusaste.
Yleisin käsikirjoitusvirhe on tehtävien kirjoittaminen ohjeiksi: "Napsauta Asetukset, sitten siirry Ilmoituksiin ja muuta vaihtoehtoasi..." Tämä kertoo käyttäjälle mitä tehdä, mikä tarkoittaa, että testaat voivatko he noudattaa ohjeita, eivät onko liittymä intuitiivinen.
Kirjoita tehtävät skenaarioiksi: "Kuvittele, että saat liian monta ilmoitusta ja haluat vastaanottaa hälytyksiä vain silloin, kun joku mainitsee sinut suoraan. Näytä minulle, mitä tekisit." Tämä antaa käyttäjälle realistisen tavoitteen ja antaa sinulle mahdollisuuden havaita, kuinka he todella navigoivat — mukaan lukien kohdat, joissa he sekaantuvat.
Vaikein osa käytettävyystestin moderaattoria on vastustaa yleistä halua auttaa. Kun käyttäjä on sekaantunut, jokainen vaisto sanoo hypätä sisään ja näyttää heille minne napsauttaa. Mutta sekaannus on data. Käyttäjä, joka kamppailee, kertoo sinulle, että liittymässä on jotain väärää — ja sillä hetkellä, kun sekaannus, menetät signaalin.
Pyydä käyttäjiltä ajatella ääneen istunnon aikana: "Kun menet eteenpäin, kerro minulle mitä katsot ja mitä ajattelet." Tämä tuottaa jatkuvan tietovuon heidän mentaalimallista. Huomaa paitsi virheet myös epärönnit — käyttäjä, joka pysähtyy kolmeksi sekunniksi ennen oikean painikkeen napsauttamista, on silti paljastanut suunnitteluongelman, vaikka he lopulta onnistuivat.
Synteesivaihe on siellä, missä suurin osa arvosta luodaan — ja jossa useimmat tiimit leikkaavat kulmat. Raakatiedot viidestä istunnosta eivät ole löydöksiä. Niistä tulee löydöksiä, kun debriefitat tiimina, ryhmitä havainnot teemalla ja määrität vakavuusarviot.
Tee debriefing samana päivänä istuntojen kanssa, kun havainnot ovat tuoreita. Ryhmäongelmat kolmeen ämpäriin: kriittinen (käyttäjät eivät voineet suorittaa tehtävää), kohtalainen (käyttäjät suorittivat tehtävän mutta merkittävällä vaikeudella tai virheellä) ja vähäpätöinen (kitka, joka ei estänyt suorittamista). Kriittiset ongelmat on korjattava ennen julkaisua. Kohtalaisia ongelmia pitäisi priorisoida seuraavassa sprintissä. Vähäpätöiset ongelmat menevät ruusukkeeseen.
Kirjoita tulokset yhdelle sivulle: kolme parhaista kriittistä ongelmaa, näytöllä vähintään kahdesta osallistujasta ja ehdotettu muutos kullekin. Kaikki, joka tarvitsee enemmän tilaa, kuuluu erilliseen asiakirjaan.