4. Verkkopalvelu - tarvekartoitus, toiminta- ja asiointiprosessein määrittely

Transkriptio

1 4. Verkkopalvelu - tarvekartoitus, toiminta- ja asiointiprosessein määrittely Käsiteltävät teemat: Suunnittelun tavoitteet verkkopalvelun toimijoiden näkökulmasta o Sisällönhallinta, ansaintalogiikka, lisäarvo ja kustannustehokkuus (palvelun tuottaja) o Käytettävyys, saavutettavuus, hyödyllisyys, laadukkuus käyttökelpoisuus (asiakas, käyttäjä) Käyttäjien tarpeet ja tavoitteet on tunnistettava. Miten saadaan tietoa käyttäjistä ja heidän tarpeistaan? Ei riitä, että edetään parhaan tämänhetkisen tiedon mukaan ja otetaan huomioon ne asiat, jotka tunnetaan (Turkki & Sinkkonen, 2004). Kun keskusteluissa tilaajan kanssa on päästy yhteisymmärrykseen verkkopalvelun toteuttamisesta, on määriteltävä verkkopalvelun toteuttamiseen liittyvät edellytykset, riskit, vaatimukset ja rajoitukset. Ennen verkkopalvelun teknisen määrittelytyön aloittamista on pyrittävä selvittämään ja analysoimaan monenlaisia ja monentasoisia tekijöitä, joilla on merkitystä verkkopalvelun käyttökelpoisuuden toteutumiselle. Suunnitteluvaiheen määrittelytyössä on kiinnitettävä huomiota eri tahoilta nouseviin reunaehtoihin, joita ovat: käyttäjät, heidän erityispiirteensä ja tarpeensa, verkkopalvelun tuottajan vaatimukset ja tarpeet esim. verkkopalvelun kustannustehokkuus, mahdollisten sidosryhmien tarpeet, asiointi- ja toimintoprosessit sekä käytön tavoite, informaatiosisältö, tekniset reunaehdot sekä taloudelliset yms. reunaehdot. Verkkopalvelun suunnittelun tavoitteena on käyttökelpoinen ja laadukas verkkopalvelu. Verkkopalvelun suunnittelu- ja kehittämistyössä on tiedettävä ketkä palvelua käyttävät, mikä on palvelun käyttäjän tavoite, millaisissa tilanteissa ja millaisilla päätelaitteilla palvelua käytetään, mitä asiakkaat itse asiassa tekevät käyttäessään palvelua. Tavoitteena on syventää ja laajentaa synopsiksessa esitettyjä määritelmiä: mitä (aihe), kenelle (kohdeyleisö), miksi (tavoite) ja miten (käyttötapa). Verkkopalvelun on vastattava myös palvelun tuottajan vaatimuksiin ja tuettava palvelun tuottajan tavoitteiden toteutumista. Wiion (2004) mukaan [k]äyttötilanteessa käyttäjän pyrkimykset ja prosessit kohtaavat liiketoiminnan pyrkimykset ja prosessit (Wiio 2004, 91). Käyttäjän prosessilla tässä yhteydessä tarkoitetaan käyttäjän pyrkimystä ja sen tavoittelemiseen liittyvää tekemistä eli toimintaa. (Wiio 2004, 90). 59

2 Esimerkiksi verkkokirjakaupassa palvelun tuottaja huolehtii mm. tilaustietojen välittämisestä varastoon, tilatun kirjan lähettämisestä tilaajan osoitteeseen, laskutustietojen välittämisestä laskutukseen sekä laskutuksesta jne. asiakas taas valitsee tuotteen, tilaa tuotteen ja maksaa sen. Suunnittelun tavoitteet ja palveluntuottajan näkökulma Sisällönhallinta Sisällönhallinta tarkoittaa laajimmillaan digitaalisen sisällön ylläpitoa kattaen sisällön koko elinkaaren: tuottaminen, julkaiseminen, poistaminen ja arkistointi. Parhaimmillaan hyvin suunniteltu sisällönhallinta säästää työtä ja sitä kautta kustannuksia. Lisäksi käyttäjät hyötyvät laadukkaammasta sisällöstä oikeaa sisältöä oikeaan aikaan. (Esim. Samela 2002, 140.) Sisällönhallinnan keskeisiä ominaisuuksia ja toimintoja: aineiston tuominen sisällönhallinnan piiriin, sisällöntuotantoprosessin tuki, sisältötiedostojen varastointi ja versiointi sekä niihin liittyvä ylläpito, sisällön kuvailutieto ja tehokas haku, aineiston elinkaaren hallinta, linkkien hallinta, mahdollisesti ajastetun sisällön julkaiseminen eri medioihin sekä mahdollinen aineiston personointi jne. Ansaintalogiikka Ansaintalogiikan kehittäminen ja uudet liiketoimintamahdollisuudet teknologioiden ja sisältöjen rajapinnoilla kiehtovat verkkopalveluun siirtyviä yrityksiä. Ansaintalogiikalla tarkoitetaan loogista mallia tai suunnitelmaa, jolla palvelusta tai tuotteesta on tarkoitus aikaansaada kannattava. Kannattavuutta voidaan säädellä erilaisilla hinnoittelumekanismeilla. Ansaintalogiikka onkin osa liiketoimintamallia. Ansaintalogiikkaa mietittäessä täytyy tunnistaa mahdolliset myyntituloa tuottavat vastineet, joita voi olla alkutuotannossa, teknologiassa, tuotteiden kehityksessä tai liiketoiminnan kehityksessä. Sisällön alkutuotannolla tarkoitetaan niitä toimintoja, joissa sisällöt muotoutuvat mediaelementeiksi kuten kuvaksi, ääneksi tai tekstiksi. Lisäksi nämä elementit ovat sellaisessa muodossa, että niitä voidaan käyttää sisältöpalveluiden osana. Verkkopalveluja tekevät yritykset yhdistelevät sisältökomponentteja ja teknologioita asiallisesti toimiviksi sisältötuotteiksi kun taas liiketoiminnan kehitystä tekevät yritykset kehittävät sisältötuotannon lopputuotteita markkinoille. Lisäksi verkkopalvelun käyttötilanteisiin saattaa palvelun tuottajan näkökulmasta liittyä useitakin potentiaalisia ansaintamahdollisuuksia esim. oheistuotteiden myyntiä. Lisäarvo ja kustannustehokkuus Verkkopalveluun siirtymisen syynä saattaa olla myös toimintojen virtaviivaistaminen. Palvelujen tehostamista perustellaan usein esimerkiksi sillä, että digitaalista informaatiota on helppo tallentaa ja kopioida sekä käyttää uudelleen, siirrettävyys on nopeaa, 60

