Gute Kommunikation: Ein Eckpfeiler für ein erfolgreiches Designsystem

Die Einführung eines Designsystems in Ihrem Unternehmen bietet Designern und Entwicklern eine gemeinsame Bibliothek für Ressourcen und Designwahrheiten. Doch auch wenn Designsysteme eine bessere Teamarbeit ermöglichen, müssen Unternehmen die Art und Weise, wie sie kommunizieren, neu überdenken und neu angehen.

Ein Designsystem ist weder ein Sprint noch ein Marathon. Es ist sicherlich ein Langstreckenprojekt, aber Sie laufen nicht allein. Designsysteme werden von Teams für Teams entwickelt - die tatsächliche Größe hängt davon ab, wie groß Ihr(e) Produkt(e) sind, da sie sich an die Anforderungen anpassen. Sorgen Sie für eine gute Kommunikation innerhalb Ihrer Teams und Sie werden feststellen, dass Ihr Design System Wunder wirkt.

Ein Teil der Herausforderung besteht darin, dass jedes Team in der Regel aus Entwicklern, Designern, Produktmanagern, Product Ownern und sogar zusätzlichen Spezialisten wie Content Managern oder Accessibility-Experten besteht. Alle diese Personen müssen während des gesamten Projekts miteinander kommunizieren, und der Schlüssel zum Erfolg liegt im gegenseitigen Verständnis. Und das nicht nur innerhalb des Teams: Es ist auch wichtig, eine gemeinsame Basis mit anderen zu schaffen, die (jederzeit) zu Benutzern werden oder zum Designsystem beitragen können.

Warum ist diese Designkommunikation so wichtig? Erlauben Sie mir, das zu erklären!

Wissen sollte keine versteckte Perle sein

Eine der wichtigsten Maßnahmen, die Sie bei der Einführung eines erfolgreichen Designsystems ergreifen können, ist die Umwandlung einer Kultur der Isolation in eine Kultur des Teilens.

Dinge isoliert zu schaffen, muss nicht bedeuten, dass die Verantwortlichen egoistisch oder egozentrisch sind oder sogar Angst haben, dass jemand ihre großartigen Ideen und ihren Ruhm stiehlt. Sehr oft sind diese Probleme in der Kultur eines Unternehmens verwurzelt, die über Jahre hinweg sorgfältig gepflegt worden ist.

Der Einsatz eines Design-Systems ist jedoch eine großartige Gelegenheit, alle an einen Tisch zu bitten, denn Sie haben nun ein Design-Tool für alle Beteiligten. Um eine reibungslose Integration ohne Komplikationen oder Missverständnisse zu erreichen, arbeiten Sie sich am besten Schritt für Schritt durch den Prozess...

Entwurf Systemstufen

Bei der Erstellung von Design-Systemen - und damit meinen wir den Akt der Erstellung und Sammlung aller Ressourcen, aus denen die Bibliothek besteht - können wir den Prozess in Schlüsselphasen unterteilen. Für die Zwecke dieses Themas konzentrieren wir uns insbesondere auf folgende Punkte:

• Dokumentation
• Beitrag
• Adoption
• Dokumentation

Es mag Ihnen vielleicht nicht gefallen, aber die Dokumentation ist ein wesentlicher Bestandteil jedes erfolgreichen Designsystems. Schließlich können Sketch-Bibliotheken nur von Designern geöffnet werden, während Code-Repositories für Entwickler gedacht sind, aber die Dokumentation ist für alle da!

Natürlich wird die Dokumentation aus praktischen Gründen hauptsächlich von Designern und Entwicklern verwendet, aber sie hat auch einen sekundären Nutzen für alle anderen Personen, die sich für das Designsystem des Unternehmens interessieren. Dazu können auch Personen außerhalb der unmittelbaren Teams gehören, wie z.B. die angesprochenen Manager, Produktverantwortlichen, Content Manager, gelegentliche Mitarbeiter und andere.

Diese Leute kennen sich mit dem System nicht so gut aus wie diejenigen, die rund um die Uhr damit arbeiten. Wenn Sie also Zweifel haben, denken Sie einfach daran:

"Wenn es nicht dokumentiert ist, existiert es nicht"

Wie nennen Sie es?

