Eficoden ux-tutkimustiimin johtaja ja it-alalla uransa tehnyt psykologi Raino Vastamäki pohtii työssään digitaalisten palveluiden ja tuotteiden käytettävyyden kulmakiviä päivittäin. Kuinka varmistetaan, että tuote on saavutettava, helppokäyttöinen ja hyödyllinen, mutta myös haluttava ja kiinnostava?

Tarve ja ongelma lähtökohtana

Tuotekehityksen ideointi lähtee siitä, että tunnistetaan jokin ongelma. Huomataan, että maailmassa on jokin kitka, ja että siitä voisi päästä eroon. Välttämättä ei heti tiedetä, miten.

“Se on oikeastaan ollut koko ihmiskunnan kehityksen idea. Suurin osa ongelmistahan on löytynyt sillä tavalla, että joku on joskus miettinyt vaikkapa sitä, kuinka voisin metsästää pidemmän etäisyyden päästä tai miten saisin tuon kalan tuolta veden alta koukkuun. Ja tähän on kehitetty erilaisia keinoja. Ja sitten on kokeiltu, että jos tuohon puroon laitettaisiin tuommoinen risuaita, niin jäisikö ne kalat siihen. No ei oikein jäänyt, tehdään verkko. Ihan samalla tavalla nyt, kun meillä on esimerkiksi joku digitaalinen tuoteidea, niin siitä tehdään käyttöliittymän prototyyppi, jota testataan ja validoidaan ennen kuin ruvetaan koodaamaan”, Vastamäki selittää.

 “Testaaminen on kuitenkin tehtävä riittävän aikaisin. Tulee varsin kalliiksi, jos tehdään valmis tuote, laitetaan markkinoille ja sitten vasta huomataan, ettei tätä kukaan käytä. Jos sitä olisi tutkittu käyttäjillä, niin siitä olisi saatu houkutteleva ja kiinnostava. Tuotteen hyvä käytettävyys on ratkaisevaa”, Vastamäki muistuttaa.

Käytettävyys ja käyttökokemus osana asiakaslähtöistä palveluiden muotoilua

Käytettävyys on termi, joka on Vastamäen mukaan ollut pinnalla viimeiset 20 vuotta.  Käytettävyys tarkoittaa helppokäyttöisyyttä, tehokkuutta ja miellyttävyyttä. Myöhemmin keskiöön tuli laajempi käsite käyttökokemus, joka pitää sisällään myös esimerkiksi esteettiset näkökulmat: näyttääkö digitaalinen palvelu hyvältä, houkuttelevalta ja trendikkäältä. Viime vuosina palveluiden kehittämisen kattotermiksi on noussut palvelumuotoilu.

“Palvelumuotoilu kattaa käytettävyyden ja käyttökokemuksen lisäksi myös sen, että sen varsinaisen palvelun sisältö ja logiikka mahdollisimman paljon palvelee paitsi käyttäjää, myös palveluntuottajaa”, Vastamäki selittää.

“Palvelumuotoilu voi olla myös koko liiketoiminnan suunnittelua. Esimerkiksi kun Onnibus tuli Suomen markkinoille, siinä ei pelkästään tehty parempaa käyttöliittymää ja applikaatiota, vaan muutettiin koko bisnesmalli. Halvempi hinnoittelu sopi käyttäjälle ja kuluttajalle, mutta se oli myös liiketoiminnan kannalta hyvä, tai erilainen ainakin”, Vastamäki kertoo.

Olipa kyse sitten liiketoimintasuunnittelusta tai vaikka vain yhden applikaation käyttöliittymän suunnittelusta tai parantamisesta, vallalla olevana filosofiana on asiakaslähtöisyys.

