3. luento: Verkkopalvelun suunnittelusta

3. luento: Verkkopalvelun suunnittelusta Mihin suunnittelumalleja tarvitaan? Ad hoc -menetelmä Menetelmä on tyypillinen etenkin pienissä verkkopalveluprojekteissa - toteuttava ryhmä on pieni ja tiivis sekä toteutettava verkkopalvelu on suhteellisen kevyt. Toteutus lähtee liikkeelle lähinnä kokeiluna, joka sitten viimeistellään ja hyväksytään lopulliseksi ratkaisuksi. Nopeaa ja helppoa! Mutta entä jatkokehitys? Ad hoc- menetelmän tuloksena usein dokumentoimaton toteutus, jonka logiikkaa ei kukaan ulkopuolinen ymmärrä. Tekninen toteutus usein laadultaan heikompaa. Lisää ongelmia: - Miten hallita monimutkaisia verkkototeutusten kompleksisuutta? - Miten hallita tuotantoprosessia, kun välitavoitteiden asettaminen on hankalaa? - Miten arvioida kustannuksia ja työmäärää? - Miten selvittää mitä käyttäjät ja/tai tilaajat itse asiassa haluavat? Etenkään kun tilaajakaan ei aina tiedä mitä haluaa. - Mitä tehdä kun vaatimukset muuttuvat jopa projektin aikana? Suunnittelumallin tarkoitus Verkkopalvelun suunnitteluprosessi koostuu erilaisista osa-alueista. Suunnittelumallin tarkoitus on auttaa käyttäjää hahmottamaan ja jäsentämään monimutkaista ilmiötä. Malli muodostaa yksinkertaistetun kuvan todellisuudesta ja auttaa käyttäjäänsä visualisoimaan suunnitteluprosessin kokonaisuutena. Malli auttaa myös jakamaan suunnitteluprosessin helpommin hallittaviin kokonaisuuksiin. Suunnittelumalli pyrkii havainnollistamaan suunnittelu- ja toteutusprosessin eri vaiheita ja niiden suhteita toisiinsa. Mallit toimivat siten myös projektinhallinnan apuvälineenä. (Esim. Ryder 2005.) Suunnittelumalleja on lukuisia. Suunnittelumallit voidaan jakaa karkealla tasolla kahteen eri ryhmään: 1. Perinteisemmät suunnittelumallit, jotka koostuvat erilaisista vaiheista (steps). Yleisimmin mainittuja vaiheita ovat: vaatimusmäärittely, suunnittelu, toteutus, arviointi, jakelu ja käyttö sekä ylläpito (esim. Balci ym. 2001a). 2. Toisen ryhmän muodostavat suunnittelumallit koostuvat erilaisista tekijöistä (points), joihin suunnittelutyön aikana tulee kiinnittää huomiota. Nämä mallit korostavat suunnittelun kehämäisyyttä, jolloin yksittäiseen tekijään tulee kiinnittää huomiota useassa eri vaiheessa. Suunnittelumallin hyödyllisyys on kiinteästi yhteydessä sen käyttökontekstiin. Arvioitaessa suunnittelumallin hyödyllisyyttä kiinnitetään huomiota siihen, miten hyvin se tukee käyttäjänsä suunnittelutavoitteiden saavuttamisessa ja suunnittelutyön kuormittavuuden jakamisessa sekä huomion kiinnittämisessä olennaisiin tekijöihin. (Ryder 2005.) Vaikka monet perinteiset suunnittelumallit voidaan nähdä osin jo vanhentuneina, ovat ne kuitenkin edelleen hyödyllisiä mm. menetelmien valinnassa, olioiden tarkassa kuvauksessa ja suunnittelutyön täsmällisessä arvioinnissa. 1

