Transcript

[0:00] Wir nutzen alle den ganzen Tag, ist zumindest mein Gefühl, JSON als quasi Standard in der Front- und Backend-Entkopplung.
Also am Ende sind es eigentlich immer so ganz gleiche Objektstrukturen. JSON halt.
In den Projekten, wo wir dann halt wirklich auch unser Geld mitverdienen, sind wir halt maximal effizient dann, weil wir halt viel, viel schneller sind.
Und dann halt auch nochmal eine ganz andere Konversation mit den Kunden führen können.
Auch da, man sagt auch Spaß oder sagen wir auch immer, das dritte Designsystem ist das erfolgreiche. Zwei Bauste zum Lernen und Wegschmeißen.

[0:33] Music.

[1:00] Diese Revision von Working Draft wird euch präsentiert von Hörerinnen und Hörern wie euch.
Auf patreon.com slash workingdraft könnt ihr uns ein paar Euro in den Hut werfen.
Aus euren Beiträgen und unseren gelegentlichen Werbeeinnahmen bezahlen wir allerlei teure Software-Abus und das Honorar unserer Audio-Producerin.
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash workingdraft sehr gerne machen.
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.

[1:29] Revision 607 Wir wären heute zu viert. Aus dem Team wäre dabei der Hans. Hallo.

Revision 607: Design-Systeme im Jahr 2024

https://workingdraft.de/607/

[1:37] Ich bin der Shep und das bedeutet, wir haben wieder zwei Gäste da.
Und zwar einmal den Jonas Ulrich und einmal den Daniel Lay.
Hallo ihr beiden. Hallo. Hallo.
Genau, Jonas, du warst schon mal vor anderthalb Jahren bei uns.
Jens, ich weiß nicht, ob sich die Zuhörenden an dich erinnern, aber falls sie es nicht tun und falls wir neu gewonnene Hörerinnen haben, stellt euch doch mal beide nochmal vor.
Genau, ich fange einfach mal kurz an und hole vielleicht nicht so weit aus wie beim letzten Mal.
Auch nochmal reingehört, da war dann die Vorstellung recht lang, weil sie auch eine gute Überleitung gleichzeitig darstellte.
Aber genau, ich bin Jonas, ich arbeite seit ungefähr 20 Jahren jetzt im Web-Frontend-Bereich, wie auch immer man es nennen möchte. Ich habe da vieles mitgemacht, vor allem auch in Agenturen, in einer eigenen Agentur.
Vor allem, da haben wir sehr lange Websites, so Corporate-Websites im Grunde, größere Websites mit Typo3, so in der Gegend viel gemacht.
Haben da viel Frontend gebaut. Das war auch immer schon so am ehesten, würde ich sagen, meine Passion. Also irgendwie PHP oder irgendwelche Backends waren da jetzt nie.

[2:44] Das Spannendste, würde ich sagen, für mich, sondern wirklich das reine Frontend war schon das, was mich da früh fasziniert hat.
Und dann haben wir halt vor mittlerweile auch erschreckend zweieinhalb, drei Jahren gesagt, wir wollen das alles verändern.
Das Agenturgeschäft, das gefällt uns irgendwie auch nicht mehr so.
So, wir wollen uns eher auf die Sachen konzentrieren, die uns auch Spaß machen und haben halt angefangen, das Ganze in ein Produkt umzuwandeln, wo wir versuchen, anderen die Frontend-Arbeit wiederum zu erleichtern, anhand von dem, was wir vielleicht auch so ein bisschen in unserer täglichen Arbeit selber immer wieder so als Hindernisse gespürt haben oder wir dachten, hm, wenn wir jetzt hier noch irgendwie so ein bisschen mehr Zeit reinstecken könnten, könnte man wirklich qualitatives Ergebnis liefern, aber das gibt dann ja häufig eben genau diese Agentur.

[3:27] Alltag mit Deadlines und Budgets und so weiter nicht unbedingt her, da seiner Passion so weit zu folgen, wie man das vielleicht mit einem guten Produkt kann.
Das ist vielleicht so die Quintessenz davon. Genau.
Deswegen, Daniel, erzähl du doch gerne, was du dazu beigebracht hast, weil ich glaube, das ist dann... Du bist der Partner in Crime, sozusagen.
Und ab da wird es auch spannend im Kontext für diesen Podcast, was wir so machen, denke ich.
Genau. Ja, hallo. Ich bin Daniel, auch aus Bonn, wieder, Jonas.
Ich bin vor zweieinhalb Jahren dazugestoßen nach über 20 Jahren vieler Stationen im Konzern, beim Backgrounds Visual Design.
Eigentlich habe ich aber sehr früh, ich glaube 2003, meinen ersten Usability-Test mitgemacht und damit sozusagen die Leidenschaft für UX entfacht und habe.

[4:16] Damals auch in einer Agentur gearbeitet, eine Online-Agentur, wo wir dann aber auch sehr früh den Shift geschafft haben, weg von vom reinen Dienstleister hin zum Produktunternehmen eine Software gebaut für die Reisebranche, sind dann vom Branchen Primus Amadeus gekauft worden.
Und da habe ich dann viele Jahre lang über viele Stationen eben das ganze Thema UX aufgebaut, mit evangelisiert, war so ein bisschen auch auf so Mittelmanagement-Ebene unterwegs.
Unterwegs und in der ganzen Zeit war auch das Thema Designsysteme für mich immer hochgradig relevant, nicht nur aus dieser Designerperspektive, sondern wirklich, wir müssen eine konsistente, Sprache schaffen, die die Produkte sprechen und wie lösen wir das und eben im Rahmen von Amadeus war das dann so globalgalaktisch direkt mit über 400 Produkten international, Viele Standard-Software-Suiten in den Reisebüros weltweit, wo ich ganz viel gelernt habe und gemerkt habe, da brenne ich auch doll für.
Und als ich dann mit Jonas, wir kennen uns schon sehr, sehr, sehr lange, natürlich hier aus dem regionalen Umfeld.

[5:36] Dann immer mal wieder gesprochen habe, was er denn so macht, eben kam das so zusammen, wo wir gesagt haben, ja, da können wir doch mal versuchen, was draus zu schnüren, wo auch andere Menschen Nutzen haben.
Und eigentlich haben wir so Spaß an dieser Materie, lass uns doch zusammen das mal dingfest machen. Und das war so der Startschuss für Kickstart DS.
Das ist ein Open-Source-Meta-Framework für Designsystem-Erstellung.
Klingt so ein bisschen sperrig, ist auch sperrig, ist ein komplexes Thema.
Und das haben wir angefangen zu bauen und mittlerweile dreht sich auch so unser Geschäft um diese Open-Source-Software.
Also wir haben das Glück, mittlerweile genug Kunden zu haben, die wir betreuen, eben mit Kickstart DS Design System aufzusetzen und dabei merken wir halt auch zunehmend, dass es Organisationen, also dass es ein Thema wird, was immer mehr Momentum erfährt, aber auch wie viele Fragestellungen es halt rund um das Thema gibt.
Also nicht nur, wie fange ich damit an und wie kann ich das gut machen?

[6:50] Wie kriege ich eine gute Konversation hin? Wie kriege ich die Abläufe, die Prozesse hin zwischen Design und Entwicklung und den ganzen Stakeholdern?
Und wie kriege ich es überhaupt in die Organisation reingetragen? Mhm.
Für mich, also so rein definitionstechnisch wäre es ja so, dass ein Designsystem auf jeden Fall ja nicht nur, also es ist ja nicht nur so ein Corporate Identity Style Guide und sowas, sondern das zieht sich dann ja also weiter ein bisschen in die Umsetzung rein.
Das ist ja auch das, was Kickstart DS ist.
Also letztlich ist ja Design eher so im Sinne von Entwurf zu verstehen.
Und dass man dann auch ein Pattern Library und Komponentenbaukasten, also dass das da alles mit drin steckt und nicht davor schon endet, sozusagen.
Das würde ich auch genauso unterschreiben. Und das ist auch, wo wir uns dann immer abgrenzen würden von vielem, was sich Design-System nennt heute schon, aber eigentlich nur in Figma und auch nur auf einer Design-Ebene existiert, wo wir halt immer sagen, das war nie unser Ansatz, wir wollen da im Code ansetzen, wir wollen da ansetzen, wo ab dann auch wirklich Wert geschaffen werden kann, in Produkten, in Seiten, in was auch immer damit gebaut wird.
Das war da für uns von recht früh irgendwie ziemlich klar und ich würde sagen, so im letzten Jahr haben wir auch gemerkt.

[8:14] Dass man auch das nochmal unterteilen kann, so ein bisschen, was das Designsystem eigentlich ist und das, was du jetzt auch vielleicht Komponentenbibliothek nennen würdest oder so, ja auch nur ein Teil wiederum davon ist.
Und dann gibt es Design-Tokens und dann gibt es bei manchen auch noch Language, was wichtig ist, wie schreiben wir Texte, Voice, Ton of Voice, solche Dinge. Also, das ist sowieso schon hochgradig custom, je nachdem, mit wem man redet.
Was sind die für dich wichtigen Punkte, was auch schon zeigt, wie sehr es halt von der Organisation aus unserer Sicht abhängt, mit der man zu tun hat, mit welchen Personen man dort zu tun hat.
Also, da gibt es wenig, was man dann doch wiederum als Blueprint so runterbrechen könnte, glaube ich. Was wir interessant fanden, war so ein bisschen die Erkenntnis, ein Design-System ist eben nicht auch nur eine Component-Library.
Und im besten Falle hat sie auch Wert für Leute, die nicht deine Component-Library vielleicht benutzen wollen, die vielleicht trotzdem deine Tokens verwenden können, die trotzdem nachlesen können, wie sie kommunizieren sollen.
Also so ein bisschen der Gedanke, ein gutes Design-System holt jeden halt da ab, wo er ist und versucht nicht, jeden dahin zu zwingen, wo es ist, so vom Spirit her.

[9:22] Das finde ich gut. Vielleicht kann man darauf basierend einmal so ein bisschen definieren, was bedeutet dann oder was fasst man denn alles unter Design-System zusammen?
Jetzt haben wir schon über Design-Tokens gesprochen, irgendwie Component-Library, aber irgendwie wollen wir ja auch jeden abholen.
Was braucht man denn dafür, um ein Design-System wirklich...
Und was ist so ein allumfängliches Design-System?

