6 Fragen zu Erfolg und Scheitern von Design Systems

In letzter Zeit beschäftige ich mich intensiv damit, weil ich an der anfänglichen Konzeption eines Design Systems beteiligt bin.

Dazu habe ich letzte Woche etwas bei UX Collective gelesen. Ich hatte es für die Mitglieder des Design-System-Teams in meinem Unternehmen übersetzt und teile es jetzt auch hier, weil es zu schade wäre, es nicht zu tun.

Es heißt, es sei eine Zusammenfassung von Interviews mit 10 Designerinnen und Designern, die mit Design Systems arbeiten.

Frage 1. Wie scheitert man in einer DS-Rolle?

• Zum Polizisten werden

• Die Macht der Designer ausspielen (politische Themen)

• Komponenten vereinheitlichen, aber sie dann nicht verwenden

• Statt Anforderungen der Teams vorauszusehen nur reaktiv arbeiten

• Nicht auf die Stimmen der Nutzerinnen und Nutzer (andere Designer oder Entwickler) hören oder sie nicht erforschen

• Ein DS nur für das DS bauen

• Keinen klaren Fahrplan und keinen klaren Prozess für die Arbeit beibehalten

• Ein ideales Erlebnis schaffen, das sich nicht umsetzen lässt

• Nicht gemeinsam mit dem Team testen

• DS nicht als ein Produkt verstehen

• Tools bauen und den Leuten nicht beibringen, wie sie sie nutzen sollen

• Zu viele Theorien einbringen, die weit von der tatsächlichen Arbeitsweise entfernt sind

• Denken, dass man es allein schaffen kann

• Sich nicht zu 100 % auf Wissensaustausch mit jemandem aus dem Technikteam konzentrieren

• Zu unflexible Komponenten bauen und kein Detaching erlauben

• Weder um Hilfe bitten noch sich mit anderen vernetzen (intern oder extern)

• Regeln aus der Ferne vorgeben statt direkt an der Seite der Teams

Frage 2. Welche Soft Skills braucht ein DS, um erfolgreich zu sein?

• Kommunikation, Kommunikation, Kommunikation!!!

• Gemeinsam mit den Nutzerinnen und Nutzern arbeiten, zuhören, fragen und recherchieren ist wirklich wichtig.

• Fehler demütig eingestehen

• Geduld haben

• Die Fähigkeit, einen sicheren Raum zu schaffen

• Lehren

• Eine systematische Vision dafür vermitteln, wie Wiederverwendung funktioniert

• Auch bei der Skalierung konsequent Konsistenz wahren

• Um andere zu verstehen, muss man sich nicht übermäßig einfühlen. Akzeptiert Regeln, wie sie sind.

• 95 % sind Hard Skills und 5 % sind Soft Skills für den Fall, dass Regeln gebrochen werden.

• Das Wachstum der Menschen fördern und teilen

• Autonomie

• Das Produkt (DS) immer weiter verkaufen

• Strategisch denken

• Alle zur Teilnahme bewegen

• Rund um DS für Aufmerksamkeit sorgen

• So viel Zeit wie möglich investieren, um so viele Szenarien wie möglich zu identifizieren

• Die Sprache aufeinander abstimmen.

Frage 3. Sollte die Art, wie DS betrieben wird, stärker zentralisiert oder stärker verteilt sein?

Es gibt zwei Wege: ein zentralisiertes Team, das prüft und verantwortet, wie Menschen designen, und einen Ansatz, bei dem alle dafür Verantwortung tragen. Die Leute wurden gefragt, welche Seite die richtige ist.

• Wir sind ein zu stark zentralisiertes Team, daher entstehen Bottlenecks. Aber ein verteiltes Modell kann auch zu schwächerem Ownership führen.

• Wir haben ein Designteam mit mehr als 100 Leuten, um DS zu zentralisieren.

• Wir arbeiten mit Alpha-Libraries zusammen, die von den Leuten erstellt werden, und machen daraus den Backlog des DS-Teams.

• Wir schulen die Leute darin, freiwillig Komponenten zu erstellen.

• Ob man zentralisiert oder nicht, ist stark eine politische Frage. Bevor man das entscheidet, muss man genau wissen, wie skalierbar es sein soll.

• Man muss Erwartungen abstimmen und die Leute in den Aufbau des DS einbeziehen.

• Wir wollten Zusammenarbeit, wussten aber nicht genau wie, also haben wir einen Prozess geschaffen. (Culture vs Process)

• Anfangs kann man für die Auslieferung etwas weniger kollaborativ sein. Mit zunehmender Reife kann es kollaborativer werden.

• Wir haben jetzt den Punkt erreicht, an dem wir das dezentralisieren müssen; wir müssen den Leuten beibringen, wie sie beitragen können.

• Wenn man die Leute nicht schult, werden sie nichts beitragen.

• Wenn Designer über den Standard hinausgehen und bessere Ergebnisse schaffen wollen, muss man gleichzeitig mitdenken können, wie sich das standardisieren lässt.

• DS kann man nicht mit 1–2 Personen machen. Weil es um den Aufbau eines Systems geht, sollte DS auf Squad-Ebene beginnen.

• Das hängt stark von der Teamgröße ab; manchmal konzentriert sich das DS-Team auf die Entwicklung von Core-Komponenten und andere Ambassadors tragen sie weiter.

