


Wat hoort er in een website briefing checklist?
Je hebt besloten dat je een website nodig hebt, maar weet niet goed waar je moet beginnen. Misschien heb je al wel een lijst met wensen gemaakt, maar vraag je je af of je alles hebt bedacht wat een websitebouwer nodig heeft. Deze website briefing checklist helpt je om eerst overzicht te krijgen.
Een briefing voor je website is een werkdocument: het beschrijft wat je website moet doen en maakt zichtbaar welke keuzes al vaststaan, nog open zijn of door iemand anders moeten worden uitgezocht. Het is geen eindproduct, maar een hulpmiddel om samen met een provider duidelijke afspraken te maken. Zo voorkom je dat je halverwege het project voor verrassingen komt te staan, zoals extra kosten, vertraging of onduidelijkheid over wie wat doet.
Deze website briefing checklist koppelt elke vraag aan een mogelijk gevolg voor je project. Dat kan gaan over de omvang (scope), de benodigde inspanning, verantwoordelijkheden, risico's of de aannames die een provider doet bij het maken van een offerte. Per punt geef je aan of je dat nu alvast kunt vastleggen (beslis nu), of je dat samen met een provider wilt verduidelijken, of dat het alleen nuttig is als je het toevallig al weet. Een open technische vraag is dus geen fout in je briefing, maar een signaal dat je die samen kunt oplossen.
Eerst zie je hoe de verschillende onderdelen van je briefing doorwerken in het project als geheel.
De gevolgen van je briefingkeuzes
Je antwoorden in de briefing werken niet los van elkaar. Samen bepalen ze wat er nodig is, wie iets moet doen en waar nog risico's zitten. Een duidelijke doelstelling helpt bijvoorbeeld om later te beslissen welke pagina's en functionaliteiten echt nodig zijn. En als je van tevoren weet wie je bezoekers zijn, kun je beter inschatten welke content en toegankelijkheidseisen belangrijk zijn.
Elk onderdeel van je briefing heeft invloed op minstens één van deze vijf gevolgen:
- Scope: Wat valt er wel en niet binnen het project?
- Inspanning: Hoeveel werk is er nodig om het te realiseren?
- Verantwoordelijkheden: Wie doet wat tijdens en na het project?
- Risico: Waar kunnen vertraging, extra kosten of miscommunicatie ontstaan?
- Offerte-aannames: Welke aannames doet een provider als jij iets niet specificeert?

