Käyttöliittymät II  (syksy 2004)

2  Käyttötapaukset

Sari A. Laakso & Antti Latva-Koivisto

Sisällys

2.1 Sama käyttöliittymä tukee monia tilanteita

2.2 Eri käyttötapauksesta erilainen käyttöliittymäratkaisu

2.3 Käyttötapaukset realistisina tilanneasetelmina

2.3.1 Kiinnitetyt toiminnot

2.3.2 Yleistetyt tilanteet

2.4  Muunlaiset kuvaukset suunnittelun syötteenä

2.4.1 Skenaariot

2.4.2 Persoonat

Lähteet

 

Viimeistään silloin, kun valmis järjestelmä otetaan käyttöön, käyttäjät ryhtyvät tekemään järjestelmän avulla työtehtäviään ja yrittävät suoriutua heille päivittäin eteen tulevista tilanteista. Jotta nämä käyttötilanteet eivät tulisi ohjelmiston kehitysprojektissa yllättäen eteen vasta hyväksymistestausvaiheessa tai jopa vasta käyttöönoton jälkeen, järjestelmän määrittely kannattaa perustaa näihin tilanneasetelmiin jo alusta lähtien.

Kun selvitämme ja määrittelemme heti projektin alussa ne käyttötilanteet, joiden suorittamista järjestelmän on tarkoitus tukea, voimme johtaa järjestelmässä tarvittavat toiminnot ja tietosisällön niistä. Realististen käyttötilanteiden avulla pystymme myös jäsentämään toiminnot ja tiedot käyttöliittymään siten, että näytön organisointi vastaa käyttäjän käsillä olevaa työtehtävää ja siirtymistä tehtävästä toiseen. Lisäksi pystymme rajaamaan järjestelmän siten, että rajaus on mahdollisimman optimaalinen suhteessa käyttötilanteisiin.

2.1  Sama käyttöliittymä tukee monia tilanteita

Kun konkreettisia käyttötilanteita selvitetään käyttöliittymäsuunnittelun syötteeksi, aluksi saattaa vaikuttaa siltä, että erilaisia tilanteita on satoja tai tuhansia, mahdollisesti jopa enemmän kuin erilaisia käyttäjiä. Tässä vaiheessa monen suunnittelijan mielessä herää kysymys siitä, voidaanko suunnittelua käytännössä mitenkään perustaa käyttötilanteiden varaan, jos erilaisia käyttötilanteita on näin paljon. Riittävän kattavan selvityksen tekeminen saattaa vaikuttaa suunnattoman kalliilta tai mahdottomalta.

Käyttötilanteita lähemmin tarkastelemalla kuitenkin ilmenee, että valtava määrä erilaisia käyttötilanteita on niin lähellä toisiaan, että sama käyttöliittymäratkaisu palvelee tehokkaasti niitä kaikkia. Erilaisten käyttötilanteiden määrä saadaan pudotettua hyvin pieneksi, kun samanlaiset käyttötilanteet osataan tunnistaa ja niputtaa samaan kategoriaan. Toisaalta käytännön suunnittelutyössä jo muutama lähes satunnaisestikin valittu käyttötilanne vaikuttaa sisältävän hämmästyttävän paljon kattavuutta: kun otamme suunnitteluun mukaan pari konkreettista tilannetta, niiden avulla suunnitellusta käyttöliittymästä menee valtava määrä muitakin tapauksia läpi hyvin.

Tärkeintä tilanteiden laatimisessa on se, että tilannekuvaukset perustuvat konkreettiseen, jollekin esimerkkihenkilölle todellisuudessa eteen tulevaan tilanteeseen tai tapahtumaan. Jos tilanteet ovat konkreettisia, jo 4-5 tilanneasetelman ottaminen mukaan esimerkiksi hotellivarausjärjestelmän suunnitteluun vaikuttaa kattavan paljon useampia tosielämässä eteen tulevia tilanteita kuin ilman konkreettisia käyttötilanteita tehty suunnittelu. Kattavuutta arvioitaessa kannattaa huomata, että järjestelmän ei tarvitse tukea lainkaan sellaisia tilanteita, joita ei tosielämässä esiinny tai jotka käyttäjien kannattaa aina hoitaa järjestelmän ulkopuolella.

Seuraavan esimerkin avulla havainnollistetaan, kuinka aivan erilaisten käyttäjien erilaisilta vaikuttavat käyttötilanteet edustavatkin itse asiassa samaa tilannekategoriaa ja siten johtavat samanlaiseen käyttöliittymäratkaisuun. Esimerkkijärjestelmänä on parturikampaamon web-palvelu, josta asiakkaat voivat katsoa parturien vapaita aikoja ja tehdä sitten varauksensa puhelimitse.

Ensimmäinen käyttötilanne kuvaa tietotekniikka-alan yrittäjänä toimivan esimerkkikäyttäjä Karrin parturikäyntiä (kuva 2.1). Skenaariossa kuvataan mahdollisimman realistisesti ne tapahtumat, jotka liittyvät Karrin ajanvaraukseen ja parturissakäyntiin.

Joululoman jälkeen yksityisyrittäjänä toimivan Karrin tukka alkaa olla taas leikkauksen tarpeessa, ja parturissakäynti olisi hyvä hoitaa pois jaloista, ennen kuin asiakasprojektit taas pyörähtävät täysillä käyntiin. Maanantaiaamulla 12.1. Karri varaa itselleen ajan tiistaiksi 20.1. Hänellä on silloin palaveri uuden projektin tiimoilta iltapäivällä klo 13-15 Pitäjänmäessä, joten Karri ottaa vakioparturiltaan Veskulta iltapäiväajan klo 16-17. Tiistaina 20.1.

Karri on hyvissä ajoin Pitäjänmäellä palaverissa, mutta asiakkaan edustaja tulee paikalle 20 minuuttia myöhässä. Palaveri venyy yli kaksituntiseksi, koska kaikille on epäselvää, mitä projektissa kannattaisi tehdä, ja Karri pääsee lähtemään vasta klo 15.35. Hän arvelee ehtivänsä vielä juuri ja juuri ajoissa perille, mutta iltapäivän ruuhkan takia hän myöhästyy viisi minuuttia. Onneksi Vesku kuitenkin on vasta rahastanut edellisen asiakkaan, kun Karri saapuu paikalle, eikä sen kummempaa harmia pääse syntymään.

Kuva 2.1. Karrin skenaario.

Kuvassa 2.2 esitetty käyttöliittymäratkaisu on laadittu tukemaan edellä kuvattua Karrin tilannetta. Kuvan tilanteessa Karri avaa järjestelmän ja näkee oman parturinsa Veskun kuluvan viikon ajat, joita hän on tarkastellut edelliselläkin käyttökerralla. Hän etsii omasta kalenteristaan sopivia aikoja, jotka osuisivat Veskun vapaisiin aikoihin ja huomaa seuraavan viikon tiistai-iltapäivän. Hän soittaa parturiliikkeeseen, jossa Ilona vastaa puhelimeen ja varaa Karrille ajan Veskulta tiistai-iltapäiväksi.

Kuva 2.2. Karrin skenaariota tukeva käyttöliittymä.

