Kravspecifikation för hemsida: de tio områden som avgör projektet

En kravspecifikation avgör mer av ett webbprojekt än själva offerten.

Det är den byrån räknar på, den ni jämför anbuden mot och den ni går tillbaka till när någon undrar vad som egentligen var beställt. Ändå skrivs den ofta sist, i en hast och utifrån en mall.

Vi har läst många kravspecifikationer för nya hemsidor. De som fungerar har en sak gemensamt, och det är inte längden. De är fasta på vad webbplatsen ska åstadkomma och vad den ska kopplas till, och öppna på hur den ska se ut. De som inte fungerar gör tvärtom: lösa mål, men design och funktioner styrda i detalj.

Här är de tio områden vi tycker att en kravspecifikation för en ny hemsida ska täcka. Två av dem går vi igenom på djupet, eftersom det är där de flesta projekt avgörs.

Listan kommer från checklistan i vår guide Upphandling av hemsida. Den går att använda som mall för dokumentet eller som underlag för samtalet med byrån, oavsett om ni kallar det en kravspecifikation för hemsida eller för webbplats.

1. Syfte och mål. Varför ni behöver en ny webbplats, och hur ni vet att den blev bättre än den gamla.
2. Funktionalitet. Vad webbplatsen ska kunna göra, hur enkelt CMS:et ska vara för era redaktörer och vilka system den ska kopplas till.
3. Design och användarvänlighet. Grafisk profil, hur navigeringen ska fungera och vilken tillgänglighetsnivå webbplatsen ska nå.
4. SEO och prestanda. Krav på rubrikstruktur, metadata och adresser, en målnivå för laddningstid och en inventering av det som redan syns i Google.
5. Innehållsstrategi. Vem som skriver texterna, hur många språk som behövs och hur mycket innehåll som ska flyttas från den nuvarande webbplatsen.
6. Analysverktyg och spårning. Vilka verktyg som ska finnas på plats och vem som ansvarar för att sätta upp dem.
7. Tidsplan och budget. Ett önskat lanseringsdatum och en fastställd budget.
8. Juridiska krav. GDPR för formulär och kunduppgifter, hur cookies och samtycke ska hanteras, och om webbplatsen omfattas av tillgänglighetslagen eller DOS-lagen.
9. Intern projektorganisation. Vilka hos er som deltar, och vem som är intern projektledare.
10. Förvaltning och support. Support och underhåll efter lansering, svarstider i ett SLA, backup och en plan för när något går sönder.

Listan är inte ett formulär där varje rad ska fyllas i lika utförligt. Vissa områden ska vara skrivna i detalj. Andra räcker det att ni har tagit ställning till.

Tumregeln är enkel: lås det som är dyrt att ändra senare.

Fast: mål och mätning, integrationer, budget, lagkrav (inklusive tillgänglighet) och vem som bestämmer. Ändras de mitt i projektet ändras också priset, tidsplanen och ibland hela valet av plattform. Det sista går vi igenom längre ner.

Öppet: hur sidorna ser ut, hur menyn är uppbyggd och exakt vilka komponenter som behövs. Det är just där byrån har mest att tillföra, och där användartester brukar ändra riktningen.

Det betyder inte att design är oviktigt. Det betyder att designen ska svara mot målen, inte bestämmas innan någon vet vad målen är.

Tillgänglighet är ett lagkrav för fler än ni tror
Sedan den 28 juni 2025 gäller tillgänglighetslagen för bland annat e-handel och banktjänster som riktar sig till konsumenter. Offentlig sektor omfattas sedan tidigare av DOS-lagen. Båda utgår i praktiken från WCAG 2.1 nivå AA, och mikroföretag som säljer tjänster är i regel undantagna.
Ansvaret ligger hos er, även om en byrå har byggt webbplatsen. Omfattas ni ska kravspecifikationen ange nivån, hur den ska testas och vem som tar fram tillgänglighetsredogörelsen. Vår guide Tillgängliga webbplatser med WCAG reder ut vilka som omfattas och har färdiga kravformuleringar.

De två områden vi går igenom nedan är de som oftast skrivs för löst. Båda hör till det som ska vara fast.

Det här är det första en byrå behöver förstå. Ju tydligare det är, desto bättre kan byrån föreslå rätt lösning, i stället för att bygga exakt det som stod i listan över funktioner.

Vi slår här ihop område 1 och område 6 i checklistan. Ett mål som inte går att mäta är ett önskemål, och mätning utan mål blir siffror ingen tittar på.

Skriv i en eller två meningar varför ni behöver en ny webbplats. Vanliga syften är att:

• stärka varumärket
• generera leads eller öka försäljningen
• förbättra användarupplevelsen och tillgängligheten
• nå nya målgrupper digitalt
• effektivisera med integrationer

Välj ett eller två. Om allt är lika viktigt prioriterar byrån åt er.

Ett mål ska gå att följa upp efter lansering. Det behöver inte vara perfekt, men det ska finnas. Exempel:

• 30 procent fler offertförfrågningar
• halverad laddningstid i mobilen
• högst två klick från startsidan till kontaktformuläret
• 20 procent fler besök från Google till tjänstesidorna

