Echtes AI Prototyping statt Figma & Penpot: Feedback in Stunden statt Wochen | #KIundTECH

[00:00:00] Hallo und herzlich willkommen zurück zu einer neuen Ausgabe des KI und TECH Podcasts. Mein Name ist Holger Winkler und ich freue mich, dass du wieder da bist. AI verändert nicht nur, was wir an Software bauen, sondern auch, wie schnell wir prüfen können, ob eine Idee beim Nutzer oder Kunden wirklich trägt. Statt mit Figma und Penpot Wochen für Mockups, Abstimmungen und Click Dummies zu investieren, verkürzt AI gestütztes Rapid Prototyping die Arbeit von Produkt UX

[00:00:30] und TECH Teams radikal. Das sehen wir uns heute an und dazu begrüße ich jetzt ganz herzlich Jens Rositschka von Kick & Boost. In diesem Sinne wünsche ich uns allen spannende Impulse, neue Gedanken und ein wirklich erhellendes Gespräch. Hallo und herzlich willkommen Jens. Ja, hallo Holger. Danke, dass ich hier sein kann. Schön, dass wir das heute gemeinsam angucken dürfen, Jens. Zum Einstieg erzähl uns doch kurz, wer du bist, was du machst für alle, die dich noch nicht kennen.

[00:00:52] Und dann, dann lass uns zu Beginn erst mal AI gestütztes Rapid Prototyping definieren, so auf einer ganz, ganz einfachen Flughöhe bitte. Ja, genau. Aktuell nenne ich mich gerne manchmal Product und UX Creator. Ist jetzt mal ein ganz neuer Begriff. Einfach den Unterschied aufzeigen zu dem, wie es vorher war. Ich habe mich spezialisiert auf AI Rapid Prototyping und AI First Workflows.

[00:01:20] Komme ja gleich noch dazu und bringe aber auch Erfahrung aus Management und in der Praktik mit aus den Bereichen Product, UX und Programmierung. Okay. Lass uns definieren gemeinsam zum Anfang AI gestütztes Rapid Prototyping, sodass es wirklich jeder versteht. Was verstehst du darunter? Was wollen wir in dieser Sendung darunter verstehen?

[00:01:44] Ja, also ich benutze bewusst diese Unterscheidung. Ich nenne es AI Rapid Prototyping, gestützt mit AI. Da man damit Techniken benutzt, indem man Produkt- und Nutzerkontexte clever kombiniert mit Prompt Engineering Frameworks, um mit Vibe Coding neue Features und Produkte zu visualisieren. Im Klick-Dummy gleich ein Code, um sie dann abstimmen zu können mit Nutzern oder Stakeholdern.

[00:02:12] Okay. Jetzt nochmal zurück. Welche Art von Prototypen schauen wir uns heute an? Es gibt ja im Prinzip 3D-Druck und Prototypen daraus. Das ist heute nicht das Thema. Nee, genau. Es ist Softwareprodukte für Apps, Webseiten, aber hauptsächlich Apps eigentlich, genau, Software.

[00:02:33] Okay. Warum, lieber Jens, sollte man sich dieses Interview anhören? Was ist der große Vorteil, wenn wir uns mit dem AI Rapid Prototyping beschäftigen, anstelle es klassisch mit Figma und PenPod zu machen? Ja, das ist jetzt eine gute Frage. Tatsächlich habe ich die Frage sehr oft und sie ist auch schwierig zu beantworten, vor allen Dingen für Unternehmen, die sehr stark in dieser Figma-Welt festhängen.

[00:03:00] Die haben auch andere Wege oder Werte für sich entdeckt, an denen sie gerne festhalten und von denen ist schwieriges wegzukommen. An sich beschleunigt der Prozess heute schon bei Startups und Scale-Ups, mit denen ich rede, radikal den Entwicklungsprozess. Es wird gar nicht mehr Figma benutzt, also Figma kommt gar nicht mehr zum Einsatz. Und es beschleunigt radikal, wie neue Features und Abzweigungen, Produktbereiche entwickelt werden in dem Produkt, das man aufbaut.

[00:03:28] Wir haben ja bereits im Vorgespräch über den Titel dieses Interviews ein bisschen diskutiert. Damit man mitbekommt, um wie viel das das beschleunigt, gib uns doch mal den Ansatzpunkt. Wir haben ja darüber gesprochen, ob das jetzt Feedback in Stunden statt Wochen oder Feedback in Sekunden statt Wochen ist. Welche Dimensionen sprechen wir, damit alle, die in dieser klassischen Prototyping-Welt verhaftet sind für Software, vielleicht sich doch die Augen reiben?

[00:03:55] Ja, tatsächlich, also wenn wir sagen, im klassischen Weg dauern Prototypen eine Woche lang, dann können wir das vergleichen mit Tagen vielleicht oder mit Stunden, weil es dort auch immer um Abstimmungsprozesse geht. Aber das reine Prototyp erstellen, was vielleicht ein guter Prototyper heute an einem Tag schafft, kriegt man mit solchen Tools in Minuten hin. Gerne vielleicht sogar Sekunden erste Konzept-Drafts. Und das direkt aus einem Workshop-Scribble heraus.

[00:04:23] Also jetzt höre ich die Damen und Herren schon schreien, die sagen, ach lass doch, hat da überhaupt keine Qualität, kann man überhaupt nicht vergleichen. Was sagst du dazu?

