Hoe je een webproject start: beslissingen eerst, technologie daarna

Een webproject begint vaak met de zin: “We hebben een nieuwe website nodig.” Al snel gaat het gesprek over het CMS, template, kleuren en lanceringsdatum. Nog steeds is niet duidelijk wat de nieuwe website moet veranderen.

Dat is een dure vergissing. Technologie kan heel snel iets opleveren dat het bedrijf niet nodig heeft.

Schrijf eerst op welke beslissing de website moet ondersteunen

Ik begin niet met een paginalijst. Ik begin met de situatie van het bedrijf en de bezoeker. Moet de site gekwalificeerde aanvragen opleveren, verkoopuitleg verkorten, zonder tussenkomst van een persoon verkopen, het supportwerk verminderen of het merk naar een andere categorie brengen?

Het doel moet naar een beslissing leiden. “Een modernere presentatie” is een wens. “Meer relevante aanvragen van productiebedrijven en minder vragen over eenmalige kleine opdrachten” maakt het al mogelijk om beslissingen te nemen over content, navigatie en meting.

  • Wie is belangrijk voor de website en in welke situatie komen zij daar terecht?
  • Wat moeten zij begrijpen, vergelijken of doen?
  • Welk bewijs kan het bedrijf eerlijk laten zien?
  • Welke volgende stap past bij hun bereidheid?
  • Hoe herkennen we verbetering na de lancering?

De contentstructuur komt vóór het wireframe

Pas daarna stel ik de informatiearchitectuur samen. De hoofdnavigatie moet de organisatiestructuur van het bedrijf niet kopiëren. Ze moet mensen helpen een antwoord te vinden en het aanbod te begrijpen.

Voor een bestaande site inventariseer ik eerst URL’s, verkeer, links en de daadwerkelijke content. Sommige pagina’s behoud ik, andere voeg ik samen, leid ik om of verwijder ik. Een migratie mag niet op indrukken worden gebaseerd. Een onaantrekkelijke pagina kan goede links hebben of relevante business opleveren; een veelbezochte pagina kan mensen aantrekken die volledig buiten het bedrijf vallen.

Voor SEO zijn een duidelijke structuur, interne links en content voor een echte doelgroep belangrijk. Google vat zijn vragen over bruikbaarheid samen in de gids voor people-first content. Een praktische SEO-basis staat ook in mijn artikel SEO voor beginners.

Een prototype moet de route controleren, niet indruk maken tijdens de vergadering

Eerst teken ik de belangrijkste routes uit zonder gedetailleerd ontwerp. Kan iemand begrijpen voor wie het bedrijf bedoeld is? Kunnen zij een dienst, bewijs, prijs of contactmethode vinden? Werkt de route op een smal mobiel scherm en met alleen een toetsenbord?

Ik zet echte koppen en ongeveer realistische tekstlengtes in het prototype. Lorem ipsum verbergt een probleem dat na oplevering op magische wijze terugkeert—meestal op de vrijdag vóór de lancering.

Kies technologie op basis van beheer

Een statische site, WordPress, een e-commerceplatform of een maatwerkapplicatie kan allemaal de juiste keuze zijn. Belangrijk zijn de benodigde bewerkingen, integraties, rechten, snelheid van wijzigingen, beveiliging, het budget en de mensen die de site na de lancering beheren.

De briefing moet ten minste bevatten:

  • eigenaarschap van het domein, accounts, broncode en analytics;
  • redactionele rollen en het publicatieproces;
  • formulieren, e-mailaflevering en koppeling met sales;
  • omleidingen voor oude URL’s en een aangepaste foutpagina;
  • back-ups, updates, monitoring en verantwoordelijkheid voor incidenten;
  • een beheersbudget, niet alleen een productiebudget.

Snelheid en toegankelijkheid zijn geen afwerking voor het einde

Een grote afbeelding, externe lettertypen en tien marketingscripts zijn eenvoudig toe te voegen. Iedere bezoeker betaalt vervolgens de prijs daarvan. Core Web Vitals volgen het laden van de hoofdcontent, responsiviteit en visuele stabiliteit; Google houdt actuele metingen en drempelwaarden bij in zijn documentatie over Web Vitals.

Daarom stel ik vóór het ontwerp een prestatiebudget vast: afmetingen en formaten van media, het aantal lettertypevarianten, regels voor scripts van derden en het gewenste gedrag op een gewone mobiele telefoon. Analytics moet laden zonder content te blokkeren en alleen gegevens verzamelen die beslissingen ondersteunen.

Ik pak toegankelijkheid tegelijkertijd aan: semantische HTML, zichtbare focus, bediening via het toetsenbord, contrast, labels voor formulieren en respect voor verminderde beweging. Dit is geen speciale versie van een website. Het is een goed gebouwde website.

Ontwerp de meting vóór de lancering

Na de lancering wil ik niet meer discussiëren over wat succes betekent. Ik leg gebeurtenissen en hun verband met beslissingen vast: een gekwalificeerde aanvraag verzonden, calculator gebruikt, belangrijk bewijs geopend of bestelling afgerond. Niet elke klik verdient een gebeurtenis.

Technische meting wordt behandeld in de Google Analytics 4-gids. Een bredere checklist staat in de online projectchecklist.

Een website is niet klaar bij de lancering

Tijdens de eerste weken monitor ik fouten, snelheid, indexering, formulieren en echte vragen van mensen. Daarna verbeter ik plaatsen waar de website een beslissing niet helpt. Niet na elke opmerking of op basis van één metric, maar volgens een combinatie van gegevens, feedback en bedrijfsimpact.

Een nieuwe website is niet het doel. Het is een nieuw besturingssysteem voor het bedrijf. Zonder eigenaar, budget en regels voor veranderingen begint de website al op de lanceringsdag te verouderen.

Als je al een website hebt en zwakke plekken wilt vinden, begin dan met Hoe je een website sneller maakt. Als je beslissingen vóór de productie op één lijn wilt brengen, bekijk dan hoe samenwerking werkt.

Behoefte aan duidelijkheid in marketing?

Laten we eerst de situatie helder maken.

Als jouw bedrijf voor een vergelijkbare beslissing staat, stuur me dan kort de context. Dan bekijken we of het zinvol is om verder te gaan.

Beschrijf de situatie