Johdanto                 Tiivistelmä       Tutkimusmenetelmät
1. Web-käytettävyys      2. Web-tuotanto   3. CASE-kuvaukset
4. Heuristinen arviointi 5. Raatiarviointi 6. Yhteenveto
7. Käytettävyyden tila   Lähteet           Liitteet

3.3. Verkkoliitteen tuotantokuvaus

Kaavio Verkkoliitteen tuotantoprosessista

Helsingin Sanomain Verkkoliite on verkkojulkaisupalvelu, joka sisältää paperiversion ja verkkotoimituksen omaa toimituksellista sekä ilmoituksellista aineistoa. Palvelun tarkoitus on tarjota sähköinen versio Helsingin Sanomista sen tilaajille ja sen kohderyhmänä on kaikki Helsingin Sanomien tilaajat verkkokäyttökokemuksesta riippumatta. Palvelun oletettu käyttö on aamulla ennen töihin lähtöä (päivän uutiset), töissä tauolla tai päivän päätteeksi (päivän uutiset, erikoistapahtumat) ja kotona töiden jälkeen (erikoistapahtumat, viihdepalvelut).

Palvelu sisältää muun muassa pääuutiset ja -artikkelit paperiversion osioista (kuten Kotimaa, Kulttuuri), Verkkoliitteen toimituksen tuottaman Klik!- verkkoliitteen, paperisen NYT-liitteen artikkeleita sekä ilmoituksellista aineistoa.

Palvelun kartoitus käynnistyi kesällä 1995. Versio 1.0 - ja tutkittava tuotantoprosessi - julkistettiin toukokuussa 1996. Ensimmäisen version pääpaino oli nopeudessa ja luotettavuudessa (sen aikaiset kotimodeeminopeudet olivat 2-4 kertaa nykyisiä hitaampia). Tämän jälkeen palvelu on uusittu vuosittain: versiossa 2.0 (kevät 1997) uudistettiin lähes koko ulkoasu ja versiossa 3.0 pääsivu (kevät 1998) muine hienosäätöineen.

Vapaan aikataulun vuoksi projekti toteutui rinnakkaisvaiheina tai sykleittäin, joissa edettiin osin yhtäaikaa kartoituksen, suunnittelun, tuotannon ja testauksen osalta. Prosessin kuvauksen kannalta eri vaiheita on vaikea erottaa toisistaan niiden päällekkäisyyden takia. Monet tekijöistä toimivat myös monissa eri rooleissa ja eri prosesseissa, mikä on tyypillistä juuri web- palveluiden alkuvaiheessa. Tähän tutkimukseen on valittu tuotantoprosessi 1995-96 kartoituksesta ensimmäisen version julkistukseen, rajattuna kuitenkin palvelun journalistisen sisällön osioihin (uutiset, Nyt, Klik) palvelukokonaisuuden laajuuden takia.

Lanseeraus suoritettiin Suomen mittakaavassa massiivisesti. Helsingin Sanomat painatti 50 000 kpl romppuja, joille oli lisensioitu, suomennettu ja räätälöity Netscape-selain. Paperiversion tilaajille tarjottiin mahdollisuus saada maksutta romppu ja ilmainen rekisteröintitunnus verkkopalveluun.

Tavoitteet

Tuotantoryhmälle ja muodostettavalle verkkotoimitukselle annettiin varsin vapaat kädet kesällä 1995 sekä riittävät resurssit luoda omalla aikataululla Verkkoliite. Tavoitteena oli luoda paperiversion rinnalle päivittäinen elämänhallintapalvelu, josta selviäisi uutisten lisäksi tapahtumat, elokuvat ja sää. Palvelun osaksi suunniteltiin myös artikkeliarkisto. Alkuvaiheen sisällöllinen pohja olisi lehtiaineistossa, mutta alusta alkaen olisi myös verkkotoimituksen omaa tuotantoa. Tavoitteet elivät palvelun toteutuksen yhteydessä ja muokkaantuivat hiljalleen nykymuotoonsa: Helsingin Sanomien lukijoiden palveleminen uutis- ja tietopalveluilla web:n avulla.

Palvelun lähtökohtana oli tukeutuminen HS:n paperiversion perinteisiin eli laatu, luotettavuus ja tunnettuus. Paperiversio vaikutti myös palvelun jäsentelyyn. Lisäksi reunaehtona oli, että palvelu on maksuton, mutta on saatavilla vain paperiversion tilaajille. Palvelun tehtävä hahmotettiin mielikuvamarkkinoinniksi sekä tuotemarkkinoinniksi osana HS:n tuotemerkkiä.

