Fra webanalyse til fungerende WordPress-prototype

Hvad sker der, når en hjem­mesi­de­op­gave ikke begyn­der med farver og skrift­ty­per, men med spørgs­må­let: Hvil­ket arbejde skal hjem­mesi­den egent­lig udføre? I et femu­gers projekt­for­løb for en dansk bran­che­or­ga­ni­sa­tion arbej­dede jeg fra teknisk opryd­ning og stra­te­gisk afkla­ring til infor­ma­tions­ar­ki­tek­tur, en skaler­bar indholds­mo­del og funge­rende Word­Press-proto­ty­per. Opga­ven udvik­lede sig dermed fra et ønske om en ny hjem­meside til en under­sø­gelse af sammen­hæn­gen mellem orga­ni­sa­tio­nens mål, bruger­nes behov, indhol­dets struk­tur og den prak­ti­ske imple­men­te­ring. Projek­tet blev ikke afslut­tet som en offi­ciel lance­ring på orga­ni­sa­tio­nens domæne. Det, jeg viser her, er den doku­men­te­rede arbejds­pro­ces og en funge­rende proof-of-concept, som jeg har beva­ret på mit eget domæne. 

Før designet: et stabilt teknisk grundlag

Jeg begyndte med at gennemgå det eksi­ste­rende Word­Press-miljø, sikre indlæg, sider og bille­der gennem backup og afklare, hvilke plugins og elemen­ter der skulle beva­res. Hosting, plat­form og tema-/buil­der­valg blev under­søgt, og jeg etab­le­rede et nyt webho­tel med en ny Word­Press-instal­la­tion som teknisk reset. Jeg under­søgte også eksi­ste­rende Analy­tics-data og begyndte at arbejde med rappor­te­ring i Looker Studio. Det var vigtigt, fordi et rede­sign ikke kun er et synligt lag. Hvis drift, indhold og måling ikke har et stabilt funda­ment, bliver selv et flot design vanske­ligt at vedli­ge­holde og forbedre. 

Hjemmesiden som forretnings- og kommunikationssystem

Jeg brugte blandt andet SOSTAC, Busi­ness Model Canvas, 7P, 5 Why og back­ca­sting til at gøre en uklar hjem­mesi­de­op­gave konkret. Arbej­det rejste spørgs­mål som: Hvad skal hjem­mesi­den bruges til? Hvor­for skal målgrup­pen besøge den? Hvilke hand­lin­ger skal forskel­lige brugere kunne fore­tage? Hvor­dan skal cases, nyhe­der, projek­ter og publi­ka­tio­ner adskil­les? Og hvor­dan kan effek­ten senere vurderes? 

Busi­ness Model Canvas blev brugt til at under­søge værdi­til­bud, målgrup­per, kana­ler, rela­tio­ner, part­nere og akti­vi­te­ter. SOSTAC skabte sammen­hæng fra situ­a­tion og mål til hand­lin­ger og kontrol. 7P gjorde det muligt at se hjem­mesi­den som ét af flere kontakt­punk­ter i orga­ni­sa­tio­nens samlede tilbud. 

Fra mål til konkrete brugerhandlinger

Projek­t­ma­te­ri­a­let inde­hol­der forslag til mål som rele­vante henven­del­ser, down­lo­ads, nyheds­brev­stil­mel­din­ger og delta­gelse i akti­vi­te­ter. Det er design­mål og måle­for­slag – ikke doku­men­te­rede resul­ta­ter efter lancering. 

5 Why-analy­sen af nyheds­bre­vet er et eksem­pel. Mange produk­tions­virk­som­he­der er ikke klar til at handle på addi­tive manu­fa­c­turing med det samme. Tekno­lo­gien kræver læring, intern afkla­ring og timing. Nyheds­bre­vet blev derfor tænkt som mulig beslut­nings­støtte frem for indhold for indhol­dets egen skyld. Back­ca­sting under­søgte på samme måde, hvilke kontakt­punk­ter og infor­ma­tio­ner der skulle eksi­stere, før et virk­som­hed­for­løb kunne begynde godt: scre­e­ning, kontakt, delta­gere, tids­plan, kontrakt, infor­ma­tions­mail, rele­vante cases og intromøde. 

Forskellige brugere kræver forskellige indgange

De poten­ti­elle brugere spændte fra ledere og innova­tions­ansvar­lige til produk­tions­folk, tekni­ske speci­a­li­ster, part­nere og videns­mil­jøer. De har ikke samme forhånds­vi­den, sprog eller beslut­nings­ansvar. Derfor arbej­dede jeg med forskel­lige indgange og næste skridt til forskel­lige modenhedsniveauer. 

Informationsarkitektur for et komplekst indholdsunivers

Flow­char­tet samlede blandt andet forside, landing pages, produk­ter, forløb, projek­ter, cases, nyhe­der, rappor­ter, publi­ka­tio­ner, events, messer, scre­e­ning, bereg­nere, netværk, formu­la­rer og track­ing pages. 

