2.4. Suunnittelu

Suunnitteluvaiheessa luodaan puitteet ja päätetään siitä, miten kartoituksessa hahmotetut asiat toteutetaan. Suunnittelussa pitäisi määritellä muun muassa:

• käytettävä projektimalli
• ihmiset, roolit ja toimenkuvat
• suunnitelma sisällöstä
• sisällön sisäinen ja ulkoinen rakenne
• navigointitavat
• aihepiirien nimeämistapa
• tiedostojen nimeämispolitiikka
• palvelun käyttöliittymäidea
• visuaalinen yleisilme
• tekniset toteutustavat
• tuotantotyökalut ja -ympäristö
• testauksen suunnittelu
• mahdolliset demot
• aikataulu

Yllä olevia osa-alueita käsitellään yksityiskohtaisemmin kirjoissa Web Site Engineering ( Powell, 1998), Information Architecture for the World Wide Web (Rosenfield & Morville, 1998) ja graafisen suunnittelun näkökulmasta kirjassa Creating Killer Web Sites (Siegel 1997b).

Projektimalli

Kolme yleisintä projektimallia ovat:

• ad hoc
• spiraali
• vesiputous

Projektimallien löyhässäkin omaksumisessa on kuitenkin etuna, että tuotantoprosessi kiinteytyy. Yksinkertaisimmillaan kannattaa pitää sännöllisiä palavereja 1-2 viikon välein ja noudattaa sovittuja aikatauluja. Varsinainen tuotantomalli (keskitetty, hajautettu jne.) muotoutuu yleensä tuotannon myötä. Osa tutkittujen palveluiden heuristisista virheistä (kuten sivujen yhtenäistäminen) olisivat oletettavasti poistuneet pienellä koordinoinnilla ja tuotantoproseduurilla.

Yleisin verkkopalveluiden projektimalli on ns. ad hoc. Malli saattaa toimia hyvin pieniessä projekteissa, joissa myös toteuttava ryhmä on tiivis ja kooltaan pieni (Powell, 1998). Tämänkaltainen malli tuottaa kuitenkin yleensä tulokseksi dokumentoimattoman tuotteen, jonka suunnittelussa tehtyjen ratkaisujen logiikka jää usein ulkopuoliselta piiloon. Myös ohjelmakoodi on ad hoc -prosesseissa usein laadultaan heikkoa. Nämä molemmat seikat vaikeuttavat helposti tuotteen jatkokehittelyä ja uusien ihmisten tuomista mukaan prosessiin, ilman pidempää perehdyttämiskautta.

Ad hoc -malli on hyvin ominainen web-tuotteille, koska rakentamiseen tarkoitetut työkalut yleensä rohkaisevat kokeilemaan ja hyväksymään kokeilun viimeisteltynä tuotteena. Tässä mielessä web-tuotteistus muistuttaa jollain tavoin nopeaa ohjelmistokehitystä (RAD), joskin suunnittelu- ja testausvaiheiltaan lyhennettynä. Web-projektien kohdalla kuuleekin usein määritelmän "toteuta ja julkaise", jolla halutaan kuvat prosessin helppoutta: toteuta ideat ja julkaise ne verkkoon.

Verkon alkuvaiheista periytynyt nopean toteuttamisen malli ei kuitenkaan enää toimi aikana, jolloin yhä useammat palvelut kilpailevat samoista asiakkaista ja vain alusta saakka hyvin toimivat palvelut onnistuvat vetämään kävijät takaisin palveluun. Siksi käytettävyyteen panostaminen on noussut etenkin uusille palveluille onnistumisen ehdoksi. Käyttäjät eivät palaa helposti palveluun, jota on vaikea käyttää, jos tarjolla on muitakin palveluita.

Vaihtoehtoisia projektimalleja löytyy mm. ohjelmistosuunnittelun puolelta, jossa on käytetty menestyksekkäästi spiraalimallia. Siinä edetään iteroiden lopulliseen ratkaisuun toistuvien ideointi-arviointi-analysointi-syklien avulla. Luonteeltaan spiraalimalli on vaikeammin hallittavissa, koska prosessin eri osista on vaikea sanoa tarkasti milloin ne alkavat ja päättyvät (esim. milloin ideat on tuotettu, mistä alkaa analysointi ja mistä tuotannon suunittelu). Tällaisessa mallissa, kuten tietysti muissakin, tehtyjen päätösten ja valintojen dokumentointi auttaa prosessin edetessä, jos dokumentoitua tavoitesuunnitelmaa ei ole kirjattu.