[00:04:31] Die Qualität steht und fällt entscheidend mit dem Aufwand oder dem Invest, dass man, ja, dem Aufwand, den man investiert, in ein gutes Setup, in gute Kontexte, Produkt-Nutzerseitige Kontexte und wie gut zum Beispiel auch das eigene Style Guide, die eigenen Guidelines des Unternehmens in der Software definiert, repräsentiert sind und für die AI klar verständlich und sofort anwendbar.

[00:05:01] Heißt das jetzt, es ist genauso gut? Heißt das jetzt, es kann besser sein? Heißt das jetzt, es ist schlechter? Lass uns mal auf die Rolle eingehen, auf demjenigen, der vor dem Computer und dem AI-Szenario sitzt und das, was die AI liefern kann. Weil das ist ja, glaube ich, der Schlüssel einer ganzen Geschichte. Ja, auf jeden Fall. Das heißt erst mal noch gar nichts qualitativ.

[00:05:28] Es ist wirklich nur erst mal schneller und jetzt vielleicht mit Blick auf einen UX-Designer oder Product-Designer im Softwarebereich zurückzuführen. Wenn er seine Prozesse nicht beschleunigt, dann kann es passieren, wie mit dem Beispiel der Startups gerade, dass er komplett raus aus dem Spiel ist. Weil während er noch überlegt, wie er vielleicht seine Dateien aufbaut, ist schon längst auf der anderen Seite das Feature fertig gebaut.

[00:05:53] Also das ist die Gefahr, die ich hier sehe, dass hier vor allen Dingen dann auch qualitativ unterscheidende Rollen raus aus dem Spiel kommen und wirklich dann in die Hand von AI übergeben wird, wie jetzt nutzerseitig eine Software gebaut wird. Und die macht das genauso schlecht tatsächlich, wie wir vor 15 Jahren mitunter. Wenn die Systeme nicht gut installiert sind und aufgesetzt sind, dann schreibt es halt an einem Button Senden dran, anstatt irgendwie einen guten nutzerseitigen Text.

[00:06:24] Also ich habe mitgenommen, dass es eigentlich so ist, dass die AI ohne denjenigen, der sie bedienen kann, plus minus wertlos ist, weil da kommt eigentlich dann wirklich Bullshit raus. Und deswegen steht und fällt es eigentlich mit demjenigen, der davor sitzt und das im Prinzip als Werkzeug einsetzt. Soweit richtig? Und wenn ja, gib uns doch zwei, drei Sätze dazu über dieses Rollenverständnis.

[00:06:50] Ja, absolut. Das sehe ich genau so und ich sehe das ja auch in anderen Bereichen schon. Tatsächlich ist es hier, wenn man an die gleichen Techniken einen Entwickler setzt, dann kann er damit schneller arbeiten und schafft uns eine sichere Software, die Datenschutzthemen einhält ohne Probleme. Wenn wir einen Product Manager heransetzen, dann wird bestimmt auf jeden Fall die Business-Kriterien und die Klickpfade so eingehalten, dass wir ein gutes Geschäft machen können.

[00:07:16] Aber wenn wir wirklich Nutzer begeisternd überzeugen wollen, dann müssen wir in Design investieren und auch eigene Hirnkapazitäten dafür verwenden, um die AI dann praktisch richtig anzuweisen, richtig Kontext zu liefern, dass es das macht, was wir im Sinn haben.

[00:07:37] Also ich habe so als Bild vor den Augen, es gab ja irgendwann als 3D-Konstruktionen die Welt der Architekten zum Beispiel und Gestalter und Designer erobert hat. Da hat ja vorher auch jeder noch mit Hand gezeichnet mit diesen riesen Zeichenmaschinen. Irgendwann war es dann auch klar, dass man da nicht mehr so weitermachen kann, sondern es hat zwar ein bisschen gedauert, aber dann hat das 3D-Programm und 3D-Konstruieren und so weiter und fort Einzug gehalten. Heute würde auch kaum jemand mehr noch mit Tusche, Stift und Zeichenmaschine versuchen, im Wettbewerb zu bestehen.

[00:08:08] Vielleicht ist das ein gleicher, ähnlicher Shift, den wir da vor uns haben. Das bedeutet, es beginnt zwar schon mit der Technik, also mit dem, was AI kann, aber es beginnt eigentlich viel vorher, also viel früher, nämlich mit den Menschen, die davor sitzen, der Bereitschaft, dem Willen und auch der Begeisterung dafür. Ist das so? Ja, absolut. Also ich hatte erst gestern jetzt hier ein spannendes Gespräch darüber. Da hat dann jemand gesagt, okay Jens, man merkt ja, dich begeistert das Thema.

[00:08:38] Ich habe vor eineinhalb Jahren, habe ich wirklich darin Zeit investiert, mir ein Szenario ausgemalt. Okay, mein Job wird in den Arten, wie ich ihn interpretiere, wird er sich komplett ändern und das bevor ich in Rente gehe. Und ich muss da jetzt Zeit investieren, ich muss den Schritten vorauseilen. Und tatsächlich ist es so, dass ich aus den Modellen ganz andere Dinge raushole als andere. Das ist ja auch völlig legitim, ich gehe mit meinem Mindset ran.

[00:09:05] Ich optimiere die Prompts in die Richtung, dass die Ergebnisse so passen, dass ich zufrieden bin. Also das ist absolut, kann man das unterstreichen. Wie ändert sich denn jetzt das Prototyping konkret zwischen dem klassischen Vorgehen, so wie wir das heute State of the Art machen, im Vergleich zu AI-gestütztem Rapid Prototyping?

