Mit einer Design Pattern Library arbeiten

Erzähl doch gerne kurz etwas über dich!

Robert: Danke für die Einladung, finde ich super, dass das geklappt hat! Ich bin Webdesigner, mein Name ist Robert. Ich bin seit einiger Zeit aktiv unter dem Namen „Rooosh Creative Studio”.

Ich kann auf ca. 8-9 Jahre Berufserfahrung zurückgreifen und hatte ursprünglich als Grafikdesigner angefangen, habe mich dann aber schnell in den Bereich Webdesign bewegt und arbeite heute selbstständig als Webdesigner/Webentwickler. Ich komme aus Brandenburg und bediene Kunden aus ganz Deutschland, Schweiz und Österreich.

Jonas: Programmierst du auch Webseiten?

Robert: Ja, genau, ich bin da interdisziplinär unterwegs. Habe mit dem Webdesign angefangen und dann hat es sich ergeben, dass ich Programmiersachen ebenfalls übernommen habe. Alles was den Frontend Bereich betrifft, kann ich anbieten.

Wie bist du zum Thema Pattern Library gekommen?

Robert: Das ist bei mir noch gar nicht so lange ein Thema. Ich habe vor knapp drei Monaten ein Artikel dazu in der Page gelesen und das ganze Thema schlug die Brücke zwischen Design und Development und da mich beides anspricht, hat mich das Thema gleich von Anfang an interessiert.
In der „Page” gab es nur einen dreiseitigen Artikel dazu und nachdem ich mich selbst damit beschäftigt hatte, habe ich festgestellt, dass es zu dem Thema noch nicht viel Lektüre gibt oder Stellen im Netz, wo man mehr darüber nachlesen kann. Deswegen finde ich es sehr spannend, wenn man das Thema nochmal präsenter machen kann. Seit ungefähr 3-4 Monaten interessiere ich mich dafür.

Was kann man sich unter einer Pattern Library vorstellen? Was ist das überhaupt und wofür verwendet man es?

Robert: Dafür ist es wahrscheinlich hilfreich, wenn ich kurz erkläre was ein Pattern an sich ist:

Es gibt eine Definition, die mir gut gefallen hat: Ein Pattern an sich ist ein Element eines Produktes, dass sich für ein bestimmtes Problem ergibt, sodass man das Element in unterschiedlichen Texten und mit unterschiedlichen Inhalten immer verwendbar macht. Ein Element, dass sich sozusagen zu verschiedenen Problemstellungen immer wieder anwenden lässt.

Dabei könnte man das Ganze gleich zum Styleguide abgrenzen. Ein Styleguide ist ja eher so aufgebaut, dass man vor einem Projekt gewisse Design Prinzipien festlegt und daraus die grafischen Grundlagen definiert. Ein Pattern Library ergänzt das Ganze nochmal, beschreibt sozusagen nicht nur das Aussehen von Elementen und Komponenten, sondern beschreibt Verhaltensweisen und Interaktionsregeln. Also hat im Prinzip auch viel mit Usebility und Nutzerverhalten zu tun.

Jonas: Das heißt die Information, die wir aus einem Styleguide kennen und diesen kennen wahrscheinlich die meisten, wenn sie schon mal in einer Agentur gearbeitet haben. Hier gibt es oft Brand Guidelines, an die man sich beim Gestalten halten muss.

Diese Styleguide-Geschichte ist natürlich auch irgendwann vom Print ins Web übertragen worden. Wie also Elemente visuell aussehen sollten oder wie Schriftgrößen und Farben anzuwenden sind. Die Pattern Library erweitert das Ganze dann noch um Elemente, ihr Verhalten und ihre Funktion. Zum Beispiel wenn du über einen Button einen Hover-Effekt legst oder Animationen von Tooltipps, wenn man mit Elementen interagiert.
Sehe ich das grundlegend richtig, dass auch Informationen, die eigentlich in einem Styleguide zusammengefasst werden, auch in der Pattern Library vorhanden sind?

