De Validate-fase: aannames toetsen
Drie soorten aannames, negen proeven om ze te toetsen, en waarom elke aanname die hier omvalt een verbouwing is die je later niet hoeft te doen.
Introductie
Van ontwerp naar prototype
In de Launch-fase hebben we het kernprobleem scherp gekregen en samengevat in één 'hoe kunnen we'-vraag. Die vraag is het startpunt van de Validate-fase, en dit is de fase waarin de meeste projecten hun geld terugverdienen of juist worden gestopt.
In deze blog
Wat valideren precies is, welke drie soorten aannames je moet toetsen, met welke proeven je dat doet, en hoe dat er in onze projecten uitzag. Dit stuk bevat ook het materiaal uit ons eerdere artikel over het valideren van AI-oplossingen; die twee gingen over hetzelfde en staan nu bij elkaar.
Valideren is aannames onderuit proberen te halen
Met valideren bedoelen we: bewijzen of juist ontkrachten wat je over de oplossing denkt. Wat gebruikers willen, hoe de techniek zich gedraagt, welk effect het heeft op het werk. Die aannames vallen in drie soorten, en het scheelt veel tijd als je ze apart houdt.
- Haalbaarheid. Kan het technisch en praktisch, binnen de randvoorwaarden die er zijn? Bestaat de data, mag je erbij, en houdt het model het bij deze hoeveelheden?
- Wenselijkheid. Lost het een probleem op dat mensen echt hebben, en past het bij hoe zij werken?
- Toekomstbestendigheid. Is het over twee jaar nog te betalen en te beheren? Wie doet dat dan?
Ongemakkelijk, en de moeite waard
Toegeven dat je iets nog niet weet, past slecht bij hoe in veel organisaties naar projecten wordt gekeken: daar hoort een plan bij met een uitkomst. Maar de rekening voor een aanname die je hebt overgeslagen, komt later en is hoger. In dit stadium is het doel niet om in één keer de goede oplossing neer te zetten, maar om zo snel mogelijk te weten waar je het mis had.
Ons advies is dan ook onveranderlijk hetzelfde: laat eindgebruikers zo vroeg mogelijk met iets echts werken, haal op wat er niet klopt, en kom met een betere versie terug.
Experimenten
Proeven per soort aanname
Voor elk van de drie soorten aannames bestaan proeven die je in een paar dagen kunt doen. Niet alle negen elke keer: kies degene die de grootste onzekerheid wegneemt.
Techniek
Haalbaarheid toetsen
Een proof of concept die alleen de kern doet, om te zien of het überhaupt kan. Een dataverificatie: is de data er, is hij goed genoeg, en mag je hem gebruiken? En een technische toets of de bestaande infrastructuur het aankan. Die laatste wordt het vaakst overgeslagen en levert de vervelendste verrassingen op.
Gebruikers
Wenselijkheid toetsen
Gebruikerstests op een prototype of zelfs op schetsen; je hoeft niets werkend te hebben om te zien of iemand snapt wat hij ziet. Een wizard-of-oz-test, waarbij een mens achter de schermen doet wat het systeem later moet doen: verrassend leerzaam en bijna gratis. En A/B-tests zodra je twee varianten hebt en niet weet welke beter valt.
Houdbaarheid
Toekomstbestendigheid toetsen
Verkennen wat het kost en wie het gaat beheren, en of dat past bij de organisatie. Bij een oplossing die persoonsgegevens raakt hoort hier ook de formele kant: een gegevensbeschermingseffectbeoordeling, en bij overheidsalgoritmes vaak een mensenrechtentoets. Die doe je tijdens de ontwikkeling, niet erna.
Best practices
Concrete oplossingsrichtingen in beeld
In de Validate-fase zetten we ideeën om in tastbare prototypen. Per project werkten we de “Hoe kunnen we…?”-vraag uit tot een concrete oplossingsrichting. In onderstaand overzicht laten we zien welke keuzes we maakten, hoe we deze vertaalden naar een prototype en welke inzichten dat opleverde voor de volgende stap in het proces.
BMC
De eerste leads voor domeinspecifieke configuraties
Tijdens de Validate-fase legden we de eerste door PRYSM gegenereerde leads voor aan eindgebruikers. Samen onderzochten we de kwaliteit, relevantie en presentatie van deze leads. Deze fase bood ruimte om context en samenvattingen te toetsen, verbeterpunten te identificeren en een eerste iteratie te maken op de lay-out van PRYSM.
NOC*NSF
Modelvalidatie met alle input: sportbeleid, thema’s en gemeentelijke context
Voor NOC*NSF ontwierpen we de dataflow en interfaces en legden deze voor aan eindgebruikers. We selecteerden de meest nauwkeurige en betrouwbare AI-algoritmes, sloten de benodigde datasets aan en trainden het model voor optimale resultaten.
BeleidsBot
De eerste chatsessies
We ontwikkelden de eerste versie van de BeleidsBot, waarin basisfunctionaliteiten en vormgeving samenkwamen. Gebruikers konden collecties aanmaken en vervolgens chatten met een specifieke set documenten. Om deze versie te toetsen, organiseerden we validatiesessies bij vijf gemeenten. Testgroepen beoordeelden de kwaliteit van de antwoorden, de bruikbaarheid van de functies en wensen voor toekomstige uitbreidingen. Deze sessies gaven ons als ontwikkelteam een scherp beeld van de richting waarin de BeleidsBot verder moest worden ontwikkeld.
InkoopInzicht
Van Excel naar Dashboard
In de Validate-fase ontwikkelden we een eerste reeks prototypes in Power BI. Hiervoor gebruikten we aanvankelijk Excel-imports, zodat we de eerste ideeën over dashboards konden toetsen voordat het datawarehouse ingericht was. In werkgroepen, presentaties en sprint reviews konden we functionaliteit en ontwerp voortdurend aanscherpen met feedback van eindgebruikers. De output uit deze sessies vertaalden we naar een gedetailleerdere vormgeving van de dashboards. Deze iteratieve aanpak zorgde voor oplossingen die echt aansloten bij de praktijk.
Data Discovery Sprint
Ideeën genereren en keuzes maken
Het traject bij de Rijksinkoopsamenwerking volgde een afwijkend format. De tweede sessie stond volledig in het teken van ideeën genereren en keuzes maken. Via een Crazy-8 met persona’s bedachten we 45 mogelijke oplossingsrichtingen rond de centrale “Hoe kunnen we..?”-vraag uit de Launch-fase. Hieruit kozen we de meest impactvolle: een centrale gegevensvoorziening die met aanpalende systemen communiceert, zodat data langs het proces wordt verrijkt in plaats van versnipperd opgeslagen. Om te kunnen starten met de bouw van een werkend prototype, brachten we de belangrijkste functionaliteiten van het nieuwe systeem in kaart. Hiervoor gebruikten we de productzijde van het Value Proposition Canvas , zoals eerder in deze serie besproken.
AI-gedreven Ondersteuning voor Kamervragen
Kamervragen sneller, nauwkeuriger en consistenter beantwoorden
In 2023 voerden wij de Ministerie-overstijgende pilot Kamervragen uit, samen met directies van Ministeries van Financiën, EZK, VWS, RVO, Belastingdienst en Douane. Doel was te onderzoeken welke waarde AI-tool Codi kan toevoegen aan het beantwoorden van Kamervragen. In de Validate-fase ontwierpen we intuïtieve interfaces en legden deze voor aan eindgebruikers. Ook selecteerden we, via cross-validatie, de meest nauwkeurige en betrouwbare AI-algoritmes.
Ontwerp van de eerste prototypes
Wat de Validate-fase oplevert
Aan het eind liggen er blauwdrukken: prototypes die met gebruikers zijn getoetst en zijn doorgetekend tot ontwerpen die je kunt bouwen. Daarnaast weet je hoe die oplossing binnen de bestaande technische omgeving past, want dat is in deze fase uitgezocht en niet aangenomen.
En je weet welke aannames níet klopten. Dat is geen bijproduct maar de eigenlijke opbrengst: elke aanname die hier omvalt, is een verbouwing die je straks niet hoeft te doen.
Een blik vooruit
Awaken-fase
In de volgende blog gaan we naar de Awaken-fase: van gevalideerd prototype naar een werkend product, met de databronnen eronder en de logica erin. Dat kan een dashboard zijn, een app of een AI-toepassing; de fase is dezelfde.
Meer weten?
Benieuwd hoe we uitdagingen binnen jouw organisatie kunnen omzetten naar een prototype? Neem contact met ons op voor een vrijblijvende intake.
