AI kan de interface maken. Wie bepaalt of het de juiste is?

In augustus publiceerde Anthropic een draaiboek voor softwareontwikkeling met AI-agents. Nielsen Norman Group las het grondig en zag dat UX er geen eigen fase of poort in heeft. Wij denken dat NN/g gelijk heeft, en dat het vooral telt voor organisaties die ontwerpbeslissingen neerleggen bij de teams die met agents bouwen.

Wat het draaiboek weglaat

Het draaiboek houdt de zes bekende fases aan: plannen, ontwerpen, bouwen, testen, uitrollen en onderhouden. Onderweg schrijft AI de documenten (een intent, een spec, een plan) en keuren mensen ze goed bij poorten: een product owner, een engineer, een technical lead. In The Role of UX in Agentic Software Factories wijst Tanner Kohler van NN/g erop dat geen van die poorten bij UX hoort. Gebruikersonderzoek komt er niet in voor. De testfase toetst de code aan de eigen documenten van het team, niet aan wat gebruikers nodig hebben. UX blijft over als context voor de AI.

NN/g noemt drie rollen voor UX: bepalen wat het waard is om te bouwen, beoordelen wat er gebouwd is en context toevoegen aan wat AI genereert. Het draaiboek dekt alleen de derde.

Een interface maken is nog niet weten of het de juiste is

Een agent maakt in een middag een scherm dat er af uitziet. De spec is goedgekeurd en de tests slagen. Of het ook het juiste scherm is, zegt dat nog niet. Of mensen het begrijpen, of het hun echte probleem oplost, of het er überhaupt moet komen: geen spec die dat beantwoordt, want een spec bevat wat het team al dacht. Dat antwoord komt alleen van gebruikers.

Dat geldt ook voor een organisatie die ontwerpbeslissingen bij de teams legt die met agents bouwen. Die stap is logisch: wie het dichtst bij het product zit, beslist. Maar de beslissing verhuist, en de expertise verhuist niet vanzelf mee. Leg je de beslissing bij de teams, dan moet je de kwaliteitsborging meenemen: gebruikersonderzoek, expertise in UX en iemand die eigenaar is van de hele reis van de gebruiker, niet alleen van de schermen van één team. Anders klopt bij elk team de eigen flow, en ziet niemand waar een gebruiker vastloopt tussen twee flows in.

De drie rollen in onze lus

Ons proces kent dezelfde drie rollen, onder andere namen. Het begint bij de kern: wat hebben je gebruikers nodig, en wat wil je als bedrijf bereiken? Daaromheen draait een lus van maken, kiezen en meten. AI doet veel van het maken. In de andere delen zitten de rollen van NN/g.

Bepalen wat het waard is om te bouwen, dat is de kern. Voordat er iets gemaakt wordt, praten we met gebruikers en stakeholders en spreken we af wat voor allebei waar moet zijn. NN/g stelt voor om het sjabloon voor een intent in te richten rond wat gebruikers nodig hebben, met bewijs dat het probleem echt bestaat en begrip van waarom het ontstaat. Daar is een kern voor.

Beoordelen wat er gebouwd is, dat is kiezen. NN/g vraagt teams vast te leggen wanneer een review door een UX expert of een snelle gebruikerstest verplicht is, bijvoorbeeld bij een wijziging in de navigatie of een flow die afwijkt van wat gebruikelijk is. In onze lus ligt dat moment vast: we testen wat we maken, eerst snel met AI en daarna met gebruikers, en pas dan kiezen we wat blijft en wat live gaat.

De signalen volgen als het live staat, dat is meten. NN/g wil signalen van gebruikers in de monitoring, naast de technische meldingen: taken die halverwege worden afgebroken, een piek in vragen bij support. Op precies die signalen letten we na de livegang, gemeten aan de doelen uit de kern. Wat we leren, gaat terug naar de kern en wordt de volgende lus.

Context bevat wat we al weten

De derde rol, context toevoegen, dekt het draaiboek wel, en daar werken we zelf aan. Meridian, een tool die we zelf ontwikkelden, is gedeelde configuratie voor Claude Code die in elk project van ons laadt en zichzelf bijwerkt. Er staan onze huisregels in: hoe we toegankelijkheid controleren, hoe we teksten in een interface schrijven, welke design tokens een component mag gebruiken. Een agent die code schrijft in onze projecten volgt ze, en een controle in de pipeline houdt een kleur tegen die geen token is.

Dat werkt, en het laat het punt van NN/g van binnenuit zien: context kan alleen bevatten wat we al weten. Meridian zorgt dat een agent onze regels voor een goed formulier volgt. Of dit formulier er moet komen, en of de mensen die het invullen de vraag begrijpen, dat vertelt het ons niet. Hetzelfde geldt voor een design system dat agents kunnen lezen, wat NN/g terecht aanraadt: dat houdt de componenten consistent, niet het product juist. Daarvoor blijven de kern, een test met gebruikers en de cijfers na livegang nodig.

Als jouw team met agents ontwikkelt

Vier vragen bepalen of UX zijn plek houdt:

• Wie bepaalt wat het waard is om te bouwen, en met welk bewijs van gebruikers?
• Op welke momenten kijkt een UX expert ernaar, of probeert een gebruiker het, voordat het live gaat?
• Welke signalen van gebruikers staan in je monitoring naast de technische?
• Wie is eigenaar van de hele reis, over de teams heen die er elk een deel van maken?

Een agent beantwoordt er geen van. Wel maakt hij elk antwoord sneller te toetsen, zodra iemand de vraag stelt.