Seuraavaksi määrittelemme käyttötilanteen aivan erilaiselle käyttäjälle, 66-vuotiaalle eläkeläiselle Niilolle (kuva 2.3). Vaikka esimerkkihenkilö ja tilanne ensi silmäyksellä saattavat vaikuttaa täysin erilaisilta kuin kuvassa 2.1 esitetty Karrin tilanne, kuvan 2.2 käyttöliittymäratkaisu palvelee myös Niilon käyttötilannetta hyvin ja suoraviivaisesti.

Niilo, 66-vuotias aktiivinen ja tietokoneita käyttävä eläkeläinen, on varaamassa itselleen seuraavaa parturiaikaa, koska edellisestä käynnistä on kulunut jo puolitoista kuukautta. Hän huomaa, että seuraavan viikon sunnuntaina 20.6. pidetään hänen tyttärentyttärensä Millan rippijuhlat, joten parturissa voisi käydä mieluiten ennen tuota viikonloppua. Hänellä ei ole viikonloppua edeltävänä torstaina eikä perjantaina mitään erityistä tekemistä, joten hän päättää varata parturiajan torstaiksi klo 11.30 Jaanalta, jonka parturoitavana hän on käynyt jo monta vuotta. Jaana on näpsäkkä ja huumorintajuinen nainen, jonka kanssa on mukava turista.

Kuva 2.3. Niilon skenaario.

Kun Niilo alkaa käyttää kuvan 2.2 käyttöliittymää skenaarionsa mukaisesti, hän saa järjestelmän käynnistämisen jälkeen näkyviinsä Jaanan kuluvan viikon ajat. Sen jälkeen hän valitsee kalenterista näkyviin seuraavan viikon, tarkastelee torstain vapaita aikoja ja päättää pyytää itselleen aikaa torstaille klo 11.30. Niilo soittaa parturiliikkeeseen, jossa Jaana itse sattuu vastaamaan puhelimeen ja varaa Niilolle ajan torstailta.

Kuvassa 2.4 esitetään vielä kolmas esimerkkihenkilö, yksinhuoltajaäiti Niina, jonka vakiokampaaja Kristel on juuri tullut äitiyslomalta takaisin töihin. Myös Niinan tapauksessa kuvassa 2.2 esitetty käyttöliittymäratkaisu toimii erinomaisesti. Kun hän avaa järjestelmän, hän näkee äitiyslomalta palanneen Kristelin parturilistassa ja klikkaa hänen aikansa näkyviin. Järjestelmä näyttää oletuksena kuluvaa viikkoa, josta hän toteaa, että lauantaiaamu voisi olla hyvä ajankohta.

Niinalla on tänään maanantaina 31.5. palkkapäivä, ja palkassa on mukana ylityökorvauksia alkukuun ylitöistä. Niina ei ole käynyt kampaajalla moneen viikkoon; viimeksi hänen ystävättärensä siisti hiuksia kotikonstein. Nyt kun rahaa on vähän enemmän, Niina päättää nauttia ja käydä ottamassa hiuksiinsa jonkin ihanan käsittelyn. Niina tietää, että hänen vanha vakiokampaajansa Kristel on luultavasti tullut nyt reilun vuoden kestäneeltä äitiyslomaltaan takaisin töihin, joten hän päättää varata ajan vanhasta tutusta parturikampaamosta. Tosiaan, Kristel on jo töissä! Koska Niinalla on tällä viikolla työvuoro joka päivä klo 16 asti ja Kristelillä on vapaita aikoja vain klo 17 asti, Niina ottaa itselleen parin tunnin ajan ensi lauantailta klo 10-12. Niinan tytär Elli voi olla sen aikaa yksin kotona katsomassa lauantaiaamun lastenohjelmia.

Kuva 2.4. Niinan skenaario.

Edellisessä esimerkissä olemme saaneet katettua samalla käyttöliittymäratkaisulla kolmen aivan erilaisen käyttäjän kolme erilaista tilannetta. Kun tarkastelemme yhä uusia tosielämän skenaarioita, löydämme suuren joukon ensivaikutelmaltaan erilaisia käyttötilanteita, joista valtaosa kuitenkin paljastuu olennaisilta osiltaan hyvin samanlaisiksi. Näin saamme vähennettyä erilaisten suunnittelussa tuettavien tilanteiden määrää niin radikaalisti, että tilanteet pysyvät suunnittelun kannalta hallinnassa.

Kuvassa 2.5 edellä esitetyt käyttötilanteet on analysoitu ja ne on jäsennetty tavoitepohjaisiksi käyttötapauksiksi, joissa tilanneasetelmien virittävät tiedot on nostettu esille (alleviivaukset). Virittävät tiedot ovat niitä, joiden perusteella käyttäjä tekee päätöksentekoa ja jotka vaikuttavat käyttöliittymäratkaisuun, eli kuvan 2.5 tapauksessa käyttäjän tuntemalla vakioparturilla käyminen ja tietämättömyys parturin vapaista ajoista (joita kuitenkin todellisuudessa löytyy). Kuvan 2.5 kaikissa esimerkkitilanteissa käyttöliittymäratkaisuun vaikuttavat kriittiset tiedot ovat samat. Eroja löytyy ainoastaan esimerkkidatasta, kuten henkilöiden nimet ja vapaat aikavälit. Nämä käyttötapaukset ovat siis variaatioita samasta käyttötapauksesta.

Käyttötapaus 1a:
Karrin seuraava käynti Veskulla

Käyttötapaus 1b:
Niilo ennen rippijuhlia Jaanalle

Käyttötapaus 1c:
Niinan seuraava käynti Kristelillä

Karrin tavoite: Tietotekniikka-alan yrittäjä Karri on käynyt leikkauttamassa hiuksiaan parturikampaamo HAIR:issa vakioparturillaan Veskulla jo useamman vuoden ajan. Hiukset ovat kasvaneet niin paljon, että niitä olisi syytä leikata, mutta hän ei tiedä Veskulle sopivia ajankohtia.

Niilon tavoite: Eläkeläinen Niilo on käynyt leikkauttamassa hiuksiaan parturikampaamo HAIR:issa vakioparturillaan Jaanalla jo kymmenen vuoden ajan. Hiukset ovat kasvaneet niin paljon, että niitä olisi syytä siistiä ennen seuraavan viikon sunnuntain rippijuhlia, mutta hän ei tiedä Jaanalle sopivia ajankohtia.

Niinan tavoite: Kenkäkaupan myyjänä työskentelevä yksinhuoltajaäiti Niina on käynyt parturikampaamo HAIR:issa vakioparturillaan Kristelillä jo useamman vuoden ajan, mutta Kristel on välillä ollut äitiyslomalla reilun vuoden. Hiukset ovat taas kasvaneet niin paljon, että niitä olisi syytä leikata, mutta hän ei tiedä Kristelille sopivia ajankohtia.

Tilatietoja

·                      Nyt on ma 12.1.2004 klo 8.45.

·                      Karri on työpaikal­laan Vuori­miehenkadulla.

Karrin menot

·                      Karrin työkalenteri on hyvin täynnä 22.1. lähtien.

·                      <Muut Karrin kalenterissa olevat työkiireet>

Parturi Veskun varaustilanne

·                      <Veskun varaustilanne>

Parturiliike HAIR          

·                      Parturikampaamo HAIR sijaitsee osoitteessa Uudenmaankatu 15.

·                      HAIRissa on viisi työntekijää: Ilona, Jaana, Kristel, Vesku ja Mikko.

Tilatietoja

·                      Nyt on ti 8.6.2004 klo 8.45.

