North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.
Eihän se käyttäjä klikkausten määrään turhaudu, vaan siihen, että klikkauspolku ei ole seurattava: käyttäjä ei hahmota, mitä seuraavaksi pitäisi/kannattaisi klikata, tai ei pysty ennakoimaan mitä klikkauksesta tapahtuu. Ja jos virheklikkaus tapahtuu, ei löydä klikkausta, jolla virhe korjattaisiin.
Kuinka monta klikkausta on liikaa??
Moni käyttäjä tekee palvelupolullaan tyytyväisenä kymmenittäin klikkauksia, jos prosessi on sujuva, hahmotettava, hallittava ja ymmärrettävästi tavoitteeseen ohjaava.
Tähän palvelupolun sujuvuuteen tähtäävät Jacob Nielsenin klassiset käytettävyyden laatuperiaatteet: opittavuus, tehokkuus, muistettavuus, virheiden ehkäisy ja miellyttävyys.
Noista periaatteista ehkä ainoastaan miellyttävyys joutuu koetukselle, jos käyttäjän on pakko naksutella tolkuton määrä klikkauksia onnistuakseen toiminnassaan. Tässäkin tapauksessa kiduttavaa on vain se, jos klikkaukset ovat ilmeisen turhia: klikkauksesta avautuva näkymä olisi esimerkiksi yhtä hyvin voinut olla valmiiksi auki, tai matkan varrella on turhan paljon varmistuksia, joihin pitää vain todeta ”OK”.
(Mutta auta armias, jos se varmistusdialogi ”OK / Peruuta” puuttuu juuri silloin, kun jokin virheklikkaus tuli tehtyä! Toiselle turhauttava ”ylimääräinen klikkaus” onkin toiselle pelastusrengas.)
Monilla suunnittelijoilla on suorastaan nyrkkisääntönä jokin maaginen luku sille, kuinka monen klikkauksen päässä käyttäjän etsimä tieto/palvelu saa korkeintaan olla. Mutta mistä laskien? Etusivultako? Vai miltä tahansa sivulta, jolle käyttäjä voi Googlesta laskeutua? Jos käyttäjä pääsee etsimänsä tiedon äärelle ymmärrettävästi (=opittavasti) ja muistettavasti, virheitä tekemättä, on palvelun käyttö tehokasta, huolimatta siitä montako klikkausta matkan varrella joutuu tekemään.
Tehokkuuden mittari on aika, ei klikkausten määrä
Käytettävyyden laatuperiaatteena käytön tehokkuus tähtää siihen, että tietty toiminto saadaan tehdyksi nopeasti. Mittarina on siis tehtävään käytetty aika. Vaikka jokainen sivulataus (tai muu klikkauksesta seuraava tilan vaihtuminen) vie jonkin verran aikaa, ei tehtävän läpivientiin tarvittava kokonaisaika synny klikkauksista, vaan niiden välissä tapahtuvasta ajattelusta ja hiiren siirtelystä.
Oikopolku on käyttöliittymissä tyypillinen toiminnan tehostamisen keino: keskeisellä paikalla (etusivulla, ylätunnisteessa, alatunnisteessa) tarjotaan suora linkki rakennehierarkiassa syvällä olevaan tietoon. Tämä parantaa ilman muuta käytettävyyttä: jos käyttäjä oppii oikopolun, ja muistaa sen vakiopaikan vastaisuudessakin, hän pääsee yhdellä klikkauksella usein tarvitsemansa tiedon äärelle.
Mutta haluaisitko, että verkkokaupan 5000 tuotetta olisivat kaikki yhden klikkauksen päässä, oikopolkuina etusivulla??
Käyttöpolulla tarvittavien klikkausten vähentäminen tarkoittaa vääjäämättä sitä, että yhdessä näkymässä on enemmän klikattavia kohteita, joista pitää löytää ja osua tarvitsemaansa linkkiin. Ymmärrettävyys, opittavuus ja virheiden ehkäisy kärsivät, eli käytettävyys huonontuu.
Toiminnon läpiviemiseen tarvittavaan aikaan on siis laskettava myös se aika, jonka käyttäjä klikkaustensa välissä tuijottaa käyttöliittymää, lukee sen tekstejä, silmäilee näkymän elementtejä, vierittää näkymää, siirtelee katsettaan käyttöliittymän kohdasta toiseen ja lopulta siirtää fokuksensa/hiirensä seuraavaan klikattavaan kohteeseen.
Motorinen tehokkuus tarkoittaa sitä, että käyttäjän vuorovaikutus käyttöliittymän kanssa on sähäkkää ja fokusoitunutta: katsetta ja hiirtä on nopeaa siirtää polttopisteestä toiseen, syöttökentästä toiseen tai tarvittavasta klikkauksesta seuraavaan klikkaukseen.
Jos käyttöliittymä hiotaan motorisen tehokkuuden näkökulmasta äärimmäisen optimoiduksi ja tiiviiksi, siitä syntyy kompakti paketti, jossa elementit ovat tosi lähellä toisiaan eikä pinta-alaa tuhlata selityksiin tai tyhjään tilaan. Toimintojen käyttäminen on nopeaa, mutta ei välttämättä kovin opittavaa ja ymmärrettävää. Ja virheklikkauksiakin saattaa lipsahtaa helpommin.
Kumpi sitten on tärkeämpi käytettävyyden kriteeri: tehokkuus vai opittavuus?
Satunnaiset käyttäjät vs. tehokäyttäjät
Hyvän käytettävyyden nyrkkisääntöjä on vaikea antaa, koska käyttäjät ovat erilaisia ja palvelut ovat erilaisia. Laatuperiaatteet on priorisoitava palvelun käyttötapojen mukaan.
Jos satunnainen käyttäjä tulee kerran vuodessa kukkakaupan sivustolle tekemään kukkatilauksen, on tärkeintä kiinnittää huomiota tilausprosessin ymmärrettävyyteen eli opittavuuteen – tilauksen läpiviennin vaatima aika ei ole kovin merkityksellistä. Jos samaa kukkakauppaa hyödyntää päivittäin juhlapalvelun järjestäjä, on huolehdittava, että tällä on käytössään oikopolkuja ja pikavalintoja tilauksen joutuisaan tekemiseen – pikavalinnat eivät kuitenkaan saa hämmentää sitä satunnaista käyttäjää.
Kun jokainen suomalainen saattaa hoitaa veroilmoituksensa täyttämisen vuosittain tai passitilauksensa neljän vuoden välein, on tällaisissa asiointipalveluissa kyseessä isot rahat tai vakavat lakisääteiset asiat: asiointiprosessissa on kriittistä, että käyttäjälle on pläkkiselvää, mitä hän tekee, mitä tuli ilmoittaneeksi tai mihin tuli sitoutuneeksi. Virheiden ehkäisy on verottajan tai poliisin palvelussa paljon tärkeämpää kuin tehokkuus.
Vasta kun tietojärjestelmä on tarkoitettu päivittäiseksi työkaluksi, nousee tehokkuus tärkeimmäksi laatukriteeriksi. Jos järjestelmää käytetään arkityön tukena, sen avulla läpivietävien prosessien pitää olla virtaviivaisia ja sähäköitä. Järjestelmän kanssa tappeluun kuluva aika voi olla elämän ja kuoleman kysymys, kuten toteavat ne yli 600 lääkäriä, jotka ovat tehneet kantelun potilastietojärjestelmä Apotista.
Monimutkaisen tietojärjestelmän käyttöliittymien suunnittelussa on melkoista hienosäätötyötä tasapainoilla sen välillä, kuinka mutkikkaiden toimintojen kirjo saadaan paketoitua tehokkaan kompaktiksi, mutta ymmärrettäväksi työkaluksi. En tunne Apottia, mutta en usko, että sen kirjausprosesseista voidaan saada klikkausten määrää kovinkaan vähäiseksi.
Jos Apotin ongelmia ja niiden korjausvaihtoehtoja lähtisi kvantifioimaan, en käyttäisi mittarina klikkausten määrää, vaan yksittäisen toiminnon läpiviennin vaatimaa aikaa. Ja sekin pitäisi mitata erikseen rutinoituneilta tehokäyttäjiltä ja satunnaisilta hoitajilta.
Miksi Sisusta tuli painajainen?
Aamulehden julkaisemassa jutussa ”Tamperelainen yliopisto-opiskelija yritti ilmoittautua kurssille, mutta joutui klikkaamaan yli 60 kertaa – Sisu-järjestelmä on painajainen etenkin vanhoille opiskelijoille” on mukana video, joka esittelee erinomaisen valaisevasti Sisu-järjestelmän käytettävyysongelmia. Videon katselija jakaa ilman muuta käyttäjän tuskan siitä, kuinka mahdottomalta yksinkertainen kurssi-ilmoittautuminen tuntuu.
Mutta ongelman ydin eivät ole ne 60 klikkausta. Videolla läpikäyty ”tehtävä” ei ole itse asiassa yksioikoinen ilmoittautumisprosessi, vaan siinä käyttäjä tutustuu kurssitarjontaan, tarkistaa yksittäisen kurssin suoritusvaihtoehdot, sijoittaa kurssin omaan opintosuunnitelmaansa ja sitten ilmoittautuu kurssille. Ei kai näiden prosessien voi olettaakaan hoituvan ihan parilla klikkauksella?
Omaan silmääni näyttäisi siltä, että Sisun käytettävyysongelmien juurisyynä ovat ne lukuisat toimintoprosessit, jotka on yhdistetty samaan järjestelmään mahdollisimman tehokkaasti.
Sisun käyttöliittymänäkymien suunnittelussa vaikuttaisi olevan kantavana periaatteena laaja kokonaiskuva: elementtejä, toimintovaihtoehtoja ja kontrolleja on haluttu näyttää mahdollisimman pitkälle isossa kontekstissa, yhdessä valtavassa kanvaasinäkymässä. Tällä on mahdollisesti pyritty varmistamaan hallinnan tunne ja järjestelmän hahmotettavuus; kaikkien toimintoprosessien tehokas saatavuus yhdessä näkymässä?
Tuosta isosta kokonaiskuvasta seuraakin sitten se, että yksittäisen toimintaprosessin ohjaus ikävästi sirpaloituu. Nappula, jota käyttäjän pitäisi omassa tilanteessaan ”seuraavaksi” klikata, voi sijoittua ylhäälle tai alhaalle tai reunaan tai jäädä jonkin välilehden taakse. Tämä vaatii käyttäjältä sitä, että on itse pidettävä tiukasti fokuksessa sitä, mitä toimintoa on juuri suorittamassa, ja ymmärtää sen loppuunviennin vaatimat toimet.
Sisu vaikuttaa tosiaankin paljon enemmän ”opintojen suunnittelutyökalulta” kuin ”ilmoittautumiskoneelta”. Yksittäiselle kurssille ilmoittautuminen on pieni sivupolku siinä kokonaiskuvassa, jossa opiskelija hallinnoi omia suorituksiaan koko yliopiston koulutustarjonnassa. Niinpä ohjaus yksittäisellä sivupolulla ei ole kovin yksiselitteistä.
Monessa Sisun aukiklikattavassa kohdassa olisi selkeämpää avata klikkauksista uusia ikkunoita, joihin mahtuisi enemmän vaihtoehtojen selitystä ja selvempiä valintakohtia, joista käyttäjä voisi viedä tietyn prosessin hallitusti päätökseen, ja joista käyttäjä ohjattaisiin loogisesti seuraavaan näkymään.
Tällaisen yksittäisen toimintaprosessin läpivientiä varten on olemassa paljon käytännön standardeja, joiden avulla asiointi on junan lailla etenevää. Hyvänä esimerkkinä onkin VR:n täysremontoitu lipputilausjärjestelmä, jolla hämmentyneinkin käyttäjä pystyy viemään läpi reittivalinnan, junan valinnan, paikan varauksen ja matkan maksamisen.
Mutta kyseessä onkin yksittäinen, selkeärajainen toimintaprosessi. Sisu olisi epäilemättä selkeämpi järjestelmä, jos se olisi purettu useammaksi työkaluksi, joissa kurssitarjonta, ilmoittautumiset, omien suoritusten hallinta jne. olisivat toisistaan erillisiä kokonaisuuksia. Mutta onko ”opintotietojärjestelmä” edes purettavissa tuollaisiin erillisiin prosesseihin? Moisesta ratkaisusta seuraisi varmasti uusia, vähän erilaisia käytettävyysongelmia :-)
Ja sitä paitsi järjestelmän pilkkominen aiheuttaisi epäilemättä käyttäjälle jälleen lisää klikkauksia, jos niitä joku laskee.
Käyttäjätyytyväisyys luotettavimpana mittarina
Niin Sisun kuin Apotinkin ongelmallisuudesta ei liene epäselvyyttä: käyttäjät ovat sankoin joukoin nostaneet haloon tyytymättömyydestään järjestelmän toimintaan. Sitä ei pidä lakaista maton alle senkään varjolla, että korjaustoimenpiteet ovat vaikeita.
Jos käyttäjät eivät osaa eivätkä opi, on turha syyttää käyttäjiä: vika on järjestelmässä. Käyttöliittymiä tehdään käyttäjille.
Ja todellisena taklattavana ongelmana ei ole tarvittavien klikkausten määrä tai ehkä edes prosessin läpiviennin vaatima aika, vaan se että opiskelijat eivät onnistu ilmoittautumaan kurssille, tai että potilasturvallisuus vaarantuu.
Ongelmanratkaisun ensimmäisenä askeleena on laadullinen käyttäjätutkimus siitä, mitä käyttäjät eivät ymmärrä, osaa tai opi; mitkä ovat ne kohdat prosessia, joissa käyttäjät menevät metsään. Korjaukset vaativat muutoksia tekstityöhön, käyttöliittymäelementteihin, näkymien taittoon, ulkoasuun, prosessien vaiheistukseen ja toimintalogiikkaan.
Kun näihin haetaan korjaustoimenpiteitä, voidaan toki mittariksi ottaa vaikkapa jokin tavoiteaika, jossa prosessi pitäisi keskimääräisesti onnistua viemään läpi. Mutta kaikkein olennaisin mitattava asia on kyllä käyttäjätyytyväisyys.
Käytettävyys on aina muodikasta
North Patrolin suunnittelutyössä kiinnitetään johdonmukaisesti huomiota siihen, että digipalveluista tulee mahdollisimman ymmärrettäviä, opittavia, tehokkaita, asiakaskunnalle saavutettavia ja kaikin puolin miellyttäviä käyttää. Palvelumuotoilulla ja prototyypeillä haetaan toimivat ratkaisut, joiden havainnollista esittelyä organisaation sisällä tuetaan osuvilla mallinnuksilla.
PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme:
Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00).
Ilmoittaudu webinaariin
Lue palveluistamme
Pyydä tarjous
