Een website plannen: de complete handleiding
De meeste webontwikkelprojecten lopen niet uit omdat de code lastig was. Ze lopen uit omdat het plan mager was: niemand was het eens over wat de site moest bereiken, wie de teksten zou schrijven, of wat «klaar» betekende.
Deze gids behandelt het planwerk dat aan ontwerp en bouw voorafgaat, in de volgorde waarin het werkelijk nuttig is, en de beslissingen die later duur zijn om te wijzigen.
Begin met één taak die de site moet vervullen#
Een website die alles moet doen, bereikt meestal niets meetbaars. Schrijf vóór alles de ene handeling op die het meest telt: een verstuurd formulier, een telefoontje, een aankoop, een boeking, een download.
Al het andere — paginastructuur, navigatie, wat bovenaan staat, hoeveel je moet uitgeven — volgt uit dat antwoord. Een site met als hoofdtaak aanvragen genereren is een ander project dan een site met als hoofdtaak 4.000 producten verkopen.
- Hoofddoel: de ene handeling die je zou behouden als je er maar één mocht behouden.
- Nevendoelen: nuttig, maar niet de moeite waard om het hoofddoel voor in te leveren.
- Hoe je het meet: een getal dat je volgend kwartaal kunt nakijken, niet «meer verkeer».
- Wat de site niet hoeft te doen: opgeschreven, zodat het buiten scope blijft.
Als twee mensen in jouw organisatie verschillende hoofddoelen zouden noemen, duikt dat meningsverschil in week zes van de bouw op. Los het op in week nul, wanneer het een vergadering kost in plaats van een herbouw.
Weet wie er binnenkomt en waarvoor#
Doelgroeponderzoek hoeft geen formele exercitie te zijn. Wat je nodig hebt is een korte, eerlijke beschrijving van de twee of drie groepen die daadwerkelijk langskomen, met welke vraag ieder aankomt en wat hen zou wegjagen.
| Bezoeker | Komt met de vraag | Vertrekt omdat |
|---|---|---|
| Eerste koper | Kunnen deze mensen wat ik nodig heb? | Geen bewijs, geen prijzen, geen duidelijkheid |
| Terugkerende klant | Waar is wat ik nu nodig heb? | De taak ligt drie kliks diep begraven |
| Iemand die vergelijkt | Waarin verschilt dit van de rest? | Algemene teksten die bij elke concurrent zouden passen |
| Een sollicitant | Hoe is het om hier te werken? | Geen vacaturepagina, of een verouderde |
Bepaal de pagina's vóór het ontwerp#
De paginastructuur is op papier het goedkoopst te wijzigen en na goedkeuring van een ontwerp een van de duurste dingen om te wijzigen. Zet elke pagina op een rij, groepeer ze in secties, en markeer welke nodig zijn voor de lancering en welke later kunnen komen.
De gebruikelijke misser is een structuur die je organogram weerspiegelt in plaats van de taak van de bezoeker. Niemand komt binnen op zoek naar jouw «afdeling Oplossingen»; men zoekt waar men behoefte aan heeft.
- Zet elke pagina die je denkt nodig te hebben op een eigen regel, zonder te groeperen.
- Markeer elke pagina als lanceringkritiek of later. Wees streng: de meeste sites gaan live met minder pagina's dan gepland.
- Groepeer de kritieke pagina's in hoogstens vijf of zes secties op het hoogste niveau.
- Schrijf de ene zin op die elke pagina moet overbrengen. Lukt dat niet, dan hoort die pagina er waarschijnlijk niet te zijn.
- Controleer of het hoofddoel vanaf elke pagina op het hoogste niveau in één klik bereikbaar is.
Content is het kritieke pad: plan het eerst#
Teksten, foto's en productgegevens houden meer lanceringen op dan welk technisch probleem ook. De bouw is af en de site staat zes weken op de testomgeving te wachten op een pagina «Over ons».
Bepaal nu wie welke pagina schrijft, wie goedkeurt en wanneer het af moet zijn — en neem die data net zo serieus als de ontwikkelmijlpalen. Heeft intern niemand tijd, begroot dan een tekstschrijver; dat is goedkoper dan een stilstaand ontwikkelteam.
- Wijs per tekstpagina een verantwoordelijke en een datum aan, niet «marketing».
- Bepaal wat er met bestaande content gebeurt: migreren, herschrijven of schrappen. Het meeste zou geschrapt moeten worden.
- Boek fotografie vroeg: dat heeft de langste doorlooptijd van de hele lijst.
- Exporteer en schoon voor een webshop de productgegevens vóór de start op, niet tijdens.
- Spreek af wie de eindgoedkeuring geeft. Twee goedkeurders met gelijke bevoegdheid is een planningsrisico.
Een nuttige toets: als de site morgen af was, zou je hem kunnen vullen? Is het antwoord nee, dan is content je echte deadline.
Stel een budgetbandbreedte vast en kies de bouwaanpak#
Planning eindigt met twee getallen en één keuze: wat je kunt uitgeven, wanneer het live moet, en of dit een sjabloon, een CMS of maatwerk wordt. Die drie bepalen met wie je überhaupt zou moeten praten.
| Aanpak | Past wanneer | Belangrijkste risico |
|---|---|---|
| Websitebouwer | Kleine brochuresite, geen ongebruikelijke eisen | Je loopt tegen een plafond en moet opnieuw beginnen |
| CMS (bijv. WordPress) | Contentgedreven site, vaak bijgewerkt door niet-ontwikkelaars | Wildgroei aan plug-ins en doorlopend onderhoud |
| E-commerceplatform | Productverkoop, standaard afrekenbehoeften | Platformkosten en beperkte aanpasbaarheid |
| Maatwerk | De site is het product, of koppelingen sluiten de rest uit | Hoogste kosten, en het onderhoud is van jou |
Veelgestelde vragen
Hoelang zou de planning moeten duren?
Voor een site van een klein bedrijf één tot twee weken echt werk — geen doorlooptijd. Voor een webshop of een applicatie drie tot zes weken, grotendeels besteed aan contentinventarisatie en productgegevens in plaats van aan documenten. Duurt de planning maanden, dan is het hoofddoel meestal niet vastgelegd en draait de discussie in kringetjes.
Heb ik een formeel eisendocument nodig?
Je hebt iets op schrift nodig waar beide partijen naar kunnen wijzen, maar het hoeft niet lang te zijn. Een paginastructuur, een lijst met functies binnen scope, een lijst met wat er expliciet buiten valt, en een contentverantwoordelijke per pagina voorkomen meer geschillen dan een specificatie van vijftig pagina's die niemand leest. De uitsluitingenlijst is het deel dat men overslaat en het deel dat het project redt.
Moet ik in deze fase het ontwerp plannen?
Plan de structuur, niet het uiterlijk. Bepalen welke pagina's er zijn en wat elke pagina moet bereiken is plannen; kleuren en lettertypen kiezen is ontwerpen, en dat doen vóór de structuur bestaat betekent dat het ontwerp wordt omgegooid zodra de echte content arriveert. Wireframes zijn het nuttige midden.
En als de eisen halverwege veranderen?
Dat gebeurt. Wat telt is dat je vooraf hebt afgesproken hoe wijzigingen worden afgehandeld: wie er een mag aanvragen, wie hem beprijst, en of hij de lanceerdatum verschuift. Een project met een wijzigingsproces loopt beheerst uit; een project zonder loopt uit in een ruzie.
website plannenwebsiteplanningwebproject planwebsite eisenwebsitestructuurwebontwikkeling plannen