[9:51] Ja, ich glaube, wie Jonas auch schon gerade sagte, das ist insgesamt sehr stark abhängig von den Bedürfnissen der Organisation und dem Wert, den das Designsystem für die jeweilige Organisation, das Unternehmen schaffen soll.
Also, natürlich gehört da für uns eine UI-Komponenten-Bibliothek mit rein, die auf der einen Seite die Designer da abholt, weil vielleicht gibt es das in Figma, vielleicht gibt es das in Sketch und das macht die Designer effizienter.
Das sollte es in jedem Falle auch im Code abgebildet geben, sodass ich halt Frontend-Komponenten habe, die man halt in der Entwicklung rauspicken kann.
Das Thema UX-Writing, merke ich gerade, nimmt auch immer zu im Stellenwert.
Das ist auch super wichtig. Wie sprechen wir mit unseren Anwendern?
Wie sollen die denn überhaupt das Interface erleben?

[10:44] Dann sind das natürlich so die Foundations der Organisation, Also wie stellt sich die Organisation dar, also wirklich im Sinne des Markenerscheinungsbildes, also die rudimentären Farbe und Schriftwerten, das Logo und jener Organisation kann das ab da immer weiter gedacht werden.
Also da gibt es dann die Icons, da gibt es die Assets zum Runterladen und oftmals ist auch ein digitales Designsystem eingebunden in das Brandportal, wo aber dann auch noch für andere Medien und Omnichannel die Vorlagen liegen.
Also von daher, das ist so ein Fass ohne Boden, wenn man da einmal anfängt zu graben und macht auch die Komplexität auf der gleichen Seite klar.
Wir sagen immer, so ein bisschen spaßig, ein Designsystem ist 50 Prozent irgendwie das, was man da inhaltlich, technisch vielleicht baut und 50 Prozent ist das Stakeholder-Management und das Reden mit den richtigen Leuten zum richtigen Zeitpunkt, um überhaupt rauszufinden, erstmal was wird benötigt und später auch rauszufinden, wie funktioniert das und wie kann es besser werden.
Und all das ist mehr als essentiell, um mit einem Designsystem erfolgreich zu sein aus unserer Sicht und mindestens genauso wichtig wie die technischen Entscheidungen, die ich auf dem Weg dahin treffe.

[12:04] Ich habe mich gefragt, wie lange es eigentlich Designsysteme so als Konzept schon gibt.
Also ich glaube so Corporate Identity Style Guides und so, die gibt es schon relativ lange.
Aber ich habe schon das Gefühl, dass dieses Konzept der Designsysteme, so wie wir sie gerade beschrieben haben, Also das ist die vielleicht vor zehn Jahren noch nicht in der Masse im Einsatz gab oder man nicht so viel darüber gesprochen hat, wie das heutzutage der Fall ist. Vielleicht täusche ich mich da.
Ich meine, Daniel, du bist ja auch einer der UX-Bonn-Meetup-Hosts, also wahrscheinlich habt ihr euch da auch schon früher mit solchen Themen beschäftigt.
Aber stimmt mein Eindruck, dass so dieses Thema Designsysteme irgendwie auch so sich wie so eine Welle aufbaut?

[13:04] Ja, das finde ich schon. Jetzt gerade bekommt es wirklich stark Momentum und es gibt etliche schillernde Beispiele von großen Organisationen, die das auch publik machen.
Mir selber ist das, glaube ich, erstmalig 2010, 2011 so unter die Räder gekommen, wo ich gemerkt habe, ich habe die Verantwortung für verschiedene Design-Teams und Produkte und es gibt noch unterschiedliche eben Auftritte und wie wollen wir das harmonisieren.
Und damals hieß das noch so lebender Styleguide, Living Styleguide, Design System Language waren so Begriffe.
Dann kam auch irgendwie kurz danach dieser Begriff Atomic Design auf, der das Ganze sehr von Brad Frost was so schematisiert, mal...
Die ganzen Ingredienzien aufgesplittet hat, aber wirklich aktiv darüber sprechen und sagen, wie bilden wir das im Design ab und die Konversation zu führen aus dem UX-Team, auch mit den Frontend-Devs, das war so wirklich schon 13 Jahre her mindestens.

[14:12] Das würde ich auch ähnlich sagen. Also ich glaube, du liegst mir in zehn Jahren da gar nicht so schlecht für so ein grobes Timing, wo man so angefangen hat, das so zu nennen und wo auch viele so der heutigen Gedanken, glaube ich, ihren Ursprung haben, eben mit einem Brad Frost, der Atomic Design geschrieben hat.
Ich weiß, dass damals die ersten Projekte mit PatternLab, haben wir auch damals sehr viel gemacht, gearbeitet haben, um eben auch schon so diese erste Art, meine Workbench als Frontendler zu haben.
Heute ist da irgendwie Storybook riesig in dem Bereich.
Also ich glaube, da ist schon so vieles auf die Zeit zurückzuführen.
Ich weiß auch, dass wir, das muss auch 2013, 2014 gewesen sein, für die Telekom damals ein riesiges Projekt gemacht haben.
Das hieß halt noch Component Library. Das war aber im Kern das Gleiche, halt ein zentrales Komponentensystem mit Dokuseiten, wie das Ganze einzusetzen ist, mit Do's und Don'ts.
Also wahrscheinlich, wenn man die Augen etwas zusammenkneift, würde das aus heutiger Perspektive schon so ein bisschen so aussehen wie ein Designsystem. System.
Also, ich glaube, was halt neu ist, ist, dass halt deutlicher gesehen wird, was eigentlich nötig ist, um damit erfolgreich zu sein.
Also, dass es eben nicht nur die Frontend-Workbench sein kann, sondern dass es eben da andere Parteien gibt, dass die mindestens genauso wichtig sind, um später Erfolg garantieren zu können und dass es am Ende nicht nur Developer-Experience ist, die entscheidet, ob irgendwas funktioniert oder nicht.
Da würde ich sagen, das ist vielleicht eine Erkenntnis, die noch so ein bisschen neuer ist, zumindest ist es mein Gefühl.

[15:35] Ja, ich finde auch in den letzten, in der ganzen Dekade ist so viel reingespielt.
Also diese ganzen Themen agiles Arbeiten, cross-funktionale Teams, dass halt eben nicht irgendwie, also auch wenn es heute immer noch passiert, dass Design groß gedacht, vorgemacht wird, über den Zaun geworfen wird und dann bitte so umsetzen.
Und eigentlich wissen wir alle, das geht nie gut, das führt immer zu Reibungen, keiner ist so richtig glücklich, es gibt viele offene Fragen, die sind nicht geklärt und dann fängt man an, Sachen zu beantworten, vielleicht auch selbst verantwortlich und dann war es auch nicht richtig, und das ist halt deutlich besser geworden.
Also ich finde, auch wenn ich mal Figma schändlich als immer noch interaktiveres PDF-Titel irgendwie.

[16:26] Hat das schon dazu beigetragen, dass Designern diese systematisierte Denke angetragen wurde und dass auch jetzt Webdesigner sich damit auseinandersetzen müssen, strukturierter zu arbeiten.
Das fing auch schon vor, fiel mir an, mit Sketch-App. Da habe ich auch selbst ich damals als Designer den Begriff, Ich muss jetzt meine Library refactoren, damit das wieder richtig irgendwie konsistent ist.
Und dafür war das, glaube ich, sehr, sehr hilfreich, eine bessere Basis der Konversation zwischen Design und Development zu schaffen.
Und vielleicht ist es auch so, dass diese Tools, das ist ja zum einen Figma und Sketch vielleicht, aber andererseits auch die SPA-Frameworks, andererseits, dadurch, dass die vielleicht diese Philosophie des alles in Komponenten oder in quasi Atomic und wie auch immer aufteilend.

[17:32] Vorgegeben haben, letztlich dass man dann so in dieses Mindset auch reingekommen ist, also zwangsläufig vielleicht.
Also die haben das möglicherweise auch begünstigt, ich weiß es nicht. Das glaube ich auch, ja.

[17:48] Ich finde es auch deswegen interessant, weil es, ich glaube, in der Folge 600 gab es ja einen schönen Blog zu Designsystemen, auch da so ein wiederkehrendes Thema war.
Wie sorgt ihr eigentlich dafür, dass sowas dann auch funktioniert?
Und gerade dieses, wie funktioniert es zwischen Designern und Developern?
Wie Daniel gerade sagte, wird es über den Zaun geworfen oder ist es cross-functional?
Ich glaube, das ist halt ein Riesenpunkt, der da interessant ist und der halt maßgeblich auch beeinflusst, wie man da am besten Erfolg erzielen kann mit so einem Design-System später. Da waren ja auch so Tools dann Thema.
Ich glaube, Story-to-Design wurde zum Beispiel angesprochen.
Da haben wir tatsächlich schon mal ein bisschen tiefer reingeschaut gehabt vor einer Weile und auch immer mal wieder, weil wir das auch super spannend finden, halt zu sagen, wenn ich doch Komponenten habe, kann ich die denn nicht irgendwie in einem Designer-Entwickler einfach so reingenerieren, dass er sie direkt verwenden kann?
Also wie seine Palette aus Design-System-Komponenten und dann malt er damit Interfaces.

[18:40] Man merkt da halt noch, das ist halt hyperkomplex Und das krankt halt an vielen Stellen.
Das heißt nicht, dass sie da nicht vielleicht irgendwann hinkommen können, aber in unseren Tests hatte das immer so starke Limitierungen, dass es am Ende halt irgendwie sehr brüchig ist.
Und ich frage mich da auch immer, ist das überhaupt oder sollte das überhaupt das Ziel sein, diese Schnittstelle loszuwerden zwischen Design und Entwicklung oder ist das nicht eigentlich wertvoll, die zu haben?
Also ist es nicht auch eigentlich gut, dass es beide Seiten gibt und dass es beide Denkmuster gibt und dass man darüber sprechen muss?
Also gefühlt versucht man, das Schwierige wegzuoptimieren, obwohl eigentlich gerade da der Wert entsteht eben im Austausch, im Wie machen wir es denn?
Sollen wir für euch die Varianten in Figma anpassen oder exportieren wir euch das?
Oder also diesen Dialog einfach überhaupt erstmal zu führen, glaube ich, ist eigentlich das Entscheidendste dabei.

