4. Verkkopalvelun sisällölliset ja toiminnalliset vaatimukset

Transkriptio

1 4. Verkkopalvelun sisällölliset ja toiminnalliset vaatimukset Ei riitä, että edetään parhaan tämänhetkisen tiedon mukaan ja otetaan huomioon ne asiat, jotka tunnetaan (Turkki & Sinkkonen, 2004) Määrittelyvaiheen merkitys 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. Yleisellä tasolla nämä asiat on määritelty synopsiksessa, joka hyväksytetään tilaajalla. Suunnittelutyön seuraavissa vaiheissa ryhdytäänkin tarkentamaan verkkopalvelun toteuttamiseen liittyvät edellytyksiä, riskejä, vaatimuksia ja rajoituksia. Tavoitteena on syventää ja laajentaa synopsiksessa esitettyjä määritelmiä: mitä (aihe), kenelle (kohdeyleisö), miksi (tavoite) ja miten (käyttötapa). Määrittelyvaihe (tai vaatimusmäärittely, vaatimusanalyysi jne. 1 ) on eräs verkkopalveluprojektin kriittisimpiä vaiheita, sillä yleisimmin ohjelmistoprojektien epäonnistumisen syynä on puutteellisesti tehty määrittelytyö (Taylor 2000). Pahimmillaan epäonnistunut määrittelytyö johtaa toteutukseen, jota asiakkaat (käyttäjät) eivät käytä. Ennen varsinaiseen verkkopalvelun toteuttamistyöhön ryhtymistä onkin selvitettävä ja analysoitava monenlaisia ja monentasoisia tekijöitä, joita ovat esimerkiksi: asiakkaat (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. Määrittelytyön keskeisenä tavoitteena on ilmaista eri tahoilta nousevat vaatimukset määrittelydokumentissa mahdollisimman konkreettisina, yksiselitteisinä sekä selkeinä. Epäselvästi ja puutteellisesti määritellyt vaatimukset johtavat helposti siihen, että eri toimijoilla saattaa olla suurestikin toisistaan eriävät käsitykset siitä mitä itse asiassa ollaan tekemässä. Haasteelliseksi tämän tekee muun muassa se, että vaatimuksia on monentasoisia ja monen tyyppisiä. 1 Verkkopalvelun suunnittelutyöhön liittyvään vaatimusten määrittelyyn viitataan englanninkielisessä kirjallisuudessa erilaisin termein kuten esim. requirements gathering, requirements capture, requirements elicitaion, requirements analysis, requirements engineering. Eri käsitteet ilmentävät erilaista näkemystä vaatimusten luonteesta (Preece, Rogers & Sharp 2002, 204). 53

2 4.2. Erityyppisiä vaatimuksia Vaatimuksia on paitsi monentasoisia myös erityyppisiä. Eri tutkijoiden näkemykset siitä minkä tyyppisiin asioihin verkkopalvelun määrittelyvaiheessa tulisi kiinnittää huomiota vaihtelevat ensinäkin sen suhteen mitä määrittelytyön osa-alueita he painottavat. Esimerkiksi ajatellaanko saavutettavuus erillisenä osa-alueena, johon liittyvä määrittelytyö tulee tehdä erikseen vai ajatellaanko saavutettavuuteen liittyvien vaatimusten määrittely osana käyttäjä- ja käytettävyysvaatimuksia (vrt. Silius ym. 2003). Toisekseen näkemykset eroavat sen suhteen miten laajasti vaatimusmäärittelyn tulee kattaa verkkopalvelun eri tasot. Määrittelytyö voidaan ulottaa kattamaan verkkopalvelun verkossa toimivan ns. virtuaalisen osion (virtual service) ohella myös ne palvelun fyysisen osion (physical service) toimintoprosessit, jotka täydentävät virtuaalista palveluprosessia (vrt. Sousa & Voss 2004) Käyttökelpoisuuden ulottuvuudet Jotta verkkopalvelu olisi käyttökelpoinen (usefulness) on sen täytettävä käytön sujuvuuteen ja verkkopalvelun hyödyllisyyteen (utility) liittyvät vaatimukset (vrt. Nielsen 1993; Silius ym. 2003): Verkkopalvelun käytön sujuvuus Käytettävyysvaatimukset (usability requirements): verkkopalvelun on täytettävä tiettyyn tehokkuuteen, opittavuuteen, muistettavuuteen ja virheettömyyteen liittyvät vaatimukset. Saavutettavuusvaatimukset (accessibility requirements): verkkopalvelun tulee olla käytettävissä tietyissä käyttötilanteissa, tietyillä päätelaitteilla sekä tietyistä käyttäjien yksilöllisistä ominaisuuksista riippumatta. Verkkopalvelun hyödyllisyys (verkkopalvelun tulee soveltua tiettyyn käyttötarkoitukseensa) Tavoitteen saavuttamisen tukemiseen liittyvät vaatimukset, jotka riippuvat verkkopalvelun käyttötarkoituksesta (asiointi, tiedonhaku, viihtyminen, kuluttaminen jne.): Merkityksellisten sekä virtuaalisten että fyysisten toiminto- ja asiointiprosessien tukeminen (korostuu operatiivisissa verkkopalveluissa), Informaation laadukkuus kuten informaatioarkkitehtuuri, informaation esitystapa ja luotettavuus (korostuu erityisesti viestinnällisissä verkkopalveluissa). Verkkopalvelun käytön tuottama hyödyn eli lisäarvon (added value) toteutumiseen liittyvät vaatimukset Taustalla on ajatus, että eritasoisten kontekstien vaatimukset välittyvät em. vaatimusten kautta. Esimerkiksi käyttäjän henkilökohtaisessa kontekstissa vaikuttavat psyykkiset ja fyysiset tekijät asettavat tiettyjä vaatimuksia, jotka tulee ottaa huomioon niin käytettävyys- ja saavutettavuusvaatimuksia kuin verkkopalvelun hyödyllisyyteen liittyvien vaatimusten määrittelyssä. Sosiaalisessa ja yhteiskunnallis-kulttuurisessa kontekstissa vallitsevien arvostusten ja toimintakulttuurien asettamien vaatimusten katsotaan välittyvän käyttäjien henkilökohtaisten kontekstien kautta. (Silius ym ) 54

3 Preece, Rogers & Sharp Toiminnalliset vaatimukset (functional requirements): kuvaa toimintoja toteutuksen tulee kyetä suorittamaan Informaatiosisältöön liittyvät vaatimukset (data requirements): informaatiosisällön määrä/koko, tyyppi, pysyvyys, luotettavuus, ajantasaisuus yms. Käyttökontekstiin liittyvät vaatimukset (environmental requirements, context of use): olosuhteet, jossa toteutusta tullaan käyttämään Fyysisen toimintaympäristön (physical environment) asettamat vaatimukset kuten esim. valaistus, melu, liike Sosiaalisen toimintaympäristöön (social environment) liittyvät vaatimukset kuten kommunikointi, informaation jakaminen ja yhteistoiminta Organisationaalisen toimintaympäristön (organizational environment) asettamat vaatimukset kuten käyttäjien koulutus ja tukipalvelut, kommunikointijärjestelmät Teknisen ympäristön (technical environment) asettamat rajoitukset ja vaatimukset niin tuotantoteknologiaan kuin lopullisen toteutuksen sijoitusympäristöön liittyen Käyttäjävaatimukset (user requirements): keskeisten käyttäjäryhmien ominaispiirteet ja niistä juontuvat vaatimukset esim. käyttäjien tieto- ja taitotaso. Käyttäjien ominaispiirteiden perusteella muodostetaan tyypillisten käyttäjien profiilit (user profile), joita yhdellä tuotteella voi olla useampiakin (katso kurssin oppimateriaali 3, s. 42). Käytettävyysvaatimukset (usability requirements): esimerkiksi (suorituskyvyn) tehokkuus (efficiency), tuottavuus (tehokkuus tavoitteen saavuttamisen kannalta) (effectiveness), opittavuus (learnability), muistettavuus (memorability), varmuus (safety) jne. Käyttäjäkokemukseen liittyvät tekijät (user experience goals) : kuten miellyttävyys, viihdyttävyys, esteettisyys, motivoivuus, jännitys jne. (Preece, Rogers & Sharp 2002, ) Esimerkki: Preece, J., Rogers, Y. & Sharp, H. Identifying Needs and Establishing Requirements. Assignment Comments [online] [viitattu ]. A companion website for the book Interaction Design: beyond human-computer interaction. Saatavissa www-muodossa: <URL: > The Volere Requirements Specification Template Volere vaatimusmäärittelyn mallissa vaatimukset ymmärretään varsin laaja-alaisesti. Mallissa on otettu huomioon sekä itse toteutettavaan verkkopalveluun että tuotantoprojektiin liittyvät vaatimukset. Erityyppiset vaatimukset ryhmitellään viiteen eri ryhmään: Projektin perusvaatimukset (project drivers): Vaatimuksia toteutukselle asettavat projektin perusvaatimukset (mitä ollaan tekemässä), tilaajan ja eri sidosryhmien asettamat vaatimukset sekä käyttäjän asettamat vaatimukset. Näkökulma on verkkopalvelun liiketoimintaan liittyvä. Projektin rajoitukset (project constraints): Vaatimukset, jotka liittyvät teknologiaan (valmiin palvelun tekninen toimintaympäristö, integrointi muihin teknisiin järjestelmiin, tekninen tuotantoympäristö), aikatauluihin ja budjettiin. Lisäksi määrittelytyössä käytettävät termit ja niiden määritykset sekä erilaiset suunnittelutyössä huomioonotettavat tekijät, jotka 55

4 eivät ole varsinaisia vaatimuksia, mutta joilla voidaan olettaa olevan vaikututusta toteutettavaan verkkopalveluun. Toiminnalliset vaatimukset (functional requirements): Verkkopalvelun asiointi- ja toimintoprosessien toiminnallinen määrittely (myös mahdolliset olemassa olevat prosessit, jotka tullaan korvaamaan/täydentämään uuden verkkopalvelun myötä). Lisäksi käyttötapauksiin liittyvät toiminnalliset ja informaatiosisältöön liittyvät vaatimukset. Ei-toiminnalliset vaatimukset (non-functional requirements): Toimintojen toteutumisen kannalta olennaiset vaatimukset kuten käytettävyys, saavutettavuus ja esitystapa. Myös personointi, turvallisuus, varmuus, luotettavuus, saatavuus sekä skaalautuvuus jne. lisäksi mm. kulttuuriset ja lainsäädäntöön liittyvtä vaatimukset. Projektiin liittyvät tekijät (project issues): Eivät ole varsinaisia tuotettavaan verkkopalveluun liittyviä vaatimuksia. Tässä luokassa esitetyt vaatimukset ovat merkittäviä verkkopalvelun suunnittelu- ja tuotantoprojektin onnistumisen kannalta kuten esimerkiksi olemassa olevien tuotteiden hyödyntäminen osana suunnittelua ja tuotantoa sekä riskit yms. (Robertson & Robertson 2006.) Taulukko 4.1. The Volere Requirements Specification Template. (Lähde: Robertson & Robertson 2006) PROJECT DRIVERS: 1. The Purpose of the Product 2. Client, Customer, Stakeholders 3. Users of the Product PROJECT CONSTRAINTS: 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS: 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements NON-FUNCTIONAL REQUIREMENTS: 10. Look and Feel 11. Usability and Humanity 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal PROJECT ISSUES: 18. Open Issues 19. Off-the-shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation 26. Waiting Room 27. Ideas for Solutions Lisätietoja: Robertson, J. & Roberston, S The Volere Requirements Specification Template [online]. London: The Atlantic System Guil Limited, 2006, [viitattu ]. Edition 11. Saatavissa www-muodossa: <URL: >. 56

5 4.3. 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.) Asiakkaan, palvelun tuottajan sekä eri sidosryhmien 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 Kuka on asiakas tai käyttäjä? Suunnittelutyön yksi keskeisimpiä tehtäviä on käyttäjien tarpeiden tunnistaminen. Ensimmäisen haasteen muodostaa asiakkaiden tai käyttäjien määritteleminen. Merkittävimmän ryhmän muodostaa tietenkin ne henkilöt, jotka toimivat vuorovaikutuksessa verkkopalvelun kanssa tietyn tavoitteen saavuttamiseksi ja jotka käyttävät verkkopalvelua suhteellisen usein. Sekundaarisena käyttäjän voidaan pitää sellaisia henkilöitä, jotka käyttävät verkkopalvelua harvoin tai välillisesti. Kolmantena käyttäjäryhmänä voidaan mainita sellaiset henkilöt tai tahot, jotka vaikuttavat verkkopalvelun käyttöönottoon jollakin tavalla tai ne henkilöt, joiden omaan toimintaan verkkopalvelun käyttöönotto vaikuttaa jollakin tavalla. (Vrt. Eason 1987 ref. Preece, Rogers & Sharp 2002, 171; Abras, Maloney-Krichmar & Preece 2004.) Kysymyksessä on siis varsin laaja joukko ihmisiä. Varsinaisten käyttäjien ohella puhutaankin sidosryhmistä (stakeholders). Sidosryhmillä tarkoitetaan sellaisia tahoja tai henkilöitä, joihin tässä tapauksessa verkkopalvelu jotenkin vaikuttaa. Sidosryhmiin luetaan esimerkiksi loppukäyttäjät, verkkopalveluun liittyvien organisationaalisten prosessien hallinnoijat ja toimijat, verkkopalvelun ylläpidosta ja kehityksestä vastaavat tahot, verkkopalvelua tai siihen liittyvä prosesseja hyödyntävät organisaation omat asiakkaat ja alihankkijat, erilaiset ulkoiset toimijat kuten tietoliikenneyhteyksiä tarjoavat organisaatiot, viranomaiset jne. (Esim. Kotonoya & Sommerville 1998 ref. Sharp, Finkelstein & Galal 1999.) Verkkopalvelun määrittelytyön keskeisiä ongelmia on se, että sidosryhmät määritellään joko liian kapeasti huomioiden ainoastaan kaikkein ilmeisimmät sidosryhmät ja heidän vaatimuksensa. Ongelmia syntyy myös silloin, kun sidosryhmät määritellään liian väljästi. Vaarana on vaatimusten määrittely liian yleisellä tasolla, jotta niitä kyettäisiin soveltamaan käytäntöön. (Sharp, Finkelstein & Galal 1999.) Sharp, Finkelstein ja Galal (1999) esittelevät artikkelissaan erään tavan sidosryhmien tunnistamiseksi. 57

