Driv nettet som et forretningssystem.
Innholdsstrategi for nettsteder
Bruk en formålsbrief med ni felt til å prøve behovet, velge riktig innholdsbeslutning og gi skribenten et tydelig produksjonsoppdrag.
WebChorus Editorial Team8 min lesetid
Før noen skriver, bør teamet godkjenne en kort formålsbrief med ni felt: tiltenkt målgruppe, brukerspørsmål, siderolle, hovedbudskap, nødvendig dokumentasjon, ønsket handling, format, eier og gjennomgangsdato. Sammenlign først forslaget med eksisterende sider, verktøy, transaksjoner og andre kontaktpunkter. Beslutningen kan da bli å oppdatere, slå sammen, omdirigere, avslå eller opprette. En bestilling med arbeidstittel og ønsket format er derfor et forslag til løsning, ikke automatisk et skriveoppdrag.
Kort fortalt
Formålet må avgjøres først fordi teamet trenger et gyldig behov, en egen rolle, dokumentasjonskrav, et ønsket utfall og et vedlikeholdsansvar før bestillingen behandles som tekstproduksjon. Ellers må skribenten gjette hvem siden er for, hvilket spørsmål den skal løse, hva påstandene skal bygge på, og hvordan siden henger sammen med resten av brukerforløpet. Resultatet kan bli en tekst med flere mulige retninger eller enda en side som konkurrerer med et eksisterende svar.
GOV.UKs publiseringsveiledning knytter publisert innhold til et gyldig brukerbehov og ber team registrere sannsynlige brukere, oppgaven deres, bevis og akseptansekriterier. Nifeltsbriefen nedenfor er en praktisk redaksjonell sammenstilling av slike prinsipper for behov, planlegging og livsløp; den er ikke en offisiell standard fra kildene. Den gir interessentene et felles beslutningsgrunnlag og gir senere et konkret utgangspunkt for å vurdere utkastet.
| Felt | Kort skriveprompt | Godkjenningskontroll |
|---|---|---|
| Tiltenkt målgruppe | Beskriv mennesker gjennom oppgaven, situasjonen eller forkunnskapen som påvirker innholdet. | Er avgrensningen konkret nok til å styre språk, detaljnivå og innhold? |
| Brukerspørsmål | Formuler det sentrale dokumenterte spørsmålet eller oppgaven med målgruppens ord. | Finnes det bevis for behovet, og kan én sammenhengende leveranse møte det? |
| Siderolle | Forklar sidens unike oppgave i brukerforløpet. | Er det tydelig hvorfor en eksisterende side, et verktøy eller en annen kanal ikke gjør jobben bedre? |
| Hovedbudskap | Skriv konklusjonen eller poenget målgruppen først må forstå. | Kan budskapet gjenkjennes i den planlagte tittelen, hovedoverskriften og åpningen? |
| Nødvendig dokumentasjon | Oppgi både behovsbevis og kilder, data eller fagkontroller for sidens påstander. | Er dokumentasjonen aktuell, relevant og knyttet til konkrete utsagn? |
| Ønsket handling | Beskriv hva målgruppen skal kunne forstå, velge, finne, gjøre eller nå videre til. | Kan utfallet brukes som et meningsfullt akseptansevilkår? |
| Format | Velg veiledning, sammenligning, oppslag, forklaring, transaksjonstrinn, verktøy eller annet begrunnet format. | Følger formen av behovet og siderollen fremfor bestillerens preferanse? |
| Eier | Navngi personen eller teamet som er ansvarlig for nøyaktighet og vedlikehold. | Er bidragsytere, kontrollører og godkjennere angitt separat der de trengs? |
| Gjennomgangsdato | Sett neste kontroll ut fra kjente endringer, volatilitet, risiko og publiseringsforpliktelser. | Er både datoen og den praktiske utløseren dokumentert? |
Teamet bør undersøke om nettstedet eller det samlede brukerforløpet allerede møter behovet før en ny side godkjennes. Søk etter sider som svarer på samme spørsmål, men også etter verktøy, skjemaer, transaksjoner, hjelpetekster og andre kanaler som utfører den foreslåtte oppgaven. GOV.UKs veiledning anbefaler en tidlig gjennomgang for å finne innhold som kan oppdateres, duplisering som bør fjernes, og oppgaveinformasjon som mangler.
Beslutningen bør ikke være mekanisk. Begrenset gjentakelse på selve behovspunktet kan hjelpe en bruker gjennom en transaksjon, mens to komplette sider med samme autoritative svar kan skape usikkerhet. Spør derfor ikke bare om innholdet ligner, men hvilken kilde som skal eie svaret, hvor brukeren faktisk trenger informasjonen, og hva som skal skje med gamle innganger, lenker og sider etter beslutningen.
Ikke be skribenten produsere en side; be organisasjonen begrunne hvilken oppgave siden skal ha.
Definer målgruppen gjennom situasjonen, oppgaven eller forkunnskapen som faktisk endrer hva siden må gjøre, og formuler deretter ett sentralt, dokumentert spørsmål med ord målgruppen vil kjenne igjen. «Alle kunder» gir sjelden nok retning. «Kundeadministratorer som skal kontrollere forutsetningene før de konfigurerer en integrasjon» sier derimot noe om kontekst, kunnskapsnivå og hvilket neste steg innholdet skal støtte.
Ett sentralt spørsmål kan romme nært beslektede underspørsmål. Prøven er ikke om hvert spørsmål kan stå alene, men om siden kan løse ett sammenhengende behov uten å bli en oppsamlingsplass. Bevis kan komme fra søke- og bruksanalyse, henvendelser til kundesenter, tidligere brukerundersøkelser eller relevante eksterne data. Hver kilde må vurderes mot spørsmålet: høy trafikk viser aktivitet, men forklarer ikke alene hensikten bak besøket.
Skill dessuten mellom behov og foreslått løsning. En interessent kan be om en video, en ny produktside eller en bestemt overskrift, men ønsket dokumenterer ikke at formatet eller siden trengs. Registrer antakelsen, finn hva mennesker faktisk prøver å forstå eller gjøre, og marker tydelig hva som er observert, hva som er tolket, og hva teamet fortsatt må undersøke før briefen kan godkjennes.
De tre feltene virker sammen ved å fastsette hva siden alene skal bidra med, hvilken konklusjon brukeren trenger, og hvilket grunnlag som må underbygge den. Siderollen beskriver plasseringen i brukerforløpet og grensen mot eksisterende sider, verktøy og kanaler. Hovedbudskapet gir redaksjonell prioritet. Dokumentasjonsfeltet hindrer at et klart budskap forveksles med en påstand organisasjonen faktisk kan bevise.
Tenk på en støtteside før et konfigurasjonsverktøy. Siden kan forklare hvilke tilganger, kompatibilitetskrav og opplysninger en administrator må kontrollere før start. Verktøyet skal fortsatt utføre selve konfigurasjonen. Denne arbeidsdelingen følger prinsippet om at veiledning og transaksjoner gjør forskjellige jobber, og at informasjon bør ligge der den trengs i forløpet, ikke kopieres ukritisk til alle berøringspunkter.
Dokumentasjonen må dekke to spørsmål: Hvorfor finnes behovet, og hva skal bevise utsagnene på siden? Den kan derfor omfatte både henvendelsesdata som viser et tilbakevendende spørsmål, og produktdokumentasjon eller faglig verifisering som underbygger svaret. Når utkastet kommer, bør tittel, hovedoverskrift og åpning kontrolleres mot hovedbudskapet. WCAG 2.4.2 krever at sidetittelen beskriver emne eller formål, men denne kontrollen alene etablerer ikke full tilgjengelighet.
Ønsket handling bør angi hva målgruppen skal kunne forstå, beslutte, sammenligne, finne, gjøre eller gå videre til, og formatet bør velges etter dette utfallet. Handlingen er dermed et praktisk akseptansevilkår for innholdet, ikke automatisk et skjema, et salg eller en annen kommersiell konvertering. En god formulering beskriver brukerens oppnåelige neste tilstand uten å late som briefen garanterer resultatet.
Velg først format når behovet, siderollen og plasseringen i forløpet er tydelige. Stabil informasjon som skal slås opp, kan kreve en referanseside; alternativer som må vurderes mot hverandre, kan egne seg for en sammenligning; en forgrenet oppgave kan høre hjemme i et verktøy eller en transaksjon. Dette er eksempler, ikke en universell typologi. Dersom en produktendring, et kundesenter eller en annen kanal løser oppgaven bedre, skal beslutningsloggen si det fremfor å presse behovet inn i en ny side.
Siden bør ha én navngitt person eller ett team som er ansvarlig for nøyaktighet og vedlikehold, mens bidrag, kontroll og godkjenning fordeles eksplisitt. Eieren koordinerer arbeidet, men overtar ikke automatisk ansvaret til produkteksperter, tilgjengelighetsspesialister, jurister, regulatoriske fagpersoner eller tekniske implementører. Digital.gov beskriver nettopp opprettelse, vedlikehold, oppdatering og fjerning som deler av livsløpet, med eierskap, faglig verifisering og godkjenning som særskilte funksjoner.
Neste gjennomgang bør settes ut fra kjente endringer, innholdets volatilitet, konsekvensen av feil, tilgjengelige bevis og organisasjonens publiseringsforpliktelser. Registrer gjerne både en dato og en konkret utløser, som en planlagt produktversjon eller endring i en autoritativ kilde. Det finnes ikke ett forsvarlig kvartalsvis eller årlig intervall for alle sider. GOV.UKs veiledning viser at registre kan synliggjøre forfalte gjennomganger og støtte beslutninger om å oppdatere, rette eller avvikle, men en registrert dato garanterer ikke at arbeidet blir utført.
En ferdig nifeltsbrief er kort nok til å brukes som beslutningslogg, men konkret nok til at en skribent slipper å gjette oppdraget. Eksemplet nedenfor gjelder en hypotetisk støtteside for en bedriftsløsning. Det inneholder ingen påstander om trafikk, gjennomføring, konvertering eller kostnadsbesparelser; et virkelig team må erstatte alle antakelser med dokumentasjon fra sitt eget produkt, sine brukere og sitt brukerforløp.
Før oppdraget godkjennes, skal interessentene kunne peke på bevis for målgruppen og spørsmålet, forklare hvorfor beslutningen og siderollen er tydelige, angi hovedbudskapet og dokumentasjonen, beskrive et meningsfullt neste utfall, begrunne formatet, navngi eieren og forplikte seg til en gjennomgangsdato med utløser. Hvis et vesentlig svar mangler eller motsier resten av briefen, bør bestillingen gå tilbake til undersøkelse eller revisjon før utkastet fordeles.
Godkjenn skriveoppdraget først når behovet, den valgte innholdsbeslutningen, alle ni feltene og livsløpsansvaret henger sammen. Briefen reduserer uklarhet i oppdraget, men erstatter ikke brukerundersøkelser, faktasjekk, tilgjengelighetsarbeid, teknisk vurdering eller spesialistgodkjenning. Ta inn kvalifiserte fagpersoner når innholdet omfatter vurderinger som krever deres kompetanse. Den ansvarlige innholdseieren skal samordne disse bidragene, ikke opptre som erstatning for dem.
En formålsbrief er en kort intern beslutningslogg som avklarer målgruppe, behov, siderolle, hovedbudskap, dokumentasjon, ønsket utfall, format, eierskap og gjennomgang før skrivingen starter. Den skal hjelpe organisasjonen med å begrunne oppdraget, ikke fungere som et miniutkast.
Bruk ni felt: tiltenkt målgruppe, brukerspørsmål, siderolle, hovedbudskap, nødvendig dokumentasjon, ønsket handling, format, eier og gjennomgangsdato. Malen er en praktisk redaksjonell sammenstilling av dokumenterte planleggings- og styringsprinsipper, ikke en universell offisiell standard.
Kontroller først eksisterende innhold og andre kontaktpunkter, og valider deretter behovet. Fyll ut de ni feltene, velg mellom å oppdatere, slå sammen, omdirigere, avslå eller opprette, og godkjenn beslutningsloggen før et utkast bestilles.
Nei. En eksisterende side, sammenslåing, omdirigering, endring i en transaksjon, et verktøy eller en annen kanal kan møte behovet bedre. Bestillingen bør avslås dersom dokumentasjonen ikke viser et gyldig behov eller en tydelig siderolle.
Det finnes ikke ett passende intervall for alt innhold. Sett neste kontroll ut fra kjente endringer, volatilitet, konsekvensen av feil, dokumentasjonen og organisasjonens forpliktelser, og registrer gjerne både dato og utløser.
Denne artikkelen bygger på følgende kilder:
Bygg et sporbart strategikart som kobler publikumsbehov og hele kundereisen til nettstedsfunksjoner, målbare resultater og tydelige veivalg.
En praktisk metode for å følge viktige brukeroppgaver gjennom navigasjon, etiketter, lenker og søk før dere beslutter redesign eller migrering.
En leverandørnøytral metode for å sammenligne CMS-er med kjøpereide publiseringsscenarioer, faste utfall, feilvarianter og dokumentert innsats.