“Lähdetään tekemään palvelua tai tuotetta asiakkaille eikä niin, että tehdään meidän organisaatiolle ja liiketoiminnalle joku rajapinta. Eli suunnittelu ei ole organisaatiolähtöistä tai suunnittelijalähtöistä vaan asiakaslähtöistä. Tämä on se oleellinen muutos”, Vastamäki selittää.

 “Perinteinen taide tai muotoilu lähtee siitä, että meillä on sankariarkkitehti, vaikkapa Alvar Aalto, joka tekee meille hienon maljakon. Se syntyy siitä, että hänellä on intuitio ja lahja suunnitella ja toteuttaa maljakko. Käyttäjäkeskeinen suunnittelu lähtee puolestaan siitä, että tutkitaan ensin, mitä ne käyttäjät oikeasti tarvitsevat ja haluavat ja iteroidaan suunnitelmaa ja tuotetta, kunnes se on hyvä. Alvar Aalto noudatti tätä funktionalismin ideaa, että rakennukset olisivat enemmänkin toiminnallisesti kuin esteettisesti käytännöllisiä, mutta käytännössä rakennukset olivat edelleen kuitenkin ensisijaisesti esteettisesti suunniteltuja. Alvar Aalto ei kyllä käytännössä juurikaan ottanut käyttäjiä tai asiakkaita mukaan suunnitteluun tai tutkinut heitä”, Vastamäki vertaa.

Miten palvelumuotoilun prosessi etenee?

Palvelumuotoilu lähtee nykytilanteen kartoittamisesta: katsotaan, millaisia palveluita on olemassa. Tämän jälkeen käyttäjiä ja heidän näkemyksiään tutkitaan erilaisilla menetelmillä, kuten haastatteluilla, kyselyillä tai toimintaa seuraamalla. Toimintaa seuraamalla saadaan tietoa siitä, mitä käyttäjät asiaan liittyen nykyään tekevät ja millaisia palveluita he voisivat toimintaansa tarvita. Tarkastellaan, millaisia heikkouksia ja vahvuuksia nykyisillä palveluilla on.

 “Tekemällä käytettävyystesti nykyisellä palvelulla haastetaan käyttäjää kertomaan, mikä nykyisessä palvelussa on hyvää ja huonoa, ja millaiset asiat olisivat parempia. Käyttäjiltä voidaan kysyä, mitkä asiat toiminnallisuuksissa ovat sellaisia, jotka tukevat hänen työtään tai tavotteitaan, ja mitä tästä puuttuu”, Vastamäki kertoo.

Toiminnallisuus ja asenteet käytettävyyden mittareina

Käytettävyyttä tutkiessa on hyvä hahmottaa toiminnan ja asenteiden ero. Voimme tutkia havainnoimalla, mitä käyttäjä varsinaisesti tekee, mutta asenteistaan ja mielipiteistään käyttäjän täytyy kertoa esimerkiksi haastatteluissa tai kyselyissä. Mitä käyttäjä haluaa, toivoo ja kritisoi? Osaako hän käyttää palvelua?

“Ihmisen käyttäytyminen ja asenteet ovat joissakin asioissa hyvin erilaisia maailmoja. Ihminen on varsin luotettava lähde omiin mielipiteisiinsä mutta ei välttämättä omaan toimintaansa”, Vastamäki kertoo.

“Käytettävyydessä korostuu toiminnallinen, behavioraalinen taso. Klikkaamme linkkejä, navigoimme jossain valikossa, eksymme ja löydämme. Se on juuri käytettävyyttä ja helppokäyttöisyyttä ytimeltään. Käyttäessämme jotain digitaalista palvelua emme kuitenkaan itse ole kovinkaan tietoisia esimerkiksi siitä, miksi emme esimerkiksi osaa käyttää sitä. Kun asiantuntija katsoo vierestä, kun  ihminen käyttää tuotetta, niin hän näkee, että “aa, se eksyy tuonne, aa, se yrittää tuota, ei ymmärrä tuota”. Ulkopuolinen tarkkailija osaa paremmin nähdä, mikä tuotteessa toimii käyttäytymisen tasolla ja mikä ei”, Vastamäki selittää.