[19:30] Wie kann man sich diesem Dialog denn eventuell etwas, sag mal mal, prozessualer annähern?
Also gibt es vielleicht einen Pattern dafür?
Gibt es eventuell so eine Art Blueprint, den man da anwenden kann, damit man schon mal so ein bisschen ein paar Konflikte aus dem Weg räumt?
Also was wir gesehen haben, was halt total hilft, ist möglichst früh halt mit möglichst diversen Leuten darüber sprechen, was sie eigentlich von einem Designsystem benötigen.
Und das sind sowohl Designer, die sagen, sie müssen vielleicht Design gut und effizient anpassen können und schnell ausrollen können.
Das sind Entwickler, die sagen, sie müssen schnell Ergebnisse produzieren und irgendwie flexibel adaptierbar bleiben, weil ihre Aufgabe sich täglich ändert und sie nicht so strikt sein können, wie das vielleicht ein Designsystem will.

[20:15] Aber das sind vor allem auch Redakteure zum Beispiel oder Entscheider, die in den Prozessen auch oft eigentlich super wichtig wären, um zu überlegen, ja, was wird denn dem Nutzer eigentlich später angezeigt und was muss dann eigentlich eine Komponente können, damit wir das gut einstellen können, damit wir vielleicht auch mal einen A-B-Test machen können, um mal die Variante mit der Headline drüber und die mit dem Button etwas größer auszuprobieren statt was anderem.
Also möglichst früh halt darüber zu reden, was braucht man eigentlich an Komponenten und was müssen die können.
Und dann folgt halt, wie malt man sie an, wie baut man sie und so weiter, weil diese, wir nennen das manchmal Component API, sich da halt möglichst früh zusammenzusetzen mit möglichst vielen Leuten und zu überlegen, was sind denn wirklich unsere Requirements und das dann im Frontend auch festzunageln und zu bauen in seinem Designsystem.

[21:04] Ja, das hat sich wirklich als bewährt bewiesen, auch wenn viele Auftraggeber am Anfang dann denken, wieso jetzt nochmal das Ganze fast Stakeholder aufmachen, weil wir dann auch wirklich reingehen und sagen, wer ist denn involviert in dem Prozess, wer arbeitet damit und lasst uns da nochmal wirklich reingucken und fragen.

[21:26] Wo sind denn da Pains und Gains und was wollen die eigentlich damit erledigt bekommen.
Und dann hat sich auch, also grundsätzlich Blueprint gibt es dafür nicht so.
Das ist auch wieder sehr individuell auf die Organisation und ihre Bedürfnisse oder auch Produkte und Anwendungen zugeschnitten.
Aber dass man zumindest schaut, dass man entweder klein anfängt, sagt, okay, wir nicht alles wieder auch im Designsystem upfront bauen, sondern gucken, wo können wir möglichst schnell auch Wert mit den Komponenten schaffen.
Das kann ein Pilotprojekt sein oder ein kleineres, vielleicht nicht ganz so wichtiges Projekt, was eh neu gebaut werden muss, wo man dann erste Erfahrungen sammelt, die man dann möglichst schnell auch wieder iterativ in die Entwicklung einfließen lässt.
Das heißt, es kann aber auch eine total wichtige, die eine total komplexe Komponente sein, die vielleicht nur zwei Teams nutzen, die aber wichtige Produkte machen, an denen viel Umsatz hängt und wo die sich oft die Zähne ausbeißen, dass man denen diesen Schmerz nimmt und sagt, wir bauen diese, lasst uns doch damit anfangen und damit den Wert schaffen.
Also das ist auch sehr, sehr unterschiedlich.

[22:48] Was für Werte kann so ein Design-System so generell für die verschiedenen Parteien schaffen?
Also mir würde jetzt einfallen, man muss halt eben sich die Gedanken hinsichtlich Tonalität, Design und so nur einmal machen und kann dann eben später sich einfach aus dem Baukasten bedienen und ist dann sozusagen mit dem Upfront-Investment am Anfang, aber hinterher dann einfach deutlich schneller.

[23:21] Was kann man noch machen? Man kann Komplexität generell gut kapseln vielleicht und also quasi dann durch Einsatz multiplizieren.
Das kann Barrierefreiheit sein, die da auch drin steckt, aber vielleicht irgendwie auch andere Aspekte wie Performance und so, also Dinge, die sehr komplex sind.
Genau, was könnten oder was sind denn noch so Antreiber, warum man in einer Firma oder in einem Projekt ein Designsystem haben wollen könnte?
Also wie kann man das zum Beispiel an andere pitchen in der Firma, die vielleicht noch so ein bisschen, die noch nicht so weit sind gedanklich?
Also was auch neben all dem Gesagten noch ein sehr relevanter Faktor ist, wenn ein Unternehmen halt viele unterschiedliche Marken hat, mit eigenem Auftreten, das Designsystem einen halt da sehr gut befähigt, eben Multi-Theming oder Multi-Mandanten-Fähigkeit zu schaffen und im Kern hat man trotzdem all diese Mehrwerte, die du gerade genannt hast und somit eben das skalieren lässt.

[24:36] Man kann, also jetzt für mich ein bisschen durch die UX-Brille gesehen, ich bin viel schneller, also vielleicht nur kleine Mehrwerte, aber man kann schneller Prototypen bauen, außerhalb von Figma, sondern mit lauffähigem Code.

[24:54] Wir haben für ein Team bei der UNICEF das gebaut. Die machen Performance-Marketing.
Die sind damit, also sind viel, viel schneller fähig, Seiten live zu stellen, weil sie das schon haben und sich Prozesse sparen im Sinne von Designagentur beauftragen.
Dann gibt es ein Konzept und dann gibt es die Umsetzung und jetzt haben wir endlich unsere Spendenseite, sondern jetzt kann sich die Agentur wirklich um das Konzept und die visuelle Identität so einer Spendenkampagne kümmern und die UNICEF selber, das Team selber, baut die dann selber.
Das heißt, da werden immense Kosten gespart, die sonst für Entwicklungen auch vielleicht an eine Drittfirma bezahlt wurden.
Und so kommt es da dann sogar in dem schönen Beispiel dann wirklich den Bedürftigen noch mehr zunutze.
Ich glaube auch. Du hast viele, viele Werte da ja auch, glaube ich, gut schon genannt mit Accessibility und so weiter.
Wobei ich sagen würde, so bestimmte Dinge werden quasi auch schon fast von einem erwartet mittlerweile, wenn man sagt, dass man ein Designsystem baut, ist irgendwie auch die Erwartung, dass es performant ist, dass es accessible ist.
Also zumindest ist das so ein bisschen unser Gefühl mittlerweile, dass das jetzt auch nicht mehr die Alleinstellungsmerkmale oder das Besondere ist, was man da erzählen kann.

[26:12] Was ich noch ganz interessant finde, ist, wenn man eben schon solche Standards in so einem Designsystem für sich schafft und da sehr viel dokumentiert, halt auch darüber nachzudenken, wie man diese ganzen dokumentierten, oft ja auch sehr strukturierten Informationen halt auch noch einfacher nutzbar machen kann in anderen Systemen zum Beispiel.
Beispiel, also wenn ich Komponenten habe und sehr genau weiß, wie sind die aufgebaut, welche Eigenschaften haben die so, bin ich gar nicht mehr so weit davon entfernt, das auch zu konvertieren für einen Redakteur in einem CMS-System, der dann genau so eine Komponente einsetzen kann.
Also, Daniel hatte gerade so ein bisschen dieses UNICEF-Beispiel genannt.
Da sieht man das, finde ich, ganz schön. Die haben halt angefangen mit so einem Git-basierten Workflow.
Das heißt, die haben sich dann selber ihre Snippets zusammen kopiert aus Komponenten.
Die haben sich in Storybooks zusammen konfiguriert, genauso wie sie die brauchen.
Und dann kopieren die die einfach hintereinander und dann wird eine neue Seite der Spendenkampagne live gestellt.
Und das merken die halt auch, dass es als Git-Workflow jetzt noch nicht so convenient, wie das ein Redakteur sich eigentlich gerne wünscht. Wenn dann viele Bilder hochgeladen werden müssen, muss man die wie einzeln in Git hochladen.

[27:15] Das ist einfach nicht optimal und da tauscht man das Ganze jetzt halt gegen eine eher CMS-basierte Lösung aus, aber kann halt seine Komponenten genauso behalten, wie sie da waren, weil es sind ja die richtigen Komponenten.
Da hat man sich ja unabhängig von irgendeinem CMS-System Gedanken drüber gemacht und das ist halt genau diese Herangehensweise, sich diese Gedanken halt unabhängig und vorher zu machen, befähigt einen dann auch unabhängiger gegenüber vielleicht seinen Systemen zu sein, die man anbindet und vielleicht Algorithmen zu haben, die das automatisch für einen tun können.
Das ist so, was uns in letzter Zeit vor allem umtreibt, wie man vielleicht auch noch effizienter automatisiert Wert generieren kann mit so einem Design-System.

[27:56] Und, aber würdet ihr sagen, dass Designsysteme schon so einen No-Brainer-Status mittlerweile erreicht haben, dass also sozusagen man den Leuten nicht erklären muss, warum ein Designsystem, also sozusagen ist es schon so, dass alle von Designsystemen gehört haben und eigentlich von denen träumen, wenn sie denn keins haben, aber man sie nicht überzeugen muss oder wie ist da so die Lage draußen?
Ich glaube, dann habe ich wahrscheinlich auch etwas zu sehr aus der Blase gesprochen gerade. Das gebe ich auch gerne zu.
Aber das ist schon noch ein Nischenthema. Wie gesagt, wir sehen da sehr großes Interesse und auch wirklich sehr großes Wachstum.
Aber es ist halt immer noch ein sehr kleines Thema, was halt in sehr bestimmten Bereichen aus unserer Sicht den Wert hat.
Wir sagen selber, wenn wir danach gefragt werden, auch häufig die Firma mit 100 Mitarbeitern in einer Digitalabteilung, die auch tatsächlich mit mehr als ein, zwei Touchpoints zu tun hat, die haben da einen Wert von.
Für ganz viele darunter ist das häufig auch Overhead, zumindest wenn man es alles selber machen soll und auch alles sich selber ausdenken soll.
Da hoffen wir natürlich, dass wir vielleicht diese Lücke so ein bisschen schließen können, dass vielleicht mit sowas wie Kickstart TS einfach der Invest-Upfront so ein bisschen kleiner wird und damit es vielleicht mehr Leute interessant wird.
Aber am Ende des Tages muss man schon fairerweise sagen, dass lange nicht jeder davon profitiert und auch lange nicht jeder das Thema so gut kennt, dass es da Selbstverständlichkeiten gäbe, glaube ich.