Kartoitus

Palvelua kartoitettiin omakohtaisella vertailulla olemassa olevista vastaavista palveluista sekä vielä markkinatutkimuksella toukokuussa 1996, kuukautta ennen lanseerausta. Siinä kehitettävää palvelua näytettiin videolla ja haastateltiin vastaajia. Tämän myötä selvisi, että pääpaino olisi uutisissa sekä nuorisoaiheiden huomioinnissa. Lisäksi käyttöliittymää selkiytettiin ja sähköinen menokalenteri havaittiin tarpeelliseksi. Kohderyhmäksi rajattiin kaikki suomalaiset Helsingin Sanomien päivälehden tilaajat, erityisesti 18-24- vuotiaat HS:n NYT-liitteen lukijat.

Palvelu päätettiin toteuttaa sisällöllisesti omatuotantona (in-house). Järjestelmä- ja verkko- osaaminen päätettiin hankkia ulkopuolelta ja osin ulkomailta selaimen lisensioinnin yhteydessä . Selaimista päätettiin tukea Netscape 2.0:aa, joka kartoituksen aikaan oli eräänlainen de facto standardi. Tavoitteena oli myös luoda huomattavasti kehittyneempi ja automatisoidumpi sähköinen toimitusjärjestelmä, kuin mitä paperiversion tuottamisessa käytettiin.

Tuotantoryhmän koostumus oli

  • kehittämispäällikkö
  • kaksi projektivetäjää
  • toimitussihteeri
  • tekninen vastaava
  • toimittaja / koodaaja
  • toimittaja
  • graafikko

Suunnittelu ja toteutus

Projektin läpiviennille ei päätetty tiukkaa mallia, koska palveluun haluttiin edetä kokeilun kautta ja tuotantoryhmällä oli mahdollisuus itse päättää palvelun julkistuspäivä. Avoimen aikataulun myötä palvelua luotiin osin rinnakkaisella kartoituksella, suunnittelulla ja toteutuksella.

Hanke käynnistyi 1995 kesällä ja seuraavan kesän Atlantan olympialaisia ajateltiin "hyväksi tilanteeksi näyttää" eli tarjota tällöin toimiva palvelu. Suunnitteluryhmän tapaamiskäytännöksi vakiintui säännölliset viikkokokoukset ideointeineen. Ideoita testattiin muun muassa visualistilla ja teknisellä vastaavalla, joiden palaute otettiin jatkokehittelyyn seuraavaan kokoukseen. Alussa ei ollut mitään kiteytymää, mihin tähdättiin, vaan palvelu lopulta "tuli palikka kerrallaan". Resursseja tarvittiin kaikilla tuotannon osa-alueilla arvioitua enemmän.