6 Tunnista perustason sidosryhmät Käyttäjät (users): tunnista keskeiset käyttäjäryhmät esim. noviisikäyttäjät ja kokeneet käyttäjät. Järjestelmän kehittäjät (developers) kuten suunnittelijat, toteuttajat, tietoliikennevastaavat, projektiorganisaation jäsenet yms.: tunnista keskeiset toimijaryhmät. Päätöksentekijät (decision-makers): tunnista keskeiset toimijaryhmät. Erilaiset ohjaavat tahot (legislators) kuten esim. laadunvalvonta, viranomaiset: tunnista keskeiset toimijaryhmät. Käyt läpi jokaisen sidosryhmän keskeiset toimijaryhmät Analysoi kunkin perustason sidosryhmän (käyttäjät, järjestelmän kehittäjät, päätöksentekijät, ohjaavat tahot) keskeiset toimijaryhmät ja tunnista kunkin ryhmän osalta Hankkijat (supplier), jotka tuottavat informaatiota tai tukevat tietyn prosessin toteutumista. Asiakkaat (client), jotka suorittavat toimintoja tai käyttävät tuotetta. Satelliitit, jotka ovat vuorovaikutuksessa (esim. kommunikointi, informaation haku ja omaksuminen) sidosryhmän kanssa. Tunnista tärkeimmät sidosryhmät ja niiden edustajat priorisoi. System Satellite stakesholder interact affect Baseline stakesholder (users,developers, legislators, decision-makers) interact Satellite stakesholder Supplier stakesholder support products Client stakesholder Kuva 4.1. Sidosryhmien tunnistaminen. Lähde: Sharp, Finkelstein & Galal Lisätietoja: Sharp, H., Finkelstein, A. & Galal, G. Stakeholder identification in the requirements engineering process [online] [viitattu ]. Saatavissa pdf-muodossa <URL: >. Proceedings of the 10th International Workshop on Database & Expert Systems Applications on the 1-3 September 1999 in Florence. Italy, ISBN: Bryson, J. M. What to do when stakeholders matter. Stakeholder Identification and Analysis Techniques [online]. 2004, [viitattu ]. Saatavissa pdf-muodossa: <URL: lysis%20pmr%20article.pdf >. Saatavissa painettuna Public Management Review, Volume 6, Number 1, March 2004,