Erilaisia suunnittelu- ja tuotantoprosessia ohjaavia malleja Verkkopalvelujen suunnittelussa hyödynnetään eri alojen lähestymistapoja ja suunnittelumalleja. Esimerkiksi ohjelmistotuotanto, ihminen-tietokone vuorovaikutus, projektinhallinta, käytettävyystutkimus, simulaatiot (Lee ym. 2003, 1). Lisäksi suunnittelumalleja on myös joihinkin erikoistarpeisiin kuten opetuskäyttöön suunnatun verkkototeutuksen suunnittelumallit (instructional l. educational design models). Ohjelmistotuotannon malleja Vesiputousmalli (the Waterfall Model) Perusajatuksena on, että sovellus suunnitellaan vaiheittain (lineaarinen malli). Suunnittelutyön vaiheet vaihtelevat hieman lähteistä riippuen. Olennaista on se, että vaiheet seuraavat toisiaan ennalta määritellyssä järjestyksessä. Jokainen vaihe päättyy arviointiin (tarkastukset ja kastelmukset). Jo suoritettuun vaiheeseen ei palata. 1. vaatimus määrittely (requirement analysis,, system engineering, analysis) : järjestelmän tehtävät, päätoiminnot, ulkoiset vaatimukset ja rajoitukset, liittymät jne.) 2. suunnittelu (design): tekninen rakenne, pääkomponentit, tietorakenteet, käyttöliittymä yms. 3. toteutus (implementation): suunnitelman realisointi toimivaksi ohjelmaksi 4. testaus (testing): toimivuuden ja vaatimusten täyttyminen, virheiden korjaus 5. käyttöönotto : käyttäjien koulutus, asennukset 6. ylläpito (maintenance): tarvittavat korjaukset ja päivitykset Kuva 1. Vesiputousmalli Hyviä puolia: Malli on perinteinen ja tuttu. Se on helppo omaksua sekä selkeä ja yksinkertainen käyttää. Pitää sisällään periaatteessa kaikki tarvittavat vaiheet. Soveltuu sellaiseen projektiin jonka tavoitteet ovat selkeät ja yksiselitteiset ja jonka toteuttaa pieni, tehokas ja yhteen hitsautunut työtyhmä. Tuloksena tällöin helposti johdettava ja ennakoitava projekti. 2

Ongelmia: Todellisen elämän projekti on harvoin lineaarinen. Ohjaa käsittelemään liian suuria kokonaisuuksia kerralla. Aiheesta toiseen eteneminen on sidottu tarkastuksiin ja hyväksymisiin > jäykkä menetelmä. Toimiva järjestelmä saadaan asiakkaan käyttöön myöhäisessä vaiheessa. Vasta tuolloin nähdään konkreettisesti miltä toteutus näyttää ja miten se toimii loppukäyttäjän näkökulmasta tarkasteltuna. Vasta loppuvaiheessa esiin nousseet muutostarpeet saattavat tulla todella kalliiksi. (Esim. Preece ym. 1994, 355 357.) Spiraalimalli (the Spiral Model) Mallista on kehitetty lukuisa eri versioita. Malli yhdistää iteratiivisen vaatimusmäärittelyn sekä lineaaristen mallien systemaattisen lähestymistavan. Malli pitää sisällään samoja vaiheita kuin esim. vesiputousmalli. Mutta mallin mukaan ratkaisuun ja valmiiseen tuotteeseen edetään iteroiden, useiden toistuvien syklien avulla. Malli korostaa riskien hallintaa. 1. Tavoitteiden ja rajoitteiden määrittely 2. Vaihtoehtojen arviointi sekä riskien tunnistaminen ja ratkaiseminen. 3. Kehittäminen ja seuraavan tason tuotteen määrittely 4. Seuraavien vaiheiden suunnittelu ja resurssien arviointi Kuva 2. Spiraalimallin vaiheet yksinkertaistettuna Hyviä puolia: Soveltuu erityisesti sellaisen verkkopalveluprojektin suunniteluun, missä perusratkaisu ei ole täysin kirkastunut: mitä oikeastaan on tarkoitus tehdä. Prosessi etenee ongelman esittämisen ja ratkaisun sykleinä hioutuen valmiiksi ratkaisuehdotuksiksi, joita voidaan analysoida tarkemmin. Riskein määrä vähenee kierros kierrokselta. Tukee asiakkaan sitoutumista. Ongelmia: Suhteellisen vaikeasti hallittavissa, koska eri vaiheista on vaikea sanoa missä ne alkavat ja mihin ne päättyvät. Ei sovellu aloitteleville suunnittelijoille. Asiakkaan jatkuva aktivointi voi olla ongelmana. Suhteellisen hidas eteneminen. (Vrt. Boehm 1988; Preece ym. 1994, 355 357.) 3