[29:24] Nee, das merken wir schon auch. Also, wenn wir Kicks.at.de vorstellen, dann muss man eigentlich mal doppelt pitchen. Also, erst mal das Designsystem.
Warum ist das gut?

[29:37] Und um dann zu sagen, das ist halt auch ein großer Aufwand und ein großer Invest.
Und das wollen wir mit Kicks.at.de als Open-Source-Lösung halt eben für dich, liebes Unternehmen, noch viel günstiger und einfacher machen. Und das stimmt schon.

[30:21] Wir sind hier inkonsistent und da kommt bald Barrierefreiheit auf uns zu und wie tacklen wir das?
So und dann wird es vielleicht schon ein bisschen einfacher.
Aber insgesamt ist das noch immer leider ein frisches Thema.
Und gibt es auch oder habt ihr Mittel und Wege gefunden, auch sowas zu entwickeln wie sozusagen Design-System-KPIs, also dass ihr sowas macht, wie dass ihr quasi ein, so waren eure Performance-Metriken in bestimmten Bereichen, bevor ihr ein Design-System hattet.
Und jetzt haben wir ein Designsystem und schaut mal, so hier können wir auch irgendwie euch zeigen, dass Dinge besser geworden sind. Habt ihr sowas auch schon mal gemacht?
Also wir haben schon mit Unternehmen drüber gesprochen, aber ich finde, oder merke halt, die Unternehmen, die sich gerade um Telemetrie kümmern von Designsystemen und wirklich das versuchen zu messen, das sind die, die auch schon da ein paar Jahre, in der Reifeskala weil er sehr weit oben stehen und schon viele Erfahrungen gemacht haben.
Aber vielleicht auch so, Unicef-Projekt hat vorher.

[31:43] Jede Spendenkampagne hat sechs Wochen gebraucht, jetzt nur noch zwei oder so.
In dem Kontext kann man das sehr deutlich benennen, ja. Also da gibt es dann so sehr offensichtliche Themen.
Was Daniel nur so ein bisschen anspricht, ist dieses Return on Invest und so, ist halt ein Riesenthema in diesem Designsystem-Bereich, muss man sagen.
Und aus unserer Sicht halt vielleicht auch nicht immer die wichtigste Frage vorneweg.
Also wir sehen halt, dass man das beste Feedback halt, wenn man eben klein anfängt, das Ganze iterativ angeht, halt eben aus den eigenen Abteilungen bekommt und den Personen, die in diesen Projekten sagen, ja, das funktioniert gut oder das funktioniert nicht gut und das macht meine Arbeit einfacher.
Ich tue mich da immer schwer damit, dass auch so einfache Zahlen runterzubrechen am Ende, weil es glaube ich gar nicht geht und man dann nur schnell Gefahr läuft, irgendwelchen Zahlen wie Adoption Rates hinterherzulaufen und irgendwie Leute darauf trimmt, irgendwo Buttons auszutauschen, aber am Ende ihnen auch nur das Leben zur Hölle macht und nicht wirklich Wert generiert.

[32:41] Ich glaube, das ist schwierig, das so auf schöne Zahlen runterzubringen, was ja immer Spaß macht eigentlich und irgendwie auch cool ist.
Ja, und auch da gibt es so die unterschiedlichen Perspektiven.
Also vielleicht das DesignOps-Team, die sich vorrangig um das Designsystem kümmern, die dann halt feststellen wollen, wie viele Forks gibt es denn hier oder so, um Indikatoren zu finden, ob was gut ist oder schlecht ist.
Aber jetzt wirklich gesprochen aus so Executive-Brille in irgendwie ROI und was bringt uns das denn auf der Skala gegenüber dem Invest?
Das ist halt wirklich die Frage, wie kann man das verkaufen, wenn man so Exec-Level-Menschen hat, die da irgendwie noch nicht so durchsteigen bei dem Thema.
Und da ist es halt, muss man sagen, häufig alleine halt das Erklären darum, wie das Ganze theoretisch funktioniert und dann im besten Fall halt auch das Erklären, warum das Effizienz bedeutet, bedeutet, ohne dass man die jetzt automatisch eins zu eins messen könnte, aber warum das halt dann wert ist.
Und da kann man auch häufig über andere Werte noch gehen, wie eben Konsistenz und wie Qualität.
Also da ist dann auch Effizienz auch nur einer von den wichtigen Punkten wiederum, wenn man mit so dieser C-Level-Ebene von Entscheidern spricht.

[34:04] Ja. Und also insgesamt, aber auch da trotzdem, glaube ich, ist das ein ganz guter Punkt, um da anzuknüpfen und zu sagen, wie schafft man denn schneller oder besser Adoption?
Weil auch das ist immer wieder ein Thema, was uns begegnet, auch wenn man sich so in dieser Design-System-Community austauscht.
Jetzt gibt es ein gutes digitales Design-System, es gibt irgendwie die ersten zwei Anwendungspunkte, aber wie trage ich das denn jetzt in die Organisation?
So als Lehrauftrag oder gibt es auch etliche total diverse Mittel, das reinzutragen mit Trainings und so weiter.
Und so ganz pragmatisch haben wir immer gemerkt, ist wirklich einfach gucken, wo gibt es denn einen konkreten Punkt und das dann auch so ein bisschen entweder gecoacht mittragen von dem Team, als dass man jetzt wieder sagt, wir machen Trainings und so weiter.
Und dann ist das nur eine andere Art von, wir kippen das über den Zaun und dann macht doch mal. Das hilft halt auch oft nicht.

[35:20] Also du meinst quasi, dass man zum Anschieben mit in die Teams reingeht und sozusagen dieses Designsystem mitbringt und mit denen das dann etabliert in ihren Produkten, an denen die bauen. Genau.
Und darüber kann man dann vielleicht auch sehen, gibt es hier wieder bestimmte Muster, was immer wieder vorkommt und da dann wieder durch irgendwie Semi-Automatisierung oder gute, passgenaue Dokumentation, das halt dann zu unterstützen und von da aus dann das zu multiplizieren.
Also wie eben jetzt auch bei der UNICEF, wo es dann halt erst durch so Code anfängt und sagen zu bauen, jetzt.

[36:04] Wandeln wir das in so ein CMS-Paket und dann ist es noch mal viel leichter für ein Team, was vielleicht weniger Code-affin ist, auch darauf onzuborden und dann kommt der nächste Touchpoint dazu und dann der nächste Touchpoint, und Ja, wenn man das Anwenden leicht macht, ist es natürlich immer vorteilhaft.
Ich würde auch sagen, dass das eben nicht als Last gesehen wird.
Das würde ich auch fast behaupten. Wenn du die Arbeit nicht vereinfachst von den Leuten, die damit arbeiten sollen, dann werden sie es nicht einsehen.
Also das muss man halt einfach, es sollte kein Regelwerk sein, nachdem ich geprüft werde, ist das, glaube ich, einer der wichtigsten Punkte, dass das halt.

[36:48] Wirklich differenziert passieren muss. Ja, und das ist auch so ein bisschen bei uns zum Motto geworden.
Ein Designsystem ist nichts ohne ein System, welches es anwendet.

[37:03] Und unter dem Motto bauen wir jetzt auch demnächst so, also wir haben die gebaut, eben fertige CMS-Data, die dann mit Kickstart DS sozusagen direkt das ein bisschen Ende zu Ende denken und aufnehmen und auch da den Einstieg erleichtern sollen.
Genau, das geht so ein bisschen in die Kerbe. Wie kann man das schneller nutzbar machen?
Wie kann man vielleicht auch für so eine Idee wie ein Designsystem die Tür öffnen, wenn da vielleicht noch gar nicht die Gedanken für da sind?
Also eben auch in die etwas kleineren Unternehmen in die Richtung gedacht, die vielleicht nicht die Mittel haben, mal eben noch ein Designsystem aufzuziehen, halt irgendwie so einen Starter bereitzustellen, der erstmal eine Website für mich abbildet, weil die brauchen die meisten irgendwie, Selbst große brauchen dauernd Websites, ob es Landingpages sind, Marketingkampagnen.
Auch die wollen immer schnell sein und möglichst neben dem Haupt-CMS auf der .com arbeiten können, wenn sie das tun.
Auch für die ist das interessant, aber gerade für die Kleineren halt zu sagen, wie kann man denn vielleicht schnell loslegen, ohne sich gleich in den Fuß zu schießen dabei, weil man, weiß ich nicht, vielleicht nach einem halben Jahr dann doch bereut, mit Tailwind UI alles zusammengeklebt zu haben und jetzt fängt es halt irgendwie an zu bröckeln, weil man nochmal dran muss.
Ist das so ein bisschen die Idee? Wie können wir das halt weiter runterbrechen?
Und da ist halt ein Kernpunkt von dem, was wir machen, und das ist auch so ein bisschen ein Rückgriff auf, was ich mit dieser Strukturierung meinte, dass wir halt JSON-Schema benutzen, um Komponenten zu dokumentieren.

[38:31] Das ist halt ein super Mittel, wir nutzen alle den ganzen Tag, ist zumindest mein Gefühl, JSON als quasi Standard in der Front- und Backend-Entkopplung, also ob wir da über APIs reden, ob wir CMS-Systeme anbinden, ob wir irgendwie JSON oder YAML in Repositories ablegen, am Ende sind es eigentlich immer so ganz gleiche Objektstrukturen, JSON halt.
Und das war für uns so der Punkt, als wir angefangen haben, Kickstarter erst zu schreiben, Wir haben schon lange eben so Komponentenbibliotheken gebaut.