[00:09:28] Wenn wir jetzt mal so aus dem Snapshot rausgucken, lass uns mal, wir können es vielleicht auf verschiedene Ebenen unterzeichnen oder unterteilen. Mit welcher Ebene möchtest du anfangen? Wie unterscheidet es sich, welche Ebene fangen wir an? Mit Ebenen meinst du? Also wir hätten vielleicht den klassischen Projektflow, wir hätten die Tools, wir hätten die Personen. Je nachdem, also welche Ebenen du siehst an der Stelle. Okay.

[00:09:58] Genau, die Ebenen, die ich sehe an der Stelle aktuell, ist es wirklich so. Nehmen wir, ich fange mal mit dem groben Überblick oder dem groben Workflow, den gesamten Workflow ab. Gehe dann gerne ins Detail bis hin zum eigenen Workflow im Prototyping und danach komme ich zu dem Punkt, wie dann einzelne Schritte darin aussehen vielleicht noch.

[00:10:23] Also früher ist es so gewesen, dass Designer sehr viel schneller waren als Entwicklung. Deswegen konnten wir uns längere Designprozesse erlauben. Wir konnten länger darüber reden, über die Varianten. Wir konnten Nutzer auch testen. Wir hatten die Zeit dafür. Und bevor das dann wirklich programmiert wurde, weil Programmierung auch immer komplexer wurde in den letzten Jahren. Sicherer, besser ausführbar, wartbar und so weiter. Standardisierter. Und das hat sich jetzt komplett quasi verändert.

[00:10:53] Sogar so, dass ich sehe, dass einige Teams oder auch einige einzelne Gründer komplett an einem Tag die gleiche Arbeit wie eine Woche leisten, bis hin zu einem Monat in der Woche und nicht einmal mit Nutzer geredet haben. Das nannten wir früher schon Feature-Retis und das kann man heute noch so machen. Und das führt dazu, dass ich empfehle, den Workflow anders aufzusetzen. Wirklich eine kurze Zeit in neue Funktionalität zu investieren und dann sich genug Zeit zu geben, mit Nutzern zu validieren.

[00:11:21] Und quantitativ oder qualitativ ist hier egal. Ich persönlich bevorzuge qualitativ. Auf jeden Fall immer als im Schritt vor dem Quantitativen überprüfen. Und genau, also so mal grob. Ich sehe, dass es noch nicht ganz angekommen ist, sondern es wird wirklich weiter feature-pleißig gebaut, anstatt sich jetzt Zeit zu nehmen, tatsächlich mit Nutzern dann und mit Kunden ausgiebig zu reden, von den gleichen Teams, die auch bauen. Wenn man jetzt hier hineinzoomt, früher haben wir dann wirklich,

[00:11:51] also ich habe ja wirklich alle drei Rollen durchspielt, UX, Product und Management. Product und UX haben meistens sich mit Consulting von Tech zusammen neue Prototypen überlegt, haben sie gebaut, haben sie Management gespiegelt, haben sie Nutzer getestet. Und hier ist es jetzt so, dass man das an einem Vormittag erledigen kann. Also aus reinen kleinen Scribbles mit einem richtig aufgesetzten Setup kann ich schnell mir Konzepte erstellen lassen, die ich dann als Vorstufe für Prompts fürs Coding nehmen kann.

[00:12:20] Und ich empfehle auch stark, das zu trennen. Denn so ein AI-Coder, der muss halt auch viel darüber nachdenken, wie er das programmiert. Und oft überlasten wir dann die Modelle oder die Kontext der Modelle, wenn wir dort auch noch das Konzept mit hineinschieben. Dann tendiert er dann doch öfter zu Standards oder zu den Sachen, die aus Best Practices reintrainiert wurden, aus guten Softwarebeispielen. Genau.

[00:12:47] Also das ist dann die nächste Ebene, diese Arbeit zu unterteilen in zwei Schritte. Konzept, Planung, zusammen mit einem Large Language Model einfach nur, dass ich genau weiß, was ich will und wie ich es will. Daran schnelles Itarieren an Programmierung zu gucken, wie würde sowas aussehen. Und da kann man alles machen. Da kann man kleine Prompts testen, da kann man große Prompts testen. Wichtig ist nur, dass man ständig seine Prompts optimiert,

[00:13:12] bis für einen dieser erste Outcome aus dem Weibgecodeten, von der AI erstellten, programmierten Prototypen, dass der einem gefällt. Dass man sagt, okay, da ist jetzt alles so, wie ich es gemacht hätte gerne. Das übernehme ich jetzt und itariere daran weiter. Und dann ist es dann einer der Hauptfehler, die ich dann gerne auch immer wieder sehe, dass wenn ich einen schlechten Prompt starte und danach immer weiter verfeinere und refine,

[00:13:41] die Modelle wirklich Probleme haben und im Code, nicht in der sichtbaren Ebene für den Nutzer, sondern im Code Dinge übereinander lagern, sodass der Code immer mehr verwurschtigt wird, Kraddelcode wird, Legacycode ganz schnell und das nicht dienlich ist und man mit dem Prototypen danach nichts mehr unbedingt machen kann. Lass uns kurz angucken, die Tiefe oder Funktionalität, die dann ein solcher Prototyp haben kann, im Vergleich zu dem klassischen Vorgehen.

