Design-System-Beiträge ohne das bestehende System zu beschädigen

Das Dienstags-Standup ist der Ort, an dem diese Dinge sterben. Sie haben drei Tage in Figma damit verbracht, eine sauber wirkende Datumsbereichs-Auswahlvariante zu bauen. Der DS-Lead wirft einen Blick auf den Link, lehnt sich zurück und sagt: "Das haben wir als Komponente schon." Und Sie rechnen nach. Entweder sind Ihre drei Tage für die Katz, oder die Version, die ausgeliefert wird, ist der Schnellschuss, den Sie gebaut haben, den niemand besitzt, und in acht Monaten baut ein neuer Designer ihn ein viertes Mal nach.

Beide Ergebnisse sind schlecht. Die gute Nachricht ist, dass die Lücke zwischen ihnen ein Prozessproblem ist, kein Talent-Problem. Ich habe ICs erlebt, die in zwei Wochen saubere Beiträge in ausgereifte Systeme eingebracht haben, und Senior-Leute, die sechs Monate damit verbracht haben, eine Button-Variante an einem Gatekeeper vorbeizuschieben. Der Unterschied lag selten in der Arbeit. Er lag fast immer im Beitragsmodell.

Das hier ist die funktionierende Version dieses Modells.

Warum das jetzt wichtig ist

Fragmentierte Systeme kosten mehr als langsame. Bei jedem Team, das damit kämpft, sehe ich zwei Versagensmuster, die gegensätzlich aussehen, aber dasselbe Ergebnis produzieren.

Das erste ist das abgeriegelte System. Das DS-Team besitzt alles. Beiträge brauchen drei Genehmigungen und einen vierteljährlichen Roadmap-Slot. ICs hören nach der zweiten Ablehnung auf zu versuchen. Die Bibliothek erstarrt. Neue Muster werden außerhalb aufgebaut, weil es schneller geht, und jetzt haben Sie ein design system, das eigentlich ein Museum ist.

Das zweite ist das offene Chaos. Jeder kann alles veröffentlichen. Nach sechs Monaten hat jedes Produktteam seine eigene Dropdown-Komponente, drei "primäre" Buttons in leicht unterschiedlichen Blautönen und eine Figma-Seite namens "TEMP - NICHT VERWENDEN", die jeder verwendet. Willkommen bei Ihrer Fragmentierungssteuer.

Ein typisches Produktteam, das ich prüfe, hat nach zwei Jahren 3 bis 7 Versionen "desselben" Buttons. Nicht weil das jemand so wollte. Weil der Beitragsfluss entweder zu eng oder zu locker war, und der Weg des geringsten Widerstands darin bestand, lokal zu bauen und es nie zurückzuführen.

Das folgende Modell ist der mittlere Weg. Es setzt voraus, dass Beitragen eine handwerkliche Fähigkeit ist, keine politische, und der IC, der saubere DS-Arbeit liefert, mehrt seinen Einfluss schneller als der, der eine private Komponentenbibliothek aufbaut.

Wann man das DS nutzt und wann man eine neue Komponente baut

Die meisten "wir brauchen eine neue Komponente"-Gespräche enden in dem Moment, in dem jemand den 80/20-Test durchführt. Es sind zwei Fragen:

1. Kann ich 80 % davon mit einer bestehenden Komponente plus Props oder einer Variante lösen?
2. Wenn ich das hinzufüge, werden es mindestens 20 % der Teams innerhalb von sechs Monaten nutzen?

Wenn die Antwort auf Frage 1 ja ist, brauchen Sie keine neue Komponente. Sie brauchen eine Variante oder eine Prop, was ein kleinerer, schnellerer, günstigerer Beitrag ist. Wenn die Antwort auf Frage 1 nein ist, aber auch auf Frage 2, ist das ein Einzel-Fall. Behalten Sie ihn lokal, vergiften Sie die Bibliothek nicht.

Eine neue Komponente rechtfertigt sich nur, wenn beide Antworten richtig ausfallen: das vorhandene Kit kann den Fall nicht abdecken, und mehr als ein Team wird sie wiederverwenden.

