Nieuwe website laten maken? Maak eerst deze projectbrief

Wanneer ben je klaar om offertes aan te vragen?

Je hoeft nog geen sitemap, technisch plan of volledig ontwerp te hebben. Je bent klaar om offertes aan te vragen zodra je de volgende vragen in gewone taal kunt beantwoorden:

• Welk bedrijfsprobleem moet de website oplossen?
• Wie zijn de belangrijkste bezoekers?
• Wat moeten die bezoekers op de website kunnen begrijpen of doen?
• Welke informatie is al beschikbaar en wat moet nog worden gemaakt?
• Welke functies zijn noodzakelijk bij de eerste lancering?
• Wie neemt beslissingen en wie beheert de website daarna?
• Welke grenzen zijn er rond budget, planning of bestaande systemen?

“Wij hebben een nieuwe website nodig” is nog geen projectdoel. “Bezoekers moeten binnen enkele minuten kunnen beoordelen of onze dienst past en daarna gericht een aanvraag kunnen indienen” is dat wel.

Die formulering helpt een leverancier om keuzes te maken. Misschien is een compacte website voldoende. Misschien zijn meerdere landingspagina’s nodig. Misschien ligt het echte probleem niet in het ontwerp, maar in onduidelijke diensten, ontbrekend bewijs of een omslachtig aanvraagproces.

Wie gebruikt de website en wat moeten zij kunnen doen?

Begin niet bij pagina’s. Begin bij mensen en taken.

Beschrijf per belangrijke doelgroep:

1. Wie is deze bezoeker?
2. Met welke vraag of situatie komt die persoon binnen?
3. Welke informatie heeft die persoon nodig om verder te gaan?
4. Welke actie moet eenvoudig en logisch voelen?
5. Welke twijfel kan die actie blokkeren?

Een zakelijke website kan bijvoorbeeld meerdere soorten bezoekers hebben: een potentiële klant die een oplossing vergelijkt, een bestaande klant die informatie zoekt, een sollicitant die het bedrijf wil begrijpen of een partner die betrouwbaarheid controleert.

Niet iedere bezoeker verdient een eigen pagina. Wel moet iedere belangrijke taak ergens duidelijk worden ondersteund. Dat voorkomt een website die vooral vertelt wat het bedrijf wil zeggen, maar niet beantwoordt wat de bezoeker probeert uit te zoeken.

Welke pagina’s en content zijn werkelijk nodig?

Een pagina hoort een duidelijke functie te hebben. Veel websites worden onnodig groot omdat ieder onderwerp automatisch een aparte pagina krijgt. Andere websites worden juist te klein doordat verschillende vragen op één algemene pagina worden samengeperst.

Gebruik voor iedere mogelijke pagina deze test:

• Heeft de bezoeker hier een herkenbare, zelfstandige vraag?
• Is er genoeg unieke informatie om die vraag goed te beantwoorden?
• Hoort er een andere vervolgstap bij dan op bestaande pagina’s?
• Kan de pagina onderhouden worden wanneer informatie verandert?

Een eerste versie bevat meestal alleen pagina’s die nodig zijn om het aanbod te begrijpen, vertrouwen op te bouwen en een passende vervolgstap te nemen. Content die nog geen duidelijke taak heeft, kan later worden toegevoegd.

Maak ook onderscheid tussen aanwezige en ontbrekende content. Denk aan:

• dienstbeschrijvingen;
• foto’s of visualisaties;
• projecten en voorbeelden;
• werkwijze;
• veelgestelde vragen;
• voorwaarden, privacy en bedrijfsgegevens;
• formulieren, bevestigingsberichten en foutmeldingen.

De tekst op knoppen, formulieren en bevestigingspagina’s is ook content. Neem die mee in de scope.

Welke functies en koppelingen horen in de eerste versie?

Een functie is alleen waardevol wanneer die een taak aantoonbaar eenvoudiger, sneller of betrouwbaarder maakt. “We willen een dashboard” of “er moet AI in” beschrijft een middel, geen resultaat.

Verdeel functies daarom in drie groepen:

Moet bij lancering werken

Zonder deze functie kan de website haar hoofdtaak niet uitvoeren. Bijvoorbeeld een passend aanvraagformulier, meertaligheid wanneer de doelgroep dat vereist of een noodzakelijke koppeling met een bestaand proces.

Mag na lancering volgen

