Nopein tapa viedä projekti maaliin: testaa käytettävyys ennen koodausta

Jos taas käytettävyyttä testataan vasta samaan aikaan koodauksen kanssa (kuten yleensä tehdään), testauksesta saatava palaute tulee liian myöhään. Työ on jo aloitettu, ratkaisut lukittu ja korjaukset muuttuvat kalliiksi muutoksiksi jo-sovittuun budjettiin. Silloin nämä havainnot päätyvät helposti backlogille tarralla “tehdään sitten joskus”. Ja se “joskus” jää yleensä tulematta, koska huomio siirtyy seuraaviin ominaisuuksiin.

Miksi varhainen testaus säästää aikaa ja rahaa?

Suunnitteluvaiheessa korjaus on käytännössä: muokkaa prototyyppiä. Toteutusvaiheessa sama korjaus on: muokkaa koodia, testaa uudelleen, päivitä hyväksynnät ja vie muutos läpi sprintin. Sama havainto on siis myöhemmin moninkertaisesti kalliimpi, ja usein myös hitaampi tehdä, koska se kilpailee toteutuksen ja aikataulun kanssa.

Tähän ryhmäläpikäynti on erittäin tehokas menetelmä: 4–6 käyttäjää käy tärkeimmät käyttötapaukset läpi yhdessä fasilitoidussa sessiossa. Yhdessä 60–90 minuutin tilaisuudessa nousee yleensä nopeasti esiin:

• missä käyttäjät epäröivät tai eksyvät
• mitä he eivät ymmärrä (sanasto, rakenne)
• mitkä kohdat hidastavat tekemistä tai aiheuttavat virheitä

Ja tärkeintä: päätökset voidaan tehdä heti, kun muutos on vielä “piirrä uusiksi”, eikä “refaktoroi”.

Käytettävyysvelka maksetaan aina, rivi vain vaihtelee

Jos löydökset jätetään backlogille, ne eivät katoa. Ne siirtyvät kustannuksiksi muualle.

On valitettavan tuttu tilanne, että testissä tunnistetut puutteet tiedetään, mutta niitä ei toteuteta. Sitten käy niin, että julkaisun jälkeen asiakaspalvelu ruuhkautuu, kun käyttäjät ovat hukassa epäselvässä käyttöliittymässä. Aspa opastaa käyttöä ja vastaa samoihin kysymyksiin päivästä toiseen. Jos löydökset olisi korjattu prototyyppivaiheessa, tätä kuormaa ei olisi syntynyt.

Julkisella sektorilla huono käytettävyys näkyy usein juuri asiakaspalvelun kuormana, koska asiakkaalla ei ole vaihtoehtoa asioinnilleen. Yksityisellä puolella se näkyy katoavana konversiona ja sitoutumisena, koska vaihtoehtoja on aina.

Kun käytettävyys varmistetaan ennen toteutusta, sprintit kuluvat vähemmän korjaamiseen ja enemmän arvoa tuottavaan kehitykseen. Ja ennen kaikkea: projekti etenee nopeammin, koska se ei joudu palaamaan samoihin päätöksiin myöhemmin.

Miksi käytettävyystestaus toimii kehityssprintissä?

Sprintissä käytettävyystestaus toimii hyvin, koska:

• Kaikki näkevät saman ongelman heti. Kun kehitystiimi seuraa käyttäjää livenä, syntyy yhteinen ymmärrys ilman pitkiä raportteja.
• Ratkaisut löytyvät nopeammin. Kehittäjät voivat saman tien arvioida, mikä on helppo korjata nyt ja mikä on liian iso muutos tähän sprinttiin.
• Päätöksenteko nopeutuu. Yhdessä sessiossa yhdistyy käyttäjän kokemus, tekninen toteutettavuus ja liiketoiminnan prioriteetit — ja seuraavat toimenpiteet voidaan sopia heti.