“Käyttökokemuksen muut puolet menevät enemmän subjektiiviselle tasolle. Käyttäjä voi esimerkiksi suoraan sanoa, että en minä tästä tykkää, koska en tarvitse tällaista juttua. Tai että en tykkää koska nämä värit ovat minun mielestäni kamalia. Mielipide tulee suoraan sanotuksi haastattelussa tai kyselyssä.”

Käytettävyyttä tutkiessa asiantuntija voi esimerkiksi antaa käyttäjälle tehtäviä tai käyttötapauksia. Käyttäjälle voidaan antaa vaikkapa kokonaisen sivuston prototyyppi kokeiltavaksi, ja käyttäjän annetaan vapaasti liikkua sivustolla. Vastamäen mukaan käyttäjä tyypillisesti ohjataan ajattelemaan ääneen, jotta tutkija voi samassa tilanteessa saada selville, mitä käyttäjä yrittää tehdä. 

“Käyttäjä voi sanoa vaikkapa, että “mä nyt yritän hakea verkkokaupasta sopivaa pyörää” ja kun käyttäjä on sen löytänyt, hän voi kertoa, että “tämän polkupyörän mä nyt ajattelin ostaa, yritänpä mennä maksamaan tänne”. Tutkija havainnoi sitten, mikä sujuu hyvin, mikä on kankeampaa ja missä tulee virheitä”, Vastamäki kertoo.

Käytettävyystestaus tuottaa yksilöllistä tietoa

Käytettävyystestaus tehdään yleensä yhden ihmisen kanssa kerrallaan. Koska käytettävyystesti on työläs ja vie aikaa, Vastamäki suosittelee noin 6-8, korkeintaan 12 ihmisen testijoukkoa. Tavallisesti tunti on sopiva aika käydä läpi esimerkiksi kokonainen verkkopalvelu yhden käyttäjän kanssa. 

“Käyttäjältä voi itseltä myös tulla paljon korjausehdotuksia. Meidän kokemuksemme mukaan kannattaa kuitenkin sitten enemmän luottaa suunnittelijan tai käytettävyysasiantuntijan mielipiteeseen. Maallikkokäyttäjän ehdotukset siitä, miten palvelua tai tuotetta pitäisi korjata, ovat harvoin hyviä ratkaisuja”. Vastamäki kertoo.

Vastamäki on aiemmin tehnyt käytettäyystestit tavallisesti kasvokkain. Koronan aikana on kuitenkin huomattu, että Teamsin tai Zoomin kaltaiset alustat ovat toimineet testeissä hyvin. Käyttäjän toimintaa voi myös samaan aikaan seurata useampi asiantuntija. 

“Livetilanteessa saa paljon tietoa ja voi kysyä lisäkysymyksiä. Mutta tarvittaessa voi myös myöhemmin palata tallenteeseen. Litteroimaan ei tavallisesti kuitenkaan kannata ruveta. Hyöty ei välttämättä ole enää riittävän suuri panostettuun aikaan nähden”, Vastamäki kertoo.

Esimerkiksi turvarannekkeen käyttö vaatii puolestaan pidempiaikaista seurantaa.  Vastamäki suosittelee mm. päiväkirjan pitämistä tai kyselyyn vastaamista päivittäin. Käyttäjä tai hänen avustajansa voi laittaa muistiin, mitä rannekkeen käytön aikana tapahtui, menikö joku pieleen ja mikä oli kivaa tai hankalaa. Tietyn käyttöjakson, kuten viikon tai kuukauden, jälkeen voidaan tehdä vaikkapa ryhmäkeskusteluna. Tässä voi käyttää myös erilaisia sovelluksia, kuten WhatsAppia. Pienryhmissä kannattaa Vastamäen mukaan olla 2-3 käyttäjää kerrallaan. Intiimin terveysdatan ollessa kyseessä keskustelut käydään kahden kesken. 

Erilaisia menetelmiä eri vaiheissa

