Es gibt eine große Anzahl von Artikeln , die zeigen, wie Designer Nein sagen können . Hier geht es hauptsächlich um Freiberufler und den Umgang mit schwierigen Kunden. Außerdem gibt es Artikel mit Tipps zum Umgang mit Produktmanagern. Aber was ist, wenn Sie ein Designsystem unterstützen? Was tun mit widersprüchlichen Anfragen von anderen Designern oder Entwicklern?

Ich weiß noch nicht was ich mache…

Wenn Sie kein Experte sind und gerade erst anfangen, ein Designsystem für Ihr Unternehmen von Grund auf neu zu erstellen, wissen Sie vielleicht nicht, in welche Richtung Sie gehen sollen. Sie können natürlich mehrere Artikel mit Rezepten zum Thema „ Wie fange ich an“ lesen , aber manchmal gibt es nichts Besseres als persönliche Erfahrungen. Etwas ausprobieren, manchmal Fehler machen und aus Fehlern lernen. Offen sein für Neues. Seien Sie eine „Ja, lass es uns versuchen“-Person.

In einer solchen Situation muss man so flexibel wie möglich sein. Dokumentieren Sie Ihre Entscheidungen jedoch, wenn Sie nicht möchten, dass erfolgreiche Entscheidungen „schwarze Magie“ und erfolglose Entscheidungen ein unbekannter Zufall bleiben.

Damit meine ich nicht nur die Entscheidung selbst aufzuschreiben, sondern wie Sie (oder andere) dorthin gelangen. Argumente usw. Ja, das kann manchmal schwierig sein. Vor allem, wenn die Entscheidung intuitiv war (Bauchgefühl). Wenn Sie jedoch lernen, sich selbst und andere zu hinterfragen, können Sie schließlich beginnen, die Quelle der Idee zu verstehen.

Eine solche Dokumentation ermöglicht es Ihnen, Ursache-Wirkungs-Beziehungen besser zu verstehen und zu erfahren, was funktioniert und was nicht. Und wenn Sie das nächste Mal sehen, dass ein neuer Vorschlag in ein bekanntes Muster passt (oder in die gleiche Richtung geht), können Sie andere darauf hinweisen. Das heißt, Sie lernen, begründete Gründe gegen riskante Lösungen anzuführen.

Ich habe das schon mal irgendwo gesehen…

Du kannst die Community immer nach Beispielen fragen, wenn es um schlechte Entscheidungen geht . Designer (und viele andere Berufe) erstellen gerne Listen mit Dingen, die man nicht tun sollte .

Es gibt einen großen Querschnitt an Artikeln in der Kategorie „ 10 Worst Design Decisions “ und dergleichen. Was Designsysteme betrifft, werden die Beschreibungen von „guten/schlechten“ Praktiken, „Patterns“, „Do's & Don'ts“ usw. am wichtigsten sein. Und es ist am besten, in der Dokumentation offener Designsysteme danach zu suchen.

Oft liefern solche Dokumente knappe, aber prägnante Argumente für oder gegen eine bestimmte Lösung, und sie können bei der Analyse von Situationen, die in Ihrem System auftreten, sehr hilfreich sein. Und auch in Ihrer täglichen Designarbeit.

„Do & Don'ts“ sind ein Schlüsselelement jeder Dokumentation zum Systemdesign, und je früher Sie damit beginnen, „gute/schlechte“ Praktiken für Ihr System zu dokumentieren, desto mehr Fragen und Missverständnisse können Sie vermeiden.

„ Was nicht dokumentiert ist, existiert nicht “

Die Dokumentation ist eine Verpflichtung. Aber auch Hinweise „was kann/sollte ich tun“. Schließlich treffen Designer oft fragwürdige Entscheidungen, weil sie nicht wissen, was innerhalb des Designsystems getan werden sollte und was nicht. In seiner Abwesenheit ist die Aussage „alles ist möglich“ ein vernünftiger Gedanke.

Aber hier gilt es zu betonen: Bei der Dokumentation geht es nicht um Verbote. Die Dokumentation soll erklären, wie das System funktioniert, und angemessen angeben, was es wert ist, getan zu werden und was nicht. Wenn der Designer (oder Entwickler) also nur von „So gefällt es“ getrieben wird und es der Dokumentation widerspricht, haben Sie einen vernünftigen und berechtigten Grund, dies abzulehnen, indem Sie sich auf die Dokumentation beziehen.

Dokumentation hilft, anderen ein gutes Beispiel zu geben, um ihre Ideen zu argumentieren. Und verwandeln Sie Ideen in Lösungen, die Ihnen helfen, Ihr Designsystem auf die nächste Stufe zu heben.