·                      Niilo on kotonaan Töölössä.

Niilon menot

·                      Ke 16.6. päiväretki Nokian Edeniin.

·                      Su 20.6. tyttärentyttären rippijuhlat.

Parturi-kampaaja Jaanan varaustilanne

·                      <Jaanan varaustilanne>

Parturiliike HAIR          

·                      Parturikampaamo HAIR sijaitsee osoitteessa Uudenmaankatu 15.

·                      HAIRissa on viisi työntekijää: Ilona, Jaana, Kristel, Vesku ja Mikko.

Tilatietoja

·                      Nyt on ma 31.5.2004 klo 17.50 ja palkka on juuri tullut tilille.

·                      Niina on kotonaan Mellunmäessä.

Niinan menot

·                      Niina on tällä viikolla töissä Itäkeskuksessa joka päivä klo 8-16.

Kampaaja Kristelin varaustilanne

·                      <Kristelin varaustilanne>

Parturiliike HAIR          

·                      Parturikampaamo HAIR sijaitsee osoitteessa Uudenmaankatu 15.

·                      HAIRissa on viisi työntekijää: Ilona, Jaana, Kristel, Vesku ja Mikko.

Kuva 2.5. Karrin, Niilon ja Niinan skenaarioita vastaavat käyttötapaukset.

Kun tarkastelemme esimerkiksi Karrin skenaariota pidemmältä ajanjaksolta, kuten puolen vuoden ajalta, havaitsemme, että sama käyttötapaus 1a toistuu hieman erilaisena variaationa yhä uudelleen: Karri varaa puolen vuoden aikana monta kertaa seuraavan ajan vakioparturiltaan. Vastaava tilanne toistuu myös Niinan ja Niilon kohdalla. Siten saman käyttötapauksen variaatioita esiintyy paitsi eri henkilöiden välillä, myös saman henkilön kohdalla, kunhan tarkastelemme riittävän pitkää aikaväliä.

2.2  Eri käyttötapauksesta erilainen käyttöliittymäratkaisu

Osa esimerkkihenkilöiden skenaarioissa esiintyvistä käyttötilanteista on aidosti erilaisia tilanneasetelmia, joihin tarvitaan erilaiset käyttöliittymäratkaisut. Alla esitetyt parturin ajanvarausjärjestelmän käyttötapausesimerkit 1-3 on valittu siten, että jokaisesta käyttötapauksesta syntyy käyttöliittymään hieman erilaista tietosisältöä ja erilainen tietojen organisointi.

Kuvan 2.6 tilanneasetelmassa jatkuvasti samalla vakioparturilla käyvän Juhanin pitäisi saada hiuksensa leikkautettua lähipäivinä. Kyseessä on siis neljäs variaatio samasta käyttötapauksesta kuin edellisessä aliluvussa esitetyt käyttötapauksen 1 variaatiot 1a-1c.

Käyttötapaus 1: Vakioparturi Veskulle lähipäivinä

 

Juhanin tavoite: Opiskelija Juhani on käynyt leikkauttamassa hiuksiaan parturikampaamo HAIR:issa Veskulla jo useamman vuoden ajan. Nyt hänen hiuksensa ovat taas kasvaneet niin paljon, että niitä olisi syytä leikata, mutta hän ei tiedä Veskun vapaita aikoja.

 

 

Kuva 2.6. Käyttötapaus 1 ja sitä vastaava datanäkymä.

Käyttötapauksen 1 seurauksena syntyvän käyttöliittymän tietosisältökin organisoidaan täsmälleen samalla tavalla kuin kuvan 2.2 käyttöliittymässä. Juhania palvelee parhaiten datanäkymä, jossa hänen on mahdollista fokusoitua vakioparturiinsa (Vesku), jonka vapaat ajat on visualisoitu (kuva 2.6). Vapaita aikoja kannattaa näyttää mahdollisimman paljon kerralla, jotta Juhanin ei tarvitse navigoida eri päivien välillä selvittääkseen, milloin Veskulla on vapaata.

Kun valitsemme suunnittelun lähtökohdaksi riittävän erilaisen käyttötapauksen, tarvittava tietosisältö ja tiedon organisointi muuttuu. Kuvassa 2.7 esitetyssä käyttötapauksessa 2 Soilella on muilta osin samantyyppinen tilanne kuin tapauksen 1 Juhanilla, mutta Soile on menossa uuteen kampaamoon, jonka työntekijöitä hän ei tunne ennestään. Hänen päätöksentekonsa tueksi pitäisi näyttää kampaajien vapaiden aikojen lisäksi jotakin sellaista vertailudataa, jonka perusteella hän pystyisi valitsemaan itselleen sopivimman kampaajan.

 

Käyttötapaus 2: Uudelle kampaajalle

 

Soilen tavoite: Soilen yksityisyrittäjä-vakiokampaaja on jäänyt äitiyslomalle, ja edellisestä hiusten leikkuusta on jo yli viisi viikkoa. Hän näkee kampaamoliike HAIRin lupaavan mainoksen Keltaisilla Sivuilla, mutta hän ei ennestään tunne HAIRin työntekijöitä eikä tiedä, milloin heillä olisi vapaata aikaa.

 

 

Kuva 2.7. Käyttötapaus 2 ja sitä vastaava datanäkymä.

Kuvan 2.7 datanäkymässä vertailudataksi on valittu mm. jokaisen työntekijän kokemusta ja erityisosaamista kuvaavia tietoja. Tiedot on organisoitu siten, että Soile pystyy katsomaan kunkin päivän kohdalta eri kampaajien vapaita aikoja rinnakkain.

Käyttötapauksen 3 tilanteessa (kuva 2.8) Henri kävelee parturiliikkeen ohi ja miettii, kävisikö samantien parturissa. Tilanne eroaa käyttötapauksesta 2 ainoastaan Henrin fyysisen sijainnin osalta: Henri on tapahtumahetkellä parturiliikkeen kohdalla. 

Käyttötapaus 3: Nyt heti parturiin

 

Henrin tavoite: Henri on ollut jo jonkin aikaa hiustenleikkuun tarpeessa, kun hän sattuu kävelemään lupaavan näköisen parturiliikkeen ohi. Hän ei ennestään tiedä, sattuisiko kenelläkään parturilla olemaan vapaata aikaa nyt heti.

 

 

Kuva 2.8. Käyttötapaus 3 ja sitä vastaava datanäkymä.

Kuvassa 2.8 on käytetty samaa vertailudataa parturin valitsemista varten kuin kuvassa 2.7, mutta näkymä on järjestetty seuraavaksi alkavien vapaiden aikojen mukaan: Kristel olisi vapaana nyt heti, mutta Veskua ja Ilonaa pitäisi odottaa yli tunti. Datan organisointi on lähellä käyttötapausta 2, mutta tässä tilanteessa Karille riittää näyttää vain heti alkavia parturiaikoja.

Käyttötapauksen suorittamisen eli toteumaskenaarion aikana saattaa käydä niin, että skenaario siirtyy toisen käyttötapauksen puolelle. Jos esimerkiksi käyttötapauksessa 3 parturiliikkeen ohi kävelevä Henri päätyy hylkäämään Kristelin korkean hinnan vuoksi, toteumaskenaario saattaa jatkua käyttötapauksen 2 aktivoitumisena: Henri yrittää selvittää, mihin aikaan seuraavina päivinä muilla normaalihintaisilla partureilla olisi vapaata aikaa.