Robert: Es ist eine Ergänzung und ist auf dem Styleguide aufgebaut.
Es hat wie gesagt viel mit Usebility zu tun. Wenn du dir ein Produkt anschaust, haben sich im Laufe der Jahre bestimmte Nutzerverhalten ergeben. Man weiß zum Beispiel, was bei einem bestimmten Button oder einer Bearbeiten-Schaltfläche passiert oder auf welcher Seite sich der Speicherbutton befindet. Ganz grundlegende Sachen eben. Wenn irgendwas nicht funktioniert, freut sich die Serviceabteilung und das gilt es ja eigentlich zu vermeiden. Der User sollte nicht an eine Stelle auf einer Website gelangen, an der er nicht weiter weiß.

Jonas: Ich glaub da sprichst du auch einen guten Punkt an. Gerade im digitalen Bereich ist es sehr wichtig, dass wenn wir ein Userinterface gestalten, auch die Konsistenz mit reingebracht wird.
Also wie du sagst, Schließen-Button ist immer oben rechts oder Speichern unten rechts. Das sind Gewohnheiten, die der User natürlich kennt. Aber genauso kann man auch bei einer Website oder einem Interfacedesign für ein Unternehmen von zum Beispiel einer App, Gewohnheiten beibringen bzw. den Benutzer an die Gestaltung des Designers gewöhnen.

Das Problem ist, wenn wir in Teams oder mit anderen Designern oder Programmierern, nicht konsistent genug arbeiten. Wir rennen häufig in das gleiche Problem, dass wir Elemente wie Input-Felder, Button oder Teaser, wieder und wieder neu erstellen, obwohl es für den gleichen Kunden oder das gleiche Projekt ist. Vielleicht kann sich der ein oder andere da rein versetzen, wenn man zu einem schon vorhandenen Projekt hinzugeholt wird. Es ist schwierig Vorlagen zu bekommen oder sich mit Designern auszutauschen, die davor zwei Jahre dran gearbeitet haben. Mit der Zeit verliert man den Überblick. Vor allem Entwickler und Programmierer sind dann frustriert darüber, da zu viele Wiedersprüche auftreten. Ein Entwickler bekommt vielleicht ein neues Design vorgelegt, dass eigentlich schon mal umgesetzt wurde. So entsteht leicht ein sehr langer Code und das versucht man zu verhindern, indem man mit Pattern Libraries arbeitet. Damit hat man Module, die schon vorgearbeitet sind und an die man sich halten kann. Man muss sich keine Gedanken über einen bestimmten Button machen, da das schon jemand anderes zuvor gemacht hat.

Was mir gut an einer Pattern Library gefällt, ist, dass man damit wieder Konsistenz in das Gestalten rein bringt. Ich hatte mich noch nicht so intensiv damit beschäftigt, aber ich kenne die Probleme, wenn ich an Projekten arbeite.

Probleme, die du mit einer Pattern Library verhindern kannst

Robert: Wir können nochmal auf die Probleme schauen, die oft auftreten, wenn man nicht mit einer Pattern Library arbeitet:

Als erstes die Interaktionen, die dazu geführt haben, dass es teilweise ein schlechtes Verhältnis zwischen Designer und Developer gibt. Die fehlende Synchronisierung, dass man sich nicht entsprechend austauscht. Gerade wenn man lange mit einem Team zusammenarbeitet, das aus mehreren Personen besteht. Oftmals ist es in Agenturen so, dass es mehrere Units gibt. Dann kann es passieren, dass ein Designer aus einem Team vor einem Problem steht und für sich einen Lösungsansatz entwickelt, den er nicht kommuniziert. Einer aus einem anderen Team hat die selbe Problemstellung, entwickelt aber einen ganz anderen Lösungsansatz. Dadurch entstehen durch mangelnde Kommunikation mehrere Lösungsansätze. Das ist die Inkonsistenz, die dann entsteht, bis man gar nicht mehr weiß, welcher Lösungsansatz jetzt für welche Problemlösung die schnellste und beste ist. Da macht man sich doppelte Arbeit, auch ein Punkt, den man mit der Pattern Library am liebsten ausmerzen will.

