UI engineering Podcast

Michael Geers treibt seit mehreren Jahren das Thema Micro Frontends mit an. Wir unterhalten uns mit Michael darüber, wie Design Systeme und Pattern Libraries auch bei den nicht-technischen Herausforderungen in diesem Bereich helfen können. Das Interview wurde am 03.03.2020 aufgenommen. Shownotes & Links Michael Geers auf Twitter Micro Frontends Webseite Michael’s Vortrag auf der MicroCPH Konferenz: Micro Frontends the nitty gritty details Duet Design System (auf Web-Component Basis) Das Buch: Micro Frontends in Action

Hans und Peter bauen Warhol: Eine App mit der man seine Pattern Library für Tests der Design-Konsistenz des eigentlichen Produkts nutzen kann. Die beiden stellen Design Testing generell vor und erklären, warum Warhol eine gute Lösung dafür ist. Das Interview wurde am 21.02.2020 aufgenommen. Shownotes & Links Warhol auf Twitter Hans-Christian Reinl Peter Kröner

Wir sind zurück! Kaum zu glauben, aber es gibt uns immer noch. Die letzten zwei Jahre über ist viel passiert. Wir resümieren etwas und stellen die UIengine vor, welche in unseren Projekten als Werkbank für UIengineering dient. Das Interview wurde am 14.02.2020 aufgenommen. Shownotes & Links UIengine auf Github UIengine Dokumentation Thonet Brand Manual UIengineering Pattern Library Beispiel Klingel: Designsystem hoch 15 Dennis Reimann Jan Persiel

Antje Kroon und Ralph Schumann von der zwhy GmbH berichten über die Entscheidung eine Agentur Anfang 2017 in zwei Firmen zu trennen, um diese dann wieder zusammenzubringen, um Dinge aus einer Hand machen zu können. Glaubwürdig. Wir horchen mal rein wie es zu dieser Trennung gekommen ist und was das eigentlich bedeutet. Wie macht trennt man so eine Firma auf? Welchen Einfluss hat das auf die Kultur? Was hat das mit New Work und einer Konferenz dazu zu tun? Die Teams in denen die Hardcore-Entwickler und die Super-Kreativen saßen gab es irgendwie immer Gerangel … —Antje Kroon Wir versuchen gerade herauszufinden wo die Schnittmengen sind: Ist ein Websitenprojekt ein Software- oder ein Kommunikationsprojekt? Es ist beides. —Ralph Schumann Wenn wir (d.h. Entwicklung und Kommunikation/Design) zusammenarbeiten … müssen wir nichts wegdiskutieren, weil wir es vielleicht als eine Partei nicht können. —Ralph Schumann Die New Work Future Konferenz findet am 14. und 15. Juni 2018 in Hamburg statt. Infos und Tickets auf der Konferenz-Website. Das Interview wurde am 20.10.2017 bei der Ministry Group / zwhy live aufgenommen. Shownotes & Links Trennung oder Neugründung? Wie die Ministry Group sich neu definiert hat! Ministry Group zwhy Jobs New Work Future Konferenz

Susanne Kaiser ist Technischer Vorstand bei der Just Software AG in Hamburg. In unserem Interview spricht Jan mit ihr über die Historie des Unternehmens und die der Software. Welche Auswirkungen hat die Entwicklung der Software auf die Teams und umgekehrt? Aber auch die Anforderungen an Produkt und Unternehmen von außen sind Thema. Team und Softwarearchitektur waren bei uns monolithisch und mit dem Wachstum wurden wir langsamer. Daraufhin haben wir unsere Teams aufgeteilt und auch die Software auf Mikroservices umgestellt, um wieder schneller agieren zu können. —Susanne Kaiser Die Teams können autonom arbeiten und entscheiden, aber … Es ist so, dass wir schon eine gemeinsame Basis benötigen, … hinsichtlich Styleguides z.B. Es soll sich ja noch aus einem Guss anfühlen. Und wir haben Standards, so dass sich nicht jedes Team seine eigene React-Library einführt. —Susanne Kaiser Wissenstransfer und Dokumentation ist ein weiterer Punkt im Gespräch: Wir haben erkannt, dass Dokumentation in der Sekunde der Erstellung veraltet ist. Wir dokumentieren durch wartbaren Clean-Code. Wir schreiben aber viele Read-Mes, die wir auch mit dem Code einchecken. —Susanne Kaiser Das Interview wurde am 22.09.2017 bei der Just Software AG live aufgenommen. Shownotes & Links Die Just.Social Suite Jobs

