Stefan: 0:10

und herzlich willkommen zu Coffee-Coating-Consult Heute mit einer Folge zum Thema Designsysteme Ich habe heute einen super Sonderspezialgast bei mir und zwar ist das die Mandy Urban von der Visual West. Sie ist seit einiger Zeit dort die Expertin für Designsysteme und hat Entwicklung des Designsystems vorangetrieben und möchte... Uns heute da von ihren Erfahrungen erzählen und wir werden uns ein bisschen austauschen, was da so alles hinten dran stand in dieser gesamten Entwicklung des Designsystems und was sich im Laufe der Zeit entwickelt hat und was das eigentlich alles so bedeutet. Herzlich Willkommen Mandy!

Mandy: 0:46

Hallöchen! Schön, dass ich hier sein darf.

Stefan: 0:48

Schön, dass du da bist ja, dann wollen wir direkt rein starten,

Mandy: 0:53

gleich los.

Stefan: 0:54

los, gut, dann fangen wir einfach mal an. Designsysteme was genau ist das, warum tun wir das überhaupt?

Mandy: 1:01

Genau, also Designsysteme das ist einfach so ein... Ab Komponentensatz oder Stylesatz, also es gibt auch Stylesysteme oder nur Designsysteme wo man einfach Sachen wiederverwenden kann. Das ist der ganz wichtige Punkt. Es sieht bei zum Beispiel auf der Plattform alles gleich aus. Also wir haben einheitliches Design, daher Designsystem, einheitliches Design und man muss sich halt nicht alles selber entwickeln und bauen.

Stefan: 1:27

Und warum macht man sowas wenn wir alles einheitlich haben? Hat es Vorteile? Hat es Nachteile?

Mandy: 1:33

Ja, also der ganz, ganz große Vorteil also ich muss nicht alles doppelt bauen. Also ich vermeide Doppelungen im Code, Implementierung. Das Schlimmste, was es gibt, wir bauen eine Komponente und sie ist dreimal unterschiedlich gebaut und dann finde den Fehler. möchten wir vermeiden. Es soll immer gleich aussehen, sich immer gleich verhalten, egal wo ich bin, auf der Seite, in der wo auch immer, wo man sie verwendet Genau. Und eins der Punkte warum ich da auch so Fan von bin, ich habe die Erfahrung gemacht, Frontend tun halt viele gerne ab und sagen, ach ja, ist ja nur Frontend, aber es hängt doch viel mehr dahinter. Und jeder, der mehr Backend-Erfahrung hat, sagt dann am Ende doch, oh je, oh je, oh je. Und mit so einem Designsystem wird halt viel Arbeit abgenommen. Das ist einfach anwenden und man muss sich nicht um die ganze Logik innerhalb von Komponenten kümmern.

Stefan: 2:23

Backend Entwickler oder die eher Backend lastigen Entwickler, die haben dann Bausteine, die sie einfach per Anleitung quasi Copy Paste reinnehmen können, müssen sich um nichts kümmern und müssen sich nur ein bisschen um die Logik kümmern, was dann vielleicht auch gerade so funktioniert.

Mandy: 2:36

Also bei uns ist es tatsächlich so, dass unser Designsystem, wir haben in Angular verschiedene Komponenten die wir anbieten und dem Backend-Entwickler haben wir sogar einen Code-Generator, wo er sich das zusammenklicken kann und dann sagen kann, okay, ich möchte die Komponente, die soll das und das können, das klickt man sich zusammen und dann kann man sich den Code kopieren. Er muss sich dann nur noch um Input und Output kümmern und der Rest ist ihm egal. Und ich sehe als Vorteil die Erleichterung beim Entwickler, er muss sich darum nicht kümmern und aber auch es geht halt schneller, wenn man es nicht selber entwickeln muss. Copy paste, los geht's.

Stefan: 3:11

gut. Haben wir noch mehr Vorteile, außer dass wir ein einheitliches Aussehen haben und dass wir Backend-Entwicklerinnen und Entwickler mit an die Hand nehmen oder auch den Frontend-Entwicklern natürlich die Arbeit ein bisschen leichter machen? Hat sich darauf schon beschränkt jetzt erstmal. Das sind so die Hauptargumente warum wir das

Mandy: 3:27

