Käyttöliittymät II (syksy 2004 / Sari A. Laakso)

3 Käyttötapausten selvitysmenetelmät

Sisällys

3.1 Tavoitepohjaisten käyttötapausten tarve

3.2 Käyttäjätarkkailut

3.2.1 Tarkkailun tekeminen

3.2.2 Raportointi aikajanalle

3.3 Kontekstuaaliset haastattelut

Lähteet

2.1 Tavoitepohjaisten käyttötapausten tarve

Tavoitepohjaiset käyttötapaukset ovat rakenteisessa muodossa esitettyjä realistisia tilannekuvauksia. Käyttötapaukset kannattaa kuvata erottamalla tavoiteosa (goal) ja tilatiedot (status data), mikä helpottaa käyttötapausten ryhmittelyä ja hyödyntämistä käyttöliittymäsuunnittelun alkaessa.

Korkean tason tavoitepohjaisia käyttötapauksia tarvitaan projektin kuluessa mm.

· käyttöliittymäsuunnittelun lähtökohtana,

· käyttöliittymän arvioinnin testitapauksina,

· järjestelmän demojen käsikirjoitusten osina (”demotapauksina”),

· käyttöohjeen käyttöesimerkkeinä,

· toteutuksen suunnittelussa ja toteutusratkaisujen katselmoinnin osana ja

· järjestelmätestauksen korkeimman tason testitapauksina.

2.2 Käyttäjätarkkailut

Käyttäjätarkkailut (user observations) on hyvä menetelmä tavoitepohjaisten käyttötapausten selvittämistä varten. Käyttötapausten selvittäjä menee seuraamaan käyttäjien toimintaa heidän työ- tai harrastuspaikalleen [Hackos98, luku 9].

Käyttäjätarkkailujen avulla voidaan etsiä käyttötapauksia sekä nykyjärjestelmän kehittämistä varten että aivan uuden konseptin suunnittelua varten. Tuotteen kohderyhmän käyttäjillä on pitkälti samoja tavoitteita riippumatta siitä, minkälaisia laitteita ja ohjelmistoja heillä on käytössään. Jos esimerkiksi olemme suunnittelemassa matkapuhelimeen kalenteriohjelmaa, voimme selvittää tulevan järjestelmän käyttötapauksia tarkkailemalla käyttäjiä, joilla ei vielä ole matkapuhelimessaan kalenteriohjelmaa tai joilla ei ole edes matkapuhelinta: seuraamme käyttäjien päivän etenemistä ja yritämme paikantaa ne tilanteet ja tapahtumat, joihin tuotekonseptimme toisi paljon lisäarvoa. Jos tarkkailtava käyttäjä esimerkiksi yrittää sopia kaverinsa kanssa yhteistä illanviettoa sähköpostitse TKTL:n mikroluokassa, voimme huomata, että hän olisi oikeastaan paljon kätevämmin voinut sopia tapaamisesta jo bussissa TKTL:lle tullessaan, jos hän olisi voinut matkapuhelimellaan antaa kaverinsa tietoon omat sopivat ajankohtansa lähimmän viikon osalta. Työmatkalla oleva kaveri voisi nähdä matkapuhelimessaan oman kalenterinsa rinnalla ystävänsä ehdottamat sopivat ajat.

2.2.1 Tarkkailun tekeminen

Yksi tarkkailukerta kestää tyypillisesti 3-4 tuntia. Tarkkailtavan käyttäjän kanssa kannattaa yrittää sopia sellainen tarkkailuajankohta, jolloin käyttäjälle todennäköisimmin sattuisi tarkkailun kannalta mielenkiintoisia tapahtumia. Siitä huolimatta joskus käy niin, ettei käyttäjä teekään ehkä koko 3-tuntisen tarkkailurupeaman aikana mitään sellaista, mikä olisi kiinnostavaa käyttötapausselvityksen kannalta.

Tarkkailun aikana tarkkailija kirjaa muistiin mahdollisimman paljon yksityiskohtia käyttäjän työnkulusta, tapahtumista ja toimenpiteistä erilaisten tietojärjestelmien käytössä. Hänen on tärkeää kirjata muistiin alkuperäiset yksityiskohtaiset tapahtumat mahdollisimman täsmällisesti ja varoa yleistämästä niitä korkean tason johtopäätöksiksi [Hackos98, 264-267]. Tarkkailijan ei kannata yrittää laatia käyttötapauskuvauksia tarkkailun kuluessa, koska käyttäjän korkean tason tavoitteet eivät yleensä suoraan näy yksityiskohtaisten pikkutehtävien ja toimenpiteiden alta.

