Een functioneel ontwerp opstellen betekent dat je op papier zet wat je software moet kunnen, voor wie en waarom. Nog niet hoe het technisch werkt, maar wat een gebruiker ermee doet. Het is je wensenlijst, alleen dan zo duidelijk dat een ontwikkelaar er een eerlijke prijs en planning op kan maken.
Je hoeft er geen IT-kennis voor te hebben. Jij kent je bedrijf, je klanten en je processen het best. In dit artikel lees je wat er in een functioneel ontwerp hoort, hoe je het stap voor stap maakt en welke fouten je beter kunt vermijden.
Wat is een functioneel ontwerp precies?
Een functioneel ontwerp (vaak afgekort tot FO) beschrijft het gedrag van een systeem vanuit de gebruiker. Denk aan zinnen als: een klant kan inloggen en zijn facturen downloaden, of een medewerker ziet elke ochtend welke opdrachten vandaag gepland staan. Het technisch ontwerp komt daarna en gaat over databases, servers en code. Dat laat je aan de bouwer over.
Soms heet het ook een programma van eisen of een lijst met functionele eisen. De naam maakt weinig uit. Waar het om gaat: iedereen leest hetzelfde document en heeft daarna hetzelfde beeld van het eindresultaat.
Waarom een wensenlijst je geld en gedoe bespaart
Zonder duidelijke wensenlijst raadt een ontwikkelaar wat je bedoelt. Dat gaat vaak mis op de details, en juist die details kosten tijd. Een goed functioneel ontwerp helpt je op een paar manieren:
- Je krijgt offertes die je echt kunt vergelijken, omdat elke partij op hetzelfde rekent.
- Je ziet zelf eerder waar je nog keuzes moet maken, voordat er code geschreven is.
- Wijzigingen halverwege worden kleiner, want de grote lijnen staan vast.
- Je hebt na oplevering iets om tegen af te vinken: doet het systeem wat we afspraken?
Lees ook hoe je offertes van webbureaus vergelijkt. Een functioneel ontwerp is daar de basis van.
Wat hoort er in een functioneel ontwerp?
Een functioneel ontwerp voor een klein of middelgroot project hoeft geen dik rapport te zijn. Vijf tot vijftien pagina's is meestal genoeg. Deze onderdelen horen erin:
- Doel: welk probleem los je op en hoe weet je dat het gelukt is? Bijvoorbeeld: offertes in tien minuten in plaats van een uur.
- Gebruikers en rollen: wie gaan het gebruiken? Klant, medewerker, beheerder. Wat mag elke rol zien en doen?
- Functies: wat kan elke gebruiker doen? Schrijf dit per scherm of per taak.
- Gegevens: welke informatie leg je vast? Klantnaam, adres, ordernummer, status, bijlagen.
- Koppelingen: met welke andere systemen moet het praten, zoals je boekhouding, agenda of webshop?
- Schermschetsen: simpele tekeningen op papier of in een gratis tool zijn genoeg.
- Randvoorwaarden: aantal gebruikers, talen, privacy, toegankelijkheid en wanneer het klaar moet zijn.
Zo stel je een functioneel ontwerp op in zes stappen
Je kunt het functioneel ontwerp opstellen in een paar middagen. Werk in deze volgorde, dan blijft het overzichtelijk.
- Stap 1. Beschrijf het huidige proces. Hoe gaat het nu, met welke Excel-lijsten, mails en telefoontjes? Schrijf ook op waar het knelt.
- Stap 2. Praat met de mensen die het gaan gebruiken. Collega's en soms klanten zien dingen die jij mist.
- Stap 3. Schrijf user stories. Dat zijn korte zinnen in de vorm: als [rol] wil ik [actie], zodat [doel]. Bijvoorbeeld: als planner wil ik een opdracht naar een andere dag slepen, zodat ik snel kan schuiven bij ziekte.
- Stap 4. Bepaal per wens de prioriteit. Gebruik must, should, could en won't. Alles wat must is, hoort in de eerste versie.
- Stap 5. Maak schetsen van de belangrijkste schermen. Pen en papier is prima. Het gaat om de inhoud, niet om de kleuren.
- Stap 6. Laat het lezen door iemand die er niet bij was. Snapt die persoon wat het systeem doet? Dan is het helder genoeg.
Functioneel ontwerp voorbeeld: een simpel klantportaal
Stel, je hebt een installatiebedrijf en wilt een portaal waar klanten hun onderhoudsafspraken zien. Een deel van je functioneel ontwerp kan er zo uitzien:
- Doel: minder telefoontjes over afspraken en facturen.
- Rollen: klant, monteur, kantoor.
- Als klant wil ik mijn volgende onderhoudsafspraak zien, zodat ik weet wanneer de monteur komt.
- Als klant wil ik een afspraak kunnen verzetten binnen de vrije tijden, zodat ik niet hoef te bellen.
- Als kantoor wil ik een melding krijgen bij elke verzetting, zodat de planning klopt.
- Als klant wil ik mijn facturen als pdf downloaden. Koppeling: boekhoudpakket.
- Prioriteit: afspraak zien en facturen zijn must, verzetten is should, een chatfunctie is won't voor versie 1.
Je ziet: geen technische woorden, wel heel concreet. Meer over dit soort projecten lees je in het artikel over een klantportaal laten maken.
Veelgemaakte fouten bij het opstellen van functionele eisen
Een functioneel ontwerp schrijven is niet moeilijk, maar er zijn een paar valkuilen die vaak terugkomen:
- Oplossingen voorschrijven in plaats van problemen beschrijven. Schrijf niet: er moet een dropdown komen. Schrijf: de gebruiker kiest uit vijf vaste statussen.
- Alles is even belangrijk. Als alles must is, wordt de eerste versie te groot, te duur en te laat.
- Uitzonderingen vergeten. Wat gebeurt er als een klant twee adressen heeft, of als een betaling mislukt?
- Te vaag blijven. Gebruiksvriendelijk en snel zijn geen eisen. Beschrijf liever wat iemand in hoeveel klikken moet kunnen.
- Het document na de start niet meer bijwerken. Een functioneel ontwerp leeft. Pas het aan als je samen iets anders besluit.
Moet je het functioneel ontwerp zelf schrijven?
Niet per se. Jij levert de kennis van je bedrijf, de ontwikkelaar helpt die om te zetten in heldere functionele eisen. Bij kleinere projecten is een goed gesprek plus een korte wensenlijst vaak genoeg. Bij grotere systemen loont het om het ontwerp samen uit te werken voordat de bouw begint. Hoe dat hele traject verder loopt, lees je in hoe softwareontwikkeling verloopt.
Twijfel je nog of je wel maatwerk nodig hebt? Dan helpt het om eerst te kijken of maatwerk of een standaard pakket beter past. Ook die keuze maak je makkelijker met een wensenlijst op papier.
Hoe we bij Violexa met je wensenlijst werken
Bij Violexa beginnen we elk software-project met jouw wensen, in gewone taal. Hisham loopt je proces met je door, stelt de vragen die je misschien nog niet had bedacht en zet het om in een helder plan met prioriteiten. Zo weet je vooraf wat je krijgt. Grotere projecten krijgen een vaste prijs vooraf, op papier.
Een webapplicatie op maat begint bij ons vanaf €1.799 excl. btw (€2.177 incl. btw) per project, inclusief ontwerp, ontwikkeling, een ontwerp dat op elk scherm werkt en training. Wat jouw project kost, hangt af van wat er op je wensenlijst staat.
Wil je je wensenlijst eens laten toetsen? Plan dan een gratis quickscan. In 30 minuten, online of op locatie, bespreken we je plan. Daarna krijg je kort schriftelijk advies met een prijsindicatie, zonder verplichting.
Veelgestelde vragen
Hoe stel je een functioneel ontwerp op?
Begin met het doel en de mensen die het systeem gaan gebruiken. Beschrijf daarna per rol wat iemand moet kunnen doen, liefst als korte user stories. Geef elke wens een prioriteit en maak simpele schetsen van de belangrijkste schermen.
Wat is het verschil tussen een functioneel en een technisch ontwerp?
Een functioneel ontwerp beschrijft wat het systeem doet vanuit de gebruiker. Een technisch ontwerp beschrijft hoe het gebouwd wordt, met databases, servers en code. Als opdrachtgever schrijf je vooral mee aan het functionele deel.
Hoe lang moet een functioneel ontwerp zijn?
Voor een klein of middelgroot project is vijf tot vijftien pagina's meestal genoeg. Lengte is niet het doel. Het moet duidelijk genoeg zijn dat iemand die er niet bij was snapt wat het systeem moet doen.
Wat zijn user stories?
User stories zijn korte zinnen die een wens beschrijven vanuit de gebruiker: als [rol] wil ik [actie], zodat [doel]. Ze helpen om te focussen op wat iemand wil bereiken, in plaats van op technische oplossingen.