[00:14:12] Weil wir haben ja häufig, so wenn ich es richtig sehe, früher reine Click-Dummies gehabt, die eigentlich im Prinzip kaum Funktionalitäten hatten, wo wir wirklich bloß einen theoretischen Ansatz getestet haben. Jetzt ist das ja teilweise komplett anders, richtig? Absolut, ja. Also es gab da zwar auch früher schon Ansätze in Programmen, dynamische Daten in Prototypen reinzulegen, aber in der schnelle und in der Art und Weise, wofür wir Prototypen eigentlich brauchen, wurde dafür dann oft nie Zeit investiert.

[00:14:42] Und was wir gemacht haben, waren Szenarios hart, in die Prototypen reinzubacken. Das ist also wirklich auch das ganze Skript, wie wir den Nutzertest danach führen, optimiert ist auf ein Nutzungsszenario und dann alle Texte gepasst haben. Das war sehr angenehm und praktisch, aber es blieb statisch. Der Invest jetzt in datengetriebene Prototypen ist sehr gering geworden. Also wir können wirklich ganz klar auf jeden Fall schon mal reagieren auf Nutzerinteraktion

[00:15:11] und Dinge in der Software verändern, basierend auf der Interaktion. Ganze Abzweigungen bauen, die sich anders verhalten, was vor allen Dingen komplexeren B2B-Softwares extrem dienlich sein kann, aber auch für First-Usage-Flows in B2C-Produkten. Und wir können tatsächlich sogar APIs andocken. Hängt natürlich jetzt alles von dem Unternehmen ab,

[00:15:39] wie sehr sie ihre eigenen APIs daran docken möchte und kann. Oder aber auch sogar Large Language Models connecten über die API und AI-Interaktionen Prototypen und Mockupen. Prototypen und schnell visualisieren. Und das hier wird natürlich entscheidend, weil so eine AI-Interaktion und so ein Chatbot zum Beispiel lebt ja nur davon, dass die Interaktion in der Veränderung

[00:16:06] von Input zu Output des Bots passiert. Das kann ich gar nicht mehr mit Figma machen. Ich habe das Gefühl, früher hat das Ganze einfach Zeit gekostet und es war begrenzt wahrscheinlich durch gewisse Kapazitäten, zeitlich und finanziell. Jetzt habe ich das Gefühl, es geht alles viel, viel schneller. Die Gefahr, die ich so ein bisschen sehe, ist, dass man deswegen trotzdem nicht früher auf den Punkt kommt, sondern mehr Tiefe reinbaut,

[00:16:36] mehr Varianten baut. Bin ich da richtig oder wie denkst du darüber? Was müssen wir daraus ableiten, wenn die These richtig ist, für eine gute Projektstruktur? Ja, absolut. Ich sehe das genauso. Wir erzeugen gerade sehr viel Daten. Und es werden auch sehr viele Daten aufbewahrt und aufgehoben, die eigentlich so flüchtig waren, wie in der Vor-AI-Zeit eigene Gedanken. Ich sehe das absolut, dass wir viele Varianten erzeugen.

[00:17:06] Wahrscheinlich sogar die Arbeit. Also Arbeit nimmt sich immer den Raum, den sie braucht. Oder wie ist dieser Spruch? Und manche Ideen, ganz klar, manche Ideen müssen reifen beim Entscheider. Also die Rolle wird generell weggebracht von jemandem, der tut und macht, hin zu jemandem, der Ergebnisse entscheidet oder Ergebnisse versucht, entscheidungsfähig zu machen, durch Validierung zum Beispiel. Und die Entscheidung wird oft nur getroffen,

[00:17:35] wenn man die eigene Erkenntnis hat reifen lassen. Also es ist nur so schnell, wie wir denken, wie wir entscheiden können tatsächlich. Und in der Zwischenzeit kann sehr viel passieren. Variationen können erzeugt werden. Es kann Unsicherheit durch Überangebot an Ergebnissen entstehen. Absolut. Das ist organisatorisch. Die Frage, kann man da groß reagieren? Oder ist es nicht einfach auch ein Mindshift, der stattfinden muss?

[00:18:04] Eine Erkenntnis, durch den die Menschen laufen müssen bei der Arbeit mit solchen Tools? Vielleicht wird auch nochmal alles dringlicher, wenn die KI-Unternehmen endlich schwarze Zahlen schreiben und wir nicht alles immer so kostenlos und einfach kriegen. Ich denke, es geht auf jeden Fall um Mindshift. Bestimmte Dinge waren vorher schon sehr gut. Es müssen Entscheidungen getroffen werden auf validen Grundlagen, auf Einbezug mit Stakeholdern. Das geht nicht weg und das war eigentlich schon vorher da.

[00:18:32] Bevor wir gleich ins Detail nochmal gehen, was das für Kapazitäten oder Wissen bei den Menschen braucht, die damit arbeiten, würde ich gerne kurz abbiegen, woanders hin. Nämlich über die Rolle, die Bedeutung und den Umfang vom Prototyping. Weil ich denke, es gibt viele Unternehmen, die unendlich viel Geld investieren in dieses Thema. Dass das nicht unbedingt heißt, dass das Ergebnis gut wird. Das sieht jeder, der einen aktuellen VW fährt,