Thomas Lobinger ist Software Development Manager bei Amazon Web Services in Berlin. In unserem Interview mit ihm sprechen wir ein wenig über seinen Werdegang, über Design Systeme, wie bei Amazon Web Services Teams funktionieren und was er für Erfahrungen in den letzten Jahren in einem ständig wachsenden Unternehmen gemacht hat. Unser Team kümmert sich um das Design System, Tools und Automating … um das Leben von Frontend-Entwicklern und Designern besser zu machen und deren Produktivität zu erhöhen. —Thomas Lobinger Das Design System ist über eine längere Phase entstanden. Die Genesis des AWS Design Systems liegt darin begründet, dass das zentrale Frontend-Entwicklungsteam der großen Menge an Projekten nicht nachkommen konnte. Alleine 2016 sind 1017 Features und Services gelauncht worden, um dies mal in einen Kontext zu setzen. Deshalb ist das durch ein Team auch nicht machbar gewesen. —Thomas Lobinger Wir sprechen über Granularität und Feinteilgkeit in Designsystemen und was die Basis für Komponenten ist: Was ist der richtige Grad an Vorschriften vs. Einschränkung der Kreativität? Für uns sind HTML-Tags/Webstandards diese Basis. Wir haben uns dann auf web components fokussiert, haben deren API aktuell noch über Klassen abstrahiert, können diese dann aber (wenn web components native verfügbar sind) ablösen. —Thomas Lobinger Standardisierung ist für das Team um Thomas bei AWS auf allen Ebenen und in allen Gewerken Thema: Wir haben einen Prozess angestoßen, der nicht nur im Frontend standardisiert ist sondern auch im Design. Wir stecken z.B. Research in solche Standards, denn wenn wir standardisieren dann auch richtig. —Thomas Lobinger Open Source für Design Systeme ist Thema für uns und Thomas sagt dazu: Wir glauben, dass es ein Benefit ist für die Community (unser Design System open source zu stellen), … um zu sehen wie es gelöst worden ist. —Thomas Lobinger Uns am Ende noch ein Aufruf: Sucht Euch eine Firma wo ihr das (Design Systeme/UIengineering) umsetzen könnt. Seid nicht der frustrierte Einzelkämpfer. Lasst Euch nicht aufhalten! —Thomas Lobinger Das Interview wurde am 15.09.2017 per Skype aufgenommen. Shownotes & Links Working backwards (Blogpost) Working Backwards (Video) Olga Madejska: Breaking Bad - Web Components in production, what worked for us | JSConf EU 2015 (Web?) Components in production Draft of the Unity (Single File Web Component) Specification

Christoph Reinartz ist UI/UX Engineer und Fullstack Developer bei Trivago. Wir sprechen in unserem Interview mit ihm über das bei Trivago eingeführte Design System und die Kultur der Produktteams. Um die Designer und Product Owner mit an Bord zu holen geht es ja auch darum, eine gemeinsame Sprache zu entwickeln. Damit die Leute ein gemeinsames Verständnis haben, von dem was man macht. —Christoph Reinartz Das Design System unterstützt dabei das Finden und Kommunizieren der gemeinsamen Sprache. Das [Design System] ist kein rein technisches Thema, es ist auch nicht ein reines Design-Thema. Das ist eigentlich ein Thema, was die Organisation im Gesamten betrifft. —Christoph Reinartz Wir sprechen über die Idee des Design Sprints und wie sie bei Trivago in der Produktentwicklung eingesetzt werden: Ideen werden getimeboxed erarbeitet. Es geht relativ schnell in Skribbles, die werden wieder diskutiert, es wird gevotet auf die verschiedenen Lösungen. So kann man auch durch das Timeboxing schnell eine Idee konkretisieren. —Christoph Reinartz Trivago sieht sich als “data-informed” und testet insbesondere Neuentwicklungen über Metriken und A/B-Tests. Nichtsdestotrotz verlässt man sich nicht allein auf Zahlen, sondern testet auch intensiv mit richtigen Nutzern: Man kann nicht immer alles im A/B-Testing sehen. Du siehst in der Regel die Zahlen, es hilft aber auch mal einen User die Website testen zu lassen. Und das dann zu kombinieren… damit hast du gute Möglichkeitebn, dein Produkt weiterzuentwickeln. —Christoph Reinartz Das Interview wurde am 08.09.2017 per Skype aufgenommen und am 12.09.2017 veröffentlicht. Shownotes & Links Rebuilding an aircraft on the fly Anatomy of a Design Sytem Sprint: Wie man in nur fünf Tagen neue Ideen testet und Probleme löst Lerna: A tool for managing JavaScript projects with multiple packages Stylelint: A mighty, modern CSS linter Jobs bei Trivago