3 sama informaatio soveltuu eri medialle ja siirtokanaville, informaation jakaminen on helppoa, muokkaus ja päivittäminen on helppoa informaation muuttuessa tai vanhentuessa jne. Toimintoja voidaan myös siirtää asiakkaan tehtäviksi, jolloin voidaan säästää henkilöstökustannuksissa. Esimerkiksi pankit ovat siirtäneet suuren osan asiakaspalvelun tehtävistä verkkopankkiin asiakkaan itse tehtäväksi. Suunnittelun tavoitteet ja käyttäjän näkökulma Jotta verkkopalvelu olisi käyttökelpoinen (usefulness) on sen täytettävä seuraavat vaatimukset (vrt. Nielsen 1993; Silius ym. 2003): 1. Verkkopalvelun käytön on oltava sujuvaa: o Käytettävyys (usability), o Saavutettavuus (accessibility) eli mahdollisuus käyttää verkkopalvelua käyttötilanteesta, päätelaitteesta ja yksilöllisistä ominaisuuksista riippumatta 2. Verkkopalvelun on oltava hyödyllinen (utility) eli sen tulee soveltua tiettyyn käyttötarkoitukseen: o Tavoitteen saavuttamisen tukeminen: - Merkityksellisten toiminto- ja asiointiprosessien tukeminen (korostuu operatiivisissa verkkopalveluissa), - Informaation laadukkuus kuten informaatioarkkitehtuuri, informaation esitystapa ja luotettavuus (korostuu erityisesti viestinnällisissä verkkopalveluissa). o Verkkopalvelun käytön tuottama hyöty eli lisäarvo (added value). Käytettävyys Käytettävyydellä tarkoitetaan tuotteen toimivuutta ja käyttäjän tukemista tavoitteen saavuttamisessa sen tyypillisessä käyttötilanteessa ts. miten sujuvasti, tehokkaasti ja miellyttävästi käyttäjä pystyy tuotetta käyttämään. Käytettävyyttä voidaan tarkastella monesta eri näkökulmasta (esim. Keinonen 1998): Suunnittelun tavoitteena: suunnittelutyön tavoitteena on systeemi, joka on hyödyllinen, jonka käyttö on helppo oppia (ja muistaa) ja jota on helppo ja miellyttävä käyttää. Gould ja Lewis vuonna Tuotteen ominaisuutena: yleisimmin mainittuja ominaisuuksia ovat johdonmukaisuus, hallittavuus, esitystapa, virheiden sieto, muistettavien asioiden määrä, tehtävän sopivuus, joustavuus ja opastus. - Normanin vuonna 1991 esittämät viisi tuotteen ominaisuutta: käsitemalli, näkyvyys, kytkentä, palaute ja virheet. - Nielsenin vuonna 1994 esittelemät kymmenen heuristista sääntöä. Tuotteen käyttöön liittyvänä ominaisuutena: yleisimmin mainittuja ominaisuuksia ovat opittavuus, tehokkuus (nopeus ja virheiden määrä) ja miellyttävyys. Näkökulmaa edustavat esim. ISO DIS , Bennet 1984, Shackel 1991, Nielsen 1993 ja Jordan Käyttäjän kokemuksiin liittyvä ominaisuus: tarkastelun kohteena on tällöin mm. tietotekniikkaan ja sen käyttöön liittyvät asenteet, käytön tyydyttävyys, käytön havaittu hyödyllisyys, käytön henkinen ja fyysinen rasittavuus, turhautuminen sekä omistamiseen ja käyttöön liittyvä mielihyvä, aistillisuus sekä viihdyttävyys. 61

