Digitale Design Systeme: "Code is the source of truth"


Ashley: Taktsoft Campus Podcast. Willkommen zurück! Schön, dass du wieder dabei seid. Du solltest als Entwickler ein Frontend entwickeln. Gesagt, getan oder auch nicht. Hinter einer einfache Anforderung stecken viele Themenkomplexe. Welche Kunden Kanäle müssen bedient werden? Welche Systeme müssen integriert werden? Dann stellt sich die Frage Hat jemand bereits Teile implementiert? Können bereits geschriebene Code Snippets wiederverwendet werden? Oft ist die Antwort: Nein und es werden Funktionen und Features immer wieder neu entwickelt. Deshalb die Frage: Was kann getan werden, um mehr Effizienz in der Softwareentwicklung zu schaffen? Heute rede ich mit Jonas Ulrich und Daniel Ley, Gründer der Firma Kickstart.DS. Daniel ist ein passionierter User Experience Manager und Jonas ist leidenschaftlicher Entwickler und, wie er selbst sagt, von Tag eins dabei. Daniel in Jonas erzählen Welche Herausforderungen ein Entwickler sich stellen müssen? Was passiert im Ecosystem? Hilft eine Architektur wie JamStack und die spannende Frage, ob und wie ein digitale Design System helfen kann? Ich freue mich auf das Gespräch mit Daniel und Jonas. Und wie immer, wenn ihr Themen habt, die ihr gerne in einem Podcast beleuchtet haben möchtet, schickt uns eine Email an podcast@taktsoft.com.


Ashley: Hallo, Jonas. Hallo, Daniel. Wie geht es euch heute Abend?


Jonas: Gut, gut. Sehr gut.


Ashley: Ja. Schön, euch wiederzusehen. Ich muss sagen, wir haben in der Vergangenheit mit beiden von euch mal Podcast aufgenommen. Jonas, wir hatten mit dir glaube ich über das Thema Webcam uns mal unterhalten und was da passiert. Und ja, das war das ganze Thema XY und wie man wie man diese Themen im Entwicklungsprozess mal einbindet. Wenn ich mich richtig erinnere. Genau, genau. Ja, und da sind ein paar Sachen bei euch passiert, sage ich mal so zwischendurch Ihr habt ihr beide zusammen eine Firma gegründet, die Kickstart der ES habt ihr gegründet. Ich hatte mal einen Podcast mit dem Search gemacht, vor ein paar Wochen, wo es um die Transformation eines Unternehmens ging. Und er erzählt natürlich Ein wichtiger Punkt ist dann zu schauen, was kann ich als Mehrwert zu meinem Kunden geben? Nicht nur welche Produkt verkaufe ich, aber welchen Mehrwert kann ich dann meinen Kunden geben? Deswegen so meine erste Frage wäre okay. Habe dann entschieden so eine Firma zu gründen, aber welche Problem wollt ihr dann eigentlich mit dieser Firma lösen? Was war da? Was war der Anreiz zu sagen wir machen was neues? Und was ist das Problem, was ihr auf dem Markt sieht, wo er dazu was beitragen könnte oder aus Lösungen dazu beitragen könnt?


Daniel: Ja, also ich fand ganz spannend in meiner Zeit vorher bei Amadeus. Da habe ich auch neben meinem Job als Manager eben auch global am Design System mitgearbeitet und auch mit dem Design Upstream gearbeitet. Und das kam halt aus dem Grund heraus, dass man immer wieder für jedes Produkt neu starten musste. Entweder mit neuen Technologien steckt dahinter, aber jedes Mal musste man den Button immer wieder neu gestalten, um dem Brand zu entsprechen, der Konsistenz zu entsprechen und immer mehr. Immer wieder wurde der auch ins Marketing übertragen und Jonas und ich, wir kennen uns schon sehr, sehr, sehr lange und wir haben immer wieder über solche Themen gesprochen. Und da haben wir gedacht, dass wir einmal unsere Kräfte verbinden, unser Wissen verbinden, um halt eben ein Designen, ein Framework zu schaffen, mit dem man sehr schnell solche Design Systeme an den Start bringen kann. Deswegen auch Kickstart DS und das DS dabei für Design System.


Jonas: Ja genau das ist so wirklich die Idee dieses Kickstart. Vor allem das ist doch das, was immer gut ankommt. Wenn man mit Leuten darüber spricht, stellt man fest Das wird schnell verstanden.


Ashley: Aber aber dann, wenn ich sie dann kurz zu dir da zurückgehe, du hast gesagt, dann auch dieses Wunsch nach Konsistenz. Was meinst du dann genau damit? Mit Konsistenz? Redest du da oder ist das Thema dahinter? Verschiedene Kunden, Kanäle, verschiedene Touchpoints oder was? Was? Was heißt es dann eigentlich zum Thema? Oder was will so ein Enterprise Kunde mit Konsistenz dann erreichen?