7 Käyttökelpoisuuteen liittyviä vaatimuksia Verkkopalveluiden käytön ongelmat voivat liittyä käytössä oleviin laitteisiin ja ohjelmistoihin tai käyttäjän fyysisiin tai kognitiivisiin toimintarajoitteisiin kuten esimerkiksi havaitsemiseen, motoriikan hallintaan, oppimiseen tai kielen ymmärtämiseen. Rajanveto käytettävyys- ja saavutettavuusongelmien välille on vaikeaa. Viime kädessä kysymys on ennen kaikkea tasa-arvoisuudesta ja erilaisuuden huomioimisesta. 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ötilanteissa olevat henkilöt sekä ikäihmiset ja eri-ikäiset lapset. Minkä tahansa verkkopalvelun tulisi täyttää käytettävyyden toteutumiselle asetetut vaatimukset. Yleisellä tasolla käytettävyyden voidaan ajatella tarkoittavan 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. Haasteelliseksi käytettävyyteen liittyvän vaatimusmäärittelyn tekee se, että käytettävyyttä voidaan tarkastella monesta eri näkökulmasta (esim. Keinonen 1998): Käytettävyys 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 Käytettävyys 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öä. Käytettävyys 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äytettävyys käyttäjän kokemuksiin liittyvä ominaisuus: tarkastelun kohteena on tällöin mm. käytön tyydyttävyys ja palkitsevuus, 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 (vrt. Preece, Rogers & Sharp 2002, 19). Käytettävyyden ja saavutettavuuden toteutumiselle asetettujen vaatimusten määrittely on varsin haastava tehtävä, sillä huomioon otettavat tekijät ovat varsin monentasoisia ja moniulotteisia (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ä 59

8 Kontekstitekijät: kohteena oleva tehtävä, käyttäjän yksilölliset kyvyt ja rajoitukset, käyttötila ja sen olosuhteet, käyttötilanne. Suunnittelutyön varhaisessa vaiheessa onkin määriteltävä mitä saavutettavuudella ja käytettävyydellä tässä yhteydessä tarkoitetaan (vrt. Robertson & Robertson 2006). Seuraavaksi on tunnistettava verkkopalvelulle asetetut saavutettavuus- ja käytettävyysvaatimukset sekä dokumentoitava ne riittävän yksiselitteisesti. Osa vaatimuksista on jo luonnostaan ilmaistavissa konkreettisesti ja yksiselitteisesti (esim. yksittäisen sivun latausajan on oltava alle 5 sekuntia tietyntyyppisellä verkkoyhteydellä). Tämän tyyppisen vaatimuksen toteutumisen arvioiminen on myös yksinkertaista. Osa vaatimuksista on taas luonteeltaan hyvin abstrakteja ja hankalasti ilmaistavissa (esim. sivuston tulee olla vuotiaiden tyttöjen mielestä kiinnostava). Tämän tyyppisen vaatimuksen määritteleminen edellyttää ensinnäkin taustatutkimusta kuten esimerkiksi tietyn ikäisten tyttöjen haastattelua. Toiseksi on myös mietittävä millä perusteella voidaan arvioida onko ko. vaatimukseen onnistuttu vastaamaan. (Vrt. Garret 2003, 40 59; Preece, Rogers & Sharp 2002, ) Lisätietoa: 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 www-muodossa: <URL: > Vaatimuksena lisäarvon tuottaminen Jo varhaisessa vaiheessa verkkopalvelun suunnittelutyötä pyritään vastaamaan kysymykseen miksi verkkopalvelu ylipäätään aiotaan toteuttaa. Vastaus kysymykseen pitää sisällään erään keskeisimmistä verkkopalvelulle asetetuista vaatimuksista, joka liittyy verkkopalvelun tarjoamaan lisäarvoon. Tarkasteltaessa verkkopalvelun lisäarvoja vertaillaan yleensä verkkopalvelua suhteessa perinteiseen tapaan tuottaa palvelu ja pohditaan mitä erityistä hyötyä tietoverkon käyttö tietyssä käyttötilanteessa tuo organisaatiolle ja asiakkaille sekä sidosryhmille verrattuna ns. perinteisesti palveluun. Täysin uudentyyppisen verkkopalvelun ollessa kysymyksessä lisäarvoa voidaan tarkastella vertailemalla verkkopalvelun tarjoamaa hyötyä suhteessa käyttäjien toimintaan tavoitteen saavuttamiseksi henkilökohtaisessa kontekstissaan. Lisäarvoa voi syntyä myös silloin kun verkkopalvelu tarjoaa ratkaisun johonkin reaalimaailman ongelmaan. Huomioitavaa on myös se, että tietoverkon hyödyntämisen palveluprosessissa tulisi tuottaa jotakin erityistä hyötyä tai lisäarvoa sekä asiakkaalle että organisaatiolle. Suurin kokonaishyöty saadaan silloin kun mahdollisimman moni osapuoli saa erityistä lisäarvoa verkon hyödyntämisestä palvelussa. 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. 60

9 Palvelun tarjoajan näkökulmasta verkkopalveluun siirtymisen syynä saattaa olla myös toimintojen virtaviivaistaminen. 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. Verkkopalvelun hyötyjä perustellaan usein myös sisällönhallinnan eli digitaalisen sisällön tuottamisen, julkaisemisen, jakelun, poistamisen ja arkistoinnin tehostumisella. Tätä perustellaan esimerkiksi sillä, että digitaalista informaatiota on helppo tallentaa ja kopioida sekä käyttää uudelleen. Sen siirrettävyys on nopeaa, sama informaatio soveltuu eri medialle ja siirtokanaville, joten informaation jakaminen on helppoa. Myös informaatiosisällön muokkaus ja päivittäminen on helppoa informaation muuttuessa tai vanhentuessa jne. 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.) Ansaintalogiikka Ansaintalogiikalla tarkoitetaan loogista mallia tai suunnitelmaa, jolla palvelusta tai tuotteesta on tarkoitus aikaansaada kannattava. Ansaintalogiikka voi liittyä esim. kustannussäästöihin tai tuottavuuden lisääntymiseen, joita verkkopalvelulla tavoitellaan. Toisekseen ansaintalogiikka voi liittyä uusien markkinoiden valtaamiseen tai asiakkaiden sitouttamiseen. Kolmanneksi ansaintalogiikka voi liittyä myyntitulon saamiseen. Ansaintalogiikka onkin osa liiketoimintamallia. Ansaintalogiikan kehittäminen ja uudet liiketoimintamahdollisuudet teknologioiden ja sisältöjen rajapinnoilla kiehtovat verkkopalveluun siirtyviä yrityksiä. Ansaintalogiikkaa mietittäessä täytyy tunnistaa mahdolliset myyntituloa tuottavat vastineet, jotka voivat liittyä sisällön alkutuotantoon 2, käytettyihin teknologisiin ratkaisuihin, tuotekehitykseen ja lopputuotteisiin tai liiketoiminnan eri prosesseihin. Toisin sanoen on pyrittävä tunnistamaan sellaiset tekijät, joista voidaan kerätä maksu ja josta ollaan valmiita maksamaan. Esimerkiksi osallistumisesta (jäsenmaksu), näkyvyydestä (mainokset yms.), palvelusta sinänsä (käyttömaksu), sisältötuotteista tai konkreettisista tuotteista (maksu). Lisäksi verkkopalvelun käyttötilanteisiin saattaa palvelun tuottajan näkökulmasta liittyä useitakin potentiaalisia ansaintamahdollisuuksia esim. oheistuotteiden ja palveluiden myyntiä. 2 Sisällön alkutuotannolla tarkoitetaan niitä toimintoja, joissa informaatiosisä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. 61