4 Käytettävyyteen vaikuttavat tekijät ovat monentasoisia (Keinonen 1998; Sinkkonen ym. 2002): suhteellisen pysyviä tekijöitä: ihmisen psykologisiin ja fysiologisiin rakenteisiin liittyvät tekijät (muisti, havaitseminen, aistit) ja jotkin kulttuuriset tekijät (kieli, normit, tavat) sekä kontekstitekijät: kohteena oleva tehtävä, käyttäjän yksilölliset kyvyt ja rajoitukset, käyttötila ja sen olosuhteet, käyttötilanne. Saavutettavuus Verkkopalveluiden käytön ongelmat voivat liittyä käytössä oleviin laitteisiin ja ohjelmistoihin tai kognitiivisiin tekijöihin kuten havaitseminen, oppiminen tai kieli. Rajanveto käytettävyys- ja saavutettavuusongelmien välille on vaikeaa. Laajasti ajatellen saavutettavuus voidaan ymmärtää mahdollisuutena käyttää verkkopalvelua. Kun käyttäjän toiminnan esteet on poistettu ja hänelle avautuu mahdollisuus palvelun käyttöön, siirrytään käytettävyyden alueelle: kuinka tehokasta, helposti opittavaa, miellyttävää jne. verkkopalvelun käyttö on. (Esim. Turkki & Sinkkonen 2004.) Saavutettavuutta tarkastellaan usein tiettyjen käyttäjäryhmien näkökulmasta. (Esim. Turkki & Sinkkonen 2004.) Tällaisia käyttäjäryhmiä ovat esim.: toimintarajoitteiset henkilöt kuten esim. näkö-, kuulo-, liikunta- tai CP-vammaiset sekä ihmiset, joilla on jokin muu pysyvä tai tilapäinen erityisongelma, myös erilaisia päätelaitteita käyttävät henkilöt, erilaisissa käyttötilanteessa olevat henkilöt sekä ikäihmiset ja eri ikäiset lapset. Kysymys on ennen kaikkea tasa-arvoisuudesta ja erilaisuuden huomioimisesta. Käytettävyyden suunnitteluun ja arviointiin liittyviä menetelmiä voidaan soveltaa myös saavutettavuuteen liittyvissä kysymyksissä. Lisälukemista: Keinonen, T. Tuotteen käytettävyys [online]. Helsinki: Taideteollinen korkeakoulu, 1999, julkaistu [viitattu ]. Pentti Roution laatima lyhennelmä luvusta 2 teoksesta Keinonen, T One-dimensional usability - influence of usability on consumers' product preference. Taideteollisen Korkeakoulun julkaisu A21. Helsinki: Taideteollinen korkeakoulu. Saatavissa wwwmuodossa: <URL: >. Lisäarvot Arvioitaessa lisäarvoja tarkastellaankin verkkopalvelua suhteessa perinteiseen palveluun ja pohditaan mitä erityistä hyötyä tietoverkon käyttö tietyssä käyttötilanteessa tuo organisaatiolle ja ennen kaikkea asiakkaille verrattuna ns. perinteisesti toteutettuun palveluun. Lisäarvon toteutuminen on voimakkaasti sidoksissa henkilön omaan kontekstiin, joten lisäarvoa ei voida arvioida ilman todellisia käyttäjiä. Sama verkkopalvelu voi erota lisäarvoiltaan eri käyttäjien kesken. Esimerkiksi maaseudulla asuvalle erilaisten viranomaisten lomakkeiden saaminen verkon välityksellä omaan käyttöönsä on usein jo merkittävä lisäarvo kun taas asutuskeskuksissa asuvat evät koe tällaista menettelyä erityisenä lisäarvona. 62

5 Huomioitavaa on se, että tietoverkon hyödyntämisen palveluprosessissa tulisi tuottaa jotakin erityistä hyötyä sekä asiakkaalle että organisaatiolle perinteiseen palveluun verrattuna. Suurin kokonaishyöty saadaan silloin kun mahdollisimman moni osapuoli saa erityistä lisäarvoa verkon hyödyntämisestä palvelussa. Summa summarum: Asiakkaan ja palvelun tuottajan näkökulmista nousevien vaatimusten analysoinnin tuloksena saadaan tieto siitä, mitä reunaehtoja ja erityisvaatimuksia näistä seuraa verkkopalvelun käytettävyydelle, saavutettavuudelle ja hyödyllisyydelle. Asiakas sekä hänen tarpeensa ja tavoitteensa on tunnettava Jos toteuttaa verkkopalvelun pelkkien asiakasta koskevien mielikuvien varassa, melko todennäköisesti onnistuu rajaamaan osan potentiaalisista asiakkaista ulkopuolelle (Turkki & Sinkkonen, 2004). Ei ole mahdollista toteuttaa verkkopalvelua, joka olisi jollakin tapaa universaali eli helppokäyttöinen, saavutettava ja tavoitteiden saavuttamista tukeva kenen tahansa asiakkaan tai käyttäjän näkökulmasta. Vaikka jotkin ominaisuudet ovat suhteellisen pysyviä, niin jokaisessa projektissa tulee määritellä erikseen: käyttötilanteet, -tehtävät ja -ympäristö, tuotteen käyttäjät ja heidän osaamistasonsa. (Esim. Sinkkonen ym. 2002, 24 30; Turkki & Sinkkonen 2004.) Käyttäjistä, käyttötilanteista kootaan tietoa, joka otetaan huomio verkkopalvelun suunnittelu- ja toteutustyössä mahdollisimman kattavasti. Verkkopalvelua testataan suunnittelu- ja toteutusvaiheessa toistuvasti ja tarpeen vaatiessa toteutusta muutetaan ja korjataan eli hyödynnetään ns. iteroivan suunnittelun menetelmää. (Esim. Sinkkonen ym. 2002, 24 30; Turkki & Sinkkonen 2004; Wiio 2004.) Verkkopalveluiden tai sovelluksen käyttötilanteiden ja käyttäjien tarpeiden määritteleminen yksiselitteisesti on haastavaa. Sovellussuunnittelun alalla onkin kehitetty lukuisia menetelmiä, joissa pyritään ottamaan todellinen käyttäjä tavalla tai toisella mukaan sovelluksen suunnitteluun. Tällaisia menetelmiä on mm. "Joint Application Design", "user-centered requirements analysis", "usercentered design", "many participatory design techniques" ja "Contextual Design". (Holzblatt & Beyer, 1993.) Tilannetutkimus (Contextual Inquiry) -menetelmän avulla voidaan kerätä informaatiota sovelluksen käyttökontekstista jo ennen suunnittelun alkamista erilaisten vaatimusmäärittelyjen pohjaksi. Tilannetutkimus hyödyntää etnografista menetelmää informaation kokoamisessa. Olennaista on käyttäjän havainnointi ja haastattelu todellisessa käyttökontekstissa todellisia (työ)tehtäviä suorittamassa. Havainnoitsijan on helppo tarvittaessa kysyä käyttäjältä, mitä hän kulloinkin oli tekemässä ja miksi. Menetelmä on erityisen hedelmällinen siksi, että havainnoitsija ja käyttäjä voivat yhdessä saada selville sellaisiakin tarpeita, joita käyttäjä ei välttämättä osaa ääneen kertoakaan. (Esim. Holzblatt & Beyer, 1993; Preece ym. 1994, 661.) 63