Den centrale opgave var at undgå, at alt indhold blev behand­let som almin­de­lige sider eller blogind­læg. Cases, nyhe­der og projek­ter har forskel­lige formål og redak­tio­nelle behov og skal derfor kunne opret­tes, kate­go­ri­se­res og vises forskelligt. 

Cases som et redaktionelt produkt

Virk­som­heds­ca­ses blev iden­ti­fi­ce­ret som et centralt trovær­dig­heds- og beslut­nings­værk­tøj. Jeg udvik­lede et framework, som orga­ni­se­rede en case omkring intro­duk­tion, kontekst, problem eller poten­ti­ale, nyt perspek­tiv, konkret hand­ling, doku­men­ter­bart resul­tat, gene­rel læring, fakta­bokse og en rele­vant call to action. Det betød, at arbej­det ikke kun hand­lede om, hvor­dan en case skulle se ud. Det hand­lede om, hvilke infor­ma­tio­ner den skulle inde­holde, i hvil­ken række­følge og med hvil­ket formål. 

Et skalerbart casesystem i WordPress

Den redak­tio­nelle model blev omsat til en teknisk løsning. Cases blev etab­le­ret som en selv­stæn­dig indhold­s­type med faste custom fields og en central temp­late. De samme oplys­nin­ger kunne genbru­ges dyna­misk på forsi­den, case­over­sig­ten, kate­go­ri­si­der, karru­sel­ler og den enkelte caseside. 

Det er noget andet end seks manu­elt byggede sider. Når indhold og præsen­ta­tion adskil­les, kan redak­tio­nen oprette nye cases ensar­tet, genbruge oplys­nin­ger flere steder og ændre den centrale visning uden at rette hver case. Seks udvalgte cases blev opret­tet eller bear­bej­det i samar­bejde med interne og eksterne kolle­ger. Eksem­pel­tek­ster og virk­som­heds­tal i proto­ty­pen skal læses som demon­stra­tions­ind­hold og ikke som doku­men­te­rede resultater. 

En caseskabelon med genbrugelige moduler

Den enkelte caseside blev opbyg­get af modu­ler til intro­duk­tion, kontekst, fakta­bokse, værdi, udfor­dring, læring, virk­som­heds­op­lys­nin­ger, rela­te­rede cases og næste skridt. 

En forside-/kom­po­nent­demo, en All Cases-side og en fuld eksem­pelcase blev bygget som proof-of-concept. Dermed blev analy­ser og diagram­mer omsat til sider, der faktisk kunne vises i en browser. 

Måling blev tænkt ind før lanceringen

Mate­ri­a­let omfat­ter forslag til Google Analy­tics, Tag Mana­ger, thank-you-pages og Looker Studio-rappor­ter. Den centrale tanke var, at man først kan vælge rele­vante målin­ger, når man ved, hvil­ket arbejde et webs­i­te­e­le­ment skal udføre. Projek­tet doku­men­te­rer analyse og igang­sæt­telse af dette spor, men ikke en færdig track­ing­plan eller efter­føl­gende effektdata. 

Fra undersøgelse til prototype på fem uger

1. Adgang, backup, back­end og eksi­ste­rende data.
2. Webs­i­te­a­na­lyse, marke­ting­plan, plat­form og hosting.
3. Møder, præsen­ta­tion af proces og teknisk reset.
4. Bruger­rej­ser, case-system, temp­late og indhold.
5. Forside-sprint og samling af prototypesiderne.

Rammer og succeskri­te­rier ændrede sig under­vejs, og projek­tet nåede ikke en normal lance­rings- og effek­t­må­lings­fase. Derfor beskri­ver jeg det som et udvik­lings­for­løb og en doku­men­te­ret proof-of-concept – ikke som et færdigt offi­ci­elt website. 

Hvad projektet viser om min måde at arbejde på

• Jeg kan skabe over­blik i et eksi­ste­rende WordPress-miljø.
• Jeg kan forbinde orga­ni­sa­tions­mål, målgrup­per og brugerhandlinger.
• Jeg kan anvende analy­se­mo­del­ler på en konkret digi­tal opgave.
• Jeg kan kort­lægge bruger­rej­ser og kompleks informationsarkitektur.
• Jeg kan udvikle en redak­tio­nel content-model og et case-framework.
• Jeg kan bygge custom post types, custom fields og dyna­mi­ske templates.
• Jeg kan omsætte analy­ser og diagram­mer til funge­rende websider.
• Jeg kan doku­men­tere begræns­nin­ger og skelne mellem design­mål og målte resultater.

Projek­tets værdi ligger i hele kæden: teknisk funda­ment → forret­nings­for­stå­else → bruger­rej­ser → infor­ma­tions­ar­ki­tek­tur → content-model → Word­Press-imple­men­te­ring → måling og videre udvikling.

Det er den type opgave, jeg trives med: Når et komplekst udgangs­punkt skal under­sø­ges, struk­tu­re­res og omsæt­tes til noget, andre kan bruge og arbejde videre med.