Dit is het derde artikel in een reeks artikelen over het tot stand komen van een maatwerk-website. Een introductie en het artikel over de Analysefase gingen hier reeds aan vooraf. Per fase wordt een omschrijving van de acties, de deliverables en de valkuilen gegeven. De tweede fase is in ons model is de Ontwerpfase. Het doel van deze fase is het vastleggen en vertalen van de geïnventariseerde informatie in diverse ontwerpen.

Het proces is als volgt gefaseerd:

• Analysefase
• Ontwerpfase
  • Functioneel Ontwerp
  • Technisch Ontwerp
  • Grafisch Ontwerp
• Bouwfase
• Kwaliteitfase
• Acceptatiefase
• Lanceerfase

De noodzaak van ontwerpen

Allereerst de vraag: zijn ontwerpen wel nodig? Als je geen belang hecht aan fixed price, een strakke planning, of vooraf weten wat je kunt verwachten, kan het antwoord nee zijn. Het wordt lastiger als je een van genoemde zaken van te voren wel scherp wil hebben. Maak dan een ontwerp van te voren! Vooraf ontwerpen levert minimaal de volgende voordelen: efficiency tijdens de bouw, hogere kwaliteit, een beter te managen project, een strakkere planning, minimalisatie van risico’s  en gelijkgestemde verwachtingen bij klant en leverancier.

Na een project of honderd gedaan te hebben kan ik persoonlijk concluderen dat de projecten zonder ontwerp stuk voor stuk minder succesvol zijn geweest dan projecten waarbij van te voren grondig is nagedacht. De tijd die je investeert in de ontwerpen vooraf verdien je namelijk makkelijk terug tijdens de bouw. Het scheelt je een hoop welles-nietes-discussies tijdens de bouw en na oplevering en daarmee dus veel overhead en tijd. Omdat je inzichtelijk hebt wat er gebouwd gaat worden, is alles veel beter te plannen en dat scheelt ook weer werkdruk.

Bezwaren

Fijn zo’n voorspelbaar project! Klinkt mooi , maar toch zijn er enkele veelgehoorde bezwaren tegen het maken van ontwerpen. Een bezwaar is bijvoorbeeld dat je vooraf wordt gedwongen om goed na te denken over wat je wil gaan bouwen en hoe je het wil hebben. Maar zeg nou zelf: wat is hier eigenlijk mis mee? Bij een huis ontwerpt een architect ook van te voren alles? Als je achteraf vloerverwarming wil installeren terwijl de vloer net is gelegd, sta je ook voor onaangename verrassingen.

Een ander vaak gehoord bezwaar is dat er geen ruimte meer is voor flexibiliteit in het project. Daar ben ik het tot op zekere hoogte wel mee eens. De ruimte om tijdens de bouw het project aan te passen is wat beperkter. Vaak heeft dit echter te maken met het feit dat er van te voren niet goed genoeg is nagedacht over wat men precies wil. Dit probleem is dus eigenlijk goed vooraf te tackelen! Zoals gezegd: het bouwen van een website is geen rocketscience meer, en een Business Consultant kan u prima adviseren over de best practices op het gebied van functionaliteit en techniek.

Prototyping

Wilt u echter een website gebaseerd op geheel nieuwe technieken die niet vaak gebruikt zijn,  of weet u van te voren echt niet goed welke kant de applicatie op moet, of wat het allemaal moet kunnen? Dan zou ik adviseren om budget en planning vast te zetten (timeboxing) en de scope flexibel te houden. Zo weet je niet precies wat je krijgt, maar weet je in elk geval wel wanneer je iets krijgt en zal je niet over je vooraf bepaalde budget heen gaan. Een eerste versie uit zo’n project is dan soms ook een prototype, dat achteraf nog eens ‘goed’ gebouwd wordt als het prototype de vuurdoop doorstaat.

Meestal weten klanten echter in grote lijnen wel wat ze willen en hebben ze altijd een mening over hoe het eruit moet komen te zien. Al met al prima input voor de ontwerpen!

Diverse ontwerpen

Binnen het ontwikkelen van een website onderscheiden we diverse ontwerpen:

• functioneel ontwerp
• grafisch ontwerp
• technisch ontwerp

Ik zou persoonlijk adviseren om altijd te beginnen met een functioneel ontwerp, maar het is goed mogelijk om deze ontwerpen enigzins parallel te plannen.

In een functioneel ontwerp worden de klantwensen vertaald naar functionaliteit.  Hierin staat wat de site moet kunnen en bevat het vaak al schetsen (wireframe) van de belangrijke schermen in de website (prima input voor de grafisch ontwerper!). Het vormt hiermee de blauwdruk van de site.

In het ideale geval bevat de briefing naar de grafisch ontwerper naast de grafische elementen zoals logo’s huisstijlen, en andere voorkeuren ook het functioneel ontwerp.  Bij het maken van een grafisch ontwerp wordt gekeken naar de beste manier om alle functionaliteit te presenteren op een gebruiksvriendelijke manier. Het is dus niet alleen puur grafisch ontwerp, maar ook een stukje user interface design. Het is natuurlijk prettig als het grafisch ontwerp naadloos aansluit op het functioneel ontwerp. Zo benader je immers al zo gedetailleerd mogelijk het te verwachten eindresultaat in een zeer vroeg stadium.

In het technisch ontwerp worden de harde noten gekraakt door de techneuten als het gaat om database design, datamodellen en workflows. Zaken die je vooraf moet bedenken omdat deze zo belangrijk zijn voor de fundamenten van een website dat als je deze halverwege het project moet aanpassen dit zeker een zeer grote impact zal hebben. (vergelijk het met de fundering van een gebouw).

Communicatie en afstemming

Alle ontwerpen dienen natuurlijk op elkaar afgestemd te worden. De praktijk leert dat hier vaak misverstanden ontstaan omdat niet zelden alle ontwerpen door verschillende partijen worden gemaakt. Ook zie je dat een partij het ontwerp maakt, maar dat een andere partij het moet bouwen. Ik zou adviseren om dit niet te doen (zeker niet bij grotere maatwerkprojecten) De partij die het ontwerp maakt heeft immers veel tijd gestoken in de behoeften en wensen van de klant en goed nagedacht over de te ontwikkelen site/applicatie (flows, koppelingen). Deze kennis komt dan ook uitstekend van pas tijdens de bouw. Als je een partij het ontwerp laat maken en een andere partij moet de bouw doen, dan zal de bouwende partij altijd een leercurve hebben om deze ontwerpen goed te begrijpen.

In de volgende artikelen in deze reeks ga ik per ontwerp wat dieper op de inhoud in. Stay tuned!

Wellicht ook interessant!

• Websites op maat in het watervalmodel: Analysefase
• Websites op maat in het watervalmodel
• Watervalmodel: Functioneel ontwerp
• Watervalmodel: Technisch Ontwerp
• Watervalmodel: Grafisch Ontwerp

Bart Lelieveld is werkzaam als Manager Bouw bij Liones, internetbureau voor uitgevers. Als programmamanager overziet hij alle projecten binnen Liones, en is hij verantwoordelijk voor de dagelijkse operatie en het procesmanagement. Daarnaast is hij werkzaam als Senior projectleider en Business Analist.
Bekijk meer berichten van Bart Lelieveld