6 Lähtökohtana asiakkaan prosessit Toiminnallisuudeltaan käytettävän ja saavutettavan verkkopalvelun suunnittelu vaatii käyttötilanteiden ymmärtämistä. Edellytyksenä käyttötilanteiden ymmärtämiselle on käyttäjän prosessien analysointi ja ymmärtäminen. (Esim. Wiio,2004.) Suunnittelutyön tavoitteena on informaatiosisältöjen sekä toiminta- ja asiointiprosessien jäsentäminen asiakkaan (käyttäjän) näkökulmasta. Asiakaan näkökulma riippuu hänen tarpeistaan ja tilanteestaan. Lisäksi tulee kiinnittää huomiota siihen, että informaatio ja erilaiset toimintaprosessit tukevat tarvittaessa toisiaan. (Ibid.) Lähestymistavasta on selkeitä etuja: asiakaan on helpompi hahmottaa valmiin verkkopalvelun toimintaprosessit ja asiat, verkkopalvelussa käytettävät käsitteet ja termit ovat todennäköisemmin käyttäjälle tuttua kieltä. Tavoitteena käyttötilanteiden ymmärtäminen 1 1. vaihe: tunnistetaan käyttäjät, 2. vaihe: tunnistetaan kaikille käyttäjille yhteiset pyrkimykset (verkkopalvelun käyttötarkoitus), 3. vaihe: mallinnetaan prosessi (tai prosessit), 4. vaihe: prosessien sisältämät tilanteet, joissa verkkopalvelu ja käyttäjä ovat tekemisessä keskenään käyttämiseen liittyvät tilanteet, 5. vaihe: tilanteisiin liittyvät tarpeet, 6. vaihe: sidosryhmien tarpeiden tunnistaminen. 1. Käyttäjien tunnistaminen Kuvaus verkkopalvelun tyypillisestä käyttäjästä sekä hänen tarpeistaan ja erityispiirteistään. Laajennetaan käsittämään myös potentiaaliset käyttäjät ja heidän tarpeensa. Esimerkiksi millaiset auton ostajat hyötyisivät verkon välityksellä tuotettavista palveluista? 2. Käyttäjien yhteisten pyrkimysten tunnistaminen Mitkä pyrkimykset ovat yhteisiä kaikille käyttäjille? Sopivan auton ostaminen verkkopalvelun pääasiallinen käyttötarkoitus on tukea käyttäjää sopivan auton ostamisessa. 3. Prosessin mallintaminen Suunnittelun lähtökohtana tulee olla se prosessi, joka tukee palvelun käyttötarkoitusta eli tässä tapauksessa: auton ostaminen. Prosessia tarkastellaan aina kokonaisuutena: mitä kaikkea tapahtumia ja vaiheita asiakas kohtaa ennen kuin hän on auton omistaja. Tavoitteena on siis koko prosessin vaiheiden tunnistaminen. Erilaisten liiketoiminnan ja tietojärjestelmien prosessien kuvaamiseen on olemassa lukuisia eri tekniikoita, mutta usein riittää jäsennys niistä toimenpiteistä ja tapahtumista, jotka vievät prosessia eteenpäin. 1 Luku pohjautuu Antti Wiion (2004) ajatuksiin. 64

7 Tarjontaan tutustuminen. Kiinnostavien vaihtoehtojen rajaaminen. Autojen vertailu ja järjestäminen paremmuusjärjestykseen. Koeajo. Neuvottelu ja kaupan teko. Auton hankkimiseen liittyvät muut toiminnot: vakuutukset, rekisteröinti. Myöhemmin määräaikaishuollot, varusteiden ostaminen jne. On huomioitava, että välttämättä kaikkia prosessin vaiheita ei voida järkevästi ja tarkoituksenmukaisesti tukea verkon välityksellä tarjottavan palvelun avulla. Toisaalta mikäli verkkopalvelu pitää sisällään erilaisia käyttötarkoituksia, saattaa prosesseja olla useitakin. 4. Käyttämiseen liittyvät tilanteet Seuraavaksi pohditaan miten prosessin eri vaiheissa voidaan tukea käyttäjää tavoitteen saavuttamisessa. Millaisia toimintoja ja informaatiosisältöjä tarvitaan käyttäjän tueksi? Esimerkiksi vaiheet: Tutustuminen tarjontaan ja kiinnostavien vaihtoehtojen rajaaminen - Autonet -hakupalvelu Autonet -autohaku on jäsennetty päätasolla seuraavasti: etusivu, uudet autot, vaihtoautot, uutiset ja liikkeet. Toimiiko hakupalvelun pääjako auton ostamisen näkökulmasta? Periaatteessa tässä vaiheessa käyttäjän haluaako hän tutustua uusiin autoihin vai vaihtoautoihin. Kuva 4.1. Autonet autohaku Tarkastellaan miten verkkopalvelu tukee käyttäjää "kiinnostavien vaihtoehtojen rajaamisen" prosessissa. Esimerkissä käyttäjä voi rajata vaihtoehdot käyttäen seuraavia kriteereitä: auton merkki ja malli alasvetovalikosta valittavissa auton tyyppi avoin tekstikenttä hinta sylinteritilavuus alasvetovalikko ajoneuvolaji/korimalli: alasvetovalikko: mikä tahansa, henkilöauto, kuorma-auto, pakettiauto polttoainetyyppi alasvetovalikko: mikä tahansa, bensiini, diesel kk-maksuerä autoetu alasvetovalikko: valitse tyyppi, käyttöetu, vapaa autoetu 65

