Dit artikel is reeds eerder gepubliceerd op www.publishr.nl. 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 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.

Het proces van het watervalmodel is als volgt gefaseerd:

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

Deze week bespreken we de analysefase, waar begint het nu zo’n beetje mee…

Businesscase / Verdienmodel

‘We willen een nieuwe website waar we geld mee gaan verdienen’. Een mooi uitgangspunt, maar hoe ga je dat bereiken? Het opstellen van een heldere businesscase is ontzettend lastig, maar dwing jezelf om erover na te denken en er een op papier te zetten. Zorg dat je site (indien van toepassing) een duidelijk verdienmodel heeft. De investering moet uiteindelijk gerechtvaardigd zijn. Welk doel dient de site, welke doelgroep wil je gaan bereiken of bedienen, en hoe denk je dat dan te gaan doen? Neem ook het onderhoud van de website mee in je business case. Lastige vragen maar key voor het succes van de site.

Lukt dit niet goed, win dan advies in. Should all else fail, zet dan minimaal het beoogde aantal bezoekers en pageviews op papier, zodat er in ieder geval een doel is om naartoe te werken. Meet na verloop van tijd in hoeverre je resultaten zijn bereikt (bijvoorbeeld met Google Analytics).

Scope

Vaak hebben mensen al een idee van hoe de site eruit moet komen te zien of welke functionaliteit er in grote lijnen in moet zitten. In deze fase volstaat het om in grote lijnen een lijst te maken van gewenste functionaliteit. Prioriteer deze waar mogelijk. Laat je indien nodig adviseren door een Business Consultant zodat je voorkomt dat je zelf het wiel opnieuw uitvindt. Er zijn zoveel sites en reeds bestaande modules dat de kans groot is dat een deel van je idee al bestaat en opnieuw gebruikt kan worden !

Binnen de scope van maatwerksites vallen vaak ook complexere onderdelen die grofweg te verdelen zijn in 3 categorieën:

• Koppelingen
• Content
• Workflow

Identificeer vooraf met welke belangrijke systemen de applicatie gekoppeld moet worden binnen de organisatie. Denk na over de content die op de site moet, is deze voldoende verrijkt (gemetadateerd) ten behoeve van SEO of het ontsluiten van de content? Kan de content worden geïmporteerd of moet dit handmatig? Daarnaast zijn er vaak workflows (logische paden, denk bv aan een bestelproces) binnen een applicatie nodig. Genoemde onderdelen zijn vaak een stuk complexer dan het simpelweg bouwen van een site en dienen daarom (in de volgende fase : de ontwerpfase) goed in kaart gebracht te worden, dus het loont om deze (vaak niet direct zichtbare) hindernissen vroeg boven tafel te krijgen.

Planning

De planning is natuurlijk grotendeels afhankelijk van de omvang van het project. De uitdaging is om al vroeg een realistische planning op te stellen. Een voorbeeld: een planning waarin het ontwerp twee maanden mag duren maar de site binnen een maand gerealiseerd, getest en gevuld moet zijn is niet realistisch. De doorlooptijd van een kwalitatief goede site van gemiddelde omvang (30K-60K) is al gauw 2-4 maanden. Vaak helpt het om terug te rekenen vanaf de deadline. Houd hierbij de bovengenoemde fasering aan. Houd bij de acceptatie- en lanceerfase rekening met het feit dat wanneer een applicatie eindelijk is opgeleverd , er ook content in geplaatst moet worden. Vaak een tijdrovende klus die over het hoofd wordt gezien of wordt onderschat.

Organisatie

Het gebeurt helaas soms dat een website wordt opgeleverd maar dat er geen mensen zijn die de tijd hebben om de site te beheren. Vaak wordt het webmasterschap bij mensen die al een volledige dagtaak hebben erbij gefrommeld. Dit is funest voor de site. Zorg dat er mensen aanwezig zijn binnen de organisatie die kennis van zaken hebben, en dus weten hoe de website en het contentmanagementsysteem werken, kennis hebben van bijvoorbeeld Analytics en Adwords en overall ‘internet-minded’ zijn. Het actueel houden van content is wederom een succesfactor van de site, evenals het schrijven voor Google!

