Functioneel Ontwerp, onmisbaar tijdens webprojecten

16-11-2010 door Amy Suijkerbuijk

Het succes van elke activiteit valt of staat met de voorbereiding ervan. Zo ook het succes van de (door)ontwikkeling van bijvoorbeeld een website of applicatie. Dit geldt tevens voor websites of applicaties voor mobiele apparaten zoals de iPhone, Blackberry en de iPad. (In dit artikel wordt vanaf nu alleen gesproken over websites).

Een goede voorbereiding op de ontwikkeling van een website is het opzetten van een Functioneel Ontwerp. Een Functioneel Ontwerp bevat een beschrijving van alle te ontwikkelen functionaliteiten van de website. Een Functioneel Ontwerp (FO) laat stap voor stap zien hoe een gebruiker door de toekomstige website of applicatie kan ‘klikken’, met daarbij enkele voorbeelden uitgewerkt in wireframes. Een wireframe is een voorbeeldscherm binnen een internet browser dat uitbeeldt hoe de functionaliteiten van de website of applicatie gaan werken.

wireframe

Een voorbeeld van een wireframe van een bekende zoekmachine.


Het Functioneel Ontwerp vormt de basis van de afspraken tussen opdrachtgever en opdrachtnemer. Het FO kan gezien worden als een ‘contract’ waar alle betrokken partijen zich aan moeten houden tijdens het ontwikkelproces van de website.* In dit artikel wordt toegelicht wat het nut is van dit document. Ook geven we een aantal tips over wat een FO minimaal zou moeten bevatten.
 

* Het Functioneel Ontwerp kan uiteraard gedurende het proces worden bijgewerkt. Bijvoorbeeld wanneer de  opdrachtgever een bepaalde wens heeft die doorgevoerd moet worden in de website, maar daar pas na oplevering van het FO aan denkt.

Waarom een FO?

‘Je bouwt toch ook geen huis zonder een ontwerp?’ is een veelgehoord citaat van de schrijvers van FO’s. Helaas denkt nog niet iedereen op die manier tijdens een webproject. Vaak worden deadlines en het vasthouden aan de begroting belangrijker geacht dan het ontwikkelen van een goede blauwdruk van de website.

Veel voorkomende klachten tijdens website-ontwikkeling, waarbij niet met een FO gewerkt is, zijn: De applicatie doet niet wat er gevraagd is, de website wordt te laat opgeleverd of de ontwikkeling heeft veel meer geld gekost dan begroot. Er ontbrak een goede afstemming tussen opdrachtgever (met een probleem) en de ontwikkelaar (die het probleem gaat oplossen).

Met de investering in een Functioneel Ontwerp wordt de kans op deze valkuilen aanzienlijk verkleind, doordat het voor alle partijen duidelijk is wat er precies ontwikkeld gaat worden (en of het probleem ook daadwerkelijk hiermee opgelost wordt). Tijdens het opstellen van een FO worden de betrokken partijen namelijk geforceerd tot nadenken. Het voorkomt het ó zo aantrekkelijke ‘doorschuiven van lastige kwesties’.

Alle mogelijke functionaliteiten die helpen bij het behalen van de doelstellingen voor de website worden tot in detail uitgedacht en besproken met de opdrachtgever, alvorens de website daadwerkelijk gebouwd wordt. Aanpassingen in het FO zijn makkelijker door te voeren dan in de programmeercode van de website. Het vergt ook veel minder tijd (en dus ook kosten).

Op basis van een Functioneel Ontwerp kan een (concrete) kostenindicatie en een planning worden afgegeven door de verschillende partijen. Pas na de goedkeuring van het FO wordt de vormgeving en de te gebruiken techniek voor de website bepaald.

Communicatiehulpmiddel

Het ontwikkelen van een website vergt samenwerking tussen veel verschillende partijen. Denk hierbij aan:

  • Opdrachtgever
    • Eventueel in de vorm van een projectteam
  • Projectmanagement
  • Grafische vormgeving
  • Programmeurs
  • Copywriting
  • Derden
    • Bijvoorbeeld systemen/partijen waarmee koppelingen worden gemaakt

Met het Functioneel Ontwerp wordt het een stuk makkelijker om onderling te communiceren. Het bespaart tijd en kosten, omdat iedereen vanuit hetzelfde uitgangspunt werkt. Het is aan te raden om één ‘eigenaar’ aan te stellen van het FO die de eisen en wensen van de verschillende partijen doorvoert in het document.

Toetsen bij doelgroep

Ook de doelgroep (of eindgebruiker) kan goed in het ontwikkelproces betrokken worden door het ontwerp voor te leggen aan deze partij. De wireframes uit het FO kunnen bijvoorbeeld omgezet worden naar een werkend (klikbaar) prototype om zo nog meer mogelijke valkuilen op te vangen, alvorens de website gebouwd wordt