Ein wichtiger Punkt ist auch, dass Designer und Entwickler oftmals nicht die gleiche Sprache miteinander sprechen. Dies führt zu Missverständnissen, wenn der Developer nicht von Anfang an im Entwicklungsprozess mit drin steckt. Dann wird das Hütchen vom Designer über den Zaun geschmissen und der Developer muss zusehen, wie er das Problem löst. Das führt auch zu einer schlechten Kommunikation und Wildwuchs was man an Codes und Designelementen definiert.

Es ist wichtig, dass man teamübergreifend nicht dauernd nach neuen Lösungsansätzen sucht und sich dadurch permanent mit Entwicklungsprozessen beschäftigt, die an anderer Stelle vielleicht besser aufgehoben wären.

Doppelte Arbeit vermeiden. Das ist der Hintergrund weswegen man in die Richtung von Pattern Library ging.

Wie sieht eine erstellte Pattern Library konkret aus?

Jonas: Wie kann man sich das Ganze aber denn jetzt vorstellen? Ist es wie beim Styleguide, den man es als PDF zugeschickt bekommt oder ist es online auf einer Website?

Robert: Mit der Zeit hat sich das so entwickelt, dass man es häufig online sieht. Meistens ist es eine HTML Syntax. Also einfach eine HTML-Website, woraus man sich die Designelemente zieht und sich zum Beispiel ein Quellcode für einen Button dort hinterlegt.

PDF ergibt sich bei der Pattern Library nicht. In der Regel läuft das alles online ab. Es gibt auch viele Pattern Libraries, die von Agenturen öffentlich freigestellt werden (findest du weiter unten). Die kann man sich gerne mal angucken.

Wenn es darum geht die Elemente zu kategorisieren, gibt es unterschiedliche Ansätze. Es gibt Projektteams, die Elemente nach ihrer Form kategorisieren, damit man ein System kreiert. Dann gibts Agenturen, die die Elemente eher nach Funktion und Zweck ordnen. Das steht jedem frei.

Jonas: Auch ein Vorteil, wenn eine Pattern Library online stattfindet: Man vermeidet das Synchronisierungsproblem. Wenn man zu einem Projekt dazu kommt und man sich von irgendeinem Server Sachen ziehen muss. Es ist leider nicht Standard, dass einfach alle mit Cloudservices arbeiten, daher kann es vorkommen, das bestimmte Sachen erst wieder per Mail geschickt werden müssen und man nicht den Zugriff auf alle möglichen Ordner hat und das kann man damit ausschließen. Wenn das Ganze online stattfindet, ist es jedem zugänglich, jeder Designer und jeder Entwickler kann sich dort schon vorgefertigte Dinge anschauen und den Code ansehen. Das ist definitiv ein Vorteil, gegenüber eines Styleguides als PDF.

Wer pflegt und wartet eine Pattern Library?

Robert: Wenn eine Pattern Library erstellt wurde, geht es auch darum diese zu warten und zu pflegen. Wenn man von vornherein schon weiß, dass man keine Zeit oder Ressourcen dafür hat, ist es schwierig sie in Erwägung zu ziehen. Nichts ist ungünstiger als eine unübersichtliche, nicht aktuelle Pattern Library.

Gerade in Bezug auf Wartung und Pflege gibt es unterschiedliche Ansätze. Sie muss auf jeden Fall aktuell bleiben. Dabei muss auch berücksichtigt werden, dass Design oftmals destruktiv ist. Design hat viel mit Zeitgeist zu tun, da ändert sich oft was. Aber auch wenn man auf Technologie schaut, wird sich permanent etwas ändern und es bedarf deswegen einer Aktualität.