Muita malleja esimerkiksi Prototyypimallit esim. Rapid Prototyping Design Model Evoluutiomallit esim. Evolutional Design RAD-mallit esim. Rapid Application Development HCI - suunnittelumalleja Usability Engineering Life Cycle Model Suunnitteluprosessi muodostuu kolmesta päävaiheesta, jotka jakautuvat edelleen alavaiheisiin. Olennaista on prototyyppien ja käyttäjätestausten hyödyntäminen suunnittelutyön tukena sekä suunnittelutyön iteratiivisuus. 1. Esisuunnittelu (pre-design phase) Käyttäjän tunteminen (know the user); mitä käyttäjät oikeasti tekevät Kilpailijoiden analysointi (competitive studies): perehtyminen jo olemassa oleviin tuotteisiin sekä niiden heikkouksien ja vahvuuksien arvioiminen. Käytettävyystavoitteiden asettaminen (setting usability goals): minimitavoitteet käytettävyydelle ja niiden merkityksen arvioiminen käyttäjän näkökulmasta 2. Suunnitteluvaihe (design phase) Samanaikainen suunnittelu (parallel design): ongelmien ratkaisemisessa hyödynnetään erilaisia lähestymistapoja esim. pienimuotoisia käyttäjätestauksia, prototyyppejä sekä menetelmiä. Osallistuva suunnittelu (participatory design): Käyttäjien mukaan ottaminen suunnitteluprosessiin Käyttöliittymän kokonaissuunnittelu (coordinated design of the total interface): johdonmukaisuus käyttöliittymäsuunnittelussa - asettelu, opastus, dokumentointi Heuristinen arviointi ja analysointi (apply guidelines and heuristic analysis): käyttöliittymän toteutuksen ohjeistus Prototyyppien käyttö (prototyping): karkean tason prototyyppien hyödyntämien jo varhaisessa vaiheessa palautteen saamiseksi käyttäjältä Käytettävyystestaukset (empirical testing): käytettävyyden testaukset todellisilla käyttäjillä Iteratiivinen suunnittelu (iterative design): toteutuksen jatkuva kehittäminen arviointien ja palautteiden perusteella. Lähtökohtana käyttäjien tarpeet ja kokemukset! 3. "Jälkisuunnittelu" (postdesign phase): Palautteen kerääminen(collect feedback from field use). Hyviä puolia: Vähentää käytettävyysongelmien esiintymistä lopputuotteessa. Käyttäjien kouluttamiseen ei kulu resursseja. Auttaa sitouttamaan asiakasta. Ongelmia: Asiakkaan jatkuva aktivoiminen voi olla haasteellista. Vaatii osaamista toteutusryhmältä. (Vrt. Nielsen 1993; Nielsen 2001.) 4

Star Model Hartson & Hixin (1989) esittämän mallin mukaan suunnittelutyön osa-alueiden järjestys on epäolennaista. Suunnittelutyö voi alkaa periaatteessa mistä tahansa vaiheesta ja edetä arviointivaiheen kautta mihin vaiheeseen hyvänsä. Arvioinnilla on keskeinen merkitys suunnittelutyössä. Kaikki vaiheet arvioidaan käyttäjien ja asiantuntijoiden toimesta. Korostaa myös prototyyppien käyttöä sekä inkrementaalista kehitystyötä. Implementation Task analysis/ functional analysis Prototyping Evaluation Requirement specification Conseptual design/ formal design Kuvio 3. Hartsonin ja Hixin Star - malli (ref. Preece ym. 1994, 381). Hyviä puolia: Korostaa käyttäjäkeskeisyyttä ja realistisuutta. Keskittyy selvittämään mitä järjestelmältä vaaditaan, mitä tietoa tarvitaan, mitä käyttäjien tulee tietää sekä miten asetetut tavoitteet saavutetaan. Saadaan nopeasti palautetta käyttäjiltä. (Preece ym. 1994, 380-381.) Ongelmia: Projektin ja toteutuksen eri versioiden hallinta vaikeutuu. Samaten dokumentaation. Mallia on kritisoitu siitä, että se ainoastaan esittää vesiputousmallin vaiheet lisäten niihin arvioinnin. Mutta ei aidosti tue ihminen - tietokone vuorovaikutuksen suunnittelua. (Gellner & Forbrig 2003.) Muita malleja esimerkiksi o ISO 13407: Human centred design processes for interactive systems http://www.usabilitynet.org/tools/13407stds.htm 5

