Hur man skriver en brief för ett webbprojekt (och varför de flesta är fel)

De flesta webbprojekt vinns eller förloras innan någon öppnar ett designverktyg eller skriver en rad kod. De vinns eller förloras i briefen.

Briefen är dokumentet, eller samtalet, som berättar för de personer som bygger din website vad de faktiskt bygger och varför. Gör det rätt och utförandet blir tydligt, omfattningen hålls hanterbar och resultatet gör det som behövs. Gör det fel och du tillbringar de kommande tre månaderna med att ha samma samtal om felinriktade förväntningar.

Det vanligaste problemet med webbriefer är detta: de beskriver en lösning istället för ett problem.

Vad en brief brukar säga

En typisk brief ser ut ungefär så här: vi behöver en ny website med en startsida, en om-sida, en tjänstesektion, en blogg och ett kontaktformulär. Vi vill att den ska kännas modern och professionell. Vi vill att den ska fungera på mobil. Vi vill ha den klar på åtta veckor.

Det är en specifikation, inte en brief. Den berättar för teamet vad de ska bygga. Den berättar inte vilket problem de löser, för vem de löser det eller hur framgång ser ut.

Teamet bygger exakt det de ombeds att bygga. Det lanseras. Och sedan inser kunden att den nya sidan inte konverterar bättre än den gamla, eftersom briefen inte sa något om konvertering. Den var optimerad för leverans, inte för resultat.

Vad en brief borde säga

En bra brief är byggd kring ett problem, inte en lösning. Den besvarar fyra frågor innan något annat:

Vad försöker verksamheten uppnå? Inte "en bättre website". Vad är det faktiska målet? Fler kvalificerade leads, lägre avhopp på en specifik sida, möjligheten att ta emot kunder utan ett säljsamtal, eller något annat konkret.

Vem är detta för? Inte en allmän beskrivning av en målmarknad. En specifik person, i ett specifikt sammanhang, som fattar ett specifikt beslut när de kommer till sidan. Ju mer specifikt detta är, desto mer användbart blir det som vägledning för varje design- och innehållsbeslut.

Vad är den nuvarande situationen och vad är fel med den? Vad gör sidan nu? Vad fungerar inte? Vad gör människor när de landar på den? Detta ger teamet den utgångspunkt de behöver för att förstå vad förändring faktiskt innebär.

Hur ser framgång ut, specifikt? Inte "mer trafik". Ett mätbart resultat: en konverteringsgrad på en specifik sida, ett antal inkommande förfrågningar per månad, en minskning av supportvolymen eftersom FAQ:n besvarar fler frågor. Något du kan kontrollera senare.

De fem saker som en bra brief innehåller

När problemet är tydligt bör en bra brief också innehålla: affärskontexten, målgruppen, det specifika framgångsmåttet, begränsningarna (budget, tidsplan, teknisk miljö) och listan över vad som uttryckligen är utanför scope.

Den sista är underskattad. Utanför scope handlar inte bara om att begränsa arbetet. Det handlar om att samordna förväntningar innan projektet startar. Den vanligaste källan till scope creep är saker som aldrig tydligt uteslöts. Om du inte säger att briefen inte inkluderar copywriting är antagandet att någon hanterar det. Specificera vad som inte ingår och du undviker en hel del friktion.

Vad som förändras när briefen är rätt

När en brief är byggd kring ett problem istället för en lösning kan de som utför den fatta bättre beslut i varje steg. De vet när ett designval tjänar målet och när det inte gör det. De vet när en funktionsbegäran är värd den extra komplexiteten och när det är scope som inte kommer att flytta nålen.

De kan också säga ifrån när något inte är meningsfullt, eftersom de förstår varför bakom projektet. Den motpressen är värdefull. Det är det som skiljer ett team som bygger det du bad om från ett team som hjälper dig att bygga det du faktiskt behöver.

Briefen är ingen formalitet. Den är grunden. Och den bästa tiden att få den rätt är innan någon börjar bygga.

Om du vill ha hjälp med att skriva en brief inför ditt nästa webbprojekt, låt oss arbeta igenom det tillsammans.