Рост импорта компонентов маскирует падение реальной adoption дизайн-систем

Ein Balkendiagramm im Team-Board zeigt die Design-System-Adoption seit Monaten nach oben, während die Oberfläche uneinheitlicher wirkt als je zuvor. Der Entwickler Murphy Trueman nennt den Grund: Die üblichen Kennzahlen zählen Importe, nicht echte Wiederverwendung. drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen Das Wichtigste in Kürze - Adoptions-Dashboards zählen Importe und Coverage. Ein lokaler Wrapper um eine System-Komponente hebt beide Werte, obwohl die Wiederverwendung sinkt. - Der Trend ist branchenweit: Laut GitClear fiel der Anteil verschobenen Codes, das Signal für Refactoring, zwischen 2021 und 2024 von 24,8 auf 9,5 Prozent. - Aussagekräftiger sind die relative Adoption, die Zahl der Wrapper und die strukturelle Ähnlichkeit, etwa per jscpd. - Für DACH-Teams zählt die Wartungsschuld: Jeder stille Fork driftet vom barrierefreien Original ab. Korrekturen im System erreichen ihn dann nicht mehr. Warum steigt die Adoptionskurve, während die Nutzung fällt? Die gängigen Kennzahlen messen Importe, nicht Wiederverwendung. Ein Team, das die System-Komponente Card in einen eigenen ProductCard einpackt, erzeugt weiterhin einen Import und färbt die Adoptionskurve grün, obwohl das Team sich vom System entfernt. Genau diese unsichtbaren Kopien nennt Trueman Forks, die wie Akzeptanz aussehen.[1] Ein Wrapper beginnt als dünne Hülle und wächst still zu einer zweiten Schnittstelle mit eigenen Props und eigenem Verhalten. Auf dem Dashboard bleibt er ein Erfolg. Neuer Beschleuniger. KI-Assistenten senken den Preis für die eigene Variante unter den Aufwand, das vorhandene Bauteil zu suchen und sauber einzubinden. Eine Kopie entsteht in Sekunden, ihr Aufspüren im Review dauert länger. So verschiebt sich das Kräfteverhältnis zugunsten des Forks. Ist das ein Einzelfall oder ein Branchentrend? Der Design-System-Fork ist die lokale Form eines branchenweiten Musters. Kopierter Code verdrängt die Wiederverwendung, seit KI-Assistenten die Codebasis prägen. GitClear wertete 211 Millionen geänderte Codezeilen aus. Der Anteil verschobenen Codes, ein Maß für Refactoring, sank von 24,8 Prozent im Jahr 2021 auf 9,5 Prozent 2024.[2] Kopierter Code stieg im selben Zeitraum von 8,4 auf 12,3 Prozent und übertraf verschobenen Code erstmals. Duplizierte Blöcke nahmen 2024 um das Achtfache zu. Die Debatte trifft eine ältere Frage: Ist eine Sammlung von Bauteilen schon ein Design-System oder nur eine Komponenten-Bibliothek? Sichtbar wird die Verschiebung auch bei Systemen, die sich für KI-Agenten öffnen und bei agentennahen Baukästen wie dem Vue-System Balsa UI. Drei Kennzahlen statt reiner Importzahlen Wie messen Teams echte Adoption? Der Hebel ist die relative Adoption: der Anteil der System-Komponenten an allen verbauten Komponenten, nicht die Zahl der Importe. Werkzeuge wie Omlet, Supernova und Figmas Komponenten-Analyse berechnen dieses Verhältnis aus dem Produktionscode.[3] Murphy Trueman ergänzt drei Frühwarnzeichen: die Streuung der Props, die Zahl der Wrapper und die strukturelle Ähnlichkeit, die eine statische Analyse wie jscpd auch ohne Import findet. Ein automatischer Hinweis im Pull Request macht ähnliche Bauteile sichtbar, ohne den Merge zu blockieren. Für DACH-Teams wiegt die Wartungsschuld schwer. Ein still abgezweigter Fork driftet vom barrierefreien Original ab. Korrekturen am System erreichen ihn dann nicht mehr, während der Betreiber seit dem Barrierefreiheitsstärkungsgesetz vom 28. Juni 2025 für die zugängliche Oberfläche haftet. Ein Team, das die relative Adoption misst, die Wrapper zählt und ähnliche Bauteile früh anspricht, hält Konsistenz und Barrierefreiheit zusammen. FAQ: Design-System-Adoption messen Was bedeutet Adoption bei einem Design-System? Adoption meint den Anteil der zentralen System-Komponenten an allen tatsächlich verbauten Komponenten, also die relative Adoption. Die reine Zahl der Importe sagt darüber wenig aus, weil auch ein abgewandelter Wrapper als Import zählt. Warum überschätzen Import-Zahlen die Nutzung? Ein Team kann eine System-Komponente in einen eigenen Wrapper einpacken und sich schrittweise davon entfernen. Der Import bleibt bestehen und färbt die Kurve grün, obwohl praktisch eine zweite, eigene Komponente entsteht. Mit welchen Werkzeugen messen Teams die Adoption? Omlet, Supernova und Figmas Komponenten-Analyse berechnen die relative Adoption aus dem Produktionscode. Eine statische Analyse wie jscpd findet zusätzlich Bauteile, die dem System strukturell gleichen, es aber nicht importieren. Quellen [1] Murphy Trueman: „Every fork looks like adoption“ [2] GitClear: „AI Copilot Code Quality 2025 Research“ [3] Omlet: „How design system leaders define and measure adoption“