Verkkoliitteen suunnittelu- ja osittain myös kartoitusvaihe muistuttavat läheisesti spiraalimallia, toistuvine ideointi- arviointi-analysointi-sykleineen. Spiraalimalli soveltuu usein vesiputousmallia paremmin projekteihin, jossa ei alusta saakka ole selvillä mitä tehdään, millä tavalla ja kenelle. Design-prosesseille on usein tyypillistä, että ratkaisun työstäminen auttaa hahmottamaan paremmin ongelmaa, mikä puolestaan määrää tarkemmin ratkaisun suuntaa.
Suunnittelu eteni leiskojen ja protojen kautta. Lisäksi tehtiin itsenäisesti toimiva prototyyppi lanseerauksessa jaettavaa romppua. Ideoiden visualisointi ja toteutus leiskoiksi koettiin työskentelyä ja ideoita selkiyttäviksi.
Leiskojen käytti edellytti graafikolta usein jo alkuvaiheessa paljon suunnitteluongelmien ratkaisemista, mutta asioiden lukkoonlyönnin jälkeen eteneminen oli nopeaa, koska osa suunnittelutyöstä oltiin jo tehty. Leiskoja käytettiin siis tavallista syvempinä suunnitteluvälineinä eikä vain visuaalisen ilmeen tai teeman hahmottamiseen: leiskoja testattiin jo ennen toiminnallisuuden toteutusta miettimällä kuinka palvelua käytettäisiin. Myöhemmin samat leiskat hioutuivat osaksi palvelun toiminnallista prototyyppiä ja tämän jälkeen pilottipalvelua.
Sisällön organisoinnin hahmottamisessa käytettiin sivustokaaviota, joka on yleinen hahmotustapa. Kaaviota testattiin myös haastateltavilla keväällä 1996. Tuotantoryhmälle jäi vaikutelma, että "käyttäjiltä on hyvä kysyä, mutta ei kuitenkaan antaa päätäntävaltaa" suunnitteluun liittyvissä kysymyksissä.
Sivukaavio hahmotettiin hierarkkisen mallin mukaisesti, vaikka web-palvelut harvoin noudattavat tätä mallia lopulta käytännössä. Hierarkkinen sivukuvasto on usein ongelmallinen, koska se voi johtaa ajattelemaan palvelun rakennetta esim. yrityksen rakenteen (yleensä hierarkkisesti kuvattuja) kautta. Käytäntö on myös osoittanut, että vaikka suunnittelijat organisoivat web-sivuja hierarkkisesti, niin käyttäjät kokevat niitä lineaarisina jatkumoina: suunnittelijoiden luoma kaavio tai kartta ei siis välity sellaisenaan käyttäjille, vaikka rakenne olisi kuinka hyvin määritelty (tähän viite hierarkkisen ja lineaarisen kokemuksesta).
Informaatioarkkitehtuurin suunnittelussa ei käytetty tutkimuksia tai jaotteluita vaan hyvin yleistä käytännön vertailua olemassa olevista palveluista. Tuotantoryhmän lähestymistapa oli, että "on jenkit nää tutkinu." eli oletettiin että amerikkalaiset web-julkaisut olisivat hyödyntäneet alan tutkimusta omissa hankkeissaan Samoihin aikoihin palvelun kanssa keväällä 1996 lanseerattiin Kauppalehden sekä Aamulehden verkkoversiot. Tätä ennen webissä oli ollut vain Iltalehti Online, joten muita kotimaisia laajoja, päivittäisiä web-julkaisuja ei ollut vertailukohtina.
Vertailussa noudatettiin löyhästi benchmarking- ajattelua, jossa saman toimialan ratkaisujen kautta pyrittiin hahmottamaan omaa ratkaisua. Vertailua ei kuitenkaan laajennettu yli toimialojen tai suoritettu vertailutaulukon avulla. Parhaita ratkaisuja hyödyntävää best practises -analyysiä ei myöskään suoritettu.
Alkuvaiheessa kokonaisuutta lähdettiin hahmottamaan hakemiston ja navigointinappien avulla, kartta-metaforan pysyessä taustalla. Hakemisto päätettiin toteuttaa hierarkkisena, valitsemalla päivälehden paperiversion osastot päähierarkiaksi. Lisäksi palveluun haluttiin tarjota navigoinnin tueksi palvelun sisäinen haku ja erillinen palautekanava. Pyrkimyksenä oli huomioida erilaisia käyttäjätyyppejä ja tilanteita, niin että jokainen käyttäjä voisi itse valita haluamansa etenemistavan sisällössä.
Palvelulle ei valittu mitään tietoista metaforaa, vaikka esimerkiksi kansio- ja paperivertauskuvien mahdollisuus tutkittiin. Käytännössä palvelun rakenne on kuitenkin hyvin päivälehden oloinen ja voidaankin sanoa tämän toimineen suunnittelullisena metaforana, vaikka se ei aina näy käyttöliittymässä kovin konkreettisesti.
Visuaalista ja käyttöliittymäsuunnittelua ei erotettu toisistaan. Hakemiston osastoissa haluttiin ottaa käyttöön vahvat värit, jotta palvelu olisi tunnistettavissa yhdellä vilkaisulla.
Visuaalisessa toteutuksessa tuotteen identiteetin hahmottaminen nousi siis informaatiokoodausta tärkeämmäksi, ainakin värien valinnassa.
Päänavigointi päätettiin laittaa oikealle, koska länsimainen lukusuunta on vasemmalta oikealle. Pääasia eli uutiset sijoitettiin ruudun vasemmalle reunalle. Käytännössä toteutus oli kuitenkin vaikeampi koodata ja huomattiin nopeasti vaikeammaksi kuin navigaation sijoittaminen vasemmalla puolelle. Ratkaisua ei kuitenkaan muutettu. Osastokohtainen alahakemisto sijoitettiin uutisen yläpuolelle sekä sivun loppuun uutisen jälkeen. Kokonaisuus luotiin "vaistolla", "fiiliksellä" ja "mutu"-menetelmällä. Muodollista käyttäjätestausta tai heuristista analysointia ei suoritettu.

