Käytettävyystestaus on menetelmä, jonka tarkoitus on arvioida suunnittelunaikaisten valintojen toimivuutta todellisissa olosuhteissa. Se on siis pitkälti käytettävyysmaailman vastike toteutusvaiheen tekniselle testaukselle. Vaikka käytettävyystestaus onkin eräs yksinkertaisimmista tavoista parantaa tuotteen käytettävyyttä, sivutetaan se ohjelmistoprojekteissa merkillisen usein. Syitä löytyy varmasti aina projektipolitiikasta lähtien, mutta yksi on ylitse muiden: käyttöliittymäsuunnittelijan rooli on helppo ymmärtää väärin.
Tässäpä shokkiuutinen: käyttöliittymäsuunnittelija ei ole sovelluksen käytön asiantuntija – se rooli kuuluu käyttäjälle!
Käyttäjä – tuo oman alansa rautainen ammattilainen – tarkastelee käyttöliittymää kymmenien vuosien kokemuksen tuomasta näkökulmasta, eikä yksikään suunnittelija voi tavoittaa sitä tiedostamattomien valintojen polkua, jonka käyttäjä tekee käyttöliittymän ääressä. Kattavalla käyttäjätutkimuksella ja toimialaymmärryksellä voidaan toki luoda puitteet järkevälle suunnittelulle, mutta kun kyse on oikean maailman oikeista työtehtävistä, vastaa yksi oikea käyttäjä tuhatta arvuuttelevaa konsulttia. Ainoa poikkeus tähän ovat ne suunnittelijat, jotka omaavat itse vuosien kenttäkokemuksen myös laborantin, kirjanpitäjän, lennonohjaajan ja kirurgin työstä.
Koska käyttäjät eivät ole suunnittelijoita, on käyttöliittymäsuunnittelijan rooli havainnoida käyttäjiä ja sorvata käyttöliittymä tätä käyttöä paremmin tukevaan muotoon. Sovelluskehityksen kannalta olisikin parasta järjestää kevyt käytettävyystestaus heti kun se on vain mahdollista, jotta ohjausliikkeet saataisiin tehtyä ennen työlään toteutusvaiheen etenemistä.
Kaikkein kevyinkin käytettävyystestaus on parempi kuin täysin testaamatta jättäminen. Käytettävyystestauksen ohittaminen onkin verrattavissa siihen, että sovellus viedään tuotantoon ilman minkäänlaista teknistä testausta.
Toblerone ©Mondelez Schweiz GmbH
Toinen yleinen, joskin täysin inhimillinen, prosessivirhe on Toblerone-efektiksi ristimäni ilmiö (jos tälle on jokin virallinen termi, ole hyvä ja kerro se minulle).
Tuossa ylempänä on kaikille tuttu Tobleronen logo. Huomasitko, että vuoren sisälle on piilotettu karhun siluetti? Kas näin! Tästedes aina kun näet tuon logon, huomaat karhuhahmon, halusitpa sitä tai et. Toblerone-efekti tarkoittaakin juuri tätä: kerran koettua oivallusta ei ole mahdollista “oppia pois”.
Kun ryhmä eri alojen asiantuntijoita suunnittelee sovellusta yhdessä, muodostuu käyttöliittymälle usein sama Toblerone-efekti. Viikkoja kestäneen suunnittelun jälkeen käyttöpolut ja painikkeiden toiminnat ovat työryhmälle yksinkertaisesti niin tuttuja, ettei niiden käyttäytymistä ole edes mahdollista kokea toisin. Tällöin muutosehdotukset sivutetaan helposti väärinymmärrettyinä, ja käyttöliittymä oletetaan erilaiseksi kuin se projektin ulkopuolisen silmin todellisuudessa on.
Käyttäjätestaus on tehokkain tapa päästä eroon Toblerone-efektistä. Oikean käyttäjän kokemus konkretisoi ajatustenluvun mahdottomuuden ja mahdollistaa ensireaktion uudelleenkokemisen toisen käyttäjän silmin. Käyttäjätestaus tuo projektiin objektiivisen näkökulman – se pakottaa karhun pois vuoren sisältä.
Lue lisää käyttäjäkeskeisestä suunnittelusta:
