Näin laadit sivun tarkoitusbriefin ennen verkkosisällön kirjoittamista

Ennen kuin kukaan kirjoittaa, ehdotuksesta kannattaa hyväksyä yhden sivun päätöstietue, jossa on yhdeksän kenttää: tarkoitettu yleisö, käyttäjän kysymys, sivun rooli, avainviesti, tarvittava näyttö, tavoiteltu toiminta, formaatti, omistaja ja tarkistuspäivä. Ensin ehdotusta verrataan nykyiseen sisältöön ja koko asiointipolkuun. Lopputulos ei ole automaattisesti uusi sivu, vaan päätös voi olla nykyisen sivun päivittäminen, sisältöjen yhdistäminen, uudelleenohjaus, pyynnön hylkääminen tai uuden sivun luominen.

Miksi sivun tarkoitus pitää ratkaista ennen kirjoittamista?

Tarkoitus ratkaistaan ensin, jotta tiimi voi osoittaa todellisen tarpeen, sivun oman tehtävän, väitteiden tarvitseman näytön, tavoitellun tuloksen ja ylläpitovastuun ennen toimeksiantoa. Ehdotettu otsikko, kampanjatoive tai valmiiksi valittu video on vasta ratkaisuehdotus. Jos siitä tehdään suoraan kirjoituspyyntö, kirjoittaja joutuu arvaamaan, kenelle sisältö on tarkoitettu, mihin kysymykseen se vastaa ja miten se liittyy jo julkaistuun aineistoon.

GOV.UK:n julkaisuohjeessa sisällöltä edellytetään perusteltua käyttäjätarvetta sekä käyttäjien, tehtävän, näytön ja hyväksymiskriteerien kirjaamista. Tässä käytetty yhdeksän kentän briefi kokoaa nämä periaatteet, ennakkosuunnittelun ja elinkaaren omistajuuden yhteen käytännölliseen muotoon. Se ei ole virallinen standardi eikä lupaus siitä, että sivu olisi briefin ansiosta löydettävä, saavutettava, virheetön tai tuloksellinen.

Briefi toimii myöhemmin luonnoksen arviointiperusteena: kattaako teksti sovitun kysymyksen, välittääkö se avainviestin ja mahdollistaako se tavoitellun toiminnan? Hyväksytty tietue ei kuitenkaan poista tarvetta käyttäjätutkimukselle, sisältöinventaarille, saavutettavuuden arvioinnille, tekniselle selvitykselle tai faktantarkistukselle. Se tekee näkyväksi, mitä on jo päätetty, mitä pitää vielä tutkia ja kenen on hyväksyttävä ratkaisu ennen julkaisemista.

Mitä tiimin pitää tarkistaa ennen uuden sivun hyväksymistä?

Ennen hyväksymistä tiimin pitää tutkia nykyinen sivusto ja koko asiointipolku saman tarpeen näkökulmasta. Haku ei saa rajoittua samankaltaisiin otsikoihin: mukaan kuuluvat ohjesivut, tukiaineistot, hakemistot, työkalut, lomakkeet, kirjautuneet palvelut ja muut kanavat. GOV.UK-ohjeistus neuvoo tunnistamaan päivitettävän sisällön, puuttuvat tehtävätiedot ja tarpeettomat päällekkäisyydet varhain, ennen kuin uutta sisältöä ryhdytään lisäämään.

• Päivitä, kun nykyinen sivu omistaa jo tarpeen ja sen tehtävä on edelleen oikea.
• Yhdistä, kun useat sivut pirstovat yhden vastauksen tai kilpailevat ensisijaisen lähteen asemasta.
• Ohjaa uudelleen tai poista käytöstä, kun toinen sivu on muuttunut ajantasaiseksi ja ensisijaiseksi.
• Hylkää, kun näytöstä ei synny perusteltua käyttäjätarvetta tai erillistä sivun tehtävää.
• Luo, kun tarve, rooli, näyttö, toiminta, formaatti, omistaja ja tarkistussuunnitelma muodostavat eheän kokonaisuuden.

Samankaltaiset sivut voivat hämärtää, mikä lähde on ajantasainen, ja vaikeuttaa oikean vastauksen paikantamista. Yhdistäminen ei silti ole mekaaninen siivoussääntö. Asiointivaiheessa voidaan tarvita lyhyt muistutus juuri päätöksen kohdalla, vaikka laajempi ohje sijaitsee muualla. Olennaista on erottaa tarkoituksellinen, käyttötilanteeseen sidottu toisto kahdesta keskenään kilpailevasta sivusta, jotka yrittävät omistaa saman vastauksen.

Älä briefaa kirjoittajaa tuottamaan sivua, vaan organisaatiota perustelemaan sivun tehtävä.

Miten tarkoitettu yleisö ja käyttäjän kysymys määritellään?

Tarkoitettu yleisö määritellään sen tehtävän, tilanteen tai tietotason avulla, joka todella muuttaa sivun sisältöä. Ilmaus ”kaikki asiakkaat” ei vielä kerro, mitä lukija tietää, mitä hän yrittää tehdä tai millaista epävarmuutta sivun täytyy poistaa. Yhdellä sivulla voi olla useita läheisiä käyttäjäryhmiä, kunhan niiden tarpeet muodostavat saman johdonmukaisen tehtävän eivätkä vaadi keskenään ristiriitaisia vastauksia.

Käyttäjän kysymys kirjoitetaan keskeiseksi, tunnistettavaksi kysymykseksi tai tehtäväksi ja sidotaan näyttöön. Aineistoa voivat olla analytiikka, asiakaspalvelun yhteydenotot, aiempi käyttäjätutkimus ja relevantti ulkoinen tieto. Yksittäinen käyntiluku ei kuitenkaan osoita, miksi sivulle tullaan tai löytyikö vastaus. Työnimi, johtoryhmän toive tai pyyntö tehdä video kertoo ehdotetusta ratkaisusta, ei vielä käyttäjän tarpeesta.

Hyvä määrittely voi olla esimerkiksi ”asiakasorganisaation pääkäyttäjä, joka valmistelee tuetun integraation käyttöönottoa” ja ”mitä minun on varmistettava ennen määritysten aloittamista?”. Kysymys saa sisältää läheisiä alakysymyksiä, kuten käyttöoikeudet ja yhteensopivuuden, jos ne kuuluvat samaan valmistautumistehtävään. Kanadan sisältötyyliohjeen periaatteen mukaisesti sisältö rakennetaan tarkoitetulle yleisölle ja keskitetään sen päätehtävään.

Miten sivun rooli, avainviesti ja tarvittava näyttö tukevat toisiaan?

Sivun rooli, avainviesti ja tarvittava näyttö muodostavat ketjun: rooli kertoo sivun ainutlaatuisen työn, avainviesti sen olennaisen johtopäätöksen ja näyttö perustan, jolla johtopäätös voidaan julkaista. Roolia ei kannata kuvata muodolla, kuten ”tietosivu”, vaan polulla tehtävällä työllä. Briefissä pitää myös perustella, miksi nykyinen sivu, työkalu, asiointitoiminto tai toinen kanava ei hoida samaa työtä paremmin.

Integraatiota koskeva tukisivu voi esimerkiksi selittää ennakkoehdot ennen kuin pääkäyttäjä avaa määritystyökalun. Sivun avainviesti on, että käyttöoikeudet, yhteensopivuus ja tarvittavat tiedot on varmistettava ensin. Työkalu puolestaan käsittelee varsinaiset asetukset. Tätä eroa tukee GOV.UK:n palveluohje, jonka mukaan ohjeilla ja asiointitoiminnoilla on eri tehtävät ja tieto pitäisi sijoittaa siihen kohtaan polkua, jossa sitä tarvitaan.

Tarvittava näyttö kattaa kaksi eri asiaa: aineiston, joka osoittaa sivun tarpeen, sekä lähteet ja varmennukset, joilla sivun väitteet voidaan perustella. Avainviestin olennainen sisältö sijoitetaan ennen tukevia yksityiskohtia. Julkaisuvaiheessa sitä verrataan sivun otsikkoon, pääotsikkoon ja aloitukseen. WCAG-kriteeri 2.4.2 edellyttää aihetta tai tarkoitusta kuvaavaa sivuotsikkoa, mutta tämä yksittäinen tarkistus ei vielä osoita saavutettavuuden kokonaisuutta.

Miten tavoiteltu toiminta ohjaa sisältömuodon valintaa?

Tavoiteltu toiminta määrittää, mitä yleisön pitää pystyä päättämään, tekemään, vertaamaan, paikantamaan, ymmärtämään tai saavuttamaan seuraavaksi sivun käytön jälkeen. Se toimii käytännöllisenä hyväksymisehtona: valmista sisältöä voidaan arvioida sovittua tulosta vasten. Toiminnan ei tarvitse olla yhteydenottolomake, myyntiliidi tai ostos. Päätöksen lykkääminen perustellusti tai oikean tukireitin löytäminen voi olla aivan yhtä merkityksellinen lopputulos.

Formaatti valitaan vasta, kun tarve, rooli ja tavoiteltu toiminta ovat selvät. Vaihtoehtona voi olla ohje, vertailu, hakuteos, selite, tarkistuslista, video, asiointivaihe tai työkalu, mutta lähteet eivät tarjoa yrityssivustoille yleispätevää formaattitaksonomiaa. Jos tehtävä ratkeaa paremmin työkalun muutoksella, asioinnin selkeyttämisellä tai muussa kanavassa, briefiin kirjataan tämä päätös sen sijaan, että tarve pakotettaisiin uudeksi sivuksi.

Formaattia voi testata kysymällä, mitä käyttäjän pitää havaita ja tehdä sekä missä tilanteessa sisältöä käytetään. Pitkä selite on heikko valinta, jos käyttäjä tarvitsee vain nopeasti tarkistettavat ennakkoehdot työkalun vieressä. Video voi täydentää vaikeasti kuvattavaa vaihetta, mutta ennakkoon pyydetty video ei itsessään todista tarvetta. Valinta on perusteltava käyttäjän tehtävällä, tietotasolla, polun kohdalla ja sisällön ylläpidettävyydellä.