[39:02] Einer der Hauptpunkte, die wir uns gefragt haben, wie können wir das noch besser strukturieren?
Und da haben wir Jason Schema gefunden und jetzt halt gesehen, dass uns das halt wirklich ermöglicht, dann so einen CMS-Connector einfach automatisch zu generieren.
Das heißt, du hast dein Designsystem, du hast irgendwie eine Schemadatei, die sagt, hier, das ist meine Page, die besteht aus einer Reihe von Sections und Sections dürfen diese 15 Komponenten enthalten, die ich dir hier benenne und dann automatisch halt hinzugehen und zu sagen, okay, dann nimm doch diese Information und konvertier die in ein Storyblock-Schema oder in ein Static-CMS-Schema und wenn man sich diese ganzen Headless-Systeme so anschaut, sieht man schnell, dass die am Ende im Kern alle das Gleiche machen.
Also im Grunde so glorifizierte Datenbank-Verwaltungstools für JSON-Dokumente sind.
Und der eine hat dann seinen Schnitt eher so gelegt, dass es ein bisschen strukturierter ist beim anderen, beim anderen ist es ein bisschen mehr strukturiert und am Ende ist es aber eigentlich immer das Gleiche.
Und das ist so ein bisschen das, was in dem Kern für diese Starter für uns drinsteckt, eben sowas automatisch generieren.
Wenn du schon ein Designsystem hast, wenn du schon so lange mit den hoffentlich richtigen Leuten darüber gesprochen hast, was so eine Komponente können soll, warum dann die Finger damit jedes Mal wieder schmutzig machen, sie immer und wieder zu implementieren oder beim Wechsel des Systems alles neu erfinden zu müssen.
Das ist so für mich immer der größte Pain gewesen, wie bereitwillig im Frontend immer noch Code weggeschmissen wird, immer und immer wieder, obwohl da sehr viel Zeit und sehr viel Aufwand drin steckt häufig.

[40:30] Da denke ich eher, könnte so ein Frontend eher das sein, was überdauert und das CMS-System oder mein Backend ist vielleicht das, was sich immer mal wechselt.
Mal ist es vielleicht die API, mal eine andere.
Also das macht zumindest so in meiner Welt wesentlich mehr Sinn, als dass das Frontend immer der Ort ist, wo man alles neu erfinden muss, wenn man irgendwie anfängt.
Das passt jetzt vielleicht so ein bisschen zusammen, was wir da jetzt gerade versucht haben und wie das so ein bisschen funktioniert und soll aber im Grunde auch nur nochmal sagen, wenn man sich diese strukturierten Gedanken am Anfang macht und auch überlegt, wie kann ich mir solchen Wert generieren, dann kann man da, glaube ich, kreative Lösungen für sich finden.
Das muss dann nicht unser Storyblock-Starter mit unserem Schema sein, sondern das kann auch meine ganz eigene Systematik sein, in der ich mir irgendwie geschickt die Informationen irgendwo rausziehe und einem anderen in meinem Unternehmen bereitstelle, der das bei sich wieder anwenden kann.
Ob das ein MPM-Package ist, ob das eine JSON-Datei ist, die ich ihm per Mail schicke.
Wie gesagt, das will ich gar nicht sagen, dass das da immer genau eine Art hat, wie das aussieht.

[41:34] Ich weiß, als du das letzte Mal da warst und wir über Designsysteme gesprochen hatten und auch über Kickstart DS im Speziellen, dass natürlich dann irgendwann auch die Frage aufkam, in welcher Frontend oder mit welchem Frontend-Stack ist das gebaut.
Und da landet man ja dann eigentlich früher oder später immer bei dem Thema Web-Components, weil das natürlich auch so ein bisschen so der, zumindest konzeptionell der Garant dafür ist, dass man sein Frontend ja dann vor jegliches, was auch immer für eine Logik da am Start ist, schnallen kann.
Aber ich weiß, dass ihr damals euch für React entschieden hattet, glaube ich.

[42:22] Ähm, wie es, wie seht ihr, oder wie seht ihr diese Fragestellung?
Interessanterweise würde ich sagen, hat das sich relativ aktuell verändert so ein bisschen.
Und auch da war in der Folge 600 ja ein sehr schöner, langer Austausch zu Web-Components zu hören.
Und aus unserer Sicht war der große Knackpunkt immer, dass es halt für uns, die schon irgendwo auch so ein bisschen diese Unternehmensseiten, Marketing-Darstellungsseiten in der DNA haben, halt so der fehlende Block, was jetzt SEO angeht, die JavaScript-Abhängigkeit.
Da waren für uns viele Fragen drin, wo wir uns halt nicht sicher waren, dass das einen riesen Wert darstellt, so wie es aktuell ist.
Aber damit das jetzt der Declarative Shadow DOM da ist, sieht das aus unserer Sicht plötzlich sehr, sehr viel interessanter aus und ist auch was, wo wir sehr aktiv drüber nachdenken, unsere Komponenten eben darauf umzustellen.
Wir haben früher auch schon gesagt, für uns ist das, was die Komponente nachher definiert, halt das Markup, was da rauskommt.
Ob das jetzt von einem React erzeugt wird oder von einer Web-Component oder von einem Vue.js, das ist uns irgendwo auch ein Stück weit egal, solange da halt bestimmte Funktionen gegeben sind, bestimmte Qualitätskriterien einhaltbar sind mit dem Ansatz, ist uns der Ansatz eigentlich egal.
Egal, wenn wir ganz viel Geld hätten, würden wir es einfach in jedem Framework bauen.

[43:39] Das ist natürlich der Pipe-Dream, der wahrscheinlich auch keinen echten Sinn macht und nur sehr oberflächlich irgendwie sich nett anhört, aber theoretisch aus unserer Sicht könnte man das ja auch tun.
Und deswegen finde ich Web-Components super spannend, weil sie halt so ein gemeinsames Dach vielleicht auch irgendwann über verschiedene Entscheidungen, die ja auch zu verschiedenen Szenarien die richtigen sind. React ist nicht immer die richtige Entscheidung.
Das würden auch wir nicht behaupten. Es ist nur für uns in dem Moment die richtige gewesen, weil es halt auf Composition-Ebene für uns super viele wertvolle Features mitgebracht hat, die wir sonst auch so noch nicht so einfach als Ersatz gefunden hätten.
Aber ich finde halt, Web Component ist super interessant.
Also ich glaube auch, dass es da auch für uns hingehen wird.

[44:21] Ja, das ist sozusagen der heilige Gral dann, ne? Ja, aber das ist halt auch, deswegen finde ich es so spannend, weil es Interoperabilität das erste Mal wirklich eher möglich macht.
Also, wir sind großer Freund von Composition und Dinge nicht jedes Mal neu erfinden.
Auch wir haben nicht ein Layout-System erfunden, sondern nutzen halt Bedrock-Layout als unsere Library für Layouts in React, also Separation of Concerns.
Jeder kümmert sich um bestimmte Dinge und dann sehr gut, macht ja auch einfach Sinn.
Und ich glaube halt, wenn der Standard noch geteilter ist und wir gleicher an Komponenten arbeiten, wird auch das noch mehr zunehmen, dass man wirklich Kompositionen betreiben kann. Ist zumindest meine Hoffnung.
Hans, ich hatte dich eben unterbrochen. Du wolltest was fragen. Ja.

[45:10] Ich hatte mich gefragt bei dieser Diskussion, welches Framework man nimmt, wie lang diese Diskussion denn noch ein Thema sein wird, weil im Idealfall so in meinem Kopf könnte es ja so sein, dass man jetzt zwar React schreibt, aber dann gibt es halt irgendwie ein Tool, was das Ganze halt auch so umstellen kann, dass du es halt problemlos mit Angular, sage ich jetzt einfach mal mit Vue, ist wahrscheinlich realistischer, nutzen kannst.
Oder mit Welt oder wie auch immer nutzen kannst oder vielleicht auch in einem Swift UI Kontext, ja, wo es ganz anders theoretisch zugeht auf so einem iPhone, aber halt, dass man halt gar nicht mehr diese Notwendigkeit hat, so viel darüber nachzudenken, was ist jetzt meine Library of Choice, muss ich vielleicht Web Components verwenden, um halt wirklich überall sozusagen verwendbar zu sein.
Oder kann ich nicht einfach sagen, ist doch egal, da gibt es ein Tool, da jage ich das durch und die API ist halt die gleiche. Ich glaube, dass Mitosis doch so ein bisschen in die Richtung geht.
Also Bilder.io, die bauen ja auch so einen großen visuellen Baukasten.
Ich weiß, dass die da sehr viel in der Richtung, man muss wahrscheinlich schon fast forschen, sagen, also wirklich unterwegs sind.

[46:29] Bisher fühlt es sich für mich noch ein bisschen früh und sehr experimentell an und ähnlich geht es mir so ein bisschen manchmal mit AI, was ja auch gerne dann als Thema aufgebracht wird, dass ich irgendwie abstrakt irgendwie da sinnvolle Verbindungen sehe, aber mir das noch nicht so konkret das Gefühl gibt, damit könnte ich irgendwie morgen das nächste Projekt bauen oder würde das guten Gefühles tun, so.

[46:53] Deswegen wahrscheinlich dauert es noch ein bisschen. Also noch ist es halt dann nicht so weit, aber irgendwie könnte, also wäre es ja cool, wenn das halt kein Problem mehr ist, mit dem man sich als Library Builder halt irgendwie beschäftigen muss.
Uns ist es am liebsten, wenn solche Funktionalitäten in den Standard wandern.
Das geht uns ähnlich, wenn wir über Design-Tokens reden, da sind wir kurz vor der Fertigstellung, also wir als die Community gesprochen, von dem offiziellen Standard für Design-Tokens.
Das wird nochmal, glaube ich, einen großen Push bedeuten können, weil dann halt einfach ein allgemeiner Standard für die Definition von Tokens existiert und sich dann sowohl Design-Tooling wie Figma als auch Code-Tooling wie ein Style-Dictionary plötzlich sinnvollerweise natürlich im Standard einig sind.
Und ähnlich sehe ich das mit Web-Components parallel.
CSS gewinnt gerade einen Haufen Features, die es eigentlich unnötig machen, bestimmte Pre-Processor-Lösungen zu verwenden.
Also auch wir überlegen, ob wir überhaupt noch Sass verwenden müssen heute.
Also eigentlich, wir nutzen Sass recht ausführlich noch bei uns, aber im Grunde genau betrachtet durch modernes CSS ist da eigentlich mittlerweile alles abgedeckt mit Nesting und Co.

[48:00] Deswegen bin ich da immer ein großer Fan von Standards, wenn sie das hergeben, was man von ihnen braucht und das war für mich immer der einzige Tick an den Web Components, dass es irgendwie nicht fertig wirkte für mich und das tut es jetzt irgendwie viel eher, ohne es jetzt genauer ausprobiert zu haben, wäre das immer die präferierte Lösung, vor allem für uns als Framework-Anbieter ja sowieso.
Also wir schießen ja im Grunde sehr viele Leute automatisch aus durch unsere Wahl von React.
Egal wie oft wir sagen, das ist nur eine Template Library, das ist für uns auch nur ein aufgebohrtes Handlebars am Ende des Tages.
Du kannst auch das HTML nutzen bei uns, du musst ja gar nicht die React Engine im Browser laden, aber bis du zu dem Punkt mal gekommen bist, hast du ja auch irgendwie 90% der Leute eh schon verloren gehabt.
Deswegen, also allein deswegen wäre Web Components schön als etwas, was man sich auf die Fahne schreiben könnte, weil es halt diese Diskussion einfach auch ausklammert.
Über Standards diskutiert man halt selten.

