Productontwerp · 2026 · Aantoon

Van een brief van 27 hoofdstukken naar een bouwklare MVP in drie weken

Design system en kernflows voor een AI-platform voor contractnaleving.

Productontwerp · Design system · UX-onderzoek · Figma · Untitled UI

Dashboard van Aantoon van dichtbij: een paar tellers van wat aandacht vraagt, een raster met statussen van verplichtingen en de meest urgente taken — Dashboard, van dichtbij. Eerst wat jou nodig heeft, daarna de rest in Tasks.

hoofdstukken in de brief: 27
budget, bewust begrensd: 1 maand
schermen en een design system: Zo'n 29
een developer die ermee bouwde: Week 3

Aantoon is een Nederlands AI-platform voor contractnaleving in de publieke sector. Een complex domein. Een brief van 27 hoofdstukken. Geen visuele identiteit. Eén maand, en een developer die in week 3 zou beginnen met bouwen.

Opdrachtgevers in de publieke sector sluiten contracten vol verplichtingen, en hun onderhoudsleveranciers moeten aantonen dat ze die nakomen. Aantoon laat per verplichting zien of die is nagekomen en waar het bewijs zit. Na drie weken had de product owner een compleet design system en zo'n 29 schermen, en was de developer daarmee aan het bouwen.

De brief

De product owner kwam voor een BTNG Design Subscription van één maand, met een bewust begrensd budget. De brief bevatte 2 tot 3 maanden werk. Dat zei ik voordat de maand begon, en de product owner schrapte tot het paste.

De product owner bepaalde de volgorde op een gedeeld bord, één ding tegelijk, met een eerste versie binnen 24 tot 48 uur en één wekelijkse call. De regel, vooraf afgesproken: wat bovenaan staat wordt afgemaakt, wat onderaan staat misschien niet. Mobiel, rollen en rechten, gebruikerstests en een volledig klikbaar prototype vielen buiten de scope.

Naar de kern

Voordat ik een scherm tekende, schreef ik de kern van het product op. Vijf begrippen: contract, eis, verplichting, bewijs en oordeel. Drie flows: inlezen, aantonen en overzicht. Eén AI-regel: elke AI-stap heeft een handmatige route.

“Verplichting” kwam in geen enkel document van de klant voor. Uiteindelijk droeg dat woord het hele product.

Ik bestudeerde ook bestaande tools voor contractmanagement. Alles wat niet nodig was voor v1 werd geparkeerd met een versienummer.

Week 1

Het design system

Het design system staat op Untitled UI, met de eigen componenten van Aantoon erbovenop. Lettertypes, woordkeuze en kleur lopen via tokens, zodat elk ervan op één plek verandert, zoals de product owner vroeg. Alleen Inter, slate als neutrale kleur en merkkleur, een paar statuskleuren, light mode. Twee beslissingen dragen het systeem.

De eerste is een statuscomponent die je ook zonder kleur kunt lezen. Statuskleuren markeren status, en alleen wat actie vraagt trekt de aandacht.

De tweede is hoe AI in beeld komt. De AI van Aantoon leest eisen uit contracten en stelt oordelen voor op basis van bewijs. Hij doet alleen voorstellen: een mens ziet en modereert elke beslissing. Gearceerd betekent een AI-voorstel, egaal een menselijke beslissing, en allebei hebben ze een bronregel.

Componenten van Aantoon: taakregels met één actie, statusbadges, de verplichtingenmatrix, een bewijsupload en een AI-concept dat op bevestiging wacht — Componenten. Taakregels met één actie, statusbadges, de matrix, bewijs uploaden en een AI-concept om te bevestigen.

Week 2

Inlezen

Week 2 ging over hoe een contract in Aantoon komt.

Klikbare wireframes vóór Figma

Claude bouwde de wireframes als grijze, klikbare HTML. Ik bepaalde wat erin kwam. Met een schakelaar zag je het scherm van de opdrachtgever of van de opdrachtnemer, en elk scherm had een notitie die eindigde met open vragen voor de wekelijkse call. Negen versies in zo'n drie weken, daarna bouwde ik de schermen zelf opnieuw in Figma. HTML-wireframes zijn de snelste manier om te laten zien, uit te leggen en te itereren.

Een contract aanmaken

Eén scherm, drie groepen

Scherm contract aanmaken: contractbestanden één voor één ingelezen, een onleesbare scan gemarkeerd en de contractgegevens ingevuld — Contract aanmaken. Bestand voor bestand ingelezen, een onleesbare scan gemarkeerd, de contractgegevens ingevuld.

Uploaden, inlezen en controleren begonnen als losse stappen. Nadat de product owner 9 open punten schriftelijk had beantwoord, werd “New contract” één scherm, met de resultaten gegroepeerd als verwerkt, onleesbaar en mogelijk ontbrekend. Elke eis gaat daarna in een register.

