Op het scherm om een offerte goed te keuren heet die actie "Validatie". In de lijst ernaast heet diezelfde stap "Akkoord". En in de mail die je klant krijgt, staat "Bevestigd". Niemand heeft dat zo beslist. Het is gewoon zo gegroeid.
Wie software laat bouwen, kent dat. Kleine inconsistenties die elk op zich onschuldig zijn, maar samen zorgen dat je team twijfelt, fouten maakt en uiteindelijk terugvalt op Excel. En nu AI steeds meer code schrijft, groeit software sneller dan ooit. Die inconsistenties dus ook.
Model-driven development is een manier om daar grip op te houden. Het idee: je beschrijft eerst in één model hoe je bedrijf werkt, met de processen, de begrippen en de regels. De software wordt daaruit gebouwd en ertegen gecheckt. Meestal wordt dat verkocht als iets technisch, iets voor developers. Maar je gebruikers merken het verschil ook.
De software is gebouwd rond hun manier van werken, niet je database
Veel bedrijfssoftware is opgebouwd rond tabellen: klanten, orders, producten. Elk krijgt een lijst en een formulier. Handig voor wie het bouwt, minder voor wie ermee werkt. Je medewerkers denken niet in tabellen, maar in taken: een offerte opmaken, een levering inplannen, een klacht afhandelen.
Beschrijft het model die taken en processen, dan volgt de software dezelfde logica. Elk scherm bestaat omdat iemand daar iets moet doen, en toont precies wat daarvoor nodig is. Dat begint bij goed in kaart brengen hoe mensen echt werken.
Eén model betekent ook één woordenlijst. Een klant heet overal klant, een status betekent overal hetzelfde en dezelfde regel geldt op elk scherm. Het is hetzelfde principe als bij object-oriented UX: eerst de begrippen juist definiëren, dan de schermen.
Fouten voorkomen in plaats van melden
Iedereen kent de foutmelding na het invullen van een lang formulier: "Er is iets misgegaan." Die meldingen bestaan omdat de regels ergens diep in de code zitten, en de interface ze pas ontdekt wanneer het te laat is.
Staan de regels expliciet in het model, dan weet de software op voorhand wat mag. Een knop voor een actie die nog niet mag, is uitgeschakeld en zegt waarom: "Deze offerte heeft nog geen contactpersoon." Het gedrag van de software wordt voorspelbaarder, ze doet wat het model zegt.
Software die niet in stilte aftakelt
Dit is misschien het grootste voordeel, en het minst zichtbare. De kwaliteit van software wordt zelden in één keer slecht. Het gebeurt stukje bij beetje: een update hier, een snelle aanpassing daar. Na een jaar staat de knop die je dagelijks gebruikt ergens anders, of is hij verdwenen.
Met AI kan dat sneller gaan. Een AI-tool werkt met de context die hij op dat moment krijgt, en wat daar niet in staat, kan bij de volgende wijziging sneuvelen. Daarom is de juiste context meegeven zo belangrijk. Loopt elke wijziging via het model en wordt de code ertegen gecheckt, dan valt een verdwenen stap of een gewijzigde regel meteen op. Niet pas wanneer een klant belt.
Wat de designer bedoelde, komt ook in de software
In veel projecten leven designs in een apart bestand: een Figma, een document, een reeks screenshots. De software wordt ernaast gebouwd en drijft er langzaam van weg. Na drie releases kijkt niemand nog naar het ontwerp.
Een goed model is leesbaar voor mensen die geen code schrijven. Een inzicht uit een gesprek met je gebruikers wordt zo een aanpassing in het model, en die komt vanzelf in de software terecht. En omdat een wijziging snel tot een werkende versie leidt, kan je vaker testen met echte gebruikers in plaats van met mockups. Dat is belangrijk, want snel het verkeerde bouwen blijft het verkeerde.
Eén model, elk kanaal
Je software heeft steeds vaker meer dan één soort gebruiker. Een webapp, een mobiele app, een koppeling met een ander systeem, en steeds vaker ook AI-agents die taken uitvoeren namens je medewerkers. Komen ze allemaal uit hetzelfde model, dan gedragen ze zich hetzelfde: dezelfde regels, dezelfde begrippen, hetzelfde resultaat.
Hoe wij dat aanpakken
Bij Tandem is het model het startpunt van elk project. We brengen eerst in kaart hoe mensen werken: welke stappen ze doorlopen, welke begrippen ze gebruiken en welke regels er gelden. Dat is UX-werk, en het wordt het fundament waar de software uit gebouwd wordt, ook wanneer AI het bouwwerk doet. Wat er gebouwd wordt, checken we terug tegen dat model.
Wil je weten of je eigen software hier baat bij heeft? Stel jezelf één vraag: staat er ergens beschreven hoe je bedrijf werkt, los van de code? Als het antwoord nee is, zit die kennis in de hoofden van een paar mensen. Of nergens.
Benieuwd wat een model voor jouw software kan betekenen? Stuur ons een bericht, we denken graag even mee.