-Letztlich sind wir ein zentralisiertes Team, arbeiten aber kollaborativ mit Ambassadors zusammen. Die endgültige Entscheidung trifft das DS-Team.

4. Ist DS eher ein Regelwerk, das detaillierter und restriktiver sein sollte? Oder eher etwas Offenes und Breiteres, das Designerinnen und Designern die Freiheit gibt, neue Layouts zu erstellen?

Geschlossen oder offen? Wenn man mit Design Systems arbeitet, interessiert einen diese Frage vermutlich. Mich jedenfalls, deshalb habe ich andere dazu befragt.

• Bei "Accessibility" sollte man restriktiver vorgehen

• Wir haben alle mit einer grundlegenden Struktur begonnen, aber dann einige Inkonsistenzen geschaffen. Deshalb haben wir beschlossen, nicht 100 % geschlossen zu sein, aber doch mehr Einschränkungen einzuführen. Gleichzeitig versuchen wir immer, Wege zu finden, den Designerinnen und Designern etwas zurückzugeben

• Es hängt von der Situation ab, also messt zuerst das Risiko und entscheidet dann. Allgemein gilt: kleinere Teams = höhere Flexibilität

• Es geht nicht einfach darum, kreativ zu sein und neue Komponenten zu bauen. Man braucht Komponenten, die flexibel genug sind, um den Bedürfnissen der Menschen gerecht zu werden

• DS ist Business. Je weniger Komponenten, desto besser.

• Die Leute sollten gern mit dem DS arbeiten. Von außen sieht es leicht wie eine Uniform aus, sodass man denkt, Flexibilität sei nicht nötig (ist sie aber doch)

• Man kann nicht von Anfang an sehr restriktiv sein. Mit genügend Zeit kann sich das in bestimmte Muster usw. weiterentwickeln.

• Für Designerinnen und Designer, die neu ins Unternehmen kommen, können mehr Einschränkungen hilfreich sein. Um Regeln zu brechen, muss man mit Regeln anfangen.

• Wir stellen genug Zutaten bereit, damit die Leute ihre eigenen Rezepte machen können.

• Das hängt vom Reifegrad des Teams ab. Wenn es mehr Juniors gibt, fordern sie eher mehr Design-Guidelines, weil sie weniger Dokumentation verstehen. Das erhöht zwar den Schulungsbedarf, aber trotzdem versuchen wir, sie nicht einzusperren, sondern ihnen freies Arbeiten zu ermöglichen. Die größte Herausforderung besteht darin, die Leute dazu zu bringen, die Dokumentation tatsächlich zu lesen und zu verwenden; deshalb kann es sinnvoll sein, sie näher an den Arbeitsplatz der Designer zu bringen, etwa in Figma.

• Wenn es um Accessibility und Ästhetik geht, sollte es restriktiver sein.

• Tokens sind wichtig, um Konsistenz zu wahren.

• Gute Dokumentation findet die Balance zwischen Harmonie mit den Menschen und dem Gewähren von Freiheit.

Frage 5. Was haltet ihr von DS, das mit Branding und Marketing verbunden ist?

(In diesem Bereich kenne ich mich nicht so gut aus, daher war die Übersetzung etwas schwierig.)

Ich verstehe, dass es bei einem Design System letztlich um digitale Produkte gehen sollte, aber weil das Produkt eine der wichtigsten Brand-Plattformen sein kann, war ich neugierig, wie die Leute diese Verbindung sehen.

• Um über Branding im Zusammenhang mit DS nachzudenken, sollte man überlegen, wie es umgekehrt DS beeinflusst.

• Wir haben begonnen, das Design System an die Marke anzupassen, um Look and Feel der Marke anzugleichen.

• DS dient Skalierbarkeit und Brand Identity, aber die Verbindung zwischen beiden hängt vom Branding-Team ab.

• Since DS is a language, MKT could support with assets for it;

• Das Branding-Team sollte von Anfang an zum DS dazustoßen, um die grundlegenden Regeln mitzugestalten.

• Das hängt vom Unternehmen ab. DS ist ein Werkzeug zur Stärkung der Marke, daher ist Alignment wichtig. Die Verbindung zwischen den beiden Bereichen beeinflusst auch die Accessibility des DS.

• Es ist wichtig, Wege zu finden, sich mit dem Branding-Team zu synchronisieren, um die Strategien aufeinander abzustimmen.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• Manchmal lassen sich Dokumentation und System gemeinsam nutzen, meist aber nicht. DS ist das Interface. Das Brand-Team hat meist ein separates "Branding System", und häufiger interagieren die Libraries miteinander. Beides ist nicht vollständig identisch.

Frage 6. Wie kann man den Erfolg von DS messen?

• Wahrnehmungsumfragen, um Beteiligung, Adoption und den Zustand der Teams zu verstehen

• Komponentenabdeckung (wie stark DS genutzt wird vs. was hart codiert ist)

• Adoption

• Time to market

• ROI

• Figma Analytics

• Reaktionen der Entwicklungsteams

• Accessibility

• Anzahl der Verwendungen von Komponenten

[xguru]

Oh, das ist wirklich gut. Danke fürs Zusammenfassen!