Hypermedian suunnittelumalleja The Object-Oriented Hypermedia Design Model (OOHDM) Hypermediasovellus koostuu usein monimutkaisesti järjestettyjen informaatioaihioiden sekä näitä aihioita yhdistävän liikkumisjärjestelmän kokonaisuudesta. Suunnittelumalli tarjoaa viitekehyksen, joka tukee informaatioaihioiden kuvauksessa sekä liikkumisjärjestelmän ja käyttöliittymän suunnittelussa. Nelivaiheinen malli tukee prototyyppien käyttöä tai inkrementaalisen suunnittelu prosessimallien käyttöä. Luokittelu, yhdistely ja yleistäminen/täsmentäminen liittyvät kaikkiin vaiheisiin. 1. Vaatimusmäärittely (requirements gathering): Kohderyhmän tunnistaminen ja kohderyhmän vaatimusten ja toimintojen määrittely hyödyntäen esim. käyttötapauksia (use cases). Arviointi. 2. Käsitteellinen mallintaminen (conceptual design): hyödynnetään olioperustaisen suunnittelumenetelmien lähestymistapaa. Olio edustaa jotakin, joka on merkitsevä ko. ongelma-alueella (henkilö, henkilörekisteri, henkilötieto) ja joka on ainutlaatuinen eroten muista oliosta. Oliot muodostavat käsitteellisiä luokkia, jotka ovat jossakin suhteessa toisiinsa (yleensä hierarkkisessa). 3. Liikkumisjärjestelmän suunnittelu (navigational design): yhdistää oliot ja luokat tarkoituksenmukaisella tavalla vaatimusmärittelyihin nähden. 4. Käyttöliittymän suunnittelu (abstract interface design): määritellään käyttöliittymän visuaaliset objektit esim. tekstielementit ja navigointipainikkeet/linkit. 5. Toteuttaminen (implementation): toteutus ja käyttöönotto. (Esim. Schwabe 2003.) Hyviä puolia: Tukee informaatioaihioiden uudelleen käyttöä ja informaatioarkkitehtuurin suunnittelua. Ongelmia: Edellyttää perehtymistä käsitteelliseen mallintamiseen sekä oliopohjaiseen suunnittelumenetelmään. Merkittävien olioiden (informaatioaihioiden) tunnistaminen saattaa olla haasteellista. Scenario-Based Design Korostaa muiden HCI -suunnittelumallien tapaan käyttäjien tarpeiden ja vaatimusten määrittelyä. Miten käyttäjien tulee toimia saavuttaakseen tavoitteensa. Poikkeaa kuitenkin formaaleista ja tarkkaan määritellyistä analyysimenetelmistä. Kyseessä on kevyt menetelmä, joka auttaa kartoittamaan mahdollisia käyttötapoja. Skenaariot ovat pieniä, rajattuja kertomuksia, jotka kuvaavat yhden mahdollisen tapahtumapolun. Skenaariot soveltuvat varsin hyvin tiedon kokoamiseen käyttäjiltä heidän tehtävistään ja käyttötilanteesta helpottaen siten vaatimusanalyysin kiinnittämistä todelliseen ympäristöön. (Carroll ym. 1998; Potts 1995: Rosson & Carroll 2002.) 1. Vaatimusten analysointi (analyze): edunsaajien (kohderyhmän) määrittely, toiminnallisten ja laadullisten vaatimusten määrittely hyödyntäen skenaarioita (problem scenarios) 2. Suunnittelu (design): Toimintojen määrittely (activity design): vallitsevien toimintojen ja uusien tarkoituksenmukaisten toimintojen määrittely hyödyntäen skenaarioita (activity scenarios) 6

