Blogi 4.6.2014

Jos metsään haluat mennä nyt… Käyttäjälähtöisyys pitää sinut oikeilla raiteilla

Gofore

Kiva kun löysit tämän artikkelin! Se sisältää varmasti hyvää tietoa, mutta pidäthän mielessä, että se on kirjoitettu 10 vuotta sitten.

Valitettavan usein käyttöliittymäsuunnittelijan elämä on kuin suojaisi kukkaistutuksia sateenvarjolla raekuurossa. Tiedät, että tehtävä on lähes mahdoton. Tiedät, että voit suojella vain osan istutuksista, mutta silti tahdot yrittää. Kun löytää itsensä tuosta tilanteesta, tietää pahimman jo tapahtuneen sekä tekevänsä jotain järjetöntä.
Mitä sitten on tapahtunut? Käyttöliittymäsuunnittelija on tilanteessa, jossa hänelle satelee määrittelyjä, jotka pohjautuvat… Ai niin, kukaan ei taida tietää mihin. Hänellä on edessään huono määrittely, joka ei kuvaa sitä, mikä on olennaista käytettävän lopputuloksen saavuttamiseksi. Käyttäjälähtöinen määrittely on jäänyt tekemättä.
Käyttöliittymäsuunnittelun yksi tärkeimmistä fundamentaaleista on vastaus kysymykseen ”Miksi?”. Jos suunnittelija ei tiedä, miksi käyttäjä haluaa tehdä jonkin asian, hänen on hyvin vaikea muodostaa määrittelyn pohjalta käytettävää käyttöliittymää. Kysyt ehkä miksi. Annan sinulle esimerkin – käyttäjän tulee voida valita asioita listalta.
Kuulostaa yksinkertaiselta, vai mitä? Ammattitaitoinen käyttöliittymäsuunnittelija kaipaa kuitenkin vastausta kysymykseen ”Miksi?”. Koska tätä tietoa ei ole tarjolla, suunnittelija joutuu arvailemaan muun muassa, mitä tietoja käyttäjä tarvitsee voidakseen valita oikeat asiat listalta ja kuinka monta kohtaa hän tyypillisesti valitsee, jotta voidaan tehdä valintaan soveltuva työkalu. Tämän yksinkertaisen tiedon puuttuminen saattaa johtaa väärien käyttöliittymäkomponenttien valintaan, jotka eivät tue käyttäjän todellista tarvetta. Vaikutus voi tuntua pieneltä, mutta näin käyttöliittymäsuunnittelijan näkökulmasta ero on merkittävä. Käyttöliittymien toimintaperiaatteita on laaja kirjo. Ymmärrys käyttäjän syistä ja tarpeista antaa näkemyksen, jonka perusteella ammattitaitoinen käyttöliittymäsuunnittelija valitsee juuri tilanteeseen sopivan toimintaperiaatteen. Ilman tätä ymmärrystä mennään metsään.
Kuinka tämä uhkakuva sitten vältetään? Tärkeää luonnollisesti on se, että kerran kerätty tieto käyttäjien tarpeista ja käyttötilanteista kulkee toteutuksen mukana. Ketterässä ohjelmistokehityksessä, jossa järjestelmää toteutetaan käyttäjätarina kerrallaan, ei ole mitenkään vaikeaa kuljettaa käyttäjätarinan mukana tarvittavia tietoja. Käyttäjän tulee voida valita asioita listalta, jotta hän voi vertailla niiden sisältöjä. Valitettavaa kuitenkin on, että usein virhe on tapahtunut jo paljon aiemmin kuin käyttäjätarinoita kirjoittaessa. Virhe on tapahtunut siinä, miten määrittelyn pohjalla oleva tietämys on kerätty.
Voi sitä ärtymyksen ja turhautumisen määrää, mikä minuakin on piinannut useissa projekteissa. Ne ovat niitä hetkiä, kun kokee suojaavansa kukkaistutuksia sateenvarjolla. Edessäsi on määrittely, jonka alkuperän tiedät vääräksi. Määrittely on tullut pelkästään joltain muulta kuin järjestelmän todelliselta käyttäjältä. Jos ongelma oli ”Miksi?”, niin ongelma on myös ”Kuka?” ja ”Miten?”. Valitettavan usein, edelleen, järjestelmien määrittely tehdään komiteoissa ja pelkästään organisaation johtoa haastattelemalla. Taas ollaan menossa metsään ja vauhdilla. En sano, että tämä on väärin. Sanon, että tämä ei yksin riitä. Näin toimiessa saadaan lähes poikkeuksetta vain organisaation näkemys siitä, mitä järjestelmällä tulisi saavuttaa. Syntyy määrittely, joka kuvastaa organisaation johdon näkemyksiä tavoitellusta lopputuloksesta. Syntyy toimintalähtöinen määrittely. Erittäin tärkeä tieto tämäkin, mutta se tärkein substanssiosaaja on juuri jäänyt kuulematta. Metsään mennään ja aurinkoranta on vielä vain haaveena.
tienviitta
Käyttäjä on paras osaaja kertomaan, mitä hän tarvitsee, jotta hän voi tehdä työtään hyvin. Mitä hän tarvitsee, jotta hän voi mahdollisimman hyvin ja tehokkaasti saavuttaa sen lopputuloksen, jota organisaatio häneltä kaipaa. Olipa kyseessä järjestelmän uudistus tai aivan uuden sovelluksen luominen, käyttäjä tietää parhaiten, mitä hän tarvitsee. Käyttäjä on järjestelmän kovin substanssiosaaja niistä tietotarpeista, joita hän sujuvan työskentelyn kannalta tarvitsee. Hän on myös oikein osallistettuna erittäin hyvä innovaattori, joka kykenee kehittämään organisaation toimintatapoja. Käyttäjä on se henkilö, joka sanoo ”Ei ole mitään järkeä, että…”.
Saatoit ehkä kiinnittää huomiota, että sanoin käyttäjän kertovan. Kyllä, tällä tarkoitetaan myös käyttäjältä kysymistä ja käyttäjän kanssa tehtävää yhteistä pohdintaa tai esimerkiksi käyttäjän observointia. Kun ammattilainen tarkkailee käyttäjää luonnollisessa ympäristössä todellisen työtehtävän äärellä, saadaan sellaista ymmärrystä, joka täydentää käyttäjien sanat todellisuudeksi. Observoinnin avulla voidaan tunnistaa käyttäjien tiedostamattomat tietotarpeet ja ongelmat. Hyvin tehty käyttäjätyö, haastatteluja ja observointeja hyödyntämällä, yhdistää käyttäjiltä saatavan subjektiivisen ja objektiivisen datan. Käyttäjä katsoo järjestelmää laatikon sisäpuolelta, käyttäjätyön ammattilainen laatikon ulkopuolelta. Kun tämä ammattilainen on tehnyt laadukasta työtä tunnistaen laatikon molemmat puolet, hän ymmärtää mistä laatikossa on kyse. Ilman käyttäjää ei saada sellaista lopputuotetta, joka toimii tehokkaasti ja helppokäyttöisesti omassa toimintaympäristössään.
Kyse on siis toimintalähtöisen ja käyttäjälähtöisen määrittelyn yhdistämisestä. Molemmat kuvaavat muodostuvaa järjestelmää omista näkökulmistaan. Kumman tahansa pois jättäminen aiheuttaa joko ongelmia järjestelmän toiminnan tavoitteiden tai tavoitteiden tehokkaan saavuttamisen kanssa. Huonoa käytettävyyttä ja tehotonta työskentelyä. Ei kuulosta minusta modernilta järjestelmältä. Suurin harmitus tästä tulee, kun tiedän, miten asiat voisivat olla. Olen Goforella ollut tekemässä useita käyttäjälähtöisen määrittelyn projekteja yhdessä toimintalähtöisen määrittelijän kanssa. Näissä projekteissa olen nähnyt, kuinka laadukas määrittely edesauttaa merkittävästi korkean käytettävyyden saavuttamista. Goforella käyttäjälähtöinen ja toimintalähtöinen määrittely kulkevat aina yhdessä. Tämän tekstin opit kumpuavat niistä projekteista, joissa virheet on tehty ennen meidän saapumista mukaan kuvaan.
Mitä sinulle tästä jutusta pitäisi sitten jäädä mieleen? Väärin laadittu ja käytetty määrittely vie sinut varmasti metsään. Minä taas tahtoisin mennä aurinkoiselle rannalle. Uskon, että niin tahdot sinäkin ja kaikki muutkin käyttäjät.
 

Takaisin ylös