Fangen wir von vorne an

Designsystem. In den letzten Jahren ist dieser Begriff allgegenwärtig. Für uns Designer sind Definition und Nutzen eines Designsystems selbstverständlich. Für andere Teammitglieder ist es jedoch nicht immer so klar. 

Wenn Sie bereits wissen, was ein Designsystem ist, zögern Sie nicht, direkt zum Abschnitt über Kommunikation zu springen.

2018 bot Usabilis folgende Beschreibung an: Ein Designsystem ähnelt einer Bibliothek mit Komponenten, visuellen Elementen und Prinzipien sowie wiederverwendbarem Code. Dieses sich stetig weiterentwickelnde Toolkit bietet Designern und Entwicklern digitaler Produkte und Dienstleistungen ein Repository für UX und UI. Okay, aber ohne den Fachjargon?

Wir könnten ein Designsystem mit einer großen Küche vergleichen. Es gibt viele Zutaten und Rezepte, mit denen Sie diese Zutaten richtig verwenden können.

Die Köche des Designsystems sind die Designer (UI und UX) und die Entwickler. Ihnen wird das Designsystem am meisten dienen. Die Designer werden die Zutaten auswählen (die Komponenten erstellen), die Rezepte schreiben (die Modelle herstellen) und sie den Entwicklern zur Verfügung stellen, die die Gerichte kochen (die Websites, Apps usw. entwickeln).

Durch die Verwendung einer gemeinsamen Küche, der gleichen Zutaten und der gleichen Rezepte können Designer und Entwickler sicher sein, dass alle Gerichte, die in den Raum (in der Produktion) geliefert werden, konsistent sind und vor allem ein Ergebnis entwickelt wird, das sehr ähnlich oder sogar identisch mit dem ist vorgelagert erstellte Modelle.

Und das ist noch nicht einmal der Hauptvorteil des Designsystems! Tatsächlich ist sein Hauptvorteil die Ausführungsgeschwindigkeit, die es dem gesamten Produktteam (Designer + Entwickler) ermöglicht. Da die Komponenten bereits fertig sind, müssen Sie sie nur noch zusammenbauen, um neue Seiten, Schnittstellen usw. zu erstellen! Wir vergleichen das Designsystem oft mit Lego, nicht umsonst.

Der andere Hauptvorteil ergibt sich aus Komponentenaktualisierungen. Da alle Komponenten mit der Bibliothek „verbunden“ sind, ermöglicht eine Aktualisierung einer von ihnen direkt in der Bibliothek, die Komponente mühelos zu aktualisieren, wo immer sie verwendet wird. Spart Zeit, spart Aufwand (kein Suchen von Hand wo das Bauteil verwendet wird!), was will man mehr?

Disclaimer: Für die Entwickler hat das Designsystem nur Vorteile für die Front. Es nimmt in keiner Weise von der Komplexität des Rückens und den Managementregeln ab.

# Inhalt

Ein Designsystem besteht im Allgemeinen aus 2 Arbeitsquellen. Eine Quelle für Designer, kompatibel mit der verwendeten Software (Sketch, Figma,…) und eine Quelle für Entwickler, die alle bereits entwickelten Komponenten sowie deren Code präsentiert. In jedem Fall können die in diesen Quellen vorhandenen Komponenten direkt „aufgerufen“ werden (entweder in den Modellen für die Designer oder im Code für die Entwickler), was viel Zeit und Konsistenz bei der Realisierung spart.  

Bei der Besprechung des Designsystems beziehen wir uns meist auf den Entwicklungsquellcode, da dieser in der Produktion verwendet wird. Die darin enthaltenen Elemente sind für Endbenutzer sichtbar. Der Designerquellcode hingegen ist nur für Designer und Entwickler zugänglich.

Aber was ist drin? Es hängt davon ab. Es gibt natürlich Richtlinien, eine Vielzahl von Artikeln, die Best Practices auflisten. Zögern Sie nicht, ihnen zu folgen, wenn sie den Bedürfnissen nicht ganz entsprechen. Darüber hinaus ist die Einrichtung eines Designsystems etwas sehr Langwieriges. Alles auf einmal ist kompliziert. Es gibt jedoch wichtige Elemente, denen wir uns zuwenden müssen, weniger ursprüngliche Elemente, die es dennoch gut hat, und die wir später vollständig hinzufügen können.

Einige wichtige Inhaltselemente:

• die Farben
• Typografie
• Gitter
• die Komponenten
• die Richtlinien für die Verwendung aller oben genannten Elemente
• der zu verwendende Ton

Meiner Erfahrung nach sind die Hauptprobleme beim Aufbau eines Designsystems:

• für das Unternehmen: Aufbau- und Unterhaltskosten, die sich langfristig rentieren
• für die Teams, die es einrichten und verwenden: Vorwegnahme der Ankunft neuer Mitglieder im Team und Designer-Entwickler-Kommunikation

Hier konzentrieren wir uns auf das, was die Teams direkt betrifft.

Falls Sie sich fragen, was die Ankunft neuer Familienmitglieder so besonders macht, habe ich eine Frage an Sie: Haben Sie schon einmal bei jemand anderem gekocht? Wenn ja, haben Sie dann jeden Schrank und jede Schublade durchsucht, um die benötigten Zutaten und Utensilien zu finden? Waren Sie überrascht, ein Gewürz zu vermissen, das Sie für unverzichtbar halten? Meine Antwort lautet: Ja.