Daniel: Ja, das sind letztendlich ganz viele Stakeholder mit im Spiel und also ein größeres Unternehmen hat etliche digitale Touchpoints mittlerweile und wir spüren, es werden auch immer mehr, da ist die eigene Webseite, da ist vielleicht ein Blog, da ist ein Intranet, dann gibt es vielleicht auch digitale Produkte. Je digitaler die Firma aufgestellt ist, desto mehr digitale Produkte sind vertreten und desto mehr User Interfaces für solche Produkte und desto mehr vielleicht auch technische, technisch unterschiedliche Backend dahinter. Und oftmals historisch begründet hat dann jedes Backend sein eigenes Frontend. Das ist noch viel zu selten voneinander getrennt. Und dann habe ich auf der anderen Seite die Marketingabteilung, die möchte, dass meine Marke als Unternehmen korrekt und auch kohärent präsentiert wird über all diese digitalen Kanäle hinweg. Dann habe ich meine Anwender, die oftmals auch mehrere meiner Kanäle nutzen und die auch vielleicht dann eher unbewusst diesen Medien auch spüren. Dann ist in der Anwendung der Button so total rund, weil das war zu der Zeit der Zeitgeist in der Gestaltung. Der hat zwar dann die Corporate Farbe, aber sieht aus wie eine Pille. In der anderen Anwendung ist er eher klein und knuddelig und ein bisschen eckig. Und dann ist oftmals der kleinste gemeinsame Nenner das Set an Farben, was ich solche Applikationen und digitalen Touchpoints miteinander teilen. Und wir sehen halt es wird immer. Wichtiger, dass das Vieh konsistenter ist, das man auch in der Entwicklung Werkzeuge bietet, die das Leben der Entwickler einfacher machen. Nicht immer wieder von Neuem anzufangen, nicht immer wieder den Button neu zu gestalten und und da halt eher auf ein gutes Set zu setzen. Eben ein Design System, wo sich all diese Komponenten konsistent vererben.


Ashley: Dann gehe ich mal kurz dann zu Jones. Ich sage mal so Jones du kommst aus der eher aus der Agentur Seite, das heißt Daniel, sag ich jetzt mal so eine Art deiner, deine alte Rolle zu den Enterprise der Kunde und du gehst genau zu Jones von der Agentur seite hin, sozusagen. Ich will genau diese Konsistenz haben, genau diese Touchpoints. Und so weiter und so fort. Das heißt aus der aus der Agentur sicht oder vielleicht aus der Entwickler Sicht das was was Daniel mal mal kurz angesprochen hat das Thema Leben der Entwickler einfacher zu machen. Was bedeutet das dann für dich, Jones oder für dich als als in Anführungsstrichen Agentur der Jim, der das bauen muss? Was bedeutet dann diese ganze Theme für dich dann?


Jonas: Genau. Also so ein bisschen ist das ja auch die Historie, wie das Ganze entstanden ist, dass wir halt gesehen haben, dass wir selber unsere Arbeit sehr oft wiederholt haben, eben als Agentur, die für Mittelständler CMS Systeme aufstellt und da immer auch mit dem Frontend zu tun hatte. Natürlich logischerweise. Und da haben wir halt sehr früh schon festgestellt, das macht total viel Sinn, das strukturiert zu wiederholen, was man lernt und nicht halt jedes Mal komplett bei Null anzufangen. Tatsächlich ist es aber so, dass halt sehr, sehr oft noch bei Null angefangen wird und das hat halt viel damit zu tun, wie wiederverwendbar Code ist, der gerade im Frontend geschrieben wird, da der halt häufig von Backlinks abhängt. Und das war bei uns in der Agentur Geschichte immer so, man integrierte irgendein Frontend ins Backend und das ist ein sehr aufwendiger Prozess. Ist das dann eher so der zweite Gedanke, den man irgendwie auch noch machen muss? Man wählt dann das CMS, man stellt das alles korrekt ein und dann sorgt man noch so gut es geht dafür, dass es richtig aussieht. Aber im Grunde ist die Frontend Entwicklung immer so ein bisschen nachgelagert und auch so ein bisschen wie Wegwerf Ware betrachtet. Irgendwie. In zwei drei Jahren kommt ja eh der Relaunch, dann muss ja eh wieder alles anders aussehen, da schmeißen wir eh wieder alles weg. Ist da so ein bisschen lange die Maxime gewesen. Und da haben wir halt auch früh schon gesagt, wir versuchen da langfristiger zu entwickeln. Und das ist auch der Background, wo wir dann gesagt haben, das macht Sinn, als Produkt eben zu sagen, diesen Startschuss in so ein Projekt, eben die ganzen Basics, die Daniel auch schon erwähnt hat, dass halt ein Button ein richtiger Button ist, dass da die richtigen Elemente drin sind, um den Content zu pflegen, den ich darstellen möchte, damit ein Redakteur sich auch wirklich auf die Strategie dahinter konzentrieren kann und nicht in Details festhängt dabei, was seine Elemente können und was nicht und wie ihn das halt entweder ermächtigt oder eben auch dabei behindert, seinen Job gut zu machen. Und gerade diese Wiederverwendbarkeit und diese Langlebigkeit, die man im Design System im Frontend etablieren kann, die gibt irgendwie auch dem ganzen Thema erst so das richtige, angemessene Gewicht aus meiner Sicht. Also das ist am Ende, was Nutzer sehen, womit Nutzer interagieren, wo ich meine Botschaften transportiere, wo Nutzer meine Funktionen wahrnehmen und verwenden, dort möchte ich halt gut sein. Und dann sollte man dort auch viele Gedanken investieren und es eben nicht als Wegwerf Produkt sehen. Und das ist gerade etwas, was Design Systeme aus unserer Sicht ermöglichen, neben vielen anderen Punkten wie auch Dingen wie Multi Branding und solchen Mandanten fähigen Systemen. Also wenn man zum Beispiel auch bestimmte Bereiche in seinem eigenen Öko Kosmos hat, wo Dinge anders aussehen müssen wie die Kunden die man selber betreut oder so auch da gibt es dann im Design System durch die Strukturen, die da auch gerade langfristig geschaffen werden, viel mehr die Möglichkeiten auf so was effizient einzugehen. Und da spart es halt dann wirklich sehr viel Entwicklungszeit, weil man eben diese Basics nicht zwei drei mal immer wieder.