[00:19:01] an der Software und dem UX, das dahinter steckt. Auf der anderen Seite gibt es Unternehmen, die vielleicht für das Thema kaum ein Auge haben, weil sie einfach Dinge an den Markt bringen wollen. Also wir haben so eine enorme Spannbreite zwischen, ich würde sagen, einer Wissenschaft, die sich verselbstständigt hat, mit fragwürdigem Ergebnis, aber mit einem sehr großen Selbstverständnis, dass das extrem wichtig ist, was man da tut. Und auf der anderen Seite, die da eigentlich kaum Augenmerk oder viel zu wenig legen.

[00:19:31] Du mit deiner Erfahrung, mit dem, was du jetzt gesehen hast und vor der Herausforderung, jetzt das Ganze vielleicht viel schneller machen zu können. Was sind denn realistische Ziele des Prototypings, des UX-Prototypings dahinter, die man ansetzen sollte und wie bekommt man das in das richtige Verhältnis von Aufwand und Nutzen? Hui, das war jetzt lang. Was ist die konkrete Frage am Ende? Sorry. Alles kein Problem. Also die konkrete Frage ist,

[00:20:00] welche Ziele sollte man sich schlauerweise setzen, die man mit dem Prototyping wirklich realistisch erreichen möchte? Was ist das Outcome und wie viel Invest packe ich dahinter? Ja, genau. Also das kann ich auch tatsächlich wieder auf mehreren Ebenen beantworten. Wie viel Invest betreibe ich dafür? Ich sehe es ja auch, dass in Unternehmen vor allen Dingen, jetzt zum Glück haben sie jetzt Zugang und dürfen selbst mit experimentieren. Es ist ja auch unglaublich, wie viele Tools mittlerweile freigeschaltet sind

[00:20:30] und was wirklich vor einem Jahr noch undenkbar war für viele Mitarbeiter in größeren Unternehmen. Und natürlich passt das wahrscheinlich einfach ans Daily Business nicht rein, wenn man im Daily Business liefern muss. Und wir haben ja auch, du hast VW genannt, das Beispiel, dass in wirklich sicher geglaubten Branchen sogar dann auch noch Mitarbeiter verschwinden. Das heißt, Investitionen in solche Techniken kann ja fast dann nur in der eigenen Freizeit, in der privaten Zeit stattfinden. Und das nochmal zu transferieren

[00:20:59] in den täglichen Arbeitsfluss ist natürlich eine ganz andere Herausforderung. Ich sehe das wirklich dann am stärksten bei jüngeren Unternehmen, die sich halt Zeit dafür nehmen, sowas gleich im Unternehmen in die DNA reinzubauen. Es gibt nie genug Zeit dafür investiert. Ich habe mittlerweile das Gefühl, es kommt nicht viel Neues nach. Es verbessern sich nur die Techniken. Also ich denke an einem bestimmten Punkt, wenn man tiefer drin ist, bekommt man dieses Gefühl und man ist vorbereitet sogar auf die neuen Releases der Softwareunternehmen. Ich aktuell, wahrscheinlich wäre es mir

[00:21:29] in einem halben Jahr an, schlaibe ich mir die Hände über den Kopf. Ich denke, aktuell geht es vor allen Dingen um Skalierung der Modelle, effizientere Modelle, multimodales Arbeiten, Austausch. Das sind praktisch Systeme um diese Kerntechnologie. Und wie viel Zeit? Ja, genau. Man sollte auf jeden Fall versuchen, bestimmte Arbeitsbereiche AI-first anzugehen, einfach als Gedanken, als Grundlage und schauen,

[00:21:58] wie sich darauf die Arbeit verändert. Sie shiftet mehr zu einem Spezifizierer und jemanden, der dann Ergebnisse abnimmt, anstatt wirklich Dinge zu machen dann am Ende. Und in einem Arbeitsbereich schon damit anzufangen, ist auf jeden Fall ein guter Invest. Ich gehe nochmal zurück, Jens. Also aus meiner Sicht haben wir Folgendes. Wir haben vorne die grundsätzliche Idee, etwas neu zu schaffen, ein Angebot, eine neue App. einen neuen Service. Ich habe im Idealfall schon etwas, möchte das besser machen. Also ich habe da schon Cashflow dahinter.

[00:22:28] Da läuft schon Geld, ich möchte es besser machen. Oder Alternative, ich habe eben eine Idee, möchte damit starten. Also die Idee ist die erste. Dann müssen wir das in irgendeiner Form in ein Teststadium bringen. Das sind wir jetzt gerade bei dem Prototyping. Und nur, weil der Test plus minus gut läuft oder wir fünf Varianten im Prinzip nachher dann validieren können, bedeutet es ja noch nicht wirtschaftlicher Erfolg, sondern da sind nochmal ganz andere Stellschrauben dahinter, dass das nachher auch verkauft wird und dass es dann auch

[00:22:58] danach auch tatsächlich noch Ertrag gibt. Also im Prinzip das Prototyping ist ja nur ein ganz, ganz kleiner Punkt innerhalb dieser Kette zum wirtschaftlichen Erfolg. Was sind aus deiner Sicht realistische Ansätze, die ich mir geben sollte, was das Zeitfenster und den Invest angibt? Wie viele Prototypen sollte ich fahren? Wie viel Zeit sollte ich mir da nehmen? Was sind die Rahmenbedingungen, die sinnvoll sind? Ja, das ist eine gute Frage. Das blickt auch so sehr stark in die Zukunft. Also tatsächlich ist dieses Prototyping

