Een functioneel ontwerp is de brug tussen je idee en de developer die het gaat bouwen. Of je nu nieuwe software laat ontwikkelen of een bestaande applicatie uitbreidt: het functioneel ontwerp beschrijft wat je webapplicatie moet doen, voor wie en waarom. Zonder functioneel ontwerp bouwt iedereen zijn eigen versie van het plan in zijn hoofd. Met een goed functioneel ontwerp weet je wat je krijgt, en weet de bouwer wat hij moet maken.
Wat is een functioneel ontwerp?
Een functioneel ontwerp is een document dat in gewone taal beschrijft wat een applicatie doet. Je ziet erin welke functies er zijn, wie ze gebruikt, welke gegevens het systeem vastlegt en aan welke eisen het moet voldoen. Het gaat over het wat, niet over het hoe: welke programmeertaal of database je gebruikt, staat er niet in.
Het functioneel ontwerp is daarmee ook de basis voor een betrouwbare planning en een inschatting op maat. Een developer kan pas goed inschatten hoeveel werk iets is als duidelijk is wat er gebouwd moet worden. Besteed je de opdracht uit, dan maakt het offertes ook vergelijkbaar: iedere partij rekent met dezelfde antwoorden op dezelfde vragen.
Misschien ken je ook het programma van eisen (PvE): een lijst met eisen waaraan een project moet voldoen. Een functioneel ontwerp gaat een stap verder. Het laat zien hoe die eisen er in het gebruik uitzien, met rollen, schermen en scenario’s. De eisen uit het programma van eisen vind je dus terug in het functioneel ontwerp.
Waarom een functioneel ontwerp tijd en geld bespaart
Een fout op papier herstel je met een gum. Een fout in een werkend systeem kost een herbouw. Een functioneel ontwerp dwingt je om vooraf na te denken over vragen die anders pas tijdens de bouw opduiken:
- Wat gebeurt er als een klant zijn wachtwoord vergeet?
- Wie mag een order annuleren, en tot wanneer?
- Wat moet er in het overzicht staan, en in welke volgorde?
Zo komen de verschillen in verwachtingen tussen jou, je collega’s en de ontwikkelaar boven tafel voordat er gebouwd wordt. Alle teams die aan het project werken, van opdrachtgever tot developer en tester, hebben daarna hetzelfde beeld.
Wat staat er in een functioneel ontwerp?
Een functioneel ontwerp voor een webapplicatie bevat meestal deze onderdelen:
- Doel en probleem. Welk probleem lost de applicatie op en hoe weet je of het gelukt is?
- Gebruikers en rollen. Bijvoorbeeld klant, medewerker en beheerder, met per rol wat die mag zien en doen.
- User stories. De taken die gebruikers uitvoeren, met de prioriteiten erbij.
- Schermen. Schetsen of wireframes van de user interface: welke informatie staat op welk scherm, en waar klik je naartoe?
- Gegevens. Welke informatie het systeem vastlegt, zoals klanten, orders en documenten, en hoe die aan elkaar zijn gekoppeld.
- Koppelingen. Met welke andere systemen de applicatie praat, zoals je boekhouding of CRM.
- Randvoorwaarden. Eisen rond privacy (AVG), beveiliging, toegankelijkheid, talen en de apparaten waarop het moet werken.
- Buiten scope. Wat er bewust níet in de eerste versie komt. Dit deel wordt vaak vergeten.
Voorbeelden, screenshots van de huidige werkwijze en bestaande Excel-bestanden kun je als bijlagen toevoegen.
Van wensenlijst naar user stories
Bijna elk project begint met een wensenlijst: “een dashboard”, “export naar Excel”, “koppeling met de boekhouding”. Dat is een prima start, maar een wensenlijst zegt niet waarom iets nodig is. Daardoor is het lastig om prioriteiten te stellen.
User stories lossen dat op. Je beschrijft elke wens vanuit de gebruiker, in een vaste vorm:
Als [rol] wil ik [actie], zodat [doel].
Een voorbeeld voor een simpel klantportaal:
- Als klant wil ik mijn facturen downloaden, zodat ik ze in mijn administratie kan verwerken.
- Als klant wil ik de status van mijn order zien, zodat ik niet hoef te bellen.
- Als medewerker wil ik een melding krijgen bij een nieuwe aanvraag, zodat ik die binnen een dag oppak.
Geef elke story ook acceptatiecriteria: wanneer is hij af? Bijvoorbeeld: “De klant ziet alleen zijn eigen facturen” en “Facturen zijn te downloaden als pdf”. Zo kan iedereen testen of het resultaat klopt.
Het mooie van user stories: ze maken bespreekbaar wat écht nodig is. Een wens zonder duidelijk “zodat” is vaak een kandidaat om te schrappen.
Functioneel ontwerp voorbeeld: een online boekingssysteem
Stel: een fysiotherapiepraktijk wil dat patiënten zelf online een afspraak boeken, net zo makkelijk als bestellen in een webshop. Het functioneel ontwerp voor de eerste versie ziet er op hoofdlijnen zo uit:
- Doel: minder telefoontjes aan de balie, omdat patiënten zelf boeken.
- Rollen: patiënt, therapeut en baliemedewerker.
- Pagina’s: een overzicht van vrije tijden, een boekingspagina, een bevestiging en een beheerscherm voor de balie.
- Gegevens per afspraak: naam, e-mailadres, behandeling, therapeut, datum en tijd, en de prijs van de behandeling.
- User story: Als patiënt wil ik een vrij tijdslot kiezen en boeken, zodat ik niet hoef te bellen.
- Buiten scope: online betalen en sms-herinneringen komen in een volgende fase.
Schermen en user interface
Per pagina beschrijf je kort wat erop staat: een titel, welke velden de gebruiker invult en welke knoppen er zijn. Een schets op papier is genoeg; het visuele design komt later. Op deze manier zie je heel snel of er iets ontbreekt, zoiets als een annuleerknop of een melding als een tijdslot net door iemand anders is geboekt.
Functioneel ontwerp versus technisch ontwerp
Het functioneel ontwerp en het technisch ontwerp worden vaak door elkaar gehaald. Het verschil:
| Functioneel ontwerp | Technisch ontwerp | |
|---|---|---|
| Vraag | Wat moet het systeem doen? | Hoe bouwen we het? |
| Taal | Gewone taal, voor de opdrachtgever | Technisch, voor ontwikkelaars |
| Inhoud | Rollen, user stories, schermen, eisen | Architectuur, datamodel, frameworks, hosting |
| Wie schrijft het? | Opdrachtgever samen met een adviseur | Developer of architect |
Eerst komt het functioneel ontwerp, daarna het technisch ontwerp, vlak voordat de ontwikkeling begint. Wil je meer weten over wat er in de bouwfase gebeurt, lees dan webapplicatie maken.
Zo maak je stap voor stap een functioneel ontwerp
- Beschrijf het probleem in een paar zinnen. Wat gaat er nu mis, en wat kost dat?
- Breng de gebruikers in kaart en praat met ze. Kijk mee hoe ze nu werken.
- Verzamel de wensenlijst en zet elke wens om in een user story.
- Stel prioriteiten. Wat moet erin voor de eerste versie, wat kan later? Een handige methode is MoSCoW: must, should, could, won’t.
- Schets de belangrijkste schermen. Op papier is prima. Het gaat om de flow, niet om het design.
- Bespreek het met de bouwer en werk het samen bij. Vragen van de ontwikkelaar laten zien waar het ontwerp nog niet duidelijk is.
Veelgemaakte fouten bij een functioneel ontwerp
- Te veel tegelijk willen. Alles in versie één stoppen maakt het project groot en traag. Begin met de kern, zoals bij een MVP.
- Oplossingen beschrijven in plaats van problemen. “Een knop rechtsboven” zegt minder dan “de gebruiker moet snel een nieuwe order kunnen starten”.
- Uitzonderingen vergeten. Wat als een betaling mislukt, of een klant twee accounts heeft?
- Het document als contract behandelen. Je leert tijdens het bouwen. Een functioneel ontwerp mag meegroeien.
Hoe Inesta helpt met je functioneel ontwerp
Je hoeft een functioneel ontwerp niet alleen te schrijven. Wij gaan samen met je aan tafel, stellen de vragen die vaak vergeten worden en zetten je wensenlijst om in heldere user stories en schetsen. Geen dik document vooraf, wel snel iets tastbaars waar je op kunt reageren.
Inesta bouwt sinds 2005 webapplicaties, voor ruim 150 klanten. Benieuwd hoe we een webapplicatie ontwikkelen, van eerste gesprek tot livegang? Of vertel ons je idee, dan hoor je binnen 1 werkdag van ons.