10 4.4. Miten saadaan tietoa käyttäjistä sekä heidän tarpeistaan ja tavoitteistaan? Käyttäjistä, käyttötilanteista kootaan tietoa, joka otetaan huomio verkkopalvelun suunnittelu- ja toteutustyössä mahdollisimman kattavasti. Verkkopalveluiden 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ä ovat mm. "Joint Application Design", "user-centered requirements analysis", "user-centered design", "many participatory design techniques" ja "Contextual Design". (Holzblatt & Beyer, 1993.) 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. Edellyttää, että käyttäjillä on käytössään tuote tai sen prototyyppi, jolla voidaan suorittaa erilaisia tehtäviä. Tarinat ja päiväkirjat, joilla kirjataan konkreettisia kokemuksia. Roolileikit eli simulaatiot, joilla simuloidaan ja varioidaan käyttötilanteita. Eräs tunnettu menetelmä informaation keräämiseksi sovelluksen käyttökontekstista jo ennen suunnittelun alkamista erilaisten vaatimusmäärittelyjen pohjaksi on tilannetutkimus (Contextual Inquiry). 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.) Lisätietoa Requirements [online]. UsabilityNet, 2003 [viitattu ]. Saatavissa www-muodossa: <URL: > Erilaisia menetelmiä, joita voidaan hyödyntää vaatimusten määrittelyssä. Routio, P. Tuote ja tieto. Tuotteiden tutkimus ja kehittäminen [online]. Helsinki: Taideteollinen korkeakoulu, päivitetty [viitattu ]. Kyselevät tutkimustavat. Saatavissa www-muodossa: <URL: >. Routio, P. Tuote ja tieto. Tuotteiden tutkimus ja kehittäminen [online]. Helsinki: Taideteollinen korkeakoulu, päivitetty [viitattu ]. Toteava havainnointi ja koe Saatavissa www-muodossa: <URL: >. 62

