Home » Techniek

Waarom een functioneel ontwerp (niet) het belangrijkste is

Geschreven door Mark Janssen () op donderdag 23 april 20099 reacties
Waarom een functioneel ontwerp (niet) het belangrijkste is

Het zou zo makkelijk moeten zijn: een website bouwen. Trek een van de vele Content Management Systemen uit de kast, vul het aan met applicaties als betaalmodules, mailsystemen of forums en klik het bij elkaar. De ontelbare websites en blogs van hobbyisten bewijzen het: in een avondje bij elkaar geklikt met Wordpress, Blogger of een kant-en-klare sitebuilder en soms onbedoeld nog aardig succesvol ook. En dan zijn er ook grote aantallen professionele websites die als voorbeeld kunnen dienen. Het proces van websites bouwen zou inmiddels bekend moeten zijn.

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…

  • email
  • Print
  • Google Bookmarks
  • Technorati
  • LinkedIn
  • NuJIJ
  • Hyves
  • Twitter

Wellicht ook interessant!


Bekijk meer berichten van Mark Janssen

9 reacties »

  • Bart Lelieveld schreef:

    Een kleine toevoeging:

    Ik sluit me graag aan bij Timmermans, flexibiliteit is zeer belangrijk! De kunst is echter wel om ook de eerste release te beperken toe een voor ieder acceptabele scope. Anders lever je nooit een eerste versie op, en blijft de planning uitlopen.

    De eerste release van de site moet datgene doen waarvoor de site in het leven is geroepen. Dus eerst de core, en vervolgens meten en analyseren of je business case nog gerechtvaardigd is. Vervolgens kun je dan de site doorontwikkelen.

    Een site is inderdaad nooit echt af, het internet ontwikkelt door, technieken worden slimmer, klantvragen veranderen, je website zal uiteindelijk mee moeten veranderen wil je mee kunnen blijven draaien.

  • Jos van Essen schreef:

    Er is geen algemeen toepasbaar stappenplan dat je moet volgen bij bouw omdat ieder project anders is. Een FO voor een puur blog-achtig geheel is onnodig, maar bij een echt uitgebreide community weer strikt noodzakelijk. Het gaat er in FO fase ook om de klant op te voeden, en te sturen. Nog vaak genoeg zie ik FO’s als dikke pakken papier langskomen. Geen enkele klant zit daar op te wachten. En dat terwijl goede software om FO’s mee te maken ook prima in staat zijn klikdemo’s te produceren. Loop die klikdemo’s met klanten door. Geef mensen fatsoenlijk de tijd om een FO grondig te testen. Daar wordt een FO alleen maar beter van. Probeer het tegelijkertijd niet allemaal plat te documenteren, want hierdoor ontstaat een te star geheel waarin ook geen eigen inbreng is van de ontwikkelaars zelf, die soms voor kleine probleempjes ook handige opolossingen hebben. Ik zou (zoals Ruben Timmermans ook al suggereert) altijd eerst een beta of softlaunch doen en vervolgens stapsgewijs gaan testen of alle zaken die er in het FO zo logisch uitzien ook in de praktijk logisch uitpakken.

  • Bart Lelieveld schreef:

    Beste Jos, leuk dat je reageert!

    je hebt gelijk dat voor eenvoudige zaken geen FO nodig is en bij een uitgebreidde community wel. Zoals je aangeeft is het inderdaad om op te voeden (of liever: de klant te adviseren vanuit je expert-rol) en te kunnen sturen naar goede standaard-oplossingen.

    Voor wat betreft een klik-model of een beta-evrsie:

    Ik merk vaak dat klanten geen budget hebben om een prototype te laten maken. Met zoiets als websites lijkt me dat ook nagenoeg overbodig.Het is immers een redelijk uitgekristalliseerd concept. De header staat bovenin, het menu staat links of over het midden etc. Het is geen rocketscience meer. Een klik- of stappenplan door een site zie ik zleden langskomen

    Een best practice in websiteland is immers zorgen dat je gebruiker binnen 2 klikken op de plek van bestemming is! (niet altijd haalbaar helaas, denk aan een winkelmandje of afrekenproces)

    Daarnaast moet je denk ik zoveel mogelijk aansluiten bij standaarden die je op internet ziet langskomen in plaats van zelf het wiel opnieuw gaan uitvinden.

    Als ik spreek over een FO heb ik het over maximaal een week in kaart brengen wat er op de site komt, en hoe dit werkt voor de gebruikers, puur om de scope van het project in kaart te brengen.

    Het laten testen van een FO door meerdere gebruikers is reeds stukken duurder en omslachtiger, tenzij je het door expertconsultants laat reviewen.

    Hoe denk jij hier verder over?
    Ik nodig je graag uit om hier op te reageren!

  • Jos van Essen schreef:

    Hey Bart,

    Met ‘opvoeden’ bedoelde ik inderdaad vanuit je expertrol een klant adviseren wat logisch, handig en functioneel is.

    Ik herken het feit dat bedrijven vaak niet (extra) willen betalen voor een werkend prototype of klikmodel. Terwijl dit in FO of vroege bouwfase in principe prima meegenomen kan worden door de ontwerper of bouwer. Waar het mij om ging: we besteden vaak wel een weekje aan het schrijven van een functioneel ontwerp, maar onze klant is nauwelijks in staat om dit functionele plan echt te beoordelen. Een klikmodel of demo laat zich sneller door een eindgebruiker beoordelen.

    Ik ben het met je eens dat je zoveel mogelijk zou moeten aansluiten bij webstandaarden. Gelukkig zijn er op internet een heleboel design patterns en page grids die dit helpen vergemakkelijken. Toch zie ik nog vaak genoeg sites langskomen die het wiel zelfstandig opnieuw uitgevonden (denken) te hebben en daarin hopeloos de plank misslaan.

    Daarom vind ik een weekje schrijven op een goed FO prima, maar wanneer je dit bijvoorbeeld doet met Axure software dan is het ook heel eenvoudig dit project te exporteren tot mini-klikdemo. Dan zou ik er eens doorheen bladeren. Samen met collega’s, en wat mensen die wat verder van het project af staan (vrienden, ouders, kinderen, de doelgroep). Gewoon over hun schouder meekijken wat ze aan het doen zijn en je ziet binnen 5 minuten of alles werkt zoals het moet werken. Vaak vinden mensen het zelf juist ook wel leuk om ergens doorheen te klikken.

  • Bart Lelieveld schreef:

    Beste Jos,

    We zijn het helemaal eens dat een hoop klanten moeite hebben met het lezen van een functioneel ontwerp. Vaak is dat omdat een functioneel ontwerp ook best technische elementen beschrijft, en ook dient als input voor een ontwikkelaar. Een klikdemo kan ook zeker waardevolle input leveren (mits je representatieve gebruikers hebt,ik heb ook wel DURE gebruikerstesten mogen surveilleren waar dan 4 goedwillende personen worden uitgenodigd die nog net niet met de muis op het beeldscherm zitten waardoor de feedback van zeer twijfelachtige kwaliteit is…)

    We zijn het gelukkig wel eens dat een FO een goede zaak is! Bedankt voor de tip , ik zal eens kijken naar Axure. Maar ik vind eigenlijk dat we dan stiekem al bezig zijn met Usability testen, en niet zozeer meer het beschrijven van de sec requirements?

    Vind jij dat uitgewerkte wireframes bij het FO traject horen, of is het meer input voor het uiteindelijke grafisch ontwerp? Of een tussenstap? en moet de business analist dit maken?

    Ik stel erg prijs op jouw mening in deze

  • 6 tips voor meer bezoek op je weblog | Publishr schreef:

    [...] van? Zorg voor goede achtergrondartikelen. Diepgravende blogposts over web 3.0 voor uitgevers en nut en noodzaak van functionele ontwerpen scoren verrassend hoog. Bezoekers arriveren via zoekmachines en blijven lang [...]

  • Websites op maat in het watervalmodel (nieuwe website, functioneel ontwerp,proces) | Publishr schreef:

    [...] Functioneel Ontwerp [...]

  • Websites op maat in het watervalmodel: Analysefase | Publishr schreef:

    [...] Functioneel Ontwerp [...]

  • Watervalmodel: Functioneel ontwerp | Publishr schreef:

    [...] zijn voor iemand die de saite moet gaan bouwen.  Het FO is zoals eerder besproken op Publishr, de blauwdruk van de applicatie/website. Maar aan welke elementen moet je nu denken, en wat neem je op in een [...]

Laat een reactie achter!

Voeg je reactie toe of maak een trackback vanaf je eigen site.

U kunt gebruik maken van de volgende tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Deze website maakt gebruik van Gravatar avatars. Voor uw eigen Gravatar avatar kunt u registreren op Gravatar.