Also, das war am Anfang immer eines der Hauptargumente aber im Laufe der Zeit ist auch die Weiterentwicklung. Also, wenn wir Komponenten wenn ein neues Feature gewünscht ist, ist es halt viel einfacher an einer Stelle das weiterzuentwickeln als an fünf, sechs verschiedenen Stellen im Code. Und das beste Beispiel ist dafür natürlich Barrierefreiheit.

Stefan: 3:45

großes Thema in der letzten Zeit. Hatten wir auch eine Podcast-Folge zu, tatsächlich.

Mandy: 3:49

Ja, und das war jetzt auch die letzten Wochen, Monate ein unserer Hauptthemen. Unsere Komponenten bauen wir barrierefrei, wir kümmern uns darum im Designsystem und die Anwender haben dann einfach out of the box Barrierefreiheit manchmal nicht ganz, manchmal muss man halt einen Input hinzufügen, aber generell ist es halt ein Riesenvorteil man muss nicht auch noch daran denken.

Stefan: 4:11

Das heißt, man kann an einer zentralen Stelle, sind alle Expertinnen und Experten vorhanden können sich um die Änderungen kümmern Und dann wird es direkt für alle Stellen angepasst.

Mandy: 4:22

Das

Stefan: 4:23

Das heißt, wir haben jetzt so ein Designsystem, bei der VV ist es selber entwickelt worden, ich da so ein bisschen nebenher raushöre. Grundsätzlich haben wir ja aber auch die Möglichkeit, neben dem selber entwickeln, gibt es ja auch schon vorgefertigte Designsysteme die man nutzen kann. Was war denn da so der Grund, warum sich bei der VV entschieden wurde, wir machen mal Wir machen das selber.

Mandy: 4:44

Ja, also das ist auch nicht das erste Mal, dass ich dieses Spielchen gespielt habe, auch bei vorigen Arbeitgebern hatte ich die gleichen Diskussionen aber es gibt doch schon. Ja, aber man möchte immer was Individuelles haben. Also eins der bekanntesten Designsysteme würde ich jetzt sagen, ist Angular Material oder Material Allgemein Und alles toll, solange man nichts haben möchte. Also wenn der, nehmen wir den Date Picker zum Beispiel, er soll noch zusätzlich irgendwie ermöglichen dass er nicht beschreibbar ist, sondern sich sofort öffnet wenn man reinklickt. Dann fängt man an, den Material Date Picker zum Beispiel umzubauen, um das zu ermöglichen. Material macht ein Update, klickt Na ja, dann haben wir den Salat weil eventuell könnte irgendwas brechen, Breaking Changes. Wir müssen halt immer darauf achten und das ist halt der riesen Nachteil, warum ich persönlich auch überhaupt kein Fan von diesen Fertigen bin und immer auf Eigenentwicklung setzen würde, weil unsere Product Designer, die haben auch immer ganz tolle Sonderwünsche, was alles benötigt wird und am Ende ist es halt auch immer das kleine Besondere mehr als der Standard.

Stefan: 5:49

Ja, auf jeden Fall. Aber das heißt, wenn ich in einer Situation bin, in der ich eigentlich das Design ist fein so wie es ist, ich brauche keine Sonderwünsche mir reichen die Standardkomponenten dann wäre ein fertiges Designsystem ein gehbarer Weg, nehme ich so mit. Aber ansonsten in dem Moment, wo man gerne selber Sachen machen will, hoch individualisierte Komponenten und so weiter, kommt man eigentlich um eine Eigenentwicklung gar nicht drum

Mandy: 6:13

Also für kleine Projekte privat nutze ich auch Material,

Stefan: 6:16

zähle

Mandy: 6:16

jetzt nicht alles selber, aber da habe ich auch nicht diesen Anspruch Aber Größeren Projekten möchte man halt das Besondere haben vielleicht.

Stefan: 6:25

Natürlich. Und du hast den Date Picker schon angesprochen. Das heißt, du hast da auch Erfahrung mit, nehme ich jetzt erstmal an. Oder wenn du es schon so als Beispiel aufbringst, oder ist es einfach nur eine Komponente bei der halt immer wieder Sachen passieren? Ja,

Mandy: 6:39