11 Tarinat informaation kokoamisen apuna Tarinoiden kertominen on ihmiselle luontainen tapa ilmaista mitä on tekemässä tai miten saavuttaa jokin tavoite. Toisaalta eri sidosryhmien edustajat ymmärtävät tavallisella arkikielellä kerrotut tarinat helpommin kuin esim. suunnittelijoiden ammattikielellä ilmaistut asiat. Tällöin eri käyttäjien on helpompi ymmärtämää mistä on kysymys sekä myös helpompi arvioida asiantilaa. Toiseksi tarinoiden käyttö pakottaa suunnittelijat tarkastelemaan toimintoja käyttäjien näkökulmasta. Kolmantena etuna voidaan mainita se, että tarinoiden avulla saadaan koottua käyttäjille tuttua terminologiaa hyödynnettäväksi lopullisessa verkkopalvelussa. Paitsi sanallisessa muodossa voidaan tarinoita kertoa myös sarjakuvina, elokuvina, multimedian avulla tai näytelmänä. Tarinoita hyödynnetäänkin esimerkiksi eläytymismenetelmissä sekä käyttäjien toimintojen ja käyttötapahtumien hahmottamiseen. (Vrt. Preece, Rogers & Sharp 2002, ; Sinkkonen ym. 2002, ) Eläytymismenetelmä on aineistonhankintatapa, jonka avulla 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. kehyskertomusta alkuorientaationa ja pyydetään vastaajaa ideoimaan ja kirjoittamaan tarina vapaasti sen pohjalta. Olennaista menetelmän käytössä on se, että kaikki vastaajat eivät eläydy täsmälleen samaan kehyskertomukseen. Yleensä käytetään kahta neljää kehyskertomusta, joissa jokin seikka kuten käyttötilanne, ajankohta tai käyttäjäryhmä vaihtelee muun osan kehyskertomuksessa pysyessä muuttumattomana. Tarinoita voidaan menestyksekkäästi hyödyntää käyttäjien toiminnan hahmottamisessa. Sinkkosen ym. (2002) mukaan toiminnan hahmottamisessa voidaan käyttää toimintatarinoita ja käyttötarinoita. Toimintatarinoiden avulla kerätään tietoa käyttötilanteista sekä niihin liittyvistä tehtävistä, mahdollisuuksista ja rajoitteista sekä tavoitteista. Tarinoiden avulla saadaan esille toiminnot, joita tuotteella tulee saada aikaiseksi. Käyttötarinat puolestaan ovat tarinoita siitä miten asiat verkkopalvelussa tehdään uuden tuotteen avulla. Käyttötarinat kuvaavat Sinkkosen yms. (2002, 35) mukaan konkreettisia käyttötapahtumia ja niihin kerätään tavoitteellisten toimintojen alatavoitteet, tavoitteen muodostumisen aikaansaavat tekijät sekä tarvittava palaute, josta tiedetään siirtyä seuraavaan alatavoitteeseen. Toimintatarinat Käyttötarinat Navigointimallit Paperiprotot Toimivat protot Tuotteet Käytettävyyden tarkistukset Kuva 4.1. Toimintatarinat muunnetaan malleiksi, kuvauksiksi, protoiksi ja tuotteeksi. Lähde. Sinkkonen ym. 2002, 34. Lisätietoa Saaranen, A. & Puusniekka, A. KvaliMOTV - Menetelmäopetuksen tietovaranto [online]. Tampere: Yhteiskuntatieteellinen tietoarkisto, 2006 [viitattu ]. Luku 6.5 Eläytymismenetelmä. saatavissa www-muodossa: <URL: >. 63

