Tässä luvussa esitellään yleisellä tasolla tähän tutkimukseen valittuja tiedon esittä
misen menetelmiä. Luvun tarkoitus on pohjustaa työn empiiristä tutkimusta niiltä osin, joilta käytetyt menetelmät eivät ole lukijalle entuudestaan tuttuja.
6.1 Persoonat
Persoonat (engl. personas) ovat kuvitteellisia henkilöitä, joihin kiteytyvät tärkeim
pien käyttäjäryhmien pääpiirteet (Hyysalo, 2009). Menetelmänä persoonien laadin
ta on kohtalaisen uusi, sillä Alan Cooper esitteli persoonat 1990-luvun lopussa. Sen jälkeen menetelmä on hyväksytty nopeasti ja levinnyt laajalle. (Benyon et ah, 2010)
Persoona ei ole todellinen henkilö, tilastollinen keskiarvo, stereotypia tai markkina
segmentti (Hyysalo, 2009; Cooper, 2004). Se on suunnittelua varten luotu hahmo, jolla on tavoitteita ja toiveita sekä toimintaympäristö (Sinkkonen et ah, 2006). Li
säksi persoonalle annetaan nimi, kuva ja joukko yksityiskohtia, jotka auttavat suun
nittelijoita samaistumaan kuviteltuun hahmoon. Kuvassa 6 esitellään kolme eri ta
voin esitettyä esimerkkipersoonaa. Vaikka persoona on näennäisesti suunnittelijan mielikuvituksen tuotetta, sen tulee pohjautua vahvasti kerättyyn tutkimustietoon ja edustaa todellisen kohderyhmän oleellisia piirteitä. (Cooper, 2004) Sinkkonen et ah (2006) ohjeistavat valitsemaan persoonalle ne todellisen käyttäjäryhmän piirteet, jotka erottavat heidät käyttäjinä kaikista muista käyttäjäryhmistä.
Persoonan suurin hyöty on, että se auttaa suunnittelemaan tuotetta hyvin yhdelle, määritellylle käyttäjälle. Näin tuotteesta ei tule kompromissia, joka tarjoaa jokaiselle mahdolliselle käyttäjälle jotakin, muttei todellisuudessa vastaa yhdenkään käyttäjän tarpeita. Persoona myös pakottaa suunnittelemaan tuotteen ominaisuudet ennalta määritellyn käyttäjän mukaan. Muussa tapauksessa, kuten geneerisesti käyttäjäs
tä puhuessa, suunnittelijat kuvittelevat helposti käyttäjän ominaisuudet aina sen mukaan, miten ne sopivat kulloinkin käsiteltävään suunnitteluratkaisuun. (Cooper, 2004)
Paitsi että persoona auttaa eläytymään edustamansa käyttäjäryhmän tarpeisiin, toimintatapaan ja ongelmiin, se myös helpottaa kommunikointia muiden suunnitte
lijoiden ja toteuttajien kanssa (Sinkkonen et ah, 2006). Lisäksi persoona helpottaa konkretisoimaan käyttäjän taitotason ja antaa perspektiiviä tuotetuille ratkaisuille (Cooper, 2004). Persoonat voidaan muodostaa jo suunnitteluprosessin alkuvaihees
sa, jolloin niitä voidaan tarvittaessa täydentää myöhemmissä vaiheissa (Hyysalo, 2009).
Cooper (2004) suosittaa luomaan jokaiseen projektiin uudet persoonat, joita tulisi olla 3-12 kappaletta. Hyysalo (2009) suosittaa persoonien määräksi 3-7 kappaletta ja painottaa, että niissä tulisi olla mahdollisimman vähän päällekkäisyyksiä. Toisaal
ta Cooperin mukaan suunnitteluratkaisuja ei tarvitse muokata jokaiselle persoonalle
Pertti Polkija Ikä:26
Ammatti: Pyörälähetti
Koulutus: Biologian opinnot kesken Perhe: Ei perhettä
Harrastukset: Pyöräily, kiipeily, vaeltaminen Tekninen osaaminen:Tottunut korjailemaan harrastusvälineitä, käyttää tietokoneesta lähinnä tekstinkäsittelyä ja sähköpostia sekä kännykkäänsä puhumiseen ja tekstaamiseen Pertti on juuri aloittanut pyörälähettinä Helsingissä, ja kaikki paikat eivät vielä ole tuttuja. Hänellä on kymmeniä toimeksiantoja yhdessä päivässä, joista suurin osa löytyy jo rutiinilla...
Kuva 6: Kolme erilaista tapaa esittää persoona. (Hyysalo, 2009; Diniz et ai., 2007; Kan
kainen ja Parkkinen, 2001).
sopivaksi, vaan osa persoonista voidaan luoda jopa sitä varten, ettei ratkaisuja teh
dä heidän mukaansa, mikä selittänee eron suositellussa persoonamäärässä. Persoo
nien hiomisen jälkeen valitaan ensisijainen persoona, jolle suunnitteluratkaisut koh
dennetaan. Hyvin valittu ensisijainen persoona on sellainen, jolle muille persoonille suunnitellut ratkaisut eivät sellaisenaan sovi. Joskus ensisijaisia persoonia tarvitaan kaksi tai kolme, mutta tällöin myös suunnittellusta tuotteesta tarvitaan kaksi tai kolme eriytettyä versiota. Jos ensisijaisia persoonia tarvitaan neljä tai enemmän, on ongelma liian laaja, eikä sitä voida yksinkertaistaa persoonien avulla. (Cooper, 2004)
6.2 Toiminta- ja käyttötarinat eli skenaariot
Toiminta-ja käyttötarinat eli skenaariot (engl. scenarios) ovat kuvitteellisia tarinoi
ta, jotka sisältävät toimijoiden lisäksi tuotteet ja käyttöympäristön (Preece et ah, 1994). Usein toimijoina käytetään edellä esiteltyjä persoonia, jotka edustavat tuot
teen kohderyhmiä. Skenaario voidaan esittää kirjallisen kertomuksen lisäksi kuva- tarinana (engl. storyboard), videona tai parin minuutin näytelmänä ja sitä voidaan täydentää tarpeen mukaan piirroksilla, valokuvilla ja malleilla (Sinkkonen et ah,
2006). Kuvassa 7 on esimerkki äärimmilleen viedystä kuvatarinasta, jossa ei käytetä tekstiä tai ääntä lainkaan. Kirjoitetusta skenaariosta annetaan esimerkkejä luvussa 10.2.
Toimintatarina kuvaa persoonan toiminnan nykytilanteessa ja käyttötarina uuden tuotteen kanssa (Sinkkonen et ai., 2006). Molemmat skenaariotyypit tulisi kertoa tavallisella arkikielellä (Sinkkonen et ai., 2006) ja niiden tulisi kertoa joko päivittäi
sistä käyttötilanteista tai harvoin tapahtuvista, mutta erityisen tärkeäistä käytöistä (Cooper, 2004). Kuten persoonankin, tulee myös skenaarion pohjautua tutkimustu
loksiin, vaikka tulokset esitetään tarinamuodossa (Cooper, 2004). Skenaarioita käyt
tämällä voidaan hyödyntää ihmisen luontaista taipumusta välittää ja muistaa tietoa tarinoiden ja kertomusten avulla (Sinkkonen et ah, 2006).
Skenaariot auttavat ymmärtämään, hahmottamaan ja arvioimaan tehtyjä suunni
telmia (Benyon et ai., 2010). Lisäksi ne ovat keino kerätä, mallintaa ja tarkastella käyttötilanteita. Skenaarioiden etu on - aivan kuten persoonienkin - niiden konkreet
tisuudessa. (Sinkkonen et ah, 2006) Konkreettisuuden lisäämiseksi Shneiderman ja Plaisant (2005) suosittavat näyttelemään ja mahdollisesti myös videoimaan kaikki käyttäjien välistä vuorovaikutusta sisältävät skenaariot, jos se on suinkin mahdol
lista.
Skenaariot kertovat tuotteen käytöstä melko yleisellä tasolla. Niiden tarkoitus on sijoittaa tuotteen käyttö kontekstiin eli kuvailla käytön arkea ja käyttöympäristöä, jonka vuoksi ne eivät kuvaile tarkasti miten vuorovaikutus laitteen kanssa todel
la tapahtuu. Vuorovaikutuksen yksityiskohtia kuvaavaa tarinaa kutsutaan käyttö- kuvaukseksi (engl. use case). Käyttökuvauksia voidaan laatia skenaarioiden osille, jolloin ne kuvailevat, millä tavalla ja missä kohdissa suunniteltu teknologia tulisi tilanteeseen istumaan. (Hyysalo, 2009)
6.3 Käyttäjävaatimukset
Käyttäjävaatimukset (engl. user requirements) määrittelevät, mitä tuotteen pitää tehdä tai millainen sen tulee olla. Ne perustuvat tiedonkeruussa saatuun materiaa
liin, joka muokataan joukoksi yksiselitteisiä, mutta selkokielisiä vaatimuksia, joita kaikki osapuolet ymmärtävät teknisestä taustastaan riippumatta. Yleensä käyttä
jävaatimukset esitetään kirjallisesti, mutta niiden esittämisessä voidaan hyödyntää myös piirroksia, valokuvia, prototyyppejä, videota tai muuta selkeyttävää oheisma
teriaalia. (Robertson ja Robertson, 2006; Benyon et ah, 2010)
Käyttäjävaatimukset keskittyvät käyttäjän tarpeisiin, eivätkä tuotteen ominaisuuk
siin (Young, 2002). Ne ovat siinä mielessä abstrakteja, ettei niissä oteta kantaa tuot
teen tekniseen toteutukseen. Ne eivät kerro käytettäviä laitteita, ohjelmointikieliä tai käyttöliittymäelementtejä, vaan nämä kaikki otetaan mukaan vasta myöhemmin tuotetta suunnitellessa. Esimerkiksi vaatimus ”Järjestelmä kysyy salasanaa kirjau- tumisvaiheessa” määrittää järjestelmän toimintaa turhan tarkasti. Sen voisi ilmaista
tarvelähtöisemmin esimerkiksi näin: ”Vain tunnistetuilla käyttäjillä on pääsy luot
tamukselliseen tietoon.” (Robertson ja Robertson, 2006)
Eri vaiheissa määrittely- ja suunnitteluprosessia syntyy erilaisia vaatimuksia. Tutki
muksen alkuvaiheessa, johon tämä työ sijoittuu, pysyvät vaatimukset sangen yleisellä tasolla. Suunnittelun edetessä ja käyttökokemuksen kertyessä vaatimukset tarkentu
vat, kehittyvät tai jopa muuttuvat uuden tiedon myötä. (Robertson ja Robertson, 2006)
Käyttäjävaatimukset voidaan jakaa kahteen osaan, jotka ovat toiminnalliset ja epä- toiminnalliset vaatimukset. Yleensä, joskaan ei aina, käyttäjävaatimusten laatiminen aloitetaan toiminnallisista vaatimuksista, jotka kertovat, mitä tuotteen pitää tehdä.
Tämän jälkeen siirrytään epätoiminnallisiin vaatimuksiin, jotka käsittelevät järjes
telmän ominaisuuksia. (Robertson ja Robertson, 2006; Benyon et ab, 2010) Esimer
kiksi toiminnallinen vaatimus voisi määrittää, että järjestelmän tulee mahdollistaa muistiinpanojen tekeminen muun käytön ohessa. Siihen liittyvä epätoiminnallinen vaatimus voisi puolestaan vaatia, että muistiinpanojen tekemisen on oltava nopeaa.
Varsinaisten vaatimusten lisäksi suunnittelussa voi olla muita, ulkoa päin tulevia ra
joitteita, joihin suhtaudutaan kuten varsinaisiin vaatimuksiin (Robertson ja Robert
son, 2006). Näitä voisivat olla esimerkiksi, että tuotteen pitää olla valmis tiettyyn päivään mennessä tai että se saa maksaa enintään tietyn summan asiakkaalle.
Hyvän käyttäjävaatimuksen voi esittää yhdellä lauseella. Jos sen esittämiseen tarvi
taan useita lauseita, on vaatimus liian laaja ja usein pilkottavissa useiksi vaatimuk
siksi. (Robertson ja Robertson, 2006) Tämän yhdessä lauseessa esitettävän idean lisäksi vaatimukselle määritellään tarkat ja testattavat kriteerit, joiden avulla usein abstraktilta tuntuvan vaatimuksen toteutumista voidaan mitata, sekä perustelut, jotta lukijan on helpompi hahmottaa, kuinka vaatimukseen on päädytty (Benyon et ah, 2010). Lisäksi vaatimukset kannattaa arvottaa tärkeysjärjestykseen, sillä usein käytettävissä olevat resurssit eivät riitä kaikkien vaatimusten täyttämiseen (Young, 2002).
Kuva 7: Kuvatarina, joka kertoo kuinka trooppista tunnelmaa luova ihmematto piristää päähenkilön aamua. (Muokattu harjoitustyöstä Diniz et ai. 2007)