10 vinkkiä, joilla nettisivuprojekti onnistuu

LumoLinkillä on vuosikausien kokemus sekä kotimaisista että kansainvälisistä nettisivuprojekteista. Avuksi niin tuleville asiakkaillemme kuin muillekin, joiden työtehtäviin kuuluu Internet-sivujen hankinta, päätimme koostaa ja julkaista lyhyehkön ohjeen. Tämä ohjeistus perustuu omiin hyviin ja ei niin hyviin kokemuksiimme.

Kymmenen kohtaa – itse asiassa vinkkiä tai tapaa – sisältävä ohje antaa kullanarvoisia vinkkejä siihen, miten on mahdollista tehdä hyvä nettisivuprojekti ja miten voidaan varmistaa projektin onnistuminen. Samalla annamme vinkkejä mahdollisten ongelmien varalle.

1. Hyvä tarjouspyyntö

Tarjouspyyntövaiheeseen panostetaan yleensä vähiten nettisivuprojekteissa. Se kyllä tiedostetaan, että on tarve ja aika tehdä (uudet) nettisivut. Esimerkiksi juuri perustetulle yritykselle tarvitaan nettisivut tai vanhentuneiden tilalle täytyisi tehdä uudet sivut. Selvähän se.

Kun tarve on tiedossa, ei maltti tahdo riittää tarjouspyynnön kanssa. Nopeasti vain etsitään verkkosivujen toteuttajia, pyydetään tarjouspyyntöjä ja sitten ruvetaan tekemään. Tällä tavalla turhan hätäisesti toimittaessa projekti ei useinkaan vastaa tilaajan eikä myöskään toteuttajan odotuksia, koska asiakas on niin sanotusti ostanut sian säkissä.

Tyypillisesti reitti ongelmiin on hyvin samankaltainen. Asiakas on kertonut, että tarvitaan simppelit sivut, jolloin toteuttaja on mieltänyt projektin pienemmäksi ja hinnoitellut projektin sen mukaisesti. Sitten paljastuukin, että on olemassa ”pieni” integraatio johonkin asiakkuudenhallinta- eli CRM-järjestelmään – ja yhtäkkiä projekti kasvaakin 50 %. Sitten kun asiakas on vielä tyytymätön designiin, joudutaan tekemään toinen vaihtoehtoinen versio, jolloin toteuttajalta loppuvat resurssit. Myös projektin hinnoittelussa mennään miinuksen puolelle. Tässä tilanteessa toteuttaja haluaa vain eroon projektista, hinnalla millä hyvällä. Asiakas puolestaan kokee, että hän ei saa rahoilleen toivomaansa vastinetta ja häntä on kohdeltu väärin. Kuten arvata saattaa, lopulta molemmat osapuolet ovat osallisina siihen, että projekti epäonnistuu.

Sen lisäksi, että toteuttajan tulee ottaa huomioon tarjouspyynnössä mainitut asiat, toteuttajan on hyvä osata kysyä sellaisia asioita, joita asiakas ei osaa itse kysymättä kertoa. Toteuttajan on pystyttävä riittävän selkokielisesti kertomaan asiakkaalle, mitä asiakas on tosiasiassa ostamassa.

Hyvä tarjouspyyntö on sellainen, jossa asiakas kertoo lyhyesti omasta taustastaan sekä siitä, mitä nettisivujen tulee tehdä ja mikä on niiden tärkein tehtävä. Yleensä sivuston tärkein tehtävä on myydä, olipa sitten kyse B2B- tai B2C-myynnistä. Yritysten välillä eli B2B-puolella ei ole välttämättä kyse kalliin tuotteen ostosta nettikaupasta vaan ykköstavoite voi olla yhteydenotto, mutta tässäkin tapauksessa yhteydenoton myötä tähdätään ja pyritään myyntiin. Yritysten ja kuluttajien välillä eli B2C-puolella myynti on usein verkkokauppamyyntiä, suoramyyntiä.