Es gibt aber auch Ansätze, dass man nicht zu viel in die Pattern Library reinbuttert. Eine Pattern Library ist ursprünglich so geplant, dass sie übersichtlich, leicht bedienbar und relativ schlank bleiben soll. Das wäre der Optimalfall. Es kann aber auf Grund der Wartung und Pflege passieren, dass zu viele Pattern erstellt werden und dadurch wird es unübersichtlich.

Es gibt den Ansatz, dass man das Ganze mit einem explizit dafür eingesetzten Pattern Team durchführt. Dieses Team kümmert sich dann darum, dass die Pattern Library sauber und übersichtlich bleibt.

Eine weitere Möglichkeit wäre, dass die Teams sich ohne eine zwischengeschobene Gruppe an der Pattern Library bedienen und Pattern einfügen und verbessern. Ähnlich wie bei Github und den Repository. Wo man jederzeit drauf zugreifen und verbessern kann. Aber Repository ist jetzt schon wieder ein spezielles Thema. Aber so ähnlich kann man sich das vorstellen.

Ab welcher Projektgrößenordnung macht es Sinn eine Pattern Library anzulegen?

Robert: Ich würde den Tipp geben, dass man die Pattern Library auch schon bei kleineren Projekten oder Teams erstellt. Einzige Bedingung, die ich sehe, ist, dass man mit mindestens zwei Teams arbeitet. Weniger würde keinen Sinn machen, da man es ja sonst teamintern bearbeiten könnte. Dafür braucht man keine Library. Auch kleine Agenturen können damit arbeiten. Aber umso größer das Team oder das Projekt umso größer auch die Pattern Library.

Den Hintergedanken und die Vorteile einer Pattern Library auf dein Layout übertragen

Effizienter und konsistenter arbeiten und Prozesse beschleunigen

Jonas: Wenn man sich nochmal die Voreile der Pattern Library vor Augen hält und für was man sie überhaupt erstellt, kann man das auch gut auf kleine Website Projekte übertragen. Zum Beispiel: man erstellt sich eine Bibliothek damit der Design Prozess beschleunigt werden kann und man selbst effizienter gestaltet. Dadurch kann man auf lange Sicht Zeit spart.

Oder wenn man konsistent arbeitet und immer wieder gleiche Styles verwendet. Das ist auch möglich wenn ich allein eine Website mit Sketch erstelle. Da gestalte ich mir auch Templates und Vorlagen, die ich immer wieder verwenden kann. Das ist am Anfang vielleicht ein bisschen mehr Arbeit, aber am Ende spart es dir Zeit. Und das ist auch der Gedanke bei einer Pattern Library. Das man einen Weg findet effizienter, konsistenter zu arbeiten und dass man Prozesse beschleunigen kann. Ich glaube, da kann man auch klein anfangen. Auch wenn ich für mich allein eine Bibliothek erstelle, von der ich immer wieder etwas verwenden kann.

Wenn man Pattern Libraries im Internet sieht, sind sie immer wieder von ziemlich großen Unternehmen veranschaulicht, die natürlich auch das Budget und die Zeit zur Verfügung haben, das ganze von Teams erstellen zu lassen. Aber es macht auch bei kleineren Projekten wirklich Sinn.

Robert: Wie du schon sagst, geht es ja bei der Pattern Library um Wiederverwendbarkeit und Zeitersparnis. Aber auf Grund dieser Wiederverwendbarkeit erstellst du die Library ja nicht für jedes Projekt neu. Man erstellt sie unabhängig von irgendwelchen Projekten. Du bekommst dadurch Elemente und Codes, die immer wieder für verschiedene Problemstellungen innerhalb eines Unternehmens verwendet werden können. Klar, man fängt klein an.