Skriv också ner nuläget, om ni har det. Ett mål om fler förfrågningar säger ingenting om ingen vet hur många det är i dag.

Här blir område 1 användbart på riktigt. När målet står först går det att pröva varje önskad funktion mot det. En chatt ska finnas för att den minskar antalet samtal till kundtjänst, inte för att en konkurrent har en.

En funktion som inte går att koppla till något mål är inte nödvändigtvis fel. Men den ska kunna strykas först om budgeten inte räcker, och det ska stå i dokumentet.

Utan en definition går det inte att säga om den nya webbplatsen blev bättre. Skriv vad ni räknar som en konvertering: en kontakt, en bokning, en nedladdning, ett köp. Skriv också vart informationen ska ta vägen, till exempel till ert CRM, och om den ska bearbetas internt.

Det här är raden som oftast saknas. Lista de verktyg ni använder i dag, till exempel Google Analytics 4 eller Matomo för statistik och Google Tag Manager eller Meta Pixel för marknadsföring. Ange vilka som ska finnas på den nya webbplatsen, och om det är byrån, ni själva eller en tredje part som ansvarar för att de sätts upp.

Har ingen fått ansvaret tar ingen det.

Syfte: Webbplatsen ska generera fler förfrågningar från företagskunder.
Mål: 30 procent fler offertförfrågningar via webbplatsen inom tolv månader efter lansering, jämfört med samma period året innan.
Konvertering: En skickad offertförfrågan. Förfrågan ska hamna i vårt CRM.
Mätning: Google Analytics 4 och Google Tag Manager. Byrån sätter upp konverteringen och verifierar att den registreras före lansering. Vår marknadsansvarige äger kontona.

Fyra rader. Det räcker för att byrån ska förstå vad som ska byggas, och för att ni ska kunna utvärdera projektet efteråt.

Integrationerna är det dyraste och mest riskfyllda i ett webbprojekt. Kopplingen till CRM, affärssystem, bokning eller lager avgör ofta mer av priset än designen gör. När den är okänd räknar byrån på en webbplats som kanske inte är den som ska byggas.

I checklistan ligger integrationerna under område 2, funktionalitet. Vi lyfter ut dem, eftersom de förtjänar ett eget avsnitt i dokumentet.

Innan ni listar system: beskriv vad besökaren gör och vad som händer sedan. Besökaren fyller i formuläret, förfrågan hamnar i vårt CRM och säljaren får en avisering. Det behöver inte vara snyggt.

Går flödet inte att rita är ni inte redo att be om ett fast pris på integrationerna. Det gäller till exempel om ni ännu inte vet vilka system webbplatsen ska kopplas till. Be då byrån räkna på en förstudie som tar fram flödet, och be om fast pris efteråt. Det är ett typiskt uppdrag inom digital strategi.

För varje system webbplatsen ska kopplas till, svara på sex frågor:

1. Vilket system? Namnge det: HubSpot, Salesforce, Lime CRM, Fortnox, ert bokningssystem.
2. Vad ska skickas eller hämtas? Leads, kunddata, ordrar, produktdata, lagersaldo.
3. Åt vilket håll? Från webbplatsen till systemet, tillbaka, eller båda.
4. Hur ofta? I realtid, en gång per dygn eller när någon trycker på en knapp.
5. Vem äger systemet? Och finns det ett API, eller behöver det köpas till? Vet ni inte, skriv det och be byrån bedöma vilken typ av koppling som behövs.
6. Vad händer om kopplingen slutar fungera? Ska förfrågan sparas och skickas senare, eller räcker det att någon får ett larm?

Den sista frågan glöms nästan alltid. Den avgör om ett avbrott en fredagskväll kostar några förfrågningar eller en helg av förlorade ordrar.

Integration: Formulär till CRM.
System: HubSpot, som vi redan använder.
Data: Namn, företag, e-post, telefon och vilken tjänst förfrågan gäller.
Riktning och frekvens: Från webbplatsen till HubSpot, direkt när formuläret skickas.
Ägare: Vår marknadsavdelning. HubSpots API används.
Vid fel: Förfrågan sparas på webbplatsen och marknadsansvarig får ett mejl.

Skriv det. Det är bättre att skriva vi behöver en betallösning för företagskunder med faktura, och vill ha förslag än att välja ett system ni inte är säkra på. En erfaren byrå kan föreslå olika system utifrån era förutsättningar och behov.

Ska webbplatsen ha e-handel växer det här avsnittet: betalning, frakt, lager och PIM tillkommer, och e-handel omfattas dessutom av tillgänglighetslagen. Vår guide Upphandling av hemsida har en egen checklista för sju områden kopplade till e-handel.

Skriv in att alla integrationer ska vara dokumenterade, och att hela flödet ska testas före lansering, från första klick till att informationen har kommit fram. Det kostar lite i projektet och mycket om det saknas när någon annan ska förvalta webbplatsen.

Integrationerna och de större funktionerna avgör mer än priset. De avgör också vilken plattform som passar.