Tarjouspyyntöä tehdessään asiakkaan kannattaa kuvailla tarvetta ja taustaa. Kannattaa esimerkiksi kertoa, että yritys on perustettu vuonna 2010 ja sen nykyiset nettisivut on hankittu silloin ja silloin, mutta nyt on tarkoitus uusia nettisivut, koska halutaan saada uusi ilme, luoda nettikauppa ja perustaa yritykselle oma blogi. Jotain tämänkaltaista, jotta lähtötilanne ja pyrkimykset tulevat ilmi.

On hyvä luoda vaatimusmäärittely, vaikka se monesti onkin asiakkaalle erittäin vaativa tehtävä. Käytännössä vaatimusmäärittely voi olla yksinkertainen Excel-tiedosto, johon asiakkaan tulee kuvata nettisivujen ominaisuuksia tietyssä muodossa. Siinä asiakkaan omat vaatimukset pitää jakaa kolmeen eri kategoriaan niiden tärkeysjärjestyksen mukaisesti. Vapaasti suomennettuna kategoriat ovat englanninkielisine vastineineen seuraavat: ”pakollinen ominaisuus” (must have), ”toivottava ominaisuus” (should have) ja ”lisäominaisuus” (nice to have).

Vaatimusmäärittely täytetään muodossa ”X pitäisi pystyä tekemään Y nettisivulla” (X = kenen pitäisi pystyä tekemään, Y = mitä pitäisi pystyä tekemään). Esimerkiksi ”Sivuston vierailijan pitäisi pystyä jättämään yhteystiedot sivustolle” (X = Sivuston vierailijan, Y = jättämään yhteystiedot sivustolle). Toisin sanoen X on rooli ja Y on yhtä kuin toiminto. Huolellisesti tehtynä vaatimuksista syntyy lista, joka kertoo sivustoon kohdistuvat vaatimukset tärkeysjärjestyksessä.

Must have -ominaisuuksissa pitäisi olla kaikki ne ominaisuudet, jotka ovat niin tärkeitä, että ilman niiden toteuttamista koko sivustoa ei ole kannattavaa julkaista. Should have -ominaisuuksina olevat ovat joko mahdollisesti tulevaisuudessa tulevia ominaisuuksia tai jo nyt mukaan tulevia ominaisuuksia, jos budjetti sallii ne ja niiden toteutus käy kätevästi. Nice to have -ominaisuudet puolestaan ovat sellaisia kivoja lisäjuttuja, joilla ei ole kokonaisuuden kannalta niin paljon merkitystä, mutta jos ne saadaan mukaan, niin se on kiva asia. Joka tapauksessa projektin myötä syntyvä sivusto voidaan julkaista ilman näitä ei niin pakollisia, vähemmän tärkeitä ominaisuuksia.

Kun tuollainen dokumentti on kerran huolella täytetty, on paljon helpompaa pyytää tarjouksia ja myös vertailla saatuja tarjouksia keskenään. Samalla poistuu tai ainakin merkittävästi vähenee riski siihen, että joku toimittaja ei suostukaan projektiin ja sitä ei sitten pystytäkään toteuttamaan.

2. Sopimukset

Kun oikea palveluntarjoaja eli nettisivujen toteuttaja on vihdoin ja viimein löytynyt, on aika solmia sopimus. Tosin pienemmissä projekteissa sopimusta ei yleensä edes täytetä vaan asiakas hyväksyy tarjouksen, jossa on ehtoja käyty läpi.

Sopimuksessa on tärkeää varmistaa, että sivuston omistusoikeus siirtyy asiakkaalle sen jälkeen, kun hän on hoitanut maksun sovitulla tavalla. Sopimuksessa täytyy varmistaa myös se, että projektia voi jatkaa joku toinen, kolmas osapuoli, jos on pakko. Projektin mahdollisiin siirtotilanteisiin kannattaa kaiken varalta varautua mahdollisimman paljon jo etukäteen. Siksikin verkkosivujen toteutukseen kannattaa ehdottomasti käyttää jotain yleistä teknologiaa. Enemmän kuin suositeltavaa on pyrkiä käyttämään avoimen lähdekoodin ratkaisuita (esimerkiksi WordPress) ja muita suosittuja ratkaisuita, joita käyttäviä toimittajia on paljon niin Suomessa kuin muualla maailmassakin. Näin ennaltaehkäistään tulevia ongelmatilanteita.