Erilaiset menetelmät tuottavat erilaista tietoa tuotekehityksen eri vaiheissa. Tuotteen ideoinnin ja palvelukonseptin luomisen vaiheessa haastatellaan käyttäjää siitä, miten hän arjessaan toimii ja millaisia tarpeita silloin herää. Käyttäjän toimintaa voidaan myös havainnoida. Näin saadaan selville käyttökonteksti ja sieltä kumpuavat aidot tarpeet. Tämän jälkeen hahmotellaan käyttäjäpersoonat.

“Käyttäjäpersoonat ovat esimerkkejä tyypillisistä käyttäjäryhmistä. Voidaan kirjoittamalla luoda turvaranneketta käyttävä Matti ja Maija ja hahmottaa, mitkä heidän tarpeensa ovat suhteessa ideoituun tuotteeseen. Mikä on käyttökonteksti ja mitkä ovat niitä  toiminnallisuuksia, joita tuotteet tarvitsisivat Matin ja Maijan käytössä”, Vastamäki kertoo. 

Tämän jälkeen kiteytetään palvelukonsepti. Palvelusta riippuen tehdään asiaan kuuluva prototyyppi. Prototyypin tekemisessä hyvä menetelmä on käyttää viidessä päivässä toteutettavaa Design Sprintiä.

“Nykyään erilaiset prototyyppi-työkalut ovat aika hyviä. Niillä voidaan tehdä toiminnallinen käyttöliittymäprototyyppi mahdollisesti aika valmiiksi ennen kuin sitä on oikeastaan koodattu vielä mitenkään. Tehdään sellainen käyttöliittymä, jonka prototyyppi voidaan testata käyttäjillä. Yleensä se on lyhyt testi. Sitten validoidaan käyttöliittymä ja vähän korjataan, jonka jälkeen sitä ruvetaan iteroiden kehittämään ja koodaamaan. Siinä voi sitten olla yksi tai useampi käytettävyystestikierros vielä”, Vastamäki kertoo. 

“Tyypillisesti suosittelemme kahta, kolmea testikierrosta. Jos kierroksia saadaan useampi, käyttäjämäärät voivat olla vähän pienempiäkin, mutta myös isommalla massalla voi kerätä tietoa. Ja yleensä yksi testaus kannattaa jättää melkein kehitystyön loppuun, kun siellä on jo sisältöä. Filosofia pitäisi kuitenkin olla, että se tuote ei ole koskaan valmis, vaan siitä aina tehdään parempi versio jossakin vaiheessa”, Vastamäki sanoo. 

Suunnittelija suodattaa käyttäjältä saatavan tiedon

Käyttäjän kanssa yhdessä toimiminen ja osallistaminen on hyvä keino löytää uusia ideoita. Sellaisenaan niitä ei kuitenkaan voi vielä ottaa käyttöön vaan ne täytyy validoida hyvin tarkalla filtterillä ja testata niitä edelleen toisilla käyttäjillä. Vastamäki katsookin, että tuotekehityksen on oltava viime kädessä suunnittelijan hallussa. 

“Osallistamisen tai osallistumisen kautta käyttäjä pystyy kontribuoimaan sillä tavalla, että suunnittelija näkee mitä käyttäjä tekee ja haluaa, ja ehkä ideoikin. Suunnittelija kuitenkin valitsee ne toimivat ideat”, Vastamäki sanoo.

“Käyttäjän idea voi toki olla sattumalta hyvä. Samoin käyttäjä tietää omista tarpeistaan jotain, mutta ei välttämättä kaikkea. Meistä ei varmaan kukaan olisi koskaan voinut kuvitella ennen kännyköitä, että haluaisimme kirjoittaa ja lähettää tekstiviestejä. Tai jos joku olisi näyttänyt WhatsAppin meille ennen tekstiviestejä, niin emme olisi todennäköisesti edes sanoneet, että tämä on meidän tarve. Että “en minä jaksaisi kahdella sormella kirjoittaa, täysin mahdoton ajatus”. Ja nyt jälkikäteen sitten huomaamme, että tämä tarve kirjoittaa kahdella sormella onkin ollut melkoinen”, Vastamäki sanoo.

