Viestinnällisen verkkopalvelun uudistaminen on mittava ponnistus, joka kestää helposti määrittelyineen ja kilpailutuksineen yli vuoden verran. Viimeiset viikot ennen julkaisua ovat hankkeessa intensiivistä aikaa, jolloin tavallisesti törmätään viiteen seuraavassa kuvattuun ”yllättävään” ongelmaan. Jos ei pidä yllätyksistä, kannattaa suunnittelussa olla näiden suhteen kaukonäköinen.

1. Talosta ei löydy enää sisällöntuotantoresursseja

Verkkopalvelu-uudistuksessa täytyy talosta mobilisoida kaikki mahdolliset sisältö- ja viestintäihmiset, sillä tekemistä riittää: uuden verkkopalvelun sisältö on konseptoitava ja suunniteltava, vanhan palvelun sisällöt on käytävä läpi, päivitettävä ja muokattava, tarvittavat uudet sivut on käsikirjoitettava, sivut on syötettävä julkaisujärjestelmään (mitä varten uuden järjestelmän käyttö on opittava), sivut on testattava, kuvat on löydettävä ja aseteltava paikoilleen. Kieliversiot vaativat saman työn tuplana käännätysprosessin mutkan kautta.

Sisällönsyöttö tehdään julkaisujärjestelmän valmistumisen ja palvelun käyttöönoton välisenä aikana – samana ajankohtana, jolloin olisi myös hoidettava hyväksyntätestaus järjestelmän teknisen toimittajan työlle. Varsinkin jos sisältöihmiset tekevät verkkopalvelu-uudistusta ”oman työn ohessa”, ei sisältötyö mitenkään synny siinä muutamassa viikossa, joka sille tyypillisesti varataan.

Tämän tästä uudistusprojekteissa törmätään siihen ongelmaan, että julkaisun deadline olisi ensi viikolla, mutta verkkosivuja ei saada kasaan julkaistaviksi. Ulkopuolisen apuvoiman hankkiminen, ohjeistaminen ja ohjaaminen vaatii myös kunnolla resursseja, eikä apuvoima vastaa substanssiosaamiseltaan mitenkään oman talon kompetensseja. Lisäksi ulkopuolisesta lapiovoimasta ei ole paljoa iloa, mikäli talosta ei löydy valmiita, selkeitä käsikirjoituksia lapioitaviksi…

Kokemusten mukaan laajojen viestinnällisten verkkopalvelujen uudistuksessa olisi perusteltua varata julkaisujärjestelmän hyväksyntätestaukseen neljä viikkoa, ja sen perään vielä neljä viikkoa aikaa sisältöjen (kieliversioineen) syöttöön, testaukseen ja hiomiseen ennen julkaisua. Joka tapauksessa omaan muistilistaan kannattaa laittaa nämä:

  • laske realistisesti, paljonko työtä sisällönsuunnitteluun ja –syöttöön tarvitaan
  • varaa oman talon sisältöresurssit projektina, älä luota ”otoiluun”
  • käynnistä sisältösuunnittelun työ hyvissä ajoin ja varaa sille tarpeeksi aikaa
  • älä anna sisältösuunnittelun valua sisällönsyötön vaiheeseen

2. Osoitteiden uudelleenohjaukset unohtuvat

Google painottaa hakutuloksissaan ”vanhoja” sivustoja, joilla on pitkä historia ja joiden sivuille on linkitetty useasta eri verkkopalvelusta. Verkkopalvelu-uudistuksessa muuttuvat tavallisesti sivuston rakenteet ja nimeämistavat, joten tietystä teemasta kertova sivu saa itselleen uuden URLin. Tämän teeman nykyinen hakukonenäkyvyys menetetään lopullisesti, jos uudistuksen yhteydessä ei kerrota hakukoneille, että tämä sivu on muuttanut pysyvästi uuteen osoitteeseen.

Www-osoitteiden uudelleenohjausta varten on vanhasta palvelusta poimittava keskeisimpien teemasivujen www-osoite ja näille osoitteille on määriteltävä palvelinpäässä pysyvä uudelleenohjaus (ns. 301-ohjaus) siihen URLiin, jonka ne saavat uudessa järjestelmässä. Uuden verkkopalvelun käyttöönotossa näiden uudelleenohjauksien täytyy olla paikallaan tai vanhan sivuston hakukonenäkyvyys menetetään.

Uudelleenohjaukset pitäisi hoitaa juuri siinä projektin kiireisimmässä vaiheessa, jossa hyväksyntätestaus, sisällönsyöttö ja sisältöjen testaus vaativat kaikki sisältöresurssit. Ei ihme, että se jää niin helposti tekemättä. Siitä syystä:

  • pistä projektisuunnitelmaan kalenterivaraukset ja vastuut URLien uudelleenohjauksista
  • sovi teknisen toimittajan kanssa järjestelyistä hyvissä ajoin ennen loppumetrien kiireitä

3. Testausaika loppuu kesken

Projektinhallinnassa on pitkät perinteet sille, että deadlinen pysyminen muuttumattomana on osoitus projektin laadusta. Jostain syystä pidetään arvokkaana sitä, että arvausten perusteella kuukausia aikaisemmin keksitty julkaisupäivämäärä ei muutu, vaikka mitä tapahtuisi.