Wenn man in einer Agentur oder in einem Unternehmen nicht für sich alleine arbeitet, sondern auch für andere Entscheidungsträger oder Stakeholder, muss man auch eine gewisse Akzeptanz erreichen. Man muss Leuten erklären: „wir möchten mit einer Pattern Library das und das erreichen”. Kostet im schlimmsten Fall viel Zeit und Ressourcen. Dann muss man den Leuten klar machen wofür man das alles macht und das es auch gewisse Vorteile bringt.

Der Aufbau einer Pattern Library selber fängt klein an und je nachdem welche Projekte du damit umsetzt, gilt es gerade am Anfang viel zu testen und viel zu proben. Das Ziel ist ja, etwas ohne es nochmal zu testen oder nachzuschauen, problemlos einzusetzen. Deshalb ist es am Anfang wichtig, das man es step by step macht und nicht zu viel auf einmal.

Schränkt eine Pattern Library die Kreativität eines Designers ein?

Jonas: Wenn ich mich an meine Agenturzeit zurück erinnere, musste ich ziemlich häufig strikt nach einem Styleguide arbeiten. Dadurch sollte verhindert werden, dass so einfache Dinge wie eine Werbe-Anzeige immer wieder unterschiedlich aussieht, da der Widererkennungswert sehr wichtig ist. Ich weiß, dass der Styleguide damals zwei Jahre alt war und man hätte es oft zeitgemäßer darstellen können. Glaubst du, dass man mit Pattern Libraries auch in die Gefahr kommt und Dinge nicht up to date halten kann?

Robert: Ein Problem ist, das man schnell zu dem Entschluss kommen kann, dass eine Pattern Library die Kreativität eingrenzt. Oder man geht nicht mit der Zeit, sondern hat sie einmal erstellt und dann kann es schnell passieren, das man zwei bis drei Jahre hinterher hängt oder sagt: „ist nicht mehr ganz aktuell, was machen wir denn jetzt?” Das ist wieder ein Thema der Wartung und Pflege. Da muss man unbedingt mit ein bisschen Übung eine gute Balance finden. Auf der einen Seite, dürfen Patterns, da sie erprobt und getestet sind, nicht allzu schnell ausgetauscht werden. Es spricht aber auch nichts dagegen, wenn man ältere Patterns in Frage stellt oder modifiziert.

Gerade wenn man eine Pattern Library hat, sollte man so viel Beteiligte wie möglich ins Boot holen und zwischen Designer, Developer, Stakeholder, QA Experten kommunizieren. Es darf nicht passieren, dass einer nicht weiß, was der Designer oder Entwcikler jetzt meint. Sie müssen alle die gleiche Sprache sprechen. Deswegen muss man am Anfang versuchen, alle Beteiligte ins Boot zu holen. Das funktioniert allerdings nicht immer. Aber um die Aktualität zu erhalten, spricht nichts dagegen bei der Wartung und Pflege neue Technologien aufzugreifen und neue Designelemente hinzuzufügen. Alles was sich bewährt, landet in der Pattern Library.

Jonas: Aus der Designperspektive betrachtet: Auch wenn man meint, visuell gesehen, könnte ein Element ein Facelift vertragen, bleibt das gelöste Problem dahinter ja bestehen. Die Lösung bzw. der Aufbau bleibt also der gleiche. Zum Beispiel ein Schließen Button ist immer oben rechts. Damit hat sich jemand im Team beschäftigt und beschlossen, dass das für ein bestimmtes Layout an dieser Stelle am meisten Sinn macht. Und das muss man nicht noch mal überarbeiten. Diese Zeit kann man sich sparen. Die Gedanken sollte man stattdessen in neue Probleme investieren. Da könnte man sagen: „visuell gesehen ist es veraltet, aber die Usebility und wie man es bedienen kann, ist trotzdem sehr gut”. Es geht ja auch nicht nur um Farben, Schriften und Elementgrößen, sondern auch um Inhalte oder um Länge und Position von Texten. Es sind viele Komponenten, die da mit einfließen.

