Avainsana-arkisto: käyttäjätutkimus

käyttötilannehaastattelu, kontekstuaalinen haastattelu, etnografia, tavoiteanalyysi, tehtäväanalyysi, käyttötilanne, käyttöyhteys, skenaario, persona, korttien lajittelu, kysely, fokusryhmä

1. Ymmärrä tuettavan toiminnan tilanteet ja tavoitteet. Tuottaa vaatimuksia. 2. Havainnollista toimiva ratkaisu. Tuottaa palautetta.

Ketterä versio ihmiskeskeisen suunnittelun standardista (ISO 13407)

En taustoittanut aiemmassa artikkelissa esittämääni käyttäjäkeskeisen suunnittelun prosessimalliluonnosta. Vaikka käyttäjäkeskeisestä ja ihmiskeskeisestä suunnittelusta on julkaistu kehittyneitä ja vertaisarvioituja menetelmiä, näitä termejä käytetään arjessa löyhästi. Esittelen tässä ISO 13407 -standardissa kuvatun ihmiskeskeisen suunnittelun prosessimallin ja sen pohjalta luonnostelemani kevyemmän mallin, joka lähestyy standardia käytännön näkökulmasta.

ISO 13407 kuvaa vuorovaikutteisten järjestelmien ihmiskeskeisen suunnittelun. Sen sisältämässä prosessimallissa (kuva alla) tehdään neljää toimintaa (activity):

  1. Käyttöyhteyden ymmärtäminen
  2. Tavoitteiden asettaminen
  3. Ratkaisujen suunnittelu
  4. Ratkaisujen arvointi
1. Käyttöyhteyden ymmärtäminen 2. Tavoitteiden asettaminen 3. Ratkaisujen suunnittelu 4. Ratkaisujen arvointi

Kuva: © Tuuli Mattelmäki, 2006

Kaavio kuvaa syklisen prosessin, joka vastaa kokemukseni mukaan tiedonkulkua ja oppimista suunnittelutyössä, mutta ei sen työvaiheita, koska samassa arjen hetkessä voi tapahtua montaa ISO:n toiminnoista. Esimerkiksi käyttökokemusta arvioidessaan kannattaa yleensä pyrkiä kasvattamaan ymmärrystä paitsi olemassaolevan ratkaisun käytettävyydestä, myös sen käyttöyhteydestä eli missä tilanteessa sitä käytetään ja miksi. Montaa ISO:n toimintoa voi tapahtua yhdessä hetkessä myös suunnittelutilanteessa, kun syntyy oivallus käyttötilanteesta ja sen asettamista vaatimuksista, sekä samalla jo hahmotelma vaatimukset täyttävästä ratkaisusta.

Ihmiskeskeisen suunnittelun voi mielestäni pelkistää kahdeksi toiminnaksi. Näistä ensimmäinen on käyttötilanteiden ja tavoitteiden ymmärtäminen, toinen ratkaisujen havainnollistaminen (kuva alla). Karkeasti ottaen näitä suunnittelutyön kahta osaa voisi kutsua myös nimillä tutkimus ja suunnittelu, mutta tutkimus on kovin juhlava sana seuraaville esimerkeille.

1. Ymmärrä tuettavan toiminnan tilanteet ja tavoitteet. Tuottaa vaatimuksia. 2. Havainnollista toimiva ratkaisu. Tuottaa palautetta.

Palvelu- ja vuorovaikutussuunnittelijalta tilattavat kokonaisuudet ovat yleensä melko laajoja, jolloin yksi ”kierros suunnittelua” kestää joitakin viikkoja. Esimerkkinä toimikoon Finna.fi -tiedonhakupalvelu, jonka käyttökokemuksesta vastaan, ja jonka käyttötilanteet kartoitin viime vuonna. Uskottavia käyttötilanteita oli tunnistettu ja kerätty projektissa jo aiemmin, enkä lähtenyt tekemään varsinaista käyttäjätutkimusta. Empiirinen tiedonkeruu ei ollut tässä tapauksessa välttämätöntä myöskään, koska Finna.fi on laajalle käyttäjäryhmälle suunnattu palvelu, jonka käyttötilanteista moni oli minulle ja muille tiimissä entuudestaan tuttu ”oman elämän etnografian” kautta eli omasta elämänkokemuksesta.