Verkkopalvelun uudistusprojektissa eri vaiheet syntyvät harvoin siinä tahdissa kuin on aikataulutettu. Kun deadlinen päivämäärästä pidetään tinkimättömästi kiinni, käy tyypillisesti niin, että projektin välivaiheiden kaikki viivästykset valuvat testausvaiheeseen, mutta julkaisua ei lykätä. Riittävän testauksen vaatimaa aikaa ei oteta, vaan uusi verkkopalvelu pistetään julki testaamattomana, täynnä suurempia tai pienempiä virheitä, viimeistelemättömänä.

Huonon ensivaikutelman jälkiä on vaikeaa korjata jälkikäteen, ja käyttäjät ovat tuomioissaan melko armottomia. Pohdi siitä syystä vakavasti:

  • Mikä katastrofi muka olisi lykätä julkaisemista, jotta saataisiin aikaan toimiva, testattu ja viimeistelty verkkopalvelukokonaisuus?

4. Käyttäjätestien tuloksiin ei ehditä reagoida

Verkkopalvelujen suunnittelijat ymmärtävät hyvin käyttäjätestausten merkityksen: ainoastaan todelliset loppukäyttäjät voivat omasta näkökulmastaan verifioida sen, palveleeko verkkosivusto heidän tarpeitaan. Yhä useammin käyttäjätestaukset otetaan osaksi laadukasta verkkopalvelun uudistusprojektia.

Ongelmana onkin se, millä tavoin testaukset projektoidaan ja aikataulutetaan. Käyttäjätestaus on suhteellisen pitkä prosessi testisuunnittelusta testihenkilöiden rekrytointiin, testien läpiviemiseen ja tulosten tulkintaan. Jos tämä muutaman viikon ajanjakso saadaankin survottua projektiaikatauluun, se asemoituu tavallisesti ylikuormitettuihin ruuhkaviikkoihin ennen julkaisua.

Jos käyttäjätestauksessa sitten paljastuu jokin merkittävä käytettävyysongelma, joka kutoutuu rakenteellisiin ratkaisuihin, toiminnallisuuksiin tai käyttöliittymän esittämistapoihin, on viikkoa ennen julkaisua turhaa yrittää tehdä tälle ongelmalle mitään. Julkaistuksi tulee palvelu, joka tiedetään käytettävyydeltään ongelmalliseksi, ja kaikkia nolottaa. Jotta tältä häpeältä säästäisi itseään,

  • tee käyttäjätestauksia vaiheittain suunnittelun aikana.
  • Jos palvelu käyttäjätestataan kokonaisuutena, varaa myös useampi viikko aikaa reagoida testituloksiin ja korjata palvelua.
  • Tai entä jos kokonaisuuden käyttäjätestaus tehtäisiin julkaisun jälkeen, seuraavien kehittämiskohteiden tunnistamista varten?

5. Vanhoja sisältöjä ei saada siirrettyä

Kun verkkopalvelussa on satoja sivuja erilaisia muuttumattomina pysyviä esittelyitä, tuotetietoja, uutisia, tiedotteita ja julkaisukuvauksia, on terveen sisältösuunnittelijan kysymys tietysti: Ei kai näitä kaikkia tarvitse käsin syöttää uudelleen? Kaikkien teknisten integraattorien vastaus tähän on se, että tietenkin nykyiset sisällöt saadaan siirrettyä ohjelmallisesti uuteen ympäristöön.

Se että sisällöt ”saadaan siirrettyä”, ei kuitenkaan tarkoita että se olisi helppoa, nopeaa ja ongelmatonta. Tavallisesti aina julkaisujärjestelmästä toiseen siirryttäessä myös sisältötyypit muuttuvat: kuhunkin tyyppiluokkaan (vaikkapa ”tiedotteisiin”) kuuluvat sisältödokumentit saavat uusia rakenteistettuja elementtejä, metatietoja, esitystapoja, luokitteluja jne. Tiedotearkiston siirtäminen ”sellaisenaan” uuteen ympäristöön voi vaatia valtavan määrän suunnittelua, sovittamista ja kokeilemista ennen kuin se onnistuu oikein. Ja tämä työ on tehtävä erikseen kaikkia erilaisia sisältötyyppejä varten.

Vaikka vanhan palvelun sisältödokumentit saataisiinkin siirretyiksi uuteen järjestelmään, on niiden sisällöt silti käytävä käsin läpi: sisälinkitykset ovat todennäköisesti rikki, kuvatiedostojen paikat muuttuneet ja tyylimäärittelyt voivat olla vääriä. Ihan jokaista siirrettyä sivua (ja sen kieliversiota) on todennäköisimmin käytävä korjaamassa, muokkaamassa ja määrittelemässä uudelleen. Ja tämä on taas sitä sisällöntuottajan työtä, joka pitäisi tehdä niinä julkaisua edeltävinä viikkoina…

Näistä syistä pistä suunnittelukalenteriin:

  • pari viikkoa vanhojen sisältöjen ohjelmalliseen siirtämiseen
  • pari viikkoa niiden läpikäyntiin ja korjaamiseen
  • ja tuon läpikäynti- ja korjaustyön vaatima aika on siis pois uusien sisältöjen syöttötyöstä

Älä lannistu vastoinkäymisistä

Jos näihin ennakoitaviin yllätyksiin onkin joutunut kipeästi törmäämään – yhteen, pariin tai vaikka kaikkiin – ei pidä jäädä sirottelemaan tuhkaa ylleen: kohtalo on jaettu monessa uudistusprojektissa. Todennäköisesti niistä jää sitäkin vahvempi muistijälki, ja seuraavaa projektisuunnitelmaa varten to do -lista on lähellä täydellistä!

Kaipaatko apuamme uudistusprojektin suunnitteluun?

Kirjoittaja: Virpi Blom

Tietoa kirjoittajasta