Was eigentlich nur als ein kleines Stimmungsbild beginnt, ist vielleicht der Anfang eines ganzen Staffelthemas. Heute geht es kurz um Remote-Arbeit, die Vorurteile und ein paar Anmerkungen. Shownotes & Links Buch: Remote, office not required by David Heinemeier Hansson/Jason FriedAmazon :) Basecamp Slack Platz frei im Loft74

Heute sprechen wir kurz über die Idee wie man sich in einem Projekt seine Vorgehensweisen dokumentieren kann und Best Practises festhalten kann. Ausserdem kurz etwas zum UI Pairing mit Dennis. Shownotes & Links Pairing

Patrick Blom ist Senior Backend Entwickler bei SHOPMACHER. In unserem Interview mit ihm berichtet Patrick von typischen Prozessen bei der Entwicklung von Shops und dem Shopmacher eigenen Produkt CommerceCockpit. Wiederverwenden und Synergien nutzen ist bei SHOPMACHER ein tagtägliches Thema: Der Grundgedanke der Wiederverwendbarkeit (von Komponenten) ist da. … Natürlich schauen wir auch, ob man Komponenten aus einen Basisportfolio, das wir mal entwickelt haben, verwenden kann und diese dann )für den Kunden) angepasst werden. —Patrick Blom Technologien, die verwendet werden: Wir nutzen gängige Technologien wie HTML5, LESS, (gehen) weg von jQuery hin zu nativem JavaScript und die Basis unseres Produktes ist Symfony bzw. TWIG. —Patrick Blom Patrick spricht auch über die verschiedenen Arten von Zulieferungen aus Richtung der Kunden und Designagenturen. Oft ist der Designprozess vorgelagert, aber manchmal geht SHOPMACHER in den Lead aus einer beratenden Rolle: Wenn die Sachen (Designs) zu uns kommen setzen wir uns zusammen … und schauen uns an … wie wir das umsetzen können. Wir klären dann auch wo die User Experience leiden könnte, weil z.B. ein Gutscheincode an einer Stelle technisch Probleme mit sich bringt. —Patrick Blom Die Qualität der zugelieferten Designs ist sehr unterschiedlich. Wir versuchen in einem Briefing vorab genau zu klären was wir genau in den Designs sehen müssen, um mit diesen schnell arbeiten zu können. —Patrick Blom Wir bieten dem Kunden an schon früh die ersten Komponenten abzunehmen ohne dabei von allen anderen Shop-Seiten (wo diese verwendet werden) abhängig zu sein. —Patrick Blom Wir versuchen die Grenzen zwischen Design und Entwicklung so weich wie möglich zu halten. —Patrick Blom Wenn wir früh in den Designprozess als Berater einbezogen werden, so arbeiten wir eher auf Mockup-Ebene und gehen dann schrittweise vor und verfeinern. —Patrick Blom Das Team bei SHOPMACHER arbeitet nicht nur in Gescher bei Münster, sondern auch mit 15 Personen in Vietnam: Unsere Teams sind interdisziplinär zusammengestellt … und die Reviews der Sprints sind offen. Jeder kann so schauen was die anderen Teams gemacht haben, was wir durch total offene Prozesse unterstützen. Die Teamleiter tauschen sich zusätzlich aus … und bei wichtigen Themen machen wir eben ein internes Barcamp. —Patrick Blom Bei uns sind Teams für sowohl Setup als auch Betreuung der Shops zuständig. … Der Vorteil ist, dass man die Shops dann auch so baut, dass die Betreuung gut funktionieren kann, was eine potentielle Fire-and-Forget-Attitude eines reinen Setupauftrags verhindert. —Patrick Blom Das Interview wurde am 18.08.2017 per Skype aufgenommen und am 21.08.2017 veröffentlicht. Shownotes & Links SHOPMACHER