der Date Pickers war tatsächlich vor fast zwei Jahren über zwei Jahren die erste Komponente die ich bei uns bei der Visual West bauen durfte. Und es war wirklich ein komplexes Gerät sage ich jetzt mal. Es gab auf der ganzen Plattform wahrscheinlich fünf, sechs verschiedene Date-Picker, alle unterschiedlich implementiert und das, und jeder hatte unterschiedliche Funktionen. Wochenenden sollen ausgegraut werden, bestimmte Monate sollen nicht markierbar sein. Also das nur so als Beispiel, was da war und das war dann halt wirklich, ich sag mal, das ist mein kleines Monster. Der Date-Picker ist mein kleines Monster und tatsächlich im Moment ich sitze wieder dran, wegen der Barrierefreiheit, weil man möchte natürlich, dass die Tastaturbedienbarkeit in dem Das Element, was sich öffnet um das Datum zu wählen, also der Picker an sich halt so einfach wie möglich ist, das haben wir vor zwei Jahren in der Basisversion gemacht und jetzt machen wir halt nochmal, dass es wirklich gut funktioniert. Aber hier ganz klar der Vorteil die Plattform muss sich nicht drum kümmern.

Stefan: 7:35

es

Mandy: 7:36

ist dann für alle einmal ausgerollt

Stefan: 7:38

absolut. Hattest du aber da, gerade wenn wir mit dem Datepicker reden, noch wirklich irgendwelche Herausforderungen bei der Entwicklung? wo du vielleicht auch Tipps geben kannst, worauf man bei einer Entwicklung von so einem eigenen Designsystem vielleicht achten sollte?

Mandy: 7:52

mobile Ansicht ist auch immer ein ganz guter Punkt. Also bei uns ist es tatsächlich auch so, dass der Datepicker mobil ganz anders sich öffnen soll als auf Desktop-Webseiten. Das sind halt, ja, Herausforderungen manchmal.

Stefan: 8:05

Mhm. Hauptherausforderung ist da mobil versus Desktop-Ansicht oder gibt es noch mehr Herausforderungen wo man darauf achten sollte, wenn man eben wie gesagt selbstständig anfängt solche Designsysteme zu entwickeln?

Mandy: 8:20

Ja, also zum Beispiel der Datepicker. Also es ist ein Form-Element. Es muss halt, wir arbeiten mit Angular, es muss halt zum Beispiel wirklich technisch es muss halt für Reactive- und Template-Driven-Forms funktionieren. Also es sind so Kleinigkeiten, an die wird ein Product-Designer oder sowas nie denken. Das ist sehr technisch. Inputs, die man verwendet, müssen halt typsicher sein. Das sind so wirklich technische Sachen, auf die man achten muss. Das, was wir wieder rausgeben als Event-Emitter oder wie auch immer, muss halt typsicher sein und der Anwender muss genau wissen, was er damit zu tun hat.

Stefan: 8:50

Das heißt, das A und O ist an der Stelle eine konsistente API, damit jeder der es benutzt Die Schnittstelle wie spricht der diese Komponente an, dass die dokumentiert ist, dass die gut ist, also durchdacht ist und einfach anwendbar ist?

Mandy: 9:07

Also die Dokumentation, es muss halt alles ganz klar auch dokumentiert sein, deutlich sein. Und ich bin halt sehr Fan, also ich persönlich, ich bin auch Entwickler und daher, ich kenne das, ich will jetzt nicht alle Entwickler über einen Kamm scheren, aber ich liebe es einfach, ich sehe Code, ich kopiere ihn, ich füge ihn ein und gucke ob es funktioniert. Da haben wir halt auch diesen Code-Generator, wo ich sage, okay, willst du einen Date-Picker? Hier hast du deinen Code-Schnipsel, kopiere es dir. Wir kennen es ja alle aus dem Internet von Material, anderen Design-Systemen bieten das auch. Super wichtig. Kein Entwickler liest die Doku, würde ich jetzt behaupten.

Stefan: 9:42

ist hilfreich wenn man einen Fall hat, wo es nicht funktioniert und dann gucken kann, okay, wieso geht das jetzt eigentlich nicht und dann guckt man auch ausnahmsweise mal in die Doku und findet dann, oh, vielleicht war ich blöd vielleicht hätte ich hier vorher mal reinschauen können.