Olika CMS har olika förutsättningar. Vissa är byggda för att redaktörer snabbt ska kunna publicera sidor, andra för att hämta och skicka data mellan flera system. De skiljer sig i hur innehållet lagras, hur det går att återanvända i andra kanaler och hur enkelt det är att bygga kopplingar till CRM, affärssystem eller lager. Ett system som är utmärkt för en informationswebbplats kan bli dyrt och krångligt när det ska hantera produktdata i realtid, och tvärtom.

Därför är det riskabelt att låsa plattformen i kravspecifikationen innan ni har beskrivit vad webbplatsen ska göra. Står det "webbplatsen ska byggas i system X" räknar byrån på system X, även om behoven pekar på något annat. Upptäcks det mitt i projektet är det dyrt att byta plattform. Plattformen hör alltså till det som är dyrt att ändra, och just därför ska ni låsa behoven som avgör valet, inte systemet.

Gör så här i stället:

• Beskriv behoven, inte systemet. Vilka integrationer som behövs, vilka större funktioner ni ser framför er, hur många redaktörer som ska arbeta i systemet, hur många språk som behövs och om ni vill kunna bygga kampanjsidor själva.
• Be byrån föreslå ett CMS och motivera valet utifrån er kravspecifikation. Då blir motiveringen en del av anbudet, och ni kan jämföra hur väl olika byråer har förstått ert behov, inte bara vad de brukar arbeta med.
• Fråga hur valet påverkar framtiden. Finns det gott om utvecklare för systemet? Vad kostar licens och drift över tid? Ett ovanligt CMS kan göra er beroende av en enda leverantör.

Finns det skäl att välja system i förväg, till exempel en befintlig licens, en policy från IT eller ett system ni redan förvaltar, skriv det som ett krav och skriv varför. Då vet byrån att det är en förutsättning och inte en preferens.

Vill ni förstå skillnaderna mellan plattformarna innan ni pratar med byråerna går vår guide Välj rätt CMS igenom traditionella och headless system och sex vanliga plattformar.

Tre råd som gör störst skillnad:

Utse en person som äger dokumentet. Någon som har mandat att säga nej, och som läser hela kravspecifikationen i ett svep innan den skickas. Krav som krockar med varandra ger offerter som inte går att jämföra.

Pröva varje krav. Fråga: vem hos oss behöver det här, och vad händer om vi inte har det? Det krav ingen kan svara på stryks. Det gäller särskilt om dokumentet har skrivits med hjälp av AI, som vet vad en webbplats kan ha men inte vad just ni behöver.

Glöm inte den gamla webbplatsen. Kravspecifikationen beskriver den nya, men det som rankar och konverterar i dag ska bevaras, flyttas eller omdirigeras. Kräv en inventering innan designen börjar.

Mer om vad som brukar gå fel finns i Tio misstag vi ser i upphandlingar av hemsidor. Ska ni börja ännu tidigare, med en kortare beskrivning till byrån, se Brief till webbyrån.

Vad ska en kravspecifikation för en ny hemsida innehålla?
Tio områden: syfte och mål, funktionalitet, design och användarvänlighet, SEO och prestanda, innehållsstrategi, analysverktyg och spårning, tidsplan och budget, juridiska krav, intern projektorganisation samt förvaltning och support.

Vilka delar är viktigast?
Mål och mätning, integrationer, budget, lagkrav och vem som bestämmer. De är dyrast att ändra mitt i projektet och ska därför vara tydliga. Utformningen kan lämnas öppen för byråns förslag.

Hur detaljerad ska kravspecifikationen vara?
Så detaljerad att mål, flöden, integrationer och lagkrav är entydiga, och inte mer. En specifikation som låser varje sida och knapp gör projektet dyrt att ändra när ni lär er något nytt.

Ska vi bestämma CMS i kravspecifikationen?
Helst inte. Beskriv vad webbplatsen ska göra, vilka system den ska kopplas till och hur ni ska arbeta med innehållet, och be byrån föreslå ett CMS och motivera valet utifrån det. Olika plattformar har olika förutsättningar för integrationer och innehållsarbete. Har ni skäl att välja i förväg, till exempel en befintlig licens, skriv det som ett krav med motivering.

Måste vår hemsida uppfylla WCAG?
Det beror på verksamheten. Offentlig sektor omfattas av DOS-lagen. Sedan juni 2025 gäller tillgänglighetslagen också för bland annat e-handel och banktjänster som riktar sig till konsumenter. Båda utgår i praktiken från WCAG 2.1 nivå AA. Vår WCAG-guide går igenom vilka som omfattas.

Finns det en mall för kravspecifikation?
Ja. Checklistan i vår guide Upphandling av hemsida täcker alla tio områden och går att använda som mall rakt av.

Vad är skillnaden mellan en brief och en kravspecifikation?
En brief är en kort beskrivning av uppdraget som byrån kan ställa frågor utifrån. Kravspecifikationen är det dokument anbuden lämnas mot och ska vara tydlig nog att räkna på.

Ska ni ta fram en ny hemsida? Vår guide Upphandling av hemsida innehåller hela checklistan för de tio områdena, och en egen checklista för e-handel. Ladda ner guiden