Halten wir also fest: Nicht jedes bereits gelöste Problem muss erneut gelöst werden und dank der Auswahl an Patterns lassen sich viel schneller Prototypen erschaffen und testen. Beides verschafft einem Zeit, sich auf die wirklich neuen Probleme zu konzentrieren oder um sich um Feinschliff und Details kümmern.

Ab welchem Zeitpunk sollte eine Pattern Library erstellt werden? Mitten im Projekt oder eher erst am Ende so wie man es von einem Styleguide kennt?

Robert: Ich glaube, das kommt viel auf Erfahrungswerte an. Du erstellst eine Pattern Library für dich, als wiederkehrende Problemlösung und da ist es völlig egal für welches Projekt du das machst. Du konzentrierst dich auf wiederkehrende Elemente oder Problemstellungen. Darauf arbeitest du hin. Ich würde eine Pattern Library projektunabhängig und immer wieder fortlaufend erstellen bzw. daran arbeiten.

Jonas: Ich denke, man sollte die Library nebenher aufbauen. Wenn du zum Beispiel ein Dialogfeld hast und es kommt im Projekt immer wieder vor, kannst du es direkt von Anfang an festlegen und dann wieder einsetzen. Dadurch musst du dir im nachhinein nicht nochmal die ganze Arbeite machen.

Robert: Patterns selber können im Prinzip viele Elemente sein.

• Welche Interaktionsregeln legen wir fest?
• Wie muss der Übergang aussehen oder wie muss eine Animation ablaufen?
• Wie werden Buttons in welche Größe oder Aussehen benannt?

Das kann bei allen möglichen Elementen sehr spannend sein. Gerade auch bei der Dateibenennung. Da kann unheimlich viel Zeit drauf gehen. Gerade wenn man an verschiedenen Projekten arbeitet, muss man auf viel Erfahrung setzen, damit man weiß, welche Namen in bestimmten Situationen nicht funktionieren. Manches ist nicht leicht skalierbar oder einfach nicht wiedervernwendbar.

Von wem wird eine Pattern Library erstellt? Designer, Entwickler oder beide zusammen?

Robert: Das kann unterschiedlich sein. In der Regel von Designern und Entwicklern zusammen. Aber es gibt auch andere Stakeholder, die da Entscheidungsträger sind, was ein Pattern ist, was ein Pattern sein soll und wie es beschrieben werden sollte.

Ich kenne ein gutes Beispiel von Wolf Brüning. Er ist Interface Designer bei OTTO und hat das anhand von einer Artikelreihe ganz gut beschrieben. Da ging es darum, dass OTTO 2011 eine komplett neue E-Commerce Plattform aufgemacht hat und er damit beauftragt wurde, die Pattern Library zu erstellen mit 2/3 Kollegen zusammen. Er selber ist Designer, die Kollegen waren ebenfalls Designer und Entwickler und haben das dann gemeinsam aufgezogen. Wer das macht, muss man nicht konkret benennen. Das kann unterschiedlich sein. Von Designern, Entwicklern, Projektmanagern, irgendwelchen Beratern…

Jonas: Ich hab ein paar Beispiele, für jeden, den es interessiert und der gerne mal wissen möchte, wie das konkret aussehen kann. Ich hab von Mailchimp was ganz cooles gefunden, Google material Design haben wahrscheinlich auch schon einige gesehen, da gibts auch eine Art Pattern Library und AirBnb und Salesforce. Die haben alle gute Online Dokumentationen, wie sie Elemente gestalten, aufbauen, wie Farbe und Schriften zusammengefasst sind, wie auch Animationen sein sollten oder wie Tooltipps aussehen und eben interaktive Elemente.

Du arbeitest auch als Programmierer, gibt es dafür Vorlagen oder Templates, um Pattern Library schneller zu erstellen?

