Wat er in een goede briefing staat
Een briefing hoeft geen dik document te zijn. Wel moet hij de vragen beantwoorden die anders halverwege het project alsnog gesteld worden — dan zijn ze duurder.
01
Begin bij het doel, niet bij de pagina's
De eerste zin van een briefing hoort te zeggen wat de site of app moet opleveren: aanvragen, afspraken, bestellingen, sollicitanten of minder telefoontjes. Zolang dat er niet staat, is elke discussie over kleuren en menu's een discussie zonder maatstaf.
Daaronder hoort wie het gaat gebruiken en met welke vraag in zijn hoofd. Een monteur op een dak, een klant die 's avonds op de bank zoekt, een inkoper die drie leveranciers vergelijkt: dat leidt tot verschillende keuzes.
En hoe je over een tijdje weet of het gelukt is. Vaak is dat gewoon te tellen. Als niemand het telt, is het geen doel maar een wens.
02
De feiten die je toch moet aanleveren
Bedrijfsgegevens zoals ze overal moeten kloppen: naam, adres, telefoonnummer, openingstijden, werkgebied, KvK en btw. Deze gegevens komen ook in de structuurdata terecht, dus verschillen tussen je site, je bedrijfsprofiel en gidsen werken tegen je.
Prijzen of prijsindicaties, voorwaarden, garanties, certificeringen en verzekeringen. Wat je niet wilt noemen is ook een keuze, maar besef dat bezoekers die informatie ergens anders gaan zoeken.
Beeld en teksten, of de afspraak wie ze maakt. Een project dat op voorbeeldtekst wordt ontworpen, moet aan het eind altijd worden bijgesteld — en dan is bijstellen duur.
Toegang: domeinnaam, huidige hosting, analytics, het bedrijfsprofiel bij Google en de systemen waarmee gekoppeld moet worden. Die accounts horen op naam van je eigen bedrijf te staan.
03
Wat je juist niet moet dichttimmeren
Een briefing die per pagina de indeling voorschrijft, sluit betere oplossingen uit. Beschrijf liever wat een bezoeker op die plek moet kunnen — dan mag de vorm daaruit volgen.
Hetzelfde geldt voor techniek. 'Het moet in dit systeem' kan een goede eis zijn als je er al mee werkt, maar als het alleen komt doordat iemand die naam ergens hoorde, beperkt het onnodig.
Wel scherp zijn op randvoorwaarden die echt vastliggen: koppelingen die moeten werken, huisstijl die er al is, talen, wettelijke eisen en wie er intern moet meebeslissen. Dat laatste bepaalt vaak meer aan het tempo dan alle techniek bij elkaar.
- Eén zin met het doel, en hoe je het gaat tellen
- Wie het gebruikt, en met welke vraag
- Bedrijfsgegevens, prijzen, voorwaarden, beeld en teksten
- Toegang tot domein, hosting en de systemen die mee moeten doen
- Randvoorwaarden wél vastleggen, de vorm niet dichttimmeren
Korte vragen bij dit onderwerp
Moet ik de teksten zelf schrijven?
Niet per se, maar de kennis moet wel van jou komen. In de praktijk levert een gesprek per onderwerp meer bruikbaar materiaal op dan een verzoek om zelf te schrijven: vertellen gaat de meeste mensen makkelijker af. Wat je daarna controleert zijn de feiten, niet de stijl.
Hoe uitgebreid moet een briefing zijn?
Twee pagina's die de juiste dingen zeggen zijn beter dan twintig die alles beschrijven behalve het doel. Als doel, doelgroep, feiten en randvoorwaarden erin staan, kan een bureau er iets mee — de rest komt uit het gesprek.
Kennisbank
Een vraag die hier niet bij staat?
Stel hem gerust. Plaincodelab antwoordt ook als het antwoord is dat je iets niet nodig hebt.