En tydlig kravspecifikation för en hemsida gör det enklare att få jämförbara offerter, undvika missförstånd och prioritera rätt funktioner. Den behöver inte beskriva varje knapp innan projektet börjar, men den ska göra det tydligt vad verksamheten behöver uppnå och vilket ansvar leverantören ska ta.

En bra kravspecifikation fungerar både som offertunderlag och som referens under projektet när nya önskemål eller avvägningar uppstår.

1. Beskriv projektets bakgrund

Förklara kort varför webbplatsen ska byggas eller göras om. Är nuvarande lösning tekniskt gammal, svår att redigera, dålig på att generera leads eller otillräcklig för nya marknader?

Bakgrunden hjälper leverantören förstå vilka problem som faktiskt ska lösas.

2. Definiera affärsmålen

Beskriv vad webbplatsen ska bidra till. Exempel:

  • fler kvalificerade offertförfrågningar
  • fler bokningar
  • ökad e-handelsförsäljning
  • mindre supportarbete
  • bättre rekrytering
  • tydligare information för befintliga kunder

Prioritera gärna ett huvudmål och några stödjande mål.

3. Definiera målgrupper och deras uppgifter

Lista de viktigaste användargrupperna och vad de behöver kunna göra. Undvik formuleringen ”alla”. En inköpare, arbetssökande och befintlig kund kan behöva helt olika vägar genom webbplatsen.

4. Lista sidtyper, inte bara sidnamn

Beskriv vilka återkommande mallar som behövs:

  • startsida
  • tjänstesida
  • produkt eller kategori
  • artikel eller guide
  • case
  • FAQ
  • kontakt
  • landningssida

Det ger en bättre bild av design- och utvecklingsomfattningen än en lång lista över enskilda URL:er.

5. Beskriv CMS-behovet

Förklara vad redaktörer ska kunna ändra själva och vilka roller som behövs. Ska användaren kunna skapa nya sidtyper, återanvända komponenter, tidsstyra innehåll eller förhandsgranska före publicering?

Testa gärna redaktörsupplevelsen innan plattformen väljs.

6. Specificera integrationer

Lista alla system som webbplatsen behöver kommunicera med:

  • CRM
  • bokning
  • betalning
  • nyhetsbrev
  • ERP
  • lager
  • analys
  • inloggning
  • andra API:er

Beskriv också riktning och syfte: vilken data skickas, när och vilket system är källa?

7. Kravställ formulär och leadflöden

Ange vilka formulär som behövs, vilka fält som är obligatoriska, var informationen ska hamna och hur användaren ska få bekräftelse.

Om leads ska till ett CRM behöver även felhantering och dubbletter tänkas igenom.

8. Sätt tydliga SEO-krav

Webbplatsen bör ge kontroll över sidtitlar, metadata, canonical, redirects, sitemap, robots och stabil URL-struktur. Vid migrering ska befintliga URL:er kartläggas innan lansering.

För en komplett grund, se SEO för företagshemsidor.

9. Definiera prestandakrav

Be leverantören beskriva hur bilder, JavaScript, cache, CDN och hosting ska hanteras. Kravet bör avse verkliga sidtyper, inte bara en tom demosida.

Se prestandaguiden.

10. Lägg in tillgänglighet från början

Specificera krav på tangentbord, kontrast, formulär, fokus, alt-texter och manuell testning. Tillgänglighet som kommer in sent blir ofta dyrare att rätta.

Använd checklistan för tillgänglig hemsida.

11. Definiera mätningen

Bestäm vilka händelser som ska kunna följas från lansering:

  • formulär
  • bokningar
  • köp
  • telefonklick
  • downloads
  • andra viktiga konverteringar

Ange också vem som äger analytics- och annonskonton.

12. Fördela innehållsansvaret

Bestäm vem som skriver texter, tar fram bilder, migrerar gamla sidor, verifierar fakta och godkänner slutversionen. Många webbprojekt blir försenade för att innehållsansvaret är oklart.

13. Beskriv designprocessen

Ange om projektet kräver wireframes, visuella designförslag, komponentbibliotek eller designsystem. Definiera hur många beslutspunkter och godkännanden som är rimliga.

14. Kravställ ägande och åtkomst

Det ska vara tydligt vem som äger domän, DNS, kod, design, innehåll, media och externa konton efter betalning. Företaget bör ha egen administrativ åtkomst till kritiska tjänster.

15. Beskriv säkerhet och drift

Definiera backup, uppdateringar, incidenthantering, åtkomstkontroll och ansvar efter lansering. Om leverantören erbjuder support bör svarstider och omfattning vara tydliga.

Se underhåll av hemsida.

16. Sätt en realistisk tidplan

Beskriv önskat lanseringsdatum men be leverantören bryta ned arbetet i faser. Tydliggör vilka beroenden som kan påverka tiden, exempelvis innehåll, integrationer, juridiskt godkännande eller tredjepartsleverantörer.

17. Definiera acceptanskriterier

Bestäm hur ni vet att leveransen är klar. Exempel:

  • alla prioriterade sidtyper publicerade
  • formulär testade
  • redirectlista genomförd
  • analytics verifierad
  • mobiltest godkänt
  • kritiska tillgänglighetsfel åtgärdade
  • backup och drift dokumenterade

18. Separera måste-krav från önskemål

Märk krav som exempelvis måste, bör och kan. Det gör offertdiskussionen mycket enklare om budgeten behöver justeras.

19. Be leverantören redovisa antaganden

Två offerter kan se olika ut för att leverantörerna gjort olika antaganden om innehåll, antal mallar eller integrationsarbete. Be därför varje leverantör beskriva vad som ingår och vad som uttryckligen inte ingår.

20. Skicka samma brief till alla

För att priser ska gå att jämföra behöver leverantörerna räkna på samma grund. Om en byrå inkluderar SEO, innehållsmigrering och support medan en annan bara räknar design och utveckling är totalsiffrorna inte jämförbara.

Kort mall att kopiera

  1. Bakgrund och nuläge
  2. Affärsmål
  3. Målgrupper
  4. Sidtyper
  5. CMS och redaktörsroller
  6. Funktioner och integrationer
  7. SEO
  8. Prestanda
  9. Tillgänglighet
  10. Mätning
  11. Innehållsansvar
  12. Designprocess
  13. Säkerhet och drift
  14. Ägande och konton
  15. Tidplan
  16. Acceptanskriterier

Sammanfattning

En bra kravspecifikation beskriver mål, användare, sidtyper, funktion, integrationer och ansvar utan att låsa projektet vid onödiga tekniska detaljer. Den gör offerter jämförbara och minskar risken för scope-konflikter. Definiera särskilt SEO, mätning, ägande och support – områden som annars ofta blir otydliga först efter lansering.