Ashley: Durchspielen und nicht nur die reine Entwicklungszeit, aber das ganze Thema das diese ich mal so Komponenten dann Bereichs durch einen Qualitätssicherung Check durchgegangen sind. Und wie gesagt nicht nur das reine ich muss ich brauche jetzt eine Stunde oder zwei Stunden um das zu schalten und Unit Test zu machen. Aber das ganze Rundherum.


Jonas: Das ist so ein bisschen halt auch so die Erfahrung, die man gemacht hat, dass das halt als erstes hinten runterfällt. Wenn es dann schnell gehen muss, dann wird halt bei der Qualität gespart und quasi nur noch das gemacht, was nötig ist, um über die Hürde zu springen. Es ist dann aber schnell nicht mehr irgendwie wirklich exzessiv oder Performance mäßig optimiert. Also aus SEO Sicht nicht optimal. Da gibt es dann sehr viel, was unter die Räder gerät, eben weil dann dafür nicht mehr die richtige Zeit da ist. Und meistens ist dann vor allem für die Dinge, die man als Besonderes sich überlegt hat, erst recht keine Zeit mehr da. Also irgendwie doch noch mal was Nettes Eigenes für ein Projekt zu machen, was es besonders macht oder herausstellt, sondern man verbrät sehr viel Zeit mit den Basics.


Daniel: Und und da sieht man auch schon ganz essenziell, wir sprechen jetzt schon immer über diese Basics und eben den Code und die Wiederverwendbarkeit dessen. Und das ist auch so wichtig, weil. Viele Kunden oder auch Menschen aus dem Umfeld der IT. Wenn man über Design Systeme spricht, dann denken die halt immer noch vorrangig an das Design. Und wir sprechen jetzt schon sehr stark auf dieser Code Ebene des Design Systems. Das ist die Library und und das müssen wir immer noch allen bewusst machen. Das ist auch ein Prozess, den es braucht, dass eben letztendlich Anwender, egal was sie bedienen, die interagieren mit Quellcodes, Quellcode, der ein Interface darstellt. Und ja, das Interface ist designt worden, aber im besten Fall in einem Zusammenspiel aus dem gesamten Team mit UI Designern und dem Entwickler und vielleicht dem Product Owner und wen es noch so braucht aus dem Marketing. Und so weiter. Und das ist auch ganz wichtig, da einfach zu differenzieren. Und viele denken einfach noch, da steht Design drauf. Also es ist ein Designer Thema, das ist ich. Ich kenne diese Leidensgeschichte mit dem Begriff UX Design. Da steht Designerin, also geht es um irgendwie. Wir machen das jetzt um gut nutzbares Design, aber letztendlich verbirgt sich hinter dem Begriff UX viel, viel, viel, viel mehr. Und hier ist es halt eben auch. Und deshalb versuchen wir auch schon, wenn wir darüber sprechen, immer das zu spezifizieren, zu sagen, dass es ein digitales Design System, um eben auch den Fokus auf diesen digitalen Part zu setzen. Es gibt auch diese noch größere oder holistische Klammer drumherum. Das ist das Design. System ist alles, was die Marke ausmacht. Das ist auch wie sprechen wir mit unseren Kunden, das sind unsere Werte, unsere Philosophie. Und so weiter. Und aber nichtsdestotrotz bricht es letztendlich in der digitalen Welt immer darauf hinunter, dass Menschen mit Quellcode interagieren.