Techniek

Als er eisen zijn die vooraf aan de techniek gesteld worden, breng deze dan in kaart. Denk hierbij aan het te gebruiken besturingssysteem of de te gebruiken programmeertaal. Waar wordt er gehost, intern of extern? Zijn er bepaalde eisen die de ICT-organisatie stelt aan de applicatie of de beveiliging?

Tot slot

Het loont om over bovenstaande zaken vooraf goed na te denken en het geheel samen te vatten in een document. We noemen dit ook wel het requirementsdocument (een parallel naar projectmanagement voor de Prince II-ers onder u, ik vergelijk dit document vaak met een PID). Er mag van een professionele bouwclub verwacht worden dat zij meedenken over bovengenoemde punten om de website tot een succes te maken!

Organisaties die een maatwerk-website willen bouwen hebben vaak moeite met het in kaart brengen van bovenstaande gegevens. Helemaal als er al ingewikkelde backoffice applicaties zijn gerealiseerd met geïntegreerde workflows waar op aangesloten dient te worden. Deze zijn vaak niet gedocumenteerd en de kennis zit in de hoofden van mensen die er werken. Hierdoor is het lastig om een ontwikkelpartij goed te briefen over de te maken website en ontstaan vaak al vroeg in het proces onduidelijkheden die kunnen leiden tot ontevredenheid.

Een Business Consultant kan hier een belangrijke rol vervullen. Deze kan op alle punten adviseren en stelt samen met met u de requirements op zodat men goed beslagen ten ijs komt bij het opstellen van het functioneel ontwerp en het benaderen van een leverancier  voor het realiseren van de website.

In het volgende artikel: de ontwerpfase. Stay tuned!

De komende weken wordt in de reeks artikelen ‘Websites op maat in het watervalmodel‘ het proces van het tot stand komen van een website besproken. De reeks artikelen volgt de fasering binnen dit proces. Per fase krijgt u een omschrijving van de acties, de deliverables en de valkuilen die per fase kunt tegenkomen. Het proces is zoals gezegd, gebaseerd op het aloude watervalmodel: wellicht een beetje stoffig, maar mits goed uitgevoerd en enigzins aangepast, een zeer krachtig en nog steeds veel toegepast model. Ondanks nieuwe methoden zoals Scrum, Agile Development en andere nieuwe projectmanagementmethodieken en ontwikkelprocessen doorstaat dit model de tand des tijds. In de komende artikelen wordt uitgelegd waarom.

Proces

Omdat overal geldt: “Divide and Conquer” is het proces als volgt verdeeld:

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

In elk artikel wordt op een van de (sub)- fases in detail ingegaan. Een toevoeging op bovenstaand proces: we spreken over het ontwikkelen van een website of webapplicatie op maat voor de klant (al dan niet gebruikmakend van bestaande componenten). Dus niet de implementatie van een standaard pakket met standaard template of de invoering van een SAP-project. Ik durf te beweren dat voor projecten van ongeveer 10.000 tot 500.000 euro het watervalmodel een uitstekend model is om te hanteren binnen de ontwikkeling.

Uitvoering

De laatste jaren is er flink tegen het watervalmodel aangeschopt omdat het te star zou zijn, projecten niet op tijd opgeleverd zouden worden of uit het budget zou lopen of dat het eindproduct niet voldoet aan de gestelde wensen vooraf. Allemaal prima overkomelijke problemen, mits goed uitgevoerd. De uitvoering mag echt niet meer een probleem zijn, het wiel hoeft niet opnieuw uitgevonden te worden, het idee van een website is nagenoeg uitgekristalliseerd, er ontstaan steeds meer standaarden. Het bouwen van een site is dan ook gewoon een vak dat geleerd kan worden en wordt uitgeoefend door vele professionele bureaus.

De grootste voordelen van het watervalmodel zijn toch wel:

• Kosten vooraf bekend
• Planning vooraf bekend
• Resultaat vooraf bekend

Ik nodig u uit om deze reeks artikelen de komende tijd te volgen, en stel natuurlijk prijs op uw mening.  Stay tuned !