Jos toimittajan ja asiakkaan välisessä kirjallisessa sopimuksessa lukee, että nettisivusto on asiakkaan omistama ja se on tehty avoimeen lähdekoodiin pohjautuvalla teknologialla, asiakas voi olla melko varma siitä, että toimittajan vaihtaminen kesken projektin onnistuu, jos matkan varrella tulee äärimmäisiin toimenpiteisiin johtavia erimielisyyksiä.

Lisäksi sopimuksessa on syytä määrittää ja selventää aikatauluja, vastuita, kustannuksia ja tilanteita, joissa kustannukset ylittyvät. Siitäkin on hyvä olla mustaa valkoisella, missä tapauksessa kustannukset voivat ylittyä, millä tavalla ne voivat ylittyä ja mitä tapahtuu silloin, kun ne ylittyvät.

3. Rautalankaversio (mockup)

Rautalankaversio eli niin sanottu mockup on hyvä tapa käydä sivustoa läpi ennen kuin aletaan miettiä ulkoasupuolta, sanalla sanottuna designia. Rautalankaversio on vähän niin kuin kynällä piirretty hahmotelma, joka poistaa epäselvyyksiä. Mikäli projektissa on vähänkään epäselvyyksiä tai projekti on suhteellisen iso, suosittelemme aina, että ensin tehdään rautalankaversio nettisivuista. Rautalankaversiovaiheessa tavoitteena on pikkuisen visualisoida sivuston arkkitehtuuria ja rakennetta ottamatta kantaa väreihin ja muihin vielä tässä vaiheessa epäolennaisiin seikkoihin.

Jos aloitetaan tekemällä design heti, on hyvin todennäköistä, että asiakas haluaa tehdä paljon muutoksia eri asioihin, koska hän näkee designin. Siitä tulee mieleen uusia ajatuksia sivuston rakentamiseen liittyen, jolloin monesti ruvetaan miettimään värejä ja fontteja. Rautalankaversiossa ei ole kuitenkaan edes mahdollista puhua väreistä ja fonteista, koska ne eivät ole olennaisia. Niiden sijaan olennaista on rakenne, miten paljon tekstiä on missäkin kohdassa ja missä kuvat ovat. Mockup on kommunikointiväline, jota käydään läpi ja muokataan niin kauan, että eri osapuolille syntyy hyvä ymmärrys siitä, mitä ollaan rakentamassa.

Rautalankaversion tekeminen on kustannustehokasta ja se ei useinkaan vie useita tunteja. Kaikkein mittavimmissa projekteissakin puhutaan enimmillään muutamasta päivästä, ei sen pidemmästä ajasta. Mockupissa voidaan keskittyä rakenteeseen sekä käydä se läpi toimittajan ja asiakkaan kesken. Kun rakenne on selvillä, tämän jälkeen asiakas voi pyytää muutoksia rakenteeseen ilman, että siitä aiheutuu toimittajalle suuresti päänvaivaa ja kustannuksia. Mockup on hyvä apukeino ja mikä parasta, parhaassa tapauksessa se säästää paljon rahaa.

Kun rautalankaversio on tehty ja hyväksytty, silloin meillä toteuttajana on hyvä ymmärrys siitä, mitä olemme rakentamassa. Itse asiassa sopimuksen mukaan toimittajalla pitäisi aina olla oikeus tarkentaa tarjouspyyntöä rautalankavaiheessa, koska rautalankaversiossa nähdään ensimmäistä kertaa, mikä ja mitä sivusto oikeasti on sekä minkälaisia toiminnallisuuksia siellä pitää olla. Jos rautalankavaiheessa paljastuu, että kustannusarvio oli tehty väärin, sitä pitäisi pystyä korjaamaan. Tämä ei suinkaan tarkoita sitä, että toimittaja heti nostaa hintaa rautalankaversion jälkeen, koska jos näin tapahtuu ja asiakas kokee sen olevan väärin, asiakas voi lähettää rautalankaversiota, vaatimusmäärittelyä ja tarjouspyyntöä muille toimijoille ja pyytää kilpailevia tarjouksia. Tämän vuoksi ei ole toimittajan omankaan edun mukaista nostaa hintaa kohtuuttomasti ihan muuten vaan.