Ashley: Denn dann stelle ich trotz deiner Beschreibung da die Frage Wie würdet ihr dann kurz und knapp dann so ein digitales Design System erklären? Was was steckt wirklich dahinter? Du hast viel über Quellcode gesprochen. Verbindung von Es ist nicht nur Design, aber so kurz und knackig zu sagen. Doofe Frage Was ist es dann? Was? Was ist es? Was ist dann das Design System?


Jonas: Ich würde sagen, es ist eine Art Code Library, im Grunde ein möglichst direkt einsetzbares Stück Software, das Entwickler nutzen können, um ihre Arbeit effizient zu gestalten. Und das beinhaltet dann halt so ein paar Dinge, würde ich sagen und auch so ein paar Ebenen, durchaus in sich schon, die unter anderem dafür gedacht sind, verschiedene Entwickler und Stakeholder entsprechend dort abzuholen, wo sie gut bedient werden können. Das fängt halt an mit sehr allgemeinen Design Tokens, die das Design, das Kern Design an sich definieren. Da sagt man mittlerweile auch ganz gerne die atomaren Entscheidungen in meinem Design System sind eigentlich die Design Tokens. Und darauf aufbauend geht es dann im Grunde immer weiter runter, hin zu konkreten Komponenten, die ich direkt installieren und in mein Projekt ziehen kann, die diese Tokens entsprechend wieder verwenden, um diese Konsistenz zu erzeugen. Und so weiter. Also man kann da sich sehr viel vorstellen und da gibt es auch mittlerweile sehr viel Bewegung in dem Bereich, zum Beispiel aus den Tokens auch Teams zu generieren für Bootstrap oder andere Ansätze wie Material. Ui, da kann man sich sehr viel denken. Im Grunde, wie gesagt, geht es aber immer darum, die Entwickler und entsprechenden Nutzer eines solchen Systems intern halt abzuholen. Und das ist dann ganz unterschiedlich, ob das viele Entwickler sind, ob das vor allem viele Designer sind. Also da sind die Prozesse auch sehr unterschiedlich. Aber es geht immer darum, etwas konkret Greifbares, etwas Nutzbares zu liefern.


Ashley: Und bei diesem Fall auch noch.


Jonas: Ein Ort für Austausch. Aber vor allem dieses direkt Einsetzbare ist natürlich der Kern.


Ashley: Und wenn ich dann zurückblicke in unseren letzten Podcast, wo wir das ganze Thema Web Components uns uns darüber unterhalten haben, was ist dann da eigentlich der Unterschied zwischen so ein Design Systeme und Web Companies mit verschiedenen Standards usw wo, wo, wo, wo ist dann der? Wo ist dann der ausschlaggebende Punkt wo man sagt okay hey, das ist jetzt was neues.


Jonas: Also ich würde sagen, Web Components ist im Grunde eine Möglichkeit, Komponenten zum Beispiel zu implementieren. Das ist erst mal völlig unabhängig von Tokens. Also wenn man sich so unser Design System anguckt, dann habe ich meine Tokens und dann darunter vielleicht eine oder mehrere Arten Komponenten zu bauen. Und ein Weg könnte eben sein, Web Components einzusetzen. Das heißt, ich würde sagen, es konkurriert gar nicht, es ist eher so orthogonal zueinander. Also ich kann halt wählen, wie ich meine Komponenten später implementierte. Man muss aber auch sagen, da sind weiterhin Web Components noch nicht super etabliert und das hat so ein paar verschiedene Gründe. Also zum Beispiel die Server seitige Generierung, das ist so ein Thema. Was für SEO immer sehr wichtig ist, ist da noch nicht so etabliert, das heißt, nur mit JavaScript im Browser kann ich dann wirklich den Inhalt sehen von solchen Komponenten. Aber es hat auch noch ganz konkrete andere Nachteile, wenn jetzt über Design Systeme redet, wenn man es ganz streng implementiert. Ich weiß nicht. Wenn man die Episode sich noch mal anhört, die wir schon mal hatten, haben wir da sehr viel über den Shadow Doom gesprochen und wie er dabei hilft, Stile zu isolieren. Das ist in einem Design System und bei Konsistenz als hohem Ziel gar nicht immer so das, was man sich wünscht. Da möchte man eigentlich eher dann doch von oben herab das richtige Design forcieren, als sie jedem einzelnen Element zu überlassen, sich korrekt aussehen zu lassen. Das ist deswegen vielleicht so ein kleiner Einschränkung, warum man bei Web Components jetzt auch noch nicht so schnell viele Design Systeme gesehen hat. Also die meisten sind eben in JS, React und teilweise noch Angular, weil es auch die etablierten Technologien in dem Bereich sind, die da einfach viel mehr bieten. Aber das ist so ein Grund dafür, warum vielleicht Web Komponente sich da auch weiterhin nicht so wie man sich es vielleicht auch wünscht, durchgesetzt haben.