2.3  Käyttötapaukset realistisina tilanneasetelmina

Käyttäjille eteen tulevat erilaiset tosielämän tilanteet ja tapahtumat voidaan kiteyttää tavoitepohjaisiksi käyttötapauksiksi. Tärkeintä käyttötilanteen kuvaamisessa on realistinen tilanneasetelma, jossa tulevan järjestelmän toimintoja tai käyttäytymistä ei ole vielä millään tavalla kiinnitetty. Seuraavissa aliluvuissa esitetään esimerkkejä käyttöliittymäsuunnittelun kannalta hyödyllisistä käyttötapauskuvauksista sekä käsitellään kahta käyttötapausten määrittelyvaiheessa tyypillisesti esiintyvää ongelmaa, kiinnitettyjä toimintoja (luku 2.3.1) ja tilanteiden yleistämistä (luku 2.3.2).

2.3.1  Kiinnitetyt toiminnot

Vaatimusmäärittelyvaiheen käyttötapauskuvauksissa ei pidä kiinnittää suunniteltavan järjestelmän toimintoja tai työnkulkuja. Esimerkiksi yliopiston sisäistä kirjastojärjestelmää määriteltäessä ”Kirjan varaaminen” ei kelpaa käyttötapaukseksi, koska siinä kiinnitetään varaustoiminto. Seuraavan kirjastoesimerkin avulla havainnollistetaan, miksi toiminnallisuutta ei pidä kiinnittää ennen käyttöliittymäsuunnittelua.

Kuvassa 2.9 on kirjastojärjestelmän suunnitteluun laadittu tavoitepohjainen käyttötapaus. Tässä käyttötapauksessa ei kiinnitetä toiminnallisuutta tai työn suoritustapaa, vaan tarkoituksena on antaa lähtöasetelma, johon myöhemmin suunnitellaan mahdollisimman hyvä käyttöliittymäratkaisu tarvittavine toimintoineen ja tietosisältöineen.

Käyttötapaus 1: Cardin visualisointikirja yliopiston muissa kirjastoissa

 

Tutkijan tavoite: Hannu Toivosen Tutkimustiedonhallinnan peruskurssin seuraavalta luennolta puuttuu vielä pari keskeistä esimerkkiä, joiden hän tietää olevan Cardin kirjassa ”Information Visualization”. Hän ei kuitenkaan tiedä, miten hän saisi kirjan käsiinsä mahdollisimman vaivattomasti.

 

Tilatietoja

·         Tänään on ma 1.9. klo 9.30.

·         Luento on ti 9.9. klo 10-12.

·         Hannu on aiemminkin lukenut Cardin kirjaa, mutta hänellä ei ole omaa kirjaa.

·         Omassa TKTL:n lähikirjastossa on 3 lainakappaletta, kaikki henkilökunnalla lainassa.

·         Lääketieteellisen kirjastossa on 3 kpl: lainassa 2, saatavilla 1. Hannu ei ole aiemmin käynyt siellä, ei tiedä kirjaston sijaintia.

·         Kasvatustieteellisen ja psykologian kirjastoissa on 2 kpl, kaikki lainassa.

Kuva 2.9. Kirjastoesimerkin tavoitepohjainen käyttötapaus.

Kuvassa 2.10 on eräs kuvan 2.9 käyttötapaukseen laadittu käyttöliittymäratkaisu, joka sisältää edellä mainitun varaustoiminnon. Kuvan tilanteessa esimerkkikäyttäjä Hannu aloittaa hakemalla esille Cardin kirjan, minkä jälkeen hän ryhtyy vertailemaan ratkaisuvaihtoehtoja. Omassa TKTL:n lähikirjastossa kaikki kirjat ovat lainassa, mutta lääketieteellisen kirjastossa olisi yksi vapaa kappale hyllyssä. Päätöksentekoprosessi perustuu kahden järjestelmän tarjoaman vaihtoehdon vertailemiseen: kannattaisiko hänen yrittää saada kirjaa lainaksi joltakin kollegaltaan TKTL:lta (järjestelmä näyttää, keillä kirja on lainassa) vai noutaisiko hän kirjan lääketieteellisen kirjastosta. Tässä esimerkkitoteumassa hän päätyy noutamaan kirjan lääketieteellisen kirjastosta, minkä seurauksena hänelle kannattaa tarjota myös varaustoiminto.

Kuva 2.10. Kirjastokäyttöliittymä, joka perustuu kirjan varausmenettelyyn.

Koska kuvan 2.9 käyttötapauksessa ei kiinnitetä varaustoimintoa, voimme yrittää edelleen suoraviivaistaa kuvan 2.10 käyttöliittymäratkaisua ja sen sisältämiä toimintoja. Tällä hetkellä suurin ylimääräinen työ syntyy kirjan noutamisesta lääketieteellisen kirjastosta. Voisimme suoraviivaistaa tuota kohtaa muuttamalla työnkulkua siten, että kirjoja olisi mahdollista tilata yliopiston kirjastoista sisäpostilla, jolloin esimerkkikäyttäjämme säästäisi paljon aikaa ja vaivaa.

Kuvassa 2.11 esitetään työnkulkua optimoimalla parannettu ratkaisu samaan käyttötapaukseen 2.9. Kuten kuvasta voidaan huomata, myös järjestelmän toteutus muuttuu edullisemmaksi: karttapohjaista vertailua ja kirjastojen sijaintien näyttämistä kartalla ei enää tarvita lainkaan. Kuvan 2.11 tilanteessa esimerkkikäyttäjä Hannu hakee esille Cardin kirjan, minkä jälkeen hän edelleen tekee päätöksen kahden vaihtoehdon välillä: kysyisikö hän joltain TKTL:n kollegaltaan kirjaa lainaksi vai tilaisiko sisäpostissa itselleen tuon yhden lainakappaleen, joka näkyy olevan saatavilla. Tässä tapauksessa hän päätyy tilaamaan lainakappaleen sisäisessä postissa. Lainakappaleen sijainnilla ei ole hänelle tässä tapauksessa erityistä merkitystä.

Kuva 2.11. Kirjastokäyttöliittymä, jossa työnkulkua on suoraviivaistettu.

Jos olisimme kiinnittäneet jo määrittelyvaiheessa käyttötapaukseen kirjan varaustoiminnon, emme olisi voineet koskaan päätyä kuvan 2.11 esittämään vaihtoehtoon, jossa työnkulkua on suoraviivaistettu ja joka saattaa kokonaiskustannusten kannalta tulla jopa edullisemmaksi kuin kuvassa 2.10 esitetty noutamismenettely. Siksi järjestelmän toimintoja (kirjan varaaminen) tai työnkulkukäytäntöjä (kirjan noutaminen) ei pidä kiinnittää vielä käyttötapauskuvauksissa.

2.3.2  Yleistetyt tilanteet

Käsitys siitä, että järjestelmän käytössä esiintyy valtava määrä erilaisia käyttötilanteita johtaa helposti yritykseen muodostaa yleistettyjä käyttötapauksia. Esimerkiksi YTV:n Reittioppaan kaltaista aikatauluhakujärjestelmää suunniteltaessa voisi tuntua loogiselta yleistää käyttötilanteet käyttötapaukseksi ”Reitin selvittäminen paikasta A paikkaan B”. Ainahan käyttäjä on jostakin lähdössä ja jonnekin menossa.