Jos tarkkailijalla on käytössään digitaalikamera, hänen kannattaa tallentaa suurin osa esimerkkidatasta kuvaamalla tietokoneen tai kannettavien laitteiden näyttöjä, pöydillä lojuvia papereita ja muita dokumentteja. Lisäksi hän voi pyytää tarkkailutilanteen lopuksi käyttäjältä valokopioita tärkeimmistä paperimateriaaleista.

Tarkkailijan tulee varoa häiritsemästä käyttäjän toimintaa tarkkailutilanteessa. Hän voi tarvittaessa kysyä muutaman kerran tarkkailun aikana joitain yksityiskohtia, jotka ovat tilanteen ymmärtämisen kannalta välttämättömiä, kuten ”kirjoitatko tätä sähköpostia sille samalle asiakkaalle, joka juuri äsken soitti sinulle?” Kysymistä kuitenkin kannattaa yrittää välttää jo senkin vuoksi, että käyttäjät helposti innostuvat keskustelemaan tarkkailijan kanssa, ja tilanne voi huomaamatta valua haastatteluksi. Tällöin ollaan taas kysymässä, mitä käyttäjä haluaa, eikä tekemässä havaintoja siitä, mitä käyttäjä tarvitsee.

2.2.2 Raportointi aikajanalle

Jos tarkkailtavan käyttäjän tehtävistä ja tapahtumista on syytä jälkeenpäin saada mahdollisimman täsmällinen käsitys, tarkkailutapahtumat (esim. tuleva puhelu, johtokunnan kokous, sähköpostin kirjoittaminen) voidaan sijoittaa aikajanalle. Kun tapahtumat on sijoitettu aikajanalle, samaan tehtävään liittyvät tapahtumat kannattaa ryhmitellä yhteen. Kuvassa 1 on esimerkki Kööpenhaminan paluulennon siirtämiseen liittyvien tapahtumien ryhmittelystä. Aikajanan ensimmäisenä tapahtumana on ”Soittaa matkatoimistoon”, ja sen takana olevan korkeamman tason tehtävä on Kööpenhaminan työmatkan paluulennon siirtäminen päivällä eteenpäin. Tehtävä on otsikoitu lyhyesti ”Paluulennon siirtäminen”.

Kuva 1. Tarkkailuraportin sivu.

Tarkkailun tekijä eli raportin laatija on etsinyt kaikki paluulennon siirtämiseen liittyvät tapahtumat aikajanalta ja korostanut ne mustalla pohjavärillä:

· Soittaa matkatoimistoon

· Matkatoimistosta soitetaan takaisin

· Lähettää tiedot matkatoimistoon

· Matkatoimistosta soitetaan

Tapahtumat kuvataan aikajanan (overview) vieressä tekstin ja tapahtumia havainnollistavien digikuvien avulla (details). Kaksi muuta esimerkkisivua aikajanapohjaisesta tarkkailuraportista löydät DUO-tarkkailumenetelmän kuvauksen yhteydestä [Laakso02] (pdf 400 KB).

2.3 Kontekstuaaliset haastattelut

Joidenkin järjestelmien käyttö on niin satunnaista ja harvinaista, että tarkkailutilanteita ei ole mielekästä järjestää. Tällaisia järjestelmiä ovat tyypillisesti esimerkiksi yritysten ja organisaatioiden web-sivustot, kuten Helsingin yliopiston, Silja Linen tai Helsingin Sataman web-sivustot. Kohderyhmien käyttäjien on vaikea ennustaa, milloin heillä aktivoituu sivuston palveluihin liittyviä käyttötapauksia vai aktivoituuko niitä milloinkaan.

Kun tarkkailujen tekeminen ei ole järkevää tai mahdollista, hyviin tuloksiin voidaan päästä kontekstuaalisilla haastatteluilla, jotka tehdään käyttäjän oikeassa työympäristössä. Tällöin käyttäjä näyttää eli tavallaan demonstroi haastattelijalle aiempia käyttötilanteitaan (haastattelupainotteinen, esim. [Hackos98, 135-137]) tai hän alkaa tehdä normaaleja työtehtäviään, joista haastattelija esittää kysymyksiä sitä mukaa kuin tilanne etenee (tarkkailupainotteinen, [Beyer98, 64-66, 73-76], [Hackos98, luku 10]).

Esimerkiksi Helsingin yliopiston web-sivuston käyttötapauksia kartoittava haastattelupainotteinen kontekstuaalinen haastattelu voisi alkaa sillä, että haastattelija kysyy käyttäjältä, milloin hän viimeksi käytti yliopiston web-sivuja. Käyttäjä saattaa vastata, että hän käytti niitä toissapäivänä, kun hän yritti selvittää, minne virkahakemus pitää toimittaa ja mihin mennessä. Tämän jälkeen haastattelija voi pyytää käyttäjää näyttämään, mitä hän silloin teki ja mistä hän löysi aiheeseen liittyvää tietoa. Kun käyttäjä pääsee näyttämään konkreettisesti, mitä hän toissapäivänä teki web-sivuston avulla virkahakemusasiansa eteen, hänelle palautuu mieleen monia käyttötapauksen yksityiskohtia, jotka antavat haastattelijalle hyviä vihjeitä tarpeellisen esimerkkidatan kyselemistä varten.