Ashley: Verstehen verstehe, aber eher als.


Jonas: Orthogonal als jetzt wirklich, dass es im Widerspruch stände oder man sich entscheiden müsste.


Ashley: Okay, man kann es kombinieren. Verstehe. Und dann Daniel, was passiert so auf dem Markt momentan? Man hört Schlagworte wie wie Samstag ist also wie will Lamp ihm im Frontend Umfeld sag ich mal so aus der Layer mal so erzählt was was passiert auf dem Markt und vor allen Dingen es gibt so ein paar Big Players auf dem Markt. Ich sage jetzt mal so Ikea aus. Als Beispiel tut sich da was.


Daniel: Da tut sich in ihn mit allem, was du genannt hast, in vielerlei Hinsicht eine ganze Menge, also das ganze Thema James Stack, das überlasse ich jetzt gleich dem Jonas, weil da geht es halt eher um wie, wie, wie setze ich meinen Text Geek auf und die Trennung von Backend und Frontend über APIs. Du hast auf Sigma angesprochen. Ja, so recht. Da passiert sehr viel am Markt und und das ist auch wieder eine gute Bestätigung dafür, dass das Design in dem Begriff Design System noch so ein bisschen die Überhand hat. Also Sigma ist mittlerweile das, ich würde sagen eigentlich das hauptsächliche Design Tool für digitale Produkte geworden. Es hat auch sehr viel, ähm tolle Funktionalitäten, die damals einen Sketch angefangen hatte reinzunehmen, die Adobe XT versucht nachzuahmen. Und Ikea macht das schon wirklich sehr, sehr sehr gut. Dem Designer ein Werkzeug an die Hand zu geben, ein fast reales Web Layout zum Beispiel zu designen, was ich auch response verhält, wenn man es testet. Man kann sehr schnell Prototypen bauen, man kann auch komplette Design Systeme vor designen. Und da haben wir aber dann wieder dieses Problem wie auch früher. Dieses Big Design Up Front zahlt sich hintenraus nie aus. Also entweder sprechen, also ist es ein Hand in Hand Prozess und dann wird auch geknotet und designed und das immer sukzessive so gesteigert. Aber in Ikea wird gerade wahnsinnig investiert. Jeder benutzt es. Man sieht ganz viele Blogposts. Es gibt etliche Addons und Plugins, die auch versuchen, diese Design Token Welt schematisch und strukturiert in das Design Fall zu bekommen. Immer mit der großen Hoffnung Das höre ich auch, wenn ich mit vielen Designern spreche und mich austausche, dass doch irgendwann, dass man aus dem Design Tool heraus heißt, fertig bedienbar alle Komponenten generiert, so dass man ja eigentlich gar kein Development Development mehr braucht. Das ist halt so der hehre Wunsch und und auch unserer Ansicht nach ein absoluter Mythos, der auf lange, lange Sicht nicht existieren wird, weil dann letztendlich doch Technologie viel zu komplex ist, wie wie wir Firma, sage ich mal, Framework agnostisch Komponenten generieren, die vielleicht mit WHU, JS, Angular und React laufen können und und und. Das ist vielleicht jetzt ein ganz guter Bogen, auch an Jonas, wo wir bei Frameworks sind und agnostisch.


Ashley: Oder vielleicht mal spielen wir den Ball jetzt zu der Idee und genau dieses, dieses Thema, Frameworks und Schlagwort, was ich vorhin erzählt habe bei jedem Stack, was man tut, das hilft das hilft das nicht.