8 Ovatko hakukriteerit valittu mielestäsi niin, että niiden perusteella on mahdollista löytää itselleen sopiva auto? Auton hinta lienee yksi keskeinen tekijä. Rajaavana tekijänä voisi toimia myös auton koko: "kauppakassi", perheauto vai tila-auto. Myös auton turvallisuuteen ja mukavuuteen liittyvät ominaisuudet saattaisivat olla tekijöitä, joiden avulla asiakas voisi rajat itselleen kiinnostavat vaihtoehdot. Nyt käyttäjä joutuu etsimään näitä tietoja aina merkki- ja mallikohtaisten esittelysivujen takaa. 5. Tilanteisiin liittyvät tarpeet Erilaisilla käyttäjäryhmillä voi olla erilaisia tarpeita liittyen käyttötilanteisiin. Prioriteetit voivat olla niin erilaisia, että niiden palveleminen vaatii erilaisia käyttöliittymiä. Esimerkiksi henkilöauton ostajalla on varmasti erilaisia vaatimuksia kuin kuorma-auton ostajalla. 6. Sidosryhmien tarpeiden tunnistaminen Sidosryhmillä tarkoitetaan sellaisia henkilöitä, joihin käsiteltävä asia jotenkin vaikuttaa. Usein määrittelytyössä keskitytään verkkopalvelun tuottajan taholta olevien sidosryhmien pyrkimysten ja tavoitteiden analysoimiseen. Harvoin kiinnitetään huomiota käyttäjän sidosryhmien tarpeiden analysointiin. Sidostahoja kannattaa etsiä mahdollisimman laajalta alueelta. Palvelun tuottajalla on saattaa olla monenlaista muutakin liiketoimintaa tai markkinointia, jossa voidaan edistää verkkopalvelun peruskäytön yhteydessä. Ts. voidaanko käyttötilanteessa myydä jotakin, saada hyödyllistä tietoja käyttäjistä tai neuvoa ja opastaa käyttäjiä ongelmallisessa kohdissa. Informaation jalostaminen edelleen On huomioitava, että käyttäjät, palvelun tuottajat sekä potentiaaliset sidosryhmien edustajat näkevät samaan asiaan liittyvät prosessit eri näkökulmista. Kun asiointiprosessi on jäsennetty eri toimijoiden näkökulmista, on helppo koota kuvaus siitä, mitä tapahtumia ja toimintoja ohjelmiston ja tietokannan tulee tukea. Työvälineenä voidaan hyödyntää esim. JSD Jackson Structured Design elinkaarien kuvaustekniikkaa tekstimuotoisena. JSD kuvaa prosessien elinkaarimalleja neljän perusrakenteen avulla: peräkkäisrakenne, vaihtoehdot, toistorakenne, rinnakkaisrakenne. (Wiio 2004, ) Esimerkki. Wiio (2004) havainnollistaa asiaa kurssin järjestämisen prosessin avulla: Kurssin suunnittelijan näkökulmasta: Alustava suunnitelma kurssista Suunnitelman prosessointi: rinnakkaisesti Kommentit markkinoinnista Kommentit johdolta Kommentit asiantuntijoilta Suunnitelman muokkaus Kurssin pitopäätös: vaihtoehtoisesti 66