12 Skenaariot suunnittelun tukena Skenaariot kuvaavat esimerkinomaisesti konkreettisia episodeja käyttäjän toiminnoista. Skenaario eräänlainen epämuodollinen tarina, jolla on juoni ja "idea". Yleensä skenaarioina käytetään pieniä, rajattuja kuvauksia käyttötilanteista kuvaamassa yhtä mahdollista tapahtumapolkua, joiden pohjalta voidaan keskustella käyttökontekstista, tarpeista ja vaatimuksista. Skenaario ei ole abstrakti kuvaus ihmisen ja tietokoneen välisestä vuorovaikutuksesta eikä esimerkiksi lista järjestelmän ominaisuuksista tai toiminnoista. Skenaariot kuvaavat arkikielellä konkreettisen episodin ihmisen ja tietokoneen välisestä vuorovaikutuksesta sekä käyttäjän henkilökohtaisesta kokemuksesta. (Esim. Preece, Rogers & Sharp 2002, 223; Rosson & Carroll 2002.) Yleisimmin skenaarioita hyödynnetään 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 ns. tehtäväskenaarioita, jotka kuvaavat mitä pitää saada aikaan, mutta eivät kerro suoritustapaa. Myös määrittelyistä malleista kuten esim. käyttötapauksesta (use case) voidaan johtaa useitakin skenaarioita (deduktiivisuus). Käyttötapaus kuvaa yleispätevästi mitä tapahtuu, kun käyttäjä toimii tietyn tavoitteen saavuttamiseksi. Käyttötapaus saattaa muodostua niin monimutkaiseksi ja abstraktiksi, ettei käyttäjä kykene ymmärtämään sitä. Tällöin käyttötapauksia voidaan konkretisoida käyttäjälle esimerkkitapauksilla eli skenaarioilla. Skenaario kuvaa yhden tietyn käyttötapauksen sisältämän polun mitä tapahtuu kun esim. opiskelija ilmoittautuu kurssille verkkolomakkeen välityksellä. (Esim. Potts 1995.) Joukosta skenaariota voidaan johtaa yleistyksiä verkkopalvelun toimintamalleista ja käyttötapahtumista eli tuottaa yleisiä malleja kuten käyttötapauksia (induktiivisuus). Toisin sanoen skenaarioita voidaan hyödyntää vaatimusmäärittelyjen pohjana. Samalla ne helpottavat käyttäjää ymmärtämään mistä oikein on kyse sekä auttavat kiinnittämään vaatimusmäärittelyn todelliseen ympäristöön. Skenaariot ovat myös helposti kehitettävissä, jaettavissa ja kerrattavissa. Lisäksi niiden pohjalta voidaan helposti laatia luonnoksia, kuvakäsikirjoituksia sekä erilaisia malleja ja prototyyppejä. (Esim. Carroll ym. 1998; Potts 1995.) Skenaariot voivat olla karkeita tai hyvinkin yksityiskohtaisia kuvauksia episodeista tarjoten siten paitsi konkreettisen myös joustavan työvälineen määrittelytyön tueksi. Alkuvaiheen skenaariot ovat yleensä varsin karkeita kuvauksia toiminnoista, joita käyttäjät järjestelmällä haluavat tehdä. Tässä vaiheessa ei kuitenkaan kuvailla kovinkaan yksityiskohtaisesti miten toiminnot toteutetaan tai miten vuorovaikutus käyttäjän ja järjestelmän tapahtuu. (Vertaa toimintatarinat Sinkkonen yms. 2002, 35.) Rossonin ja Carrollsin (2002) mukaan skenaariopohjaisessa suunnittelussa (scenario-based design) vaatimusten analysointi on hyvä aloittaa määrittelemällä ja rajaamalla järjestelmän vaatimukset ns. peruskäsitteiden (root concept) avulla. Peruskäsitteet voidaan poimia esim. synopsiksesta, jossa on jo karkealla tasolla määritelty mitä järjestelmällä voidaan tehdä, miksi järjestelmä tullaan toteuttamaan sekä kenelle järjestelmä on tarkoitettu. Nämä peruskäsitteet toimivat lähtökohtana varsinaiselle vaatimusmäärittelylle. Vaatimusten analysointivaiheen keskeisin tulos on joukko ongelmia kuvaavia skenaarioita (problem scenario) sekä väittämiä (claims), jotka voivat perustua havaintoihin tai käyttäjien tuottamiin tarinoihin. Tehokas tapa laatia ongelmia kuvaavia skenaarioita on ensin laatia käyttäjäprofiilit eli rikas kuvaus oletetuista tai tunnistetuitta sidosryhmien edustajista. Seuraavassa vaiheessa kootaan tarinoita eli skenaarioita, jotka kuvaavat käyttäjien vallitsevaa tapaa toimia. Ongelmaskenaarioiden pohjalta laaditaan sekä positiivisia että negatiivisia väittämiä, jotka konkretisoivat skenaarioiden kuvaa- 64

13 mia episodeja. Tuloksena ei saada vaatimuksia perinteisesti ymmärretyssä mielessä. Vaiheen tarkoituksena on ennen kaikkea varmistaa, että suunnittelutyön perusta on tarkoituksenmukainen ja että tavoitteet ja konteksti ovat realistisia. (Rosson & Carroll 2002.) Kuva 4.2. Skenaariopohjainen suunnittelumalli. Lähde: Rosson & Carroll Varsinaisen suunnitteluvaiheen (design) yleisenä tavoitteena on kuvata miten vallitsevaa toimintatapaa voidaan tukea tai toimintoja korvata kokonaisuudessaan informaatioteknologian avulla. Vaihe jakautuu toimintojen, informaatiosisältöjen ja vuorovaikutuksen suunnitteluun. Toimintojen suunnitteluvaiheen (activity design) tavoitteena on hahmottaa skenaarioiden avulla järjestelmän keskeiset toiminnot. Informaatiosisältöjen suunnitteluvaiheen (information design) tarkoituksena on selvittää miten informaatiosisällöt järjestetään ja millaisia informaatiosisältöjä esimerkiksi noviisikäyttäjät tarvitsevat toimintojen toteuttamiseksi. Vuorovaikutuksen suunnitteluvaiheessa (interaction design) hyödynnetään käyttötarinoiden kaltaisia skenaarioita määrittelemään miten käyttäjät toimivat vuorovaikutuksessa järjestelmän kanssa. Vaiheen tavoitteena on kuvata miten käyttäjät konkreettisesti toimivat järjestelmän kanssa tietyn tavoitteen saavuttamiseksi. (Ibid.) Rosson ja Carroll (2002) korostavat jatkuvan arvioinnin merkitystä määrittely- ja suunnittelutyön kaikissa vaiheissa. Varsinainen käyttäjätestaus tulisi suorittaa kuitenkin heti toiminnallisen prototyypin valmistuttua. Olennaista skenaariopohjaisessa suunnittelussa on vaatimusten tarkentaminen koko suunnittelu- ja kehitystyön ajan sekä suunnitteluratkaisujen esittäminen heti siinä vaiheessa, kun informaatiota on kerätty riittävästi eri sidosryhmien ja heidän tarpeidensa tunnistamiseksi. Skenaarioita tulisi olla riittävästi. Jokaisen järjestelmän käytön kannalta merkityksellinen tavoite tulee toteutua jonkin skenaarion välityksellä. Kuitenkin laajan järjestelmän ollessa kyseessä voi olla perusteltua keskittyä esim. mahdollisten esteiden analysointiin. Tärkeätä on myös muodostaa ns. positiivisia ja negatiivisia väittämiä keskeisten skenaarioiden pohjalta. On myös 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. (Ibid.) 65