Ein Name mag unbedeutend erscheinen, aber seine Bedeutung darf nicht unterschätzt werden. Was für den einen ein "Wasserhahn" ist, kann für den anderen ein "Zapfhahn" oder "Wasserhahn" sein. Es ist nur eine kleine Änderung, aber zwei Menschen mit unterschiedlicher Terminologie wissen vielleicht gar nicht, dass sie über dieselbe Sache sprechen.

Lassen Sie uns also ein Beispiel aus einer Designbibliothek erstellen, indem wir ein UI-Element wie das folgende verwenden. Wie würden Sie es benennen? Welche Funktion hat es? Sobald Sie Ihre Antwort haben, fragen Sie Ihre Kollegen.

Wie viele verschiedene Antworten haben Sie erhalten? Ich habe für die folgenden Beschreibungen die Antworten einiger bekannter Unternehmen und ihrer internen Designsysteme recherchiert:

Texteingabe "Texteingaben ermöglichen es dem Benutzer, mit Daten zu interagieren und sie einzugeben. Verwenden Sie sie, wenn die Anwendung vom Benutzer lange Inhalte verlangt." - Carbon Design System

Eingabe "Texteingaben werden für die freie Dateneingabe verwendet." - Salesforce Design System

Textfelder "Über Textfelder können Benutzer Text eingeben und bearbeiten." - Google Material Design

Wie Sie sehen, versteht das jeder ein bisschen anders, aber dieses "bisschen" kann einen Schneeballeffekt auslösen und Ihr Designsystem Schritt für Schritt immer weniger konsistent machen. Wenn Sie es als Textfeld bezeichnen, verstehen Sie dann, wenn ein anderes Team über Änderungen am Eingabefeld diskutiert?

Kurz gesagt, Worte sind sehr wichtig, aber andererseits will sich niemand all diese Begriffe durchlesen. Sie fragen sich also sicher: Wie kann ich kommunizieren, was ich will, und trotzdem verstanden werden?

"Informationen werden aufgeschrieben - aber niemand liest sie gerne"

Halten Sie Ihre Dokumentation so einfach wie möglich und fassen Sie sie kurz. Achten Sie auf die Wortwahl und verwenden Sie Schlüsselwörter wie "freie Dateneingabe" oder "Text eingeben", damit andere Benutzer den Zweck der jeweiligen Komponente schnell verstehen können.

Verwenden Sie außerdem, wenn möglich, visuelle Beispiele anstelle von Worten - aber auch hier sollten Sie den Leser nicht überfordern. Dazu können Sie beitragen, indem Sie:

• Zeigen Sie nur die wichtigsten Zustände an, sonst haben Sie am Ende Hunderte von Bildern.
• Verwendung echter Daten anstelle von Lorem ipsum und Platzhaltern, die Assets in Kontakt zeigen.
• Beispiele für Verhaltensweisen und Nicht-Verhaltensweisen.
• Erstellen Sie nach Möglichkeit interaktive Beispiele für jede Komponente (mit Codebeispielen)

Auch die in der Dokumentation verwendete Sprache sollte nicht zu technisch sein: Sie sollte für ein breites Publikum leicht verständlich sein. Die Benutzer müssen ermutigt werden, zu handeln und Ihre Elemente zu verwenden. Ein Profi-Tipp: Versuchen Sie, passive Wörter zu vermeiden. Verwenden Sie stattdessen Gerundien, die auf "ing" enden, wie z.B. erweitern und anzeigen. So wird schnell klar, was die Komponente tut.

Sie sollten sich auch darüber im Klaren sein, dass Ihre Kollegen interessantere Dinge zu tun haben, als Ihre Dokumentation zu verfolgen. Jede neue Aktualisierung, sei es eine wichtige Aktualisierung, neue Komponenten oder Meilensteine bei der benutzerdefinierten Einrichtung, sollte allen mitgeteilt werden. Am besten kommunizieren Sie dies über einen gelegentlichen Newsletter, eine Ankündigung oder einen internen Blog-Beitrag. Warten Sie nicht, bis die Leute merken, dass Sie die Dokumentation geändert oder erweitert haben.

Eine weitere wichtige Überlegung ist die Einrichtung einer Kategorie namens Changelong oder Updates. Auf diese Weise können Benutzer, die sich auf dem Laufenden halten möchten, schnell die neuesten Änderungen sehen und sich über das Designsystem informieren.