Rautalankaversiossa voi paljastua uusia tarpeita tai asiakas voi haluta uusia ominaisuuksia, joita ei ole otettu huomioon tarjouksessa. Ei ole itsestään selvää, että toimittaja suostuu lisäämään näitä uusia ominaisuuksia maksutta. Otetaan esimerkiksi tilanne, jossa asiakas haluaa yhteydenottolomakkeen tilalle sivustolle paremmin sopivan ja hyödyllisemmän tuotteiden hintalaskurin. Hintalaskurin halutaan poistavan turhia yhteydenottoja ja myyntimiestä turhaan työllistäviä hintatiedusteluita, koska asiakas pystyy itse laskemaan hinnan nettisaitilla ja voi ottaa yhteyttä vasta hinnan laskettuaan. Hintalaskuri on paljon vaikeampi toteuttaa kuin perinteinen yhteydenottolomake. Toiminnallisuuden lisääminen tulkitaan lisätyöksi, joten lisätoiminnallisuudesta toimittaja antaa kustannusarvion.

Rautalankaversiossa on vielä mahdollista perusteellisestikin muokata sivuston ominaisuuksia eikä projektista tule liian jäykkä. On kaikin puolin hyvä asia ja kaikkien edun mukaista, että kustannukset tarkastetaan ja varmistetaan rautalankaversiossa.

4. Konversio-optimointi

Konversio-optimointi tarkoittaa tässä yhteydessä sitä, että pitää miettiä sivuston tärkein tehtävä ja täytyy luoda koko sivusto sen ympärille. Jos tavoitteena on saada yhteydenottoja, sivustoa käyttävillä ihmisillä täytyy olla mahdollisuus ottaa yhteyttä jokaiselta alasivulta – ja vieläpä hyvin yksinkertaisesti ja helposti. Jos taas on tarkoitus myydä ja sivusto on verkkokauppa, pitää miettiä erityisesti sitä, miten konversiota voidaan parantaa, miten ihmiset saadaan ostamaan ja miten keskiostosta voidaan kasvattaa. Esimerkiksi luotaessa jokin ominaisuus tai toiminto, jolla asiakas voi saada alennusta useampia tuotteita ostaessaan, keskiostos kasvaa.

Konversio-optimointi unohdetaan usein, jos ja kun sen sijaan keskitytään designiin ja muihin asioihin. Jos mietitään maailman suosituimpia sivustoja, kuten Googlea ja Wikipediaa, ne keskittyvät ihmisten ongelmien ratkaisemiseen. Kaikki muu, siis ihan kaikki, on toissijaista. Myös omassa verkkosivuprojektissa täytyy pitää päätavoite kirkkaana mielessä ja luoda koko sivusto ajatellen omia asiakkaita, heidän ongelmiaan ja konversiota, mitä halutaan saada aikaiseksi.

5. Product owner

Product owner on henkilö, jolla on viimeinen sana nettisivuasioissa. Toimittajan kannalta ihannetilanne on sellainen, että projektissa asiakkaalla on vain yksi nettisivutoteutuksesta vastuussa oleva henkilö. Käytännössä kyseisen henkilön ei suinkaan tarvitse olla teknisen puolen asiantuntija vaan olennaista on se, että hänellä tulee olla päätösvaltaa nettisivuihin liittyen ja valtuudet päättää nettisivuasioista asiakkaan puolesta.