Informaatiosisällön suunnittelu (information design): tehtävien suorittamisen ja tavoitteiden saavuttamisen kannalta olennaisen informaation sisällön ja aihioiden määrittely hyödyntäen skenaarioita (information scenarios) 1. Prototyypit ja arviointi (prototype and evaluate): Käytettävyyden arviointi (usability evaluation): skenaarioiden hyödyntäminen käytettävyys tavoitteiden määrittelyssä. Hyviä puolia: Nopea ottaa käyttöön, helppo tehdä uudestaan tarvittaessa. Voidaan suhteellisen helposti ottaa mukaan laajempikin käyttäjäjoukko. Ideat saadaan nopeasti testattua. Skenaariot ovat konkreettisia > helppo analysoida ja tulkita. Saadaan helposti reaalimaailman tapaukset arvioitaviksi. Ongelmia: tarvitaan ainakin jonkinasteista perehtymistä ihmisen kognitiivisten prosessien ominaispiirteisiin, sosiaaliseen käyttäytymiseen. Käyttöönoton helppoudessa piilee vaaransa. Muita malleja esimerkiksi: Hypermedia Design Model RMM- relationship management methodology Hypermedian perusteet kurssi. http://matwww.ee.tut.fi/hmopetus/hypmed04/ VINKKI: Suunnittelumallien eri vaiheiden tai osa-alueiden yhteydessä soveltuvien menetelmien valinnassa auttaa esim. UsabilityNet:in menetelmätaulukko. Methods table [online]. UsabilityNet, 2003 [viitattu 24.1.2005]. Saatavissa www-muodossa: <URL: http://www.usabilitynet.org/tools/methods.htm > Mitä verkkopalvelun suunnittelu on? Verkkopalveluiden suunnittelu on monivaiheinen ja monipuolinen prosessi, johon tulee panostaa aikaa ja asiantuntemusta. Huonoja suunnitelmia on myöhemmin vaikea korvata edes tuotantovaiheen asiantuntemuksella. Suunnitteluvaiheeseen kannattaa budjetoida riittävästi, sillä esimerkiksi alle kuukauden suunnittelulla ei saa kuin korkeintaan suppean verkkopalvelun suunnittelutyön tehdyksi. Suurempien verkkopalveluiden suunnittelutyöhän on varattava 2-8 kuukauden työpanos. (Jussila & Leino 1999, 121-122.) Verkkopalvelun suunnittelutyössä on kaksi puolta: - projektin suunnittelu, budjetointi, aikataulutus ja työjako sekä - varsinaisen tuotteen/palvelun ja sen sisällön yksityiskohtainen suunnittelu ja määrittely (Kauhanen-Simanainen 2001, 78-79). A) Projektin suunnittelu Hankkeen projektipäällikön tehtävä on koota ja hallita projektisuunnitelma, budjetti, aikataulu ja työnjako sekä hankkia oikeat ihmiset oikeisiin työtehtäviin. Projektipäällikkö pitää myös yheyttä eri tahojen kesken jo heti suunnitteluvaiheessa. Kyseessä on itse asiassa projektin hallinnan tehtävistä. (Kauhanen-Simanainen 2001, 78-79.) 7