Designbibliothek ≠ Designsystem

Häufig treten Probleme auf, wenn Benutzer (oder Mitwirkende) nicht verstehen, was ein Designsystem ist, und es als Designbibliothek betrachten. Viele Designer sind es gewohnt, mit Standard-Designbibliotheken umzugehen und sie an ihre Bedürfnisse anpassen zu müssen.

„Ich mag dieses UI-Kit, aber es wurde ohne Rücksicht auf meine Anwendungsfälle erstellt und muss daher angepasst werden.“ Klingt ziemlich vernünftig, oder? Ja, wenn es sich um Lösungen von Drittanbietern handelt, von denen Sie (oder jemand anderes) nur einen kleinen Teil nutzen werden. Bei einem hausinternen Designsystem kann dies jedoch zu Chaos führen.

Etwas ähnliches, aber ein bisschen anders….

Meiner Meinung nach ist es am schwierigsten, wenn Benutzer kleine Änderungen wünschen. Ganz kleine Änderungen:

• Fügen Sie die Möglichkeit hinzu, Symbole in Kopfzeilen zu verwenden.
• Ändern Sie die Reihenfolge der Blöcke in der Liste.
• 3 Schaltflächen statt 2 anzeigen (definiert durch eine Komponente).

• Konsistenz des Ansatzes mit anderen Komponenten.
• Die Komplexität der Implementierung in Code- und Designkomponenten (Figma, Sketch usw.).

Zuerst müssen Sie herausfinden, ob sich das Muster mit einer anderen Komponente schneidet. Dazu müssen Sie entweder alle Komponenten und ihr Verhalten auswendig kennen oder jede von ihnen durchgehen und prüfen, ob der Vorschlag mit einer der anderen Komponenten in Konflikt steht. Bei geringsten Konflikten muss der Vorschlag nicht isoliert, sondern im Kontext des Verhaltens mehrerer Komponenten diskutiert werden. Dazu kann es oft erforderlich sein, mehr Personen in die Diskussion einzuladen.

Die Komplexität der Umsetzung

Was im Design nach einer einfachen Lösung aussieht, kann oft einen enormen Aufwand in der Entwicklung erfordern. Vielleicht, weil die aktuelle Architektur nicht flexibel genug ist. Vielleicht verstößt es einfach gegen die grundlegenden Standards/Ansätze, die in der Entwicklung verwendet werden. Theoretisch ist fast alles möglich, aber einige Dinge erfordern mehr Aufwand. In einer solchen Situation müssen Sie möglicherweise verstehen, wie wichtig diese Änderungen sind: „Nice to have“ oder „kritische Bedürfnisse“.

Wir sind Diener, keine Diktatoren

Das Designsystem ist ein Produkt . Aber es ist eine sehr spezifische. Während der Erfolg der meisten Produkte daran gemessen werden kann, wie viel Geld sie verdienen, ist der Hauptindikator für ein Designsystem, wie viele Benutzer es verwenden und wie sehr es ihnen das Leben erleichtert. Mit anderen Worten, ein Designsystem ist „das ehrlichste Produkt“ . Und das bringt viel Verantwortung mit sich. Wir müssen nicht nur das Beste aus den Wünschen der Kunden machen, sondern ihnen auch helfen, die Konsequenzen jeder fragwürdigen Entscheidung zu verstehen:

• ein Mangel an Flexibilität in der Aussicht
• Verzögerungen bei der Lösungsentwicklung (aufgrund der Komplexität der Lösung und ihrer Wartung)
• die Notwendigkeit, Änderungen an anderen Komponenten oder Vereinbarungen zu kaskadieren
Stewarding Design System Beiträge

Letztendlich geht es beim Designsystem um die Benutzer (Designer und Entwickler). Sie müssen also sehr aufmerksam auf sie sein. Denn ohne sie sind wir niemand. Und wenn die Bearbeitungen vernünftig sind und nichts kaputt machen – warum nicht?

Bei allen Gründen, „nein“ zu sagen, geht es nur darum, sicherzustellen, dass wir das Produkt entwickeln, das die Benutzer brauchen, und nicht das, was sie wollen.

Auf die Frage nach dem Input der Kunden bei der Entwicklung des Ford Model T sagte Henry Ford bekanntermaßen: „Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“

Danke fürs Lesen! Lass uns in Verbindung bleiben! Verbinden Sie sich mit mir auf LinkedIn und folgen Sie mir auf Dribbble und hier auf Medium , um weitere designbezogene Inhalte zu erhalten.