Usein varsinkin isoissa projekteissa perustetaan erilaisia ryhmiä – ohjausryhmiä ja muita – ja pyydetään palautetta useilta henkilöiltä. Tämä on sinänsä hyvä asia, mutta asiakkaalla täytyy olla yksi toimittajan kanssa läheisesti toimiva ja käytettävissä oleva henkilö, joka tarpeen vaatiessa kertoo asioiden kulloisenkin tilan ja kerää sisäistä palautetta. Hän on yhteyshenkilö, kun kehityksen aikana joudutaan tekemään päätöksiä ja mahdollisesti myös kompromisseja tai keskustelemaan toiminnallisuuksista ja muista seikoista. Tällaisen product ownerin tärkein tehtävä on kerätä palautetta sisäisesti, minkä lisäksi henkilön on tiedettävä ja tunnettava asiakkaan kohderyhmät eli nettisivujen tulevat käyttäjät ja heidän ongelmansa.

Jos tällä product owneriksi kutsutulla henkilöllä on kaiken lisäksi edes jonkinlaista teknistä osaamista tai ymmärrystä, se on todella hyvä ja arvokas asia. Hänen pitäisi ainakin ymmärtää ja tietää, millaisia resursseja hänen edustamallaan yrityksellä eli asiakasyrityksellämme on. Tällöin ei turhaan luoda sellaisia ominaisuuksia, jotka vaativat resursseja, joita yrityksellä ei kerta kaikkiaan ole olemassa. Esimerkiksi on turha laittaa livechat-toimintoa sivustolle, jos kukaan ei pysty päivystämään livechatissa ja viestittelemään nettisivuilla vierailevien kanssa.

6. Projektinhallinta ja -seuranta

Projektinhallinta tarkoittaa lyhykäisyydessään sitä, että projektissa on olemassa tietyt vastuut ja ihmiset, jotka ovat vastuussa määrätyistä asioista. Näillä ihmisillä on säännöllistä yhteydenpitoa ja kommunikaatiota keskenään. Käytännössä pienissä projekteissa asiakkaan edustaja, henkilö X, vastaa projektista ja toimii product ownerina, kun taas toimittajayrityksessä projektista vastaa henkilö Y. Heillä voi olla kahden viikon välein Skype-palaveri, jolloin he käyvät sivustoa ja tilannetta läpi, ja muulloin he viestivät keskenään esimerkiksi sähköpostitse.

Mittasuhteiltaan suuremmissa projekteissa on hyvä käydä projektin aloituksessa asiat läpi. Lisäksi jokaisesta palaverista on hyvä syntyä jonkinlainen muistio, mikä suojelee molempia osapuolia. Jos asioita tulkitaan tai muistetaan väärin, muistioihin on hyvä vedota ja niistä on myös jälkikäteen kätevää varmistaa, että toimittaja ja tilaaja tekivät asiat juuri oikealla tavalla.

Niin ikään isommissa projekteissa on hyvä, jos asiakas saa pääsyn toimittajan käyttämään projektinhallintajärjestelmään sekä pystyy luomaan sinne vaikkapa ohjelmointivirheitä sisältäviä bugilistoja ja muutenkin seuraamaan projektia projektinhallinnan kautta. Varsinkin jos projekti kestää pitkään, pääsy projektinhallintajärjestelmään voi olla todella hyvä asia. Tällaisissa tapauksissa valitaan yleensä tietty osa ominaisuuslistasta, jota toteutetaan seuraavassa syklissä. Sykli voi olla esimerkiksi kaksi viikkoa, jolloin kahden viikon päästä asiakas saa uuden version nettisaitista, tarkastaa sen ja tekee tarpeellisiksi katsomansa muutospyynnöt suoraan toimittajan projektinhallintajärjestelmään.

7. Aikataulutus

On suotavaa sopia aikataulusta – ennen kaikkea realistisesta aikataulusta. Usein asiakkaan pyytäessä tarjouksen nettisivujen toteutuksesta hän on jo hieman myöhässä, mistä johtuen hän haluaa saada nettisivuston valmiiksi mahdollisimman nopeasti. Kannattaa kuitenkin muistaa, että nettisivusto ei voi yhtäaikaisesti olla laadukas, nopeasti tehty ja kaiken lisäksi halpa. Se ei vain kerta kaikkiaan ole mahdollista.