Mandy: 9:55

Ja, genau. Bei uns ist es auch so, dass wir sagen, dass die Dokumentation oder das Ganze, wie wir es aufgesetzt haben, ist halt nicht nur für Entwickler, sondern auch für unsere Product Designer, für unsere Business Designer, eigentlich jeder kann dort reinschauen und schauen, was kann die Komponente, um dann zu entscheiden, brauchen wir sie an der Stelle, wo wir sie einbauen wollen oder nicht. Ich hoffe natürlich immer auf Ja.

Stefan: 10:18

Ansonsten darfst du dir demnächst eine neue Komponente entwickeln. Ich meine, das ist

Mandy: 10:21

macht Spaß.

Stefan: 10:22

Genau. Und wie funktioniert es dann mit diesen ganzen Spezial- und Sonderfällen, weil das kann ich mir vorstellen, wenn man dann versucht, so eine einigermaßen allgemeine API anzubieten für die Komponente wie zum Beispiel den Date Picker. Wenn ich dann 500 Spezialfälle habe, dann kann ich ja nicht anfangen, irgendwie 500 Input-Parameter zu geben, dann ist die Komponente ja plötzlich auch unübersichtlich und nicht mehr bedienbar.

Mandy: 10:48

Genau. Also bei der Entwicklung einer Komponente haben wir so einen bestimmten Workflow. Es fängt natürlich bei Product Design an. Die kennen die ganzen Einsätze, die wissen, wo was benötigt wird und dann erstellen sie erstmal so ein Design mit, was soll wie möglich sein und was soll machbar ist. Dann kommen wir Entwickler und sagen, ich würde jetzt sagen, sagen erstmal nein, Aber evaluieren das, also wir prüfen technisch was ist möglich und wie machen wir das. Also ist bei der Entwicklung, wir sind zwar auch ein kleines Team, aber es entscheidet nicht einer alleine, wie die API aussieht. Manchmal ist auch die Konsequenz, dass wir sagen, irgendetwas können wir nicht umsetzen die Gründe können sein, es macht keinen Sinn aus technischer Sicht. Es kann aber auch, wir haben es auch schon entschieden, dass es einfach zu viel Aufwand ist. Wir sind ein kleines Team und haben gesagt, ist uns das für den einen Fall wert? Ist es uns das wert oder gibt es Alternativen, die werden können? Also kann man ein anderes Element verwenden oder wie auch immer? Dann entscheiden wir auch mal, dass etwas nicht, also dieser eine Spezialfall, dass wir ihn nicht umsetzen. Aber ich glaube, der Datepicker, der hat wirklich einiges. Also ich glaube, ich hatte vorhin schon gesagt, man kann bestimmte Datumswerte deaktivieren, man kann verschiedene Fehlermeldungen ausgeben aufgrund der Eingabe Barrierefreiheit ist immer wichtig.

Stefan: 12:06

Das heißt aber, grundsätzlich ist es so, es wird festgestellt, wir haben den Bedarf an einer Komponente fürs Designsystem, weil wir eben ein bestimmtes Element, eine bestimmte Funktionalität an verschiedenen Stellen in unserer Anwendung benutzen wollen und dann Wird das Ganze, wie du eben gesagt hast, über unsere Product Designer und Designerinnen gespielt, die sich erst mal Gedanken machen, wie könnte das denn tatsächlich für unsere komplette Plattform an allen möglichen Stellen sinnvoll aussehen, was sind die Konfigurationsmöglichkeiten die Product Designer an der Stelle braucht und dann kommt das Ganze zu euch, gibt noch mal ein bisschen ein Hin und Herspiel und dann letztendlich wird das Ganze umgesetzt im Designsystem und wenn dann die entsprechende Komponente entwickelt habt, dann geht eine Info an die Entwicklerinnen und Entwickler raus, hey wir haben jetzt diese coole neue Komponente, benutzt sie doch bitte an den und den Fällen und dann geht es so weiter.

Mandy: 13:03