Robert: Es gibt nichts Spezielles, man hat da eigentlich freie Hand. Grundsätzlich sollte man sich aber schon an diesen Beispielen orientieren, gerade was Online Plattformen betrifft. Generell würde ich so eine Art Wiki aufziehen. Ich weiß bei Otto haben sie damals direkt ein eigenes CMS dafür erstellt, wenn man das Budget hat, dann gerne. Aber wenn man kleinere Teams hat oder ein kleineres Budget, dann einfach auf ganz normale Online Tools zurückgreifen. Da gibts ja so Unmengen an Auswahl. Ich kenne jetzt auch kein Beispiel bei dem ich sage, das ist jetzt prädestiniert dafür.

Jonas: Ich denke das Wichtige ist, dass es gut strukturiert wird und man es gut durchsuchen kann. Vielleicht gibt es aber auch gar nicht so viele Inhalte und man kann die Navigation schon in eine Sidebar packen, damit Bereiche schnell erreichbar sind. Das schafft eine gute Übersicht und man weiß sofort wo was liegt.

Fazit und kurze Zusammenfassung Pattern Library

Robert: Die Pattern Library hat 2 Ziele: Kosten senken und Zeitersparnis.

Wozu mache ich eine Pattern Library?

Einfach um wiederkehrende Problemstellungen zu lösen und das relativ schnell. Wenn ich Elemente zügig umsetzen kann, habe ich logischerweise mehr Zeit, um mich elementareren Sachen zuzuwenden. Zeit um individuelle Lösungen für das Projekt zu erarbeiten.

Du hast auf der anderen Seite auch automatisch eine viel bessere User Experience. Du kannst schneller Prototypen entwickeln. Schneller MPP´s erstellen und das lässt dir Zeit und Raum um einfacher Verbesserungen immer wieder vornehmen zu können.

Eine klare und effiziente Kommunikation zwischen allen Beteiligten sollte nicht unterschätzt werden. Du verbesserst dadurch automatisch den Code und verhinderst Coderesodanzen.

Zudem sorgt eine gut erstellte Pattern Library dafür, dass es nicht unübersichtlich wird, das kein Wildwuchs entsteht, indem was man an Möglichkeiten hat, um zu einer Lösung zu gelangen.

Zudem entfällt eine große Einarbeitung von neuen Teammitgliedern. Die Möglichkeit sollte gegeben sein, das er sich recht schnell und ohne große QA Runden zurechtfindet.

Jonas: Sehr gut. Das ist natürlich ein wahnsinnig umfangreiches Thema, da könnte man noch weiter ins Detail gehen. Aber ich glaube, jetzt haben wir einen guten Einblick bekommen.

—

Danke an Robert von Rooosh Creative Studio für das Gespräch! Du findest ihn auch auf Facebook oder Behance.

—

Patter Library Beispiele:

• Marvel: Gut strukturiert, übersichtlich gestaltet
• Slesforce: Sehr umfangreich, interessanter Aufbau
• Fontshop: Sehr umfassend, ansprechend gestaltet, könnte übersichtlicher sein
• Futurelearn: Angelehnt an Atomic Design, stylish aber etwas unübersichtlich
• Lonely Planet
• Google Material Design
• Mailchimp

Weiterführende Links:

• Artikel-Reihe von Wolf Brüning (Otto Group): Auch die Kommentare sind interessant, leider ist die Reihe nicht komplett; er überlegt aktuell, sie eventuell neu aufzusetzen.
• Bezüglich Wartung und Pflege: Wie man Verantwortung und Code für Patterns im Unternehmen verteilt
• Pflege und Design von Pattern Libraries: Ergänzend eine Zusammenfassung aus der Sicht eines Senior UX Designer
• Unterschied Pattern Library vs. Styleguide: Inkl. Beispiel-Angaben
• 14 Dinge, die du tun solltest, wenn du eine Pattern Library baust:: Inkl. Beispiel Library
• Let’s Talk Design Patterns Video