Heute sprechen wir über ein kleines Tool, welches das im Code designen ein wenig einfacher macht: Codekit. Alternativen gibt es einige (s.u.) und es ist ein guter Einstieg ins Arbeiten mit Dingen wie Preprozessoren und Browsersync, ohne dies als Designer alles von einem Entwickler aufsetzten lassen zu müssen. Shownotes & Links Codekit Prepros Koala

Benjamin Rabe ist User Experience Designer bei mindmatters. Er berichtet in diesem Interview von der Zusammenarbeit mit Kunden und den größeren Aufgaben, denen man mit Design begegnen kann und unsere Verantwortung als Produktentwickler. Ich glaube die größere Aufgabe ist tatsächlich, dieses Toolset das man als Designer hat soweit zu öffnen, dass sie zum einen verfügbar sind für alle und zum anderen auch das Mindset so zu schärfen, das jeder weiß, wann man sie anwenden kann. —Benjamin Rabe Es geht darum, wie wir im Zusammenspiel mit Kunden auch grundsätzlich auf das Projekt einwirken und größere Fragen klären können: Das was Design grade im frühen Prozess leisten kann, ist diesen Ideationsprozess gut zu begleiten, Möglichkeiten sichtbar zu machen und Wege auszuleuchten. —Benjamin Rabe Außerdem sprechen wir auch über die Verantwortung, die in der Produktentwicklung liegt und welche kulturstiftenden Aspekte unsere Arbeit haben kann: Ich finde das ist in gleichem Maße der schwere wie auch spannendste Auftrag den wir haben: Empathie möglichst früh aufzubauen, sie über ein Projekt aufrechtzuerhalten, immer anzupassen und sie aber auch wiederum im Projekt zu verteilen. —Benjamin Rabe Das Interview wurde am 11.08.2017 per Skype aufgenommen. Shownotes & Links Jobs To Be Done Salesforce Lightning Design System

Ein kleines Update zu Dennis’ UI Pairing Sessions und bevorstehenden Konferenzen: Die Web Engineering Unconference auf Mallorca und das eCommerce Camp Hamburg. Shownotes & Links Quick 'n dirty Episode 4 bei YouTube A Designer’s Code of Ethics

Unser Interviewgast Rico Pfaus ist Frontend-Architekt bei Galeria Kaufhof. Vor drei Jahren haben wir gemeinsam mit Rico am Relaunch der Galeria Kaufhof Platform gearbeitet und sprechen mit ihm über die Entwicklungen seit dieser Zeit. Das Interview wurde am 04.08.2017 per Skype aufgenommen. Die Episode wurde am 14.08.2017 offline gestellt.

Unser Interviewgast Mario Nebl arbeitet als Freies Radikal bei der SinnerSchrader Deutschland GmbH. Wir unterhalten uns mit Mario über den von ihm entwickelten Pattern Library Generator patternplate und Design Systeme. Allein dadurch dass alle über die selbe Sache sprechen, spart man viel Zeit und erreicht eine andere Durchdringungstiefe in allen Gewerken. —Mario Nebl Ebenso sprechen wir über Teamkonstellationen bei SinnerSchrader: Wir strukturieren unsere Teams anders: Es gibt kein Team in dem nur Technik oder nur Designer sitzen. Es wird immer gemeinsam in relativ kleinen Teams an einem Feature gearbeitet. Das führt dazu, dass man gemeinsam Verantwortung für das Ergebnis übernimmt. —Mario Nebl Das Interview wurde am 17.07.2017 in Hamburg aufgenommen. Shownotes & Links patternplate Space in Design Systems – Nathan Curtis React Sketch.app

