Was ist eigentlich ein Designsystem?

Es hängt davon ab, wie wir es betrachten. Es gibt im Moment eine Menge Innovation im Bereich der Designsysteme, weshalb so viel darüber geredet wird. Es gibt viele Gründe, warum dies geschieht. Um nur einige zu nennen:

• Entwickler möchten nicht dieselbe Arbeit auf verschiedenen Medien wiederholen.
• Unternehmen wollen effizienter sein.
• Product Owner und Produktdesigner möchten, dass die Produkte, an denen sie arbeiten, schneller und besser zugänglich sind und trotzdem konsistent aussehen. 

All dies sind echte Probleme, mit denen wir täglich konfrontiert sind und die uns dazu bewegt haben, neue Technologien zu entwickeln, neue Arbeitsmethoden und neue Wege zu finden, um Design besser zu verwalten und zu skalieren.

Das sind nur einige Gründe, warum Unternehmen so viel mehr in den Bereich Design-Systeme investieren. Da es sich jedoch um einen neuen Begriff handelt, ist seine Bedeutung und sein Prozess immer noch unklar, vage und inkonsistent. Aus diesem Grund sehen wir Diskussionen, Buzz und gelegentlich ein gutes altes Meme.

Soweit ich weiß, gibt es keine formale Definition, was ein Designsystem ist. Ich denke, weil die Probleme, die es löst (besonders im Bereich der digitalen Produkte), erst vor kurzem aufgetaucht sind. Um zu erklären werde ich ein Beispiel aus der realen Welt geben.

Wir haben eine Reihe von Produkten, die alle getrennte Codebasen und mehr oder weniger separate Teams / Owner haben:

• Hauptplattform
• Prototyp-Viewer
• Entwurfs-Werkzeuge
• Mobile Apps (iOS / Android)
• Mac Apps (Skizzen Plugin) 

Wir entwickeln und unterstützen auch einige statische Seiten:

• Marketing-Website
• WordPress Blog
• Eine Reihe von isolierten Back-End-Vorlagen 

Wir versenden auch täglich HTML-Mails:

• Einige von ihnen sind automatisiert
• Einige von ihnen müssen speziell erstellt werden 

Wir haben auch verschiedene Teams, die täglich zusammenarbeiten:

• Produkt
• Frontend
• Back-End
• Marketing
• Vertrieb

Mit all diesen verschiedenen Plattformen, Kanälen, Teams und Prozessen ergeben sich eine Reihe von Herausforderungen. Beispielsweise:

• Wie machen wir Design für alle Teams zugänglich?
• Wie stellen wir sicher, dass jedes Team die gleichen Technologien, Elemente und Muster verwendet
• Wie versenden wir neue Funktionen für jedes Produkt, ohne die gleiche Arbeit immer wieder zu wiederholen? Oder mit anderen Worten, wie bleiben wir effizient?
• Wie bringen wir all das Konsistenz? 

Was sind die Vorteile eines Designsystems?

Ich habe kurz einige der Probleme erwähnt, mit denen wir konfrontiert waren, bevor wir Design Systeme entwickelt haben. Die Vorteile bestehen also darin, Lösungen für die genannten Probleme zu finden, z. B. die Entwicklung konsistenter und zugänglicher Software über verschiedene Medien hinweg, die Wiederverwendung und Pflege von Code und Design auf effizientere Weise. Und natürlich die teamübergreifende Zusammenarbeit zu verbessern.

Was kann man vom Aufbau eines Designsystems lernen?

Es ist eine Herausforderung, ein Designsystem zu entwickeln, das gut skaliert, wenn das Team wächst. Besonders, wenn gleichzeitig die Produkte an Umfang und Komplexität wachsen. Es braucht viel Zeit und Mühe und es scheint immer Hürden zu geben.

Was wir in den letzten zwei Jahren realisiert haben ist, dass es sehr hilfreich sein kann, das Designsystem als separates Produkt zu behandeln. Es braucht eigene Anforderungen, eigene Features, eine solide Roadmap und klare Priorisierung.

Zum Beispiel sind unsere Pattern Libraries nicht etwas, das wir gebaut und dann sich selbst überlassen haben. Sie entwickeln sich jeden Tag, denn es gibt einen ständig wachsenden Rückstau an Feature-Anfragen (nur intern). All diese Dinge zu verwalten und dabei sicherzustellen, dass die Produkte konsistent bleiben, nicht kaputt gehen oder seltsam aussehen, erwiesen sich als der schwierigste Teil. Am Ende des Tages ist es eine Mischung aus Design und Software, so dass es auf die gleiche Weise behandelt werden muss.