Saavutettavuuden varmistaminen on kiinteä osa tuotekehitystä

Tuotekehityksessä on alusta saakka otettava myös saavutettavuuskriteerit huomioon, sillä digitaalisten palveluiden saavutettavuudesta huolehtiminen on lakisääteistä. Saavutettavuus tarkoittaa esteettömyyttä verkossa, jolloin mm. ikäihmiset ja aistivammaiset pystyvät käyttämään palveluita yhtä hyvin kuin ne, joilla rajoitteita ei ole. Saavutettavuuslaki toimii apuna niille noin miljoonalle ihmiselle, jotka ovat vaarassa tippua digitalisoituvan yhteiskunnan kyydistä. Esimerkiksi saavutettavasti.fi-sivustolta löytyy kootusti ohjeita saavutettavuuden varmistamiseen.

“Varsinkin jos kohderyhmässä on vaikkapa senioreita paljon, niin sitten pitäisi ottaa näitä ihmisiä, joilla on jotain rajoitteita, mukaan näihin testeihin. Esimerkiksi verkkopalveluiden kohdalla olisi hyvä käyttää saavutettavuuslakiin liittyvää, W3C:n (The World Wide Web Consortium) WCAG-ohjeistoa (Web Content Accessibility Guidelines). Se on hyvinkin tarkka kriteeristö”, Vastamäki selittää.

“Muuten siinä käy niin, että on valmis tuote ja sitten sitä testatessa vasta huomataan, että nyt pitää korjata. Voi olla, että joudutaan korjaamaan aika isojakin asioita, ihan lähtien graafisesta ilmeestä. Esimerkiksi kontrastit voivat olla pielessä: harmaat fontit eivät näy harmaalta pohjalta. Tuote voi jopa mennä hyväksyttäväksi ihan johtoryhmään asti, ja siellä sitten vasta huomataan että “ai, meidän pitää muuttaa meidän visuaalista ilmettä, kuinkas tässä näin on käynyt”, Vastamäki kertoo. 

“Esimerkiksi fontteja voi toki suhteellisen helposti muuttaa ilman, että tarvitsee puuttua koodiin, mutta jos kyseessä on vaikka keskustelusofta tai kännykkäapplikaatio, niin voi olla että se on niin syvällä siinä ohjelmoinnin alkulogiikassa, että ei sitä pystytäkään halvalla korjaamaan.”

Saavutettavuus on myös laajempi asia kuin esimerkiksi WCAG-kriteerit, jotka keskittyneet verkkopalveluihin. Saavutettavuuden lisäksi palvelun käyttämisen täytyy olla sujuvaa kaikille käyttäjille.

“Käyttäjiä on tietysti monenlaisia. Ei esimerkiksi ole yhdenlaista sokeaa ihmistä vaan kaikki ihmiset ovat myös yksilöitä. Vaikka joku palvelu täyttää nämä kriteerit, ei se välttämättä vielä tarkoita, että käyttö olisi erityisryhmille helppoa”, Vastamäki muistuttaa. 

Saavutettavuuden tutkimisessa kannattaa käyttää asiantuntijoita

Vastamäki suosittelee käyttämään saavutettavuuden tutkimisessa asiantuntijoita. Tyypillinen saavutettavuusarviointi esimerkiksi verkkosivuston kohdalla vie asiantuntijalta Vastamäen mukaan noin 4-6 päivää.  Asiantuntija kirjaa ongelmat raporttiin ja antaa korjausehdotukset.