Kuka omistaa sivun, ja milloin se tarkistetaan?

Sivulle nimetään yksi henkilö tai tiimi, joka vastaa sen paikkansapitävyydestä ja ylläpidosta. Omistaja ei kuitenkaan tee yksin kaikkea työtä. Sisällöntuottajat, aiheasiantuntijat, hyväksyjät, saavutettavuusasiantuntijat, juristit, sääntelyn tuntijat ja tekniset toteuttajat kirjataan erillisiin tehtäviin tarpeen mukaan. Digital.gov kuvaa sisällön hallinnan koko elinkaarena, jossa omistajuus, asiantuntijavarmennus ja hyväksyntä ovat erillisiä osia luomisesta ylläpitoon ja poistamiseen.

Tarkistuspäivä asetetaan tunnettujen muutosten, sisällön vaihtelevuuden, riskin, käytettävissä olevan näytön ja organisaation sitoumusten perusteella. Kaikille sivuille ei pidä määrätä samaa vuosittaista tai neljännesvuosittaista rytmiä. Päivän yhteyteen kannattaa kirjata myös laukaisin, kuten tuoteversion julkaisu, sopimusehdon muutos tai omistavan tiimin vaihtuminen. GOV.UK-ohjeistus tukee tarkistusten seurantaa ja myöhempiä päivitys-, korjaus- tai poistopäätöksiä, mutta ei yhtä yleistä tarkistusväliä.

Tarkistuspiste muuttaa epämääräisen ylläpitolupauksen ajoitetuksi työksi, mutta kalenterimerkintä ei takaa toteutusta. Briefissä on siksi varmistettava, että omistaja hyväksyy vastuun ja tietää, mistä muutossignaalit tulevat. Tarkistuksessa ei kysytä vain, ovatko sanat vanhentuneet. Samalla voidaan päättää korjata sivu, yhdistää se toiseen, vaihtaa ensisijainen lähde, tehdä uudelleenohjaus tai poistaa sisältö hallitusti käytöstä.

Miltä valmis yhdeksän kentän briefi näyttää?

Valmis briefi on tiivis päätöstietue, jonka jokainen kenttä tukee samaa ratkaisua ja jonka oletukset on erotettu varmennetusta tiedosta. Seuraava kuvitteellinen esimerkki koskee yritysasiakkaiden tukisisältöä. Esimerkki ei väitä mitään kävijämäärästä, tehtävän läpäisystä, konversiosta, tuotannon nopeudesta tai kustannussäästöstä. Todellisen organisaation pitää korvata esimerkin oletukset omalla käyttäjä-, tuote- ja tukiaineistollaan.

Täytetty esimerkki

• Tarkoitettu yleisö: asiakasorganisaation pääkäyttäjät, jotka valmistautuvat tuetun integraation määritykseen.
• Käyttäjän kysymys: mitä minun on varmistettava ennen määritysten aloittamista?
• Sivun rooli: ennakkoehdot selittävä ohje ennen varsinaiseen määritystyökaluun siirtymistä.
• Avainviesti: varmista käyttöoikeudet, yhteensopivuus ja tarvittavat tiedot ennen aloittamista.
• Tarvittava näyttö: ajantasainen tuotedokumentaatio, kysymyksen osoittavat tukitiedot ja vastuullisen tuoteasiantuntijan varmennus.
• Tavoiteltu toiminta: päätä, onko organisaatio valmis, ja siirry oikeaan työkaluun tai tukikanavaan.
• Formaatti: tiivis ohje, jonka yhteydessä on ennakkoehtojen tarkistuslista.
• Omistaja: tuotetuen sisältötiimi sekä erikseen nimetyt tuote- ja saavutettavuustarkastajat.
• Tarkistuspäivä: seuraava sovittu tarkistuspiste, joka on sidottu dokumentoituun tuotejulkaisun laukaisimeen.

Ennen kirjoitustehtävän hyväksymistä sidosryhmien pitää pystyä osoittamaan näyttö yleisöstä ja kysymyksestä, perustelemaan valittu päätös ja sivun erillinen rooli sekä nimeämään avainviestin tarvitsema todistusaineisto. Lisäksi heidän pitää kuvata merkityksellinen seuraava tulos, puolustaa formaattivalintaa, nimetä vastuullinen omistaja ja sitoutua sekä tarkistuksen laukaisimeen että päivään. Jos jokin olennainen vastaus jää unsupporteduksi tai ristiriitaiseksi, pyyntö palautetaan tutkimukseen tai korjattavaksi.

Kirjoittaminen kannattaa käynnistää vasta, kun tarve, viidestä vaihtoehdosta valittu päätös, kaikki yhdeksän kenttää ja elinkaaren vastuu tukevat toisiaan. Omistaja koordinoi työn, mutta ei korvaa pätevää saavutettavuuden, juridiikan, sääntelyn, tekniikan, datan tai aihealueen asiantuntijaa. Tarvittavat ammattilaiset otetaan mukaan silloin, kun sivun väitteet, velvoitteet tai toteutusratkaisut edellyttävät heidän harkintaansa.