Genau Also als wir angefangen haben, gab es unsere ganze Plattform schon. Das heißt, viele Entwicklungen waren schon da. Also auch der Datepicker gab es vorher schon in verschiedenen Ausprägungen. Das war zum Beispiel eine der Komponenten wo wir gesagt haben, okay, wir haben verschiedene Implementationen auf der Plattform und wir wollen das vereinheitlichen. Wir nehmen es instabil Designsystem. So sind wir mit ganz vielen dieser Elementen und Komponenten durchgegangen was halt mehrfach verwendet wird. Also seit Models Tabs Buttons, so simpel es auch ist, alle Input-Elemente die es so gibt, haben wir alle nachgebaut. Also im Prinzip ermöglicht, dass die Entwickler das verwenden können. Wir sind jetzt, ich sag, wir sind jetzt so nach zwei, drei Jahren an einem Punkt, wo wir sagen, wir bauen nicht mehr alles Was schon gibt, sondern wir bauen auch neue Sachen. Also wir hatten auch schon den Fall, dass bei uns eine Subdomain auf uns zukam, wir hätten gern. Und dann wird halt auch evaluiert, gibt es noch andere Möglichkeiten, das zu verwenden, weil nur für einen Fall bauen wir das nicht im Designsystem, das wird dann direkt in der Seite gebaut. Sobald man sich aber herauskristallisiert, dass da noch eine zweite, dritte vierte Anwendung möglich ist und das wiederverwendet werden kann, Designsystem. Dann schreien wir hier und wollen das bauen.

Stefan: 14:14

haben wir so eine schöne Komponente gebaut nach den Anforderungen von Product Design und jetzt wollen wir die aber weiterentwickeln. Gerade Barrierefreiheit hast du ja schon erwähnt. Thema, was uns im Moment alle sehr stark beschäftigt wage ich zu behaupten. Das heißt, auch da an der Stelle geht das Ganze dann wieder über Product Design, sagt, hey das muss barrierefrei sein und dann ist die gleiche Iterationsschleife oder gibt es bei der Weiterentwicklung vielleicht noch andere Dinge, die zu beachten sind, die dann vielleicht einen anderen Weg ein bisschen gehen, Dinge, die dir bei der Implementierung an der Stelle auffallen, wie funktioniert es mit der Verwendung weil die Komponenten sind ja schon im Einsatz, wenn wir die jetzt aktualisieren können Ja, was passiert dann mit den schon eingesetzten?

Mandy: 14:52

Genau, also wir müssen ganz stark darauf achten, dass wir keine Breaking Changes einbauen. Also das ist das ganz Wichtigste. Bei jeder Weiterentwicklung müssen wir halt immer rückwärtskompatibel sein. Ich würde jetzt mal sagen, in 95 Prozent der Fälle schaffen wir das. Es gab auch das ein oder andere Mal schon einmal Ausnahmen wo wir Wir vom Designsystem gesagt haben, okay, wir kommen nicht drum rum, es macht keinen Sinn hier, das so zu verkomplizieren damit wir nicht den Breaking Change haben, dann müssen wir halt Bescheid geben, dass die Leute dann zu einem bestimmten Zeitpunkt updaten müssen. Das ist aber auch bei uns kein Problem, es gibt die Regel, dass die nur zwei Sprints alt sein darf, das heißt, man muss irgendwann updaten. Aber ja, das Wichtigste ist... Breaking Changes sind ein No-Go, das ist ganz wichtig und bei jeder Weiterentwicklung halt auch die Teams informiert und wir bitten immer um Feedback. Also wir arbeiten in unserem Designsystem manchmal auch sehr isoliert, dass man das nicht immer alles mitbekommt was doch noch rechts und links nicht funktioniert, aber wir versuchen dann auch sehr schnell zu reagieren und zu fixen

Stefan: 15:54

Das heißt, jede Anpassung ist auch immer mit so ein bisschen verbunden, weil jemand könnte die Komponente so verwenden, wie ihr es nicht antizipiert habt und dann müsst ihr plötzlich schnell reagieren und es muss eine neue Änderung geben oder ist dann doch gar nicht so viel Druck?

Mandy: 16:10