Kuten heti ohjeemme ensimmäisessä vinkissä kerroimme, panostamalla hyvään tarjouspyyntöön voi varmistaa kustannusten pysyvän kurissa ja sen, että asiakas saa sitä, mitä hän oikeasti haluaa. Varsinaiseen sivuston toteutukseen kannattaa kuitenkin varata reilusti aikaa, sillä projekti koostuu monesta eri vaiheesta. Myös se, että asiakkaalla on iso rooli projektissa, voi vaikuttaa aikatauluun joko positiivisesti tai negatiivisesti. Usein asiakkaalta palautetta pyydettäessä asiakas on niin kiireinen, ettei ehdi antaa palautetta, jolloin projektin venyessä toimittaja joutuu ikävään tilanteeseen, kun nettisivujen toteuttajasta riippumattomista syistä ei pysytä sovitussa aikataulussa.

Toki toteuttajankin pitäisi olla avoin ja pystyä heti sanomaan, mikäli se ei kykene suoriutumaan projektista asiakkaan pyytämässä aikataulussa tai sivujen tekeminen vie todellisuudessa kauemmin. Toteuttajat haluavat mahdollisimman monta projektia, mistä johtuen aikatauluihin suostutaan monesti jo ennen kuin aikataulua on edes ehditty nähdä. Jos aikataulu on hyväksytty siihen sen tarkemmin tutustumatta, voi olla, että myöhemmässä vaiheessa ei auta muu kuin todeta, että nyt ollaan aikataulusta myöhässä ja pahasti.

On hyvä varata projektille riittävästi aikaa, pitää välipalavereita ja kertoa avoimesti, jos tulee esteitä tai viivästyksiä puolin tai toisin. Jos aikataulu venyy, silloin se venyy. Olennaista on se, että viivästys ja siihen johtaneet syyt on avoimesti tuotava esille. Kaikenlainen tiedon pimittäminen esimerkiksi asiakkaan lähtemisen pelossa on äärimmäisen huono vaihtoehto, jolla voi olla katastrofaaliset seuraukset projektin, asiakkaan, toimittajan tai kaikkien niiden kannalta.

Nyrkkisääntömme on sellainen, että kun projektin kestosta on jonkinlainen ajatus tai arvio, se on hyvä kertoa kahdella, niin päästään lähemmäs realistista kestoa. Jos siis ajattelee saavansa nettisivut tehtyä kuukaudessa, se kannattaa kertoa vielä kahdella. On paljon parempi olla aikaa tehdä ja testata asioita hyvin kuin ”juosta” aamusta iltaan, tehdä mitä sattuu ja tehdä hirveitä kompromisseja. Kaikki ovat stressaantuneita, toimittaja tekee ylitöitä ja myös asiakas kärsii liian tiukan aikataulun vuoksi. Kenelläkään ei ole kivaa.

8. Kommunikaatio

Kommunikaation tulee olla jatkuvaa, minkä takia on hyvä pitää palavereita säännöllisesti. Yksittäisen palaverin ei tarvitse olla sen kummempi kuin Skype-palaveri, joka voi kestää puolisen tuntia ja josta kirjoitetaan lyhyt muistio, joka sitten toimitetaan sekä asiakkaalle että toimittajalle.

Palaverissa yleensä käydään läpi, mitä on tehty edellisen palaverin jälkeen, minkälaisia ongelmia tai riskejä on olemassa, mitä ja millaisia toimenpiteitä tarvitaan asiakkaalta sekä toki myös se, ollaanko aikataulussa. Tässä ovat yleisimmät palavereissa läpikäytävät kysymykset. Kun ne käydään läpi, siitä tehdään lyhyt muistio, joka toimitetaan kaikille osallistujille vaikkapa sähköpostilla.

Kun säännöllisiä palavereita pidetään, omakohtaisen kokemuksemme mukaan projektin onnistuminen on tällöin huomattavasti todennäköisempää. Jatkuvaan kommunikaatioon kannattaa todellakin panostaa ja sen merkitystä ei tule millään tavalla väheksyä.