[48:54] Ja, und dann weiß man eben von jetzt an für immer, werden die Browser das halt rendern können.
Ihr hattet das vorhin schon mal kurz fallen lassen.
Ihr habt den Begriff, ich glaube, DesignOps genannt.
Ich glaube, der Begriff war es.
Was mich zu der Frage führt, also wer sollte in einem Unternehmen oder in einem Team oder so, Also wer ist für das Designsystem verantwortlich?
Also wer bildet dieses DesignOps-Team?
Also für mich klingt das so, als sollten da vielleicht nicht alle dran herumwerkeln gleichzeitig.

[49:39] Sonst gäbe es ja kein DesignOps-Team. Was würdet ihr da empfehlen?
Ja, da gibt es natürlich auch unterschiedliche Modelle.
Es ist so zentralisiertes. Also es gibt wirklich das eine DesignOps-Team.
Und die treffen alle relevanten Entscheidungen.
Die kommunizieren natürlich vorab mit den Stakeholdern und sind vernetzt und treffen diese Entscheidungen.
Und dann kommen die in das Designsystem und werden da reingebacken.
Seien es jetzt Designentscheidungen oder Codeentscheidungen.
Also das ist in der Regel auch cross-funktional aufgestellt.
Ich glaube, das so föderalisiert zu haben, geht nur bei einer extrem hohen Reife sämtlicher Mitwirkenden in einer Organisation, dass man das wirklich verteilt, die Arbeit an den Designsystemen verteilt.

[50:33] Aber das ist insgesamt, glaube ich, auch eines der Themen, die sich noch am Finden sind, also wo sich irgendwie die Best Practices noch herausstellen werden.
Also gerade jetzt, wo wir eben einiges über Adaption gesprochen haben, ist auch das Thema Governance da halt eben auch was, wo sich jetzt die Vorreiter in dieser ganzen Szene mit wirklich tollen Vorbild-Design-Systemen auch jetzt gerade erst anfangen zu beschäftigen.
Wie kriegen wir denn eine ordentliche Governance für das alles hin?
Und wann wird eine Komponente eben aus dem Rennen genommen und ersetzt durch eine neue?
Wann wird eine große technische Entscheidung getroffen?

[51:16] Wann darf man Breaking Releases haben, wann nicht? Wie viel hängt denn da dran?
Wie viel Kosten verursacht das?

[51:25] Und... Ja, das sind natürlich alles Fragen, die man am Anfang erstmal in den Gesicht nicht stellt, wenn man ein Designsystem etabliert, aber wenn man natürlich dann ein Designsystem für eine Weile am Laufen hat, dann genau, man kennt das ja, auch irgendwie von den Frameworks, wenn dann irgendwie man von View 2 auf View 3 upgraden muss oder so, also wie macht man das?
Hat man dann so ein Micro Frontend-Konzept, wo man irgendwie alt und neu parallel leben lässt oder.

[51:54] Ja, spannend. Ja, total spannend. Und auch, also, glaube ich, das macht Zeit.
Weil je nachdem, wie tief so ein System schon im Einsatz ist, hängt da halt wirklich viel Investment dran im Rahmen von Zeit und Nachkehren und so weiter.
Und da müssen viele Entscheidungen wohl überlegt sein.
Und dann gibt es natürlich viele Organisationen, wo halt auch alles extrem dokumentiert ist.
Und dann gibt es für alles Prozesse und so eines elendig große Jira-Boards mit Checklisten und vielen Stationen, die dann ein Ticket durchlaufen muss, bis es bestimmte Stakeholder abgezeichnet haben.
Dann ist die erste Entscheidungsförderung getroffen. Dann gibt es eine Design-Umsetzung, dann Usability-Tests und da fließt die Research ein.
Und dann gibt es natürlich noch Marketing und Brand und irgendwelche anderen wichtigen Stakeholder, die ihren Senf da reingeben wollen, ihre Duftmarke vielleicht hinterlassen wollen.
Das ist hochgradig spannend und auch deswegen sehr schnell explosiv.

[53:02] Ich finde das auch besonders spannend, weil wir auch vorhin schon so ein bisschen mit diesem Design-Developer, ich will es nicht selber Divide eigentlich nennen, aber dass es da irgendwie zwei Lager gibt.
Und ich glaube, Design ist auch oft noch mit Marketing und eher der Seite im Unternehmen verbandelt, während man dann auf Developer-Seite eher mit der Umsetzung zu tun hat.
Und auch da, wo ist dieses Team eigentlich anzusiedeln, ist, glaube ich, noch nicht, da gibt es auch keine Best Practice.
Also sollten es vor allem Umsetzende sein, Vor allem das Marketing sein.
In welchem Verhältnis sollten sie es sein?
Weil am Ende sind ja doch alle wichtig, wenn es darum geht, tatsächlich, also die Sachen, die man sich vorne draufschreibt.
Konsistenz kriege ich ja dann nur hin, wenn auch wirklich alles nachher so aussieht.
Und dafür muss ich ja mit möglichst allen zumindest reden.
Und das macht es, glaube ich, auch sehr herausfordernd, weil das in gerade auch klassischen größeren Organisationen leider ja doch getrennte Lager sind, auch was Verantwortlichkeiten, was Stabsstellen angeht, was Budgets angeht.
Und das sind dann natürlich immer große Diskussionen. Bezahlt das Marketing das?
Dann möchte das Marketing aber auch sehr viele Dinge sicherstellen dabei oder die Kommunikation.
Dann hat man aber vielleicht auch automatisch mehr Reibung mit den Entwicklungsabteilungen, die mit diesen Entscheidungen leben sollen.
Andersrum baut man sonst vielleicht irgendwie ein tolles technisches Konstrukt, aber nachher sagen alle anderen einem ja, das sieht ja nicht gut aus.
Also deswegen ist das, glaube ich, eine der spannendsten Fragen.
Wo ist das eigentlich aufgehängt in so einem Unternehmen und wie werden hauptsächlich Entscheidungen später getroffen? Was sind da die Prozesse?

[54:32] Und bei den Unternehmen, die ihr kennt, die so ein Designsystem haben und pflegen, also die könnt ihr auch mit eurer Kickstarter DS sein.
Also wo seht ihr, dass es dann in der Regel irgendwie landet unter der Ägide von welchen Menschen in Firmen?
Oder schaffen die das auch, so cross-funktionale Teams zusammenzustellen, die das pflegen?
Ich glaube halt, dass das auch wieder so ein bisschen davon abhängt, wo die in ihrer Reise, was Designsysteme angeht, halt auch stehen.
Also meistens muss man schon sagen, kommt es über Marketing, Kommunikation und Brand als Anfrage oder als Thema, was aufkommt, was mit Sicherheit auch damit zu tun ist, dass in dem Bereich dieses Thema halt gerade so ein bisschen Schwung erfährt, eben durch Figma und sehr viel in dem Bereich.
Aber das kann halt auch der perfekte Touröffner sein, um von da aus halt dann so einen Change-Prozess überhaupt erstmal anzustoßen zu stoßen und ab da dann vielleicht doch die richtigen Leute abzuholen und vielleicht auch nicht im ersten, sondern im zweiten, dritten Wurf dann das Designsystem zu bauen, was tatsächlich die Probleme löst.
Auch da, man sagt auch Spaß oder sagen wir auch immer, das dritte Designsystem ist das erfolgreiche.
Zwei baust du zum Lernen und wegschmeißen.
Einfach nur um zu lernen, was du eigentlich wirklich brauchst.
Und auch das gehört dazu irgendwo, diesen Lernprozess selber durchzuspielen, um für sich selber die Sicherheit zu haben, Ich habe hier die richtigen Entscheidungen getroffen.
Ich hänge nicht davon ab, was irgendwer anders sich für mich sinnvoll ausgedacht hat.

[56:02] Und besonders aus dem Grund, weil dieser gemeinsame Lernprozess von Design und Dev da eine entscheidende Rolle spielt und der braucht einfach Zeit.
Also, wenn ich mir vorstelle, wie das bei mir so vor vielen Jahren angefangen hat, eben noch mit dieser Idee, da ist dieses Design und so soll das umgesetzt werden und gar nicht eben auch mit dem Hintergedanken, ich hinterfrag das auch mal, was ist denn leichter umzusetzen, weil es gäbe ja vielleicht auch den Weg und den Weg und ich führe diese Diskussion gar nicht erst, sondern das ist so gesetzt, so ist es irgendwie geil.
Weil, und das ist, glaube ich, diese, diese erstmal gemeinsame Sprache zu finden und auch irgendwie, ich empfehle vielen UXern oft, ich mache über die, ich organisiere das UX-Meetup, bin aber auch im UX-Verband sehr aktiv und bin da Mentor.
Und da gibt es oft diese Fragestellung, die Entwickler verstehen mich nicht.
Ich halt immer sage, fang doch mal an, die zu lieben. Also mach doch mal UX, also du UXer und versteh die mal. Geh mal in den Diskurs.
Und darum kann es auch richtig Spaß machen, die Debatten zu führen, über Taxonomie zu streiten, anstatt über, du hast das nicht umgesetzt, wie ich wollte.

[57:21] Und das führt zu einer ganz neuen Fruchtbarkeit und ist auch echt total wertbringend.
Aber das braucht halt Zeit.
Das ist auch oftmals erstmal, das ist halt schwerfällig.
Und andersrum erlebe ich halt auch oft Entwickler, die am Anfang Bedenken hatten und sich da nicht auf so Co-Creation und so einlassen wollten.
Und auch da gibt es diese Momente, wo man so Aha-Momente hat und sagt, ach, das ist ja total toll.
Und ich finde ja trotzdem hier mein Gehör.
Ich muss ja gar nicht mitmalen, sondern da fragt mich auf einmal einer nach, wie wäre es denn performanter?
Das ist ja auch irgendwie total cool und das ist auch Teil der UX und so weiter. Ja.