Die Falle, die ich am häufigsten sehe, nenne ich die Fast-passt-Falle. Ein Designer findet eine Komponente, die zu 70 % passt. Er trennt sie ab, tweakt den Padding, tauscht einen Token und liefert sie als "auf Basis von" der bestehenden. Sechs Monate später ist sie auf sieben unsichtbare Arten auseinandergedriftet und der design-system-Eigentümer hat keinerlei Aufzeichnung, dass etwas davon passiert ist. "Fast passt" ist schlimmer als "von Grund auf neu", weil es so tut, als sei es Wiederverwendung.

Ein einfacherer Entscheidungsbaum in der Reihenfolge:

• Bestehende Komponente, keine Änderungen: nutzen.
• Bestehende Komponente, neue Prop oder neuer Zustand: eine Variante der bestehenden vorschlagen.
• Bestehende Komponente, aber das zugrundeliegende Verhalten ist falsch: ein Refactoring vorschlagen, keinen Fork.
• Wirklich neues Muster, mehrere Teams brauchen es: eine neue Komponente vorschlagen.
• Wirklich neues Muster, nur Ihr Team braucht es: lokal bauen, als lokal markieren, in 90 Tagen überprüfen.

Der letzte Punkt ist in Ordnung. Lokale Komponenten sind keine Sünde. Eine lokale Komponente als Systemkomponente auszugeben, ist es.

Der Beitragsfluss: RFC, Review, Ship, Document

Wenn Sie entschieden haben, dass es sich lohnt hinzuzufügen, verläuft der Fluss in vier Phasen, jede mit einem Zeitrahmen. Das Ganze sollte für einen normalen Beitrag unter zwei Wochen dauern. Wenn es länger dauert, stimmt etwas mit dem Prozess nicht, nicht mit der Komponente.

Phase 1, RFC (1 bis 2 Tage). Eine Seite. Problem, vorgeschlagene Lösung, berücksichtigte Alternativen, Barrierefreiheits-Hinweise und eine Skizze. Nicht sechs Mockups. Der Fehler, den ich jahrelang gemacht habe, war, zu viel in die Detailgenauigkeit zu investieren, bevor das Gespräch stattgefunden hatte. Eine einzelne Skizze erlaubt dem DS-Eigentümer, die Richtung zu hinterfragen, ohne dass Sie das Gefühl haben, drei Tage Pixel-Arbeit verteidigen zu müssen.

Der RFC ist auch der Ort, an dem Sie Abhängigkeiten kennzeichnen: neue Tokens, neue Icons, Verhalten, das bestehende Komponenten berührt. Wenn Sie feststellen, dass Sie einen neuen Farb-Token brauchen, damit das funktioniert, ist das jetzt Teil des RFC, keine Überraschung an Tag acht.

Phase 2, Review mit dem DS-Eigentümer (1 bis 3 Tage). Async zuerst, synchron wenn es feststeckt. Der Review ist kein Genehmigungstheater. Er ist eine Co-Design-Session. Der DS-Eigentümer ist nicht Ihr Blocker. Er ist die Person, die das, was Sie liefern, letztendlich warten wird, also ist sein Input zu Benennung, Props und Randfällen strukturell, nicht stilistisch.

Gehen Sie mit dem RFC hinein, stellen Sie drei Fragen: Gehört das in das System, entspricht die vorgeschlagene Form den bestehenden Mustern, und was fehlt mir auf der Engineering-Seite. Gehen Sie mit einem Ja/Nein/Überarbeitungsbedarf und einem einzelnen Eigentümer von der DS-Seite heraus, der den finalen PR reviewt.

Phase 3, Hinter einem Flag liefern (3 bis 5 Tage). In Figma bauen, in Storybook bauen, die React/Vue/whatever-Komponente hinter einem Feature-Flag oder einem beta-Kanal in der veröffentlichten Bibliothek liefern. Hinter einem Flag zu liefern, ist wichtig, weil es Ihnen und ein oder zwei Early Adoptern ermöglicht, die API unter Druck zu testen, bevor sie im Produktions-Kit ist. Die meisten API-Fehler zeigen sich bei der ersten echten Verwendung, nicht im RFC.

Phase 4, Dokumentieren und promoten (1 Tag). Story veröffentlicht, Nutzungsdokumentation geschrieben, Deprecation-Hinweise falls es etwas ersetzt, Ankündigung im DS-Kanal mit einem Abschnitt "wann Sie danach greifen sollten". Dann vom Beta- zum GA-Status in der nächsten Bibliotheksversion promoten.