Ruutukoko suunniteltiin 640 x 480 pikselin näytöille ja tälle alueelle haluttiin uutinen aktiivisesti näkyväksi heti sivun latauduttua. Tärkeintä oli, että oleellinen sisältö näkyisi yhdellä silmäyksellä, ilman tarvetta näytön vierittämiseen selaimessa.

Sisällön lähtökohtana oli paperiversion aineisto. Sieltä päätettiin tuoda paitsi uutisia ja artikkeleita (80-100 kpl päivittäin), niin myös luokiteltuja ilmoituksia, kuten asunnot, autot ja työpaikat sekä NYT-liitteestä valittuja osia, kuten 1-2 viikottaista artikkelia sekä NYT TEN- ja Mitä nyt? -palstat.

Tuotantoryhmä ryhtyi alusta alkaen tuottamaan Klik!-osiota, joka olisi tuotantoryhmän "omaa" tuotantoa. Tavoitteena oli tuottaa kerran kuukaudessa laaja paketti, jossa olisi 15-20 dokumenttia tai "sivua" sekä artikkeleja kymmenisen kappaletta kuukaudessa. Sisältö päätettiin tuottaa verkkotoimituksen sekä muutaman avustajan voimin.

Version 1 suunnitteluvaiheessa talvella 1996 pyrittiin mahdollisimman suureen automaatioon sekä paperiversion toimitusjärjestelmän integroimiseen. Toimitusjärjestelmän automatisoinnissa ilmeni kuitenkin sen toimittajista johtuvia ongelmia. Ne laskivat palvelun päivittäisen pyörittämisen käytettävyyttä, koska asioita jouduttiin tekemään kiertoteitse. Myös osa palvelun toiminnoista (kuten haut) olivat hankalia toteuttaa.

Teknisessä suunnittelussa jouduttiin hylkäämään monia ideoita. Ajankohta kevät 1996 oli selaimien teknisten rajoitteiden vuoksi liian varhainen esimerkiksi sähköpostikortille, johon voisi itse piirtää. Se saatiin toimimaan, mutta ei kaikilla selaimilla versioineen. Ylipäänsä web-teknologia koettiin palvelun kehittämistä rajoittavaksi. Esimerkiksi myöhemmin Naganon olympiakisojen aikaan kevättalvella 1998 reaaliaikainen keskustelukanava meni tukkoon viisi minuuttia ennen Suomi-Kanada pronssiottelun loppua.

Päivälehden aineisto saatiin digitaalisesti ja se muutettiin automatisoidusti HTML-tiedostoiksi, joihin koodataan käsin web-elementit. Muokattu aineisto siirretään päivityspalvelimelle, josta varsinainen palvelin päivittyy automaattisesti Netscapen sovelluksella Editor’s Workbench. Palvelimena käytettiin Sun Solarista ja ohjelmistona Netscapen Publishing & Community Serveriä. Web-sivut päätettiin toteuttaa HTML-versiolla 2, mikä oli luonnollinen ratkaisu ajankohta huomioonottaen.

Ohjelmointiin käytettiin C++:aa sekä Oraclea, koodaukseen Windowsin NotePadia ja Arachnophiliaa. Sisältö tuotettiin pääasiassa Macintoshilla, koska "PC:llä ei pystynyt tekemään kunnon grafiikkaa". Ulkoasu suunniteltiin Adobe Illustratorilla ja grafiikka tuotettiin niinikään Illustratorilla sekä Photoshopilla ja Studio Prolla. Multimediaelementit koostettiin Adoben Premierella ja animaatiot GIFBuilderilla sekä Elastic Realitylla. Tiedostot siirrettiin WS-FTP:llä, web-selaimen FTP-ominaisuudella sekä Macintoshin Fetchillä. Viestintään käytettiin MS Exchangea ja sivuston hallintaan selainta sekä palvelinohjelmaa.

