Kravdokument för webbplats: vad du ska skriva
Ett kravdokument finns till av ett skäl: att säkerställa att du och den som bygger webbplatsen talar om samma projekt. Det behöver inte vara långt. Det behöver vara specifikt på rätt ställen.
Den här guiden visar vad du ska ta med, vad du ska lämna ute och vilka avsnitt som förhindrar de vanligaste tvisterna.
Avsnitt som inte får saknas#
Vart och ett finns för att dess frånvaro orsakar ett förutsägbart problem.
- Sammanhang och mål. Vad företaget gör och vad webbplatsen ska åstadkomma, i siffror.
- Målgrupp. Vem som besöker och med vilken fråga.
- Sidlista. Alla, grupperade per mall, med markering av vilka som är nya.
- Funktioner. Formulär, sök, filter, inloggat område, vad det nu är.
- Integrationer. Varje externt system, med ansvarig för åtkomst.
- Innehåll. Vem skriver, vem fotograferar, vem lägger in, och till när.
- Tekniska krav. Språk, tillgänglighet, prestanda, stödda webbläsare.
- Utanför omfattningen. Dokumentets viktigaste avsnitt.
- Tider och ansvariga. Vem beslutar, och vad som händer vid försening.
Avsnittet «utanför omfattningen» förhindrar fler tvister än alla andra tillsammans. Skriv det även om det verkar självklart.
Hur du skriver krav som går att verifiera#
Ett vagt krav går inte att verifiera, och det som inte går att verifiera diskuteras i slutet av projektet.
| Vagt | Verifierbart |
|---|---|
| Webbplatsen ska vara snabb | LCP under 2,5 s på huvudmallarna i 4G |
| Den ska fungera på mobil | Användbar från 360 px, testad på riktiga enheter |
| Den ska vara tillgänglig | Uppfyller WCAG 2.1 nivå AA på huvudmallarna |
| Lätt att sköta | Teamet skapar och publicerar en sida utan utvecklare |
| Modern design | Följer grafisk profil; tre inledande förslag |
| Optimerad för SEO | Redigerbara titlar, sitemap, strukturerad data, omdirigeringar |
| Stödjer flera språk | SV och EN vid lansering; struktur för fler |
Vad du ska lämna ute#
Alltför detaljerade dokument kostar tid att skriva, tid att läsa och tar ifrån utföraren möjligheten att föreslå något bättre.
- Specificera inte teknik utan skäl. Ange problemet; lämna lösningen till offerten.
- Skriv inte texten på varje knapp. Det löses med skärmar framför sig.
- Designa inte webbplatsen i ord. Visuella referenser fungerar bättre än beskrivningar.
- Ta inte med funktioner «för framtiden» utan att tydligt märka dem som fas två.
- Kopiera inte krav från ett annat dokument utan att kontrollera att de gäller.
- Be inte om det du inte kommer använda. Varje funktion har en bygg- och förvaltningskostnad.
Om dokumentet passerar tio sidor för en företagswebbplats specificerar du troligen lösningen istället för problemet.
Att använda dokumentet under projektet#
Dokumentet ska inte arkiveras efter påskrift. Det är referensen som avgör tvister.
- Skicka samma dokument till alla kandidater för att få jämförbara offerter.
- Bifoga det till avtalet, så att den överenskomna omfattningen är den skrivna.
- När någon ber om något nytt, kontrollera dokumentet innan ni diskuterar tid.
- Dokumentera omfattningsändringar skriftligt, med estimat, innan arbetet börjar.
- Använd sidlistan som checklista för innehåll under bygget.
- Vid leverans, gå igenom de verifierbara kraven ett i taget.
Vanliga frågor
Hur långt ska dokumentet vara?
För en företagswebbplats räcker fem till tio sidor. För ett stort projekt med integrationer tjugo till trettio. Om du passerar det med marginal specificerar du troligen lösningen istället för problemet — och sådana dokument tenderar att ignoreras av alla, inklusive den som skrev dem.
Ska jag ange budgeten?
Ja. Utföraren kan då föreslå bästa möjliga projekt inom det beloppet istället för att gissa. Den som inte anger budget får bud som varierar tiofalt och kan inte jämföra dem. Ett intervall räcker; du behöver inte avslöja den exakta gränsen.
Vem ska skriva dokumentet?
Någon på kundsidan som känner verksamheten, helst med stöd av någon som kan webb. Ber du en byrå skriva det beskriver den naturligt det projekt byrån gillar att göra — vilket kan vara bra, men slutar fungera för att jämföra offerter. Gör du så, betala för den fasen separat.
Vad om kraven ändras mitt i?
De ändras nästan alltid, och dokumentet hindrar inte det — det organiserar det. Ha en ändringsprocedur: varje ny begäran får ett skriftligt estimat innan arbetet börjar. Problemet är inte ändringar, utan ändringar som smyger in utan att någon justerar tid och budget.
kravdokument webbplatsbrief hemsidakravspecifikation webbplatsomfattning webbprojektupphandling webbplatskrav webbprojekt