[58:05] Und ich glaube, diese ganzen verschiedenen Konversationen und Sprachen mal, also überhaupt näher zu kommen, mehr sich auf die Sprache des anderen einzulassen, zu verstehen, das braucht Zeit.
Und das ist halt eben diese Reife, die sich da aufbaut.
Und dann kann man halt auch vortrefflich über Komponenteneigenschaften innerhalb der Komponenten-API und sollen wir mit semantischen Token und oder noch zusätzlich mit Komponententoken arbeiten, kriegt dann einen ganz neuen Stellenwert.
Und ich vermute, das heißt aber auch, dass wenn man noch nicht so erfahren im Einsatz von Designsystemen und in der Pflege von Designsystemen ist, dass man das eher zwar ein fertiges Designsystem sozusagen so ein zum direkt mit sich drehenden Rädern landend anbietet, aber man natürlich dann trotzdem es schaffen kann, das im Laufe der Zeit kaputt zu konfigurieren, nehme ich mal an.
Weil man es einfach falsch anwendet, aber das gehört halt ...
Man muss halt schon noch ein mündiger Entwickler bleiben bei seiner täglichen Arbeit, auch wenn man Kickstarter-DS verwendet, ja.
Aber muss man auch, damit man genug Freiheit hat. Man muss die Konzepte auch verstehen.

[59:25] Also keiner kann jemanden irgendwie davor bewahren, dann falsch abzubiegen, einfach weil man sich, also man kann halt nicht zehn Treppenstufen auf einmal nehmen, das geht halt einfach nicht.
Weil ich noch ergänzen würde, das war so ein bisschen, als ich das letzte Mal da war, auch gemein noch unsere Herausforderung, da haben wir halt eben noch nicht das Ding mit den Rädern dran geliefert, sondern quasi nur den komplexen Aufbausatz dafür und dem Hinweis, ja und jetzt fang halt mal an.

[59:55] Und das haben wir halt gemerkt, dass das halt viele vor große Herausforderungen stellt, eben genau wie du sagst, weil man halt sehr viel eigentlich schon sich erstmal anlernen und verstehen muss, um das dann selber in Produktion zu bringen.
Und das ist eben genau der Grund dafür, dass wir jetzt gesagt haben, wie können wir denn das für etwas, was auch für jeden hoffentlich ein bisschen Nutzen hat, so runterbrechen, indem wir halt quasi selber ein Designsystem mit Kickstart DS bauen, was halt so Marketing-Sachen enthält.
Also das, was auf jeder durchschnittlichen Seite wahrscheinlich schon aus UX-Gründen sinnvollerweise gleich aussieht, weil Benutzer es dann schneller verstehen.
Also die Seiten, die halt vor allem von Content-Design nacherleben, also welche Bilder werden da eingesetzt, welche Texte stehen da, wie wird meine Botschaft rübergebracht, dass das eigentlich heute die differenzierenden Merkmale von einer guten Website sind und nicht das tolle Interface-Design.
Das kann deutlich in den Hintergrund treten und deswegen haben wir gesagt, um dieses Auto, was man direkt nehmen kann, wo man direkt einsteigen kann, zu haben, bauen wir jetzt eben dieses Designsystem, was man leicht themen kann, wo man nicht alle Token-Entscheidungen treffen kann.
Ich brauche nur sechs Farben oder so am Anfang erstmal, ohne mich halt auszuschließen aus der ganzen Welt später, wo ich dann auch meine 500 anderen Tokens völlig nach Belieben belegen kann.
Aber ich habe halt erstmal einen guten Startpunkt, der bringt mich schon in Fahrt und von da aus kann ich dann wachsen.

[1:01:15] Und deswegen würde ich sagen, ist das so der Knoten, den wir versucht haben zu lösen seit dem letzten Mal, als ich hier war, wo es halt irgendwie gefühlt schon auch irgendwo noch ein Papiertiger war, wo ich dann sehr viel darüber wissen musste, um es für mich zur Anwendung zu bringen.

[1:01:29] Ja, das finde ich auch, also so ein bisschen so in so Design-Systemen verdeckter Mission.
Also so vorrangig ist jetzt der nächste Release mit den CMS-Startern.
Ja, ich kriege halt sehr schnell so ein, ich sage jetzt mal, funky oder cooles CMS wie Storyblock an den Start gebracht und auch mit wirklich wenig Code-Berührung eigentlich kriege ich es installiert und kriege halt direkt ein Frontend für meinen Headless-CMS dazu.
Und das erfüllt unglaublich viele Anforderungen, eben aus diesem Marketing-Landing-Page-Content-Darstellungskontext jetzt erstmal.

[1:02:09] Und da stecken Designsysteme unter der Haube. Das heißt, für uns ist das aber auch noch ein bisschen zu sehen, wer adaptiert das denn?
Sind das jetzt eher eben so Digital-Teams, die halt nur schnell Landingpages bauen wollen auf einer moderneren Technologie und einem moderneren Stack und nehmen die überhaupt sozusagen das wahr, dass da ein Designsystem unter der Haube ist oder so, das ist ja jetzt für uns auch noch ein bisschen die Glaskugel, die wir dann im März, wollen wir das releasen, so rauslassen und gucken, was passiert da.
Aber für die Firmen, die das entdecken und damit arbeiten und die auch skalieren, die haben halt dann echt sozusagen das Werkzeug schon dabei und müssen dann nur den Koffer aufmachen.
Wir sagen zum Spaß halt manchmal, das ist unser kleines trojanisches Pferd, was wir den Leuten reinschieben wollen, wo dann heimlich hintenrum ein Designsystem aussteigt und so unwiderstehlich ist, dass man einfach mehr davon haben möchte.
Das ist unsere große Hoffnung.

[1:03:13] Und in den Projekten, wo wir dann halt wirklich auch unser Geld mitverdienen, sind wir halt maximal effizient dann, weil wir halt viel, viel schneller sind und dann halt auch nochmal eine ganz andere Konversation auch wieder mit den Kunden führen können, weil es dann wirklich um Content geht und um, was willst du denn darstellen?
Und lass uns doch mal messen, ob das wichtiger ist oder das. Genau.

[1:03:41] Dann kann der Fokus auch nochmal shiften auf wirklich Inhalte, weg von all dem Rahmen, in dem das überhaupt ist.
Ja, vielleicht können wir abschließend nochmal so ein bisschen die Perspektive einnehmen derjenigen, die das Designsystem nicht, also die nicht im DesignOps-Team sitzen, also die sozusagen direkten Einfluss haben auf das Designsystem, sondern die das dann nutzen.
Ich stelle mir dann vor, also wie würde, wie funktioniert denn das, wenn ich das benutze und ich merke, jetzt werden bestimmte Anforderungen von mir gar nicht dadurch abgedeckt.
Also würdet ihr sagen, dass man dann sozusagen für sein eigenes Projekt dann rogue sich die Sachen so irgendwie da dran baut, die man irgendwie braucht?
Oder werdet ihr eher so Verfechter von, hey, dann gebt das zurück in das Design-Team und arbeitet das aus?
Vielleicht lohnt sich das aber manchmal gar nicht, weil das ja so ein Universalbau-Kasten ist, wo aber wirklich nur dieses eine Team was von hat, stand vielleicht bei der einen Sache.

[1:04:56] Könnt ihr da ein bisschen was noch erzählen? Ja, also ein bisschen was hast du ja schon vorweggenommen.
Also wenn es Anforderungen sind, die auch anderen Teams und Nutzern des Designsystems den Mehrwert schaffen, darf man da gerne drüber anfangen, nachzudenken, das vielleicht in den Kern aufzunehmen.
Wenn das aber eine sehr.

[1:05:22] Spezialisierte Komponente für einen Verwendungszweck innerhalb eines sehr speziellen Produktkosmos ist, dann kann man sie vielleicht auch einfach nur dafür bauen.
Also wir hatten mal den Anwendungsfall, da musste dann, sollte eine Anwendung her für das Gelblichtlabor, Und die findet ja auch nur da statt.
Und dann kann man vielleicht ein Token-Set finden, was eben den Farbkontrasten da gerecht wird und dass das halt für bessere Lesbarkeit und so geeignet ist.
Aber das muss ja nicht in den Kern rein.

[1:06:02] Ich würde sogar fast einen Schritt weiter gehen und sagen, ein Designsystem, was an der Stelle mich dazu quasi nötig macht, dass ich rogue hingehe und irgendwas zusammenschuster mit Gaffer-Tape, ist halt auch irgendwie defekt.
Also ein Designsystem, aus unserer Sicht zumindest, sollte von Anfang an Anpassbarkeit in seinem Kern drin haben.
Also wenn ich das anders brauche, dann soll ich es auch anders nutzen können.
Vielleicht mit bestimmten Rahmen, aber das macht keinen Sinn, sind die technisch zu enkodieren, diese Rahmenbedingungen.
Das sind Absprachen, die ich mit Menschen treffe und Entscheidungen, die da getroffen werden.

[1:06:37] Die müssen aus unserer Sicht nicht technisch stattfinden. Dafür sind hoffentlich alle, die damit zu tun haben, mündig genug, um das halt verantwortungsvoll einzusetzen.
Weil wenn du dann solche harten Grenzen und Brandmauern ziehst, wirst du automatisch ein riesen Akzeptanzproblem kriegen.
Aus meiner Sicht, der ja auch Entwickler, ist ja auch völlig berechtigt, wenn da einer die Schotten hochzieht und sagt, benutze es so oder gar nicht, dann werde ich halt reaktionär.
Dann denke ich mir halt, nö, dann zerlege ich dir das Ding jetzt halt so ungefähr.
Und dann zeige ich dir, warum das doof ist, was du da ausgedacht hast.
Also ich glaube auch da von vornherein anzuerkennen, dass da meistens fähige Leute auch sitzen, die ihren Job ja auch aus einem Grund machen und eher zu überlegen, wie mache ich es denen denn einfach?
Also bei uns, wie gesagt, einer hat es ja schon ein bisschen angeschnitten, gibt es Component-Tokens, die kann jemand dann halt auch einfach austauschen für sich, für seine Komponente.
Und wenn der den Wappen dann grün macht, weil der jetzt jetzt in der Kampagnenummer halt grün ist und nicht in der Brandfarbe, dann kann er das halt auch tun.

