Käytettävyyden vaikuttavuustavoitteiden määrittäminen: perusta käytettävyyden suunnittelulle

Käytettävyysohjatun vuorovaikutussuunnittelun prosessia kuvaavan JFunnel-mallin (Jokela 2010) ensimmäinen aktiviteetti on "strategisten käytettävyystavoitteiden määritys". Sen tarkoitus kuvataan: "Strategisten käytettävyystavoitteiden tarkoituksena on määrittää, miten sovelluksen käytettävyyden halutaan tukevan liiketoimintaa (tai organisaation toimintaa). Strategiset käytettävyystavoitteet määrittävät ”liiketoiminnan kielellä”, mitä hyvä käytettävyys tarkoittaa".

Olen tullut siihen tulokseen, että "strateginen käytettävyystavoite" ei ehkä ole paras mahdollinen termi: se ei semanttisesti kerro kovin selvästi, millaisesta aktiviteetista on sisällöllisesti kyse. Kuvaavampi termi tälle asialle on "käytettävyysvaikuttavuus". Ehkä tämäkään termi ei kuullosta kovin elegantilta, mutta asiallisesti tästä on kyse: aktivitetissa kun nimenomaisesti tulisi määrittää, mitä liiketoiminnallista vaikuttavuutta käytettävyydeltä halutaan. (Englanniksi termi on elegantimpi: "usability impact".)

Käytettävyyden vaikuttavuus on valintakysymys. Se, millaista vaikuttavuutta halutaan, riippuu sovelluksesta mutta on myös business-valinta. Vaikuttavuus voi olla erilaista niin laadultaan kuin tasoltaan, riippuen casesta. Esimerkiksi yhdessä julkisen hallinnon sovelluksessa määritettiin erääksi keskeiseksi käytettävyysvaikuttavuudeksi se, että "turhat" puhelut asiakkailta vähenevät merkittävästi (koska niihin menee paljon virkailijoiden aikaa). Vaikuttavuuden taso määritettiin myös numeerisesti.

Käytettävyystoimenpiteiden määrä ja laatu sitten riippuu tästä halutun vaikuttavuuden laadusta ja tasosta. Jos sovellus ja businessvalinta ovat sellaisia, että potentilaalisesti saavutettavat vaikuttavuudet eivät ole merkittäviä, niin vaikeapa silloin voi olla perustella käytettävyystoimenpiteitä. Esim. julkisissa kilpailutuksissa on usein niin, että asiakas ei tarjouspyynnöissä aidosti edellytetä käytettävyyttä. Eipä silloin ole paljon perusteita softantekijöille otta käytettävyttä huomioon (itse asiassa tarkoittaisi vain tarjouksen kilpailukyvyn heikkenemistä).

Eli korjattu versio kirjan tekstiin:

"Aktiviteetin otsikko: 0. Käytettävyyden vaikuttavuustavoitteiden määrittäminen

Halutun käytettävyysvaikuttavuuden (desired usability impact) määritys on aktiviteetti, jota ei yleensä käytettävyyssuunnittelun lähteissä tuoda esiin. Toki on kirjallisuutta liittyen käytettävyydellä saavutettaviin etuihin (Bias and Mayhew 1994), mutta vähemmän siitä, miten määrittää etuja tavoitteellisesti. Käytettävyyden vaikuttavuus on tietoinen valinta - sen vuoksi puhutaan halututusta vaikuttavuudesta - eikä laskennallisesta "mitä kaikkia etuja käytettävyydellä voi saavuttaa".
Taustana tämän aktiviteetin sisällyttämiseen on se tosiasia, että käytettävyys on jatkuva, ei ”on/off” –suure. Sen vuoksi käytettävyydelle tulisi määrittää tavoitetaso: kuinka hyvää käytettävyyttä halutaan. Ja tällainen tason määritys periaatteessa ei voi perustua muuhun kuin niihin strategisiin valintoihin, joita liiketoiminta tai organisaatio tekee.

Tarkoitus

Haluttu käytettävyysvaikuttavuus määrittää, miten ja missä määrin sovelluksen käytettävyyden halutaan tukevan liiketoimintaa tai organisaation toimintaa. Haluttu vaikuttavuus määrittää ”liiketoiminnan kielellä”, miten käytettävyyden tulisi konkreettisesti tukea liiketoimintaa tai organisaation toimintaa.


Luonnehdinta

Tavoitteen määrittämiseksi tarvitaan tietoa sovelluksen liiketoimintakontekstista. Näitä ovat esimerkiksi:

   * mikä tuote ja sen päätoiminnallisuus (mitkä ovat sen tarjoamat palvelut asiakkaalle)
   * mille markkinoille
   * ketkä ovat asiakkaat
   * miten sen halutaan erottuvan markkinoilla
   * mitkä ovat kilpailutekijät
   * mitkä ovat liiketoiminnalliset tavoitteet