Työkalut kuvaavat hyvin alalle luonteista useiden kymmenien erilaisten ja eriytyneiden työkalujen valikoimaa, joista työryhmät itse rakentavat työn kuviinsa sopivat apuvälineet. Minkäänlaisia kokonaisvaltaisia ratkaisuja palvelun sisällön, ulkoasun tai muun ylläpidon luomisessa tai pyörittämisessä ei siis käytetty. Prosessin ajankohta huomioiden kaupallisia sovelluksia ei juuri edes ollut markkinollla. Sittemmin markkinoille on ilmaantunut ohjelmistoja sekä graafisen työskentelyn (kuten NetObjects TeamBuilder) ja sisältötuotannon prosessien hallitsemiseksi (kuten Vignette StoryServer).

Testaus

Teknisen testauksen lisäksi vaihe sisälsi muun muassa Marketing Radarin toteuttaman ensireaktio- ja sisältötestauksen kuukautta ennen julkistusta. Muodollista palvelun käyttöliittymäarviointia tai käytettävyystestausta ei tehty, joskin palvelua koekäytettiin talon sisällä ja näytettiin suunnitteluryhmän ulkopuolisille ennen julkistusta.

Projektin aikana Netscapen tai Explorerin selainversiota 3 ei ollut vielä olemassa vaan Netscape 2.0-selain oli de facto standardi. Muiden tutkittujen projektien tapaan myöhemmissä testauksissa osoittautui ongelmaksi Netscapen, Explorerin ja standardien mukaisen HTML-kielen välinen epäyhteensopivuus. Osa testauksesta jäi ja haluttiinkin jättää käyttäjille palvelun avautumisen jälkeen, koska todettiin täydellisen testauksen olevan mahdotonta. Virheitä pyrittiin sitten korjaamaan resurssien mukaan sitä mukaa, kun niitä tuli ilmi.

Verkkoliitteen testauksessa ei myöskään tehty kuormitus- tai skaalautumistestiä ja palvelu tukkeutuikin välittömästi heti avautumisen jälkeisinä minuutteina. Verkkoyhteyden nopeuttaminen ratkaisi kuitenkin pahimman pullonkaulan, eikä alun yllättävästä kuormituksesta ollut kuin hetkellinen haitta. Palvelun toiminnan kannalta oli kuitenkin tärkeää, että ylikuormaan pystyttiin reagoimaan nopeasti, vaikka sitä ei oltu suunniteltu alusta lähtien.
Internet-teknologioiden nopea kehitys näkyi projektin aikana lähinnä siinä, että tekstipohjaiselle Lynx-selaimelle saatiin väritetyt sivut. Projektiryhmä totesikin palvelun syklisen ja rinnakkaisen kehitysajan olleen niin pitkä, että testauksen osalta palvelun ongelmakohdat hioutuivat pois jatkuvassa kehityksessä.

Julkistus

Palvelun lanseeraus toukokuussa 1996 oli yksi Suomen laajimpia. Helsingin Sanomain tilaajia varten valmistettiin 50 000 romppua, jotka sisälsivät palvelua varten räätälöidyn suomenkielisen Netscapen selainversion käyttöohjeineen ja navigointikarttoineen. Paperiversiossa julkaistiin kokosivuja käsittävä kampanja, jossa Verkkoliitteeseen oli tutustumassa tavallisia ihmisiä, kuten siivoojia. Kampanja päätavoite oli viestittää, että Helsingin Sanomat oli siirtynyt internet-aikaan.

Julkistusvaiheen ainoa yllätys oli, että verkkoyhteyden ja palvelintilan tarjoajalla "ei kestänyt vehkeet". Palvelin tukkiutui ja kaistaleveys piti nelinkertaistaa julkistuspäivänä. Tekniikka oli laskettu 50 000 käyttäjän tarpeisiin, mutta hetkellinen kuorma ylitti luokituksen.

Maksimikapasiteetin lähellä toimiessaan web-palvelu joutuukin usein helposti noidankierteeseen, jossa palvelu hidastuu ja käyttäjät yrittävät ladata saman sivun uudestaan, mikä puolestaan hidastaa palvelua lisää. Maksimikäyttäjämäärät olettavatkin usein, että kaikki käyttävät palvelu "normaalisti", käynnistäen hallittavan määrän tiedonsiirto- ja laskentaprosesseja palvelussa. Ruuhkatilanteissa normaalikäytön ajatus ei kuitenkaan enää päde ja palvelu tarvitsee helposti kaksi- tai jopa nelinkertaisen kapasiteetin pystyäkseen palvelemaan tyydyttävästi.
Julkistuksen jälkeinen palaute oli projektiryhmän odotusten mukaista. Kehujen määrä jopa ylitti odotukset. Lisäksi palaute on sisältänyt ehdotuksia uusista palveluista sekä HTML-korjauksia. Verkkoliite on toiminut käytännössä myös paperituotteiden sähköpostikeskuksena, josta viestit on ohjattu yksittäisille toimittajille, jotka ovat jatkaneet keskustelua lukijoiden kassa. Yleisin kriittinen palaute on kohdistunut palvelun saatavuuteen vain paperiversion tilaajalle täyteen tilaushintaan.