-       requirementsanalyse
-       functioneel ontwerp
-       technisch ontwerp
-       grafisch ontwerp
-       bouwfase
-       testfase
-       oplevering

Het lijkt namelijk erg logisch om je scope vooraf te bepalen en zo min mogelijk te wijzigen tijdens de bouw om zo de beruchte scope creep te voorkomen. Wijzigingen in functionaliteit tijdens de bouw zorgen namelijk vaak voor grote ellende, vooral wanneer het grote wijzigingen betreft waar in het technisch ontwerp bijvoorbeeld geen rekening mee is gehouden. Alhoewel ik een groot voorstander ben van het watervalmodel (goed nadenken voor je geld uitgeeft), merk je toch dat er blijkbaar grote behoefte is aan flexibiliteit (of dit nu veroorzaakt wordt door mensen die er van te voren niet goed genoeg over nadenken is een tweede), maar soms moet je nu eenmaal aanpassingen doorvoeren om aan wensen van de klant te voldoen, en natuurlijk bestaat er ook nog zoiets als veranderende marktomstandigheden, organisatorische wijzigingen en plain basic voortschrijdend inzicht.

Een wat meer flexibele methodiek om projecten te realiseren is bijvoorbeeld het opkomende SCRUMM-model. Daar leg je van te voren niet perse 100% vast wat er gerealiseerd moet worden, maar bedenk je de details van de invulling vooral on the go.

Alhoewel er genoeg kritiek te vinden is op deze soms (schertsend bedoeld) Cowboy Coding –methodiek kan ik mij voorstellen dat het soms wenselijk is om op zeer korte termijn iets werkends te hebben staan. Gelukkig lees ik steeds meer dat ook bij deze methodiek gebruik wordt gemaakt van een functioneel ontwerp. Dat wordt steeds in iedere sprint uitgewerkt en bijgesteld zodat ook de laatste voortschrijdende inzichten worden verwerkt. Altijd fijn om een applicatie gedocumenteerd te hebben wanneer deze moet worden getest of naar beheer overgaat (of wanneer de betrokken business analist of projectleiders vertrekken)….Of wanneer er bugs ver na oplevering worden geconstateerd….of wanneer er achteraf discussie ontstaat over de kosten vs hetgeen is opgeleverd of…nou ja….enfin, genoeg redenen te bedenken waarom je ook hier de zaken goed moet vastleggen

Ik zal binnenkort enkele artikelen die ik in het verleden heb geschreven over het watervalmodel publiceren, ik heb ze nog eens nagelezen en denk dat ook hier nog steeds wel waardevolle informative in staat…

Het komt nog vaak voor dat er projecten worden gedaan zonder dat er over het gewenste eindresultaat iets over wordt vastgelegd. Een discussie of hetgeen is opgeleverd wat is afgesproken wordt achteraf dan wel erg moeilijk. Vaak komen er achteraf nog ontzettend veel wensen en aanpasingen naar boven die eenvoudig voorkomen hadden kunnen worden. Deze wensen worden dan in nieuwe releases gegoten en voordat je het weet zit je aan versie 3.8 van een net opgeleverde applicatie, met een flink stuk meerwerk waarvan je het gevoel hebt dat dit toch gewoon al in de applicatie had moeten zitten toen deze werd gemaakt.

Zonde!

Ik vind het dan ook persoonlijk geen goed idee (behalve voor zeer eenvoudige websites ) om maar met bouwen aan de slag te gaan en dan tijdens de bouw te vertrouwen op voortschrijdend inzicht.  Daarom pleit ik ook altijd om van te voren vast te leggen wat je als klant kunt verwachten van een webbouwer zodat je weet wat je krijgt voor je zuurverdiende centen! En hier geldt ook weer: hoe gedetailleerder hoe beter.  Je wil namelijk van te voren weten wie er verantwoordelijk is voor de invoer van de content, het overnemen van die ene oude database die steeds in alle gesprekken is langsgekomen, of dat je nieuwe website wel gaat werken in Chrome , of (natuurlijk volledig afhankelijk van je doelgroep) , misschien is het nodig dat jouw website nog wel werkt in Internet Explorer 6.0.

Met andere woorden, doe je huiswerk voordat je een website laat bouwen of met een bouwer in zee gaat. Kun je dit niet zelf, neem dan iemand in de arm die je kan adviseren hierin. Let wel: Een goede website bouwer zal je altijd adviseren om een en ander vooraf vast te leggen, zeker als van hen verwacht wordt dat een maatwerk-opdracht fixed price uitgevoerd gaat worden. Het functioneel ontwerp wordt daarmee een overeenkomst, waarin tot (in redelijkheid) in detail benoemd staat wat je voor je investering kunt verwachten! Wel zo fijn..

Je ziet het vooral vaak fout gaan bij beginnende projectleiders, die nog niet eerder een IT- implementatie hebben gedaan, of vooral gewend zijn aan het doen van interne projecten waarbij de scope minder van belang is geweest. Die starten dan vaak een project zonder een functioneel ontwerp op te stellen.  Maar belangrijker, het gaat helaas ook vaak mis bij webbouwers. Sommige bieden niet eens zelf aan om een functioneel ontwerp te maken. En soms doen ze het wel, maar dan gaat het alsnog mis doordat ze het functioneel ontwerp op zo’n slechte manier maken doen dat ze niet alleen de klant maar vooral ook zichzelf in de problemen brengen…

Zo maakte ik niet lang geleden mee dat er een grote wijziging op een bestaande website moest worden doorgevoerd: er moest een afgesloten omgeving voor de bezoeker worden gecreëerd,  waarbij na inloggen van die bezoeker hem allerlei functionaliteit ter beschikking werd gesteld. Inloggen zou de bezoeker ook keer op keer voordeel opleveren omdat deze bij een bepaalde handeling niet continu dezelfde informatie zou worden gevraagd.

De bouwpartij in kwestie had beloofd al deze voordelen te realiseren , tegen een fixed price aanbieding. Teneinde geen functionaliteit over het hoofd te zien, waren ze zo verstandig geweest om een functioneel ontwerp op te laten stellen door een business analist. Het functioneel ontwerp richtte zich hoofdzakelijk op de schermen die een bezoeker te zien kreeg. Deze waren in (niet al te gedetailleerde ) wireframes allemaal uitgewerkt in een indrukwekkend document (60 pagina’s). Bij nader inzien bleken echter dat de meeste wireframes gewoon waren doorgekopieerd en enigszins waren aangepast, zonder dat er nu echt goed was nagedacht. Er waren veel uren gerekend voor dit karweitje (ca 100 uur). Als klant heb je dan de beleving dat de bouwer goed over de zaak heeft nagedacht. So far so good…

Tijdens de implementatie werd echter duidelijk dat er vooral over de voorkant (presentatie) en de indeling van de schermen was nagedacht. De website die de partij notabene eerder zelf had gebouwd, moest in de te bouwen afgesloten omgeving echter ook informatie ontsluiten vanuit een achterliggende backoffice-applicatie. In deze applicatie werd gebruik gemaakt van een behoorlijk aantal workflows. En deze ontbraken geheel in het opgestelde functioneel ontwerp. Erger nog, de bouwpartij had geen idee hoe deze flow precies liep, of de moeite genomen om deze eerst in kaart te brengen. Het spreekt voor zich dat de partij fors meer uren kwijt was om deze flow alsnog netjes in kaart te brengen en het ontwerp aan te passen, maar natuurlijk ook al de reeds gerealiseerde code. Als je dan als leverancier  een fixed price aanbieding hebt gedaan op basis van een incompleet functioneel ontwerp, dan moet je helaas op de blaren zitten…

Een degelijk functioneel ontwerp dekt dit soort belangrijke zaken gewoon af. True, misschien kun je niet 100% van te voren afdekken, maar 90% – 95% moet zeker lukken als er grondig business analysis (want dat is functioneel ontwerpen met name)  plaatsvind. Als klant mag je ook verwachten dat een business analist zijn werk compleet en grondig doet, en dat je als leverancier als expert en kenner wordt gezien. Mocht er onvoldoende tijd zijn om alles netjes in kaart te brengen voor
de functioneel ontwerper, dan dient hij dit ook gewoon aan te geven.

