Miksi käyttäjäkokemus on usein paljon muutakin kuin itse ohjelmiston käyttöä? Visma Aquilan työaikajärjestelmien käyttäjäkokemuksen kehittämisestä vastaava UX Lead Atte Hakala avaa blogissaan, mitä on käyttäjäkokemus ja miten se syntyy.
"Robotti suunnittelee työvuoroni, eikä huomioi henkilökohtaisia tarpeitani". Kutakuinkin näin voisi tiivistää lehtikirjoitukset työntekijöiden tuntemuksista, kun sairaanhoitopiiri pilotoi tekoälyavusteista työvuorosuunnittelua muutama vuosi sitten. Epäluuloisuus uutta teknologiaa kohtaan voi olla määräävä tekijä käyttäjäkokemuksen syntymisessä.
Työvoimanhallinnan ohjelmistojemme tekoälyä on sovellettu jo pitkään esimerkiksi työvuorolistojen optimoinnissa, ja tyypillisesti se päihittää ihmissuunnittelijan monellakin mittarilla mitattuna. Työntekijän päällimmäinen käyttäjäkokemus järjestelmästä voi kuitenkin syntyä aivan muista asioista kuin itse käytöstä. Esimerkiksi tekoälyavusteisesti suunniteltua työvuorolistaa lukiessaan työntekijää luultavasti kiinnostaa ensisijaisesti miten monta hänen työ- ja vapaapäivätoiveistaan on toteutunut. Tällaisten syy-seuraus–suhteiden ymmärtäminen on avainasemassa, kun kehitämme ohjelmistoja, joiden haluamme parantavan ihmisten elämää.
Tässä kirjoituksessa tarkastelen käyttäjäkokemusta ja sen syntymiseen vaikuttavia tekijöitä hieman pintaa syvemmältä, erityisesti operatiivisten yritysohjelmistojen näkökulmasta.
Puhuttaessa käytettävyydestä ja käyttäjäkokemuksesta on hyvä ymmärtää niiden merkitykselliset erot.
Käytettävyys on ISO-standardin* mukaisesti mitta sille, missä määrin tietyt käyttäjät pystyvät suorittamaan määriteltyjä tehtäviä määritellyissä käyttötilanteissa tuloksellisesti, tehokkaasti ja tyytyväisesti. Käytettävyyttä voidaan siis mitata kolmessa ulottuvuudessa:
Käyttäjäkokemus puolestaan kattaa kaikki järjestelmän käytöstä seuraavat havainnot, tuntemukset ja reaktiot, sekä järjestelmää koskevat ennakko-olettamat ja mielikuvat. Käyttäjäkokemus on puhtaasti omakohtainen tuntemus, joka perustuu tietysti merkittävän paljon juuri käytettävyyteen, mutta lisäksi myös käyttäjän odotuksiin, ennakkokäsityksiin, aiempiin kokemuksiin, jopa luonteeseen ja kulttuuriseen taustaan. Tämän takia käyttäjäkokemusta ei voi suoranaisesti suunnitella – voi vain suunnitella mahdollisimman hyvät edellytykset halutunlaisen käyttäjäkokemuksen syntymiselle. Samasta syystä kahdelle eri käyttäjälle voi syntyä identtisestä käyttötilanteesta täysin erilainen käyttäjäkokemus.
Kun käytettävyys rajautuu tarkastelemaan itse käyttötilannetta, voi käyttäjäkokemus syntyä myös käyttötilanteen ulkopuolella. Jos esimerkiksi järjestelmä tykittää käyttäjän puhelimeen push-ilmoituksia ympäri vuorokauden, voi hän kokea järjestelmän kuormittavaksi ja häiritseväksi, eli käyttäjäkokemus on tältä osin negatiivinen.
Hyvä käyttäjäkokemus syntyy, kun tuote tai palvelu vastaa käyttäjän odotuksiin ja tarpeisiin ja jopa ylittää ne. Hyvä käyttäjäkokemus vaatii aina myös onnistuneen teknisen toteutuksen, mutta kokemukseni mukaan valtaosassa tapauksia huonon käyttäjäkokemuksen juurisyy on puutteellinen ymmärrys ihmisistä ja heidän tavoitteistaan.
Vaikka automaatio on jo vuosikymmeniä siirtänyt triviaalia tekemistä käyttäjiltä koneelle ja tekoälykin tekee kovasti tuloaan, on merkittävä osa järjestelmien organisaatioille tuottamasta arvosta edelleen riippuvaista siitä, että käyttäjät onnistuvat järjestelmän käyttämisessä. Automaation ja tekoälyn käyttöön ottaminen eivät poista tarvetta käyttäjäkokemussuunnittelulle, mutta suunnittelun kohde voi muuttua. Jos kone pystyykin tuottamaan tuloksia itsenäisesti ilman käyttäjän ohjausta, on itse tuloksilla lopulta joku ihminen loppukäyttäjänä. Ovatko tulokset virheettömiä, käyttökelpoisessa muodossa, ajantasaisia ja oikeaan aikaan saatavilla? Pystyykö ihminen tarvittaessa tarkistamaan tulokset tai tekemään niihin korjauksia?
Omaa työtäni käyttäjäkokemuksen parissa ohjaavat muun muassa seuraavat kolme oppia. Niitä noudattaen voimme kehittää Solveonin ohjelmistoista asiakkaillemme entistä parempia.
Tämä lienee olennaisin oppimani asia tuotekehityksestä: kukaan ei voi korvata oikeaa käyttäjää tiedonlähteenä. Järjestelmän tilaajan pääkäyttäjä ja loppukäyttäjän lähijohtaja varmasti tietävät monia asioita käyttäjien arjen haasteista ja organisaation toimintatavoista yleisellä tasolla. Järjestelmätoimittajalla voi olla muista organisaatioista kerättyä ymmärrystä aiheesta. Mutta vain oikeat loppukäyttäjät pystyvät kertomaan yksityiskohtaisella tasolla arjestaan ja kohtaamistaan haasteista. Ratkaisujen käytettävyys on myös testattava nimenomaan loppukäyttäjillä, koska tositilanteessa heidän on selvittävä järjestelmän käytöstä itsenäisesti. Käyttäjäkokemussuunnittelijan rooli tässä yhtälössä on valita työkalut ja menetelmät loppukäyttäjien tarpeiden syvälliseen ymmärtämiseen ja ratkaisuehdotusten objektiiviseen testaamiseen.
Opin tämän omakohtaisesti käyttäjäkokemussuunnittelijan urani alkuvaiheessa. Rakensimme ratkaisua lääkäreille pelkästään ylilääkärin näkemysten ja kommenttien perusteella, osallistamatta loppukäyttäjiä millään tavalla. Lopputulos oli kylmä suihku: järjestelmä teki teknisesti ottaen aivan oikeita asioita, mutta lääkärit tyrmäsivät ratkaisun huonon käytettävyyden vuoksi täysin eivätkä alkaneet käyttää sitä. Opimme virheestä, yritimme uudelleen – tällä kertaa loppukäyttäjiä osallistaen – ja nyt Numeronista löytyy omatoimisen työvuorojen varaamisen mahdollistava Vuorotori.
Sekä ohjelmistoyritykset että ohjelmistoja tilaavat organisaatiot sortuvat tyypillisesti puhumaan "käyttäjistä" geneerisesti. Oikeassa elämässä käyttäjä ei kuitenkaan ole geneerinen olento vaan ihminen tietyssä ammattiroolissa, tietyssä tilanteessa ja tietyllä taustalla, yrittämässä saavuttaa tiettyä tavoitetta.
Ajatellaanpa vaikka työvuoro- ja vapaatoiveita. Työntekijän tavoitteena on perustella työnantajalle mahdollisimman hyvin, mitkä olisivat työn ja vapaa-ajan yhteensovittamisen kannalta hänelle mieluisimmat työajat. Työvuorosuunnittelijan ensisijainen tavoite puolestaan on pyrkiä toteuttamaan työyksikön kaikkien työntekijöiden toiveet mahdollisimman tasapuolisesti, kuitenkin niin, että organisaation operatiivinen toiminta on turvattu ja työaikalainsäädäntöä noudatetaan.
Käyttäjän roolin ja tavoitteen lisäksi asiayhteyttä eli käyttökontekstia määrittävät monet muutkin näkökulmat:
Haastattelut ja kyselyt sekä käyttökontekstissa vieraileminen ovat alalla yleisesti käytettyjä menetelmiä, jotka on yleensä helppo toteuttaa, ja ne lisäävät sekä tilaajan että toimittajan ymmärrystä käsillä olevasta haasteesta ja asiayhteydestä ratkaisevalla tavalla. Jo käytössä olevan järjestelmän tapauksessa tuoteanalytiikka kertoo lahjomattomasti, miten käyttäjät järjestelmää todella käyttävät.
Kehitimme menneenä keväänä Numeron-työvoimahallintaan yhteisöllisen työvuorosuunnittelun. Tässä tuotekehitystyössä kontekstin ymmärtäminen oli avainasemassa, koska siinä kohtasivat erilaiset käyttäjät, käyttötilanteet ja tavoitteet: työntekijät toiveineen, esihenkilöt vastuullisina lainmukaisista työvuorolistoista sekä työnantaja palvelutasovelvoitteineen.
Vaikka ratkaisu ei ole vielä täydellinen, jo ensimmäinen tuotantoon julkaistu versio on saanut erittäin hyvän vastaanoton, ja pilottiyksikön lähijohtajan kommentti olikin: "Vanhaan emme palaa.".
Tuotekehityksessä tulee vastaan hetki, jolloin on maltettava lopettaa yhden asian hiominen ja siirryttävä seuraavan haasteen pariin. Tämä voi tuntua ristiriitaiselta, onhan tarkoituksena kehittää mahdollisimman hyvää ohjelmistoa. Kuitenkin, mitä pidempään hilloat tuoteominaisuutta omalla työpöydälläsi, sitä pidempään käyttäjät joutuvat odottamaan ratkaisua tarpeeseensa. Toisekseen, yksityiskohtia kiillottamalla tarjoat käyttäjille todennäköisesti vähemmän hyötyä kuin paneutumalla vielä täysin ratkaisemattomaan käyttäjätarpeeseen.
Kolmas syy liittyy ratkaisun toimivuuden todentamiseen. Mikään määrä ennalta toteutettua käyttäjätestausta ei anna sataprosenttista varmuutta, että ratkaisu kestää kaikki arjen koettelemukset. Käytännön elämässä käyttäjä operoi tositilanteessa, mahdollisesti paineen alaisena ja vastaan saattaa tulla harvinaisia poikkeustilanteita, joita tuotekehitystiimi ei ole onnistunut etukäteen tunnistamaan. Mitä nopeammin edes pieni käyttäjäkunta (ns. pilottiryhmä) pääsee käyttämään ratkaisua tosielämässä, sitä nopeammin nämä tietämyksen aukot paljastuvat.
Iso kokonaisuus kannattaa pyrkiä jakamaan pienempiin osakokonaisuuksiin niin, että edes jollekin käyttäjäkunnalle (esimerkiksi yhdelle käyttäjäroolille) voidaan julkaista joitain hyödyllisiä ratkaisuja mahdollisimman aikaisin. Tällöin kehittämiseen käytetty aika ja vaiva alkaa tuottamaan arvoa pian (niin sanottu time-to-value) ja käyttäjäpalautetta päästään keräämään aikaisin. Esimerkiksi tärkeät perusominaisuudet kannattaa rakentaa ja julkaista ensin ja vasta sitten keskittyä edistyneisiin tai harvinaisia käyttötapauksia palveleviin lisäominaisuuksiin. Käyttäjät myös omaksuvat uudistukset paremmin, kun ne tarjoillaan pienissä paloissa.
Ositeltu eteneminen toimii myös järjestelmän käyttöönottoprojekteissa, joissa tuotteesta luodaan väistämättä ensivaikutelma loppukäyttäjille. Iso käyttöönotto on hyvä toteuttaa vaiheittain rajatuille käyttäjäjoukoille. Jos haasteita ilmenee, ne koskevat kerrallaan mieluummin kymmentä kuin tuhatta käyttäjää – erityisesti käyttöönoton alkupäässä, jolloin järjestelmästä ei ole vielä käytännön käyttökokemuksia kyseisessä organisaatiossa. Tietojärjestelmät ovat kompleksisia ja niiden käyttöönotoissa vastaan tulee todennäköisesti jonkin kokoisia haasteita, joten on parempi valmistautua niiden kohtaamiseen kuin antaa itsensä tulla yllätetyksi. Start small, start with one!
Viestintä loppukäyttäjien suuntaan on tärkeää. Heidän tulee tiedostaa, että ensimmäisillä käyttäjillä voi ilmetä ennakoimattomia haasteita, mutta niiden ratkaisemiseen on ammattilaiset valmiudessa. Sen lisäksi, että organisaatio viestii työntekijöidensä suuntaan, on varmistettava myös työntekijöille sujuva kanava viestiä kokemuksistaan takaisin työnantajan ja toimittajan suuntaan.
Järjestelmähankintaa valmisteleville organisaatioille antaisin tämän vinkin: sen sijaan, että pyrkisitte varmistamaan käytettävyyden yksityiskohtaisilla toiminnallisilla vaatimuksilla, selvittäkää keinoja arvioida jo olemassa olevan tuotteen käytettävyyttä sekä toimittajan kykyä ja halua rakentaa käytettäviä ratkaisuja myös tulevaisuudessa. Pyytäkää näyttöjä siitä, että käytetävyystyötä todella tehdään, eikä vain lupailla. Tuotedemo paljastaa osaltaan, mitkä toimittajat osaavat käytettävyystyön parhaiten. Käytettävyystesteillä voi pyrkiä todentamaan opittavuutta ja helppokäyttöisyyttä, mutta muistakaa testitehtäviä laatiessanne konteksti ja realismi: lainmukaisen työvuorolistan suunnittelu on käyttäjälle paljon monimutkaisempi ongelmien vyyhti kuin vaikkapa hampurilaisen tilaaminen.
Muistakaa, että olette tekemässä vuosikausien sitoumusta järjestelmään. Merkityksellistä ei siis ole vain se, mitä ohjelmisto on tänään, vaan myös mitä se on huomenna. Kun toimittajalla on omilla palkkalistoillaan käytettävyysalan ammattilaisia, tuotteen käytettävyys on todennäköisemmin turvattuna myös tulevaisuudessa. Solveonin ohjelmistoissa tekemistämme ohjaavat hyväksi todetut parhaat käytännöt, jotka virtaviivaistavat asiakkaamme prosesseja eikä kaikkea tarvitse keksiä alusta asti.
* ISO 9241-210:2019: Human-centred design for interactive systems
usability: extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use
user experience: user’s perceptions and responses that result from the use and/or anticipated use of a system, product or service