Wenn eine einzelne Phase ihren Zeitrahmen überschreitet, ist das ein Signal. Phase 1 überschreitet: das Problem ist nicht klar. Phase 2 überschreitet: der DS-Eigentümer hat strukturelle Bedenken und braucht ein echtes Gespräch, keine weitere Überarbeitung. Phase 3 überschreitet: die API ist falsch und Sie flicken daran herum. Phase 4 überschreitet nicht. Wenn Sie sie überspringen, überspringen Sie den Teil, der alles real macht.

Namenskonventionen, die überleben

Benennung ist die langweilige Hälfte des Beitrags und der Ort, an dem die meisten Beiträge still scheitern. Eine Komponente namens BigBlueBtn wird von genau einem Team, ironisch, verwendet und dann nie wieder. Eine Komponente namens Button/Primary/Large wird übernommen, weil der Name sagt, was sie ist, wo sie sitzt und wie sie sich zum Rest verhält.

Die Namenshierarchie, die sich bewährt, ist Token, Komponente, Variante, Zustand:

• Token: color/primary/600
• Komponente: Button
• Variante: Primary, Secondary, Ghost
• Größe: Small, Medium, Large
• Zustand: Default, Hover, Disabled, Loading

Von oben nach unten gelesen: Button/Primary/Large/Hover ist eindeutig, sortierbar und entspricht der Darstellung im Figma-Komponentenfenster und in der Storybook-Navigation.

Drei Regeln, die ich verinnerlicht haben würde:

1. Keine Eigennamen. Kein BobsButton, kein Q3Modal, kein MarketingHero. Der Name beschreibt das Ding, nicht den Anforderer.
2. Keine Abkürzungen unter 5 Zeichen. Btn spart nichts und kostet Durchsuchbarkeit. Notif ist schlechter als Notification.
3. Keine Größenadjektive, die nicht auf der Skala stehen. "Groß" ist keine Größe. Large ist es. Wenn Ihre Skala S/M/L ist, führen Sie kein XLG ein, ohne es zuerst systemweit zur Skala hinzuzufügen.

Wenn Namen kollidieren (und das werden sie, besonders in größeren Systemen), gilt die Regel: der allgemeinere Name gehört zum allgemeineren Anwendungsfall. Wenn Marketing Card für eine gestaltete Hero-Card will und das System bereits Card für den generischen Inhaltsbehälter hat, wird Marketings Komponente zu Card/Hero oder HeroCard. Der Basisname bleibt beim Basisverhalten.

Barrierefreiheits-Mindeststandards: WCAG AA als Untergrenze

Komponenten werden mit dem Barrierefreiheits-Test geliefert oder gar nicht. Das ist kein Wunschdenken. WCAG AA ist die Untergrenze, nicht die Obergrenze, und sie ist die Untergrenze, weil Sie darunter Komponenten liefern, die Nutzer rechtlich und ethisch ausschließen.

Die Mindeststandards, die jede Komponente vor dem Merge erfüllen muss:

Für jede dieser Prüfungen gibt es heute automatisierte Werkzeuge. axe-core in CI fängt die strukturellen. Das Storybook-a11y-Addon fängt offensichtliche Kontrast- und ARIA-Fehler. Was es nicht fängt (und was ein IC tatsächlich tun muss) ist der Tastaturfallentest: durch jeden Zustand tabben, einschließlich Modal-geöffnet, Dropdown-expandiert, Fehlerzustand. Tastaturfallen sind das Versagensmuster, das ich am häufigsten sehe, und sie sind am einfachsten zu testen.

Wenn Sie nicht sicher sind, ob Ihre Komponente besteht, führen Sie sie vor dem Review durch den Test. Ein DS-Eigentümer, der in Phase 2 einen Kontrastfehler kennzeichnen muss, hat gerade herausgefunden, dass Sie die Arbeit nicht gemacht haben. Ein Beitrag, der sauber in Bezug auf Barrierefreiheit ankommt, ist ein Beitrag, der schnell genehmigt wird.

Figma-Bibliotheks-Hygiene

Figma ist der Ort, an dem Beiträge still verfaulen, wenn Sie nicht aufpassen. Zwei Dinge sind entscheidend:

Veröffentlicht gegenüber lokal. Veröffentlichte Komponenten leben in der Team-Bibliothek und werden an jede Datei weitergegeben, die sie nutzt. Lokale Komponenten leben in der Datei, in der Sie arbeiten, und werden nirgendwo weitergegeben. Der Fehler ist, eine lokale Komponente für Prototyping-Arbeit zu verwenden und dann zu vergessen, sie entweder zu löschen oder zu promoten. Sechs Monate später wird die Datei geöffnet und jemand kopiert die lokale, weil sie die richtige Form hat.

Regel: Eine lokale Komponente wird entweder innerhalb von zwei Wochen in die veröffentlichte Bibliothek promoted oder gelöscht. Es gibt keinen dritten Zustand.

Getrennte Instanzen sind ein Warnsignal. Wenn ein Designer eine Instanz trennt, sagt er: "Ich brauchte diese Komponente, aber leicht anders, und ich wollte mich nicht mit dem System auseinandersetzen." Das ist ein Signal. Manchmal ist die richtige Antwort, eine Variante hinzuzufügen. Manchmal ist es, die zugrundeliegende Komponente zu reparieren. Manchmal hatte der Designer es einfach eilig. Aber jede getrennte Instanz ist ein Datum, und der monatliche Sweep sollte sie verfolgen.

Der Sweep selbst ist mechanisch: einmal im Monat das Figma-Instanz-Audit ausführen (oder ein Plugin wie Instance Finder), getrennte Instanzen auflisten und sie mit dem verantwortlichen Designer durchgehen. Entweder erneut verbinden, eine Variante vorschlagen oder löschen. Dreißig Minuten Arbeit, die drei Monate Fragmentierung verhindert.

Code-Design-Parität (Storybook)

Jede Figma-Komponente hat eine Storybook-Story, oder sie ist nicht real. Das ist die Regel, die ich an die Wand hängen würde.

Storybook ist der einzige Ort, an dem Design und Code als dasselbe Artefakt koexistieren. Figma zeigt Ihnen, wie die Komponente aussehen soll. Storybook zeigt Ihnen, was sie tatsächlich ist. Wenn sie auseinanderdriften (und das tun sie immer), ist Storybook die Source of Truth, weil es das ist, was der Nutzer sieht.

Eine echte Storybook-Story für eine beigetragene Komponente enthält:

• Alle Varianten gerendert (Primary, Secondary, Ghost usw.)
• Alle Zustände gerendert (Default, Hover, Focus, Disabled, Loading, Error)
• Ein Controls-Panel, das einem Reviewer ermöglicht, Props live umzuschalten
• Eine Play-Funktion, die die Tastaturinteraktion ausübt
• Einen a11y-Addon-Bericht ohne Verstöße
• Visuelle Regression-Baselines committed (Chromatic, Percy oder hausgemacht)

Visuelle Regression in CI fängt den Drift, bevor die PM es tut. Wenn jemand die Button-Komponente aktualisiert und ein Padding-Token sich über vierzig Stories um zwei Pixel ändert, erscheint der Diff im PR. Der DS-Eigentümer genehmigt oder lehnt ab. Keine überraschenden Fehler in der Produktion.

Ohne das erfahren Sie von dem Drift, wenn ein Kunde ein falsch ausgerichtetes Formular auf Twitter screenshottiert.

Deprecation-Rhythmus

Was Sie liefern, wird irgendwann nicht mehr die richtige Antwort sein. Eine Deprecation-Disziplin ist der Weg, das Museum-System-Problem zu vermeiden.

Der Rhythmus, den ich empfehlen würde:

• Vierteljährlicher Review. Jedes Quartal gehen das DS-Team und 2 bis 3 IC-Designer die Bibliothek durch und kennzeichnen Komponenten, die: wenig genutzt werden (unter 5 Instanzen in der gesamten Codebasis), durch eine neuere Variante ersetzt wurden oder Barrierefreiheits- oder Visuell-Standards nicht mehr entsprechen.
• Zwei-Release-Deprecation-Fenster. Sobald eine Komponente gekennzeichnet ist, markieren Sie sie in Storybook als @deprecated, fügen Sie ein Deprecation-Banner in Figma hinzu und liefern Sie einen Ersatz (oder einen Migrationspfad). Geben Sie ihr zwei Release-Zyklen (in der Regel zwei Monate), bevor sie entfernt wird.
• Den Codemod bereitstellen. Das ist der Teil, den Teams überspringen. Wenn Sie eine an 200 Stellen verwendete Komponente deprecaten, ist "bitte migrieren" kein Plan. Liefern Sie den Codemod (ein kleines Skript, das <OldButton> automatisch in <Button variant="primary"> umschreibt), damit die Migration Minuten statt Wochen dauert. Ohne den Codemod wird die Deprecation ignoriert und die alte Komponente lebt ewig.