[00:23:27] halt immer dann sinnvoll, wenn ich auf jeden Fall etwas an dem Produktumfang verhindern möchte. Das ist was, das hat jetzt UX schon, redet schon sehr lange darüber. Es wird tatsächlich nicht wirklich überall gemacht und es ist auch nicht immer notwendig. Aber in bestimmten Funktionalitäten, bestimmten Team-Setups, tatsächlich auch. Also es gibt wirklich Menschen, die vielleicht dann schon ein bisschen intuitiver verstehen, die Sprache, die der Nutzer spricht oder der Kunde.

[00:23:57] Aber es ist immer hilfreich. Man lernt so viel. Also ich habe schon selbst so für mich unglaubliche Nutzerbefragungen erlebt, von denen ich sicher ausgegangen bin, dass eigentlich alles klar verständlich sein müsste und die Probleme sind an ganz anderer Stelle aufgetreten. Ich kann das leider mit meiner Erfahrung in dem Bereich nicht empfehlen oder gar nicht mehr zu machen. Das ist tatsächlich so. Und ich würde wirklich vor jedem Schritt, der größer vor allen Dingen ist, der das Produkt vor allen Dingen inhaltlich komplett verändert,

[00:24:28] so einen Testlauf machen. Und generell Prototyping ist ja auch ein bisschen Vorvisualisieren, allein schon für das Entwicklungsteam und klarer spezifizieren, wie es nutzerseitig aussehen soll, damit man da schon einen Haken dran machen kann, dass man das nicht in der Entwicklung mit den Entwicklern zusammen sich ausdenkt. Das heißt, wenn ich es richtig mache, spare ich dahinter Entwicklungszeiten und Entwicklungskosten, weil ich vorne sehr, sehr konkret

[00:24:57] das Ziel definieren kann und voraussehen kann, was wahrscheinlich funktioniert. Genau. Und diese Kosten sind natürlich tatsächlich höher beim Nochmalmachen. Die Umbauarbeiten sind immer aufwendiger als die Erstbauarbeiten. Allein nur eine Textänderung kann, naja gut, früher, einen halben Tag Arbeit hinterher sicher ziehen. Aber auch heute noch müssen immer noch alle Dinge angeworfen werden in der Programmierung, die man berücksichtigen muss. Es müssen Tests über die Software

[00:25:27] drüber fahren, damit die released und deployed werden kann. Also jede Änderung zieht einen Rattenschwanz an Arbeit, Prozessschritte in der Entwicklung nach sich, nicht nur die eine Textänderung. Jetzt gehen wir davon aus, wir sind über unser AI-Prototyping zu einem guten Ergebnis gekommen. qualitative Umfragen haben bestätigt, das ist die richtige Richtung. Wir gehen in die Umsetzung, fange ich komplett von vorne an zu programmieren, richtig?

[00:25:56] Ich setze im Prinzip nicht auf das auf, was uns jetzt das Prototyping gebracht hat oder wie ist das? Das hängt tatsächlich wirklich von dem Skillset ab, wer hier jetzt auch gerade programmiert hat mit den Coding-Tools, wer das reviewed hat. Ich habe da in meinen Befragungen mit Unternehmen und bewusst bin ich auch an Scale-Ups und Start-Ups gegangen in meiner Recherche-Phase. Hängt das sehr stark ab, wer das da jetzt baut? Ich habe Antworten bekommen von der Geschäftsführer,

[00:26:26] macht ein Prototype und der Entwickler baut das mit Multiagenten nach bis hin zu Entwickler und Product Manager planen ein Konzept zusammen und Entwickler baut es in seiner Codebase als einen eigenen Branch und das wird Nutzern vorgelegt. Natürlich kann der Entwickler dann diesen Branch, der wie ein Prototype ist, schnell so auf einen technischen Stand bringen, dass es rein merchen kann, also verbinden kann mit der Produktionsumgebung. Okay, letzte Frage für heute.

[00:26:57] ich bin verantwortlich im Prototyping bisher. Ich merke, hey, da kommt eine neue Welle auf mich zu. Dieses AI-Thema haben wir bisher als spannend angesehen, aber wir können noch nicht so richtig umgehen. Was wären aus deiner Sicht die zwei Entscheidungen, die ich treffen sollte, damit es morgen mir besser geht als heute? Die zwei Entscheidungen? Hatte ich das als Vorbefragung? Nein, nein. Die zwei Entscheidungen? Also, ja klar,

[00:27:27] ich meine, eine habe ich ja ganz offensichtlich selbst getroffen. Ich bin ja nicht reiner UX-Designer, sondern ich war ja auch wirklich in anderen Berufsstationen, vom Management bis Entwicklung und habe selbst für mich gesagt, okay, ich gehe voll rein in das Thema. Es ist faszinierend, deswegen fiel mir die Entscheidung leicht. Also, ich bin sehr fasziniert davon. Fühlt sich an wie 1996, als wir das erste Mal Webseiten gebaut haben. Also bedeutet, erste Entscheidung ist, ich interessiere mich dafür, finde ich cool, ich investiere

[00:27:56] meine eigene Zeit in Anführungsstrichen und gucke, mir da Wissen aufzubauen. Ist das so? Ja, klar, ich meine, ja, also, das ist schwierig, aber ich tendiere schon immer dazu, meine eigene private Zeit in solche Themen zu investieren. gut, das war die erste Entscheidung. Zweite Entscheidung, damit sich konkret was ändert, was mache ich dann, wenn ich die Entscheidung getroffen habe? Ich würde tatsächlich von allen liebgewonnenen, angenommenen Anforderungen an meinen Beruf