Heute sprechen wir quick & dirty über die Chocolate White Icons, welche wir im Rahmen der UIengine und in anderen Projekten einsetzen. Was nervt bei der Iconerstellung, worauf musste man achten, welche Tools können dabei helfen. Shownotes & Links Chocolate White Icons UIengine Gapplin – SVG Viewer for Mac

Heute sprechen wir quick & dirty über die UIengine, welche wir als Pattern Library Generator in aktuellen Projekten einsetzen. Shownotes & Links UIengine Die UIengineering.de Pattern Library

Ein kleines Update aus dem Off: Im quick & dirty Style melden wir uns zwischen den Staffel zurück und sprechen über das was uns aktuell bewegt. Shownotes & Links UIengine Die UIengineering.de Pattern Library

Bart Simpson musste schon als Strafarbeit an der Tafel Dinge schreiben: Ist die moderne Form der Strafarbeit die Dokumentation? Im Nachgang Dinge von anderen so aufschreiben, dass es passt. Nervt. Aber es gibt einen Weg aus der Motivationsfalle Doku: Die Dokumentation selber. In dieser Episode sprechen wir über die Art und Weise wie es Spaß machen kann eine Doku zu haben und nicht daran zu verzweifeln. Wir reden über Beispiele aus unserer Arbeit und Prinzipien, die andere verwenden, um aus Dokumentation das zu machen, was sie leider nicht immer ist: Ein wertvolles Extra. Welche Tools wir verwenden und wie man Dokumentationen zu einer integrierten Sache machen kann, die auch noch das Team besser zusammenbringt, ein paar Tipps für mehr Selbstpromotion und besseres Projektinvolvement sowie Ideen für die Zukunft in unseren Arbeiten diskutieren wir ebenfalls. Und noch etwas in eigener Sache: Wir kommen wieder! Das Ende der ersten Staffel des UIengineering Podcast ist mit Folge 10 erreicht. Ab der zweiten Staffel kommen wir mit einem angepassten Format zu Euch und werden mehr Gäste haben. Wenn Ihr einen Interviewpartner vorschlagen mögt, auch Euch selber, immer her mit den Kontakten. Wir nehmen eine kleine Pause und sind dann schon bald wieder in einem Podcatcher in Eurer Nähe oder Tasche. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes & Links Pattern patter Five tips for improving your technical writing and documentation Write The Docs: Documentation Guide Das uiengineering.de-Projekt auf Github

Es ist bekannt aus vielen Hollywoodstreifen, kein Agentenfilm oder moderner Thriller kommt ohne es aus: Das schwarze Fenster mit der weissen oder grünen Schrift, die superkryptisch aussieht. Aber ist das denn wirklich alles nur für den Obernerd zu verstehen und zu bedienen? Wie so oft in unseren letzten Gesprächen stellt sich heraus, dass es gar nicht so schlimm ist wie man denken kann. “With the helping hand of a friend” kann man auch als Designer eine Menge Freude am Terminal entwickeln, nämlich dann wenn man merkt, dass einem dieses Fensterchen ganz viel Arbeit abnehmen kann. Wer weiterhin 345 JPEGs von Hand speichern und umbenennen und optimieren will kann das gerne tun. Aber wer schlau ist, noch ein Leben nach dem Job hat, der hört genau hin und sammelt Ideen wie man früher Feierabend machen kann. Außerdem sprechen wir über die Arbeitsweise mit Build-Scripts und über die Arbeit an der uiengineering.de. Warum am Ende auch ganz kleine erste Schritte ein Weg in das mysteriöse Fenster Sinn machen haben wir auch als Punkt für diese Episode auf der Agenda gehabt. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes & Links Das uiengineering.de-Projekt auf Github