Genauso verhält es sich mit unserem Designsystem. Egal, ob ein neuer Entwickler oder ein neuer Designer ins Team kommt, er muss selbst sehr schnell finden können, wonach er sucht, und dass die Gebrauchsanweisung so klar ist, dass er die Komponenten richtig verwenden kann . Dies wird es unserem Neuling (nennen wir ihn Fred) ermöglichen, dieses neue Projekt unter den besten Bedingungen und ohne Frustration in die Hand zu nehmen.

Dann kommt das Thema Kommunikation. Durch Erweiterung der Nomenklatur und Anordnung der Komponenten im Konstruktionssystem. In der Tat muss das Designsystem bereits intuitiv sein, damit sich Teammitglieder (neu oder nicht) zurechtfinden.   

Wenn Teammitglieder mehrere Begriffe verwenden, um sich auf dieselbe Komponente zu beziehen, wird dies früher oder später zu einem Problem.

Nehmen wir ein einfaches Beispiel :

Manche werden hier von Droplist sprechen, andere von Dropdown. Wieder andere aus der Dropdown-Liste oder sogar aus DDL. 4 mögliche Namen zur Bezeichnung einer einzelnen Komponente.

Wenn für einige Komponenten des Designsystems jeder seinen eigenen Namen verwendet, wird die Kommunikation zwischen den Menschen immer schwieriger, weil sich jeder die Mühe machen muss, sich zu merken, dass Lenny „Dropdown“, Karl „DDL“, Lisa „Droplist“ sagt.

Jeder muss also jedes Mal den Gedanken des anderen übersetzen. Stellen Sie sich in diesem Zusammenhang nun Tony vor, den Neuankömmling. Er weiß noch nicht, dass diese Kollegen verschiedene Namen verwenden, um über dieselbe Sache zu sprechen. Während eines Gesprächs wird Lisa mit ihm über „Droplist“ sprechen. Das ist gut, Fred braucht es für seinen Job. Es bezieht sich daher auf das Designsystem und … es gibt keine Komponente namens „Droplist“. Daher wird es für Fred einen zusätzlichen Aufwand erfordern, das berühmte Bauteil zu finden. Er wird auch lernen müssen, dass Lenny und Karl andere Begriffe verwenden. 

Umgekehrt, wenn Sie über die nächste Farbe sprechen, die Sie „Blau“ gesagt haben, und das gesamte Team denselben Begriff verwendet, dann wird die Kommunikation gut laufen. Wenn wir sagen „diese Komponente ist blau“, weiß jeder am Tisch, über welchen Blauton wir sprechen.

Wie Sie sehen können, ist es sehr wichtig, eine einzige Nomenklatur für alle Teammitglieder zu haben, sowohl mündlich als auch im Designsystem, um eine reibungslose Kommunikation zu gewährleisten und auch um eine einfache Handhabung und Navigation im Designsystem zu ermöglichen.

# Wartung und Aktualisierung des Designsystems

Ein Schlüsselbegriff in der Usabilis-Beschreibung ist „skalierbar“. Ein Designsystem soll in Bewegung sein. Dies sind keine in Stein gemeißelten Gesetze: Die Elemente, aus denen es besteht, können aktualisiert werden, andere können erstellt werden, alte Komponenten können gelöscht werden. So wie wir ein Rezept nach mehrmaliger Zubereitung an unseren Geschmack anpassen, können wir neue Zutaten hinzufügen, um mehr Aromen und Feinheiten zu erhalten. 

Ein Designsystem ist kein Selbstzweck. Es ist ein Arbeitswerkzeug für Designer und Entwickler. Daher entwickelt es sich mit den Teams und Projekten weiter.

Ein Designsystem sollte nicht als Projekt mit begrenzter Dauer betrachtet werden. Die darin enthaltenen Komponenten und Regeln können sich ändern. Außergewöhnliche Variationen einiger Komponenten können erforderlich sein. Daher ist es wichtig, weiterhin Ressourcen (Entwickler + Designer) für die Überwachung und Wartung des Designsystems bereitzustellen. Wenn es ein Jahr lang ausgelassen wurde, wäre die Aktualisierung fast so, als würde man die ganze Arbeit wiederholen, um es einzurichten. Es ist sehr lang. Niemand will das zweimal machen. Ganz zu schweigen von den Kosten für das Unternehmen. Es ist daher unerlässlich, Ressourcen für die Wartung und Weiterentwicklung des Designsystems bereitzustellen. Je nach Reifegrad des DS kann eine Stunde pro Woche ausreichend sein.

# Schlüsselpunkte

Wenn Sie so weit gekommen sind, hoffe ich, dass dieser Artikel neue Horizonte für Ihr Designsystem eröffnet hat oder dass Sie besser verstehen, was es ist und wozu es dient.

Wenn Sie sich nur ein paar Punkte merken sollten :

• Das Designsystem ist ein Erstellungs- und Kommunikationstool, das von und für Designer und Entwickler entwickelt wurde
• Es gewährleistet die Konsistenz eines Produkts
• Die Implementierungs- und Wartungskosten werden weitgehend durch die Ausführungsgeschwindigkeit kompensiert, die Designern und Entwicklern geboten wird
• Es kann sich im Laufe der Zeit ändern
• Es sollte regelmäßig aktualisiert werden