Inhoud Functioneel Ontwerp

Het doel van een Functioneel Ontwerp is het zo compleet mogelijk de functionaliteiten van een website te beschrijven. Er zijn verschillende manieren om dit aan te pakken, in dit artikel lichten wij de door Burst gehanteerde methoden toe, die ook door andere ontwikkelaars veel gebruikt worden. Uiteraard heeft elk bureau zijn eigen manier van werken, maar voorop staat het definiëren van de functionaliteiten.

Het is belangrijk continu in het achterhoofd te houden waarom het Functioneel Ontwerp wordt opgesteld, zodat wildgroei aan niet-relevante informatie voorkomen wordt. Zaken als planning en begroting behoren niet tot het Functioneel Ontwerp. Ook informatie over technische implementatie hoort bij voorkeur niet in het FO thuis, maar in een op zichzelf staand Technisch Ontwerp (TO).

Een mogelijke structuur van de hoofdstukken die een Functioneel Ontwerp kan bevatten, is als volgt:

  • Inleiding
  • Doelgroep & Doelen
  • Scenario’s
  • Structuur van de website
  • Functionaliteiten per pagina
  • Openstaande kwesties
  • Opmerkingen voor design & techniek

Hieronder volgt een korte toelichting per hoofdstuk.

Inleiding

Ter introductie van de website wordt in de inleiding het probleem van de opdrachtgever toegelicht en de oplossing die bedacht is. Het is belangrijk om ook de auteur van het document op te nemen, zodat het voor alle partijen duidelijk is bij wie zij terecht kunnen voor vragen en opmerkingen. Een noot daarbij is dat de auteur niet de enige persoon is die aan het FO werkt, maar vooral de eigenaar en beheerder van het document is.

Vergeet ook nooit het versienummer van het FO op te nemen in het document. Zo zijn alle partijen bij latere versies op de hoogte van het feit dat er wijzigingen hebben plaatsgevonden in het document ten opzichte van de oorspronkelijke versie van het FO.

Doelgroep & doelen

Alle partijen moeten in hun achterhoofd houden voor wie zij een oplossing aan het bedenken zijn en wat zij daarmee willen bereiken. Een korte beschrijving van de doelgroep en de doelen voor de website opnemen in het FO is daarom wenselijk.

Scenario's

Een scenario is een beschrijving van de mogelijke ‘flow’ van de eindgebruiker door de website. Met behulp van scenario's krijgt de lezer een duidelijker beeld van de eindgebruiker en diens behoefte. Daarnaast geeft dit houvast voor de programmeurs, die de flow gaan bouwen.

Structuur van de website

Voeg in het FO een overzicht van alle te ontwikkelen pagina’s binnen de website toe. Het overzicht zorgt ervoor dat men een goed beeld krijgt van de omvang van het project.

Functionaliteiten per pagina

Voor het uitwerken van de functionaliteiten per pagina worden vaak wireframes gebruikt. Stel je eens voor dat je een webshop wilt (laten) ontwikkelen. Een belangrijke functionaliteit voor een webshop is het authenticatieproces: het verifiëren van de identiteit van een gebruiker. Een mogelijke oplossing voor authenticatie zijn een login- en een registratiescherm.

Voor dit proces kunnen de volgende schermen opgenomen zijn in het Functioneel Ontwerp voor de webshop:

Wireframe Authenticatieproces v1Een voorbeeld van twee wireframes voor een webshop


Is je iets opgevallen aan één of beide schermen? Nee? Bekijk de schermen dan nog eens, maar verplaats je deze keer in zowel de eindgebruiker, als degenen die deze schermen gaan ontwikkelen.

Een webprofessional zou bij het zien van bovenstaande schermen de volgende vraag (moeten) stellen: Wat als een eindgebruiker zijn wachtwoord vergeten is? Ook daar moet een functionaliteit voor ontwikkeld worden. Daarnaast kan de webprofessional zich afvragen of het voor de designers van de webshop wel duidelijk is dat er foutmeldingen in het registratiescherm kunnen voorkomen? Het scherm moet wel op een manier ontworpen worden dat het in de hoogte rekening houdt met mogelijke foutmeldingen.

Het is daarom belangrijk om het FO herhaaldelijk te controleren, het liefst door één of meerdere personen van alle partijen die aan de slag gaan met de bouw van de webshop.

Na een correctieronde zijn de schermen als volgt aangepast:

Wireframe Authenticatieproces v2Wireframes voor de webshop na een correctieronde