Spiraalimalli (kuva 2.3) soveltuukin erityisen hyvin web-tuotannon alkusuunnitteluun, jossa varsinainen design- ongelma (mitä pitäisi ratkaista tai tuottaa) ei ole täysin hahmottunut (Powell, 1998). Suunnittelu etenee sitten ongelman määrityksen ja ratkaisuehdotusten tuottamisen sykleinä, kunnes nämä ovat tarpeeksi hioutuneita ja ratkaisuja voidaan lähteä analysoimaan tarkemmin ja miettimään niiden toteutusta.

Kuva 2.3: Spiraalimalli soveltuu projekteihin, jossa tavoitteet eivät ole selkeitä

Spiraalimalli ei vaikean hallittavuutensa vuoksi ole kuitenkaan paras mahdollinen aloitteleville web-suunnitteluryhmille, vaan sen sijaan voidaan käyttää myös muunneltua vesiputousmallia. Vesiputousmalli on aikataulullisesti usein luotettavampi ja helpompi hallita, koska se etenee selkeiden peräkkäisten vaiheiden kautta. Sen vaarana on kuitenkin kartoitusvaiheen aliarvioiminen ja kiinnittyminen jo alkuvaiheessa epäoleellisiin ongelmiin (ts. lähdetään suunnittelemaan ratkaisua väärään ongelmaan tai tarpeeseen, jota ei kunnolla ymmärretä).

Vesiputousmalli (kuva 2.4) on usein selkeämpi läpivienniltään, mutta tuottaa usein ratkaisun, jonka asiakastyytyväisyys ei ole yhtä korkea kuin spiraalimallilla tuotetun. Se soveltuu parhaiten projekteihin, jossa tavoitteet ovat selkeät ja kokonaisuus on monimutkainen (Andersen, et. al., 1990).

Kuva 2.4: Vesiputousmalli sopii projekteihin, joissa on selkeät tavoitteet

Projektimallin valinnassa on tärkeää ymmärtää, minkälaisesta tuotannosta on kyse: pieni, tehokas ja vakiintunut tuotantoryhmä voi pystyä toteuttamaan omalla orgaanisella mallillaan pienehkön kokonaisuuden onnistuneesti. Suuremmat kokonaisuudet, joissa sisällön, palveluiden tai osapuolten määrä edellyttää dokumentointia, eivät usein onnistu ilman erillistä projektin johtoa ja tavoitteille soveltuvaa läpivientimallia.

Valmiiden ratkaisuiden toteuttaminen suoraviivaisesti on usein helpompaa muunnellun vesiputousmallin avulla, kun taas uusia vaihtoehtoja kartoittavia ratkaisuja on usein helpompi etsiä ainakin alkuvaiheessa spiraalimallin avulla. Projektin määritys, tekijät ja käytettävissä olevat resurssit määräävät siis minkälainen malli soveltuu parhaiten projektin läpiviemiseen.

Informaatioarkkitehtuuri

Informaatioarkkitehtuuri voi perustua useaan erilaiseen perusmalliin, joista yleisimmät ovat hierarkkia, vapaatekstihaku, hyperteksti ja navigoitavat tietoavaruudet (Foltz, 1998). Näistä hierarkkinen jäsennystapa soveltuu hyvin tietoon, joka voidaan luokitella luontevasti hierarkiaan ja jonka käyttö on luonteeltaan tarkentuvaa (auttaa hierarkian sisällä liikkumista). Vapaatekstihaku sopii puolestaan erikoisalueille, jossa on vakiintunut hakutermistö ja haettavissa olevan sisällön laajuus on selvillä. Hyperteksti taas soveltuu puolestaan merkityksellisten kokonaisuuksien rakentamiseen sisällöltään luontevasti ristiinlinkittyvään materiaaliin. Kaikissa ajattelutavoissa on kuitenkin omat puutteensa, minkä takia informaation etsimiseen onkin esitetty luontaista navigointia muistuttavia informaatioavaruuksia.

Onnistunut informaatioarkkitehtuuri auttaa käyttäjää siis ymmärtämään mitä osaa tietomassasta hän kulloinkin katselee, missä suhteessa tämä osio on muihin tietoihin, mitä kautta hän pääsee muihin tietoihin käsiksi ja milloin hän on matkalla oikeaan suuntaan. Informaatioarkkitehtuurin ja navigoinnin termistö lainaakin paljon perinteisen arkkitehtuurin ja suunnistamisen käsitteistöä: puhutaan tiloista, poluista, maamerkeistä, kartoista ja suunnistusvälineistä. Tarkemman kuvauksen informaatioavaruuksien suunnittelusta saa tutustumalla Mark Holtzin lopputyöhän verkossa (Holtz, 1998).

