Hvis du sidder med ansvaret for en ny WordPress-hjemmeside, kender du sikkert følelsen. I vil gerne have et ordentligt tilbud at tage stilling til, men før nogen kan give et seriøst tilbud, skal projektet beskrives ordentligt. Ellers får I priser og forslag, der peger i hver sin retning.
Det er her en kravspecifikation og et godt tilbudsgrundlag gør en reel forskel. Ikke som papir for papirets skyld, men som et arbejdsredskab. Et dokument, der gør det tydeligt, hvad I beder om, hvad leverandøren skal levere, og hvad der skal være afklaret, før projektet går i gang.
I mit arbejde med B2B-hjemmesider har jeg set det mange gange. Når kravene er uklare, bliver samarbejdet tungt. Når de er klare, bliver projektet roligt, struktureret og langt nemmere at styre. Det gælder især i WordPress-projekter, fordi platformen kan bruges til meget forskelligt, fra en enkel virksomhedsprofil til en mere kompleks løsning med integrationer, brugerroller og specialfunktioner.
Hvorfor en WordPress kravspecifikation giver ro i projektet
En WordPress kravspecifikation handler ikke kun om teknik. Den handler om forventninger. Når du beskriver projektet tydeligt, bliver det lettere at vurdere tilbud, lettere at prioritere og lettere at sige ja til det rigtige.
Mange tror, at en kravspecifikation skal være et langt og tungt dokument. Det mener jeg ikke. Den skal være gennemarbejdet, men den skal også være til at læse. Hvis dokumentet ligner en telefonbog med tekniske detaljer, mister det sin værdi for dem, der faktisk skal bruge det i hverdagen.
Det, jeg har lært, er ret enkelt. En god kravspecifikation skal kunne læses af både marketing, ledelse og den, der skal bygge hjemmesiden. Alle skal kunne pege på samme dokument og sige: Ja, det er det her, vi er enige om.
En kravspecifikation er ikke bureaukrati. Det er det dokument, der forhindrer, at projektet ender med at blive styret af misforståelser i stedet for beslutninger.
Når en kravspecifikation mangler, opstår de samme problemer igen og igen:
- Uens tilbud på et uklart grundlag
- Misforståelser om funktioner
- Utydelig ansvarsfordeling
- For mange rettelser sent i forløbet
- Usikkerhed om drift efter lancering
Hvad et tilbudsgrundlag til WordPress-projekter bør indeholde
Et tilbudsgrundlag er det dokument, du sender ud, når du vil have et kvalificeret tilbud på en ny hjemmeside. Det må gerne være kortere end en fuld kravspecifikation, men det skal stadig være præcist. Hvis dokumentet kun siger “vi ønsker en ny professionel hjemmeside”, får du ikke noget brugbart tilbage.
Jeg anbefaler, at tilbudsgrundlaget samler både forretningsmæssige, redaktionelle og tekniske krav. Ikke i samme detaljeringsgrad over det hele, men nok til at leverandøren kan vurdere opgaven realistisk.
Her er en enkel struktur, som fungerer godt i praksis:
| Afsnit | Det skal beskrives | Hvorfor det er vigtigt |
|---|---|---|
| Baggrund og formål | Hvorfor I vil have ny hjemmeside, og hvad den skal løse | Giver retning for hele projektet |
| Målgruppe | Hvem hjemmesiden er til, og hvad de skal kunne finde | Gør struktur og indhold mere præcist |
| Omfang | Antal sidetyper, funktioner, integrationer og afgrænsning | Gør tilbud sammenlignelige |
| Design og brand | Visuel retning, tone, designmanual og referencer | Sikrer et professionelt udtryk |
| Indhold | Hvem skriver tekster, skaffer billeder og godkender indhold | Forebygger stop undervejs |
| Teknik | WordPress-opsætning, plugins, integrationer, sikkerhed, backup og opdateringer og hosting | Giver et stabilt teknisk grundlag |
| Tidsplan | Milepæle, feedbackrunder og ønsket lanceringsdato | Skaber fremdrift og ro |
| Drift | Opdateringer, backup, support og ansvar efter lancering | Sikrer at hjemmesiden kan holde over tid |
| Pris og vilkår | Budgetramme, betalingsmodel og eventuelle forbehold | Giver klare rammer fra start |
Hvis du vil gøre dokumentet endnu stærkere, så skriv også, hvad der ikke er med. Det lyder enkelt, men det er et af de vigtigste punkter. Uklare grænser skaber rod.
WordPress kravspec skabelon med de vigtigste afsnit
Når jeg hjælper virksomheder med at afklare en ny hjemmeside, starter jeg ikke med plugins eller layout. Jeg starter med formål, omfang og ansvar. Det gør resten lettere.
Projektbeskrivelse og formål i WordPress-projektet
Begynd med en kort projektbeskrivelse. To til fire afsnit er nok. Her skriver du, hvorfor hjemmesiden skal laves, hvad der ikke fungerer i dag, og hvad I gerne vil stå med bagefter.
Det er også her, du beskriver succeskriterier. Ikke som luftige mål, men som noget konkret. Det kan være, at hjemmesiden skal præsentere ydelser tydeligere, gøre det lettere at vedligeholde indhold internt eller samle virksomhedens brand på en mere professionel måde.
Scope og afgrænsning i kravspecifikationen
Omfanget skal være tydeligt. Hvor mange sidetyper er der? Skal der være nyhedssektion, medarbejderprofiler, cases, formularer, sprogversioner eller integration til CRM? Skal eksisterende indhold flyttes med, eller starter I forfra?
Skriv også, hvad der ikke er en del af projektet. Hvis foto, tekstforfatning, oversættelse eller tredjepartslicenser ikke indgår, skal det stå sort på hvidt.
Det er her, mange projekter glider. Ikke fordi nogen vil noget forkert, men fordi ingen har skrevet grænsen ordentligt ned.
Funktionelle krav til WordPress-hjemmesiden
Funktionelle krav beskriver, hvad hjemmesiden skal kunne. Hold dem konkrete. Skriv ikke “god kontaktformular”. Skriv i stedet, hvad formularen skal indeholde, hvem den skal sende til, og om den skal gemme data eller kobles til et andet system.
Efter en kort beskrivelse kan du samle kravene sådan her:
- Kontaktformularer: Felter, modtagere, kvitteringsmail og spam-beskyttelse
- Nyhedsmodul: Oprettelse af artikler, kategorier og filtrering
- Sprogversioner: Hvilke sprog der indgår, og hvordan indhold håndteres
- Integrationer: CRM, nyhedsbrev, jobsystem eller eksterne databaser
- Brugerroller: Hvem må redigere hvad i WordPress
- Søgefunktion: Hvad der skal kunne findes, og hvordan resultater vises
Hvis et krav er vigtigt, så tilføj et accepteringskriterium. Altså en enkel måde at teste, om kravet er opfyldt. Det giver fælles forståelse og gør godkendelsen mere fair.
Tekniske krav til WordPress, plugins og drift
Det tekniske afsnit skal være tydeligt, men ikke unødigt tungt. Du behøver ikke skrive som en udvikler. Du skal bare sætte rammerne klart.
Skriv fx om hjemmesiden skal bygges i WordPress, hvilke integrationer der er nødvendige, om der er krav til hosting, sikkerhed, backup og opdateringer, og om løsningen skal kunne redigeres internt uden udviklerhjælp.
I mit arbejde er det her et sted, hvor mange virksomheder undervurderer betydningen. De fokuserer på det visuelle og glemmer fundamentet. Men en professionel hjemmeside skal ikke bare se ordentlig ud. Den skal også være stabil, sikker og til at vedligeholde.
Designkrav, UX og brandsammenhæng på hjemmesiden
Designafsnittet bør beskrive retningen, ikke færdige løsninger. Hvilket udtryk skal hjemmesiden have? Skal den være stram og teknisk, varm og relationel eller enkel og meget sober? Har I designmanual, farver, typografi og billedstil, der skal følges?
Skriv også noget om struktur og brugeroplevelse. Hvad skal være let at finde? Hvilke undersider er vigtigst? Hvordan skal navigationen tænkes? Her giver det mening at tage udgangspunkt i jeres målgrupper og deres spørgsmål, ikke i jeres interne organisationsdiagram.
En god hjemmeside føles gennemarbejdet, fordi struktur, indhold og design hænger sammen. Ikke fordi den råber højt.
Indhold, roller og godkendelser i tilbudsgrundlaget
Mange WordPress-projekter bliver forsinket af én grund: ingen ved præcist, hvem der leverer hvad. Derfor bør skabelonen have et selvstændigt afsnit om ansvar.
Skriv, hvem der står for tekster, billeder, korrektur, juridisk godkendelse og endelig godkendelse af design og funktioner. Hvis leverandøren skal opsætte indhold, skal det også beskrives. Hvis I selv skal lægge indhold ind efter oplæring, skal det stå lige så tydeligt.
Her må du gerne være meget konkret:
- Tekster: Hvem skriver, hvem godkender, og hvornår afleveres de
- Billeder: Egne fotos, stock eller ny produktion
- Feedback: Hvilket værktøj eller hvilken kanal der bruges
- Godkendelser: Hvem har sidste ord i hver fase
Fejl jeg ser i mange kravspecifikationer til hjemmesider
Den mest almindelige fejl er, at dokumentet bliver for generelt. Der står noget om et moderne design og en brugervenlig løsning, men ingen kan læse sig frem til, hvad det faktisk betyder. Det giver for meget tolkningsrum.
Den næstmest almindelige fejl er det modsatte. Dokumentet drukner i detaljer, før de vigtige beslutninger er taget. Så bruger man tid på små tekniske valg, mens formål, indhold og ansvar stadig står uklart.
Jeg vil langt hellere se en kort og skarp kravspecifikation end en lang tekst uden retning.
Der er især fire ting, jeg ville rette først, hvis jeg fik dokumentet på mit bord:
- Uklare formuleringer: Ord som ‘moderne’ og ‘brugervenligt’ uden konkret beskrivelse
- Manglende afgrænsning: Ingen beskrivelse af, hvad der ikke er med i projektet
- Ingen plan for indhold: Uafklaret hvem der skriver, leverer og godkender
- Intet afsnit om drift: Ingen aftale om opdateringer, backup og ansvar efter lancering
Drift, support og vedligeholdelse skal stå i kravspecifikationen
Det her afsnit bliver tit glemt, og det er en fejl. En WordPress-hjemmeside er ikke færdig, fordi den er lanceret. Den skal opdateres, overvåges og holdes sikker.
Drift er ikke en eftertanke. Det er den del af projektet, der afgør, om jeres hjemmeside stadig fungerer om et år.
Skriv derfor allerede i tilbudsgrundlaget, hvordan drift skal håndteres. Hvem tager ansvar for WordPress-opdateringer, plugin-opdateringer, backup, overvågning og fejlrettelser? Hvad sker der, hvis noget går ned? Og hvem betaler licenser til tredjepartsløsninger?
Det behøver ikke være kompliceret. Det skal bare være tydeligt. Når det punkt er på plads, står I langt stærkere bagefter, også internt. I kan bedre vurdere, hvad løsningen faktisk kræver på den lange bane.
Sådan bruger du skabelonen i dialog med leverandører
Når skabelonen er udfyldt, har du et ordentligt grundlag for dialog. Ikke kun for at få en pris, men for at se, hvordan forskellige leverandører tænker. Det bliver hurtigt tydeligt, hvem der har læst materialet grundigt, og hvem der bare sender et standardtilbud.
Jeg synes, at det er en god idé at sende det samme tilbudsgrundlag til alle, I vil i dialog med. Så får du et mere fair sammenligningsgrundlag. Du kan stadig tage individuelle møder bagefter og uddybe projektet, men udgangspunktet bør være fælles.
Før du sender dokumentet ud, så gennemgå det med disse spørgsmål:
- Er formålet klart: Kan en udenforstående forstå, hvorfor hjemmesiden skal laves?
- Er omfanget tydeligt: Fremgår det, hvad der indgår, og hvad der ikke gør?
- Er ansvar fordelt: Ved alle, hvem der leverer indhold og godkender?
- Er driften afklaret: Står der noget om support, opdateringer og backup?
Hvis du kan svare ja til de fire punkter, er du allerede langt. Så har du ikke bare en WordPress kravspec skabelon. Du har et arbejdsredskab, der gør projektet mere roligt, mere struktureret og mere professionelt at gå ind i. Det er i mine øjne hele pointen.
