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.
Walter Vos
on sep 8th, 2010
@ 10:10:
Dag Bart,
Jammer dat je deze website niet meer lijkt te onderhouden want het is een onderwerp waar weinig concrete informatie over te vinden is online. Hopelijk lees je de reacties nog wel. Zou je wat kunnen vertellen over hoe een functioneel ontwerp zich verhoudt tot een programma van eisen?
Functioneel Ontwerp of Wireframes koppelen denkproces los van website vormgeving « Freelance Grafisch Vormgever, Illustrator, Copywriter – Senior Designer Michiel Nagtegaal – Copywriter Illustratie, webdesign, logo, huisstijl of grafisch
on feb 14th, 2011
@ 12:32:
[...] je website Mienspace.nl – Hoe maak je een functioneel ontwerp FunctioneelOntwerpen.nl – Wat is een functioneel ontwerp? HigherLevel.nl – Hoe maak je een simpel functioneel [...]
Theo van Lieshout
on aug 9th, 2011
@ 11:19:
Ik snap het laatste punt in de opsomming van de wat meer technische opsomming niet. Het gaat over SEO (search engine optimisation) en over een banner-tool. Dit heeft niets met elkaar te maken. Bedoel je niet SEA (search engine advertising)? Of deel het anders op in twee punten aangezien zowel SEO als SEA zeer belangrijk is in een website.
Bart Lelieveld
on dec 20th, 2011
@ 16:29:
@Theo terecht punt, eerder een slordigheidje van mijn kant. Het voorbeeld was echter puur even ter illustratie om aan te geven waar je aan kunt denken! bedankt voor je reactie
Bart Lelieveld
on dec 20th, 2011
@ 16:33:
@Walter Hoi Walter, bedankt voor je vraag. Ik denk dat een programma van eisen (een requirements document) een highlevel opsomming is van eisen en wensen, en niet een zeer uitgewerkt document. Ik maak vaak een requirementsinventarisatie /analyse voordat ik een uitgebreid functioneel ontwerp maak, zodat ik in elk geval de belangrijkste randvoorwaarden in kaart heb gebracht voordat ik erachter kom dat ik met mijn ontwerp de verkeerde kant op ga.
Ik prefereer dus om hier 2 verschillende documenten van te maken.
Wat denk jij hiervan?