Käytettävyystestauksella on ansaitsematon maine kalliina ja hitaana. Kun ihmiset kuulevat sanat ”käyttäjätutkimus”, he kuvittelevat yksisuuntaisen peilin, lehtiötä pitelevän haastattelijan ja kahden viikon aikataulun. Tällaista testausta on olemassa ja sille on käyttötarkoituksensa, mutta se ei ole se versio, jota useimmat tuotetiimit tarvitsevat suurimman osan ajasta.
Useimpien tiimien tarvitsema versio on yksinkertaisempi: viisi käyttäjää, Figma-prototyyppi tai testiympäristö, videopuhelu ja 45 minuuttia per istunto. Hyvin tehtynä tämä paljastaa suurimman osan vakavista käytettävyysongelmista ennen julkaisua. Johdonmukaisesti tehtynä, vaikka kerran sprintissä, se parantaa tuotteen laatua kumulatiivisesti tavalla, jota mikään julkaisun jälkeinen analytiikka ei pysty toistamaan.
Näin sen toteuttaa alusta alkaen.
Viisi osallistujaa on oikea määrä useimpiin käytettävyystesteihin. Jakob Nielsenin tutkimus osoitti, että viisi käyttäjää paljastaa noin 85 % käytettävyysongelmista ja että sen jälkeen lisähyöty pienenee. Kolme viiden käyttäjän istuntoa suunnitteluprosessin eri vaiheissa on arvokkaampi kuin yksi viidentoista käyttäjän istunto.
Rekrytointikriteerit ovat määrää tärkeämpiä. Käytettävyystesti viidellä henkilöllä, jotka vastaavat tarkasti kohdekäyttäjääsi, paljastaa todelliset ongelmat. Testi viidellätoista henkilöllä, jotka eivät vastaa, tuottaa kohinaa. Määritä kaksi tai kolme seulontakriteeriä, kuten rooli, käyttökonteksti ja tekninen osaaminen, ja pidä niistä kiinni.
Useimmille tiimeille nopein rekrytointitapa on lähettää sähköpostia nykyisille käyttäjille, jotka ovat antaneet yhteydenottoluvan. Tarjoa vaatimaton kannustin: 20 £:n lahjakortti riittää 45 minuutin istunnosta. Pyri ajoittamaan istunnot saman viikon sisälle; mitä pidempi väli rekrytoinnin ja testauksen välillä on, sitä suurempi on paikalta poisjääneiden osuus.
Yleisin käsikirjoitusvirhe on kirjoittaa tehtävät ohjeiksi: ”Napsauta Asetuksia, siirry kohtaan Ilmoitukset ja muuta valintasi...” Tämä kertoo käyttäjälle, mitä tehdä, jolloin testaat sitä, osaako hän seurata ohjeita, ei sitä, onko käyttöliittymä intuitiivinen.
Kirjoita tehtävät sen sijaan skenaarioiksi: ”Kuvittele, että olet saanut liikaa ilmoituksia ja haluat saada hälytyksen vain, kun joku mainitsee sinut suoraan. Näytä minulle, mitä tekisit.” Tämä antaa käyttäjälle realistisen tavoitteen ja antaa sinun havainnoida, miten hän todella navigoi, myös kohdissa, joissa hän hämmentyy.
Käytettävyystestin ohjaamisessa vaikeinta on vastustaa halua auttaa. Kun käyttäjä on hämmentynyt, jokainen vaisto käskee hypätä väliin ja näyttää, mihin kohtaan pitää klikata. Mutta hämmennys on dataa. Kamppaileva käyttäjä kertoo, että käyttöliittymässä on jotain vialla, ja heti kun puutut asiaan, menetät signaalin.
Pyydä käyttäjiä ajattelemaan ääneen koko istunnon ajan: ”Kerro etenemisen aikana, mitä katsot ja mitä ajattelet.” Näin saat jatkuvan tietovirran heidän mentaalimallistaan. Kirjaa ylös virheiden lisäksi epäröinti: käyttäjä, joka pysähtyy kolmeksi sekunniksi ennen oikean painikkeen napsauttamista, on silti paljastanut suunnitteluongelman, vaikka lopulta onnistuikin.
Synteesivaiheessa syntyy suurin osa arvosta, ja siinä useimmat tiimit oikaisevat. Viiden istunnon raakamuistiinpanot eivät ole löydöksiä. Niistä tulee löydöksiä, kun pidätte tiiminä purun, ryhmittelette havainnot teemoittain ja annatte niille vakavuusluokituksen.
Pidä purku samana päivänä kuin istunnot, kun havainnot ovat tuoreita. Ryhmittele ongelmat kolmeen luokkaan: kriittinen (käyttäjät eivät pystyneet suorittamaan tehtävää), kohtalainen (käyttäjät suorittivat tehtävän, mutta merkittävien vaikeuksien tai virheiden kanssa) ja vähäinen (kitka, joka ei estänyt tehtävän suorittamista). Kriittiset ongelmat on korjattava ennen julkaisua. Kohtalaiset ongelmat kannattaa priorisoida seuraavaan sprinttiin. Vähäiset ongelmat menevät backlogiin.
Kirjoita löydökset yhdelle sivulle: kolme tärkeintä kriittistä ongelmaa, kustakin todisteet vähintään kahdelta osallistujalta ja ehdotettu suunnittelumuutos kuhunkin. Kaikki, mikä vaatii enemmän tilaa, kuuluu erilliseen dokumenttiin.