“Vaikka onkin lukenut esimerkiksi WCAG-kriteerit, niin oman käyttöliittymän läpikäyminen voi olla yllättävän työlästä, jos ei ole rutiinia ja ymmärrystä. Ammattilainen tuntee niksit ja tekee sen nopeammin ja tehokkaammin. Kuitenkin, jos yritys tekee itse tuotekehitystä ja haluaa varmistaa käytettävyyden ja saavutettavuuden, kannattaa osaamista tietenkin alkaa kerryttämään myös talon sisälle”, Vastamäki suosittelee. 

Asiantuntijoina käytetään myös erityisryhmiin kuuluvia.

“Monesti esimerkiksi sokeat käyttäjät ovat todella kokeneita verkkopalvelujen käyttäjiä. Ne ongelmat, joita suunnittelijat ovat luulleet haastaviksi, eivät sitä välttämättä sitten olekaan. He sanovat, että eihän tämä nyt mikään ongelma oikeasti ole.” 

Joskus palvelun kehittäjä voi tuoda palveluun saavutettavuuden parantamiseksi ohjelmistoja, joita erityisryhmiin kuuluvat eivät kuitenkaan käytä. Heillä voi olla jo omien koneidensa käyttöliittymissä integroituna ruudunlukuohjelma, kuten esimerkiksi Macissa VoiceOver. Myös esimerkiksi NVDA (Non Visual Desktop Access) on ilmainen sovellus PC:lle.

“Verkkosivuilla olevat tekstinlukuohjelmat tai “tekstiä puheeksi -ohjelmat” saattavat olla kuitenkin ihan kiva lisä. On esimerkiksi senioreita, joiden näkö on alkanut jo huonontua, ja heille tällainen tekstinlukuohjelma voi olla mukava, samoin kuin sellaisille henkilöille, jotka ovat tottuneet käyttämään äänikirjoja vaikkapa lenkkipolulla. Tällainen ohjelma voi vastaavalla tavalla lukea verkkosivustoa ja käyttökokemus on vastaava. Useimmiten näkövammaiset kuitenkin käyttävät omia ruudunlukuohjelmiaan käyttääkseen Interneitä, eivätkä he suosi verkkosivuille sijoitettavia tekstinlukuohjelmia, eli heidän takiansa näitä ei sinänsä tarvita”, Vastamäki kertoo.

Rajoitteita omaaville käyttöpolku on erilainen kuin niille, joilla rajoitteita ei ole. Tämä otetaan huomioon myös koodissa.

“Ruudunlukijahan ei lue vaan pelkästään sitä tekstiä joka näkyy sivustolla, vaan se oikeastaan lukee HTML-koodia suoraan. HTML:ssä on piilossa asioita joita me näkevät emme näe. Tyypillisessä verkkosivustossa voi olla aika raskaskin valikko alavalikkoineen. Jos sitä lähtisi tabulaattorilla tai ruudunlukijalla käymään läpi, niin joka kerta kun avaa uuden sivun, täytyy käydä se päävalikko uudestaan läpi. Mikä on aika rasittavaa. Mutta HTML:ssä voi olla piilossa hyppylinkki, jossa lukee, että siirry suoraan sisältöön. Myös esimerkiksi lomakkeissa on paljon sellaista koodia, mikä tukee näkövammaista käyttäjää, mutta ei näy meille näkeville”, Vastamäki selittää.

Kun Vastamäeltä kysyy tärkeintä asiaa, mikä pitää digitaalisen tuotteen tai palvelun tuotekehityksessä ottaa huomioon käytettävyyttä ja saavutettavuutta arvioidessa, hän  alleviivaa käyttäjätestaamisen ja validoinnin tekemistä riittävän ajoissa. Apua kannattaa myös kysyä käytettävyys- ja saavutettavuusasiantuntijoilta, sillä se tuo tuotekehitykseen myös kustannustehokkuutta.

LUE LISÄÄ SAAVUTETTAVUUDESTA: Eficoden saavutettavuusopas

KIRJOITTAJA: Minna Kilpeläinen, FM, KM, HIPPA-hankkeen viestintäasiantuntija, freelancer-toimittaja