[00:28:25] und an meine Arbeit mich als erstes verabschieden und sie jeden Tag kritisch hinterfragen. Wow, okay. Ja, was mache ich dann stattdessen? schauen, wo ich mit neuen Möglichkeiten die Lücken füllen kann, aber auch hinterfragen, ob es diese Prozessritte überhaupt noch notwendigerweise gibt. Das ist tatsächlich was, was ich in den letzten eineinhalb Jahren durchlaufen habe. Solche Gedankengänge wie, wenn das jetzt geht und das so schnell geht

[00:28:55] und das so einfach geht, was sollte ich denn dann eigentlich überhaupt machen? Wo fange ich an? Es geht ja um neues Wissen, es geht um neue Skills. Mit was fange ich an? Wo fange ich an? Aus deiner Sicht, wenn ich in diesem Bereich mich weiterbilden möchte? Ja, das ist das total spannende Frage, mit der ich mich auch gerade auseinandersetze, weil mich ja auch das Thema einfach aus wirtschaftlicher Sicht interessiert, wie ich Teams helfen kann, unterstützen kann, schneller voranzukommen auf diesem Pfad.

[00:29:26] Aufgrund der wirtschaftlichen Lage, wo es vielleicht einfach auch bestimmte Engpässe gerade gibt, die Leute werden entlassen, Firmen suchen ja händeringend danach, wie sie Unterstützung bekommen, aber nicht unbedingt zu hoch investieren müssen. Dass es mich halt interessiert, okay, was sind die Punkte, die ich empfehlen würde? Und ich empfehle unterschiedliche Punkte tatsächlich für Product Manager, UX Designer und Entwickler. Generell geht es darum, bestimmte Prompttechniken

[00:29:56] auszuprobieren, je nach dem eigenen Skillset. Und natürlich empfehle ich Product Managern, du kannst erstmal einen Designer loswerden mit dieser Prompttechnik und auch einem Entwickler, aber andererseits dann auch einem Designer, wenn du das in der Form machst, transferierst du dein Wissen. Also Prompt Engineering ist super wichtig, das eigene Wissen, jetzt im Designbereich, in Sätze umzuwandeln, die die Large Language Models triggern, bestimmte Dinge auszuführen.

[00:30:25] Anders als das Generische, was aus den trainierten Daten kommt. Und ja, und das abzuspeichern, Zeit in Context Engineering zu investieren, verstehen, wie Programmierung aufgebaut wird, ist ganz entscheidend, weil nur wenn ich weiß, was dahinter passiert, kann ich es richtig weit coden. Und das auch Sparne ist wirklich dieses Anforderungsmanagement,

[00:30:54] wie spezifiziere ich so, dass es programmiert werden kann, was klassisch im Product Management viel angelegt ist, angesiedelt ist und worauf ja auch irgendwo Trainingsdaten dann in der Programmierung basieren. Also Work ist gutes Design, wie entsteht gutes Design, wie kann ich das klar als Anforderungsmanagement in die Programmierung geben und wie sind die unterschiedlichen Schichten und Ebenen in der Softwarearchitektur? Wenn ich das jetzt übertrage auf die Unternehmensebene, ich habe bisher im Prinzip eine Abteilung

[00:31:24] oder ein Team, das im Prinzip Prototyping macht im Rahmen von App-Entwicklungen. Ich finde das spannend, ich würde gern das Team in diese Richtung buxieren. Es scheint mir keine so wirklich gute Idee, ein neues Projekt, vielleicht sogar ein bezahltes Kundenprojekt, dann auf die neue Technologie aufzusetzen. Was ist aus deiner Sicht der Hack, dass ich im Prinzip solche Kompetenzen richtig effizient bei mir im Unternehmen neben dem bestehenden Skillset aufsetze? Ja, das ist sehr gut,

[00:31:53] das ist sehr gut formuliert und tatsächlich in den letzten 20 Jahren ist das immer wieder so passiert. Also wir machen jetzt mal alles neu und das gleich mit einem neuen Projekt und wir fangen ganz unten an und ziehen erstmal architektonisch alles richtig hoch und machen alles besser und das sind dann solche Projekte, die nach zwei Jahren niemals live gehen. Ich denke, Skills trainieren ist das Wichtige. Wahrscheinlich wirklich sogar in unbedeutenden Projekten oder in unbedeutenden Handlungen gucken, dort nur

[00:32:25] AI-First vorzugehen, ganz einfach. In kleinen Sitesprojekten, kleinen Sidesteps, in kleinen Mini-Aufgaben wahrscheinlich schon dezidiert in ein Team dran setzen oder allen Teams, denen ein Zeitbudget zu geben, dass sie bestimmte Dinge so lösen, nur noch, damit sich solche Fähigkeiten verfestigen. Letzte Frage, wenn ich jetzt feststelle, ich möchte gerne solche Fähigkeiten bei mir im Unternehmen etablieren, kann man die einkaufen? Kann ich einen Headhunter losschicken und sagen, hey, find mir mal

[00:32:55] die fünf klugsten, schlauesten, besten oder ist es ein anderer Weg vielleicht, der anzugehen ist? Was denkst du? Das sind alles so gute Fragen, auf die ich leider aktuell noch wenig Antworten habe. Also ich empfehle das ja wirklich, zum Enablement und zum Verbessern. Es macht Sinn, sich wirklich mit Leuten auseinanderzusetzen, die dort schon einige Schritte gegangen sind und spezialisierte sind als generische AI-Agenturen. Es gibt da tatsächlich schon ein paar Angebote, Online-Workshops, Masterclasses, Workshops,