Beitrag

Der Aufbau eines Designsystems ist ein iterativer und schrittweiser Prozess. Sie beginnen mit einem Produkt oder einem Kernteil davon und andere Teams passen das System nach und nach an ihre weiteren Bedürfnisse an. Auf diese Weise können - und sollten - sie ständig Einfluss auf das Designsystem nehmen und sich als dessen Mitautoren fühlen.

Aus wirtschaftlichen und organisatorischen Gründen gibt es immer wieder Personen, die nicht in Vollzeit zum Kernteam von Design System gehören können - aber das bedeutet nicht, dass ihr Beitrag nicht genauso wichtig ist.

"Designer und Entwickler müssen sich als Co-Autoren sehen, nicht nur als Benutzer des Designsystems".

Was genau können Benutzer also zum Design System beitragen? Sie können Fehler melden, Verbesserungen einreichen, neue Komponenten vorschlagen und sogar Feedback geben. Kurz gesagt, sie können Ihr Design System noch kugelsicherer machen.

Wie kann ich Mitwirkende an Bord holen?

Zuallererst müssen Sie die Bedürfnisse und Herausforderungen jedes Einzelnen verstehen. Organisieren Sie "runde Tische", an denen Designer aus anderen Teams über ihre täglichen Herausforderungen mit jeder einzelnen Komponente sprechen können. Sie können dies vor Ort organisieren oder Online-Kommunikationstools verwenden - wichtig ist nur, dass alle offen miteinander reden können.

Dies wird sich positiv auf Ihr Designsystem auswirken, denn es bringt viele neue Erkenntnisse und bisher unbekannte Anwendungsfälle auf den Tisch. Sie können diese Informationen dann berücksichtigen und in der nächsten Phase der Komponentenentwicklung können Ihnen dieselben Personen wertvolles Feedback geben, z. B. ob die Komponente nun ihren Bedürfnissen entspricht oder nicht.

Am Ende, auch nach der Veröffentlichung, werden Sie diese Menschen nicht nur als Benutzer sehen: Sie sind Mitgestalter des Designsystems.

Dies ist jedoch etwas, bei dem Sie proaktiv vorgehen müssen - Sie können nicht einfach warten, bis man an Ihre Tür klopft. Eine gute Idee ist es, jemanden zu finden, der als Botschafter fungieren kann. Diese Person wird sein oder ihr Team repräsentieren und als Bindeglied zwischen anderen Teams fungieren. Dann können Sie sie zu Ihren Planungssitzungen und anderen wichtigen Themen einladen.

Es kann nicht oft genug betont werden, wie wichtig es ist, dass das Designsystem offen für Beiträge ist, denn Ihr Produkt wächst und es werden ständig neue Funktionen entwickelt. Die einzige Möglichkeit, die Konsistenz zu wahren und sicherzustellen, dass alles funktioniert, besteht darin, eine offene Kommunikation zwischen allen beteiligten Teams und Spezialisten zu ermöglichen.

Um auf Änderungen und neue Anforderungen von Produktteams - auch von solchen, die über die ganze Welt verstreut sind - vorbereitet zu sein, ist es immer eine gute Praxis, ein "Beitragsmodell / Workflow" in der Dokumentation zu definieren. Darin sollte festgelegt werden, wer einen Beitrag leisten kann und wie er oder sie seinen Vorschlag einreichen kann. Ein gutes Beispiel dafür ist das Kapitel "Community" in der Dokumentation für das GOV.UK Design System. Auf diese Weise weiß jeder, wie er einen Beitrag leisten kann, und die für die Pflege des Designsystems Verantwortlichen sehen jeden Beitrag.

Aber was, wenn Sie das nicht tun? Nun, mangelnde Akzeptanz, nicht diskutierte benötigte Funktionen und Integrationsprobleme sind nur die Spitze des Eisbergs. Bei schlechter oder fehlender Kommunikation beginnen Designsysteme zu zerfallen. Eine gemeinsam genutzte Bibliothek funktioniert am besten, wenn die Beteiligten von vornherein proaktiv an der gemeinsamen Nutzung teilnehmen.

Adoption

Das Design System zu entwerfen und zu entwickeln ist eine Sache, aber es ist eine andere, den Prozess über verschiedene Teams und Produkte hinweg zu implementieren.