B) Tuotteen/palvelun suunnittelu Varsinaisen tuotteen/palvelun suunnittelutyössä ratkaisun keksimisen lisäksi kuvataan ja dokumentoidaan ratkaisu. Verkkopalvelun kuvaamisen tulee olla niin yksityiskohtaista, että periaatteessa kuka tahansa toteutustekniikat hallitseva kykenisi tehtyjen suunnitelmien ja dokumenttien perusteella toteuttamaan palvelun. Yksityiskohtaisia suunnitelmia tarvitaan myös siksi, että suunnittelijat ja toteuttajat eivät yleensä ole jatkuvasti tekemisissä keskenään. Jos suunnitelma ei ole selvä, sitä joudutaan toistuvasti tarkentamaan ja täydentämään toteutuksen kuluessa. (vrt. Jussila & Leino 1999, 116.) Suunnittelutyön tueksi tarvitaan perusinformaatiota: - palveluntarjoajasta ja sen (liike)toiminnasta, - palvelun kohderyhmän toiminnasta ja tarpeista sekä - Internetistä ja verkkopalveluista (vrt. Jussila & Leino 1999, 117.) Suunnittelussa tarvitaan usein asiantuntemusta sisällön asiantuntijoiden lisäksi myös markkinoinnista, asiakaspalvelusta ja viestinnästä sekä erityisesti verkkopalveluista. Suunnittelussa pitää olla mukana myös toteutustekniikan asiantuntijoita. Tuotteen/palvelun suunnittelun työvaiheet Spiraalimaisen ja asteittaisen suunnittelun etenemiseen kuuluu seuraavia työvaiheita, jotka etenevät osin päällekkäin toinen toistaan täydentäen. 1. Konseptin suunnittelu (synopsis jatkokehitettynä) Verkkopalvelun käytöllä on jokin tarkoitus (purpose). Asiakas käyttää verkkopalvelua jonkin tavoitteen (goal) saavuttamiseksi. Hän haluaa kuluttaa, viihtyä, etsiä informaatiota, opiskella jne. Tavoitteen saavuttaminen edellyttää sitä, että asiakas on vuorovaikutuksessa verkkosovelluksen kanssa ja että vuorovaikutustapahtumien sarjat muodostavat tavoitteen saavuttamisen kannalta järkeviä tapahtumasarjoja. Esimerkiksi tukevat verkkopalvelun asiointiprosesseja. (vrt. Elin 2001, 22-25) Konseptisuunnitteluvaiheessa määritellään perusteet toteutettavalle palvelulle. Siinä kuvataan palvelun idea, sisältö ja toiminta. Erityisesti tässä suunnitteluvaiheessa korostuu palveluprosessin suunnittelu. Palveluprosessin suunnittelussa tulee huomioidaan verkossa tapahtuvan palveluprosessin etenemisen lisäksi myös se, millä tavalla palveluprosessi etenee verkon ulkopuolella. Esimerkki: Postin verkkopalvelu. 8

Konseptisuunnitelmassa määritellään myös palvelun rakenne (rakennekaavio) ja kuvataan informaatioarkkitehtuuri karkeasti. (vrt. Jussila & Leino 1999, 119.) Informaatioarkkitehtuurilla tarkoitetaan tietosisältöjen rakenteellista kokonaisuutta, joka jäsentää sisällöt, niiden elementit ja keskinäiset suhteet. Informaatioarkkitehtuuri jäsentää myös haku- ja muut käyttömahdollisuudet (esim. monikanavajulkaiseminen ja erilaiset päätelaitteet). Informaatioarkkitehtuuri on toimiessaan näkymätön, mutta toisaalta se konkretisoituu käyttöliittymien antamina näkyminä sisältöihin ja toimintoihin. (vrt. Kauhanen-Simanainen 2003.) 2. Sisällön suunnittelu Jokaisella verkkopalvelulla on jokin teema tai aihe (subject). Verkkopalvelun sisältö käsittelee siis jotakin aihetta kuten autoja, puutarhan hoitoa, urheilua jne. Verkkopalvelu voi koostua useistakin aiheita, mutta viime kädessä niillä on kuitenkin jokin yhteinen nimittäjä esim. uutiset. Sisällöllä on aina olemassa jäsennys ja esitystapa, jotka riippuvat mm. verkkopalvelun käyttötarkoituksesta, kohderyhmästä sekä genrestä. (vrt. Elin 2001, 22 25.) Sisällön suunnitteluvaiheessa määritellään ja rajataan palveluun tuleva sisältö sekä sen muotokieli. Sisällönsuunnitteluvaiheessa syvennetään informaatioarkkitehtuurin suunnittelu koskemaan yksittäisiä sisällön osa-alueita. Usein konseptin ja sisällönsuunnitteluvaiheet tapahtuvat samanaikaisesti. 9

