Att skriva en kravspecifikation handlar inte om att fylla ett dokument med tekniska termer. Det handlar om att skapa ett tydligt beslutsunderlag. Ett dokument som gör att leverantörer kan räkna på samma sak och att du som beställare kan jämföra offerter rättvist.
Om du ännu inte läst guiden Hur skriver man en kravspecifikation för en webbplats? rekommenderar jag att börja där. Här kan du läsa djupare in i vad som konkret bör finnas med och hur detaljerad du faktiskt behöver vara.
Projektets bakgrund och nuläge
Det här är ofta den mest underskattade delen. Beskriv kort:
- Har ni en befintlig webbplats?
- Vad fungerar dåligt idag?
- Varför ska ni göra om eller bygga nytt?
Det ger leverantören förståelse för om projektet handlar om prestandaproblem, låg konvertering, teknisk skuld eller varumärkesförändring. Kontexten påverkar lösningsförslaget mer än många tror.
Affärsmål och mätbara resultat
Det räcker inte att skriva “vi vill ha fler kunder”. Försök konkretisera.
- Vill ni öka antalet offertförfrågningar?
- Minska administrativa moment?
- Sälja direkt via webbplatsen?
- Stärka förtroendet i en upphandlingsprocess?
När målen är tydliga kan leverantören föreslå rätt struktur och funktioner. Det blir också lättare att följa upp om webbplatsen faktiskt levererar.
Målgrupp och användarbeteenden
Beskriv hur era kunder beter sig.
- Söker de information länge innan de tar kontakt?
- Behöver de ladda ner dokument?
- Jämför de priser?
- Besöker de webbplatsen från mobil?
Det här påverkar allt från navigation till innehållsstruktur och tekniska lösningar.
Innehållsstruktur och sidtyper
En viktig del av kravspecifikationen är att definiera vilka typer av sidor som behövs.
Exempel:
- Startsida
- Tjänstesidor
- Produktsidor
- Blogg
- Referenssidor
- Landningssidor
- FAQ
Fundera också på hur många sidor ni realistiskt behöver vid lansering. Många underskattar arbetet med innehåll.
Funktioner och integrationer
Här ska du vara konkret. Inte teknisk, men tydlig.
Behöver ni:
- Bokningssystem?
- Betallösning?
- CRM-integration?
- Nyhetsbrevsverktyg?
- Inloggning?
- Filuppladdning?
Om integrationer är viktiga, specificera vilka system som används idag.
Krav på kvalitet och prestanda
Det räcker inte att webbplatsen “fungerar”. Den ska fungera bra.
Ställ krav på:
- Mobilanpassning
- Laddningstid
- Säkerhet
- SEO-struktur
- Tillgänglighet
Det är här många projekt tappar kvalitet om det inte tydliggörs från början.
Roller och ansvar
Vem ansvarar för:
- Innehåll?
- Bildmaterial?
- Projektledning?
- Testning?
- Godkännande?
Tydliga roller minskar risken för förseningar. En bra kravspecifikation är inte ett tekniskt dokument. Det är ett tydlighetsdokument. Ju mer genomtänkt det är, desto större chans att projektet blir både prisvärt och framgångsrikt.
Så undviker du att kravspecifikationen blir för vag, eller för detaljerad
Det finns två vanliga ytterligheter när företag ska kravställa en webbplats.
Antingen är dokumentet så kort att det knappt går att räkna på. Eller så är det så tekniskt detaljerat att det låser lösningen innan dialogen ens börjat. Balansen är avgörande.
I guiden Hur skriver man en kravspecifikation för en webbplats? går vi igenom grunderna. Här fokuserar vi på hur du hittar rätt nivå.
För vag kravspecifikation, vad händer då?
Om du skriver:
“Vi vill ha en modern hemsida med bra SEO.”
Det säger väldigt lite.
Leverantören måste gissa:
- Hur många sidor?
- Vilka funktioner?
- Vilka mål?
- Vilken ambitionsnivå?
Resultatet blir antingen en låg offert med minimal lösning eller en hög offert med säkerhetsmarginal. Ingen av dem hjälper dig.
För detaljerad kravspecifikation, vad är risken?
Vissa beställare går åt andra hållet. De specificerar exakt hur allt ska byggas tekniskt. Problemet är att du då riskerar att begränsa leverantörens expertis. Kanske finns det bättre lösningar än de du tänkt dig. En kravspecifikation ska beskriva behov och mål. Inte diktera teknisk implementation.
Hur hittar du rätt nivå?
Tänk så här:
- Beskriv vad ni vill uppnå.
- Beskriv vilka funktioner som behövs.
- Beskriv kvalitetskrav.
- Låt leverantören föreslå hur det ska byggas.
- Fokusera på resultatet, inte på verktygen.
- Ställ rätt frågor internt
Innan dokumentet skickas ut, säkerställ att ni internt är överens om:
- Prioriteringar
- Budgetnivå
- Tidsram
- Långsiktiga mål
Intern otydlighet skapar extern förvirring. En bra kravspecifikation är tydlig utan att vara låst. Den ger riktning men lämnar utrymme för expertis. Det är där de bästa projekten uppstår.
Checklista inför offertförfrågan, så förbereder du dig rätt
Innan du skickar ut en kravspecifikation till leverantörer är det klokt att göra en sista genomgång. Många problem i webbprojekt uppstår inte under utvecklingen, utan redan i offertfasen.
Här är en praktisk checklista och hjälper dig att vara bättre förberedd.
- Är målen tydligt formulerade?
Kan en extern person förstå vad webbplatsen ska uppnå? Om målen är otydliga blir lösningen det också.
- Har ni prioriterat funktioner?
Allt kan inte vara högsta prioritet. Märk upp krav som:
- Måste ha
- Bör ha
- Kan vänta
Det gör dialogen mer konstruktiv.
- Har ni tänkt igenom innehållet?
Innehåll tar tid. Har ni resurser att producera texter? Ska leverantören hjälpa till? Finns det befintligt material att återanvända? Många projekt försenas här.
- Är tekniska beroenden kartlagda?
Använder ni CRM, affärssystem eller bokningssystem som måste integreras? Kontrollera att det finns tekniska möjligheter innan projektet startar.
- Är budgeten realistisk?
Om kraven är omfattande men budgeten låg uppstår spänningar direkt. En ärlig budgetdiskussion sparar tid.
- Har ni tänkt långsiktigt?
En webbplats är inte ett engångsprojekt. Fundera på:
- Skalbarhet
- Underhåll
- Uppdateringar
- Framtida funktioner
Att bygga rätt från början är billigare än att bygga om senare. Att kravställa en webbplats är inte ett administrativt hinder. Det är ett sätt att ta kontroll över investeringen.
Ju mer förberedd du är innan du begär offert, desto större chans att du får en lösning som matchar både budget och affärsmål. Och desto mindre risk att du i slutändan står där med en webbplats som tekniskt sett fungerar – men inte levererar det du faktiskt behövde.