”Liiketoiminnan” tilalla voi olla – kontekstista riippuen – organisaation, esimerkiksi sairaalaympäristön toimivuus.

Tavoitteita määrittäessä tulee ymmärtää, että käytettävyys ei välttämättä ole kaikki kaikessa vaan sen merkitys ja vaadittu taso riippuu liiketoimintakontekstista. Käytettävyyden suunnitteluun voidaan helposti laittaa paljonkin resursseja, enemmän kuin on järkevää. Haluttu käytettävyysvaikuttavuus on organisaation strateginen valinta, joiden tulisi toisaalta tuottaa järkeviä liiketoiminnallisia etuja, ja toisaalta olla kehitysresursseihin nähden järkevästi saavutettavissa.

Strategisena tavoitteena ei siis välttämättä tulisi olla, että saavutetaan ”paras mahdollinen käytettävyys”. Tavoitetason asettaminen riippuu esimerkiksi siitä, haluaako yritys haluaa olla ”johtotähti” käytettävyydessä vai pyrkiikö olemaan kilpailijoiden tasolla. Tuote voi olla liiketoimintamenestys huolimatta käytettävyysongelmista. Esimerkiksi Nokian 90-luvun peruspuhelinmallin (kuva 6, kuva 9) kaupallinen menestyminen lienee ollut erinomainen, selkeistä käytettävyysongelmista huolimatta.

Aktiviteetti on liiketoimintajohdon, yrityksen ja kehitysprojektin eri osapuolten sekä käytettävyysammattilaisten vuoropuhelua. Tavoitteiden määrittämistä varten tulee valita attribuutit, jotka sopivat sovelluksen liiketoimintakontekstiin. Käytettävyysvaikuttavuuden tyypilliset attribuutit perustuvat ns. käytettävyyden liiketoimintaetuihin, esimerkiksi:

   * järjestelmän hyväksyttävyys
   * koulutuksen helppous
   * käyttäjät eivät tee virheitä
   * käyttäjätuen tarpeen minimointi
   * käytön nopeus, vaivattomuus
   * käyttäjien työn tehostuminen
   * käyttäjä- ja työtyytyväisyys

Haluttu käytettävyysvaikuttavuus on aina väistämättä sovelluskohtaista. Vaikuttavuus  asettamisessa voidaan esimerkiksi ottaa kantaa käyttöohjeeseen tai käyttökoulutukseen: onko tavoitteena, että tuote tulisi olla opittavissa ilman käyttöohjetta tai käyttökoulutusta? Esimerkki toisen tyyppisestä tavoitteesta on asiakkaiden viranomaisille tekemien ”turhien” puhelujen vähentäminen.

Tuotokset

Aktiviteetin tuotoksena kuvataan haluttu käytettävyysvaikuttavuus niin laadullisesti (mitä attribuutteja) kuin tavoitetasona. Attribuuttien tulisi kuvata yrityksen tai organisaation todellisia liiketoimintahyötyjä. Tavoitteiden määrityksessä tulisi pyrkiä mitattavuuteen.

Syytä olisi välttää sellaisia kriteereitä, jotka eivät riipu yksikäsitteisesti käytettävyydestä. Tällainen on esimerkiksi ”lisääntynyt myynti”: myyntiin vaikuttavat niin monet muutkin seikat, että käytettävyyden vaikuttavuutta on vaikea erottaa.

Käytettävyysvaikuttavuuden määrittäminen voidaan nähdä myös riskinhallintana. Tunnistetaan riskit, jotka seuraavat potentiaalisista käytettävyysongelmista. Käytettävyyssuunnittelu nähdään sitten riskin pienentämismenetelmänä.

Menetelmät

Aktiviteetti on liiketoimintajohdon, projektijohdon ja käytettävyysasiantuntijan välistä vuoropuhelua. Taustatiedoiksi voidaan tarvita ymmärrystä niin käyttäjäryhmistä (aktiviteetti 1) ja käyttökontekstista (aktiviteetti 2).

Viitteet

Jokela, T (2010). Navigoi oikein käytettävyyden vesillä. www.kaytettavyyskirja.net

Nokian käyttöliittymäkohtalon taustat 90-luvulla?

Nyt siis Nokia kurssi huitelee alamaissa. Käyttäjäkokemuksen suunnittelussa jälkeen jäämistä pidetään yhtenä keskeisistä syistä Nokian alamäkeen.