9 Ei järjestetä kurssia Kurssi järjestetään Suunnitelman muutokset Palaute kurssilaisilta Kurssin uusinta: toistuvasti Uusintakurssi Kurssille osallistuvan näkökulmasta: Esitteen saanti Osallistumispäätös: vaihtoehtoinen Ei osallistumista Osallistuminen Ilmoittautuminen Vahvistus: vaihtoehtoisesti Peruutus Osallistuminen Osallistumisen vahvistus Materiaalin vastaanotto Luennot Palautteen anto Käyttötapauksia (Use case) voidaan käyttää edelleen kuvaamaan sitä tapaa, miten käyttäjä saa tavoitteensa toteutetuksi. Toisin sanoen käyttötapausten avulla mallinnetaan käyttäjän järjestelmän avulla toteuttamaa tehtävää. (Esim. Schneider & Winters 1998, 14 38; Wiio 2004, ) Käyttötapaus muodostaa jonkin loogisen kokonaisuuden, jolla on jokin selvä alkukohta ja jokin merkityksen omaava lopputulos. Käyttötapauksella on käyttäjä (actor), joka toimii käyttötapauksessa vuorovaikutuksessa järjestelmän kanssa tavoitteen saavuttamiseksi. Käyttäjän toiminta on syötteiden antamista ja palautteen saamista. Käyttötapaukseen liittyy aina tavoite, jonka toimija haluaa saada aikaiseksi, esimerkiksi ilmoittautua kurssille. (Esim. Schneider & Winters 1998, 14 38; Wiio 2004, ) Käyttötapausta kuvattaessa kerrotaan mitä käyttötapauksessa tapahtuu ja mistä asioista käyttäjä ja järjestelmä vaihtavat tietoa. Yleensä esitellään vuorovaikutustilanteen peruskulku. Tätä täydennetään edelleen kuvaten erilaiset muunnelmat ja poikkeustilanteet. Käyttötilanne ei kuitenkaan kerro vielä mitään siitä, miten käyttöliittymätasolla vuorovaikutustilanne toteutetaan. (Ibid.) Käyttötapauksen tarkoituksena on kuvata yleispätevästi mitä tapahtuu, kun esim. käyttäjä haluaa ilmoittautua kurssille. Käyttötapaus saattaa muodostua niin monimutkaiseksi ja abstraktiksi, ettei käyttäjä kykene ymmärtämään sitä. Käyttäjille käyttötapauksia konkretisoidaan esimerkkitapauksilla eli skenaarioilla. Skenaario kuvaa yhden tietyn käyttötapauksen sisältämän polun mitä tapahtuu kun esim. opiskelija ilmoittautuu kurssille.(ibid.) Käyttötapausten kuvaamiseen voidaan käyttää käyttötapauskuvauksia (use case description) sekä käyttötapauskaavioita (use case diagram), jotka kuvaavat usean käyttötapauksen väliset suhteet ja sekä käyttötapauksiin osallistuvat järjestelmän ulkoiset toimijat. Lisätietoa UML-kevyt johdatus [online]. Turku: Turun yliopisto, 2004 [viitattu ]. Saatavissa pdfmuodossa: <URL: >. 67

10 Miten saadaan tietoa käyttäjistä sekä heidän tarpeistaan ja tavoitteistaan? Käyttäjiä ja heidän toimintaansa koskevaa tietoa voidaan koota useilla eri menetelmillä. Usein hyödynnetään useampaa menetelmää samanaikaisesti. Esimerkiksi Turkki ja Sinkkonen (2004) jaottelevat menetelmät seuraavasti: Haastattelut ja kyselyt, joilla selvitetään käyttäjän käsityksiä ja mielipiteitä, tiedontarpeita ja asenteita. Havainnointi ja testaus, joissa käyttäjien toimintaa seurataan ja tulkitaan. Tarinat ja päiväkirjat, joilla kirjataan konkreettisia kokemuksia. Roolileikit eli simulaatiot, joilla simuloidaan ja varioidaan käyttötilanteita. Lisää menetelmiä UsabilityNet:in menetelmätaulukko. Methods table [online]. UsabilityNet, 2003 [viitattu ]. Saatavissa www-muodossa: <URL: Erilaisia menetelmiä voidaan hyödyntää periaatteessa kahdessa eri käyttötarkoituksessa: Testaaminen kuten erilaiset käytettävyystestit. Edellyttää, että käyttäjillä on käytössään tuote tai sen prototyyppi, jolla voidaan suorittaa erilaisia tehtäviä. Käyttäjien toiminnan hahmottaminen, jolla tarkoitetaan käyttäjien toiminnan seuraamista ja mallintamista tavoitteena käyttäjän toiminnan tukeminen. Esimerkiksi eläytymismenetelmä ja erilaiset skenaariot sekä tarinat ( vrt. Sinkkonen ym. 2002, ) Eläytymismenetelmällä voidaan kerätä kokemuksia kuten toiveita, pelkoja tai haaveita erilaisista ilmiöistä tai tapahtumakuluista tässä ajassa tai tulevaisuudessa. Eläytymismenetelmässä käytetään nk. kehyskertomuksia alkuorientaationa ja pyydetään vastaajia ideoimaan vapaasti niiden pohjalta. Olennaista menetelmän käytössä on kehyskertomuksen jonkun seikan (kuten tapahtumakulun, ajankohdan, käyttäjäryhmän) muuntelu muiden pysyessä muuttumattomina. Toimintatarinoiden avulla kerätään tietoa käyttötilanteista, tehtävistä, mahdollisuuksista ja rajoitteista sekä tavoitteista. > Tarinoista saadaan esille toiminnot, joita tuotteella tulee saada aikaiseksi. Käyttötarinat ovat tarinoita siitä miten asiat verkkopalvelussa tehdään uuden tuotteen avulla. > Tarinoista saadaan tuotteen mallit, kuvaukset, protot ja valmis palvelu. Tarinat luodaan arkikielellä. Etuina on mm. auttaa käyttäjää ymmärtämään mistä on kysymys > helpompi arvioida pakotta tarkastelemaan toimintoja käyttäjän näkökulmasta parempi terminologia lopullisessa verkkopalvelussa Skenaariot Skenaariot kuvaavat esimerkin omaisesti konkreettisia episodeja järjestelmän toiminnoista. Yleensä skenaarioina käytetään pieniä, rajattuja kuvauksia käyttötilanteista tarkoituksena kuvata yksi mahdollinen tapahtumapolku. Skenaario eräänlainen tarina, jolla on juoni ja "idea". (Esim. Rosson & Carroll 2002.) 68