Yritys muodostaa käyttötilanteiden pohjalta suoraan yleistettyjä käyttötapauksia johtaa kuitenkin ongelmiin. Edellä esitetyssä Reittioppaan yleistetyssä käyttötapauksessa ei ole kiinnitetty toimintoja, mikä on sinänsä hyvä asia, mutta se ei myöskään sisällä minkäänlaista konkreettista tilanneasetelmaa. Jos laadimme määrittelyvaiheessa tällaisia yleistettyjä käyttötapauksia, tuloksena on helposti YTV:n Reittioppaan kaltaista tiedon organisointia ja toiminnallisuutta, jolla voi periaatteessa yleisesti tehdä ”mitä tahansa hakuja”, mutta kaikkien todellisessa käyttötilanteissa esiintyvien hakujen tekeminen on hyvin epäoptimaalista (kuva 2.12).

   

Kuva 2.12. Nykyinen YTV:n Reittiopas (www.ytv.fi/reittiopas).

Kun korvaamme edellisen yleistetyn käyttötapauksen edes yhdellä realistisella tilanneasetelmalla, jossa esimerkiksi TKTL:n tuntiopettaja on menossa ensimmäistä kertaa Ison Omenan kauppakeskukseen auttamaan kaveriaan tennisvarusteiden hankinnassa, saamme selville, että käyttöliittymän pitäisi näyttää hänelle ensisijaisesti hänen huonosti tuntemansa määränpään sijainti kartalla. Simuloimalla paria muutakin vastaavanlaista realistista käyttötilannetta meille selviää, että itse asiassa hyvin monissa tapauksissa nimenomaan kulkuvälineen vaihtopaikat ja määränpään sijainti ovat ne karttatiedot, jotka käyttäjiltä tyypillisesti puuttuvat. Esimerkiksi nämä kriittiset kohdat tulisi siis nostaa vaihtoehtoisten reittien kanssa samaan näkymään.

Jos laadimme käyttötapauksia tyyliin ”Reitin selvittäminen paikasta A paikkaan B”, emme saa koskaan selville todellisissa käyttötilanteissa toistuvia piirteitä. Yleistetty ajattelu johtaa toimintojen ja tietojen valitsemiseen riippumatta siitä, tarvitseeko kukaan käyttäjä kyseisiä tietoja tai toimintoja missään todellisessa tilanteessa. Vielä pahempi ongelma on se, että vaikka niitä jossain tilanteessa tarvittaisiinkin, ne on yleensä organisoitu käyttötilanteen kannalta hyvin epäoptimaalisesti.

Kuvan 2.12 karttanäkymä on tyypillinen esimerkki epäoptimaalisesta tiedon näyttämisestä ja organisoinnista. Kun käyttäjä on pyytänyt karttanäkymän esiin, järjestelmä näyttää karttaa niin yleisellä tasolla, ettei siitä ole sellaisenaan mitään hyötyä missään käyttötapauksessa. Käyttäjän on joka kerta navigoitava vaivalloisesti esiin vaihtopaikat sekä määränpään sijainti suhteessa siihen pysäkkiin, jossa hän jää bussista pois. Niin kauan kuin suunnittelun lähtökohtana ei ole yhtään konkreettista käyttötilannetta, näitä toistuvia tiedonhankintakohtia ei voida ottaa huomioon suunnittelussa.

Käyttötapausten kategorisointi johtaa myöskin yleistettyihin käyttötapauksiin siinä mielessä, että monen erilaisen käyttötapauksen sijaan suunnittelussa käytetään yhtä käyttötapausta, joka edustaa kaikkia muita saman kategorian tapauksia. Olennainen ero  ”Reitin selvittäminen paikasta A paikkaan B” –tyyppisiin tapauksiin on se, että suunnittelussa ei koskaan käytetä yleistettyä muotoa vaan käyttötapauskategorian yhtä konkreettista instanssia, jossa on kiinnitetty jokin tietty tilanneasetelma. Olennaista on myös se, käyttötapausten kategorisointi tehdään vasta sen jälkeen, kun meillä on ensiksi ollut käytössä lukuisia konkreettisia käyttötapausinstansseja. Yleistettyihin käyttötapauksiin ei yritetä päästä suoraan ilman, että kuljetaan konkreettisten tapausten kautta.

2.4  Muunlaiset kuvaukset suunnittelun syötteenä

Tavoitepohjaisten käyttötapausten sijaan kirjallisuudessa on esitetty vaihtoehtoisia syötteitä käyttöliittymän suunnittelulle: skenaarioita (luku 2.4.1) ja persoonakuvauksia (luku 2.4.2). Molempiin syötteisiin sisältyy konkreettista ja realistista kuvausta käyttötilanteista ja käyttäjistä, mutta ne ovat silti ongelmallisia syötteitä käyttöliittymän suunnittelulle. Skenaariot ovat luonteeltaan jäsentymättömiä ja niistä jää puuttumaan suunnittelun kannalta kriittisiä käyttäjän päätöksentekokohtia. Persoonat puolestaan sisältävät suunnittelun kannalta epäoleellista kuvausta käyttäjien ominaisuuksista eikä niissä ole kuvattu suunnittelussa tarvittavia käyttötilanteita käytännössä lainkaan.

2.4.1  Skenaariot

Skenaariot ovat usein tarjottu konkreettinen, käyttötilanteita kuvaava syöte käyttöliittymän suunnittelulle [esim. Hackos98, Rosson02, Cooper03]. Skenaariokuvauksissa ei ole luvussa 2.3.2 esitettyä yleistämisen ongelmaa, koska ne perustuvat konkreettiselle henkilölle eteen tuleviin todellisiin tilanteisiin ja tapahtumiin. Käyttötilanteiden selvitysmenetelmät, kuten haastattelut ja käyttäjätarkkailut, tuottavat konkreettisia skenaariomuotoisia kuvauksia käyttäjille eteen tulleista tilanteista ja tapahtumista. Skenaariot voidaan myös kirjoittaa siten, että järjestelmän toimintoja ei suoraan kiinnitetä.

Kuvassa 2.13 on pitkän aikavälin skenaario, joka kuvaa esimerkkihenkilö Karrin parturikäyntejä ja niihin liittyviä ajanvaraustapahtumia. Skenaario voisi olla tulosta esimerkiksi haastattelusta, jossa käyttäjä on muistellut kalenteriinsa tukeutuen aiempia parturikäyntejään.

Nyt on perjantai 7.11. ja Karri on juuri ollut hiustenleikkuussa vakioparturillaan Veskulla. Hän päättää varata saman tien seuraavan ajan, jottei parturilla käynti jää roikkumaan. Hän tarkistaa oman 9600-kommunikaattorinsa kalenterista, miltä joulukuun puoliväli näyttää. Maanantaille 15.12. ja tiistaille 16.12. on kiinnitetty koulutus Oulussa, joten hän katsoo sopivan ajan loppuviikosta. Torstaina 18.12. näyttäisi olevan ihan sopiva aika lounaan jälkeen, joten hän varaa ajan klo 13-13.30.