Analysoin Finna.fi:n käyttötilanteet ja luokittelin ne kolmeen luokkaan, jotka ovat temaattinen haku, teoshaku ja selaileva haku. Temaattista hakua on esimerkiksi materiaalin keruu musiikintutkija A. O. Väisäsestä TV-dokumenttia tai tutkimusta varten. Tenttikirjan etsiminen olisi teoshakua. Selailevassa haussa käyttäjän päämäärä ei ole aina kovinkaan konkreettinen, esimerkiksi kun taiteentutkija surffailee materiaalia taideteoksesta tulevien tutkimustensa mahdollisiksi aiheiksi. Tein käyttötilannekartoituksen ja tavoiteanalyysin muutaman kuukauden kuluessa, mikä ei ollut kokoaikaista työtä, koska suunnittelimme ja Scrum-kehitystiimi toteutti samalla palveluun käyttöliittymäparannuksia. Idea moneen käyttöliittymäparannukseen nousi käyttötilanteiden läpikäymisestä, ja toteutustehtäviä myös priorisoitiin sen perusteella, kuinka monessa esimerkkitilanteessa ongelma toistui. Poimin ne käyttötilanteet, joissa oli riittävät taustatiedot käyttökokemuksen arviointiin, myöhemmin suunnittelussa hyödynnettäviksi. Jätin viisitoista – kaksikymmentä käyttötilannetta pois, koska niistä ei ollut riittäviä tietoja käytön ”simuloimiseen” asiantuntijatyönä. Olen käynyt esimerkkitilanteet läpi suunnittelutyön edetessä muutaman kuukauden välein, jotta käyttötilanteet ja käyttäjien tavoitteet säilyvät minun ja kehitystiimin mielissä, ja jotta ”pysyn kartalla” Finna.fi:n käyttökokemuksesta ja käytettävyydestä todellisissa käyttötilanteissa.

Ylävalikko ennen muutosta, Tietoa-valikko auki

Ylävalikko muutoksen jälkeen: Tietoa-valikko poistettu

Pienen osakokonaisuuden suunnittelu, kuvat ennen ja jälkeen.

Myös pienempien osakokonaisuuksien käytettävyyden parantaminen etenee joskus ”ihmiskeskeisen suunnittelun kierroksina”. Esimerkiksi kun sisällytimme palveluun listan mukana olevista organisaatioista, se oli aluksi vaikea löytää, koska valikon ykköstason linkkiteksti ei houkutellut avaamaan sitä. Ylemmässä kuvassa vasemmalla on tämä ensimmäinen versio. Organisaatiot-linkki siirrettiin myöhemmin valikon ykköstasolle, missä se on heti näkyvillä (alempi kuva). Tämän käytettävyysparannuksen suunnittelu ja toteutus kesti yhteensä alle henkilötyöpäivän.

Käyttäjäkeskeinen ja ihmiskeskeinen suunnittelu tarkoittavat tässä ja aiemmassa artikkelissani samaa asiaa, vaikkakin ihmiskeskeisessä suunnittelussa käytännön suunnitteluprosessi ja asiakkaan tarpeet korostuvat, kun taas käyttäjäkeskeisessä painottuu tuotteen ja loppukäyttäjän välinen vuorovaikutus. Termin käyttäjäkeskeinen suunnittelu on esitellyt Don Norman teoksessaan The Design of Everyday Things, jonka voi ladata verkosta ilmaiseksi.

Käyttäjäkeskeinen suunnitteluprosessi: ensimmäinen luonnos

suunnitteluprosessi

Hyvä palvelu- ja käyttökokemussuunnittelija tekee kahta asiaa: ymmärtää tuotteeseen tai palveluun kohdistuvat tarpeet ja luo ne täyttäviä ratkaisuja.Luomisen ja ymmärtämisen vaiheet seuraavat toinen toisiaan.

Luo. Luomisvaiheessa hahmotellaan tuote tai palvelu pitäen loppukäyttäjien tavoitteet ja asiakkaan liiketoimintatavoitteet suunnittelun lähtökohtana. Tuloksena syntyy konkreettisia havainnekuvia, joista loppukäyttäjät ja liiketoiminta-asiakkaat osaavat sanoa, täyttävätkö ne omat tarpeet ja tavoitteet vai eivät.

Ymmärrä. Ymmärryksen hankkimisvaihe tuottaa ymmärrystä sekä arvioitavien ”rautalankojen” toimivuudesta että käyttäjien ja asiakkaiden tarpeista ja tavoitteista. Havainnekuvien käyttö nostaa esiin käyttökokemuksen kannalta tärkeitä asioita, jotka jäävät helposti huomaamatta. Ymmärryksen hankkimisvaihe auttaa myös löytämään kokonaan uusia toimintamalleja, joita ei aiemmin ole ajateltu, koska se luo vuoropuhelua eri näkökulmien välille.

suunnitteluprosessi, toteutusvaihe
Ihmiskeskeinen suunnittelu toteutusvaiheissa.

Rakenna. Kuva yllä esittää suunnittelun varhaisia vaiheita, joissa toteutusta ei vielä ole aloitettu. Tekijätiimillä on hyvä olla kokonaiskuva tuotteen tai palvelunrakenteesta, ja käyttäjän vuorovaikutuksesta sen kanssa, ennen kuin toteutus alkaa. Suunnittelun yksityiskohdat täsmennetään toteutuksen aikana.

Käytettävyystesti ja kontekstuaalinen haastattelu

tumblr_lf0wsbb5871qziezc