Andere Dinge, die wir erkannt haben, waren für den Prozess entscheidend, besonders wenn Zeit und Ressourcen knapp sind:

• Ausführliche Dokumentation
• Regelmäßige Prüfung
• Nutzerforschung
• Testen 

Zu guter Letzt klingt es vielleicht sehr offensichtlich, aber wir haben bemerkt, dass alles Neue, das kompliziert ist (ein UI-Kit oder eine Musterbibliothek oder sogar ein Designprozess), nur langsam angenommen wird - es sei denn, es wird religiös durchgesetzt.

Wenn es beim Lernen Aufwand verursacht und Zeit braucht, um sich daran zu gewöhnen, werden die Leute verwirrt und ignorieren es. Der Grund ist, dass jeder seine Arbeit schnell erledigen will, was bedeutet, dass er/sie eher keine Zeit in etwas Neues investieren, das ihn kurzfristig bremst. Es ist nur schwer, die langfristigen Effizienzgewinne zu sehen. Jede Abweichung vom regulären Workflow wird einige Zeit benötigen, um Anpassungen vorzunehmen. Daher ist es auch eine Herausforderung, sicherzustellen, dass die Lösungen einfach, verständlich und unkompliziert sind.

Wie beginnt man mit der Entwicklung eines Designsystems?

Eine andere Frage, auf die wir keine konkrete Antwort haben, da jedes Projekt anders ist. Das erste, was wir tun, ist ein Audit der bestehenden Marke, Produkte und Benutzeroberflächen.

Wenn wir mit der Erstellung eines Styleguides beginnen, gibt es Seite eventuell bereits seit zwei Jahren. Sie ist ein etabliertes Produkt, das bereits ein gutes, konsistentes Design hat, das die Menschen liebten und gerne verwendeten. Es kommt jedoch vielleicht zu einem Punkt, an dem wichtige Funktionen eingeführt werden und es zu einer Plattform anstatt zu einem einzigen Produkt wird, so dass das Bedürfnis nach Konsistenz immer wichtiger wird.

Dann führen wir ein Audit der bestehenden Codebasis durch und identifizieren einige Probleme, zum Beispiel:

• Identische Komponenten wurden inkonsistent implementiert.
• Farben wurden nicht richtig ausgewogen.
• Transitions wurden scheinbar zufällig festgelegt.
• Es zu viele verschiedene Schriftgrößen.
• Wir zählten viele leicht verschiedene Schattierungen des gleichen Graus.
• Viele CSS-Dateien wurden entweder dupliziert oder nicht verwendet. 

Von da an entscheidet man sich für Technik und den Ansatz, um die folgenden Probleme zu lösen:

1. Erstellen Sie ein Framework, um alle Designwerte zu vereinheitlichen
2. Erstellen Sie eine Musterbibliothek, um vorhandene Benutzeroberflächen konsistent zu machen
3. Legen Sie klare Richtlinien und Regeln für die Verwendung fest

Was macht ein gutes Design System aus?

Wir glauben nicht, dass es eine bestimmte Sache ist und würden sagen, dass es definitiv auf die Ausführung ankommt. Aber wir denken, dass diese Punkte entscheidend für ein gutes Design-System sind:

• Gute, prägnante Dokumentation
• Regeln und Richtlinien, die leicht zu verstehen sind
• Klare Begründung, warum bestimmte Entscheidungen getroffen wurden (Ein gutes Beispiel hierfür ist das Design-System von Bulb, das unter jeder Komponente Einblicke bietet und einen Kontext dafür bietet, warum bestimmte Entscheidungen getroffen wurden - meist unterstützt durch Benutzerforschung) 

Ist ein Designsystem immer eine gute Lösung?

Wenn es die Arbeitsabläufe der Kollegen mit unnötigen Prozessen überkompensiert und verstopft, ist es keine gute Lösung. Eigentlich wäre es dann gar keine Lösung.

Es reicht, eine Musterbibliothek haben, ohne sie als Design-System zu bezeichnen. Sie können ein einfaches UI-Kit benutzen. Oder eine Reihe von Designvariablen beim Erstellen einer einfachen Website. Wenn es Ihnen hilft, schneller zu bauen, dann macht es die Arbeit. Es muss nicht immer ein System sein.

Sie können alles auch unterwegs entwerfen und stylen. Wie wenn Sie Marketing-Websites erstellen. Oder Produkte mit einer Lebensdauer als Teil von Marketingkampagnen. Es spielt keine Rolle, was und wie Sie verwenden, solange Sie produktiv und effizient sind und die Arbeit erledigen.