Kijk bijvoorbeeld naar de lijnen tussen "Doelen en succes" en "Scope". Als je doel onduidelijk is, kan dat leiden tot een te brede scope, omdat de provider zelf aannames moet doen over wat er nodig is. Hetzelfde geldt voor andere onderdelen: een vage beschrijving van je doelgroep kan extra inspanning vragen om de juiste content te maken, en onduidelijke afspraken over verantwoordelijkheden kunnen later voor risico's zorgen.
Dit betekent dat elke sectie die je invult, je provider meer richting geeft. Ook als je niet alle antwoorden weet, helpt het om aan te geven wat je al wel weet en waar je hulp bij nodig hebt.
Nu de gevolgen zichtbaar zijn, kun je per vraag bepalen wat je meteen moet vastleggen en wat je samen met een provider kunt uitzoeken.
Beslis nu, verduidelijk later of noteer als voorkeur
Niet elk onderdeel van je briefing vraagt om dezelfde mate van zekerheid. Sommige keuzes zijn direct van invloed op de rest van het project, terwijl andere pas later relevant worden of zelfs helemaal niet nodig zijn. Gebruik de volgende indeling als hulpmiddel om te bepalen hoeveel aandacht elk punt verdient.
Beslis nu
Het hoofddoel van je website is een goed voorbeeld. Als je niet weet wat je website moet bereiken, is het lastig om later te bepalen welke pagina's, functionaliteiten en content nodig zijn. Een duidelijke doelstelling helpt je om gefocust te blijven en voorkomt dat het project onnodig uitdijt.
Verduidelijk met een provider
Technische vragen, zoals welk CMS of hostingpakket het beste past, kun je vaak beter samen met een provider beantwoorden. Jij weet wat je website moet kunnen, maar een provider kan je helpen om de beste technische oplossing te kiezen. Door deze vragen als open punten te markeren, voorkom je dat je zelf aannames doet die later niet kloppen.
Handig om te weten
Sommige voorkeuren zijn nuttig om te delen, maar blokkeren het project niet als ze nog niet bekend zijn. Denk bijvoorbeeld aan een bepaalde visuele stijl of een inspiratiesite. Deze informatie helpt een designer om een richting te kiezen, maar is niet essentieel om het project op te starten.
Deze indeling is een hulpmiddel, geen vaste regel. Afhankelijk van je project kunnen prioriteiten verschuiven. Het belangrijkste is dat je weet welke punten je nu al kunt vastleggen en welke vragen je meeneemt naar het gesprek met je provider.
Met die indeling kun je nu per onderdeel vastleggen wat je website nodig heeft en welk gevolg dat heeft.
Doelen, succes en grenzen van je project
Begin met het besluit dat je website moet ondersteunen. Wat wil je bereiken? Misschien wil je meer klanten werven, je dienstverlening beter uitleggen, een product verkopen of een praktische taak vereenvoudigen. Schrijf op wat je website moet doen, niet wat je denkt dat het moet kunnen.
Daarna maak je het succes herkenbaar. Hoe weet je of je website werkt? Dat kan bijvoorbeeld zijn dat er meer aanvragen binnenkomen, dat bezoekers langer op je site blijven of dat ze een bepaalde actie voltooien, zoals een bestelling plaatsen of een formulier invullen. Kies een of twee indicatoren die voor jouw situatie betekenisvol zijn, zonder je te laten leiden door standaardstatistieken.
Tot slot leg je de grenzen vast. Wat valt er buiten het project? Misschien wil je bepaalde doelgroepen of diensten bewust niet op je website hebben. Of zijn er technische of budgettaire beperkingen waar de provider rekening mee moet houden. Door deze grenzen op te schrijven, voorkom je dat het project onbedoeld groter wordt dan je wilt.
Onduidelijke doelen kunnen leiden tot een te brede scope en verschillende aannames bij providers. Als je bijvoorbeeld zegt dat je website "professioneel" moet zijn, kan de ene provider dat interpreteren als een uitgebreid design, terwijl een ander denkt aan een eenvoudige, functionele site. Door je doel en grenzen duidelijk te omschrijven, help je providers om een realistisch voorstel te doen.
Zodra het doel duidelijk is, volgt de vraag voor wie de website dat doel moet bereiken.
Wie je websitebezoekers zijn en wat ze nodig hebben
Beschrijf wie je websitebezoekers zijn, wat ze willen doen en welke informatie ze op dat moment nodig hebben. Begin met de primaire doelgroep: wie moet je website vooral bereiken? Dat kunnen bijvoorbeeld klanten zijn, maar ook leveranciers, medewerkers of andere belanghebbenden.
Vraag je vervolgens af wat deze bezoekers op je website willen doen. Moeten ze informatie vinden, een product bestellen, een afspraak maken of contact opnemen? Schrijf op welke taken ze willen voltooien en welke informatie ze daarvoor nodig hebben. Zo voorkom je dat je website vol staat met informatie die niemand gebruikt.
Denk ook aan de situatie waarin bezoekers je website gebruiken. Moeten ze bijvoorbeeld snel iets opzoeken op hun telefoon, of lezen ze uitgebreide informatie op een laptop? En zijn er specifieke toegankelijkheidseisen, zoals een duidelijke lettergrootte of vertalingen? Deze informatie helpt om je website gebruiksvriendelijker te maken.
Een vage beschrijving van je doelgroep maakt het lastiger om te bepalen welke content en functionaliteiten je website echt nodig heeft. Als je bijvoorbeeld niet weet dat je bezoekers vooral op hun telefoon je site bezoeken, kan dat leiden tot een design dat niet goed werkt op mobiele apparaten.
De behoeften van je bezoekers bepalen vervolgens wat er bij de start van de website beschikbaar moet zijn.
Wat er op je website moet staan en wie het aanlevert
Leg per belangrijke pagina vast waarom die nodig is, wat er bij de lancering beschikbaar moet zijn en wie het aanlevert. Begin met de pagina's die direct bijdragen aan je doel. Als je bijvoorbeeld meer klanten wilt werven, is een duidelijke homepage met een call-to-action essentieel. Voor een webshop zijn productpagina's en een winkelwagen natuurlijk onmisbaar.
Geef per pagina aan wat er bij de lancering beschikbaar moet zijn. Dat kan gaan om tekst, afbeeldingen, logo's, documenten of juridische pagina's zoals een privacyverklaring. Maak een onderscheid tussen content die al klaar is, content die nog gemaakt moet worden en content die later toegevoegd kan worden. Voorkom dat content die nog gemaakt moet worden, het project blokkeert.
Daarnaast is het belangrijk om vast te leggen wie verantwoordelijk is voor het aanleveren, controleren en goedkeuren van de content. Wie schrijft de teksten? Wie levert de afbeeldingen aan? En wie controleert of alles klopt? Door deze verantwoordelijkheden van tevoren te regelen, voorkom je vertraging en miscommunicatie.
Herinner je de vijf gevolgen die in de kaart staan: scope, inspanning, verantwoordelijkheden, risico en offerte-aannames. Content die ontbreekt of nog niet af is, kan effect hebben op de scope, de inspanning en de planning van je project. Door dit van tevoren in kaart te brengen, kun je realistisch plannen.
Als duidelijk is wat er moet staan, kun je bepalen welke visuele richting en ervaring daarbij passen.
Merk, stijl en referenties voor je website
Geef richting aan de uitstraling en gebruikservaring van je website, zonder een voorbeeldsite te behandelen als het definitieve ontwerp. Begin met wat je al hebt: een logo, huisstijlkleuren, lettertypes of fotografiestijl. Deze elementen helpen een designer om een consistent ontwerp te maken dat past bij je merk.
Daarna kun je referentiesites delen om uit te leggen wat je aanspreekt. Dat kan gaan om de structuur, de toon, de interactie of de algehele uitstraling. Beschrijf wat je goed vindt aan deze sites en waarom. Zo geef je een designer houvast, zonder dat je vastzit aan een specifiek ontwerp.
Denk ook aan de gebruikservaring. Moet je website bijvoorbeeld vooral mobielvriendelijk zijn? Of zijn er specifieke toegankelijkheidseisen, zoals een duidelijke navigatie voor mensen met een visuele beperking? En welke toon past bij je doelgroep: informeel, professioneel of iets daartussenin?
Houd er rekening mee dat referentiesites geen blauwdruk zijn voor je eigen website. Ze geven richting, maar het uiteindelijke ontwerp hangt af van je doel, doelgroep en beschikbare content. Vage richtlijnen kunnen leiden tot meer ontwerpwerk en verschillende aannames bij providers.
Daarna blijft vooral de vraag over wat je website technisch moet kunnen en welke punten je nog moet laten verifiëren.
Wat je website moet kunnen en waar je hulp bij nodig hebt
Beschrijf wat je website moet kunnen en welke technische vragen je samen met een provider wilt beantwoorden. Begin met de taken die je website moet ondersteunen. Moet je bijvoorbeeld een contactformulier hebben, een webshop, een afsprakensysteem of een ledenomgeving? Schrijf op wat bezoekers moeten kunnen doen, niet welke technische oplossing je denkt nodig te hebben.
Daarna kun je relevante verbindingen benoemen. Moet je website bijvoorbeeld gekoppeld worden aan een CRM-systeem, een betaalprovider, een boekingsplatform of een e-mailservice? Geef aan welke systemen er al zijn en welke afhankelijkheden er zijn. Zo kan een provider inschatten wat er nodig is om alles soepel te laten werken.
Vervolgens zijn er vragen over domein, hosting en CMS. Wie is de eigenaar van het domein? Welk hostingpakket heb je nodig? En welk CMS past het beste bij je wensen? Deze vragen kun je vaak beter samen met een provider beantwoorden, omdat er technische en praktische overwegingen zijn waar je zelf misschien niet aan denkt.
Daarnaast zijn er onderwerpen zoals privacy, cookies, formuliergegevens en toegankelijkheid. Wat zijn de huidige wettelijke eisen? Welke cookies worden er gebruikt en hoe vraag je toestemming? En hoe zorg je ervoor dat je website toegankelijk is voor iedereen? Deze vragen kun je het beste laten verifiëren door een provider of specialist, omdat de regels kunnen veranderen.
Als je al een website hebt, is het handig om te vragen welke opgebouwde problemen door snelle oplossingen (technical debt) er zijn. Misschien zijn er technische keuzes gemaakt die later aanpassingen moeilijker maken. Door dit van tevoren te bespreken, kun je samen met je provider een plan maken om deze problemen aan te pakken.
Onspecifieke functionaliteiten kunnen leiden tot een bredere scope en meer inspanning, terwijl onduidelijke afhankelijkheden het risico op vertraging of extra kosten vergroten. Door deze vragen van tevoren te stellen, help je je provider om een realistisch voorstel te doen.
Techniek is maar één deel van de voorbereiding; je moet ook weten wie beslist, wie toegang geeft en wie na de lancering verantwoordelijk blijft.
Wie wat doet, wanneer en met welk budget
Maak vooraf duidelijk wie wat beslist, welke randvoorwaarden gelden en wie wat doet na de lancering. Begin met de beslissers: wie heeft het laatste woord over het ontwerp, de content en de functionaliteiten? En wie moet er akkoord geven voordat de website live gaat? Door deze rollen van tevoren vast te leggen, voorkom je vertraging en miscommunicatie.
Daarnaast zijn er vaak planningseisen. Zijn er deadlines waar je aan moet voldoen? Zijn er afhankelijkheden, zoals een evenement of een marketingcampagne, die invloed hebben op de planning? Door deze informatie te delen, kan een provider een realistisch tijdschema maken.
Geef ook aan wat je budget is. Je hoeft geen exact bedrag te noemen, maar een richtprijs of een budgetrange helpt een provider om een passend voorstel te doen. Als je bijvoorbeeld zegt dat je budget tussen de €2.000 en €5.000 ligt, kan een provider inschatten wat er binnen dat budget mogelijk is. Dit voorkomt dat je offertes krijgt die ver buiten je budget vallen.
Vervolgens is het belangrijk om duidelijkheid te geven over eigendom en toegang. Wie is de eigenaar van het domein, de hosting en de CMS-accounts? En wie heeft er toegang tot deze accounts? Zorg ervoor dat je als opdrachtgever de controle houdt over je website, ook na de lancering. Dit voorkomt dat je later vastloopt omdat je geen toegang meer hebt.
Tot slot zijn er vragen over wat er na de lancering gebeurt. Wie is verantwoordelijk voor het onderhoud van de website? Wie zorgt ervoor dat de content up-to-date blijft? En wie helpt je als er technische problemen zijn? Door deze afspraken van tevoren te maken, voorkom je verrassingen achteraf.
Als je offertes van verschillende providers naast elkaar legt, let dan op of de scope, aannames, uitsluitingen, verantwoordelijkheden en ondersteuning consistent zijn beschreven. Zo voorkom je dat je appels met peren vergelijkt.
Onduidelijke verantwoordelijkheden of toegang kunnen leiden tot risico's bij de overdracht, terwijl ontbrekende leveringsaannames ervoor kunnen zorgen dat providers verschillende interpretaties hebben van wat er nodig is.
Als deze punten zijn vastgelegd, kun je controleren wat al bevestigd is en welke vragen nog mee moeten naar het gesprek.
Wat is bevestigd en wat staat nog open?
Je briefing hoeft niet perfect af te zijn; je moet vooral kunnen zien wat bevestigd is en wat nog openstaat. De checklist helpt je om te controleren of je de belangrijkste punten hebt vastgelegd. Het gaat niet om het invullen van alle details, maar om het in kaart brengen van wat je al weet en waar je nog hulp bij nodig hebt.
| Klaar? | Ja / Nee | |
|---|---|---|
| 1 |
Ik heb het hoofddoel en de doelgroep van mijn website helder
|
|
|
Een onduidelijk doel of vage doelgroep leidt vaak tot extra kosten en vertraging. Bedenk wat je website moet bereiken en voor wie, en schrijf dat kort op. |
||
| 2 |
Mijn launch-content en bijbehorende bestanden zijn beschikbaar Tekst, afbeeldingen, logo en eventuele juridische pagina's zijn aanwezig
|
|
|
Begin met de tekst voor de belangrijkste pagina's en verzamel afbeeldingen en logo's in één map. Dit voorkomt dat je halverwege het project stil komt te staan. |
||
| 3 |
Domeinnaam, hosting en CMS staan op mijn naam Met directe toegang voor mij als opdrachtgever
|
|
|
Als deze accounts niet op jouw naam staan, loop je het risico dat je na de lancering geen toegang meer hebt. Controleer de eigenaarschapgegevens en regel overzetten indien nodig. |
||
| 4 |
Benodigde inloggegevens en machtigingen zijn beschikbaar Inclusief eventuele tweestapsverificatie en shared-access afspraken
|
|
|
Zorg dat je alle inloggegevens hebt verzameld en dat de juiste mensen de juiste rechten hebben. Dit voorkomt blokkades tijdens het project. |
||
| 5 |
Ik heb mijn openstaande vragen voor de provider op een rij
|
|
|
Maak een eenvoudige lijst in een notitie-app of op papier. Zo voorkom je dat belangrijke vragen tijdens het gesprek vergeten worden. |
||
|
Kies Ja als het punt bevestigd is, Nee als er nog een gat is |
||
|
Je hebt één of meer punten nog niet bevestigd. Bekijk per rij de bijbehorende stap en neem die mee naar je gesprek met de provider. |
||
Deze checklist is een hulpmiddel om je voorbereiding te beoordelen. Als de meeste punten op "Ja" staan, ben je klaar voor een nuttig gesprek met een provider. Als er nog veel punten openstaan, kun je die meenemen als vragen of voorbereidingstaken. Het belangrijkste is dat je weet wat je al hebt vastgelegd en waar je nog hulp bij nodig hebt.
De checklist sluit af met een duidelijke voorbereiding: neem bevestigde punten mee, noteer wat nog openstaat en bespreek die vragen in het gesprek met een provider. Zo voorkom je dat je belangrijke zaken vergeet en kun je samen met je provider een realistisch plan maken.
Veelgestelde vragen over je website briefing checklist
Wat is technical debt en waarom is het belangrijk voor mijn websiteproject?
Technical debt verwijst naar problemen die ontstaan door snelle, tijdelijke oplossingen die later extra inspanning vragen om te herstellen. Zulke oplossingen kunnen aanpassingen moeilijker maken en de oplevering vertragen. Bespreek daarom bestaande technical debt met je provider, zodat duidelijk is welke problemen aandacht nodig hebben.
Hoeveel extra tijd kan een onduidelijke briefing kosten?
Een slecht uitgewerkte briefing werd door Econsultancy in verband gebracht met tot wel 30% meer ontwikkelingstijd. Dat is een toegeschreven schatting, geen vaste uitkomst voor ieder project. Onduidelijkheden kunnen extra werk veroorzaken wanneer de provider aannames moet doen of later ontbrekende informatie moet uitwerken.
Wie moet eigenaar zijn van het domein, de hosting en het CMS na de lancering?
Het uitgangspunt is dat jij als opdrachtgever de controle houdt over het domein, de hosting en de CMS-accounts. Een provider kan waar nodig gedelegeerde technische toegang krijgen. Leg ook vast wie beheerdersrechten heeft en hoe je die toegang na de lancering beheert.
Wat hoort er in een volledig overdrachtspakket na de lancering?
Een volledig overdrachtspakket kan het volgende bevatten:
- inloggegevens en toegangsrechten voor het domein, de hosting en het CMS
- een README met technische informatie
- een inventaris van content en media
- opnames van trainingssessies
- beveiligingscontroles en acceptatietests
Stem af welke documentatie en training passen bij de taken die je na de lancering zelf uitvoert.
Moet ik een budgetrange opgeven en waarom helpt dat?
Een realistische budgetrange helpt providers om voorstellen te maken die beter aansluiten op wat je wilt bereiken. Je kunt offertes daardoor beter met elkaar vergelijken. Een range geeft ook eerder aan welke verwachtingen binnen het beschikbare budget passen, maar is geen garantie voor een bepaald eindbedrag.
Waarom is een verkenningsfase waardevol voor mijn project?
Een verkenningsfase helpt om aannames te toetsen, eisen te verduidelijken, werk te prioriteren en risico's vóór de ontwikkeling zichtbaar te maken. Ook kunnen jij en je provider afstemmen wie welke beslissingen neemt. De precieze invulling hangt af van de omvang en complexiteit van je project.
Wat zijn MoSCoW en Must-Should-Could?
MoSCoW en een indeling in Must, Should en Could zijn manieren om eisen en wensen te ordenen. Must-items zijn nodig voor de lancering. Should-items zijn belangrijk, maar niet noodzakelijk om live te gaan. Could-items zijn extra wensen die later kunnen worden toegevoegd. Bij MoSCoW staat Won't voor wat je in deze versie niet opneemt. Zo worden keuzes en afwegingen zichtbaar, zonder dat één methode voor ieder project verplicht is.
Gerelateerde blogs
Meer weten? In ons blog delen we praktische kennis over webdesign, development, SEO, AI en trends