B2B: Syndigo Design-System – Vereinheitlichte Komponentenbibliothek und Design-to-Code-Pipeline
Über das Projekt
Projektübersicht
- Rolle: Senior Manager, UX Design bei Syndigo — Nov. 2023 bis heute (über 10 Jahre UX-Erfahrung)
- Lösung: Ein einziges, konsolidiertes, code-verbundenes Design-System, das die gesamte Produktpalette von Syndigo abdeckt …. es ersetzt fragmentierte, duplizierte Komponentenbibliotheken durch eine einzige, gesteuerte Single Source of Truth, die direkt mit Storybook, GitHub und den KI-Prototyping-Tools des Unternehmens verdrahtet ist.
- Ziel: Designern, Frontend-Entwicklern und Product Managern ein konsistentes System an die Hand geben, auf dem sie aufbauen können – Drift eliminieren, die Lücke zwischen Design und Code schließen und die gesamte Organisation schneller machen, ohne Konsistenz oder Barrierefreiheit zu opfern. Ich kam zu Syndigo … einer B2B-Produktdatenplattform, die MDM-, PXM- und Syndication-Produkte umfasst … als Senior Manager of UX Design. Meine Verantwortung war dreifach:
Das End-to-End-Produktdesign über die Kernprodukte hinweg leiten, einschließlich der Nutrition-Analysis-Plattform und des Syndication Tracker , während ich den Designer beaufsichtigte, der mit mir daran arbeitete.
Die Verantwortung für ein fragmentiertes, ungesteuertes Design-System übernehmen und es zu einer einzigen, konsistenten, code-verbundenen Single Source of Truth umbauen.
Ein Team von über 8 Produktdesignern führen und aufbauen, während ich an den VP of Design berichtete und mit dem Director of Design und dem Frontend-Engineering zusammenarbeitete.
Design-Prozess
Ich ging den Umbau in klaren Phasen an, jede fundiert im Audit.
- Audit: Ich inventarisierte jede Komponente über die Produkte hinweg, glich Figma mit der Produktion ab und markierte jedes Duplikat und jede Inkonsistenz.
- Konsolidierung: Ich reduzierte jeden Satz von Duplikaten auf eine einzige kanonische Komponente, dokumentierte jede mit ihrer Anatomie, ihren Varianten und ihrem Versionsverlauf und führte einen klaren Workflow ein — Ideenfindung, in Arbeit, abgeschlossen — mit an Design-Frames angehängten Tickets.
- Code Connect & Storybook: Für alle über 70 Komponenten schrieb ich die Code-Connect- und Komponenten-Code-Dateien und richtete Storybook so ein, dass Design und die live programmierte Form nebeneinander angezeigt werden.
- GitHub-Integration: Da es keinen UX-Vertreter im Repository gab, gewährte mir das Engineering Zugriff, und ich committete die Komponenten- und Code-Connect-Dateien direkt in GitHub und schloss so den Design-to-Code-Kreislauf.
- KI-gestütztes Prototyping: Ich war der Erste im Unternehmen, der Figma MCP nutzte, um Designs in programmierte, klickbare Prototypen für Tests vor der Entwicklung zu verwandeln, und beschränkte dann Lovable und Claude Design auf die Komponenten des Systems, sodass Teams nur systemkonforme Arbeit generieren konnten.
- Barrierefreiheit: Ich baute und verifizierte jede Komponente, damit sie die WCAG-AAA-Standards erfüllt.
Barrierefreiheit
Das System wurde so gebaut, dass es die WCAG-AAA-Standards erfüllt. Die Komponenten wurden für Screenreader gestaltet — mit semantischer Struktur, ARIA-Rollen und klaren Labels — und direkt mit Screenreader-Software getestet. Farbe wurde für mehrere Formen der Farbenblindheit berücksichtigt, sodass keine Information jemals allein auf Farbe angewiesen war. Die Konformität wurde mit automatisierten Barrierefreiheits-Tools geprüft und in schriftlichen Richtlinien festgehalten, damit jedes Team barrierefrei bauen und zum System beitragen konnte.
Impact-Kennzahlen
Über 70 Komponenten in eine einzige, code-verbundene Single Source of Truth konsolidiert.
Syndigos erste Design-to-Engineering-Pipeline, die Designs mit programmierten Prototypen vor dem Build validiert.
Unternehmensweites systemkonformes Prototyping in Produkt- und Design-Teams über Lovable und Claude Design eingeführt.
Reduzierte Durchlaufzeit von Design zu Entwicklung durch konsistente, code-verbundene Komponenten.
Kontext & Problemstellung
Das Design-System hatte keine Struktur und kaum Steuerung. Dieselbe Komponente existierte oft in mehreren inkonsistenten Versionen über Produkte hinweg, und nichts verband das Design mit dem ausgelieferten Code: kein Storybook, keine code-verbundenen Komponenten und keine UX-Präsenz in GitHub.
Das Ergebnis war Drift. Designer, Entwickler und Product Manager interpretierten das System jeweils unterschiedlich, was die Auslieferung verlangsamte und Entwickler zwang, die UI aus inkonsistenten Spezifikationen neu aufzubauen.
Stakeholder-Analyse
- Frontend-Entwickler: Benötigten Komponenten, die der Design-Intention entsprachen und direkt in die Produktion übernommen werden konnten, statt aus inkonsistenten Spezifikationen neu zu bauen.
- Produktdesigner: Mein Team brauchte ein gesteuertes Komponenten-Kit, damit sie sich auf das Lösen von Problemen konzentrieren konnten, statt UI neu zu erstellen.
- Product Manager: Mussten Ideen schnell prototypisieren und testen können, ohne vom echten Produkt abzuweichen.
System-Audit
Bevor ich irgendetwas änderte, prüfte ich, wie das System tatsächlich genutzt wurde, damit der Umbau auf Evidenz beruhte.
- Komponenten-Inventar: Jede genutzte Komponente katalogisiert und die Duplikate identifiziert.
- Figma-zu-Produktion-Mapping: Design-Bibliotheken mit ausgelieferter UI verglichen, um Drift zu lokalisieren.
- Team-Interviews: Mit Designern und Entwicklern darüber gesprochen, wo das System half und wo sie es umgingen.
- UI-Relay-Plugin: Ein eigenes Figma-Plugin gebaut, um das System zu betreiben — Komponenten auf Code abbilden, Abdeckung und Code-Zustand verfolgen, Komponenten-Code generieren und synchronisieren, Tokens und Templates verwalten und Lücken zum Beheben markieren — und so Steuerung und Design-to-Code aus einer einmaligen Bereinigung in einen kontinuierlichen Workflow verwandeln.
Herausforderungen und Lösungen
Die zentrale Herausforderung war die fehlende Verbindung zwischen Design und Code. Ohne UX-Präsenz im Repository sicherte ich mir GitHub-Zugriff und übernahm die Verantwortung für die Code-Connect- und Komponenten-Dateien selbst, sodass Designentscheidungen die Produktion originalgetreu erreichten, statt neu interpretiert zu werden.
Fragmentierung war die zweite. Statt Konsistenz von Hand zu überwachen, konsolidierte ich Duplikate zu kanonischen Komponenten und baute das UI-Relay-Plugin, um zu verhindern, dass das System zurückdriftet.
Adoption war die dritte. Indem ich das System in die Tools verdrahtete, die die Teams ohnehin wollten — programmierte Prototypen, Lovable und Claude Design — machte ich das systemkonforme Bauen zum Weg des geringsten Widerstands.