Käyttäjätarkkailuun painottuva kontekstuaalinen haastattelu lähtee käyttäjän tarkkailemisesta. Tarkkailija täydentää havaintojaan haastattelemalla käyttäjää tarkkailun kuluessa. Tarkkailijan kannattaa yrittää sijoittaa kysymyksensä käyttäjän työskentelyn kannalta sopiviin taukokohtiin, jotta hän häiritsisi käyttäjän toimenpiteitä mahdollisimman vähän.

Jotta haastattelija saisi käyttötapauksia selville, hänen on tärkeää pystyä saamaan käyttäjältä konkreettisia tilanne-esimerkkejä. Haastatteluihin painottuvissa selvityksissä käyttäjät tekevät mielellään yleistyksiä ja antavat hyvin epämääräistä dataa. Jos edellisessä yliopiston web-sivujen esimerkissä haastattelija olisi aloittanut kysymällä käyttäjältä, käyttääkö hän usein yliopiston web-sivuja ja mihin tarkoitukseen, haastattelu saattaisi edetä seuraavaan tapaan:

· ”Kyllä minä oikeastaan aika usein katson erilaisia ammattiasioita Helsingin yliopiston web-sivuilta.”

· Millaisia ammattiasioita?

· ”Aivan kaikenlaisia.”

· Antaisitko esimerkin?

· ”No siis ne voivat olla aivan mitä tahansa.”

· Kertoisitko yhden?

· ”Se riippuu ihan tilanteesta.”

Haastattelija ei välttämättä pääse ollenkaan käyttötapausten selvittämisessä eteenpäin, kun käyttäjä yleistää asioita ja kiertelee esimerkkidatan antamista. Tällöin keskustelu kannattaa kohdistaa johonkin todelliseen tapahtumaan esimerkiksi kysymällä, mitä käyttäjä viimeksi teki:

· Milloin viimeksi katsoit jotakin ammattiasiaa verkosta?

· ”Taisi olla eilen...”

· Mitä katsoit?

· ”Henkilöstöhallinnon sivuja.”

· Mitä etsit sieltä?

· ”Että minne virkahakemus pitää lähettää ja milloin on deadline.”

· Mitä virkaa olet hakemassa?

· ”Laitoksella on assistentin virka auki ja minua kiinnostaisi...” jne.

Käyttäjiltä ei myöskään kannata kysyä yleisiä mielipiteitä käyttöliittymästä kokonaisuutena, koska heidän vastaustensa sisältö ei tyypillisesti ole juuri minkäänlaisessa yhteydessä arvosteltavan käyttöliittymän kanssa. Esimerkiksi verkkosivuston käyttöliittymä on käyttäjien sanojen mukaan lähes poikkeuksetta

· ”selkeä” tai

· ”melko selkeä ja helppo käyttää”.

Käyttäjien tehtävänä ei ole arvioida käyttöliittymää asiantuntija-arvion tavoin eivätkä he edes voi osata tehdä arviointia. Jatkokehittäjät eivät hyödy käyttäjien yleisistä ”selkeyskommenteista”. Koska käyttäjät ovat asiantuntijoita omalla sovellusalallaan, heiltä kannattaa kysyä sovellusalaan liittyvistä asioista (konkreettisista käyttötapauksista) eikä pyytää heitä arvioimaan saati suunnittelemaan käyttöliittymäratkaisuja.

Lähteet

Beyer98	Beyer H., Holtzblatt K., Contextual Design. Morgan Kaufmann, San Francisco, CA, 1998.
Hackos98	Hackos J.T., Redish J.C., User and Task Analysis for Interface Design. John Wiley & Sons, New York, NY, 1998.
Laakso02	Laakso S.A., Laakso K.-P., Page C.P., DUO: A Discount Observation Method. Julkaisematon yksityiskohtaisempi kuvaus lähteen [Wixon02] DUO-tarkkailumenetelmästä, 2002. [pdf]
Wixon96	Wixon D., Ramey J. (toim.), Field Methods Casebook for Software Design. John Wiley & Sons, 1996.
Wixon02	Wixon D. et al., Field Studies – Evolution and Revolution. CHI ’02 Conf. Proc., Extended Abstracts, ACM, New York, 2002. [pdf]

Päivitetty 27.10.2002 / salaakso@cs.helsinki.fi