CSS ist eine Schnittmenge der Gewerke Design und Entwicklung. In der achten Folge des UIengineering Podcasts sprechen wir heute darüber wie wir CSS schreiben, welche Tools wir nutzen und welche Architekturen es gibt. CSS ist nicht CSS ist CSS … heute schreibt kaum noch ein Frontend-Entwickler direkt CSS. Wer sich viel Arbeit und Zeit sparen will, der nutzt einen Preprozessor. Welchen aber nutzt man am besten? Was steckt hinter diesen Tools? Und ist das schon wieder etwas, was ein Designer lernen muss, der womöglich gerade seine ersten Schritte in CSS gemacht hat? Wir berichten über unsere Erfahrungen mit BEM, auch ausserhalb der Design-und-Entwickler-Schnittmenge, warum das Konzept gut zu Atomic Design passt und was man sonst noch so beachten kann und sollte. Keine reine Entwicklerfolge, im Gegenteil. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes & Links Preprozessoren / Architekturen BEM SASS Stylus LESS Atomic CSS SMACSS Tools zum Kompilieren Koala (Win, Mac, Linux) CodeKit (Mac) Prepros (Win, Mac, Linux)

Layouten in Sandboxen: Was? Nicht in Photoshop oder Sketch? Und was sind überhaupt Sandboxen? Sandkisten? Wir sprechen in dieser Episode über den Prozess des Layoutens, und wie und wann welche Tools für die Designarbeit sinnvoll sind. UIengineering ist nicht nur wenn ein Designer mit dem Entwickler spricht bevor er sein Layout “über den Zaun wirft”. In dieser Episode sprechen wir über die Methode in einer Sandbox, einem Bereich innerhalb einer Pattern Library, zu gestalten. Layouten mit Code (Markup/HTML und CSS, vielleicht sogar JavaScript). Manchmal kann das eine extrem effektive Art und Weise der Arbeit sein. Manchmal kann es auch langsamer sein und die Ergebnisse viel schlechter. Wann also sollte man wie vorgehen? Neben der Herausforderung mit Tools, die man nicht so gut beherrscht wie andere, zum perfekten Ergebnis zu kommen, kann man aber auch viel Zeit sparen. Mitunter auch den einzigen wirtschaftlichen Weg beschreiten, um ans Ziel zu gelangen. Wir beleuchten diese Aspekte heute aus der Perspektive des Designgewerks. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes & Links Alt aber wahr - Warum Designer coden sollten (EN) Termine mit #uiengineering

Folge Sechs unseres Podcasts ist ein Interview mit Falk Hoppe (@nothing_box), Senior Berater bei innoQ aus Monheim am Rhein. Falk arbeitet bereits seit vielen Jahren im Umfeld von Frontend und Pattern Libraries und teilt seine Eindrücke und Ideen mit uns. Die Arbeitsweise mit einer Pattern Library ist für Falk die Grundlage für funktionierendes UIengineering. Hier kommen Designer und Entwickler, aber auch Vertreter verschiedener Fachbereiche zusammen. Dabei sollte Kommunikation als Basis für eine gute Zusammenarbeit dienen und natürlich ist ein konstanter Austausch zu den Themen, die alle Gewerke beschäftigen essentiell. Aber wie deutlich wird, geht es auch für Falk nicht nur darum die Gewerke in einen Austausch zu bringen, sondern die Rollen per se zu betrachten und die Bindung einer Rolle an eine Person zu hinterfragen. Hier sieht er auch Herausforderungen, die bis zum Management einer Agentur oder eines Unternehmens hinauf gehen. Aber gleichzeitig ist ein Einverständnis nicht zwingend notwendig. Auch sprechen wir über Tools und wer diese verwenden kann. Eine Reihe von Links sind in den Shownotes zu finden. Je nach Konzeption und Anforderungen sind hier eventuell schon erste Tipps dabei, die einen Einstieg in die Welt von Styleguides und Pattern Libraries ermöglichen. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes & Links Falk Hoppe auf twitter: nothing_box innoQ Stiletiles Stylegen von GALERIA Kaufhof Frontify Fabricator Fractal.Build Living Pattern Libraries: Wie man Styleguide Zombies killt Termine mit #uiengineering