Myös palvelun ulkoasu ja käyttöliittymä sai runsaasti kommentteja. Kiittävän palautteen lisäksi projektiryhmää "opastettiin miten kannattaisi tehdä". Sisältötuotannossa ollaan harkittu käytön seurannan perusteella uutistaustojen sekä paikallisuutisten tuottamista. Ne ovat kuitenkin huomattu liian kalliiksi suhteessa käyttöön.

Tuotantoryhmä pitää palautekanavaa hyvänä, jatkuvana osviittana mihin suuntaan on kehityspaineita, kuten säätietojen julkaiseminen. Nykyisellään lukijapalautetta tulee 200 - 300 viestiä kuukaudessa.

Projektiseurannasta vastasi yrityksen johto sekä seurantaryhmä, mutta käytännössä projektiryhmä toimi hyvin itsenäisesti.

Ylläpito

Ylläpito on ollut kolmen päällekkäisen prosessin yhdistelmä: palveluun tuotetaan koko ajan lisäsisältöä, siihen kehitetään lisäominaisuuksia ja korjataan vanhoja ja itse palvelua pidetään pyörimässä. Näistä viimeinen, jatkuva palvelun saatavuuden takaaminen, on ulkoa hankittu palvelu. Sisältöprosessissa mukana olevat työntekijät ovat usein myös mukana itse palvelun konseptin ja toimintojen kehittämisessä.

Seurannan myötä palvelulle on löytynyt yksi kohderyhmä, ulkosuomalaiset.

Seurannassa havaittiin rekisteröitymislomakkeen myötä toinen suuri käyttäjäryhmä: 9-vuotiaat naispuoliset yritysjohtajat. Tämä selittyi lomakkeen perusoletuksilla, jotka ilman muutoksia hyväksymällä tuottivat eriskummallisen käyttäjäprofiilin. Käyttäjät eivät siis olleet halukkaita antamaan itsestään tietoja kovin aktiivisesti. Rekisteröityvän käyttäjän profiililomake poistettiinkin, koska sen avulla kerätty tieto koettiin enemmän virheelliseksi kuin hyödylliseksi.

Jatkokehitys

Saadun käyttäjäpalautteen perusteella on jo toteutettu joitain palvelun uudistuksia (nopeampi yhteys, muutoksia selainyhteensopivuudessa) ja lisäksi harkitaan palvelun tarjoamista erillisenä palveluna Helsingin Sanomien päivälehdestä.

Valittu julkaisujärjestelmä sen aikaiselta markkinajohtajalta (1995-96) ei ole täyttänyt odotuksia ja se aiotaan vaihtaa toiseksi, muokaten mahdollisesti samalla sisällön tuotantoprosessia. Arkiston hakujärjestelmä ei niinikään ole täyttänyt odotuksia ja sitä haluttaisiin jatkokehittää.

Tuotantoryhmän arvioita palvelun käytettävyydestä

Tuotantoryhmä itse pitää palvelua kohtuullisen helppokäyttöisenä, perustuen pitkälti sen päivälehdestä lainattuun uutisjakoon. Sivustoa pidetään myös nopeasti latautuvana erikoissisältöjä, kuten Klik, lukuun ottamatta. Vähiten tuotantoryhmä on ollut tyytyväinen ylläpidossa ja tuotannossa käytettyihin työkaluihin, jotka eivät ole täyttäneet niille asetettuja vaatimuksia. Palvelun toimeksiantajat ovat olleet tyytyväisiä syntyneeseen palveluun.

Tuotantoryhmä on tiedostanut, että palvelusta olisi syytä toteuttaa muodollinen käytettävyystestaus ja jatkokehittää käyttöliittymää tämän perusteella. Toistaiseksi palveluksia ovat kuitenkin tarjonneet vain mainostoimistot, joiden osaamisesta käytettävyysalueella ei olla vakuuttuneita.

Sisällysluettelo

3.2 Tilastokeskuksen tuotantokuvaus        4. Heuristinen arviointi