wir sind immer im Gespräch, also es kommen mittlerweile die Kollegen auch direkt immer auf uns zu. Wir haben zum einen einen öffentlichen Channel, wo jeder Probleme schreiben kann, aber wenn man ein bisschen bekannt ist im Unternehmen, dann kommen die Kollegen auch auf einen zu und fragen direkt, hey, ich habe hier, ist das ein Defekt oder ist das gewollt? Und dann sprechen wir da und entscheiden auch immer, wie dringend ist das, wie schnell muss das gefixt werden, wie kritisch ist das? Wir wollen ja nicht für irgendeinen riesen Defekt verantwortlich sein.

Stefan: 16:36

wenn dann irgendwann die Tester kommen und sagen, hey, da geht irgendwas gar nicht mehr und dann wird es plötzlich dann doch zeitkritisch. haben wir ganz viel darüber geredet was ist denn eigentlich der Workflow für neue Anforderungen und so weiter. Thema, was mich noch so ein bisschen umtreibt Sind dann tatsächlich so ein bisschen die organisatorischen Aspekte. Also wie schafft man es, so ein Designsystem im Entwicklungsprozess gut zu etablieren Wie starten wir mit dem Ganzen überhaupt, wie kriegen wir im Projekt überhaupt die Erlaubnis, hey, wir dürfen ein Designsystem machen und wer bezahlt das am Ende? meine, natürlich haben wir jetzt keine allgemeine Antwort, die für alle gültig ist, aber dadurch, dass du das jetzt bei der Visual West ja schon sehr genau begleitet hast und sehr lange, hast du da so vielleicht so ein bisschen Insights wie hat das Ganze angefangen, was waren so Was die Learnings die ihr über die Zeit hattet wie war so die Entwicklung dahin?

Mandy: 17:33

Also der Start war tatsächlich vor meiner Zeit bei der Visual West, Anfang war das halt wirklich noch kein Design-System-Team. Und da hieß es einfach, wir machen mal so eine COP, Community of Practice, weil das wäre ja vielleicht was, ich glaube es fing mit Styles an, dass man sagt, man möchte nicht die ganzen Styles in jedem Frontend selber, Schreiben, sondern wir haben eine Styles-Library und daraus ist dann das andere, die Component-Library und das Ganze ist bei uns das Design-System sozusagen entstanden. Und Owner haben das am Anfang halt nicht so verstanden weil es ist Es kostet Zeit den Entwickler, aber ich sehe noch nichts auf der Plattform oder es bringt mir noch kein Geld, wie es so schön ist. Das heißt am Anfang war da wirklich viel Überzeugung und zu überreden was, im Prinzip das, was wir jetzt erreicht haben, die Vision mussten wir vorher schon gut verkaufen Zu sagen, könnt es wiederverwenden, die Entwickler sparen Zeit, weil sie immer nur die Komponenten verwenden können und nicht selber entwickeln müssen. Und ich sage es mal so, je mehr Defects bei bereits vorhandenen Komponenten waren, die eigen entwickelt waren. Umso besser war der Vorteil für uns. Weil es ist tatsächlich, ich komme hier wieder auf den Date Picker Es ist mein Monster, aber es ist mein Lieblingsmonster. Der hatte immer mal wieder irgendwo Defacts weil er fünfmal unterschiedlich entwickelt, unterschiedlich gebaut, unterschiedliche Funktionen und irgendwas funktionierte mal nicht. Und dann hat das halt Zeit gekostet weil an fünf Stellen fünf verschiedene Leute dann getüftelt haben, natürlich nicht gleichzeitig, aber die haben dann getüftelt wo ist das Problem. Und so langsam kam dann auch dieses Verständnis, hey, wenn wir das an einer Stelle nur haben, wäre das ja ganz gut. Und so haben wir nach und nach, am Anfang mussten wir halt auch, wie ich gesagt hatte bereits. zu Beginn war viel Austausch Wir haben Komponenten gebaut im Designsystem, die es bereits auf der Plattform gab. Das heißt, wir bauen eine Komponente im Designsystem und dann kostet es erstmal der Plattform Geld, diese Komponente wieder auszutauschen durch unsere, die alte zu entfernen und unsere. Das ist erstmal wieder Aufwand. Das war am Anfang ein bisschen schwer zu machen Übermitteln wie toll das eigentlich ist, aber ich sag mal so, die richtigen Leute haben uns vertraut dass das sinnvoll ist und mittlerweile gibt's da keine Frage mehr.

Stefan: 19:44