[1:07:34] Sollte er tun. Genau, aber es könnte ja sein, also ich denke mal, dass es auch wahrscheinlich eine Weile braucht, bis ein Designsystem, bis man wirklich alle Komponenten und Bausteine drin hat, die so gebraucht werden, so im Daily Doing von Digitalschaffenden, sage ich jetzt mal.
Ich glaube, das ist ja auch, man unterschätzt das ja, glaube ich, wie viele verschiedene Bausteine man am Ende dann doch braucht wahrscheinlich.

[1:08:06] Dann sollte man das wahrscheinlich idealerweise eben zurückgeben und dann eben mit dem DesignOps-Team vielleicht mal sozusagen für dieses Projekt zusammen was entwickeln. Mhm.

[1:08:20] Also wir werben auch da halt immer für den Austausch halt, diese Kanäle auch zu bieten, dass man irgendwie auch aktiv mitbekommt, wie wird mein Produkt eingesetzt und wie, also jetzt sage ich selber schon Produkt, wir sehen das halt auch wirklich in der Innensicht in so einem großen Unternehmen, ist das eigentlich ein Produkt, was man vermarktet als so ein Design-Ops-Team.
Das ist so ein bisschen auch das Verständnis eben, seinen Anwendern da auch über die Schulter zu schauen und zu schauen, was funktioniert.
Und deswegen würde ich schon sagen, dass da ein Rückkanal super wichtig ist und dass auch da Lernen aus den Projekten super wichtig ist.
Genauso ist es aber eben auch wichtig, halt nicht so einen Bauchladen aufzumachen.
Du hast es ja auch schon so ein bisschen angesprochen. Wenn ich da alles und jeden aufnehme, dann habe ich halt auch schnell eine ganz schöne Suppe, die ich mir da zusammen gebraut habe, die irgendwie keinem mehr so richtig im Kern vielleicht auch hilft.
Also aus unserer Sicht auch da Layering, Aufteilen von Kompetenzen, das eine Team hat mit dem CMS zu tun, also nutzen die vielleicht den Kern des Designsystems und bauen sich ihr eigenes Package mit Content-Komponenten auf, daneben gibt es das Team, das baut die Dashboards, das hat da vielleicht sogar Material UI im Einsatz, sie nutzen gar nicht die Component Library, die im Designsystem steckt, sondern sie nutzen Material UI, weil sie damit viel, viel schneller sind, können aber trotzdem irgendwie das Token-Set wieder anbinden, also ziehen die sich halt die Tokens rein und mappen das auf ihr Material.
Mui-Theme in ihrer Backend-Anwendung.
Und so kann sich das halt total unterscheiden, glaube ich, auch wie man das nachher angeht.

[1:09:44] Und es gibt ja auch oftmals einfach viele Legacy-Systeme, die lassen sich nicht so einfach adaptieren.
Und dann ist auch gar kein Budget dafür da, dass selbst sowas wie Token integriert werden.
Und die leben dann erst mal nebeneinander.

[1:10:00] Oftmals kommen halt Firmen auf den Dreh, wir machen irgendwas Großes neu.
Unsere Dotcom, also eigentlich der wichtigste Point of Sale oder wir haben halt ein Rebranding anstehen, das ist doch dann der Moment, wo wir jetzt auch das Design-System mit einkaufen oder aufsetzen.
Also das ist so oftmals ein Szenario, was bei uns aufsteigt und wo wir dann halt auch sehr scharf nachfragen, wie ist denn das Ökosystem überhaupt?
Überhaupt, lässt es das denn zu?
Also ich meine, du kannst jetzt sehr viel Geld für ein Designsystem ausgeben, dir das aufbauen lassen, entweder extern oder mit unserer Hilfe intern.
Aber wie sieht denn die Landschaft aus? Also das ist auch immer total wichtig abzufragen.
Es ist ja nicht jedes irgendwie ein Startup und man wächst auf der grünen Wiese, sondern da gibt es Anwendungen, die sorgen halt für den Umsatz und die sind dann halt auch brandgefährlich, wenn man da rangeht. Da kann man auch sehr viel abschießen.

[1:11:08] Das heißt also, dass die eigenen Projekte müssen auch ein Stück weit für ein Designsystem gemacht sein.
Also die Entscheidung alleine, den Wunsch kann man hegen, aber je nachdem kann man sich den Wunsch vielleicht gar nicht erfüllen erstmal.
Ja, macht aber auf jeden Fall am meisten Sinn, das vielleicht im Zuge eines kompletten Abrisses dann anzugehen. Ja, aber ich werde da fast manchmal auch skeptisch sein.
Das macht halt alles auch irgendwie hochriskant an der Stelle und bringt halt sehr viele Stakeholder gleichzeitig ins Boot.
Jetzt wird der Ruhr-Uni in Bochum ein großes Projekt gemacht für uns zumindest, wo es darum ging, denen eine Komponentenbibliothek hinzustellen für die Marketing- und Kommunikationsabteilung bei denen, die schon sehr technisch sind.
Also das sind glücklicherweise schon Leute, die sich da sehr tief mit solchen Systemen wie Drupal auseinandersetzen und wie sie da besser an ihre Hauptanwender drankommen mit dem, was sie so rausgeben.

[1:12:08] Und die haben halt auch ein Designsystem im ersten Schritt jetzt gebaut, einfach erstmal, um das zu strukturieren. Und die stehen gerade davor, sehr viel in ihrem Auftritt zu ändern.
Das heißt, die haben das sehr bewusst davor gezogen gemacht, um quasi schon mal die Diskussionsgrundlage dann für das große Rebranding zu schaffen und Kontext zu schaffen, der dann ja so ein Rebranding selber wiederum viel einschätzbarer machen kann.
Also ich glaube, es gibt da auch großen Wert zu entdecken, eben das zu entzerren und bestimmte Erkenntnisse schon vorher zu gewinnen, bevor man dann so ein Riesensystem, also wir sprechen jetzt heute von Riesensystemen, über die dort kaum sprechen, weil viele von den Leuten, mit denen wir zu tun haben, selber ihre Hauptinternetseite auch als den Hauptkanal haben.
Das heißt, das ist deren wichtigstes System.
Das ist das, wo am meisten Legacy existiert im Zweifel, wo am meisten Prozess, der gar nicht unbedingt nur technisch ist, drumherum existiert, der mitbedacht werden muss, damit sowas funktionieren kann.
Und da macht man sich vielleicht auch das Leben sehr schwer, so viel auf einmal abzuweißen. Mhm.

[1:13:12] Das heißt also, das Designsystem nutzt man dann sozusagen als Sandbox erstmal, um ein Rebranding, so, um quasi zu gucken, wie das wirkt, wie das in der Praxis dann sich anfühlt.
Und wahrscheinlich kann man dann auch, so wie man eine Komponentenbibliothek sich anschauen kann, kann man wahrscheinlich genauso so Dummy-Seiten komplett bauen.

[1:13:38] Und auch sogar theoretisch schon vertesten als Prototypen, da erste Erkenntnisse sammeln.
Und ich glaube, dass es einfach wertvoll ist, Gedanken zu Struktur, sich unabhängig von Design zu machen.
Für mich hängt das erstmal nicht zusammen, wie etwas aussieht, welchen Nutzen es hat und wodurch es definiert wird.
Also natürlich ist dann am Ende im Browser das Design ein wichtiger Part, aber andere Punkte sind eigentlich viel entscheidender an der Stelle.

[1:14:05] Ja, spannend. Alles sehr, sehr spannend.
Coole Thematik, die ihr euch da rausgepickt habt. Finden wir auch.
Genau, ich würde auch direkt das nutzen, um an unsere Hörerinnen und Hörer die Aufforderung zu schicken, mischt euch doch auch ein und schaut bei uns in unserem Community-Slack vorbei oder schreibt irgendwen von uns Vieren an, wenn ihr dazu Gedanken habt.
Habt, sei es, was für Probleme ihr beim Anwenden von Designsystemen habt oder wie hängt ihr die auf in eurer Firma?

[1:14:41] Habt ihr ein Designsystem? Funktioniert das gut?
Das würde uns, glaube ich, sehr interessieren. Und nutzt ihr Web Components zum Beispiel? Also wie funktioniert das bei euch?
Schließen wir uns auch gerne an. Wir lesen selber gerne immer mit und sind da ja, wie gesagt, auch auf einer Reise und das ganze Thema auf einer sehr großen Reise, sich überhaupt zu finden erst mal.
Und das lebt ja davon, zu hören, wie andere das empfinden, was da die Herausforderungen, die Probleme sind.
Ich glaube, da ein offenes Ohr zu haben, ist mit das Wichtigste erst mal.
Genau, also ich wollte euch auch mit einschließen. Mit den Vieren, die wir hier darüber gequatscht haben.
Genau. Ja, cool. Super.
Vielen lieben Dank, dass ihr da wart und dass wir darüber sprechen konnten.
Genau, das letzte Mal haben wir das vor anderthalb Jahren gemacht.

[1:15:32] Da ist auf jeden Fall einiges Neues noch dazugekommen, Spannendes.
Und ich glaube, dass das auch ein Dauerbrenner-Thema bleibt.
Deswegen können wir uns einfach nochmal in anderthalb Jahren oder was weiß ich, vielleicht in einem Jahr oder in zweien, wie auch immer, können wir uns ja auch nochmal hier zusammenfinden und dann wieder ein The State of Design System Revision aufnehmen. Sehr gerne.
Absolut, dann kann ich mich nur anschließen. Es ist immer nett, mit euch zu plaudern. Absolut.
Ja, und dann viel Erfolg beim Launch des schlüsselfertigen Ende-zu-Ende Design-Systems.
Oh, jetzt steigt die Fallhöhe gerade rapide.

[1:16:22] Ja, nee, ganz ehrlich. Also, finde ich total cool. Bin ich gespannt, wie das läuft.
Ja, ich ziehe mir schon meinen Helm an.
Cool. Alles klar. Ja, vielen Dank, dass wir nochmal dabei sein durften.
Oder ich erstmalig, aber ja.
Genau, letztes Mal hatte das ja, glaube ich, nicht geklappt.
Dann hast du ja bei den Webworkern in Düsseldorf was erzählt, da konnte Jonas dann nicht.
Genau. Jetzt haben wir euch endlich mal beide hier zusammengekriegt.
Cool. Viele Grüße nach Bonn. Bitte weitermachen. Und wir lesen und hören uns.
Und an unsere Hörerinnen und Hörer, vielen Dank fürs Zuhören.
Bis nächste Woche. Macht's gut. Ciao.

[1:17:09] Music.

[1:17:25] Bis zum nächsten Mal.