11 Määrittelyistä malleista kuten esim. käyttötapauksesta (use case) voidaan johtaa useitakin skenaarioita (deduktiivisuus). Tämä on yleisempi tapa hyödyntää skenaarioita esim. arvioitaessa miten hyvin sovellus vastaa sille asetettuja vaatimuksia. Käyttäjälle annetaan ominaisuuksiltaan edustavia, tyypillisiä ja realistisia tehtäviä, joiden avulla sovelluksen arvioitava ominaisuus käydään läpi kattavasti. Tällöin hyödynnetään tehtäväskenaarioita, jotka kuvaavat mitä pitää saada aikaan, mutta eivät kerro suoritustapaa. (Esim. Potts 1995.) Joukosta skenaariota voidaan johtaa yleistyksiä eli yleisiä malleja kuten käyttötapauksia (induktiivisuus). Toisin sanoen skenaarioita voidaan hyödyntää vaatimusmäärittelyjen pohjana. ne muodostavat konkreettisia episodeja. Skenaariot soveltuvat varsin hyvin tiedon kokoamiseen käyttäjiltä heidän tehtävistään ja käyttötilanteista ja niihin liittyvistä vaatimuksista. Skenaariot ovat konkreettisia kuvauksia uusien monimutkaisesta ja abstraktisesta sovelluksesta. Ne helpottavat käyttäjää ymmärtämään mistä oikein on kyse sekä kiinnittämään vaatimusmäärittelyn todelliseen ympäristöön. (esim. Carroll ym. 1998; Potts 1995.) Perusideana on koota ns. merkityksellisten (salient) skenaarioiden joukko. Merkityksellinen skenaario on sellainen, joka nosta esiin jonkin tavoitteen ja sen saavuttamiseksi vaadittavan toiminnon väliseen vuorovaikutukselliseen liittyvän kysymyksen, joka täytyy ratkaista ennen kuin voidaan sanoa järjestelmän vastanneen käyttäjän tarpeisiin. Vaiheet Pottsin (1995) mukaan Käyttäjän tavoitteiden määrittelemien riittävän yleisellä tasolla (esim. kiinnostavien vaihtoehtojen rajaaminen). Tavoitteen jakaminen alatavoitteisiin (vrt. tehtäväanalyysi). Mahdollisten esteiden tunnistaminen (mitä tapahtuu, jos käyttäjä jättää jonkin valinnan tekemättä, ymmärtää väärin jonkin merkityksen jne.). Tavoitteen operationalisointi: tarina, joka toteuttaa tavoitteen. Skenaarioita tulisi olla riittävästi. Jokaisen järjestelmän käytön kannalta merkityksellinen tavoite tulee toteutua jonkin skenaarion välityksellä. Laajan järjestelmän ollessa kyseessä voi olla perusteltua keskittyä esim. mahdollisten esteiden analysointiin. On kuitenkin huomioitava, että skenaarioiden avulla ei saada kaiken kattavaa kuvausta järjestelmästä ja sen käytön mahdollisista esteistä. Aina tarvitaan täydentäviä menetelmiä. Toisaalta skenaariot voivat tuoda esiin sellaisiakin näkökulmia, jotka voivat jäädä muutoin huomaamatta. Case: toimintaprosessien suunnittelu Hypermedialaboratorion suunnitteleman verkkopalvelun suunnitteluvaiheessa hyödynnettiin skenaarioita käyttäjien tarpeiden määrittelyssä. Suunnittelutyötä varteen koottiin työryhmä, joka koostui suunnittelijoista sekä verkkopalvelun eri käyttäjäryhmien edustajista. Työryhmän kokoontumisiin pyrittiin luomaan rento tunnelma. Työryhmän jäseniä rohkaistiin monin tavoin tuomaan esille kaikki, hulluiltakin kuulostavat ideat. Tavoitteena oli saada kokoon mahdollisimman rikas aineisto (eli tarinoiden kokoelma), joiden pohjalta verkkopalvelun sisältämiä toimintoja ja asiointi- ja toimintoprosesseja lähdettiin rakentamaan. 69

