Pattern Libraries sitzen genau an der Schnittstelle von Kreativen, Entwicklern und Informationsarchitekten und geben allen Beteiligten eine gemeinsame Plattform. Als zentrale Referenz stellen Sie verbindliche Informationen über die Struktur und das Styling aller verwendeten Elemente zu Verfügung.

1. Pattern Libraries
design systems exchange | dsx #2
Eine Schnittstelle zwischen
User Interface Design und
Development
Titelbild © Nathan Sawaya www.brickartist.com

2. Wir helfen Unternehmen zu
erkennen, was Menschen
bewegt − und sich damit die
digitale Zukunft zu
erschließen.
die firma . experience design – Unsere Mission
www.diefirma.de

3. Customer / User Insights
Brand Storytelling
Content Marketing Strategy
User Experience / Service Design
Digital Transformation / Business
Models
Digital Prototypes / Web Design
die firma . experience design – Was wir tun

4. 1. Terminologie
2. Warum
3. Werkzeuge
4. Best Practice vs. Worst Practice
4

5. Terminologie

6. • (Living) Styleguide
• Pattern Library
• Component Library
• Design System
6

7. Ein Styleguide ist ein statisches und
abgeschlossenes Dokument, welches … vornehmlich
Aspekte des Visual Designs definiert. Der Styleguide
ist damit eng verwand mit dem Corporate Design
Manual … in der Regel detaillierter und auf ein oder
mehrere spezielle Produkte fokussiert.
Quelle: https://www.produktbezogen.de/bauanleitung-pattern-library-1/

8. Ein Living Styleguide enthält die gleichen Elemente
wie ein Styleguide. Er ist aber ein dynamisches
Dokument, welches sich analog zum Produkt
weiterentwickelt und ggf. sogar direkt aus dem
Produktcode generiert wird. Der Fokus ist in der Regel
weiterhin auf das Visual Design, die Grenzen zu einer
Pattern Library sind aber fließend.
Quelle: https://www.produktbezogen.de/bauanleitung-pattern-library-1/

9. Eine Pattern Library ist ein dynamisches Verzeichnis
von Interaktions-Patterns, Styles und ggf. Code-
Snippets mit direktem Produktbezug. Die Inhalte
verändern sich analog zur Evolution des Produkts und
sind im Idealfall direkt in der Library erlebbar. Der
richtige Einsatz der Patterns wird über fachliche und
technische Dokumentation sichergestellt.
Quelle: https://www.produktbezogen.de/bauanleitung-pattern-library-1/

10. Ebenfalls nah an der Pattern Library ist
die Component Library. Oft wird der Begriff
Synonym verwendet, … zur Abgrenzung kann die
Component Library als „grobe“ Pattern-Library
gesehen werden. Sie dokumentiert keine Atome oder
Fragmente sondern nur in sich geschlossene
Funktions- und Inhaltsblöcke aus denen dann Seiten
oder Screens zusammengesetzt werden.
Quelle: https://www.produktbezogen.de/bauanleitung-pattern-library-1/

11. Design Systeme helfen dabei mehrere Produkte auf
mehreren Plattformen (auch nicht-digitalen) zu
harmonisieren und gleichzeitig Alignment innerhalb
von großen und ggf. verteilten Design-Organisationen
herzustellen. Sie bestehen aus einer oder mehrere
Pattern Libraries ergänzt durch Design Prinzipien,
Guidelines, Entscheidungsbäume, Prozesse, Vorlagen
und vielem mehr.
Quelle: https://www.produktbezogen.de/bauanleitung-pattern-library-1/

12. Hierarchie der Begriffe
12
Design System
Pattern
Library
Living
Styleguide
Component
Library

13. Soweit die Theorie

14. Pattern Library =
Living Styleguide?
🤔
In the wild…

15. 15

17. Warum sind Pattern Libraries so wertvoll für uns?
1. Gemeinsame Sprache
2. Single Source Of Truth
3. Vermeidung von Redundanzen
4. Unsicherheit reduzieren
5. Überblick schaffen
17

18. Gemeinsame Sprache

19. Was sieht man hier?
19

20. Und hier?
20

21. Missverständnisse kosten Zeit und Nerven
Quelle: https://www.jpattonassociates.com/user-story-mapping/

22. Eine Pattern Library ist eine
eindeutige Dokumentation
aller Elemente des User
Interface.
Gemeinsame Sprache finden
22

23. Unsicherheit
reduzieren

24. Projektordner aus der Hölle
24