Joululoman jälkeen tukka alkaa olla taas leikkauksen tarpeessa ja parturissakäynti olisi hyvä hoitaa pois jaloista ennen kuin asiakasprojektit taas pyörähtävät täysillä käyntiin. Maanantaiaamulla 12.1. Karri varaa itselleen ajan tiistaiksi 20.1. Hänellä on silloin palaveri uuden projektin tiimoilta iltapäivällä klo 13-15 Pitäjänmäessä, joten Karri ottaa vakioparturiltaan Veskulta iltapäivän viimeisen ajan klo 16-17. Tiistaina 20.1. Karri on hyvissä ajoin Pitäjänmäellä palaverissa, mutta asiakkaan edustaja tulee paikalle 20 minuuttia myöhässä. Palaveri lisäksi venyy yli kaksituntiseksi, koska on epäselvää, mitä projektissa kannattaisi tehdä ja Karri pääsee lähtemään vasta klo 15.35. Hän arvelee ehtivänsä vielä juuri ja juuri ajoissa perille, mutta iltapäivän ruuhkan takia hän kuitenkin myöhästyy viisi minuuttia. Vesku on onneksi juuri vasta rahastanut edellisen asiakkaan, kun Karri saapuu paikalle, eikä sen kummempaa harmia pääse syntymään.

Maaliskuun alussa hiukset ovat ehtineet valahtaa jo vähän turhan pitkiksi, kun Karrilta on jäänyt varaamatta aika ajoissa kaikkien projektikiireiden takia. Hän avaa web-järjestelmän ja huomaa, ettei Veskulla ole enää sopivaa tyhjää aikaa ensi viikolla, kun Karri ehtisi käydä parturissa. Seuraavan viikon alussa Vesku puolestaan on vapaalla, ja Karri taas lähtee Pekingiin pitämään kurssia keskiviikkoaamuna. Jos parturissa käynnin jättää matkan jälkeen, hiukset ovat todennäköisesti jo varsin epäsiistit. Karrin kuluvan viikon aikataulu puolestaan alkaa olla aika täynnä, eikä sopivia parturissakäyntiaikoja ole kuin tiistaiaamulla ja perjantaina lounasaikaan sekä lauantaiaamulla. Veskulla ei ole enää vapaata näinä aikoina. Karri on harmissaan, mutta päättää, että kyllä jonkun ne hiukset täytyy leikata. Hän on aina aiemmin käynyt vain Veskulla, mutta päättää sitten ottaa ajan perjantaille 12.3. toiselta samassa liikkeessä työskentelevältä kampaajalta, Kristeliltä. Tämä aika pitää, ja torstai-illalla Karrin kännykkä muistuttaa seuraavan päivän parturiajasta. Kristel leikkaakin hiukset seuraavana päivänä ihan kelvollisesti.

Huhtikuussa hiukset ovat taas ehtineet aika pitkiksi ja asia tulee mieleen lounaan yhteydessä eräänä päivänä, kun Karri on koko iltapäivän asiakkaan tiloissa koodaamassa. Lounaan jälkeen ennen töiden jatkamista Karri varaa itselleen ajan Veskulta, jolta löytyy sopiva kolo maanantaina 26.3. heti aamulla klo 8. Sunnuntai-illalla 25.3. Karri muistaa seuraavan aamun parturiaikansa ja laittaa herätyskellon herättämään hyvissä ajoin klo 6.15.

Kuva 2.13. Karrin pitkän aikavälin parturiskenaario.

Kuvasta 2.14 näkyy, miten Karrin skenaariossa toistuu ajan myötä yhä uusia, hieman toisistaan poikkeavia variaatioita samasta käyttötapauksesta 1 ”Vakioparturi Veskulle lähipäivinä” (kuvat 2.5 ja 2.6). Niiden välissä skenaario sisältää yhden erilaisen tilanneasetelman, jossa vakioparturi Veskulla on täyttä ja Karrin pitäisi valita joku muista partureista täksi kerraksi. Toistuvista vakioparturikäynneistä eroava parturinvalintatilanne on merkitty kursivoituna kuvan 2.13 pitkään skenaarioon. Se vastaa luvussa 2.2 esitettyä käyttötapausta 2 (kuva 2.7), jossa Soile joutuu valitsemaan itselleen uuden kampaajan vakiokampaajan jäätyä äitiyslomalle. Aivan kuten Soile, myös Karri tarvitsee tätä käyttötapausta optimaalisesti tukevaan käyttöliittymään tietoa HAIRin muista työntekijöistä, jotta hän osaisi valita heistä sopivimman.

Kuva 2.14. Karrin parturiskenaarion sisältämät käyttötapausinstanssit.

Kuvan 2.13 kaltaisen aikajärjestyksessä esitettyihin tapahtumiin perustuvan skenaariomuodon keskeisimpänä ongelmana on se, että se ei pakota suunnittelijaa etsimään ja analysoimaan suunnittelun kannalta kriittisiä käyttäjän päätöksentekokohtia. Skenaariosta on erittäin vaikea hahmottaa, mitkä eri skenaarioissa kuvatut käyttötilanteet ovat lopulta luonteeltaan samanlaisia ja mitkä taas asettavat uusia vaatimuksia käyttöliittymälle sekä sen tarjoamille tiedoille ja toiminnallisuudelle. Jos skenaarioita ei analysoida mitenkään, suunnittelija joutuu tilanteeseen, jossa hänellä on käsissään sivukaupalla skenaarioita, joiden käyttö suunnittelussa on epäkäytännöllistä. Mitä suurempi järjestelmä, sitä hallitsemattomammaksi skenaarioiden määrä ja niiden käyttämiseen liittyvä työmäärä kasvaa.

Analysoimattomassa skenaariossa käyttäjän päätöksentekokohdat esiintyvät skenaariokerronnan sivumainintoina tai saattavat puuttua skenaariosta kokonaan. Silloinkin, kun skenaario osuu päätöksentekokohtaan, se ei tyypillisesti pysähdy erittelemään päätöksentekotilanteen vaihtoehtoja tai valintakriteerejä. Esimerkiksi kuvan 2.14 skenaario mainitsee, että Karri ”päättää sitten ottaa ajan perjantaille 12.3. toiselta samassa liikkeessä työskentelevältä kampaajalta, Kristeliltä”, mutta ei erittele millään tavalla sitä, mitkä kriteerit tähän valintaan vaikuttivat. Yhtenä taustasyynä tällaiselle kriteerien puuttumiselle saattaa olla se, että monissa muissa asiayhteyksissä, kuten yritysten tai poliitikkojen tekemiä päätöksiä kuvaavissa raporteissa ja lehtijutuissa, päätöksentekoprosessin erittelyä ei pidetä erityisen kiinnostavana. Esimerkiksi lehtijutuissa kiinnostavaa on yleensä tehdyn päätöksen lopputulos ja perustelut, mutta harvoin se, millaisella prosessilla päätökseen täsmälleen ottaen päädyttiin ja mitkä seikat asiaan vaikuttivat prosessin etenemisen eri vaiheissa.