Wenn Sie über ein gut definiertes und organisiertes Beitragsmodell verfügen, wird die Einführung in der Regel reibungslos verlaufen, weil Sie Botschafter in den Teams etabliert haben und deren Mitglieder sich als Mitautoren des Designsystems fühlen. Wenn sich die Mitarbeiter einbezogen fühlen, ist die Wahrscheinlichkeit größer, dass sie diesen neuen Ansatz übernehmen.

Dieser Erfolg hängt jedoch auch von vielen anderen Bedingungen ab, z. B. von der Produktvererbung, der Integrationsfähigkeit, der Zeit, dem Geld, usw. Neben den Beiträgen sollten Sie ihnen auch direkte Vorteile nennen, die sie dazu bewegen, das System zu übernehmen - glücklicherweise haben wir die Vorteile von Design System bereits in einem früheren Artikel besprochen.

Wenn Sie den direkten Nutzen aufzeigen - z.B. wie Design Systems dazu beiträgt, Produkte zu verbessern und zu skalieren - werden die Leute gerne an Bord kommen.

Ein wichtiges Glied in der Kommunikationskette

Sie können über eine gut organisierte Dokumentation, eine fantastische Komponentenbibliothek und sogar eine große Community verfügen, die sich um das Designsystem herum gebildet hat... aber wenn Designer und Entwickler nicht dieselbe Sprache sprechen, ist Ihr Designsystem möglicherweise gefährdet.

Schon ein einfacher Faktor wie die Wahl eines Namens für "Texteingabe" zeigt, wie kleine Änderungen auf einer höheren Ebene große Probleme verursachen. Doch die tägliche Arbeit für Designer und Entwickler geht noch tiefer. Sie wollen wissen, welche Farbe der Text hat, wie viele Pixel Padding benötigt werden, welche Schriftart gewählt werden soll.... die Liste der Anforderungen geht weiter!

Es gibt auch Tools wie Abstract oder Zeplin, die einen Inspektionsmodus anbieten, aber ist das ausreichend? Wie können wir auf diese Details verweisen, wenn wir über sie sprechen, oder sie sogar in der Dokumentation erwähnen? Die Antwort liegt in der Verwendung von Token.

Design-Token sind die Atome, die als visuelle Stileigenschaften verwendet werden. Sie werden anstelle von fest kodierten Werten verwendet, die über Produkte hinweg als Abhängigkeiten integriert werden. Da es sich nicht um fest kodierte Werte handelt, bieten sie eine skalierbare Lösung.

Ihre Werte sind schon vor der Implementierung erkennbar, denn sie werden sowohl von den Designern als auch von den Entwicklern festgelegt, wenn der neue Stil und die Eigenschaften festgelegt werden. Daher haben Designer und Entwickler von Anfang an die gleiche Perspektive und das gleiche Verständnis.

Später ist es einfacher, über die Verwendung von orange-90 oder primary-hover zu sprechen, als über "das hellere Orange". Aus der Entwicklungsperspektive hilft es, flexiblen Code mit Eigenschaften zu erstellen, die über viele Plattformen und Produkte hinweg synchronisiert werden können - genau das, was ein Designsystem braucht!

Alles zusammenfügen

Wie fangen Sie also an? Auch wenn es nach viel klingt, ist es eigentlich ganz einfach, wenn Sie es einmal ausprobiert haben. Der wichtigste Faktor ist, dass Sie sicherstellen, dass alles für alle zugänglich ist, egal ob es sich um die Dokumentation, Assets im Designsystem oder wichtige Diskussionen handelt. Wenn alle Teams beteiligt und einbezogen werden, bleibt niemand außen vor. Außerdem werden Sie feststellen, dass sie sich engagieren, das Designsystem und seine Ressourcen nutzen und verbessern wollen! Noch wichtiger ist, dass niemand mit veralteter Dokumentation arbeitet!

Geschäftsperspektive

Designsysteme ermöglichen nicht nur schnellere Entwürfe - sie verbessern auch die Kommunikation zwischen ganzen Teams und Abteilungen. Auf diese Weise wird sichergestellt, dass neue Projekte konsistent und ohne Verwirrung entwickelt werden, so dass sich jeder in allen Phasen einbezogen fühlt.