3. Mediasuunnittelu Verkkopalveluihin voidaan liittää erilaisia mediaelementtejä tai palvelua voidaan käyttää erilaisin päätelaittein. Mediasuunnitteluvaiheessa valitaan ne mediaelementit (ääni, kuva, teksti, animaatio), jotka ovat tarkoituksenmukaisia sisällön esittämisen kannalta. Mediasuunnittelu ottaa myös kantaa monikanavajulkaisemisen (eri mediat, eri päätelaitteet) vaatimuksiin. Tässä vaiheessa tarkennetaan edelleen informaatioarkkitehtuuria näiltä osin. 4. Tekninen ja toiminnallinen suunnittelu Tekninen ja toiminnallinen suunnitteluvaihe pitää sisällään yksityiskohtaisen määrittelyn teknisistä ratkaisuista, kuten toiminnallinen määrittely, arkkitehtuurisuunnittelu, tekninen määrittely, moduulisuunnittelu, toteutussuunnittelu (IEEE 1016). Verkkopalvelun tekninen suunnittelija määrittelee mitä laitteita tai ohjelmistoja verkkopalvelun toteutuksessa ja käytössä tarvitaan. Toiminnallisuus (=vuorovaikutteisuus), kuten palautelomakkeet, rekisteröitymislomakkeet yms. ovat oleellisia tyypillisiä vuorovaikutteisuuden osia verkkopalveluissa. Aina, kun www-sivuilla on toiminnallisuutta eli mahdollisuus tehdä muutakin, kuin passiivisesti lukea ja katsella sivuja, tarvitaan ohjelmointia tai valmiita ohjelmistoja ja taustaohjelmistoja. Verkkopalvelun toteuttavien tulee hallita ohjelmointi ja pystyä tuottamaan halutut toiminnalliset elementit. Verkkopalvelu voidaan kytkeä myös muihin tietojärjestelmiin, esimerkiksi ostotilaukset voidaan kytkeä yrityksen varastokirjanpidon tietojärjestelmään, jolloin toimituskehotus voidaan toimittaa automaattisesti varastoon. Tekninen suunnittelu vastaa myös tietojen siirron ja tallennuksen suunnittelusta. 6. Käyttöliittymän suunnittelu Verkkopalvelun käyttöliittymän tarkoituksena on tukea asiakasta saavuttamaan verkkopalvelun käytölle asetetut tavoitteet. Verkkopalvelun käyttöliittymän suunnitteluun sisältyy sivuston rakenteen, visuaalisen (graafisen) ulkoasun, navigoinnin ym. toimintojen sekä näyttöjen tietosisältöjen suunnittelu. (vrt. Elin 2001, 22-25) Käyttöliittymäsuunnittelun lopputuloksena syntyy käyttöliittymän määrittely, joka ottaa kantaa siihen, mitkä järjestelmän toiminnot näkyvät ja miten. Käyttöliittymän suunnittelu pohjaa pitkälle toiminnallisuuden ja informaatioarkkitehtuurin suunnitelmiin. Tarkoituksena on, että käyttöliittymä tukee käyttäjien toimintalogiikkaa sekä käyttäjien tarvetta löytää tarvitsemansa tietosisältö. Käyttöliittymäsuunnitelma koostuu tyypillisesti kuvien sarjoista, joissa järjestelmän toimintalogiikkaa havainnollistetaan näyttämällä vaihe vaiheelta toimenpiteet, joiden avulla käyttäjä etenee käyttötilanteessa kohti tavoitettaan. Graafisessa suunnittelussa verkkopalvelulle määritellään ulkoasu. Graafisessa suunnittelussa lähtökohtana on palvelun kohderyhmä. Valittua visuaalista linjaa, yleisilmettä tulee noudattaa johdonmukaisesti jokaisella sivulla. Graafisen suunnittelun tekijän tulee tuntea ennenkaikkea internetin toimintaperiaatteet ja hallita www-taiton erityishaasteet. Erittäin suositeltavaa on erotella sisältö ja graafinen ulkoasu css-tyyleillä lue lisää: http://www.w3schools.com/css/css_intro.asp tai http://www.w3.org/style/css. 10