[00:33:25] ich selbst mache sowas in die Richtung tatsächlich, aber ich sehe auch, dass Unternehmen, andere Unternehmen sagen, das machst du alleine, du baust dir jetzt selbst die Skills auf. und dann ist es manchmal schwierig zu sagen oder zu erklären, warum, was ist der Unterschied, wenn man jemanden sich nimmt, der da schon viel mehr Zeit investiert hat, wenn der AI so viel selbst macht. Und auch die andere Früge, ja, man kann es einkaufen, man kann es verbessern und besser machen, man kann sich da Unterstützung holen.

[00:33:55] Ja, und ich hatte noch, was hattest du noch gefragt? Ich hatte zumindest noch irgendeinen Gedanken, den ich jetzt versuche, versuchte festzuhalten. Wir haben von dir viel Antwort bekommen an der Frage. Ich möchte an dem Punkt darauf eingehen, ich glaube gehört zu haben, dass es nach dieser Sendung, wenn du in diesem Bereich sinnvoll unterwegs bist, es klar geworden ist, dass es wahrscheinlich in Zukunft

[00:34:24] schwierig ist, in der Zeit zu bleiben, wenn du nicht AI Rapid Prototyping bei dir etablierst. Konkrete Antworten, Fragen, Tools, die man so einfach irgendwo kaufen kann und bei dir reinstecken kann, ist im Moment schwierig, weil das ist wahrscheinlich gegen die Natur der Sache. Aber was wir gehört haben, ist die Empfehlung vom Jens, dass man das peu à peu als Wissen aufbauen sollte. Wenn es schnell gehen kann oder muss, kannst du versuchen, das extern einzukaufen mit Unterstützung.

[00:34:54] Aber wahrscheinlich geht es darum, das Wissen im Unternehmen aufzubauen und ich würde gerne ergänzen an der Stelle, dass es wichtig ist, dass du das die richtigen Leute draufsetzt, nämlich die, die von sich aus laufen und du dir sehr genau anguckst, wem du Zeit und Budget gibst, sich dazu aufzuschlauen, dass es nicht die B- und C-Mitarbeiter sind, sondern dass du guckst, dass du einen A-Mitarbeiter intern findest, der wirklich Bock drauf hat, das macht, weil dann wird es sehr viel einfacher. Ja, jetzt habe ich sogar meinen Gedanken

[00:35:23] nochmal kurz wiedergefunden. Er geht auch ganz schnell. Tipptopp. Gestern erst im Gespräch gehabt in Unternehmen, wir haben darüber gesprochen, wie eine Kooperation sein könnte und dann sagen die mir, ja, vor drei, vier Monaten wurde ihnen gesagt, man braucht keine Designer mehr, wir haben jetzt nur noch Designwerkstudenten und jetzt switchen sie sogar komplett um von einem Senior Designer, gehen sie suchen zu einem Design Lead, der ihnen hilft, diese Systeme so aufzubauen, dass die Software sich im Design praktisch schneller alleine baut mit den richtigen Leuten.

[00:35:53] Also das finde ich eine entscheidende, interessante Entwicklung, also Firmen, die schon, und die haben einen starken Buy-In in dieser Methodik, das Start-Up, dass die jetzt sogar den Schritt sogar machen und darüber nachdenken, nee, warte mal, das war eigentlich keine gute Idee, wir brauchen irgendjemanden, der uns das einfach mal richtig komplett aufsetzt, der schon das macht, selbst verstanden hat und da einen Design Lead übernimmt, um uns da zu helfen. Das fand ich, wow, also die Entwicklungen sind rasant, vor einem Jahr noch undenkbar, jetzt so klar formuliert. Ich war schon vor einem Jahr

[00:36:23] davon überzeugt, dass es dorthin kommen wird. Das war ein Hoffnungsschimmer für alle, die sich mit Design auseinandersetzen in der Softwarebranche. Ja, also ich glaube, was wir ganz zu Anfang auch an diesem Punkt noch gesagt hatten, war ja, es geht wahrscheinlich überhaupt nicht darum, einen Designer zu ersetzen, weil die AI ohne denjenigen, der davor sitzt, der Erfahrung hat und wo man hin will, ja eigentlich auch nichts produzieren kann. Es macht dich einfach nur besser und schneller, aber wichtig ist, dass du halt mit den Tools umgehen kannst.

[00:36:53] Können wir so stehen lassen? Absolut. In diesem Sinne, Jens, wir haben ein spannendes Thema gestreift. Wir haben keine konkrete Produktempfehlung gemacht. Kann man, glaube ich, im Moment auch schwer machen. Du, das könnte ich noch machen, aber man kann mich auch fragen. Aber ich habe wirklich überlegt, soll ich diesen Namen jetzt alle runterratteln? Das gibt ja eh nicht. Nein, macht an der Stelle wenig Sinn. Wichtig ist, dass du denkst und guckst, dass du dich selber befähigst, das Thema anzugehen, Wissen aufzubauen,

[00:37:23] weil es sowieso relativ individuell ist. Wir durften drauf gucken. Ich danke dir, Jens, für deinen Input. Herzlichen Dank. Gute Zeit. Bis bald. Vielen Dank auch dir, Holger. Tchau, Gott. Töchter, mit dem im empresasειuward zu