Jonas: Ich würde sagen, dass es sogar sehr hilft und so ein bisschen eine der Vorbedingungen war, damit jetzt so Design Systeme auch effizienter im Einsatz werden können, weil halt ganz zentral drinsteckt und das ist auch, kann man es fast ein bisschen reduzieren, das Frontend wirklich sehr sauber vom Backend zu trennen. Du hast den Vergleich schon genannt, wenn man sich so Slapstick anschaut wie Linux, Apache, my secret PHP quasi als die Technologien, die man einsetzt, um sein Projekt zu realisieren. Dann steht oder stand zumindest auch, dass Jam in Jam Stack mal für quasi eine Abkürzung JavaScript API und Markup. Das ist so zu verstehen, eben genau als diese Entkopplung an der Stelle. Man hat die API oft ein CMS System, vielleicht aber auch eine ganz strukturierte API, vielleicht sind es auch mehrere und die werden dann vom JavaScript, also von einem Generator. Da gibt es auch wiederum verschiedene, zusammengefügt zu einem Frontend und dafür werden dann natürlich irgendwie Komponenten benötigt, um dieses Frontend zusammenzusetzen. Aber dieser Generator ist quasi die entkoppelte Stelle. Die macht es möglich, das Frontend sehr unabhängig vom Backend zu entwickeln und im Grunde auch so weit zu entkoppeln, dass sich zum Beispiel ein Frontend behalten kann und nur das Backend wechseln. Das ist so ein bisschen was, was früher undenkbar gewesen wäre, weil meistens mein Frontend sehr tief verbandelt ist mit der Architektur, auf der ich meine Weekend Anwendung aufsetze. Also diese Trennung ist sehr schwer zu erreichen und natürlich gibt es da auch schon lange irgendwie Schnittstellen und irgendwie Rig Clients im Browser und Single Page Apps. Aber da ist jetzt gerade mit James Stack noch mal richtig Bewegung reingekommen. Dadurch, dass das so große Player wie eben diese Generatoren next js spi JS gibt, die viel Funding eingesammelt haben. Es gibt sehr viele CMS Systeme, die jetzt auf diese Art APIs anbieten. Das macht da halt sehr viel Dynamik möglich und lässt dieses Denken über Frontend überhaupt erst nach. Zu sagen, ich investiere vielleicht auch ein bisschen mehr, weil ich kann das ja vielleicht auch viel länger Gewinne auch brauchen, wenn ich das einmal angelegt habe und dann vielleicht eher so ein Mix and Match aus Backend Services betreiben und vielleicht da ab und zu mal das System wechseln, wenn ich merke, es funktioniert nicht so, habe aber in dem, was für mich eigentlich der größte Wert ist, meine äußere Präsenz halt eine gewisse Stetigkeit drin. Eben neben so einer Effizienz natürlich, ich muss nicht immer wieder neu bauen, aber es bleibt halt doch einfach da, wenn es noch gut ist und es ist selten schlecht. Wenn irgendwie ein Relaunch ansteht, ist es selten nötig, wirklich einfach alles wegzuschmeißen.


Daniel: Und das muss ich auch ehrlich sagen. Ich komme eher auch aus dieser Design Historie heraus. Und als ich das zusammen mit Jonas kennengelernt habe und nehme das als gezeigt habe und wir auch letztes Jahr erstes Projekt für den Kunden gebaut haben, was eben mit diesem Stack funktionierte und und im Frontend. Ein ein gleiches Erscheinungsbild haben sollte und wie schnell dieser Prototyp zusammen geklickt war mit einerseits Serenity als CMS dahinter sind die Studio als CMS Lösung. Dann hatten wir einen Daten Dump mit Produktdaten, die haben wir in ein Table übertragen und dann haben wir noch ein Teil, ein Teilbereich für den für den Blog mit einem WordPress, was wir Hitlers Nutzen bedient. So, und dann hatte jeder, jeder Redakteur in dieser Bedien Kette eigentlich das für sich jeweils perfekte Frontend. Der Marketer, der konnte relativ einfach und gewohnt in der WordPress Umgebung seine Blogbeiträge schreiben und News Artikel Publishing. Und dann hatte man auf der anderen Seite Serenity, mit dem man halt die Webseite bestücken konnte und dann gab es eine Buchung Strecke für diese Produkte, die wo die aus Erdkabel gezogen wurden und wo teilweise Produkte auch nochmal aus sensitiv eingesetzten ergänzenden Content hatten. So wie so ein paar Puzzlesteine, die zusammengesetzt werden und insgesamt dann wahnsinnig glänzendes Bild ergeben mit einer eklatanten Performance vorne raus. Weil das ganze die ganzen verschiedenen Datenquellen kommen dann zusammen in einem stetig Seite Generator und der baut dann eben die Webseite oder die Applikation eben zusammen und das ist auch maximal performant für den Nutzer in der bedienen Geschwindigkeit.


Ashley: Und was sich dabei ist. Was sie dabei da herausgehört habe. Daniel Es war nicht den klassischen Ansatz. Wir bauen einen Click Dummy, um zu zeigen, wie es sein könnte, sondern wirklich die ich sag jetzt die Komponenten genutzt, um das zu bauen, sprich dieser, dieses Sprung über den Click dann im Dummy hinaus. Und wirklich, ich nenne es für ein Demo erstmal wirklich echt echten Code zu nutzen, anstatt nur nur dieses Klick. Da habe ich das richtig so verstanden.