25. Single Source Of Truth

26. Pattern Libraries erfordern Prozesse
26
Visual
Design
Pattern
Library
CMS

27. Redundanzen
vermeiden

28. Was ist hier passiert?
28

29. Kontrollierte Farbpalette in einer Pattern Library
29

30. Wiederverwendbare Komponenten durch Atomic Design
30
Quelle: http://bradfrost.com/blog/post/atomic-web-design

31. Unsicherheit
reduzieren

32. Unsicherheit: was ist der letzte Stand? à Status der Komponente
Quelle: https://fractal.build/guide/core-concepts/statuses.html#custom-statuses

33. Sicherheit durch Versionierung
33

34. Überblick Verschaffen

35. Atomic Design in der Praxis: Referenzierung und Suche

36. Werkzeuge

37. Werkzeuge: Visual Design
Sketch InVision Zeplin
Layout Übergabe

38. …and many more

39. - Initiiert von Brad Frost (Atomic Design)
- Open Source
- Patterns werden in HTML, CSS und JS
dokumentiert
- verschiedene Template Engines
(Mustache, Twig, Handlebars, Underscore)
- Erweiterbar nach eigenen Bedürfnissen
Werkzeuge: Pattern Libraries
39
- Initiiert von Clearleft
- Open Source
- Patterns werden in HTML, CSS und JS
dokumentiert
- Verschiedene Template Engines
(Handlebars, Mustache, Nunchucks)
- Erweiterbar nach eigenen Bedürfnissen

41. Fractal & Patternlab: zwei Geschmacksrichtungen bei vergleichbarer Funktionalität
41

42. Best Practices

43. klein
allgemein
einfach
Bei der Überführung von Visual Designs in die Pattern Library bewegen wir uns von…
43
groß
speziell
komplex

44. 44
• Wir bauen atomare Komponenten so, dass sie
eigenständig funktionieren
• Danach fügen wir die Atome in molekularen
Komponenten zusammen
• Daraus werden funktional eigenständige
Module konstruiert
• Diese werden in übergeordneten Seiten
platziert
Von klein nach groß

45. 45
• Startpunkt sollten allgemeine Dinge wie Grid,
Header/Footer sein
• Danach kommen Artikel oder Blog-Seiten
• Von dort aus bewegen wir uns zu spezielleren
Seiten (Produkt, Event, Download, …) die
unter Umständen besondere Elemente
benötigen
Von allgemein zu speziell

46. 46
• Wenn wir uns zunächst mit den vermeintlich
einfachen Patterns zu beschäftigen
vermeiden wir es, uns zu früh mit Ausnahmen
zu beschäftigen
Von einfach zu komplex

47. Nicht zu viel Vorlauf
für Design

48. Coding Guidelines

49. Coding Guidelines und Namenskonventionen: beispielsweise BEM
Block: .search-results {}
Element: .search-results__item {}
Modifier: .search-results__item--download {}

50. Regelmäßiger
interdisziplinärer
Austausch

51. Eine Person hat den Hut auf
DesignOps

52. Worst Practices

53. Overengineering

55. Quelle: http://atomicdesign.bradfrost.com/chapter-5/
In einer perfekten Welt sieht unser
Prozess so aus.
Aber ist das ein realistisches Ziel?

56. Undead Styleguide

57. Fazit

58. Pro
• Vermeidung von
Redundanzen
• Single Source Of Truth
• Skalierfähigkeit
• Zeitersparnis beim
Deployment von Änderungen
• Gute Schnittstelle zwischen
Design und Development
Contra
• Initial etwas größerer
Zeitaufwand
• Neue Rolle für Pflege der
Pattern Library benötigt
(DesignOps?)
• Stärkere Restriktionen für
Visual Designer

59. Eure Frage?

60. Linkliste
• Ein Artikel von mir zum Thema
• Patternlab: patternlab.io
• Fractal: fractal.build
• Fractal Beispiel: innoq.style
• BEM: getbem.com/naming/
• adele.uxpin.com (Design Systems Repository)
• styleguides.io (Style Guide Resources)
• www.brickartist.com (Titelbild © Nathan Sawaya)
60

61. Thank you!
Matthias Feit
Senior UX + Strategy Consultant
m.feit@diefirma.de
@matthiasfeit
die firma . experience design
Schwalbacher Straße 78 D-65183 Wiesbaden
Tel +49 611 238 50 10
www.diefirma.de
The content of this presentation is
confidential. It must not be shared in part or in
whole with any third parties.