Häufige Fallen

Die vier Wege, auf denen Beiträge schiefgehen, in ungefährer Häufigkeit:

1. Im Verborgenen gestalten, dann das fertige Ergebnis pitchen. Sie haben drei Tage in Figma verbracht. Der DS-Eigentümer hat dreißig Sekunden Kontext und jetzt wollen Sie, dass er sechs Mockups absegnet. Das wird nicht passieren. Bringen Sie Skizzen früh, fertige Arbeit spät.
2. Die nächste bestehende Komponente kopieren und "nur leicht anpassen". Die Fast-passt-Falle. Entweder zu einer echten Variante verpflichten oder etwas Neues bauen. Niemals einen getweakten Trenner als Systemkomponente liefern.
3. Die Storybook-Story überspringen, weil "der Dev es schon machen wird". Das werden sie nicht, oder sie machen es schlecht, weil sie die Design-Absicht nicht kennen. Die Story ist Ihre Spec, genauso wie die Figma-Komponente. Wenn Sie sie nicht schreiben, wird die Interpretation des Devs zur Wahrheit.
4. Den DS-Eigentümer als Blocker statt als Co-Autor behandeln. Das ist der größte Denkfehler. Der DS-Eigentümer hat mehr Kontext als Sie darüber, was kommt, was deprecated wird, was Teams bald brauchen werden. Beziehen Sie ihn früh ein und er beschleunigt Ihren Beitrag. Verstecken Sie sich vor ihm und er verlangsamt ihn, weil er Ihr Denken rückwärts erschließen muss.

Vorlagen und Tools

Drei Artefakte, die ich griffbereit halten würde:

Einseitige RFC-Vorlage. Problem (maximal 3 Sätze), vorgeschlagene Lösung (1 Skizze und 3 Aufzählungspunkte), berücksichtigte Alternativen (2 bis 3 mit Begründung), Barrierefreiheits-Hinweise, Abhängigkeiten, wer betroffen ist. Wenn es nicht auf eine Seite passt, ist der Beitrag nicht eng genug eingegrenzt.

Komponenten-Checkliste. Verwendete Tokens, definierte Varianten, alle Zustände gestaltet, Barrierefreiheits-Test bestanden, Storybook-Story veröffentlicht mit Controls und Play-Funktion, Nutzungsdokumentation geschrieben, visuelle Regression-Baseline committed, Deprecation-Hinweis falls etwas ersetzt wird. Kleben Sie sie neben Ihren Monitor.

Deprecation-Hinweis-Vorlage. Was deprecated wird, was es ersetzt, Link zum Migrationsleitfaden, Codemod-Befehl, Entfernungsdatum. Im DS-Kanal gepostet, der Storybook-Seite hinzugefügt, Banner in der Figma-Komponente.

Erfolgsmessung

Sie werden wissen, dass das Modell funktioniert, wenn:

• Ihr Beitrag innerhalb von zwei Wochen nach dem RFC in der veröffentlichten Bibliothek landet. Länger als das und irgendetwas im Fluss ist kaputt.
• Null getrennte Instanzen Ihrer Komponente nach dreißig Tagen. Wenn sie auftauchen, deckt die API die Anwendungsfälle nicht ab.
• Die Storybook-Story existiert, hat Play-Funktionen und hat null Barrierefreiheits-Verstöße.
• Ein anderes Team übernimmt die Komponente, ohne Sie zu fragen. Das ist das echte Signal: Wenn Wiederverwendung organisch geschieht, haben Sie wirklich zum System beigetragen, nicht nur etwas hinzugefügt.

Der IC, der saubere DS-Arbeit liefert, mehrt seinen Einfluss schneller als der, der private Komponentenbibliotheken aufbaut, weil jeder saubere Beitrag den nächsten schneller macht, für Sie und für alle anderen.

Weiterführende Inhalte

• Product Designer Job Description
• Design Critique, das die Arbeit tatsächlich verbessert
• Handoff an Engineering ohne die Pixel-Nachbesserungs-Schleife
• Barrierefreiheit jenseits der Checkliste