12 Toimintaprosessien suunnittelutyössä lähdettiin liikkeelle ideoinnista, jossa hyödynnettiin skenaarioita eli tarinoita. Liikkeelle lähdettiin siten, että käyttäjät kertoivat tarinoita siitä miten keskeiset asiointi- ja toimintoprosessit toteutuvat tällä hetkellä reaalimaailmassa ja mitkä ovat ongelmallisimmat kohdat reaalimaailman palveluprosesseissa. Nämä reaalimaailman tapahtumiin pohjaavat kertomukset toimivat kehyskertomuksina auttaen käyttäjiä orientoitumaan ideoitaessa miten asiointi- ja toimintoprosessit voisivat toimia verkkopalvelun yhteydessä ja millaista lisäarvoa verkkopalvelu voisi käyttäjilleen tarjota. Eläytymismenetelmän avulla tuotettiin tarinoita, skenaarioita mahdollisista verkkopalvelun sisältämistä toiminnoista ja prosesseista (vrt. Carroll ym. 1998; Potts 1995.) Skenaarioiden pohjalta tutkijat loivat erilaisia, vaihtoehtoisia toimintaprosesseja, joita verkkopalvelu voisi sisältää. Näitä erilaisia toimintoprosesseja havainnollistettiin työryhmän jäsenille eli käyttäjille karkean tason prototyyppien (low-fidelity prototype) avulla (esim. power point -protot). Ensimmäisessä vaiheessa pyritin selvittämään ne keskeiset toiminnot mitä verkkopalvelun tulisi ainakin sisältää. Vielä tässä vaiheessa ei kiinnitetty niin tarkkaan huomiota siihen, millaisista vaiheista kukin yksittäinen toiminto tulee muodostumaan (toiminto- ja asiointiprosessien vaiheet). Menetelmänä käytettiin ryhmäläpikäyntiä. Eri kohderyhmien edustajista kootut ryhmät kuten työryhmä ja ohjausryhmä sekä suunnittelijat kävivät verkkopalvelun karkean tason protoversion avulla läpi tehtävät. Tavoitteena oli selvittää yleisellä tasolla mitä käyttäjän on mahdollista tehdä verkkopalvelun avulla sekä priorisoida verkkopalvelun sisältämät toiminnot. Kun usean iteraatiokierroksen jälkeen oli päästy yksimielisyyteen siitä mitä toimintoja verkkopalvelu tulisi sisältämään, lähdetin selvittämään millaisia vaiheita kukin toiminto itsessään tulee sisältämään, jotta toiminnolle asetetut tavoitteet saavutettaisiin. Jälleen käytettiin eläytymismenetelmää, jonka avulla tuotettiin tarinoita, skenaarioita potentiaalisista toiminto- tai asiointiprosessien etenemispoluista. Joukosta skenaariota johdettiin edelleen yleistyksiä eli yleisiä malleja kuten käyttötapauksia. Tavoitteena oli asiointi- ja toimintoprosessien mallintaminen ja sen vaiheiden tunnistaminen: mitä kaikkea tapahtumia ja vaiheita käyttäjä kohtaa ennen kuin hän on saanut tavoitteensa toteutetuksi. Myös asiointi- ja toimintoprosessien mallien toimivuus testattiin käyttäen karkean tason protojen avulla käyttäen hyväksi ryhmäläpikäynnin ideaa. Kun iteraatiokierrosten jälkeen oltiin saatu hahmotettua keskeisten prosessien etenemispolut työryhmää tyydyttävällä tavalla, laadittiin verkkopalvelusta prototyyppi, joka oli käytettävissä verkon välityksellä. Tässä prototyypissä ei kuitenkaan ollut aitoa toiminnallisuutta: käyttäjä pystyi esimerkiksi täyttämään lomakkeen, mutta syötettä ei tallennettu mihinkään. Skenaariotarinoita oli hyödynnetty myös siten, että verkkopalvelun prototyypissä käytettiin nimilappuina skenaariotarinoista peräisin olevia termejä. 70

13 Lähteet: Carrol, J. M. ym Requirements Development in Scenario-Based Design. IEEE Transactions on Software Engineering, Vol. 24 Issue 12, Gould, J.D.& Lewis, C Designing for usability: key principle and what designers think. Communication of the ACM, 28, Holzblatt, K. & Beyer, H. Making Customer-Centered Design Work for Teams [online] Communication of AMC, 1993 [viitattu ]. Saatavissa www-muodossa: <URL: ISO Guidance on Usability. Jordan, P.W An Introduction to Usability. London: Taylor & Francis. Keinonen, T One-dimensional usability - influence of usability on consumers' product preference. Taideteollisen Korkeakoulun julkaisu A21. Helsinki: Taideteollinen korkeakoulu. Nielsen, J Usability Engineering. San Diego (CA.): Morgan Kaufmann. Nielsen, J Ten Usability Heuristic [online]. Fremont: Nielsen Norman Group, 1994 [viitattu ]. Saatavissa www-muodossa: <URL: >. Norman, D Miten avata mahdottomia ovia? Tuotesuunnittelun salakarit. Suom. A. James. Helsinki: Weilin+Göös. Potts, C Using Schematic Scenarios to Understand User Needs. Proceedings of the conference on Designing Interactive Systems: processes, practices, methods & techniques: Ann Arbor, USA, elokuu 1995, Rosson, M. B. & Carrol, J. M. Scenario-Based design [online]. Blacksburg VA: Virginia Polytechnic Institute and State University, 2002 [viitattu ]. Saatavissa pdf-muodossa: <URL: >. Myös teoksessa: J. Jacko & A. Sears (Eds.) The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Mahwah (NJ.):Lawrence Erlbaum Associates, 2002, pp Samela, J Verkkosisällön hallinta. Helsinki: Edita Publishning Oy. Schneider, G. & Winters, J.P Applying Use Cases. A Practical Guide. Reading (MA.): Addisson-Wesley Longman Inc. Shackel, B Human factors and usability. Teoksessa: Preece, J. & Keller, L. (ed.) Human- Computer Interaction: Selected Readings. Hemel Hempstead: Prentice-Hall. Silius, K., Tervakari, A-M., Kaartokallio, H. & Yritys, K. Tieto- ja viestintätekniikka-avusteisen opetuksen käyttökelpoisuuden arviointimalli [online]. Espoo: Suomen virtuaaliyliopiston kehittä- 71

14 misyksikkö, 2003 [viitattu ]. Suomen virtuaaliyliopiston e-julkaisuja nro 9. Saatavissa pdf-muodossa: <URL: > ISBN Sinkkonen, I. ym Käytettävyyden psykologia. Helsinki: Edita Oyj. Turkki,L. & Sinkkonen, I. Esteetön vai käytettävä? [online]. Helsinki: Adage Oy, 2004, julkaistu , [viitattu ]. Saatavissa www-muodossa: <URL: >. Wiio, A Käyttäjäystävällisen sovelluksen suunnittelu. Helsinki: Edita Publishing Oy. 72