Het is aan te raden om bij de schermen ook een beschrijving te geven over de werking van de functionaliteiten. Alle betrokken partijen moeten conclusies kunnen trekken uit bovenstaande schermen en de beschrijving daarbij.

  • Een copywriter zal het belangrijk vinden om te weten dat er een tekst geschreven dient te worden voor de e-mail die verstuurd wordt als iemand een nieuw wachtwoord aanvraagt.
  • Een designer weet aan de hand van dit voorbeeld dat er een vraagteken-icoontje ontworpen moet worden.
  • Een programmeur wil weten wat er gebeurt op het moment dat een gebruiker naar het vraagteken-icoontje navigeert. Kan de gebruiker er op klikken of gebeurt er al iets bij een mouse-over? Opent er een nieuw scherm of een pop-up?  

Het verdient de aanbeveling om bij de toelichting te vermelden voor welke partij een specifieke opmerking bedoeld is. Bijvoorbeeld:

Opmerking voor design: Houd bij het ontwerpen van de schermen rekening met de weergave van mogelijke foutmeldingen, in verband met de hoogte van het scherm.

Opmerking voor techniek: Als een gebruiker op het vraagteken-icoontje klikt, opent een pop-up met tips om een goed wachtwoord op te stellen.

Openstaande kwesties

Het schrijven van een eerste versie van het Functioneel Ontwerp zal altijd vragen oproepen. Een opdrachtgever kan bijvoorbeeld bedacht hebben dat hij een webshop wil ontwikkelen en levert daarvoor een aantal gegevens aan. Tijdens het ontwerpen van de wireframes kan de schrijver van het FO er bijvoorbeeld op stuiten dat hij niet weet hoe de opdrachtgever de artikelen gaat verzenden, welke kosten daarvoor gehanteerd moeten worden, en op welke manier(en) klanten bij voorkeur kunnen betalen?

Verzamel daarom alle openstaande kwesties in een apart hoofdstuk en vermeld erbij voor welke partij(en) de betreffende kwesties zijn. Zo wordt voorkomen dat de partijen de openstaande kwesties zelf uit het document moeten filteren.

De opdrachtgever kan naar aanleiding van het FO met nieuwe wensen of vragen komen. Het kan daarom handig zijn om ook een hoofdstuk met Beantwoorde kwesties op te nemen in het FO.

Opmerkingen voor design & techniek

Hetzelfde geldt voor de opmerkingen voor de partij(en) die de vormgeving en de techniek van de website op zich nemen. Vermeld ze bij de betreffende schermen, maar verzamel ze ook in een apart hoofdstuk, zodat ze snel terug te vinden zijn.

Enkele tips voor het opstellen van een Functioneel Ontwerp

De ervaring van Burst is dat onderstaande punten van groot belang zijn bij het opstellen van een goed en compleet FO:

  • Zorg dat stakeholders altijd de laatste versie van het FO in hun bezit hebben.
  • Vinden er onverhoopt toch nog wijzigingen plaats in de website, terwijl de bouw ervan al begonnen is, verwerk deze dan toch nog in het FO en stel de programmeurs op de hoogte van de nieuwe versie.
  • Probeer duidelijk aan te geven wat er nieuw is bij bepaalde versies, zodat men niet alles hoeft te doorzoeken.
  • Ieder webproject is anders. Bepaal bij het werken vanuit een FO template bij ieder nieuw project welke hoofdstukken juist voor dat project relevant zijn en welke niet.
  • Herzien, herzien, herzien! Dit is zeer belangrijk om te voorkomen dat mogelijke valkuilen pas bij de vormgeving of het bouwen van de website boven komen drijven.
  • Zorg daarnaast wel voor goede afspraken met de opdrachtgever, zodat het FO niet eindeloos door correctierondes blijft cirkelen.  

Hoe doen we dit bij Burst

Burst gaat altijd van start met een analyse van het probleem van de opdrachtgever. Het kan namelijk voorkomen dat de opdrachtgever al een oplossing voor zijn probleem voor ogen heeft, maar Burst tijdens de analysefase ontdekt dat een andere oplossing beter zou passen bij het probleem van de opdrachtgever.

Op basis van de analyse wordt een advies opgesteld die doorgevoerd wordt in het Functioneel Ontwerp. Pas als het Functioneel Ontwerp akkoord is, begint de daadwerkelijke bouw van de website. Zowel het FO als de bouw van de website kunnen in meerdere fases opgeleverd worden.

De punten die onder het kopje Inhoud Functioneel Ontwerp vermeld staan, hebben we voor jou verwerkt in een voorbeeld-FO. In het voorbeeld-FO zijn ook hulpmiddelen voor het schrijven van een FO verwerkt.   

Heb je vragen naar aanleiding van dit artikel? Neem dan vooral contact met ons op.

Download