Dein Design System ist eingeführt. Benutzt wird es trotzdem nicht.

Design Systems werden üblicherweise über Adoption gemessen: wie viele Komponenten es gibt, wie viele importiert werden, wie viel Prozent der App auf dem System läuft. Jede dieser Zahlen steigt mit der Zeit, und keine sagt etwas aus.

Ich habe eine andere Messung gegen eine meiner eigenen Anwendungen laufen lassen — 389 Dateien, 104 Routen, 10.688 Aufrufstellen über 39 Komponenten. Entscheidend war am Ende nicht, welche Komponenten benutzt werden. Entscheidend war, auf wie viele verschiedene Arten eine einzelne Komponente aufgerufen wird.

Streuung

Nimm jede Aufrufstelle einer Komponente, reduziere sie auf ihre Prop-Signatur, zähle die verschiedenen und teile durch die Gesamtzahl. Zwei Beispiele aus diesem Lauf:

• input: 411 Aufrufstellen, 357 verschiedene Signaturen. 87 %.
• card: 3.162 Aufrufstellen, 240 Signaturen. 8 %.

Beide Komponenten liegen im selben System, in derselben App, gepflegt von derselben Person. Die eine wird als System benutzt: wenige Arten, die Sache zu tun, immer wieder. Die andere wird an fast jeder Aufrufstelle neu erfunden — die Komponente ist dort ein Behälter für Entscheidungen statt einer Entscheidung, die einmal getroffen wurde.

Hohe Streuung ist nicht automatisch schlecht. Manche Komponenten nehmen tatsächlich eine breite Spanne an Eingaben. Aber es ist die Zahl, die zeigt, wo ein System aufgehört hat zu entscheiden und angefangen hat zu vertagen, und keine Adoption-Prozentzahl bringt das je ans Licht.

Der Befund, nach dem ich nicht gesucht hatte

Button-Varianten nach Aufrufstellen:

• outline — 512
• ghost — 239
• default — 5

Die primäre Aktion ist praktisch nie vergeben. In einer ganzen Anwendung treffen fünf Bildschirme eine Aussage darüber, was der Nutzer als Nächstes tun sollte, und alles andere steht gleichgewichtig nebeneinander.

Das ist kein Komponentenproblem. Nichts ist kaputt, kein Lint schlägt an, jeder dieser Buttons ist eine zulässige Benutzung des Systems. Es ist ein Produktproblem, das nur sichtbar wurde, weil die Varianten gezählt statt reviewt wurden. Ich benutze diese App seit Monaten und habe es nie bemerkt — auf einem einzelnen Bildschirm sieht eine Reihe Outline-Buttons nach Absicht aus.

Der Rest des Durchlaufs war gewöhnlicher und trotzdem nützlich: 26 Icon-Buttons ohne zugänglichen Namen, 388 Aufrufstellen mit Rohfarben, 94 mit Arbitrary Utilities. Das sind die, die ein Linter hätte fangen können, wenn ich den Lint geschrieben hätte, was überhaupt das Argument für maschinenlesbare Regeln ist.

Die Dimension, die vollständig fehlte

Die erste Fassung dieses Profils zählte nur Komponenten aus meinem eigenen System. Sie sah vollständig aus. Sie vermaß eine App, deren Gestalt ich vorher schon festgelegt hatte.

Fremdbibliotheken in den Scan aufzunehmen ergab 54 davon, 45 ohne jede Entsprechung im System. Eine leistet echte Arbeit: Jede Kennzahl auf jedem Dashboard animiert über NumberFlow, und ein Profil, das nur meine eigenen Primitives zählte, konnte das nicht sehen. Für diese Fassung bestanden die Bildschirme aus Karten und Text.

Das Profil war also nicht bloß unvollständig, es war zuversichtlich unvollständig — derselbe Fehler, in den ich auch anderswo laufe. Was gemessen wird, ist entschieden, bevor irgendetwas gemessen wurde, und ein Instrument kann nicht über das berichten, worauf es nicht gerichtet war.

Was das ist und was nicht

Deutlich zur Größe der Aussage, weil die Zahlen konkret genug sind, um nach mehr auszusehen, als sie sind:

• Eine Codebase. Alles oben ist die Selbstdiagnose einer Anwendung, die ich selbst gebaut habe. Über die Verhältnisse bei anderen sagt es nichts, und einen Benchmark würde ich daraus nicht veröffentlichen.
• Ich bin Messender und Gemessener zugleich. System, App und Analyse sind alle meine — genau die Lage, in der man einem schmeichelhaften Ergebnis misstrauen sollte. Der Button-Befund besteht diesen Test vor allem deshalb, weil er unschmeichelhaft ist.
• Übertragbar ist die Methode. Verschiedene Signaturen geteilt durch Aufrufstellen sind vier Zeilen Auswertung auf einem TypeScript-AST-Durchlauf. Die Verhältnisse sind meine; die Zahl kann jeder haben.

Eine Anmerkung zur Umsetzung, weil ich es zuerst falsch hatte: Die Analyse lief ursprünglich über reguläre Ausdrücke und meldete 132 nie importierte Komponenten. Nach dem Beheben eines greedy Match und fehlender Sibling-Imports waren es 56. Mehr als die Hälfte eines Befunds war mein eigener Parser. Heute läuft sie über den TypeScript-Compiler — langsamer, erfindet dafür nichts.

Next

Eine zweite Codebase, am liebsten eine, die ich nicht geschrieben habe. Die interessante Frage ist, ob Streuung Systeme von Bibliotheken allgemein trennt oder nur beschreibt, wie ich baue. Bis dahin ist das eine Methode mit einem Beispiel daran.

Außerdem soll das Profil in CI laufen und bei steigender Streuung fehlschlagen, so wie ein Bundle-Budget bei steigender Größe fehlschlägt. Dafür braucht es eine Baseline, und eine Baseline braucht mehr als eine Messung.

Falls du ein Design System pflegst: Weißt du, auf wie viele verschiedene Arten deine meistgenutzte Komponente aufgerufen wird? Ich vermute, die meisten Teams haben die Adoption-Zahl und diese nicht, und ich würde mich freuen, damit falsch zu liegen.