Vastaavasti skenaariokuvauksessakin kerronta tyypillisesti hyppää päätöksentekoprosessin yli ja etenee suoraan valinnan lopputulokseen, jota kenties perustellaan yhdellä sivulauseella, kuten ”hän varasi Tukholman-risteilyään varten Turisti I -luokan hytin, koska se oli edullinen”. Skenaariota lukevalta suunnittelijalta saattaa jäädä koko päätöksentekokohta huomaamatta tai hän saattaa tyytyä näyttämään pelkät hyttien hinnat käyttöliittymässä, koska ”käyttäjä halusi valita edullisen hytin ja nyt hän voi tuosta ottaa sen minkä haluaa” (kuva 2.15). Skenaariomuoto ei houkuta suunnittelijaa arvioimaan, miksei käyttäjä valinnut vielä edullisempaa Turisti II –luokan hyttiä, tai selvittämään hinnan lisäksi muita hyttivalinnan kannalta relevantteja päätöksentekokriteerejä, jotka auttaisivat käyttäjää päätymään mahdollisimman optimaaliseen valintaan. Skenaariossa kuvattu käyttäjähän ei välttämättä osaa itse kuvitella saati vaatia käyttöliittymään kaikkea sitä tietoa, mikä auttaisi häntä hytin valitsemisessa.

Kuva 2.15. Heikko päätöksenteon tuki hyttivalinnassa (www.silja.fi).

Koska skenaariot eivät nosta esille päätöksentekokohtia, käyttöliittymäsuunnittelun edetessä ongelmaksi muodostuu myös käyttöliittymän jäsentäminen eli näyttöjako: miten käyttöliittymän tarjoama tietosisältö ja toiminnot jaetaan eri näytöille ja tarvitaanko samaan tietosisältöön erilaisia näkymiä eri käyttötilanteiden mukaan. Koska päätöksentekotilanteita ei ole eritelty, on epäselvää, mitä päätöksiä käyttäjän pitäisi järjestelmän avulla tehdä ja mitkä asiat näin ollen tarvittaisiin näytölle kerralla näkyviin. Päätöksentekokohtia olisi mahdollista etsiä simuloimalla käyttötilanteiden suorittamista jälkikäteen, mutta tämä edellyttäisi, että päätöksentekotilanteet osattaisiin tunnistaa simuloinnin yhteydessä. Jos päätöksentekokohdat osataan tunnistaa, ne olisi edullisempaa identifioida jo ennen suunnittelua, jolloin niitä voitaisiin hyödyntää alusta lähtien.

Päätöksentekokohtien ohittamiseen liittyvien ongelmien lisäksi skenaariomuodon heikkoutena on se, että skenaario kiinnittää aina jokaiselle päätöksenteko-ongelmalle jonkin ratkaisustrategian – sen strategian, jota tarkasteltu käyttäjä sattui soveltamaan. Käyttäjän valitsema ratkaisustrategia saattaa kuitenkin olla epäoptimaalinen esimerkiksi siksi, että hänellä on puutteellinen tietämys ratkaistavasta ongelmasta tai hänen osaamisensa erilaisista yleisistä ratkaisustrategioista on heikkoa. Suunnittelija jää helposti kiinni skenaariossa kuvattuun ratkaisustrategiaan, vaikka se olisi hyvin epäoptimaalinen, minkä seurauksena käyttöliittymään ei pahimmillaan päädy lainkaan tukea optimaalisimmille strategioille. Lisäksi kaikki vaihtoehtoiset strategiat saattavat jäädä kokonaan huomiotta. Esimerkiksi korkeakouluopintojen suunnittelujärjestelmää varten laadittu skenaario saattaa kuvata opintojen suunnittelua sellaisen opiskelijan näkökulmasta, joka opiskelee täyspäiväisesti ja käy systemaattisesti kurssien luennoilla ja harjoituksissa. Näin käyttöliittymä perustuu paljon läsnäoloa ja aktiivista osallistumista tukevaan opiskelustrategiaan, ja järjestelmästä jää puuttumaan tuki esimerkiksi sellaiselle opiskelustrategialle, joka perustuu vahvasti kurssien tenttimiseen ja etäopiskeluun esimerkiksi työssäkäynnin vuoksi.

Jälkimmäisen opiskelustrategian puuttuminen voitaisiin tietysti ratkaista laatimalla toinen skenaario tenttejä suorittavasta etäopiskelijasta. Tämän toisenkin opiskelijan skenaariosta kuitenkin tulisi hyvin pitkä kertomus, joka sisältäisi lukuisia samankaltaisuuksia suhteessa ensin mainittuun opiskelijaan. Ilmiö on vastaava kuin parturiesimerkin yhteydessä esitetyt skenaariot, joissa ajanvarausjärjestelmän kannalta samanlaiset tilanteet toistuvat Karrin, Niilon ja Niinan erilaisissa elämäntilanteissa. Jos käyttäisimme pelkkiä skenaarioita, tarvitsisimme kattavuuden aikaansaamiseksi paljon jäsentämätöntä skenaariotekstiä, jonka käyttäminen suunnittelussa on työlästä ja sellaisenaan riittämätöntä.

Jotta päätöksentekokohdan vaihtoehtoja ja valintakriteerejä voidaan eritellä, analyysi on irrotettava aikapohjaisesta skenaariosta. Kun skenaariomuotoa ryhdytään kehittämään siihen suuntaan, että päätöksentekokohdat nostetaan skenaariosta esille, aletaan lähestyä rakenteista käyttötapausmuotoa eli tavoitepohjaisia käyttötapauksia, jotka perustuvat nimenomaan päätöksentekokohdan tilanneasetelman virittämiseen.

2.4.2  Persoonat

Alan Cooper pitää persoonakuvauksia korvaamattomana käyttöliittymäsuunnittelun syötteenä [Cooper99, Cooper03]. Hänen mukaansa persoonien avulla voidaan torjua featurismia ja perustella hyviä suunnitteluratkaisuja koodaajille. Lisäksi persoonat toimivat kommunikointivälineenä asiakkaan, toteuttajien, tuote- ja projektipäällikköjen sekä suunnittelijoiden välillä. Persoonakuvauksilla voidaan hänen mukaansa välttää ns. venyvän käyttäjän (flexible user) ongelma, jonka mukaan suunnittelijan mielessä oleva käsitys käyttäjästä ja käyttäjän tarpeista mukautuu aina kulloinkin keksittyjen toimintojen ja käyttöliittymäratkaisujen mukaan. Venyvän käyttäjän ongelman seurauksena järjestelmään hyväksytään mukaan toimintoja ja ratkaisuja, jotka eivät palvele kunnolla ketään todellista käyttäjää.

Persoonakuvaukset sisältävät tyypillisesti vapaamuotoista kerrontaa kohdekäyttäjiin kuuluvan henkilön elämäntilanteesta, henkilökohtaisista ominaisuuksista ja mieltymyksistä. Kuvassa 2.16 on kolme esimerkkiä parturiliikkeen ajanvarausjärjestelmän suunnittelua varten laadituista persoonakuvauksista.

Karri, 31, on tekniikasta ja tietokoneista kiinnostunut yksityisyrittäjä. Hän nauttii uusien teknisten vempaimien ja uusien ohjelmistojen kokeilemisesta ja innostuu niistä joskus hyvinkin paljon. Hän kertoo usein kollegoilleen anekdootteja viimeisimmistä tekniikan tuulista, joihin hän on netin uutispalveluja lukiessaan törmännyt. Karrilla on tietotekniikan alalta diplomi-insinöörin tutkinto ja hän on perehtynyt laajasti tekniikan syvimpään olemukseen. Hänen intohimonsa ovat omat jännittävät koodausprojektit, joissa hän pääsee tekemään uusia innovatiivisia ratkaisuja. Niiden parissa saattaa joskus vierähtää aamun pikkutunneille saakka. Karri on kuitenkin työssään hyvin kiireinen - yrittäjyys ei jätä kovin paljon aikaa omille projekteille. Työviikot täyttyvät asiakasprojekteista sekä niihin liittyvästä hallinnosta ja venyvät usein 60-80-tuntisiksi, jolloin parturiaikoja on joskus vaikea sovittaa aikatauluun. Karri on melko tarkka siitä, että hiukset pysyvät tarpeeksi siisteinä eikä kampaus pääse ihan repsahtamaan. Karrilla oli aiemmin usein permanentti, mutta nyt hän on luopunut siitä.

