Oletko miettinyt joskus tällaisia asioita, kun kehität sovellusta tai verkkosivustoa ja harkitset palautteen kysymistä työkavereilta tai käyttäjiltä:
– en ole vielä itsekään tyytyväinen niin en vielä kysy palautetta muilta
– työlistalla on jo niin paljon pieniä muutoshommia, että en halua kaiken lisäksi uutta listaa palautteenantajilta
– työ on jo liian pitkällä, että kannattaisi/ehtisi/viitsisi tehdä muutoksia palautteen perusteella.
Onneksi olkoon! Olet erittäin fiksu. Erotut massasta, kun olet edes tullut harkinneeksi sitä, että käyttäjiä voi jotenkin osallistaa kehitystyöhön. Kerron sinulle muutaman vinkin, miten käytettävyystutkimusta voi hienosäätää, niin että lopputuloksena ei ole ärsyttävä to do -lista vaan oikeasti työtäsi helpottavia näkemyksiä.
Eri tilanteisiin on eri tavat ja oikeastaan milloin tahansa on oikea aika tehdä käytettävyystyötä.
En ole vielä itse tyytyväinen
Mihin et ole tyytyväinen? Onko nappi väärässä paikassa? Onko asettelu sikin sokin? Puuttuuko jokin ominaisuus? Tee käyttöliittymästä uusi versio muutamassa minuutissa esimerkiksi Paint-sovelluksella tai piirtämällä käsin paperille. Säästyt isolta vaivalta, kun et hifistele kammiossasi täydellistä lopputulosta vaan menet käyttäjän tai kollegan puheille mahdollisimman raa’an version kanssa. Älä kysy: ”mitä tykkäät tästä käyttöliittymästä?” vaan kysy jokin tarkempi kysymys, joka liittyy sovelluksen tarkoitukseen, kuten ”mistä klikkaisit, jos haluat vaihtaa profiilikuvaasi?”
Olennaista on siis kysymyksen asettelu. Hyvällä kysymyksellä saat selville, osaako käyttäjä käyttää sovellusta siihen, mihin se on tarkoitettu. Saat nopeasti tehdyn prototyypin avulla olennaisen palautteen, jonka avulla voit sitten hienosäätää kun hienostelun aika on.
Tällaisella kolmessa minuutissa kyhätyllä paperiprototyypillä voit jo kysyä muilta palautetta, vaikka et ole koodannut sekuntiakaan. Kysy esimerkiksi: ”Mitä tekisit, jos haluat lisätä tuotteen ostoskoriin?”
To do -lista on jo valmiiksi liian pitkä
Tämä lienee jokaisen tietokonetyöläisen perusongelma. Jos työlistan vilkaisukin lyhistää hartiat, niin keskity käyttäjätiedossa priorisointiavun saamiseen. Tee pikainen kysely käyttäjille suunnilleen näin: ”Olemme kehittämässä sovellusta ja lisäämme siihen uusia ominaisuuksia. Auttaisitko meitä kertomalla, mikä alla olevista ominaisuuksista olisi sinulle hyödyllisin.”
Käyttäjiltä ei ole aina pakko haalia listaa ongelmista vaan he voivat auttaa myös huomaamaan, mitkä asiat ovat tärkeitä ja mitkä turhia.
Työ on jo liian pitkällä
Jos et ole vielä missään aikaisemmassa vaiheessa osallistanut käyttäjiä, niin tee se viimeistään edes ennen julkaisua. Julkaisun jälkeen palautetta tulee kuitenkin. Se voi olla negatiivista, positiivista, rakentavaa tai jotain sekalaista. Joka tapauksessa tämä palaute on järkevää ottaa pieneltä testikäyttäjäryhmältä eikä koko maailmalta. Positiivisen palautteen voit hyödyntää markkinoinnissa ja rakentavampiin voit vielä puuttua ennen kuin suuri yleisö antaa tuomionsa.
Vaikka käyttäjäpalaute saattaa aiheuttaa työtä loppukirivaiheeseen, selviät tästä työstä paljon vähemmällä ennen julkaisua kuin sen jälkeen. Jälkikäteen sinun on varsinaisen muutostyön lisäksi käsiteltävä paljon isompi määrä palautteita, viestittävä tulevista muutoksista jo saavutetulle käyttäjäjoukolle ja huonossa tapauksessa koulutettava käyttäjiä uusiin asioihin liittyen.
Milloin siis on oikea aika osallistaa käyttäjiä?
Ei ole oikeita tai vääriä ajankohtia – on vain oikeita ja vääriä tapoja. Tyypillisesti käytettävyystyössä kysymys kuuluu ”miten voimme auttaa käyttäjää?, mutta voit kääntää asetelman välillä niinkin päin, että ”miten käyttäjä voisi auttaa minua?”
Mieti siis, mikä käyttäjältä saatava tieto voi juuri nyt auttaa sinua pääsemään nopeammin eteenpäin työssäsi.