Ik merk het steeds weer, blijkbaar is het opstellen van een goed functioneel ontwerp toch een vak apart….

Wat denken jullie?

Hierbij loop ik steeds weer tegen zaken aan die ik graag deel met de rest van de wereld, omdat ik nog steeds overtuigd ben van het principe: een goed functioneel ontwerp ontzorgt! Naast de artikelen over functionele ontwerpen zal ik ook wat meer focussen op het proces van het totstand komen van een website. Daarover publiceerde ik reeds in 2009 een serie artikelen op Publishr maar ik ben van plan om deze serie op functioneelontwerpen.nl voort te zetten en uit te bouwen.

Mochten jullie naar aanleiding van deze post vragen hebben, of mij vragen willen stellen over het maken van functionele ontwerpen, dan ontvang ik deze graag!

Tot snel…

In het functioneel ontwerp staat wat de te bouwen applicatie of website aan functionaliteit moet bieden zodanig omschreven dat een klant het document ook goed kan begrijpen. Dat wil zeggen: niet te technisch, maar elk woord moet wel raak zijn. Daarnaast moet de informatie ook nuttig zijn voor iemand die de site moet gaan bouwen.  Het functioneel ontwerp is de blauwdruk van de applicatie/website. Maar aan welke elementen moet je nu denken, en wat neem je op in een functioneel ontwerp?

Welke elementen bevat een functioneel ontwerp?

Puntsgewijs dient een functioneel ontwerp de volgende zaken te bevatten:

• Doel van de website
• Doelgroep van de website
• De te behalen doelen ( in ieder geval een indicatie, dus aantal bezoekers etc, achteraf meten)
• Afhankelijkheden van andere applicaties
• Overzicht van alle pagina’s in de site of applicatie (meer dan een sitemap)
• Beschrijving op voldoende detailniveau van de functionaliteit op alle pagina’s
• Uitgewerkte schema’s van de flows binnen de applicatie en de bijbehorende usecases
• Wireframes van de key pagina’s (vaak evident binnen een site, homepage, profielpagina etc)

Als we iets dieper de techniek induiken kan worden gedacht aan :

• Eisen met betrekking tot de zoekfunctionaliteit (wel/geen zoekmachine)
• Koppelingen met andere tools  (bv Analytics / Adwords/ Mailsysteem/backoffice-systeem)
• Een overzicht van de te importeren content
• Eisen aan de browsercompatibiliteit
• Eisen aan het usermanagement
• Eisen aan de beveiliging
• SEO-specs, of een beschrijving van de banner-tool die worden ingezet

Bespaar geld met een functioneel ontwerp

Al met al een hele lijst. Het kan natuurlijk zijn dat niet elk onderdeel benodigd is voor jouw site of applicatie. Gebruik bovenstaande dan toch als een checklist om jezelf ervan te vergewissen dat je in de loop van het project niet met deze zaken te maken krijgt. Het functioneel ontwerp bied prima input voor het technisch ontwerp (TO). Vooraf nadenken scheelt redesign, wijzigingen in de architectuur/database en overhead tijdens de bouw, dus je bespaart er geld mee!  Zorg ook dat het functioneel ontwerp naadloos aansluit op het grafisch ontwerp (GO) om hier misverstanden te voorkomen.

Tot slot

Los van de bovenstaande lijst zijn er nog een aantal algemenere elementen om rekening mee te houden. Voor wie maak je het functioneel ontwerp (binnenshuis/andere partij?)  Schrijf je het functioneel ontwerp al op een platform of standaardproduct dat je gaat gebruiken? In welke taal schrijf je het?  Een business analist kan je helpen om al deze vragen te beantwoorden om zo gezamenlijk tot een optimaal ontwerp te komen.

De tools worden beoordeeld op:

- gebruikersgemak
- functionaliteit
- toepasbaarheid
- flexibiliteit
- uitbreidbaarheid
- prijs

De volgende wireframe tools worden onder de loop genomen:

Firefox ‘Pencel’ add-on http://www.evolus.vn/Pencil/