Deze functie heeft waarde, maar de eerste versie kan zonder. Door dit apart te zetten, voorkom je dat een nuttige lancering wordt uitgesteld door onderdelen die nog niet bewezen zijn.

Alleen onderzoeken

Sommige wensen zijn nog aannames. Noteer dan eerst wat je wilt leren. Een prototype, handmatige tussenstap of beperkte test kan voldoende zijn voordat er een volledige functie wordt gebouwd.

Beschrijf bij iedere koppeling welke informatie van systeem A naar systeem B moet, wanneer dat gebeurt en wat er moet gebeuren als iets mislukt. Dat geeft veel meer duidelijkheid dan alleen de naam van een softwarepakket noemen.

Wie bezit en onderhoudt content, domein en techniek?

Een website is niet alleen het zichtbare ontwerp. Vraag vooraf wie eigenaar is van en toegang houdt tot:

• de domeinnaam;
• hosting en DNS-instellingen;
• broncode en ontwerpbestanden;
• het contentmanagementsysteem;
• analytics- en advertentieaccounts;
• formulieren en ontvangen gegevens;
• licenties, lettertypen en beeldmateriaal;
• documentatie en back-ups.

Leg ook vast wie verantwoordelijk is voor updates. Een website kan technisch blijven functioneren terwijl inhoud langzaam veroudert. Denk daarom niet alleen aan softwareonderhoud, maar ook aan prijzen, diensten, teaminformatie, projecten, juridische pagina’s en contactgegevens.

Vraag bij een afhankelijkheid altijd: wat gebeurt er wanneer de samenwerking stopt? Kun je de website verhuizen? Blijven formulieren werken? Kun je zelf content exporteren? Zijn er onderdelen waarvoor je doorlopend een specifieke leverancier nodig hebt?

Duidelijk eigendom voorkomt dat een lage startprijs later verandert in een kostbare afhankelijkheid.

Budget, planning en een invulbare projectbrief

Een budget hoeft geen kunstmatig precies bedrag te zijn. Een bandbreedte is vaak voldoende. Vermeld daarnaast wat binnen dat budget moet vallen: strategie, ontwerp, ontwikkeling, teksten, fotografie, koppelingen, hosting, onderhoud of ondersteuning na lancering.

Voor de planning zijn vooral afhankelijkheden belangrijk. Wie levert content aan? Wie keurt beslissingen goed? Is er een campagne, verhuizing of andere harde datum? Hoeveel feedbackrondes zijn intern realistisch?

Kopieer onderstaande projectbrief en vul hem zo concreet mogelijk in.

Projectbrief voor een nieuwe website

Bedrijf en aanbod
Wat doet het bedrijf, voor wie en in welke markt?

Aanleiding
Waarom is een nieuwe website nu nodig? Wat werkt niet goed genoeg in de huidige situatie?

Gewenst resultaat
Wat moet na lancering aantoonbaar beter of eenvoudiger zijn?

Belangrijkste bezoekers
Wie gebruiken de website en met welke vragen komen zij binnen?

Belangrijkste acties
Wat moeten bezoekers kunnen doen? Rangschik deze acties op belangrijkheid.

Benodigde pagina’s
Welke pagina’s lijken noodzakelijk en welke vraag beantwoordt iedere pagina?

Beschikbare content
Welke teksten, beelden, projecten, documenten en bedrijfsgegevens bestaan al?

Ontbrekende content
Wat moet nog worden geschreven, gefotografeerd, ontworpen of goedgekeurd?

Functies en koppelingen
Wat moet bij lancering werken, wat kan later en wat moet eerst worden getest?

Technische randvoorwaarden
Welke bestaande systemen, accounts, talen, apparaten of beveiligingseisen spelen mee?

Eigendom en beheer
Wie moet eigenaar zijn van domein, hosting, code, content en accounts? Wie onderhoudt wat?

Budget
Wat is de realistische bandbreedte en welke onderdelen moeten daarin zijn opgenomen?

Planning
Is er een harde datum? Welke interne beslissingen of leveringen bepalen de voortgang?

Selectiecriteria
Waarop vergelijk je aanbieders behalve prijs?

De projectbrief is geen technische specificatie

De projectbrief hoeft de oplossing niet voor te schrijven. Het doel is juist dat een leverancier kan beoordelen wat de kleinste oplossing is die het probleem volledig oplost en ruimte laat om later verantwoord uit te breiden.

Bekijk hoe Omnitechs een websiteproject benadert, welke soorten websites we maken en welke keuzes zichtbaar worden in onze projecten.