Resultaat van het inlezen van een contract: vijf bestanden verwerkt, gevolgd door het eisenregister met elke eis, de bron en de status — Resultaat en register. Vijf bestanden ingelezen, daarna elke eis met bron en status.

Eisen beoordelen, naast elkaar

Een eis opent met de contracttekst, het AI-voorstel en de bewerkbare definitieve eis naast elkaar.

Eis beoordelen: de brontekst uit het contract, het AI-voorstel en de bewerkbare definitieve eis in drie kolommen — Eis beoordelen. De brontekst, het AI-voorstel en de bewerkbare beslissing naast elkaar.

Week 3

Aantonen

Bewijs, voorstel, beslissing

In week 3 zat een werksessie van vijf uur, op locatie. Die leverde het verplichtingenpaneel op: bewijs, AI-voorstel, menselijke beslissing en geschiedenis. De opdrachtnemer krijgt een takenlijst en een bewijsinzending met een documentcheck.

Bewijs indienen: vier geüploade bestanden, per verplichting gecontroleerd als voldoet, voldoet niet of niet vast te stellen — Bewijs indienen. Vier bestanden, per verplichting gecontroleerd: voldoet, voldoet niet, niet vast te stellen.

Documentcheck: één plan gecontroleerd tegen elke eis die het moet dekken, met de bijbehorende passage, het AI-advies en de beslissing — Documentcheck. Eén plan tegen elke eis die het moet dekken: passage, AI-advies, beslissing.

De matrix

Verplichtingen staan in een lijst of in een matrix. De matrix laat een heel contract in één keer zien.

Verplichtingenmatrix: eisen per object per kwartaal, grotendeels grijs met een paar gekleurde cellen, en rechts het verplichtingenpaneel open — Verplichtingenmatrix. Eisen per object per kwartaal, met het verplichtingenpaneel open.

De overdracht

De developer begon in week 3 te bouwen op basis van de ontwerpen, en in week 4 maakte de product owner de schermen leidend voor de MVP.

De overdracht kwam een week voor het einde van de maand: één Engelstalig HTML-document met de v1-scope, elk scherm gelinkt aan Figma, de regels, het design system en de open punten. Daarnaast staan een gedateerd beslissingslog en een productwoordenboek in het Engels en Nederlands, omdat het product in twee talen wordt gebouwd. Daarna pauzeerde mijn scope, zoals gepland.

Hoe AI me daarbij hielp

De klant deelde een echt, vertrouwelijk onderhoudscontract. Ik gebruikte AI om het naast mijn model te leggen en te vinden waar het model niet klopte. Zo werd de documentcheck een eigen scherm. Het contract staat hier niet, en elk contract, object en elke leverancier in beeld is verzonnen.

Een AI-notulist nam de calls op. Het gedateerde beslissingslog is de bron van waarheid, niet de opnames.

Claude bouwde de wireframes. Ik legde de eerste set naast mijn kern, en die faalde op vijf punten. Het dashboard had een percentagescore die problemen verbergt, en het menu toonde schermen die nog niet bestonden. Dat loste ik op voordat de klant de volgende versie zag.

Toen de klant een lang antwoord stuurde, legde ik dat eerst voor aan vijf onafhankelijke Claude-agents: één op architectuur, een scepticus, een pragmaticus, een contractmanager en een UX-designer. Ze waren het erover eens dat de domeinlogica klopte en het statusmodel te groot was. Ik nam tien van hun wijzigingen over en stuurde de negen vragen terug die de product owner schriftelijk beantwoordde.

Op de dag van de werksessie ondervroeg Claude me, één vraag tegelijk, tot elk open punt een beslissing had, met de kern eerst als regel.

Dezelfde regel als in het product: AI deed voorstellen, en ik zag en modereerde elke beslissing.

Wat dit laat zien

Het domein kreeg de eerste dagen van de maand. Vijf begrippen, drie flows en één AI-regel kwamen vóór elk scherm, en elk scherm is daarop terug te voeren.

Daarom kon één developer in week 3 beginnen. De begrensde scope hielp ook: de product owner koos wat eerst kwam, en al het andere heeft een versienummer.

“Philip had zich binnen enkele dagen zo goed in ons domein verdiept dat het voelde alsof hij er al jaren in werkte. Bijna eng hoe snel hij de inhoud doorgrondde en vertaalde naar een sterk ontwerp. Dat heeft ons enorm geholpen: binnen drie weken lag er een complete set ontwerpen voor onze MVP. Indrukwekkend hoe hij snelheid, inhoudelijk begrip en kwaliteit combineert.”

Jeroen van de Pol Productowner

“Het resultaat is prachtig, ik ben er zo blij mee.”

Jeroen van de Pol Productowner, per e-mail na de overdracht

Bouw je een B2B-product in een complex domein, met een developer die op schermen wacht?

Maak een afspraak

Terug naar cases