9. Sisällönsyöttö

Usein toimittajaa hoputetaan ja kiirehditään sivuston toteutuksessa, mutta sitten kun sivusto on valmis ja se on toimitettu asiakkaalle sisällönsyöttöä varten, projekti venyy. Meillä on kokemusta tilanteista, joissa sisällönsyöttövaihe on pahimmillaan kestänyt jopa puoli vuotta. Eräässäkin tapauksessa varsinainen projekti saatiin tehtyä kuukauden aikana, mutta asiakkaalta sisällönsyöttövaihe kesti peräti puoli vuotta.

Kokemamme ja äsken kertomamme takia on hyvä tiedostaa, että sisällönsyöttövaihetta ei kannata odottaa vaan kannattaa kerätä sisältöä jo valmiiksi Word-tiedostoihin tai muualle. Kannattaa jo hyvissä ajoin esimerkiksi kerätä kuvia ja tehdä uusia kuvia. Sisällön luominen on hyvä aloittaa heti rautalankavaiheen (mockup) jälkeen, koska rautalankavaiheessa nähdään, miten paljon tekstiä tarvitaan millekin sivulle ja paljonko kuva- ja videoelementtejä on.

Sisällön luominen on usein asiakkaalle se kaikista vaikein vaihe. Omista asioista kerrottaessa tekstiä syntyy joko todella paljon tai vaihtoehtoisesti tekstiä ei meinaa syntyä millään, koska on hyvin vaikeaa päättää, mitkä olisivat ne kaikista olennaisimmat ja tekstissä mainitsemisen arvoiset asiat. Jos sisältöä ei muuten meinaa syntyä, sisällöntuotanto kannattaa ulkoistaa siltä osin kuin se on mahdollista. Useissa projekteissa olemmekin luoneet sisällön täysin asiakkaamme puolesta. Ensin olemme haastatelleet asiakastamme, minkä jälkeen copywriterimme on sitten tehnyt tarvittavaa sisältöä. Olemme myös syöttäneet sisällön sisällönhallintajärjestelmään asiakkaamme puolesta.

Nimensä mukaisesti sisällönsyöttövaiheen tulisi olla sisällön syöttöä eikä sen luomista. Sisällönsyöttö on aloitettava heti, kun rautalankavaihe on tehty, ettei se vahingossakaan jää viime tippaan. Jos sisällönsyöttö viivästyy, viivästyy koko projekti pahimmillaan useita kuukausia.

10. Seuranta

Sivustolla täytyy olla vähintään analytiikkatyökalut Google Analytics ja Google Search Console käytössä, jotta voidaan seurata hakukonenäkyvyyttä ja sivuston tilastoja. Lisäksi sivustolla on oltava konversioseuranta. Käytännössä siis Google Analyticsista on pystyttävä näkemään konversioita eli toimintoja, joita sivuilla käyvien ihmisten halutaan tekevän saitilla. Niiden avulla on mahdollista arvioida mainoskampanjoiden tehokkuutta.

Google Analyticsin konversioseurantaa voidaan hyödyntää Google AdWordisissa. Käytännössä AdWordsissa voidaan luoda mainontaa, suoraan mitata mainonnan tehokkuutta seuraamalla konversiota ja nähdä, miten mainokset eri hakutermeille kohdistettuina ovat tuoneet konversiota. Esimerkiksi verkkokaupan seuranta kannattaa integroida Google Analyticsiin, sillä tällöin Analyticsista voidaan euromääristä nähdä, paljonko mikäkin mainoskampanja on tuonut rahaa.

Hyvät analytiikkatyökalut ja konversioseuranta yhdessä auttavat panostamaan oikeisiin asioihin.

Haluatko sinäkin nettisivuprojektisi onnistuvan? Haluatko varmistaa, että nettisivuprojektisi onnistuu? Me LumoLinkillä olemme tehneet nettisivuprojekteja niin suomalaisille kuin kansainvälisillekin asiakkaille, joten ota yhteyttä.