In Folge Fünf des UI engineering Podcast unterhalten wir uns über die Kosten und Nutzen von Pattern Libraries. Wann macht es Sinn eine Pattern Library zu verwenden und wann nicht. Wer zahlt was? Wie ist mit Budgets pro Gewerk zu rechnen? Pattern Libraries sind der große Hype, aber was kostet denn eigentlich eine solche Pattern Library Entwicklung? Was sind die Dinge, die man sinnvollerweise einbaut? Wir sprechen über Beispiele, die wir in einigen Tools gesehen haben, die wir selber entwickelt haben und die wir uns noch gut vorstellen können für ein gutes Tool. Auch das Thema Dokumentation und das Einbeziehen von verschiedenen Gewerken ist ein Aspekt, der für uns in der Pattern Library Entwicklung eine wichtige Komponente ist. Hier diskutieren wir ebenfalls Beispiele und Anforderungen. Termine mit #UIengineering 16.3.–18.3.2017 E-Commerce Camp Jena 29.5.–2.6.2017 webinale Berlin Shownotes Enterprise UI Design Patterns How and why to create a pattern library? How we use pattern libraries to deliver value

Folge Vier des UI engineering Podcast stellt die praktische Arbeit mit Pattern Libraries vor. Es geht um Arbeitsabläufe, wo fängt man an und wie setzt man Dinge um. Wir sprechen über die Workflows, die es für den Einsatz von Pattern Libraries gibt. Wir greifen dabei auch Themen der vorherigen Episoden – Atomic Design und Styletiles – wieder auf und sehen uns ihren praktischen Einsatz an. Außerdem sprechen wir über die Zusammenarbeit von Design und Entwicklung an der Pattern Library: Was dadurch ermöglicht wird und welche Herausforderungen dabei auf das Team zukommen. In der kommenden Episode weichen wir vom bisherigen Format ab und haben uns einen Interviewgast besorgt. Wir werden tiefer in das Thema Pattern Library einsteigen und ein Open Source Projekt dazu vorstellen. Seid gespannt! Shownotes Designing Imaginative Style Guides Are Pattern Libraries Good for Design?

In der dritten Folge des UI engineering Podcast geht es um Pattern Libraries. Wir besprechen die Grundlagen und die Aspekte für die Anforderer. Atomic Design ist eine Grundlage, die wir für eine solide Basis zum Entwickeln von Webprojekten erachten. Pattern Libraries sind ein Tool diesem Design System Leben einzuhauchen und die Idee von Atomic Design in das Projekt zu bringen. Hierbei ist unserer Auffassung nach eine lebende und von allen genutzte Pattern Library notwendig. Diese und weitere Aspekte besprechen wir in dieser Folge. Das Thema Pattern Libraries wird in der nächsten Folge fortgesetzt. Shownotes Pattern Libraries: What They Are and Why You Need One Pattern Libraries in Sketch + Zeplin Boards ⇒ Creative Team and Developers happy ever after Automated Pattern Libraries for Complex Web Design Projects

In der zweiten Folge des UI engineering Podcast geht es um Style Tiles, Stil-Kacheln sozusagen: Styletiles sind ein Tool, welches bei der Findung von Designrichtungen und auch der Entwicklung von konkreten Interface-Anmutungen hilfreich sein können. Spitzer und klarer als Moodboards, aber nicht so “Detail-belastet” wie ein Layout können Sie zu sehr viel Hilfe und Tempo in der Zusammenarbeit mit Kunden, Entwicklern und Designern bringen. Wir berichten über Grundlagen und Anwendungsbeispiele, damit Ihr dieses Tool für Euch entdecken könnt. Shownotes Styletiles Website Communicating With Style Tiles Getter Better Visual Design Feedback with Style Tiles

In der ersten Folge des UI engineering Podcast geht es um Atomic Design: Was ist das genau und warum eignet es sich für die Konzeption von Web Interfaces? Wir sprechen über die Grundlagen, Komponentisierung, Wiederverwendbarkeit und Dinge, die zu beachten sind. Shownotes Atomic Design Intro Atomic Design Buch Designing Modular UI Systems Via Style Guide-Driven Development

Jan und Dennis erzählen ein wenig rund um den UI engineering Podcast: Die Motivation hinter dem Thema und warum wir den Podcast machen. Wir geben einen Ausblick auf die Themen der ersten Staffel und erzählen, an wen sich der Podcast richtet. Shownotes UIengineering Website Jan Persiel / @janpersiel Dennis Reimann / @dennisreimann Nutzt gerne das #uiengineering Hashtag