GoMockingbird http://gomockingbird.com/

Pidoco– https://pidoco.com/en

HotGloo– http://hello.hotgloo.com

Flairbuilder– http://www.flairbuilder.com/

Lovelycharts– http://www.lovelycharts.com/

iPlotz http://iplotz.com/

Omnigraffle– http://www.omnigroup.com/applications/OmniGraffle/

Axure– http://www.axure.com/

Deadlines en sitebouwers
En toch: veel organisaties verslikken zich nog altijd in hun eigen website. De bestaande website voldoet niet meer aan de wensen van het bedrijf, de look-and-feel doet verouderd aan en de bedrijfsleiding ziet kansen op internet die nog niet worden benut. En dus moet er iets nieuws komen. En ontstaat er een proces dat maar al te vaak misgaat. De deadline wordt niet gehaald en de externe sitebouwers hebben iets gebouwd dat helemaal niet past bij de oorspronkelijke plannen. Hoe kan dat nou?

Sitebouw: vast stappenplan
Het bouwen van een professionele website kent een aantal vaste stappen: bepaal het doel en de doelgroep van de site, leg alle wensen vast, definieer een sitemap en een functioneel ontwerp en laat die volgen door een technisch en visueel ontwerp. Zorg voor de juiste content, bouw een testfase en eventueel een beta-fase in en de site is klaar om succesvol opgeleverd te worden. Appeltje-eitje, in elk geval voor professionele websitebouwers.

Functioneel Ontwerp: noodzaak
En toch gaat het vaak mis. Cruciale stap in het bouwen van een website blijkt dan vaak het Functioneel Ontwerp. De noodzaak daarvan ontgaat de klant nog wel eens. ‘Dit is wat ik wil, dat moet niet zo moeilijk zijn, maak dat even’, is de gedachtegang.

Bart Lelieveld, manager Bouw bij Liones, internetbureau voor uitgevers, heeft zijn antwoord paraat voor klanten die in zulke grote stappen snel thuis denken te zijn. Lelieveld: “Het grappige is dat bij huizenbouw iedereen snapt dat een architect een ontwerp moet maken. Bij een uitbouw kijk je ook eerst hoe de leidingen lopen. Zo is het ook bij een website. Een deel eraan bouwen kan nooit veel werk zijn, denken mensen soms. Maar je moet rekening houden met het CMS erachter, de database en de workflow. Na een gedegen uitleg zien mensen dat ook wel in.”

Functioneel Ontwerp: communicatieinstrument
Een functioneel ontwerp is een blauwdruk van de site waarin alle benodigde functionaliteit en koppelingen worden aangegeven. Maar het is ook een belangrijk communicatieinstrument met de klant, aldus Lelieveld, die met zijn bedrijf betrokken is bij de bouw van honderden websites. “De opdrachtgever heeft bepaalde wensen en wil meestal een fixed price. Het FO maakt de wensen inzichtelijk en daarmee  ook de kosten. Het geeft duidelijke richtlijnen en dat scheelt een hoop discussie achteraf.” Waarbij het de uitdaging is om een ontwerp te maken dat begrijpelijk is voor de opdrachtgever, en tegelijk zinvolle informatie bevat voor de sitebouwers.

Extra wensen: verwachtingsmanagement
Maar dan nog zijn er opdrachtgevers die gaandeweg het proces toch met extra wensen komen. Er moet nog een logootje bij, een aparte rubriek, formulieren of een nieuwsbrief en – oh ja, zo’n hyves-achtige community is eigenlijk ook wel hip. Aan de sitebouwer de taak om opdrachtgever niet al te teleurgesteld achter te laten.

Verwachtingsmanagement’ noemt Lelieveld deze taak: “Het vraagt de benodigde skills van de projectmanager. Kleine tot middelgrote wijzigingen kunnen vaak nog ingewilligd worden, maar grotere wijzigingen hebben vaak invloed op de doorlooptijd en kosten. Je kunt een schuur ook niet links neerzetten als rechts de fundamenten al zijn gelegd. Zo werkt het ook met sitebouw, dat tegenwoordig toch redelijk complex kan zijn. Je legt niet even een koppeling met het CRM van het bedrijf of met iDeal.” Alles is mogelijk, maar wel even goed nadenken en de verwachtingen afstemmen vooraf.

