Een briefing voor een nieuwe website is geen verlanglijst met mooie voorbeelden. Het is een document waarmee een ontwerper, ontwikkelaar en contentspecialist begrijpen welk probleem ze samen moeten oplossen. Hoe scherper de uitgangspunten, hoe beter voorstellen te vergelijken zijn.
Je hoeft niet vooraf alle technische antwoorden te kennen. Een goede briefing maakt juist zichtbaar waar advies nodig is. Dat voorkomt dat een bureau aannames in de offerte verwerkt die pas tijdens de bouw worden ontdekt.
Begin met de situatie, niet met het ontwerp
Beschrijf kort wat je organisatie aanbiedt en waarom de huidige website niet meer voldoet. Maak het concreet. Zijn bezoekers onduidelijk over het aanbod? Komen formulieren niet goed binnen? Kost het team te veel tijd om pagina’s te beheren? Deze problemen vragen om verschillende oplossingen.
Voeg voorbeelden toe die je zelf kunt onderbouwen. Een bericht van een klant over een onduidelijke boekingsstap is bruikbaarder dan “de gebruikerservaring moet beter”. Gebruik waar mogelijk geanonimiseerde voorbeelden; klantgegevens horen niet onnodig in een briefing thuis.
Beschrijf de bezoeker en de gewenste handeling
Kies de belangrijkste doelgroep voor de eerste versie. Noteer welke informatie die doelgroep nodig heeft voordat iemand contact opneemt. Voor een zakelijke dienst kan dat de aanpak en minimale projectomvang zijn. Voor een webshop gaat het eerder om productkeuze, levering en retourneren.
Beschrijf daarna de gewenste handeling. “Meer conversies” is onvoldoende specifiek. “Een aanvraag indienen met bedrijfsnaam, vraagstuk en gewenste startperiode” geeft de bouwer een duidelijker uitgangspunt. Laat vervolgens beoordelen welke velden werkelijk nodig zijn.
Leg functies en inhoud apart vast
Een veelgemaakte verwarring is dat een pagina en een functie als hetzelfde worden behandeld. Een contactpagina is inhoud; een formulier met CRM-koppeling, foutafhandeling en automatische ontvangstbevestiging is functionaliteit.
Maak voor iedere bijzondere functie duidelijk wat er vóór, tijdens en na de handeling gebeurt. Wie ontvangt de aanvraag? Waar worden gegevens opgeslagen? Wat gebeurt er wanneer de koppeling tijdelijk niet werkt? Bespreek complexe processen vroeg met een partner voor API-koppelingen en integraties.
Vermeld ook wie teksten, fotografie en productinformatie aanlevert. “Content door opdrachtgever” klinkt helder, maar zegt niets over redactie, invoer, vertaling of controle.
Gebruik referenties als uitleg
Voeg hooguit enkele relevante websites toe en schrijf erbij welk onderdeel je aanspreekt. Bijvoorbeeld: de duidelijke dienstnavigatie, leesbare prijsopbouw of rustige mobiele presentatie. Vraag niet om een kopie. De inhoud, rechten en technische omstandigheden van een ander bedrijf kunnen volledig verschillen.
Een nuttige voorbeeldzin is: “We willen dat bezoekers zonder jargon kunnen kiezen tussen onze drie diensten. De vorm staat open, zolang het verschil duidelijk is.” Dat geeft richting zonder het ontwerp onnodig vast te zetten.
Maak voorstellen vergelijkbaar
Vraag ieder bureau dezelfde onderdelen te beantwoorden: aanpak, inbegrepen werkzaamheden, uitsluitingen, afhankelijkheden, eigendom, beheer en acceptatie. Laat aannames expliciet benoemen. Een goedkope offerte die geen contentmigratie bevat, is niet rechtstreeks vergelijkbaar met een voorstel waarin dat wel is opgenomen.
Google benadrukt inhoud die voor mensen is gemaakt. Vraag daarom niet alleen om “SEO-teksten”, maar om teksten die echte klantvragen beantwoorden en bij het aanbod passen.
Axtivons webontwikkeling kan vanuit zo’n briefing worden afgebakend. Sluit het document af met je open vragen. Een bureau dat daarop inhoudelijk reageert, geeft je meer houvast dan een voorstel dat alleen het gewenste aantal pagina’s herhaalt.