Käyttäjälähtöinen tietorakenne - käytettävyysasiantuntijan keskeisin tehtävä?

Käytettävyysalalla yritetään monesti korostaa, käytettävyys on enemmän kuin käyttöliittymä. Eli käytettävyyteen ei vaikuta pelkästään käyttöliittymäratkaisut vaan myös syvemmällä olevat järjestelmän suunnitteluratkaisut. 

Mitä nämä käyttöliittymää syvemmällä olevat ratkaisut sitten ovat? Itse näen erityisen keskeisenä, että järjestelmällä on käyttäjälähtöisesti määritetty tietorakenne. Tietorakenteita kyllä määritetään, mutta kokemukseni mukaan ei erityisen käyttäjälähtöisesti. Ja kuitenkin, jos tietorakenne on ongelmallinen, niin käyttöliittymällä sitä on hyvin hankala korjata. 

Kokemukseni mukaan käyttäjätarpeiden jäsentäminen tuottaa vahvan tietorakenteen. Ei itsestään, koska tietorakenne voi olla haastavaa jäsentää loogiseksi. Mutta tällainen jäsentäminen onkin mielestäni sopivaa haasteellista käytettävyysasiantuntijan työtä. Erityisesti järjestelmän eri entiteettien liittyvien tilojen tunnistaminen voi vaatia tosi aivotyötä - ainakin itse olen joskus joutunut todella pinnistelemään.

Ja vielä sellainen näkökulma, että tietorakennetta määritettäessä pääsee todella syvälle sovellusalueen  ja käyttäjän maailmaan. Kohta jäsennät sitä paremmin kuin käyttäjät itse. On ihan mukava tunne, kun voi tuottaa käyttäjille "ahaa"-elämyksiä.



Käyttäjälähtöisen tietorakenteen määrittäminen on perustavaa laatua oleva työvaihe. Toisaalta olen myös huomannut, että sitä ei välttämättä kukaan muu projekteissa tee. Siinä on mielestäni oiva ja keskeinen rooli käytettävyysasiantuntijalle.  

Käytettävyysasiantuntijan pisteytys

Eräässä tarjouspyynnössä pisteytetään käytettävyysasiantuntijan ominaisuuksia alla olevan mukaan:

Tässä kriteereinä ovat siis koulutustausta, projektikokemus ja toimialatuntemus. Tällaiset kriteerit ovat helppo pisteyttää (kuinka monessa projektissa ollut mukana) - eli ne on todennettavia. 

Mutta missä määrin tällainen pisteytys on validi; toisin sanoen miten nämä kriteerit oikeasti mittaavat käytettävyysasiantuntijan osaamista? 

• Se, että on ylempi korkeakoulututkinto, ei tarkoita, että olisi käytettävyysosaamista. Toki korkeampi koulutustaso luultavasti tukee analyyttistä jäsennyskykyä, mikä on ensiarvoisen tärkeää käytettävyystyössä
• Työkokemus (tyyliin kuinka monessa projektissa toiminut käytettävyysasiantuntijana/ ollut mukana): Luonnollisesti antaa kuvan siitä, miten paljon on asian kanssa ollut tekemisissä, ja sitä kautta relevantti näkökulma. Mutta ongelma on, että ei kerro mitään tekemisen laadusta. Voi olla, että ongelmalliset tottumukset ovat vain kumuloituneet.  
• Toimialatuntemus: Tämä tietenkin antaa valmiuksia ymmärtämään toimialaa. Mutta toimialan oppiminen (mitä se tarkoittaa käyttäjien näkökulmasta) ei itse asiassa ole välttämättä iso ponnistus. Oma kokemukseni on, että ulkopuolelta uuteen toimialaan tulleena voi joskus tosi nopeastikin  auttaa käyttäjiä jäsentämään heidän omaa työtään. 

Käytettävyysasiantuntijan osaamisen arviointi validisti ei tosiaankaan ole yksinkertaista: 