Käytettävyystesti ja kontekstuaalinen haastattelu ovat hyvin samanlaisia. Monilla asiantuntijoilla tosin on taipumus keskittyä käytettävyystesteissä kapea-alaisiin, tarkasti ennalta rajattuihin kysymyksiin. Tällainen lähestymistapa ei jätä juurikaan varaa perehtyä käyttäjien toimintaan, todellisiin kokemuksiin ja käyttötilanteisiin. Sen sijaan kontekstuaalisissa haastatteluissa kysymykset ja tehtävät pidetään usein avoimina ja ne liittyvät käyttäjien todelliseen toimintaan. Raja käytettävyystestin ja kontekstuaalisen haastattelun välillä on häilyvä, samaan tapaan kuin rakenteellisessa ja temaattisessa haastattelussa.

Monilla designereilla tuntuu olevan kielteinen asenne käytettävyystestausta ja -tutkimusta kohtaan. Uskon, että tämä johtuu käytettävyyden kapeasta mieltämisestä ja helppojen voittojen strategiasta, joita molempia Jakob Nielsen on voimakkaasti ajanut. Laajemmassa merkityksessä käytettävyys tarkoittaa, miten tarkoituksenmukainen, käytännöllinen ja miellyttävä palvelu tai tuote on todellisille käyttäjille todellisissa käyttötilanteissa. Tämä on käytettävyyden ”todellinen” merkitys, joka on määritelty ISO-standardissa 9241. Käytettävyys on paljon enemmän kuin suuria fontteja ja kontrasteja, kun sitä kehitetään tarkoituksenmukaisesti ja kontekstuaalisesti.

Käytettävyystestin rakenne

usability_test_comicsHuomaan, että järjestän käytettävyystestitehtävät yleensä seuraavalla tavalla:

  1. Käyttäjän omat tehtävät.

    ”Mitä teit viimeksi kun käytit tätä? […] Näytä, miten toimisit siinä tilanteessa.”

  2. Ennalta asetetut tehtävät.

    ”Tyttöystävälläsi on huomenna syntymäpäivä. Haluat ostaa elokuvaliput teille molemmille. Miten toimisit?”

  3. Katselmointitehtävät.

    ”Tutustu tähän [järjestelmän osaan tai toimintoon], ja kerro vapaasti mitä ajattelet.”

Tällä järjestyksellä pyrin minimoimaan aiempien tehtävien priming-vaikutukset. Priming-vaikutus tarkoittaa, että se mitä olet tehnyt hetkeä aiemmin vaikuttaa, miten ratkaiset ongelmia ja toimit nyt.

Laadun vaikutelma ei takaa käyttökokemusarvion laatua

Harry Houdini Käytettävyysasiantuntijan ja -asiakkaan vuorovaikutuksessa asiantuntijuuden kehittäminen ei aina paranna asiakkaan palvelukokemusta. Tähän johtavat seuraavat voimat:

  1. Ongelmalähtöisyys. Asiantuntija arvioi asiakasta, tämän kehittämää palvelua ja tämän toimintaa etsien ongelmakohtia palvelun kehittämiseksi.
  2. Asiantuntijuus. Asiantuntija tuntee osaamisalansa usein paremmin kuin asiakas.
  3. Palvelukokemus. Ongelmista kuuleminen on asiakkaalle usein epämiellyttävää.
  4. Palveluliiketoiminta. Asiakas valitsee parhaaksi katsomansa asiantuntijan.

Ulkoistettu käytettävyysasiantuntija on jäävi antamaan puolueetonta lausuntoa asiakkaansa palvelun ongelmakohdista. Asiantuntija on jäävi, koska hänen taloudellinen tuloksensa on riippuvainen asiakastyytyväisyydestä. Koska asiantuntijan tehtävänä on asiakkaan heikkouksien esiin tuominen, palvelun laadun parantuminen saattaa vaikuttaa käänteisesti asiakkaan palvelukokemukseen. Asiantuntijan liiketoiminnan kannalta on usein tuottoisampaa huolehtia oman asiantuntijapalvelun palvelukokemuksesta kuin asiakkaan tarjoaman palvelun palvelukokemuksen kehittämisestä.

Lopputuloksen kannalta käyttäjävaatimukset kannattaisi huomioida mahdollisimman varhain, mutta käytettävyysyritykselle on tuottavinta testata mahdollisimman valmiita ja ennakoitavia prototyyppejä. Lisäksi asiantuntijan työstä asiakkaalle syntyvä tuottavuusmielikuva on tärkeä asiakkaan luottamuksen voittamisessa. Tuottavuuden vaikutelma on käytettävyysyritykselle usein arvokkaampaa kuin asiakkaan tuottavuuden todellinen parantaminen.

Nähdäkseni edellä mainitut ongelmat ovat ratkaistavissa huomioimalla käytettävyysnäkökulmat jo suunnitteluvaiheessa. Lisäksi jatkuva yhteistyö asiakkaan kanssa vaikuttaa hedelmällisemmältä yhteistyön kehykseltä kuin lyhyet, ”puolueettomat” arviointiprojektit.