16 mrt 2026
Ergens in jouw organisatie bouwt iemand nu iets wat al drie keer eerder gebouwd is
Jeroen Meijers
User Experience Designer
Terwijl Team A in OutSystems een interface bouwt, doet Team B precies hetzelfde. Op hun eigen eilandje, met hun eigen budget. Waarom laten we onze duurste experts telkens het wiel opnieuw uitvinden?
Ik ben Jeroen Meijers. Als frontend developer en UX-expert bij Team Resilience heb ik de afgelopen tijd van dichtbij gezien waar die vertraging vandaan komt.
Je kiest voor low-code omdat je wilt meters maken. Ik zie vaak het tegenovergestelde gebeuren. Maar waar zit dat hem dan in?
De backend staat al snel als een huis en ook de data is zo op orde. Maar de daadwerkelijke oplevering naar de eindgebruiker? Die loopt vaak flinke vertraging op.
De echte vertraging zit vaak niet in de techniek of de skills van je developers. Het zit in het ontbreken van een centrale strategie voor je frontend en UX.
Laten we eens kijken hoe dat werkt (en misgaat) in de praktijk.
Het probleem van de eilandjes
Grote organisaties knippen hun IT-afdeling vaak op in verschillende teams. Team A doet de IT voor de financiële afdeling, Team B voor het transport, Team C voor het managen van de voorraad. Logisch, want zo houdt iedereen zijn focus.
Maar in de praktijk betekent dit dat elk team op zijn eigen eilandje aan het bouwen is. Ze werken allemaal aan hun eigen applicatie. Aan de backend is dat vaak nog wel oke, elk team heeft zijn eigen databronnen waarmee gewerkt wordt. Maar zodra er schermen gebouwd moeten worden waar een gebruiker naar kijkt, ontstaat er een enorme inefficiëntie van dubbele ontwikkeling.
Ik zal het concreet maken. Stel, vijf verschillende teams hebben in hun applicatie een tabel nodig om data te tonen. Een vrij standaard onderdeel, zou je zeggen.
In de huidige situatie gebeurt het volgende: team A begint aan hun taak (in Scrum-termen: een 'story'). Ze zien dat ze een tabel nodig hebben. Die is er nog niet, dus de developers moeten die zelf gaan bouwen. Ze kennen er veel 'story points' aan toe, omdat ze niet alleen de data moeten koppelen, maar ook moeten priegelen met de opmaak.
Tegelijkertijd loopt team B tegen precies hetzelfde aan. Ook zij gaan die tabel bouwen. En team C, D en E ook.
Je hebt nu vijf teams die allemaal tijd en budget besteden aan het bouwen van exact hetzelfde component. Vijf keer wordt het wiel opnieuw uitgevonden. En het ergste is: waarschijnlijk ziet die tabel er elke keer weer net even anders uit, omdat er geenafstemming is. Dat is niet alleen zonde van de tijd, het zorgt ook voor verwarring bij de eindgebruikers, die vaak met meerdere interne applicaties tegelijk werken.
Developers willen niet 'pixel pushen'
Daar komt nog een menselijke factor bij. Veel OutSystems-developers zijn van huis uit gericht op de achterkant van de applicaties: logica, databases, API's. Dat is hun kracht. Vraag je zo'n developer om zich druk te maken over de exacte kleur grijs van eenrandje of de witruimte tussen twee knoppen (wij noemen dat 'pixel pushen'), dan worden ze daar over het algemeen niet gelukkig van.
Daardoor krijg je last van frustratie in het team. De snelheid gaat eruit, de 'story points' per taak gaan omhoog, omdat ze opzien tegen het frontend-werk. En de kwaliteit van de interface wordt er ook niet beter op.
De oplossing: de centrale LEGO-doos
Hoe los je dit op? Door het werk centraal te organiseren.
Tijdens mijn laatste project werkte ik voor een grote logistieke speler. Daar hebben we een overkoepelend frontend-team opgezet.
Dat team zorgde voor een thema dat je kunt zien als een grote doos met LEGO-blokjes. In die doos zitten alle kant-en-klare onderdelen die de teams nodig hebben.
De basis:
Kleuren, lettertypes en huisstijl worden ingesteld.De componenten:
Wij bouwen die ene tabel en andere componenten. We zorgen dat het perfect werkt, dat je er tekst, knoppen of icoontjes in kunt zetten en dat het er goed uitziet op mobiel en desktop.De logica:
We bedenken hoe een menu uitklapt of hoe een formulier reageert.
Het effect op de werkvloer is gigantisch. Als Team A nu die tabel nodig heeft, hoeven ze die niet meer te bouwen. Ze pakken simpelweg het blokje 'tabel' uit de centrale doos.
In plaats van dat ze 8 punten rekenen voor een taak omdat ze zelf het design moeten doen, kost het ze nu misschien nog maar 2 punten om de data erin te gieten. Ze hoeven niet na te denken over pixels, ze hoeven alleen maar te implementeren. Dat scheelt niet alleen tijd, het maakt het werk voor die developers ook veel leuker. Ze kunnen zich focussen op waar ze goed in zijn: functionaliteit bouwen.
Eén bug oplossen, overal profijt
Er is nog een voordeel van dat centrale werken dat vaak vergeten wordt: onderhoud. Stel je voor dat er een foutje zit in die tabel waar we het eerder over hadden. In de oude situatie, met de eilandjes, moest elk van de vijf teams in hun eigen code gaangraven om dat op te lossen. Vijf keer zoeken, vijf keer repareren.
Met een centraal frontend-thema lossen wij het één keer op in de basis. Alle componenten worden namelijk centraal beheerd. We fixen de fout, zetten het live, en alle vijf de applicaties nemen de verbetering direct over. De verschillende teams hoeven hierzelf niet meer mee aan de slag. Of het nu gaat om een technische fout of een aanpassing in de huisstijl: je bent wendbaar over je hele organisatie heen.
Conclusie: durf te centraliseren
Het klinkt misschien tegenstrijdig. Je wilt autonome teams die snel kunnen bewegen. Maar juist door één onderdeel, de frontend en UX, centraal te regelen, geef je die teams de vrijheid om echt gas te geven.
Je stopt met het verspillen van talent aan dubbel werk. Je developers worden blijer omdat ze niet hoeven te designen. En je eindgebruikers krijgen een applicatie die niet alleen werkt, maar ook logisch en herkenbaar in elkaar zit.
Wil je eens sparren over hoe zo'n 'LEGO-doos' er voor jouw organisatie uit zou kunnen zien? Ik denk graag met je mee over de eerste stappen.