Jonas: Ich würde sogar sagen, es geht sogar ein Schritt weiter. Also der Klick ist durchaus ein total legitimer erster Schritt, der aber genauso davon profitiert, wenn ich gute Komponenten habe, wo ich ein genaues Bild davon habe Was sind ihre Funktionen, was sind ihre Werte? Wie kann ich sie verändern? Dann kann ich von dem einen sehr schnell ein Klick Dummy erstellen und habe dann von einem solchen Click Dummy hin zu einer wirklich im CMS belegbaren Seite kaum noch Brüche, weil die Komponenten einfach immer die gleichen bleiben. Von vorne weg also der Prototyp, wenn ich ihn denn dann baue oder so ein Klick Prototyp hat an sich schon eine sehr viel höhere Produktions reife hat, eben weil er auf diesen bestehenden Komponenten aufsetzt. Und wenn dann die Entscheidung fällt und das schöne ist, bis dahin kann das komplett ohne Backend in Wolfen passieren. Man baut einfach genau das im Frontend auf, wie man es denkt, es aussehen sollte und dann die Entscheidung fällt, dass es so gut ist. Ist halt das Anschließen von einem CMS im besten Falle fast automatisiert, weil ich ja genau weiß, welche Felder ich in meinen Komponenten hab. Hat eine Headline, kann ich die Größe der Headline einstellen? Was sind eben genau diese Freiheitsgrade für so einen Redakteur? Das weiß ich im Grunde alles vorher schon, weil ich meine Komponenten kenne und dann sehr einzeln einfach entscheide. Welche dieser Optionen sind für den Redakteur relevant? Also muss er die Ausrichtung der Headline einstellen oder soll er es gerade nicht können? Und in dem Bereich kann man dann sehr effizient Entscheidungen treffen und auch so ein CMS anbinden, eben weil man diese Komponenten halt gut konzipiert hat und die einen sehr guten definierten Zweck erfüllen. Das ist halt immer wichtig und das kann im Grunde nur im Code nachher passieren. Genau diese zentrale Definition. Aber das hat doch gar nichts mit Design zum Beispiel zu tun. Also dieser Punkt, den ich meinte, warum ist so was resistent gegenüber Relaunch is, weil wird über struktur reden. Es geht um Struktur von Komponenten und die ändert sich ganz, ganz selten, ganz selten braucht man eine Sub Sub Sub Headline. Also da sind alle Optionen dann irgendwann auch durchdacht und auf der Ebene ändert sich gar nicht so viel. Strukturell ändern tut sich viel im Design Bereich, also da wo man jetzt heute viel mit Tokens machen kann. Das ist so ein anderer großer Bereich in Design System.


Ashley: Das ist dann eher Funktion vor, vor und danach Form. Denn dass man dann Funktion, Konzentration auf die Funktion und wie die es beim Relaunch dann, ob die Erscheinungsbild dann halt anders ist, der Button.


Jonas: Dann ein bisschen mehr Rundung hat oder.


Ashley: Nicht. Das wäre eher ein Button oder die Funktion des Buttons ist ist immer noch das gleiche. Ein wichtiger Punkt, das, was ich rausgehört habe in in den letzten Minuten, als wir miteinander gesprochen haben, dass wirklich das Thema Design System ist mehr als Design. Es heißt zwar Design System, aber nicht nur mit Betonung auf Design. Das ist glaube ich ein Punkt, was wir wirklich haben, die Zuhörer auf dem Weg geben müssen. Gibt es irgendwelche andere Knackpunkte von von eurer Seite aus? Wo, wo, wo, wo du die Zuhörer sagst Ja, das muss die auch wirklich mitnehmen aus diesem Podcast. Nicht nur was ich da gerade gesagt habe, es ist mehr aus Design. Ihr habt über das Thema Wiederverwendbarkeit gesprochen. Gibt es so Knackpunkte, wo ihr sagt Das ist wichtig, das, dass das klar rübergekommen ist?


Jonas: Als noch nicht viel über über Stakeholder, Management und so gemeinsame Begrifflichkeit, Glossar und so gesprochen. Das würde ich sagen, ist noch ein sehr wichtiger Aspekt der hier Auch wenn sehr viel Code hier eine Rolle spielt, ist es eben auch nicht nur Code. Also Code muss auch gewollt, verstanden und dann eingesetzt werden, damit er funktioniert. Und dafür muss halt auch erklärt werden. Und das hat viel damit zu tun, die richtigen Personen mit so einem Tool abzuholen. Eben zum Beispiel so ein Story Book ist ein super etabliertes Tool, was man, wenn man es ein bisschen einstellt, auch durchaus zugänglich für Designer machen kann, um so ein bisschen Dinge erfahrbar zu machen. Und da geht es dann schon darum, eben einfach Konversationen möglich zu machen, die früher eher als Konfrontation vielleicht verstanden wurden oder als sehr großer Übergabe Prozess mit sehr viel Verhandlung oder so zwischen Design und Development. Also da ist schon würde ich sagen, auch eines der Ziele, eben diese Mauern so ein wenig einzureißen und eben zu so einem wirklich eher interdisziplinären Verständnis noch weiter zu kommen. Also ich glaube, in vielen Bereichen hat das schon angefangen. Ich glaube, das kann aber noch viel, viel weiter.


Ashley: Und Daniel, etwas von deiner Seite aus? Oder meinst du, dass wir die die wesentliche Sachen wirklich mal abgedeckt haben?


