Gebruik en adoptie zijn niet hetzelfde
Gebruik is een aantal: hoeveel keer een component wordt aangeroepen. Adoptie is een verhouding: welk deel van alles wat het systeem had kunnen dekken, ook echt uit het systeem komt. Die twee lopen uiteen. Een codebase die verdubbelt terwijl het gebruik gelijk blijft, ziet er op gebruik stabiel uit en zakt in adoptie.
Toch is gebruik over tijd bruikbaar, en vaak makkelijker te krijgen. Een stijgende gebruikslijn bij een gelijkblijvende organisatie is een adoptietrend, ook zonder dat je de noemer scherp hebt. Begin daar als een zuivere verhouding nog te duur is, maar wees expliciet over wat je meet.
Vier manieren om het te meten. Ze zien alle vier iets anders, en geen ervan ziet alles.
Statische codescan
Tel in de broncode DS-componenten tegen handgemaakte equivalenten die het systeem had kunnen dekken. Geeft een verhouding en wijst aan wáár het misgaat. Ziet niet of die code ook daadwerkelijk draait.
Installaties van het package
Hoeveel projecten trekken het systeem binnen, en welke versie. Goedkoop en direct beschikbaar. Zegt niets over hoeveel er vervolgens mee gebouwd wordt: een repo kan het installeren en er twee componenten uit gebruiken.
Runtime-telemetrie
Meet wat er in productie daadwerkelijk rendert. Het dichtst bij de werkelijkheid en het enige dat dode code uitsluit. Vraagt instrumentatie in het systeem zelf en levert privacyvragen op waar je vooraf antwoord op wilt hebben.
De ontwerpkant
Gebruik van de bibliotheek in het ontwerpgereedschap. Loopt vooruit op de code en laat zien of ontwerpers het systeem als startpunt nemen. Sluit slecht aan op wat er uiteindelijk gebouwd wordt, dus gebruik het naast een codemeting en niet ervoor.
Wat telt als adoptie
Een component importeren en gebruiken zoals bedoeld is adoptie. Daaronder liggen drie niveaus die er in een naïeve telling net zo uitzien: importeren en daarna lokaal overschrijven met eigen styling, het component kopiëren in de eigen codebase, en zelf een equivalent bouwen. Wie die drie meetelt, meet vertrouwen dat er niet is.
Dat onderscheid is niet academisch. Een overschreven component betekent dat het systeem bijna paste, en dat is precies het signaal waar je op wilt sturen. Een fork betekent dat een team het systeem niet vertrouwt maar de code wel wil. Alleen als je die apart telt, weet je welk probleem je aan het oplossen bent.
Telt als adoptie
Telt niet, maar is wel signaal
Bij meerdere repositories
Meet per repository en rapporteer per repository. Zodra je de percentages middelt, weegt een klein zijproject even zwaar als je hoofdapplicatie en verdwijnt precies de informatie waar je op stuurt. Eén cijfer voor de hele organisatie voelt netjes en is stuurloos.
Zoek je toch een totaalbeeld, weeg dan op iets dat betekenis heeft: aantal gebruikers, verkeer of het aantal teams dat eraan werkt. En houd naast de verhouding per repo de absolute gebruikslijn bij, want die laat de beweging zien op het moment dat je noemer verschuift doordat er een repo bijkomt.
| Gebruik | Adoptie | |
|---|---|---|
| Wat het is | Een aantal | Een verhouding |
| Vraag | Hoe vaak wordt het gebruikt? | Welk deel van wat kon, gebeurt ook? |
| Kosten om te meten | Laag | Hoger, je moet de noemer bepalen |
| Valkuil | Groeit mee met de codebase | Verschuift als er een repo bijkomt |
| Waarvoor | Trend zien zonder scherpe noemer | Sturen en verantwoorden |
Wat er gebeurde toen we onze eigen meter aanpasten
Simplor meet het eigen design system met een statische codescan. Op 19 juli 2026 rapporteerde die 8% adoptie: 45 DS-gebruiken tegen 514 openstaande kansen. Dat cijfer klopte rekenkundig en het was waardeloos, want het gooide twee dingen op één hoop.
Een dag later stond de meting in twee ratio’s die niet meer worden gemiddeld. Componentadoptie 50%, style-adoptie 99%: 5310 token-gebruiken tegen 31 hardcoded waarden. Dezelfde codebase, dezelfde dag, geen regel code veranderd. Wat wél veranderde was de vraag. Componenten en tokens bewegen onafhankelijk, want een pagina kan nul DS-componenten gebruiken en volledig getokeniseerd zijn. Als je ze middelt, meet je geen van beide, en stuur je op een getal dat nergens naar verwijst.
Waar je begint
Kies één methode en één noemer, schrijf op wat je wel en niet meetelt, en leg de nulmeting vast voordat je gaat verbeteren. De methode mag grof zijn; de definitie moet scherp zijn, anders vergelijk je over drie maanden twee verschillende dingen met elkaar.
Meet daarna op een vast ritme en bewaar de reeks. Eén meting is een momentopname en verandert niets, een reeks laat zien of een ingreep heeft geholpen en is het enige waarmee je budget voor het systeem kunt verdedigen. Waarom systemen zonder die sturing vastlopen, staat in waarom design systems stranden na de lancering.