Anzeige
Anzeige

Más contenido relacionado

Presentaciones para ti(20)

Similar a Pattern Libraries als Schnittstelle zwischen Design & Development(20)

Anzeige

Último(20)

Anzeige

Pattern Libraries als Schnittstelle zwischen Design & Development

  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
  16. 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
  17. Gemeinsame Sprache
  18. Was sieht man hier? 19
  19. Und hier? 20
  20. Missverständnisse kosten Zeit und Nerven Quelle: https://www.jpattonassociates.com/user-story-mapping/
  21. Eine Pattern Library ist eine eindeutige Dokumentation aller Elemente des User Interface. Gemeinsame Sprache finden 22
  22. Unsicherheit reduzieren
  23. Projektordner aus der Hölle 24
  24. Single Source Of Truth
  25. Pattern Libraries erfordern Prozesse 26 Visual Design Pattern Library CMS
  26. Redundanzen vermeiden
  27. Was ist hier passiert? 28
  28. Kontrollierte Farbpalette in einer Pattern Library 29
  29. Wiederverwendbare Komponenten durch Atomic Design 30 Quelle: http://bradfrost.com/blog/post/atomic-web-design
  30. Unsicherheit reduzieren
  31. Unsicherheit: was ist der letzte Stand? à Status der Komponente Quelle: https://fractal.build/guide/core-concepts/statuses.html#custom-statuses
  32. Sicherheit durch Versionierung 33
  33. Überblick Verschaffen
  34. Atomic Design in der Praxis: Referenzierung und Suche
  35. Werkzeuge
  36. Werkzeuge: Visual Design Sketch InVision Zeplin Layout Übergabe
  37. …and many more
  38. - 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
  39. Fractal & Patternlab: zwei Geschmacksrichtungen bei vergleichbarer Funktionalität 41
  40. Best Practices
  41. klein allgemein einfach Bei der Überführung von Visual Designs in die Pattern Library bewegen wir uns von… 43 groß speziell komplex
  42. 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ß
  43. 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
  44. 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
  45. Nicht zu viel Vorlauf für Design
  46. Coding Guidelines
  47. Coding Guidelines und Namenskonventionen: beispielsweise BEM Block: .search-results {} Element: .search-results__item {} Modifier: .search-results__item--download {}
  48. Regelmäßiger interdisziplinärer Austausch
  49. Eine Person hat den Hut auf DesignOps
  50. Worst Practices
  51. Overengineering
  52. Quelle: http://atomicdesign.bradfrost.com/chapter-5/ In einer perfekten Welt sieht unser Prozess so aus. Aber ist das ein realistisches Ziel?
  53. Undead Styleguide
  54. Fazit
  55. 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
  56. Eure Frage?
  57. 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
  58. 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.
Anzeige