Daniel: Ja, wir haben. Also es gibt noch so viel dazu zu sagen. Deswegen glaube ich, kann man da nie wirklich das Ende finden. Letztendlich gibt es Design Systeme schon seit den 90 er Jahren, also auch auf diesem digitalen Umfeld, dass man halt eben auch in Komponenten arbeitet und das versucht irgendwie möglichst wiederverwendbar zu machen. Und nichtsdestotrotz ist es heute eher an der Zeit, dass das, dass das Thema mehr Aufmerksamkeit findet. Wirklich auch von den Designern, von den Entwicklern, weil halt eben auch Web viel, viel wichtiger wird und zentraler und man nicht mehr irgendwie diese gekapselt monolithischen kleinen Softwarelösungen halt hat. Es wird immer immer stärker web driven und deswegen war halt auch viel Bewegung und viel Entwicklung. Und das freut mich halt, dass jetzt endlich die Zeit dafür reif ist, auch diesen Begriff Design System mehr in die Hand zu nehmen, das mehr Verständnis dafür zu schaffen. Und letztendlich leisten sich das im Moment immer noch große Firmen. Konzerne entwickeln selber diese Systeme für sich, weil sie halt erkannt haben, dass man damit effizienter und effektiver arbeiten kann und letztendlich auch Kosten effizienter. Das ist noch was, was man mitnehmen kann. Das ist natürlich am Anfang ein Invest, aber der rechnet sich mit langfristig sehr, sehr, sehr, sehr schnell. Also die Nachhaltigkeit. Bloß halt auch, dass die Entwickler in der Regel eine bessere Experience haben beim Entwickeln, wenn sie auf solche moderneren Stacks und Systeme zugreifen können. Und da, und das ist verstehen wir auch so ein bisschen als unsere Aufgabe mit Kickstart DS da so den nicht nur den Begriff, sondern generell Design Systeme so zu demokratisieren und den Zugang einfacher zu machen.


Ashley: Genau das. Das wäre eigentlich der Punkt. Ich glaube das was Sie beide erzählt haben in den letzten 30 Minuten, ihr habt viele Interesse geweckt. Und wenn man irgendwie du sagt, es da vielleicht ist, gibt es keine Ende. Wir könnten jetzt vielleicht noch eine Stunde Stunde uns mal unterhalten, aber wenn man sagt okay, oder wenn jemand sagt, ich möchte jetzt mich mal mehr informieren, ich will ein bisschen mehr über diese ganze Thema Design System Vorteile, wie das alles funktioniert? Gibt es irgendwelche Tipps wo, wo, wo? Du sagst ja geht dann dahin? Und dann gibt es auf jeden Fall Information, die die Leute auch einmal von der design seite, aber auch von der coding seite, wo die sich mal tiefe drüber informieren können.


Daniel: Also es gibt einen ganz bekannten Advokaten der Szene, das ist Nathan Curtis, der schreibt seit vielen Jahren immer sehr ausführlich aus vielen verschiedenen Perspektiven über das Thema Design Systeme bis hin zu wie setze ich das in der Organisation in meinem Gira auf? Der hat auch diesen letztendlich so ein bisschen den Term geprägt. Das Design System ist eben kein Produkt, sondern es ist ein Service, den man aber wie ein Produkt pflegen sollte und und dann kann man natürlich auch auf unserer Website auf Kickstarter die scoren. Wir haben jetzt auch angefangen immer mehr Artikel zu veröffentlichen in englischer Sprache, aber wo wir versuchen, mehr Einblicke in die Systematik zu geben. Und auch in die Thematik super.


Ashley: Ich glaube schon, dass die Leute da hingehen, dass sie eine Menge gute Hinweise bekommen werden. Jonas Also noch. Ja, klar. Jonas Bitte.


Jonas: Ja, weil ich ja irgendwie immer die Lanze für für Spex brechen muss, auch nach meinem letzten Auftritt hier. Die W3C Token Spec kann ich da auch nur nahelegen, sich die mal anzuschauen. Das ist aus meiner aus unserer Sicht ein super elementarer Bestandteil, zukünftig von Projekten mit solchen Tokens zu arbeiten. Da kann man sich sehr gut informieren, wie die Grundlagen gerade gelegt werden und wo man bis dahin irgendwie so ein Stepstone braucht, weil man sagt, das ist mir noch zu theoretisch, das ändert sich zu oft. Durch das Dictionary von Amazon ein Tool, sehr empfehlen. Das ist auch der Basis Grundstein gewesen für die Spec. Tatsächlich, die werden ja mittlerweile sehr aus der Praxis abgeleitet.


Ashley: Zum Glück sehr konkrete Hinweise. Super! Jonas Daniel, ich bedanke mich recht herzlich bei euch. Es war ein sehr aufschlussreiches, interessantes Gespräch. Ja und ich freue mich auf das Nachfolger Podcast mit euch. Vielen, vielen herzlichen Dank und toi, toi, toi, tschüss!


Daniel: Ja, danke. Ebenso auf bald.


Jonas: Tschüss


Ashley: Taktsoft Campus Podcast. Im Podcast für Software IT Professionals! Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Taktsoft Campus Podcast Team.