Lähteet: Balci, O. ym. Animations to Assist Learning Some Key Computer Science Topics [online]. Blacksburg (VA.): Virginia Polytechnic Institute and State University. Department of Computer Science, 2001a, [viitattu 23.1.2005]. Software Engineering. The Waterfall Model. Saatavissa wwwmuodossa: <URL: http://courses.cs.vt.edu/~csonline/se/lessons/waterfall/index.html >. Balci, O. ym. Animations to Assist Learning Some Key Computer Science Topics [online]. Blacksburg (VA.): Virginia Polytechnic Institute and State University. Department of Computer Science, 2001b, [viitattu 23.1.2005]. Software Engineering. The Spiral Model. Saatavissa www-muodossa: <URL: http://courses.cs.vt.edu/~csonline/se/lessons/spiral/index.html >. Boehm, B. 1988. The spiral model of software development and enhancement. IEEE Computer, 21 (5), 61-72. Carrol, J. M. ym. 1998. Requirements Development in Scenario-Based Design. IEEE Transactions on Software Engineering, Vol. 24 Issue 12, 1156 1170. Elin, L. 2001. Designing and developing multimedia. A practical guide for the producer, director and writer. Needham Heights (MA.): Allyn & Bacon. Gellner, M. & Forbig, P. Extreme Evaluations Lightweight Evaluations for Soft- ware Developers [online]. Rostock: University of Rostock, 2003 [viitattu 24.1.2005]. Interact 2003 - Closing the Gaps: Software Engineering and Human-Computer Interaction in Zürich, Switzerland in 1-2 September 2003. Saatavissa pdf-muodossa <URL: http://www.se-hci.org/bridging/interact/gellner.pdf >. IEEE 1016, Recommended Practice fo Software Design Descriptions. ANSI/IEEE std 1016 1987. ISO 13407 Human centred design processes for interactive systems [online]. UsabilityNet, 2003 [viitattu 24.1.2005]. Saatavissa www-muodossa: <URL: http://www.usabilitynet.org/tools/13407stds.htm > Jussila, M. & Leino, A. 1999. Net. Verkkoviestinnän käsikirja. Hämeenlinna: Karisto Oy. Kauhanen-Simanainen, A. 2001. Sisältöä verkkoon mitä sisällön tuottajan pitää hallita. Vammala: Vammalan kirjapaino Oy. Kauhanen-Simanainen, A. 2003. Informaatioarkkitehtuuri. Helsinki:Edita Prima Oy Nielsen, J. 1993. Usability Engineering. San Diego (CA.): Morgan Kaufmann. Nielsen, J. The usability lifecycle [online]. New York: IBM, 2001. Julkaistu 1.5.2001 [viitattu 24.1.2004]. DeveloperWorks: Sample IT projects. Saaatavissa www-muodossa: <URL: http://www-106.ibm.com/developerworks/library/it-nielsen3/ >. Potts, C. 1995. Using Schematic Scenarios to Understand User Needs. Proceedings of the conference on Designing Interactive Systems: processes, practices, methods & techniques: Ann Arbor, USA, elokuu 1995, 247 256. 11

Preece, J. & al. 1994. Human-Computer Interaction. Essex: Addisson-Wesley. Rosson, M. B. & Carrol, J. M. Scenario-Based design [online]. Blacksburg VA: Virginia Polytechnic Institute and State University, 2002 [viitattu 24.1.2005]. Saatavissa pdf-muodossa: <URL: http://www.lucas.lth.se/sepm/session1/sbd-handbook.pdf >. Myös teoksessa: J. Jacko & A. Sears (Eds.). 2002. The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Mahwah (NJ.):Lawrence Erlbaum Associates, 2002, pp. 1032-1050. Ryder, M. Instructional Design Models [online]. Denver: University of Colorado at Denver. School of Education [päivitetty] 13.1.2005 [viitattu 23.1.2005]. Saatavissa www-muodossa: <URL: http://carbon.cudenver.edu/~mryder/itc_data/idmodels.html >. Schwabe, D. & Rossi, G. The Object-Oriented Hypermedia Design Model (OOHDM) [online]. Päivitetty 23.6.2003 [viitattu 24.1.2005]. Rio de Janeiro: Pontifícia Universidade Catolica do Rio de Janeiro. Saatavissa www-muodossa: <URL: http://www.telemidia.puc-rio.br/oohdm/oohdm.html >. W3C. Introduction to CSS. [viitattu 24.1.2005] <URL: http://www.w3schools.com/css/css_intro.asp>. W3C. Cascading Style Sheets home page. [viitattu 24.1.2005] <URL: http://www.w3.org/style/css/>. 12