Developer experience (DX) x User experience (UX)
workflow · 
5 minuten leestijd - 8 oktober 2026
De afgelopen maanden zat ik weer middenin verschillende development sprints. Wat me daarbij opviel: hoe groot het verschil is wanneer je als designer meedenkt met het team dat jouw werk bouwt. Dat merk je niet alleen in de communicatie, maar vooral in het eindresultaat. Kwaliteit komt immers niet vanzelf, zeker nu AI het bouwen versnelt maar niet altijd de juiste keuzes voor je maakt. Hieronder leg ik uit waarom developer experience (DX) en UX elkaar versterken en waarom je er bewuster mee om zou moeten gaan, inclusief mijn takeaways en tips.
Developers zijn ook gebruikers!
Als designer denk je vooral aan de eindgebruiker. Logisch, maar er is nog een groep die met jouw werk aan de slag gaat: de developers. Ze worden niet vergeten, want zij bouwen ons werk; maar juist dat vanzelfsprekende is het probleem! Als we er bewuster mee omgaan, vullen we elkaar aan.
Wat je ook ontwerpt of aanpast, het heeft direct invloed op de DX en op hun werkplek en workflow. En die werkplek is juist complexer geworden. Het gevolg:
- Extra rondes: Vragen over ontwerpen die niet helemaal kloppen kosten iedereen tijd.
- Zelfbedachte oplossingen: Developers (of hun AI) vullen gaten zelf in. Niet uit luiheid, maar om snel verder te kunnen.
- Vertraging in de sprint: Een onduidelijk ontwerp betekent werk dat langer duurt dan gepland, en AI-output controleren kost óók tijd.
Bewustwording
Refinements en sprintplanning voelen soms als “engineering-afspraken”. Zonde, want hier krijgt jouw ontwerp zijn prijskaartje. Schuif je als designer aan? Luister mee en word je bewust van het volgende:
- Je hoort eerder wat kan en wat niet: Liever vóór de sprint dan na twee weken werk.
- Meer empathie voor de gebruiker: Neem altijd je gebruikerscontext of persona’s mee, dan voelen developers voor wie ze bouwen. Ze stellen daardoor betere vragen: niet alleen “hoe bouwen we dit?”, maar ook “waarom eigenlijk, en wat heeft de gebruiker eraan?”
- Randgevallen komen eerder op tafel: Developers denken automatisch aan lege schermen, trage verbindingen en kleine apparaten.
- Je krijgt sneller antwoord: Vijf minuten tijdens de sprint in plaats uren wachten op berichtjes.
Het resultaat: minder herstelwerk, een team dat sneller oplevert en een product dat werkt zoals jij het bedoeld hebt.
Tip van Tai:
Laat developers mee-denken of mee-ontwerpen (als ze er open voor staan) in het ontwerpproces en sta open voor technische feedback. Als een developer zegt “dit kan simpeler”, is dat geen aanval op je ontwerp, maar iemand die je uren bespaart zonder de gebruiker tekort te doen. Gebruik AI gerust om randgevallen of alternatieven te brainstormen, maar blijf zelf checken of het klopt.
Kwaliteit: het fundament van elke goede samenwerking
Het sterkste argument voor DX is misschien wel kwaliteit. Goede code, een consistent ontwerp, toegankelijke knoppen: dat check je niet aan het eind van de sprint even “erin”. Het ontstaat tijdens het werk, in de samenwerking tussen design en bouw.
Hier wordt AI een risico. AI-output klinkt vaak goed, maar rammelt inhoudelijk soms. Een gegenereerd component dat nét niet voldoet aan je design system herken je alleen als je er bewust naar blijft kijken. En worstelen developers met een onduidelijk ontwerp, dan is kwaliteit het eerste dat sneuvelt onder tijdsdruk, met of zonder AI. Is het ontwerp helder en samen gemaakt? Dan is goed werk het logische gevolg.
Tip van Tai:
Vraag om DX-feedback, net als bij gebruikersinterviews:
- Wat frustreerde het team aan hoe het werk werd aangeleverd?
- Wat kostte onnodig veel tijd?
- Waar leverde AI winst op, en waar juist rommel?
Dat is gewoon onderzoek, alleen met een andere doelgroep.
Mijn persoonlijke leerpunt
Mijn grootste takeaway: ik wil mezelf niet langer zien als “designer die oplevert”, maar als mede-eigenaar van het resultaat, samen met een team van verschillende rollen. AI versnelt alles, maar maakt bewuste keuzes juist belangrijker. Iemand moet de kwaliteit bewaken en de AI-rommel eruit filteren. Dat begint bij een duidelijk design, want dat zorgt voor:
- Betere alignment tussen design en bouw.
- Duidelijkheid over wat we bouwen en waarom.
- Geborgde kwaliteit in plaats van hopen op het beste.
Tip van Tai:
Behandel je designoplevering als een product: duidelijke namen, structuur en uitleg. Gebruik het design system. Elke keer dat een developer (of een AI) iets moet namaken, lekt er kwaliteit weg. Leer ook elkaars taal: weet wat een breaking change is en leg uit hoe jij ontwerpkeuzes maakt. Zo verdwijnt de vertaalslag tussen design en code.
Meer samenwerken, minder overleveren
De echte waarde van DX zit niet in de theorie, maar in het bewust toepassen ervan. AI verandert hoe we bouwen, maar niet wat goede samenwerking is. Developers zijn gebruikers van jouw werk, en hun ervaring bepaalt mede de kwaliteit, snelheid en uitkomst van wat je samen aflevert. Hetzelfde kun je natuurlijk ook op andere stakeholders loslaten; met andere woorden: bewustwording en empathie brengen je verder.