• Yksi syy on se, että alalla ei ole mitään yleisesti sovittuja osaamis- tai pätevyysvaatimuksia. Eri opinahjojen koulutukset eivät ole yhteismitallisia. Jopa samaa aihealueen kurssit voivat opettaa asioita eri tavalla. (Itsekin olen joutunut opettamaan käytettävyystestauksen ihan perusasioita periaatteessa alan koulutuksen saaneille henkilöille). 
• Toinen syy on se, että käytettävyystyö on hirveän pitkälle älytyötä. Se ei ole mekaanista, vaan perustuloksetkin vaativat analyyttista otetta ja pohdintaa. Sen vuoksi kokemuskaan ei ole välttämättä hyvä indikaattori. (ks. Ralf Molichin tutkimukset: http://kaytettavyysnavigoija.blogspot.com/2011/04/mika-mahtaa-olla-kaytettavyystestien.html)

Ehdotus: Itselläni tulee ratkaisuksi mieleen aito koetilaisuus, jossa osaamista testataan jopa tenttimäisesti ja jäsennyskykyä analyyttisillä tehtävillä tai suunnittelutehtävillä. (toki kokemus ym. voivat olla mukana osakriteereinä). 

Tällaisia en ole missään nähnyt. Eikä itsellänikään ole tällaisesta kokemusta hankintakontekstissa, eikä sitä kautta empiriaa idean toimivuudesta. Voi onko tällainen edes periaattessakaan (esim. lain puitteissa) mahdollista?

Olisiko joitakin ajatuksia tähän liittyen? 

Toivomuslistoilla ei aikaansaada käytettävyyttä

Eräässä terveydenhuollon tietojärjestelmän tarjouspyynnössä kannettiin selvästi huolta käytettävyydestä monessa kohden vaatimusmäärittelyä: 

• "Tunnistusmenettelyt tulee kehittää yksinkertaiseksi"
• "Käyttöliittymässä tulee olla helppokäyttöiset linkit"
• "Järjestelmässä käytettävien komentojen, termien, järjestelmähuomautuksien jne. tulee olla hyvää ja ymmärrettävää terveydenhuollon kieltä tai arkikieltä."
• "Usein toistuvat samankaltaiset toiminnot, kuten potilaan valinta, toimintayksikön valinta, tulostus jne. tulee tapahtua kaikissa järjestelmän osissa yhdennäköisellä käyttöliittymällä."
• "Tietojen, joita esitetään monilla eri näkymillä, sijainti ja järjestys tulee olla eri näkymissä samankaltainen."
• jne.

Tämän tyyppiset "vaatimukset" eivät kuitenkaan käytännössä takaa mitään järjestelmän helppokäyttöisyydestä. Kyse on lähinnä toivomuslistoista. 

Aluksikin vaatimuksissa on todennettavuusongelma. Esimerkiksi miten todentaa objektiivisesti, että vaatimus "käyttöliittymässä tulee olla helppokäyttöiset linkit" täyttyy tai ei täyty?

Toiseksi, käytännössä kuitenkin toimittaja hyväksyttää suunnitteluratkaisunsa asiakkaalla. Toisin sanoen asiakas lopulta teke päätöksen, että onko jokin suunnitteluratkaisu helppokäyttöinen vai ei. Eli vaatimukset eivät sitäkään kautta kohdistu toimittajaan. 

Summa summarum: toivomuslistoilla ei aikaansaada käytettävyyttä

Pitkät nimikkeet on ok!

Olen talven aikana ollut ainakin kolmessa eri tilanteessa, jossa välilehtien tai painikkeiden nimikkeiksi on haluttu  lyhyitä ilmaisuja; mielellään yksi lyhyt termi. Kukaan noista henkilöistä ei ollut taustaltaan käyttöliittymäalan ihminen: pari projektipäällikköä ja yksi tuotepäällikkö. Kuitenkin siis aika päättävässä asemassa, kun tehdään käyttöliittymäratkaisuja.

"Lyhyet nimikkeet" näyttää siis olevan intuitiivinen ajattelutapa. Kuitenkaan tälle ei liene muuta perustelua, paitsi että jos on tilaongelma kuten usein pienissä näytöissä.

Kuitenkin pitemmän nimikkeet ovat suotavia, jos niillä tehdään asiat selvemmiksi eikä ole tilaongelmaa.  Esimerkkinä selkeästä, pitkästä nimikkeestä alla oleva SurveyMonkeyn dialogissa oleva "Päivitä kyselytutkimuksen otsikko" - painike.

Vai näkeekö joku pitkässä nimikkeessä olevan jokin ongelma?

Vertaileva käytettävyystestaus demoilla ei toimi

Käytettävyystestaus on periaatteessa toimiva ratkaisu järjestelmien käytettävyyden vertailussa. Tällaisia näkee joskus myös tarjouspyynnöissä valintakriteerinä. Esimerkiksi eräässä tarjouspyynnössä käytettävyystestauksen tuloksen painoarvo oli 50% valintaperusteesta:

"Tarjoajan toimitettava laitteisto ja demo järjestelmästä. Testauksessa analysoidaan tehtävän onnistumista, nopeutta, virhetoimintojen määrää... Mikäli käytettävyystestauksessa 30% käyttäjistä epäonnistuu, kyseinen tarjous hylätään".

Kuitenkaan demoilla tehtävä käytettävyystestaus ei anna välttämättä ollenkaan luotettavia ja valideja tuloksia. Syy on yksinkertainen: käytettävyystestaus on menetelmänä herkkä pienillekin suunnitteluongelmille. Testauksen tulokset voivat olla huonot esimerkiksi jonkin epäselvän termin vuoksi, joka olisi helppo muuttaa lopulliseen järjestelmään. Eli hylätyksi voi tulla järjestelmä, joka olisikin pienin muutoksin toimivin.

Käytettävyystestaus voi toimia validina vertailuperusteena valmisohjelmistojen hankinnassa. Mutta jos kyseessä on joko asiakaskohtaisesti räätälöitävä tai kokonaan asiakaskohtainen järjestelmä, käytettävyyden varmistamista tulee lähestyä muuta kautta.

Tähän ei ole välttämättä valmiita yleispäteviä ratkaisuja, vaan valintakriteerit tulee kehittää tapauskohtaisesti.  Lähtökohtana tulisi periaatteessa olla päätös siitä, että jätetäänkö käytettävyys hankkijan vai toimittajan vastuulle. Vaikka jälkimmäinen on ehkä houkuttelevampi vaihtoehto, käytännössä luultavasti tulee kuitenkin lähteä siitä, että käytettävyyden varmistus jää viime kädessä hankkijan vastuulle. Käytettävyyden "vastuullistaminen" toimittajalta on mahdollista mutta metodologisesti vaativaa. Lisäksi tämän päivän toimittajamaailmassa tuskin ollaan sellaiseen vastuuseen vielä kypsiä.