Prioritering: wat moet de site doen?
Om de klant toch van dienst te kunnen zijn, kan het parkeren van nieuwe wensen tot na de release een oplossing zijn.  In een tweede fase kunnen extra wensen alsnog worden ingewilligd. Maar alles staat of valt met een duidelijke prioritering, constateert Lelieveld. “Sommige wensen dragen bijvoorbeeld niet bij aan de businesscase. De extra kosten om de wensen in te willigen, verdien je soms nooit terug. Dat moet je de klant dan ook laten zien. Samen moet je de prioritering scherp krijgen.” Want juist in die prioritering zit vaak de bottleneck in de sitebouw. “Het moet duidelijk zijn wat de doelstelling van de site is, wat deze moet gaan doen (waar het geld mee wordt verdiend) en wat daarvoor nodig is.”

En dan nog wat: de sitebouwers maken het Functioneel Ontwerp, niet de opdrachtgevers. Lelieveld: “Als een klant met een FO komt, zien we dat als requirements – een lijst van wensen. Die moet je samen analyseren, anders kun je nooit leveren wat de klant wil. Je moet de kans krijgen om door te vragen, want het gaat om de vraag achter de vraag.”

Functioneel Ontwerp: overschat belang
Ruben Timmerman , usabilitydeskundige en oprichter van Eduhub.nl, is niet te beroerd om het belang van het FO onderuit te halen. “Het belang van een FO wordt overschat,”stelt hij. “Je kunt beter een site snel lanceren zonder alle overhead van een FO. Een website kun je namelijk niet van tevoren uitdenken. Pas in het gebruik weet je hoe het echt moet.”

Timmerman, die bij veel grote webbouwprojecten betrokken was, wijst op sites als Marktplaats en Hyves. “Die zijn eerst in elkaar geramd, toen bleek er vraag naar en daarna zijn ze stapje voor stapje aanpassingen gaan uitvoeren.”

Deadlines en slechte websites
Goed, Timmerman wil ook niet zover gaan dat het FO helemaal kan worden overgeslagen. “Dan krijg je wat vage wensen en laat je het aan de fantasie van de programmeur over om er wat van te maken. Maar een FO bepaalt niet het succes van de site.”

Hij ziet te vaak gebeuren dat sitebouwers keihard vasthouden aan het vooraf uitgezette stappenplan. “ ‘Bij wijzigingen schuift de deadline op’ dreigen ze dan al snel. En opdrachtgevers zijn daar weer doodsbenauwd voor. Die denken dat een deadline heilig is, vanwege allerlei interne belangen in de organisatie. Daardoor lanceren ze iets dat niet goed is. Op die manier kent Nederland heel veel slechte websites.”

Flexibiliteit organiseren: de betafase
Timmerman pleit voor flexibiliteit. Maar hoe organiseer je dat, zonder al te losjes om te gaan met deadlines en oorspronkelijke doelstellingen? Zijn remedie: lanceer de site eerst in betafase. Timmerman: “Je ziet die trend heel duidelijk. Lanceer de nieuwe site naast de bestaande, vraag de vaste gebruiker wat hij ervan vindt en kom na anderhalve maand met de definitieve versie. Speurders deed dat bijvoorbeeld via Marketingfacts. Na die uiteindelijke lancering kun je verdere aanpassingen stukje bij beetje doorvoeren.”

Sitelancering: flexibiliteit creëren
Timmerman en Lelieveld lijken elkaar soms tegen te spreken. Toch zijn er duidelijke conclusies uit te trekken: een functioneel ontwerp is nodig (of het nou als uiterste noodzaak geldt of als een handige tussenstap). Flexibiliteit is bijna altijd nodig. En die ruimte voor flexibiliteit is te creëren. Door een extra release op te stellen of door een site in betafase te laten werken. Waarna de definitieve lancering van de site mogelijk is. En de site toch niet af is…

BRON: (overgenomen van www.publishr.nl, auteur Mark Janssen)