Niilo Vartola, 66, on eläkkeellä oleva entinen valtion virkamies. Hän viettää vaimonsa Eevan kanssa aktiivisia eläkepäiviä Töölössä sijaitsevassa kerrostalokodissaan. Iästään huolimatta Niilolla on vielä kunnolla hiuksia, ainoastaan hiusraja on hieman vetäytynyt. Hän haluaa ylläpitää huoliteltua herrasmiehen tukkaa. Hän osallistuu aktiivisesti kaupunginosayhdistyksen toimintaan, ja on omassa taloyhtiössäänkin kannattanut uudistuksia, mm. yhtiön yhteistä laajakaistaverkkoa ja kaapeli-TV:n hankintaa. Niilo ei halua sortua passiivisuuteen, vaan uskoo, että aktiivinen ote elämään ja oman aikansa seuraaminen pitää mielen ja ruumiin virkeänä vielä pitkään. Niilolla on kotonaan ajanmukainen tietokone, jonka käyttöön hän päätti ryhtyä syventymään tarkemmin heti eläkkeelle jäätyään. Ennen eläkkeellä jäämistään Niilon tietokoneen käyttötaidot rajoittuivat vain välttämättömimpiin työtehtäviin.

Kuva: http://www.morguefile.com/
ver3/?display=108667973594

Niina, 34, työskentelee kenkäkaupan myyjänä Itäkeskuksessa ja asuu kahdestaan tyttärensä Ellin, 6 vuotta, kanssa Mellunmäessä. Ellin hiukset tulee usein leikattua ihan kotimenetelmin, koska yksinhuoltajana joutuu pitämään rahan käytön kurissa. Kampaajalla tulee käytyä yleensä palkkapäivän jälkeen, ja joskus Niina haluaa vähän hemmotellakin itseään. Niinalla on kotonaan modeemilla toimiva nettiyhteys, jolla hän muun muassa pitää yhteyttä ystävättäriinsä ja hoitaa laskujen maksamisen. Luonteeltaan Niina on eloisa ja vilkas, elämänmyönteinen ja rohkeakin. Samat piirteet näyttävät tarttuneen Elliinkin.

Kuva 2.16. Parturin ajanvarausjärjestelmän persoonakuvauksia.

Kun selvitämme eri käyttäjiltä konkreettisia parturin ajanvaraukseen liittyviä käyttötilanteita, löydämme heiltä lisää toisintoja samoista tilanteista. Kuvassa 2.17 on esitetty, millaisia tilanteita Niina-persoonalla esiintyy. Myös Niinalla toistuu uudestaan instanssi samasta käyttötapauksesta, jossa käydään toistuvasti omalla vakioparturilla, joka Niinan tapauksessa on Kristel. Väliin osuu kaksi tilannetta, joissa Niina joutuu etsimään itselleen uuden kampaajan, koska Kristel jää äitiyslomalle. Ensimmäisellä kerralla Niina ei ole tyytyväinen uuden kampaajan tekemään kampaukseen, joten hän yrittää toistamiseen löytää itselleen uuden kampaajan. Sopiva kampaaja löytyy, minkä jälkeen hän voi ryhtyä varaamaan vakioaikoja tältä uudelta kampaajaltaan Pirjolta. Kun Kristel sitten palaa äitiyslomaltaan, Niina alkaa taas käydä laitattamassa hiuksensa hänellä.

Näissä vakioparturilla käyntien väliin osuvissa kahdessa parturinvalintatilanteessa on kyse aiemmin kuvassa 2.7 esitetyn Soilen käyttötapauksen ”Uudelle kampaajalle” toisinnosta. Samanlainen toisinto esiintyi myös Karrin skenaariossa, kun Veskulla oli täyttä (ks. kuvat 2.13 ja 2.14). Vaikka Niina on aivan erilainen persoona kuin Karri tai Soile, heidän kaikkien kohdalla tilanneasetelma on hyvin samankaltainen ja tilanteen virittävät tilatiedot ovat samat. Kaikki joutuvat tekemään päätöksen siitä, kenelle parturikampaajalle he varaavat ajan, vaikka syyt, joiden takia valintatilanteeseen joudutaan, ovat Niinalla ja Karrilla erilaiset.

Kuva 2.17. Niinan parturiskenaarion sisältämät käyttötapausinstanssit.

Kaikkien persoonien parturinvalintatilanteita tukee aivan sama kuvassa 2.7 esitetty käyttöliittymä. Käyttöliittymän suunnitteluun eivät vaikuttaneet esimerkiksi persoonakuvauksissa esitetyt Niinan ja Karrin henkilökohtaiset ominaisuudet kuten se, että Karri on ”perehtynyt syvällisesti tekniikan olemukseen” tai että Niina on ”luonteeltaan eloisa ja vilkas, elämänmyönteinen ja rohkeakin”. Persoonakuvauksiin sisältyvät käyttäjien henkilökohtaisten ominaisuuksien ja elämäntilanteiden luonnehdinnat vaikuttavat olevan käyttöliittymän suunnittelun kannalta tarpeettomia: niistä ei seuraa käyttöliittymäratkaisuun minkäänlaista erityistä muutosta.

Persoonakuvausten hyötynä voi olla se, että ne saattavat auttaa suunnittelijaa fokusoitumaan tietynlaiseen käyttäjään ja etsimään persoonan elämää läpikäymällä käyttötilanteita, joita tällaiselle henkilölle tulee vastaan. Siten suunnittelija saattaa helpommin päästä irti esimerkiksi pelkkien itselleen sattuneiden tilanteiden kuvaamisesta. Tämä ei kuitenkaan edellytä persoonien määrittelyä yksityiskohtaisesti, vaan tuttujen ihmisten tai haastateltujen käyttäjien kuvitteleminen mielessä riittää. Vaikka Cooper korostaa kuvitteellisten persoonien käyttöä [Cooper99], vaikuttaa siltä, että todellisten ihmisten käyttäminen lähtökohtana nopeuttaa ja tehostaa määrittelyä. Viime kädessä suunnittelua varten kuitenkin tarvitaan kuvauksia nimenomaan käyttötilanteista – ei käyttäjistä, joiden kuvaaminen ei vaikuta johtavan mihinkään.

 

Lähteet

Cooper99

Cooper, A.,
The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore The Sanity.
SAMS, Indianapolis, 1999.

Cooper03

Cooper, A., Reimann, R.,

About Face 2.0. The Essentials of Interaction Design.

John Wiley & Sons, Inc., New York, NY, 2003.

Hackos98

Hackos, J., Redish J.,
User and Task Analysis for Interface Design.
John Wiley & Sons, USA, 1998.

Rosson02

Rosson, M.B., Carroll, J.M.,

Usability Engineering: Scenario-Based Development of Human Computer Interaction.

Morgan Kaufman, San Francisco, CA, 2002.

 

 

Päivitetty 8.7.2004