14 Kuva 4.3. Skenaarioita voidaan hyödyntää varsin monella tavalla järjestelmän suunnittelutyön eri vaiheissa. Lähde: Rosson & Carroll, Lisätietoa skenaariopohjaisesta suunnittelusta (mukana myös havainnollistavia esimerkkejä) Rosson, M. B. & Carrol, J. M. Scenario-Based design [online]. Blacksburg VA: Virginia Polytechnic Institute and State University, 2002 [viitattu ]. Saatavissa pdfmuodossa: <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 Lähtökohtana asiakkaan prosessit Perinteisesti tietojärjestelmien suunnittelussa on korostettu yrityksen tarpeiden huomioonottamista. liiketoiminnan prosessien kuvaamiseen ja mallintamiseen on kehitetty lukuisia menetelmiä, joissa käyttäjä nähdään enemmän tai vähemmän prosessia toteuttavana osapuolena. Toisaalta käytettävyyden alalla on korostettu voimakkaasti käyttäjän tarpeiden ymmärtämistä. Wiion (2004, 91) mukaan kumpikin näkemys on oikeutettu, sillä [k]äyttötilanteessa käyttäjän pyrkimykset ja prosessit kohtaavat liiketoiminnan pyrkimykset ja prosessit. Toiminnallisuudeltaan käyttökelpoisen verkkopalvelun suunnittelu vaatii siis 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. Rosson & Carroll 2002; Wiio 2004.) Suunnittelutyön tavoitteena on informaatiosisältöjen sekä toiminta- ja asiointiprosessien jäsentäminen sidosryhmien näkökulmasta. Eri sidosryhmien näkökulmat riippuvat heidän tarpeistaan ja tilanteistaan. Lisäksi tulee kiinnittää huomiota siihen, että informaatio ja erilaiset toimintaprosessit tukevat tarvittaessa toisiaan. (Ibid.) 66

15 Tavoitteena käyttötilanteiden ymmärtäminen Tämä luku pohjautuu pääosin Antti Wiion teoksessaan Käyttäjäystävällisen sovelluksen suunnittelu (2004) esittämiin ajatuksiin. Käyttäjien (ja eri sidosryhmien edustajien) prosessien mallintaminen on varsin toimiva keino käyttötilanteiden ymmärtämiseksi. Apuna mallinnuksessa voidaan hyödyntää toiminta- ja tapahtumatarinoita eli skenaarioita (vrt. Rosson & Carroll 2002). 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. (Esim. Wiio 2004.) Keskeiset vaiheet yksinkertaistettuna 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 Laaditaan kuvaus verkkopalvelun tyypillisistä käyttäjistä sekä heidän tarpeistaan ja erityispiirteistään. Apuna voidaan käyttää käyttäjien profilointia. Kuvausta laajennetaan käsittämään myös potentiaaliset käyttäjät ja heidän tarpeensa. Esimerkiksi millaiset konsertissa kävijät hyötyisivät verkon välityksellä tuotettavista palveluista? 2. Käyttäjien yhteisten pyrkimysten tunnistaminen Millaiset pyrkimykset ovat yhteisiä kaikille käyttäjäryhmille? Selvittäminen mitä konsertteja on tulossa sekä lipun varaaminen/ostaminen konserttiin. Verkkopalvelun pääasiallinen käyttötarkoitus on tukea käyttäjiä tulevien konserttien tietojen tarkastelussa sekä lipun hankkimisessa tiettyyn konserttiin. 3. Prosessin mallintaminen Suunnittelun lähtökohtana tulee olla se prosessi, joka tukee palvelun käyttötarkoitusta eli tässä tapauksessa: tulevien konserttitietojen tarkastelua sekä lipun hankkimista konserttiin. 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. Hyvänä lähtökohtana on mallintaa ensin vallitseva toimintatapa. Miten ihmiset yleensä toimivat selvittäessään tulevia konsertteja sekä hankkiessaan lippuja tiettyyn konserttiin? Lippujen hankkimisprosessi tiettyyn konserttiin voisi edetä karkealla tasolla esimerkiksi seuraavasti: 67

16 Tarjontaan tutustuminen. Kiinnostavien vaihtoehtojen rajaaminen. Sopivan ajankohdan valitseminen. Paikan valinta. Lipun maksaminen. Konserttiin meno tiettynä ajankohtana. 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 on myös muistettava, että 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 Tampere talo Tampere talon etusivulla navigointi on jaoteltu päätasolla seuraavasti: ohjelmisto & liput, kokoukset, konsertit, talo & tekniikka, ravintolapalvelut, yritys. Toimiiko etusivun pääjako kiinnostavan vaihtoehdon rajaamisen näkökulmasta? Periaatteessa tässä vaiheessa käyttäjän joutuu hetken miettimään valitseeko linkin ohjelmisto & liput vai linkin konsertit. Kuva 4.4. Tampere -talo [ ].. Tarkastellaan miten verkkopalvelu tukee käyttäjää "kiinnostavien vaihtoehtojen rajaamisen" prosessissa. Esimerkissä käyttäjä voi tarkastella tulevia konsertteja tapahtumakalenterista kronologisessa järjestyksessä. Lisäksi käyttäjä voi valita tietyn linkistä tietyn kuukauden ja siirtyä tarkastelemaan tiettyyn ajankohtaan ajoittuvia konsertteja. 68

