The following article is offered for informational purposes only, and is not intended to provide, and should not be relied on, for legal or financial advice. Please consult your own legal or accounting advisors if you have questions on this topic.

Bei Flex sind wir ein kleines Engineering-Team, das dafür bekannt ist, weit über seiner Gewichtsklasse zu agieren und sehr handlungsorientiert zu sein. Nach einigen Jahren schneller Produktänderungen und Neuausrichtungen hatten wir eine beträchtliche Menge an UX-Schulden angehäuft, die sich in einer umständlichen Benutzererfahrung zeigte. 

Wir mussten weiterhin schnell liefern, aber mit deutlich höheren Qualitätsansprüchen und einem gemeinsamen Verständnis dessen, was „Qualität“ tatsächlich bedeutete. Als mir jedoch die Idee zugespielt wurde, ein Designsystem zu erstellen, geriet ich in einen leichten Panikmodus.

Da ich zuvor bereits zwei Designsysteme aufgebaut hatte, kannte ich die Fallstricke, die sie mit sich bringen können: unnötige Sonderanfertigungen, endlose Diskussionen über Kleinigkeiten, veraltete Dokumentation usw. Wir hatten weder die Zeit noch die Ressourcen, uns in dem Ballast zu verfangen, der mit Designsystemen einhergehen kann. 

Die Anforderung

Die Frage lautete schnell: „Wie können wir ein „schlankes“ Designsystem implementieren – eines, das einen Mehrwert liefert, ohne uns auszubremsen?“

Das Erste, was wir tun mussten, war zu bewerten, was ein umfassendes Designsystem mit sich brachte, im Vergleich zu dem schlanken System, das wir aufbauen wollten.

Normale, umfassende Designsysteme

• Benutzerdefinierte Komponenten (Schaltflächen, Modals, Tabellen usw.)
• Eigene Tools (Storybook-Setups, interne Infrastruktur)
• Prozesse/Governance für Änderungen
• Hohe Wartungskosten

Schlanke Designsysteme

• Nur die am häufigsten verwendeten Komponenten und Muster
• Einfach zu übernehmen – Dokumentation und Code befinden sich dort, wo Entwickler bereits arbeiten
• Nutzt bestehende Bibliotheken, anstatt von Grund auf neu zu entwickeln (wenn möglich)
• Hat Standards, um die Nutzung zu demonstrieren

Unsere Rahmenbedingungen: Kleines Team, große Ziele.

Wir begannen mit einer eleganten Designreihe, die von atomaren Komponenten (Schaltflächen, Eingabefelder usw.) bis hin zu gängigen Layouts und mehrstufigen Abläufen reichte. 

Während dieses Prozesses haben wir uns bemüht, nicht neue Komponenten zu erstellen, es sei denn, es war absolut notwendig. Die Nutzung unserer ausgewählten Tools war unerlässlich. Wir sind ein kleines Unternehmen, das jede Woche eine Menge Arbeit leistet; das Letzte, was wir brauchten, war, uns in den Kleinigkeiten kundenspezifischer Probleme durch kundenspezifische Komponenten zu verlieren.

Obwohl die visuellen Inkonsistenzen offensichtlich waren, war ein tiefergehendes Problem, das ich bei Flex bemerkt hatte, das Fehlen eines einheitlichen Ansatzes für die Erstellung gängiger Benutzeroberflächen, wie z.B. Formulare. Man konnte im Code fünf verschiedene Arten finden, wie wir Formular-UIs implementierten. Es war klar, dass wir eine Reihe von Standards benötigten.

Erstellung einer Reihe einheitlicher Standards