Leiskat ja prototyypit

• presentaatio
• funktionaalinen
• leipälauta
• pilottijärjestelmä

Prototyyppejä voi käyttää joko kertakäyttöisesti, jolloin niitä voidaan hyödyntää vain kerran prosessin aikana, tai osana varsinaisen tuotteen rakentamista. Molemmilla tavoilla on omat hyötynsä.

Yksinkertaisin prototyyppi on presentaatioprototyyppi (nk. leiskat). Sen tarkoituksena on yleensä visualisoida käyttöliittymää ja tarjota projektin osallisille alkuvaiheessa jonkinlainen kuva palvelusta, jota ollaan tekemässä. Presentaatioprotoja käytetään usein sekä myyntivaiheessa että palvelun ideoiden (etenkin käyttöliittymäideoiden) kartoituksessa. Niitä voi tehdä hyvin nopeasti paperille, jolloin ne toimivat yleensä kertakäyttöisesti.

Web-sivujen rakennustyökaluilla tehtyjä presentaatioprotoja voidaan puolestaan hyödyntää varsinaisen palvelun käyttöliittymän rakentamisessa. Toistaiseksi nopeaan protoiluun soveltuvat visualistin työkalut ovat kuitenkin niin kehittymättömiä, että ainakaan niiden tuottamaa HTML-koodia ei voi suositella varsinaisen palvelun osaksi (Hintikka 1998).

Funktionaalinen prototyyppi rakennetaan yleensä esittämään palvelun keskeisen osien (sekä toimintojen että käyttöliittymän) yhteistoimintaa. Funktionaalinen proto on siis usein tietokoneelle toteutettu toimiva proto, joskin sitä voidaan simuloida myös videon tai multimedia-esityksen avulla.

Funktionaalista prototyyppiä voi jo osittain testata käyttäjillä ja sitä voi käyttää hyväksi erityisesti vuorovaikutuksen suunnittelussa. Tämänkaltaisen proton rakentaminen on erityisen oleellista, jos palvelu on hyvin monitoimintainen tai muuten monimutkainen. Proton rakennusvaiheessa löydetyt ongelmat voidaan usein ohittaa varsinaisessa tuotantoversiossa, mutta tämä edellyttää usein prototyypin koodin hylkäämistä ja tyhjältä pöydältä aloittamista. Funktionaalinen prototyyppi on usein kertakäyttöinen luonteeltaan, joskin se voidaan soveltaa myös palvelun evolutionäärisen kehityksen osaksi.

Leipälautaprototyyppi rakennetaan puolestaan testaamaan järjestelmän tiettyä toiminnallisuutta ja analysoimaan siihen liittyviä riskejä. Tällainen voi olla esimerkiksi kolmelle palvelimelle (tietokanta, web ja sovellus) jakautuvan ratkaisun välinen tietoliikenne. Käytettävyyden kannalta tällaisilla prototyypeillä voidaan usein arvioida palvelun kuormansietoa, skaalautuvuutta ja vasteaikoja. Erityisten suurten, hajautettujen tai toiminnallisesti kriittisten (kuten pankkijärjestelmien) kohdalla leipälautaprototyypin rakentaminen on erityisen suositeltavaa. Työmääränsä raskauden takia se päätyy yleensä osaksi lopullista järjestelmää muutoksineen.

Pilottijärjestelmä on hyvin pitkälle kehitetty prototyyppi, joka sisältää usein keskeisen toiminnallisuuden ja toteutuksen lopulliseksi käyttöliittymäksi. Pilotteja voi testata ja arvioida hyvin laajasti, joskin niihin ei välttämättä aina pystytä tekemään enää kovin suuria muutoksia. Pilottiprototyyppi rakennetaan käytännössä kaikissa web-projekteissa, joskaan sitä ei aina huomata erottaa muista protoista ja unohdetaan näin testata perinpohjaisesti.

Toiminnallisten järjestelmien erilaiset prototyypit

	Presentaatio	Funktionaalinen	Leipälauta	Pilotti
Ideoiden kehittely	(ulkoasu)	(vuorovaikutus)	Kyllä	Koko järjestelmä
Päätöksen tuki	(ulkoasu)	Kyllä	(riskianalyysi)	Koko järjestelmä
Ulkoasun arviointi	Kyllä	(kyllä)	ei	Koko järjestelmä
Kartoituksen tuki	(ulkoasu)	Kyllä	Kyllä	(lisäkartoitus)
Tekniikan arviointi	ei	Kyllä	(osajärjestelmä)	Koko järjestelmä

Taulukko 2.5: Eri prototyyppien soveltuvuus tuotantoprosessin eri osien avuksi