17 Kuva 4.5. Tampere -talo [ ]. Tarjoavatko valitut toiminnot ja informaatiosisällöt mielestäsi riittävästi tukea kiinnostavan konsertin valitsemiseksi? Voidaanko prosessia mahdollisesti tehostaa jollakin tavalla? Tapahtuman tyyppi lienee yksi keskeinen tekijä. Käyttäjälle voisi kenties tarjota mahdollisuuden hakea tai järjestää tapahtumia koskevia tietoja esim. sen mukaan onko kysymyksessä viihdekonsertti, klassisen musiikin konsertti, lasten konsertti vai jokin muu tapahtuma esim. näyttely tai messut. 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ä. Onko Tampere talon kantaasiakkailla kenties jotakin erityistarpeita verrattuna muihin käyttäjiin? 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ä ongelmallisissa kohdissa. Esimerkiksi Tampere talo tarjoaa mahdollisuuden varata väliaikatarjoilun etukäteen joko puhelimitse tai s-postin välityksellä. Lisäksi verkkopalvelu tukee myös fyysisen tason prosesseja esittämällä tietoja kulkuyhteyksistä autolla, junalla, linja-autolla ja lentäen vieraspaikkakuntalaisille. 69

18 Informaation jalostaminen edelleen Prosessien mallintamisen tulokset voidaan kuvata esimerkiksi käyttötapausten (use case) avulla. Yksittäinen käyttötapaus (use case) kuvaa käyttäjän ja järjestelmän välisen vuorovaikutuksen jonkin tavoitteen saavuttamiseksi käyttäjän näkökulmasta. (Katso oppimateriaalin luku Toiminnallisuuden kuvaaminen s. 45.) Eräiden suunnittelijoiden mukaan sekä skenaarioihin että käyttötapauksiin liittyy tiettyjä rajoituksia. Skenaariot kuvaamien konkreettisten episodien pohjalta on haastavaa muodostaa riittävän yleispäteviä määrityksiä toiminnoista ja tapahtumista. Perinteiset käyttötapaukset taas pitävät sisällään jo lähtökohtaisena oletuksen käyttöliittymästä ja vuorovaikutuksesta järjestelmän kanssa. (Preece, Rogers & Sharp 2002, ) Eräänä ratkaisuna on esitetty olennaisten käyttötapausten (essential use case) hyödyntämistä. Olennaiset käyttötapaukset kuvaavat toiminnot abstraktimmalla tasolla kuin skenaariot, mutta pyrkivät välttämään perinteisiin käyttötapauksiin sisältyviä olettamuksia. Olennainen käyttötapaus muodostuu ensinnäkin nimestä, joka ilmaisee yleisellä tasolla käyttäjän tavoitteen (esim. tietyn prosessin tietyn vaiheen). Toiseksi se sisältää vaiheittaisen kuvauksen käyttäjän toiminnoista sekä vastaavasti vaiheittaisen kuvauksen järjestelmän antamista palautteista. Esimerkki olennaisesta käyttötapauksesta (Preece, Rogers & Sharp 2002, 231). Käyttäjä: kirjaston asiakas Toiminta: kirjaan lainaaminen Tapahtuma: kirjan paikantaminen. Tapahtuma: Kirjan paikantaminen Käyttäjän toiminto käyttäjän tunnistautuminen kirjaa koskevien tietojen antaminen hakutulosten huomioinen poistuminen järjestelmästä Järjestelmän palaute käyttäjän tunnistaminen tunnistetietojen vaatiminen hakutulosten esittäminen järjestelmän sulkeutuminen Tekniikkana voidaan hyödyntää myös hierarkkista tehtäväanalyysia (Hierarchial Task Analysis HTA). Tavoitteena on kuvata käyttäjän tavoite ja siihen liittyvät tehtävät ja toiminnot. Perusperiaatteena on jakaa käyttäjän tavoitteen kannalta olennainen prosessi tehtäviin (tasks) ja edelleen alatehtäviin (subtasks) jne. Tämän jälkeen määritellään missä järjestyksessä tehtävät toteutetaan käytännössä. Tehtäväanalyysin tulokset voidaan kuvata sekä tekstimuodossa että graafisena esityksenä. (Esim. Preece, Rogers & Sharp 2002, ) 70

19 Esimerkki hierarkkisesta tehtäväanalyysista (Preece, Rogers & Sharp 2002, 232). 0. Lainaa kirjan kirjastosta 1. Mene kirjastoon 2. Selvitä haluamasi kirjan sijaintitieto 2.1. Mene työasemalle, missä voi käyttää kirjaston tietokantaa 2.2. Avaa hakutoiminto 2.3. Syötä hakutiedot 2.4. Poimi haluamasi kirja hakutuloksista 2.5. Huomioi kirjan sijaintitiedot 3. Mene oikean hyllyn luo ja nouda kirja 4. Mene lainauspisteeseen ja lainaa kirja Tavoite 0. Suorita Jos kirja ei sijainnutkaan oletetusta hyllyssä, suorita Tavoite 2. Suorita Jos kirja ei ole tiedossa, suorita Lainaa kirja kirjastosta Tavoite 0. Suorita Jos kirja ei sijainnutkaan oletetusta hyllyssä, suorita Mene kirjastoon 2. Selvitä kirjan sijainti 3. Mene hyllyn luo ja nouda kirja 4. Mene lainauspisteeseen ja lainaa kirja Tavoite 2. Suorita Jos kirja ei ole tiedossa, suorita Mene työasemalle (tietokanta) 2.2. Avaa hakutoiminto 2.3. Syötä hakutiedot 2.4.Poimi kirja hakutuloksista 2,5,. Huomioi sijainti Case: Tre@Validian toimintaprosessien suunnittelu Hypermedialaboratorion suunnitteleman Tre@validia 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. 71

20 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 oli 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ä. 72