Wir hatten zuvor begonnen, an einem „Spickzettel“-Bereich für Entwickler zu arbeiten, der eine Sammlung von Best Practices zum Kopieren/Einfügen bieten sollte. Dies wurde der perfekte Ort, um unser entstehendes Designsystem zu präsentieren. Wir konnten diesen Bereich (später in „Playground“ umbenannt) nutzen, um Entwicklern zu ermöglichen, diese Standards für unsere gängigsten UIs anzusehen und zu verwenden, um ihre Arbeit zu beschleunigen, und Designern auch zu zeigen, dass das, was sie entworfen haben, tatsächlich verwendet wird. Schließlich trug die Einbettung in unsere eigene Web-App (anstatt extern über eine Plattform wie Storybook) dazu bei, die Nutzung sicherzustellen.

Doch die Geschichte hatte gerade erst begonnen. Wir mussten zuerst ein paar Drachen besiegen:

1. Wir waren an eine frühere Version unserer gewählten UI-Bibliothek gebunden und ein Upgrade wäre eine ziemlich herkuleische Anstrengung gewesen. Diese Änderung hätte sich über unsere gesamte kundenorientierte App und unser internes Tool, Alfred, erstreckt.
2. Wir mussten Repositories zusammenführen, um unsere internen und Web-Apps gemeinsam zu hosten, um die app-übergreifende Nutzung des Designsystems zu gewährleisten.

Nachdem wir diese Meilensteine erreicht hatten, haben wir beide Apps neu gestaltet, um den neuen Designs zu entsprechen, und die Dynamik begann sich aufzubauen.

Wirkungsverstärker

Nach der Neugestaltung unseres internen Tools Alfred und der Web-App begannen wir, eine Reihe von Best Practices im Playground zu erstellen. Im Laufe der Zeit enthielt Playground die „80/20“ unserer Anwendungsfälle – eine zentrale Anlaufstelle für Komponenten, Layouts und gemeinsame Dienstprogramme.

‍

‍

Obwohl wir wussten, dass Playground für Entwickler nützlich sein würde, um Komponenten zu kopieren/einzufügen und die Arbeit zu beschleunigen, erwies sich diese Sammlung von Standards als perfekt für LLMs, um zu verstehen, wie UI-Code generiert werden sollte.

Auftritt: Cursor

Kurz nachdem wir mit dem Aufbau von Playground begonnen hatten, begann unser Frontend-Team mit der Nutzung von Cursor AI. Wir haben unseren Cursor-Regelreferenz-Playground erstellt, um ihn als Ausgangspunkt für die Generierung von UI-basiertem Code zu nutzen:

• Beispiele zur Verwendung unserer Designsystem-Komponenten finden Sie im Playground unter `src/areas/playground`.
• Wenn Sie neue Komponenten wie Drawers, Tables, Wizards, Layouts usw. implementieren, kopieren Sie die Datei, wie sie im Playground implementiert ist, und verwenden Sie sie als Ausgangspunkt in dem Bereich, an dem Sie arbeiten.
• Meistens werden Sie keine Dateien in `src/areas/playground` aktualisieren, sondern die dortigen Komponenten lediglich als Ausgangspunkte verwenden, um sie in neue Ordner in `src/areas` zu kopieren.

Unsere vorherige Re-Theming-Anstrengung hat sich hier enorm ausgezahlt, da sie den Weg für Cursor ebnete, UIs zu erstellen, die mit unserem Designsystem konsistent sind, ohne Style-Guidelines konsultieren zu müssen.

Um genauer zu definieren, „was Frontend-Qualität bei Flex bedeutet“, haben wir die Standards kodifiziert, auf die wir uns zuvor als UI-Team geeinigt hatten. Cursor referenziert dies zusätzlich zu den Regeln des Playgrounds, damit das LLM nicht nur versteht, was gebaut werden soll, sondern auch, wie es in Verbindung mit unseren verschiedenen Tools und Konventionen gebaut werden muss. Hier ist ein Ausschnitt, wie wir unsere aktuelle UI-Bibliothek, Mantine, aus unserer Cursor-Regeldatei referenzieren:

• Verwenden Sie Mantine als Ihre Basis-React-Komponentenbibliothek.
• Nutzen Sie die Mantine-Bibliothek voll aus, einschließlich Komponenten aus `@mantine/core`, Hooks aus `@mantine/hooks` und Formularen mit `@mantine/form`.
• Versuchen Sie bei Komponenten immer zuerst, Komponenten in unseren Ordnern `components/core` oder `components/composites` zu verwenden, andernfalls verwenden Sie nach Möglichkeit Kernkomponenten von Mantine.
• Vermeiden Sie Inline-Styling oder Klassen — versuchen Sie stattdessen immer zuerst, Mantine-Props für die Gestaltung von Farben und Hintergrundfarben, Abständen und Größen usw. zu verwenden.
• Verwenden Sie für Farben immer unsere Mantine-Theme-Farben (z. B. `theme.colors.yourColorHere[index]`).
• Verwenden Sie für Abstände und Größen Mantines `rem()`-Funktion anstelle von Pixel- oder numerischen Werten, z. B. `gap={rem(12)}`

Flex-Ergebnisse

Der Einsatz von KI zusammen mit unserem Designsystem hat sich durchweg als bahnbrechend erwiesen, um einen höheren Standard für Geschwindigkeit und Qualität zu schaffen und aufrechtzuerhalten. Unsere kürzlich entwickelte Funktion für Debitorenbuchhaltung wurde vollständig innerhalb von drei Wochen erstellt! 

Ebenso hat die Nutzung des Playgrounds als solide Sammlung von Komponenten und Mustern unseren Qualitätsanspruch unterstrichen, sowohl für Entwickler als auch für LLMs. Durch die Verfolgung eines schlankeren Ansatzes beim Aufbau eines Designsystems konnten wir die zahlreichen Fallstricke umgehen, die oft mit Designsystemen verbunden sind, wobei die Vorteile von Konsistenz und Richtung erhalten blieben.

Kürzlich haben wir den Playground als Bildungsressource genutzt, um zu zeigen, wie Entwickler Alternativen zu einem State-Management-Tool verwenden können, das wir aktiv versuchen, zu verwerfen. In naher Zukunft wollen wir unsere Playground-Standards an unseren CI-Build anhängen, um die Akzeptanz weiter zu gewährleisten.

Lehren für andere Teams

Wenn Sie sich in der Frühphase befinden, empfehlen wir Folgendes:

• Klein anfangen: Konzentrieren Sie sich auf Ihre am häufigsten verwendeten UI-Komponenten
• Vermeiden Sie individuelle Anpassungen: Die meisten modernen UI-Komponentenbibliotheken können genutzt werden, um den Aufbau Ihres Designsystems zu beschleunigen. Heben Sie individuelle Anpassungen für komplexere Komponenten und Workflows auf.
• Definieren Sie genau, was „gut“ bedeutet: Stellen Sie sicher, dass Ihr Team über eine Reihe von vereinbarten Standards für UI-Tools und Codierungskonventionen verfügt, damit Sie diese mit KI-Tools kodifizieren können.
• Machen Sie es Ihrem Team klar: Integrieren Sie Ihr Designsystem in das Produkt, um sicherzustellen, dass es auch genutzt wird.
• Machen Sie es für LLMs zugänglich: Stellen Sie sicher, dass Ihre KI-Tools Ihr Designsystem und Ihre Standards problemlos referenzieren können, um die Konsistenz vor der Codegenerierung zu gewährleisten.

Abschließende Gedanken

Sie benötigen wahrscheinlich kein individuelles oder vollständiges Designsystem. Sie benötigen ein nützliches.

Bei Flex ist unser Designsystem zu einem Multiplikator in den Bereichen Engineering, Produkt und Design geworden. Es hat uns geholfen, schneller voranzukommen und dabei einen deutlich höheren Qualitätsstandard zu erreichen.

Für Teams in der Frühphase, die auf Geschwindigkeit und KI-Tools setzen, könnte dies eine der klügsten Infrastrukturinvestitionen sein, die Sie tätigen können.

‍