Fra utkast til publisert side: En trygg arbeidsflyt for WordPress

Mange WordPress-nettsteder har gode tekniske løsninger, men en svak publiseringsprosess. Ansatte redigerer direkte på viktige sider, godkjenninger skjer i chat, og ingen vet sikkert hvem som kontrollerte skjemaet før publisering. Resultatet er sjelden én stor feil. Det er summen av små problemer: brutte oppsett, utdaterte budskap, tunge bilder, manglende metadata og sider som ser riktige ut på PC, men ikke på mobil.

En trygg arbeidsflyt trenger ikke være omfattende. Den må være tydelig nok til at alle vet hva de kan endre, hvem som godkjenner, og hvilke kontroller som skal gjøres før en side blir synlig. Målet er ikke mer administrasjon, men færre rettelser og mindre usikkerhet.

Start med å dele endringer etter risiko

Ikke alle endringer trenger samme prosess. En skrivefeil på en nyhetsside er noe annet enn å endre forsiden, navigasjonen eller et skjema som sender kundehenvendelser. Bedriften bør derfor dele endringer inn i noen få risikonivåer.

• Lav risiko: Retting av tekst, utskifting av et eksisterende bilde eller oppdatering av kontaktinformasjon innenfor en etablert mal.
• Middels risiko: Nye innholdssider, endringer i handlingsknapper, nye Gutenberg-blokker eller større omskriving av en viktig tjenesteside.
• Høy risiko: Endringer i maler, menyer, skjemaer, sporingsoppsett, integrasjoner, betalingsflyt eller nettstedets globale design.

Endringer med lav risiko kan ofte publiseres av en innholdsansvarlig etter en kort egenkontroll. Middels risiko bør gjennomgås av en kollega eller fagansvarlig. Høy risiko bør testes utenfor det publiserte nettstedet og godkjennes av både innholds- og teknisk ansvarlig.

Denne inndelingen gjør det mulig å bruke tid der konsekvensene er størst. Den hindrer også at en enkel tekstretting blir stående i kø fordi prosessen er laget for større utviklingsarbeid.

Gi roller ut fra oppgaver, ikke stillingstitler

WordPress-tilgang blir ofte tildelt for bredt. Flere får administratorrettigheter fordi det er raskest der og da. Det øker faren for at noen endrer innstillinger, installerer tillegg eller sletter innhold uten å forstå konsekvensene.

Definer heller noen praktiske roller i arbeidsflyten:

• Bestiller: Beskriver behovet, målgruppen og ønsket resultat.
• Innholdsprodusent: Skriver og bygger siden innenfor godkjente blokker og mønstre.
• Faglig godkjenner: Kontrollerer at innholdet er korrekt, oppdatert og i tråd med bedriftens tilbud.
• Publiseringsansvarlig: Kontrollerer struktur, mobilvisning, lenker, skjemaer og metadata før publisering.
• Teknisk ansvarlig: Håndterer maler, tillegg, integrasjoner og endringer med høy risiko.

Én person kan ha flere roller i en liten virksomhet. Poenget er likevel å skille oppgavene. Den som har skrevet en side, overser lettere egne feil. En enkel gjennomgang av en annen person fanger ofte opp uklare overskrifter, manglende informasjon og handlingsknapper som ikke passer med brukerens behov.

Bruk Gutenberg som et styrt byggesett

Gutenberg gir redaktører stor frihet, men frihet uten rammer skaper fort ujevne sider. Hver redaktør kan velge egne farger, avstander, kolonneoppsett og blokker. Etter en stund består nettstedet av mange lokale løsninger som er vanskelige å vedlikeholde.

Et bedre utgangspunkt er et begrenset sett med godkjente blokker og mønstre. Lag for eksempel faste mønstre for introduksjon, tjenesteoversikt, kundehistorie, kontaktoppfordring og spørsmål med svar. Mønstrene bør være utformet slik at redaktøren hovedsakelig bytter tekst, bilde og lenke.

Avklar også hva redaktører ikke skal gjøre. Det kan være å legge inn egendefinert kode, bruke tilfeldige farger, lage tomme avsnitt for å skape luft eller bygge avanserte kolonneoppsett uten testing. Slike begrensninger er ikke til hinder for godt innhold. De gjør det enklere å holde design, universell utforming og ytelse på et stabilt nivå.

Skill mellom innhold og mal

En nyttig regel er at redaktøren skal kunne endre budskapet uten å måtte reparere designet. Hvis en vanlig tekstendring krever justering av marger, skriftstørrelser eller visningsregler, er for mye av malansvaret lagt inn i selve siden.

Globale elementer som topptekst, bunntekst, typografi og standardavstander bør styres sentralt. Det samme gjelder elementer som brukes på mange sider. Da kan bedriften forbedre uttrykket samlet, fremfor å redigere hver side manuelt.

Lag en kort sidebrief før byggingen starter

Mange korrekturrunder skyldes ikke WordPress, men et uklart oppdrag. Før noen åpner redigeringsverktøyet, bør bestilleren svare på noen grunnleggende spørsmål:

1. Hvem er siden laget for?
2. Hva skal den besøkende forstå eller gjøre?
3. Hvilken informasjon må være med?
4. Hvem eier innholdet etter publisering?
5. Når skal siden gjennomgås på nytt?

Briefen trenger ikke være lang. For en ny tjenesteside kan den bestå av målgruppe, hovedbudskap, ønsket handling, faglig godkjenner og dato for neste kontroll. Det er nok til å redusere diskusjoner om detaljer som ikke støtter sidens formål.

Skill innholdsarbeid fra tekniske endringer

Utkastfunksjonen i WordPress fungerer godt for vanlige innholdsendringer. Den er mindre egnet når arbeidet påvirker maler, funksjonalitet eller flere publiserte sider samtidig. Da bør endringen utvikles og testes i et eget miljø før den flyttes til produksjon.

Vær samtidig forsiktig med å kopiere hele databasen mellom miljøer. Produksjonsnettstedet kan ha mottatt skjemaoppføringer, bestillinger, brukerendringer eller nytt redaksjonelt innhold mens arbeidet pågår. En ukritisk overskriving kan fjerne gyldige data.

Planlegg derfor hva som faktisk skal flyttes. En endring kan bestå av kode, konfigurasjon, et blokk-mønster og noen få konkrete sider. Den teknisk ansvarlige bør vite hvilke deler som kan distribueres kontrollert, og hvilke innholdsendringer som må gjøres separat.

Bruk en fast kontroll før publisering

En publiseringssjekk bør være kort nok til at den faktisk blir brukt. For en vanlig bedriftsside kan følgende kontroll være tilstrekkelig:

• Overskriften beskriver tydelig hva siden handler om.
• Overskriftsnivåene følger en logisk rekkefølge.
• Teksten er faglig godkjent og har en tydelig eier.
• Lenker og knapper peker til riktig sted og har forståelige navn.
• Bilder er relevante, beskåret riktig og ikke større enn nødvendig.
• Alternativ tekst er lagt inn når bildet formidler informasjon.
• Siden fungerer på mobil og ved forstørret tekst.
• Skjemaer viser riktig bekreftelse og sender til riktig mottaker.
• Sidetittel og beskrivelse er skrevet for søk og deling.
• Eventuell sporing er kontrollert uten å samle inn mer enn nødvendig.

Kontrollen bør ligge der arbeidet skjer, ikke i et dokument få kjenner til. Den kan inngå i oppgaveverktøyet, publiseringsrutinen eller et fast godkjenningsfelt. For viktige sider bør det være synlig hvem som utførte kontrollen.

Publiser på et tidspunkt der feil kan håndteres

Selv en godt testet endring kan gi uventede utslag. Publiser derfor ikke viktige endringer rett før arbeidsdagen er over, med mindre noen faktisk er tilgjengelige etterpå. Velg et tidspunkt der ansvarlige kan kontrollere resultatet og rette eventuelle problemer.

Kontrollen etter publisering bør skje på den offentlige siden, gjerne i et privat nettleservindu og på en mobiltelefon. Test den viktigste brukerreisen, ikke bare om siden åpner. Hvis målet er en henvendelse, bør dere følge veien fra inngangssiden til innsendt skjema og bekreftelse.

For endringer med middels eller høy risiko bør dere også ha en enkel plan for tilbakerulling. Det kan bety å gjenopprette forrige sideversjon, deaktivere en ny funksjon eller legge tilbake den tidligere malen. Planen må være konkret nok til at den kan gjennomføres under tidspress.

Gjør opprydding til en del av arbeidsflyten

Publisering er ikke slutten på innholdets livsløp. En side kan være korrekt i dag og misvisende om seks måneder. Legg derfor inn eier og neste gjennomgang når viktige sider publiseres.

En periodisk gjennomgang bør se etter utgåtte tjenester, gamle medarbeidere, feil kontaktinformasjon, unødvendige kampanjesider og innhold som konkurrerer med nyere sider. Sletting er ikke alltid riktig løsning. Noen sider bør oppdateres, slås sammen eller videresendes til et mer relevant innhold.

Det samme gjelder Gutenberg-mønstre og blokker. Når et mønster erstattes, bør det gamle fases ut kontrollert. Ellers fortsetter redaktører å bygge nye sider med en løsning bedriften egentlig har forlatt.

Begynn med én innholdstype

Ikke forsøk å innføre en full publiseringsmodell for hele nettstedet på én gang. Velg én vanlig innholdstype, for eksempel tjenestesider, og definer risikonivå, roller, brief, godkjente blokker og publiseringssjekk for denne.

Etter noen publiseringer vil dere se hvor prosessen er for tung, og hvor den mangler kontroll. Juster den før den tas i bruk på artikler, landingssider og andre deler av nettstedet.

En god WordPress-arbeidsflyt skal gjøre det enklere å publisere riktig, ikke vanskeligere å publisere i det hele tatt. Når ansvar, byggesteiner og kontroller er tydelige, kan flere bidra uten at nettstedet gradvis mister struktur, kvalitet og fart.