heißt, es hat als eine Community of Practice angefangen, ist also so ein bisschen aus Interesse und nebenher gelaufen, weil die Notwendigkeit gesehen wurde und sich dann entsprechend interessierte Entwicklerinnen und Entwickler zusammengeschlossen haben und dazu ausgetauscht haben, vielleicht erste Entwürfe dazu entwickelt haben, wenn halt die Zeit war, aber Das ist inzwischen ja nicht mehr so. Inzwischen sind wir da schon einen großen Schritt weiter. Wenn ich es richtig im Kopf habe, dann arbeitest du hauptsächlich am Design-System. Also

Mandy: 20:13

einen großen Schritt würde ich halt noch nicht sagen, weil im Vergleich zu anderen Design-Systemen also auch die Union hat ein Design-System Solid, da gibt es auch mehrere Entwickler die dran sitzen. Wir, bei uns ist es, wir haben eine Etappe mit vier Sprints Und im Moment ist es so, dass ich ein Sprint der Etappe Vollzeit im Designsystem bin. Ein Kollege von mir ist auch Vollzeit im Designsystem. Das heißt, wir haben jetzt, ist auch im Moment, also Tag heute so, dass wir gemeinsam An der Weiterentwicklung sitzen. In den anderen Sprints haben wir eine bestimmte Prozentzahl. Also mit 20 Prozent haben wir dann Einsatz. Das heißt, man kann die Fixen und so weiter. Ich persönlich würde auch gerne die ganze Zeit 100 Prozent im Design System arbeiten, aber es fehlt halt auch die Kapazität beim Product Design, weil wir brauchen die Vorentwicklung. Wir als Entwickler können erst loslegen, wenn wir von Product Design die Ideen haben. Um Komponenten zu entwickeln. Weil es geht bei uns ganz klar, Product Design kommt mit einer Idee. Entwickler schreiben ein Konzept dazu. Das wird dann halt auch gechallenged und besprochen. Und erst dann können wir richtig loslegen. Und dieser Vorlauf, das passiert halt sonst in diesen 20 Prozent, die wir haben im Team. Das sind mehrere Kollegen.

Stefan: 21:29

Okay, das heißt, es hat als Community of Practice angefangen, dann war der Bedarf irgendwann groß genug, zu sagen, okay, wir brauchen jetzt tatsächlich Entwickler, die sich auch ein bisschen mehr damit beschäftigen. Und dann ist es irgendwann so weit gekommen, dass entschieden wurde, okay, einen Sprint lang funktioniert es auch, dass wir eine Entwicklerin oder sogar zwei Entwickler in dem Fall Abstellen die sich dann auch voll darauf konzentrieren

Mandy: 21:54

Ja, also angefangen ich durfte tatsächlich, ich glaube, zwei Etappen Vollzeit im Designsystem und da habe ich einiges umgesetzt und dann war das Problem, dass nicht mehr genug im Vorlauf war, dass ich sage, ja, langweilen möchte ich mich auch nicht. Aber wenn halt Product Design, also um Gottes Willen die liefern immer, aber es ist ein Zeitproblem. Es kostet auch Zeit zu evaluieren was gebraucht wird und was in die Pipeline kommen soll.

Stefan: 22:19

Design muss ja am Ende dann auch die Designs erstellen mit den von dir gebauten Komponenten.

Mandy: 22:24

Und am Ende auch wieder testen Also die müssen natürlich wieder abnehmen, was wir gebaut haben und ob alles genau so ist, wie sie es sich vorstellen.

Stefan: 22:33

Und dann haben Product Designer aber eben tatsächlich den Vorteil sie können mit diesen Komponenten dann arbeiten, richtig, das heißt, die müssen sich dann auch an bestimmten Stellen nicht mehr selber überlegen, was müsste denn jetzt hier, wie müsste das und das aussehen, sondern können sich dann eben auch auf Komponenten konzentrieren Verlassen und mit ihnen arbeiten.

Mandy: 22:51

genau. Das ist auch der Vorteil bei der Entwicklung für Product Design. Da wird ganz klar gesagt, schauen unser Designsystem, welche Komponenten hast du zur Verfügung, mit welchen Möglichkeiten haben die Komponenten und damit baue deine neue Seite. Und manchmal passiert es dann auch, dass dann die kommen, ja, könnten wir hier noch das und das erweitern und je nach Aufwand gibt es dann ja, nein vielleicht. Natürlich immer gern Ja,