On kaikkiaan hämmentävää Nokian epäonnistuminen hyvän käyttäjäkokemuksen tuottamisessa. Nokialla on sankoin joukoin käytettävyys- ja käyttäjäkokemusammattilaisia - moni alalta väitellyt ja kansainvälisesti tunnustettu. Ei ole uskottavaa, etteikö Nokialla olisi ollut alan osaamista. Syyt ovat muualla. Nokia teknologiavetoisesta kulttuurista on puhuttu yhtenä syynä.

Mutta pidän yhtenä mahdollisena syynä myös erikoista käyttöliittymäparadigmaa, joka sai vallan Nokialla 1990-luvulla. Mielestäni on mahdollista, että tämän paradigman vaikutukset näkyivät vielä viime vuosiin asti ja ovat osaltaan taustalla Nokian puhelinten käyttäjäkokemusongelmiin.

------------

Monet ehkä muistavat Nokian puhelinten erilaiset käyttöliittymät 90-luvun lopulla. Oli punainen ja vihreä luurinäppäin -käyttöliitymä, oli "navi"-näppäinkäyttöliittymä, oli rullakäyttöliittymä...

Nokialla sai silloin valtaa erikoinen "tyyliohjautunut" käytettävyysparadigma: strategiana oli erilaisia käyttöliittymätyylejä. Käytännössä silloin paradigma tarkoitti erilaisilla näppäimistöillä varustettuja puhelimia. Erilaisista käyttöliittymätyyleistä tehtiin itseisarvoja; niitä käytettiin mm. markkinasegmentoinnin keinona. Välitön seuraus ja ongelma oli tietenkin se, että eri puhelimet olivat keskenään erilaisia käyttää. Tyylien rajoitteissa pyrittiin kuitenkin tekemään puhelinten sovelluksista niin helppokäyttöisiä kuin pystyttiin. Ja kohtuudella onnistuttiinkin.

Toinen seuraus oli kuitenkin se, että yksinkertaistetuilla käyttöliittymätyyleillä oli vaikea suunnitella joitakin puhelinten sovelluksia millään tavalla elegantisti. Seurauksena saatettiin jättää operaattoreille tärkeitä sovelluksia pois. Jopa sanottiin, että "asiakkaat ovat väärässä", kun operaattorit halusivat tiettyä sovellusta.

Ydinasia tässä kuitenkin on se, että tyylikeskeisyys on tietenkin vastoin sitä, mitä käytettävyys aidosti on. Se on itse asiassa täysin vastakkaista käytettävyyden periaatteille, vaikka käytettävyyden nimellä sitä Nokialla sisäisesti markkinoitiinkin. Käyttöliittymänhän ei tulisi ole itseisarvo, vaan apuväline, vuorovaikutuskeino sovelluksiin. Kriteeri hyvälle käyttöliittymä on se, että sovellusten käyttö sujuu. Ei sen enempää. Käyttöliittymät tulisi suunnitella sovellusten ehdoilla eikä toisin päin.

Ja nyt pidän mahdollisena, että tämä erikoinen 1990-luvun oppi jäi elämään joidenkin Nokian päättävien henkilöiden keskuuteen myös pitkälle 2000-luvulle. Tällaista olen tulkinnut joidenkin Nokian johtajien julkisuudessa olleista lausunnoista vuosien aikana (tosin niin tarkkaan en seurannut asioita, että olisin kirjannut näitä muistiin). Joka tapauksessa vähän sen tyylistä viestiä, että ratkaisu ongelmaan olisivat olleet jotkut "käyttöliittymäjippo"-tason asiat.

-----------

Eli pidän siis mahdollisena, että tämä erikoinen oppi olisi vaikuttanut vielä viime vuosina Nokian käyttöliittymäpäätöksiin, jotka sitten viime kädessä realisoituivat tämän päivän jälkeenjääneisyyteen.

Tämä on kuitenkin minun pohdintaani, enkä tiedä, että menivätkö asiat todella näin 2000-luvulla (noita 1990-luvun tapahtumia kyllä seurasin omin silmin). Mutta ainakin tämä mielestäni olisi yksi looginen selitys sille, miksi Nokialla kävi kuin kävi; miksi Nokian merkittävä käyttäjäkokemusosaaminen ja -resurssit eivät realisoituneet tuotteisiin. Jos joku nokialainen eksyy tälle blogille, niin ehkä voi kommentoida asiaa.

Jos tämä tulkintani on osittainkin totta, niin siinä on tietenkin on mielenkiintoista pohdittavaa käytettävyys- ja käyttöliittymäalalle yleensä. Mutta ei mennä tässä asioiden edelle.

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ä.