Stefan: 23:18

schön. wären wir am Ende der Punkte über das Designsystem, die wir reden wollten. Hast du zum Abschluss vielleicht... Noch ein paar Hinweise für Leute, die sich genau mit dem Thema beschäftigen wollen, wo es vielleicht irgendwelche Online-Ressourcen gibt, die vielleicht auch Inspirationen geben können.

Mandy: 23:40

Ja, also im Internet, wenn man einfach mal nach Designsystemen sucht findet man sicher einige. Eine gute Quelle ist designsystems.surf. Da gibt es eine Auflistung von, ich weiß nicht wie vielen Designsystemen aber sehr, sehr vielen. Das finde ich eine gute Inspiration, um zu sehen, welche Komponenten könnten in ein Designsystem gehören, was brauche ich vielleicht auch einfach nur als Inspiration was Könnte ich gebrauchen. Vielleicht sagt man auch, man braucht gar kein eigenes Designsystem, weil da ist schon alles, was ich brauche. Also generell sollte man sich halt vorher überlegen, reicht mir zum Beispiel ein fertiges Designsystem aus? Also ich würde nicht den Aufwand machen, wenn man sagt, das ist völlig okay, wenn ich mit dem fertigen Designsystem arbeite weil die Styles gefallen mir so, die Anforderung oder ist genau das, was ich möchte. Sobald man mehr haben will, würde ich halt immer zu eigenen Designsystem

Stefan: 24:32

Und dann kann man sich genau bei solchen Seiten ein bisschen Inspiration holen

Mandy: 24:35

wir ganz genauso. Also wenn es darum geht zu entwickeln eine neue Komponente oder jetzt zum Beispiel, ich hatte tatsächlich gerade ein Defekt wir haben Models und in einem Model wird der Fokus getrappt, wenn man mit der Tastatur navigiert, damit man nicht rauskommt, bevor man das Model schließt Und diesen Fokus Trapp habe ich vor zwei Jahren für den Date Picker getrappt Gebaut, der Datepicker wieder, weil das auch so ein Element ist, was sich ja unterhalb öffnet und jetzt kam natürlich erst raus, dass das problematisch war, es war ein bisschen kleiner Defekt, das hat nicht so gemacht, wie es soll, wenn zum Beispiel Formulare im Model war, dann hat das ein bisschen komisch reagiert Und auch da bin ich habe ich ein bisschen abgeschaut, ich habe mir einfach mal angeschaut was hat Angular Material Design System gemacht, die haben auch eine Focus Trap, weil ganz einfacher Punkt, wir sind ein kleines Team mit wenig Leuten und da sitzen glaube ich ein paar mehr und ich gehe einfach davon aus, dass wenn die sich darüber Gedanken machen, wie die Technik funktioniert, kann das nicht ganz so schlecht sein. Dann habe ich einfach die Logik die die hatten, übernommen. Das heißt nicht, dass wir eins zu eins den Code kopieren weil die haben noch so viel da drin, was wir gar nicht brauchen oder noch nicht brauchen. Man weiß es nie. Aber Inspiration kann man sich überall holen.

Stefan: 25:51

die haben dann vielleicht eben auch auf Sonderfälle gedacht, die jetzt nicht so offensichtlich sind, Und genau sich da Input zu holen hilft dann ja selber auch eine gute Lösung zu bauen, wo dann die entsprechenden Dinge schon bedacht sind. Super, dann vielen lieben Dank, dass du da warst, dass du uns mit deinen Erfahrungen erleuchtet hast. Ich bin mir sicher, das hat einige von unseren Hörerinnen und Hörern auch weiter erleuchtet und wäre ich am Ende von dem, was ich hier sagen will. Und hättest du noch ein

Mandy: 26:20

Ja, vielen Dank, dass ich das mal ausprobieren durfte mit einem Podcast und über mein Lieblingsthema Designsystem sprechen durfte. Bin auf jeden Fall Fan davon und sage immer, los geht's, einfach machen.

Stefan: 26:33

Und damit bis zum nächsten Mal. Tschüss!