#130 Wie gutes UX-Design entsteht mit Robin Titus

Wie technisch sollten UI und UX-Engineers eigentlich sein?

Dass gutes Design und eine gute User Experience über den Erfolg oder Misserfolg eines Produktes entscheiden kann, haben Plattformen wie AirBnB oder Docker erfolgreich gezeigt. Denn irgendwie hat jedes Produkt, egal ob Hard- oder Software, eine Oberfläche und Bedienelemente. Deswegen steigen wir mit dieser Episode mal in die Felder User Interface (UI) und User Experience (UX) ein.

Wir klären, was es eigentlich ist und wo der Unterschied ist, wie UI und UX-Design eigentlich in einem hoch-technischen Produkt, wie zB einem Datenbank-Hoster, aussehen kann, welchen signifikanten Einfluss gutes UX haben kann, was Primary and Secondary Actions, die first mile of Product, Design Thinking oder Double Diamond ist, wie man eine gute Product Engineering Culture aufbaut, aber auch worauf es bei der Zusammenarbeit beim Produkt-Trio (Produkt Manager, Engineer und Designer) ankommt.

Bonus: Culture Eats Process for Breakfast

**** Diese Episode wird gesponsert von der IU Internationale Hochschule

Für dich ist Bildung wichtig und du glaubst an Technologie als Enabler? Kannst du dich mit der Mission der IU “Educate People with the Best Technology" identifizieren?

Dann schau doch mal unter https://engineeringkiosk.dev/iu, wenn du die Bildung von morgen gestalten willst.

****

**** WeAreDevelopers World Congress Gewinnspiel

WeAreDevelopers World Congress 17. bis 19. Juli 2024 in Berlin.

15.000+ Entwickler⋅innen und 500+ Speaker

Exklusiver Rabattcode für unsere Community: "WWC_EngineeringKiosk15" für 15% Rabatt.

Wir verlosen 5 Tickets! Mehr Infos unter https://www.linkedin.com/feed/update/urn:li:share:7211263176640729088/

****

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:14) Gewinnspiel We Are Developers Tickets

(00:01:38) UI und UX mit Robin Titus

(00:08:14) Die Bildung von morgen gestalten, als Dev bei der IU (Werbung)

(00:09:19) UI und UX mit Robin Titus

(00:18:44) Unterschied UX Design und UX Research

(00:21:55) UX in hochtechnischen Produkten und die First Mile

(00:28:32) Der Impact vom Backend auf die User Experience

(00:31:56) Das Produkt-Trio

(00:42:27) Produktkultur

(00:48:41) Wie technisch müssen Designer sein?

(00:54:25) Nicht jede Firma ist Apple oder Airbnb

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://www.buymeacoffee.com/engineeringkiosk
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:04 - 00:01:11)

UI und UX. Zwei Abkürzungen, die wir in den letzten 120 Episoden von diesem Podcast kaum genutzt haben. Und damit herzlich willkommen zu einer neuen Episode vom Engineering Kiosk, bei der es genau um diese zwei Abkürzungen User Interface und user experience. Wir haben uns die Frage wie technisch müssen eigentlich UI und UX Engineers sein? Denn zugegebenermaßen, nicht jede Firma ist Apple und setzt neue Design Standards. Nicht jede Firma hat eine BC Webseite wie Build DE oder Booking. Also wie Sieht UX und UI Design bei technischen Produkten eigentlich aus? Und um das zu beantworten, haben wir uns professionelle Hilfe geholt. Wir sprechen mit Robin Ditus, der Director of UX Design bei einem Database as a Service Provider ist und uns Dinge erklärt wie primary and secondary actions, was die first mile of product ist, was design thinking bringen soll, was ein double diamond ist und wie man eigentlich eine gute product engineering culture aufbaut. Und ganz nebenbei, was das Produkt Trio ist und wie man die Zusammenarbeit im Produkt Trio verbessert. Also steigen wir gleich ein in ein von technischer Seite oft unterschätztes Thema. UI und UX. Viel Spaß.

Andy Grunwald (00:01:13 - 00:01:48)

Das Feld der Softwareentwicklung und der tech Produkte ist relativ weit, weil IT ist ja nicht gleich IT und Softwareentwicklung ist ja nicht gleich Softwareentwicklung. Denn wir können die beste und tollste Software bauen, wenn man aber keine Oberfläche hat, dann kann man die einfach nicht bedienen. Und jetzt ist es natürlich so, Wolfgang und ich, wir sind jetzt auch nicht die Klügsten und von manchen Themen haben wir einfach gar keine Ahnung. Und ein heutiges Thema, was wir heute im Podcast haben, ist ein solches Thema, was zumindest für mich so eine Art böhmisches Dorf ist. Aber ich finde es relativ wichtig, weil.

Wolfi Gassler (00:02:12 - 00:02:14)

Ich denn ein böhmisches Dorf für Bürger.

Andy Grunwald (00:02:15 - 00:04:08)

Man sagt immer so böhmische Dörfer für mich so eine Umgangssprache. Kannst du mal später googeln oder auf Wikipedia nachgucken. Auf jeden Fall sprechen wir über User Interface und user experience. Und warum ist das relevant? Da geht es nicht nur um Farben und wir machen etwas schön, sondern auch in der Infrastrukturwelt hat das eine sehr, sehr hohe Relevanz. Nehmen wir uns mal einmal die Technologie Docker. Jeder denkt, Docker wäre eine tolle neue Technologie. Das ist aber jedoch eine kleine Lüge, denn die Technologie, auf der Docker basiert, ist schon super alt. 1980, 1985, 1900 neunzigste. Aber Docker hat sie erst bekannt gemacht, weil Docker es geschafft hat, eine einfache UI draufzusetzen. Eine andere Baustelle ist z.B. das Startup, nennt man das Startup noch? Weiß ich nicht, Firma Airbnb. Das Konzept von Airbnb ist eigentlich nicht neu. Ja, nannte sich zu deutsch immer Fewo direkt oder ich glaube, in kroatischen Dörfern gibt es immer noch irgendwelche zentralen Agencies, die dir dann Ferienwohnung vermieten. Der Punkt ist aber Airbnb ist so durch die Decke gegangen, weil das eine Design first oder eine Design driven Company ist. Und die haben die ganze Sache einfach schön gemacht, einfach, ich sag mal nett verkauft. Und aus diesen beiden Gründen ist UI und UX einfach ein so wichtiges Thema. Und wie gesagt, Wolfgang und ich haben davon keine Ahnung und deswegen haben wir uns einen Experten eingeladen, der dieser Einladung auch gefolgt ist. Hallo Robin, grüß euch. Mal ganz kurz für die Hörerinnen und Hörer. Wer ist Robin? Robin ist Director of UX Design bei demselben Arbeitgeber, bei dem ich arbeite, einem Database as a Service Provider, was Achtung, ein sehr technisches Produkt ist. Und das, da freue ich mich sehr drauf, wie UX und UI Design bei einem Datenbank Hoster aussieht. Robin wohnt, lebt und verbringt seine Freizeit auch in Wiesbaden, hat an der Zeit.

Wolfi Gassler (00:04:08 - 00:04:14)

Schon super war mit Grüß euch. Das kommt mir natürlich ganz gelegen. Das klingt für mich schon ganz vertraut.

Robin Titus (00:04:14 - 00:04:20)

Ja, das grüß euch, das kommt daher, weil ich aus München ursprünglich bin. Von daher ja.

Andy Grunwald (00:04:21 - 00:04:23)

Kurze Frage aus Bayern oder aus Franken?

Wolfi Gassler (00:04:24 - 00:04:25)

Aus Bayern, München.

Andy Grunwald (00:04:25 - 00:05:04)

Logisch ist der dritte Start da unten. Im Thema UI, UX bzw. Production bzw. Design warst du schon immer mal irgendwie ein bisschen tätig. Und zwar hast du an der TU München studiert, schon ein paar Jährchen her, 1990 bis 1996. Das bedeutet, du bist jetzt gerade 23 geworden. Ist das richtig, Robin? Und ab und zu stehst du auf der Bühne und du hast vor kurzem einen Vortrag an der Hochschule Mannheim gehalten zu einem Thema, da schmilzt mir so ein bisschen das Herz. Und zwar hieß der Talk Culture eats process for breakfast. Wieso hast du diesen Talk gewählt und wieso hast du dieses Wissen an Studenten weitergegeben?

Robin Titus (00:05:04 - 00:06:11)

Ja, ja, das war genau letzte Woche an der an der Hochschule Mannheim. Ich habe das Thema gewählt, weil mir das ja das Thema Produktkultur einfach extrem wichtig ist. Also alle haben vom Thema agile Entwicklung gehört. Agil ist überall. Das ist agile Manifesto. Wurde über die letzten Jahre versucht, über alles, über alles drüber zu schütten. Jeder wird agil, sogar unsere HR Abteilung ist jetzt agil. Ich habe aber auch so sage ich immer so die ganze Entwicklung von von den agilen Prozessen mitgemacht und habe einfach gesehen, dass es irgendwann in die komplett falsche Richtung gekippt ist und dass Prozesse, die sich agil genannt haben, im Endeffekt wieder die überhand bekommen haben. Und alle schauen immer nur auf die Prozesse. Prozesse sind etwas, das kann ich, kann ich, da kann ich, kann ich messen, da habe ich Metricen und so weiter. Der Kulturaspekt, der eigentlich mit dem agilen Manifesto, das Mindset, das eigentlich super ist, das ist eigentlich immer mehr in wieder in den Hintergrund getreten. Das war so ein bisschen der Kontext, warum ich diesen diesen Talk gemacht habe.

Wolfi Gassler (00:06:11 - 00:06:50)

Jetzt habe ich in der Zwischenzeit natürlich nachgeschaut. Andi, für dich was, warum böhmisches Dorf? Und sollte das natürlich kennen, weil es kommt scheinbar aus der habsburger Zeit, weil man die Leute halt dort einfach nicht verstanden hat, weil die böhmisch gesprochen haben. Das ist der ganze Hintergrund. Also UX und UI ist auch für mich ein böhmisches Dorf. Demnach eindeutig drum umso besser, dass Robin hier ist. Und ich würde mal mit einer sehr ketzerischen Frage starten, weil für mich als oder von der developer Seite, für mich ist ja Ux einfach nur intuitive Bedienung. Habe ich jetzt eigentlich da nicht schon alles geklärt, wenn es um UX geht?

Robin Titus (00:06:51 - 00:08:13)

Nein, das hast du leider nicht. User experience Design ist viel, viel breiter. Es ist es ist immer diese, wenn du, wenn du ein bisschen googlest, was ist UX Design? Dann stößt du sehr oft auf diese auf die Aussage UI is not UX. UI Design, User Interface Design ist ein Teil von UX Design, ein sehr wichtiger Teil natürlich und der Teil, den am Schluss im Endeffekt jeder sieht. Da geht es um den Look, Look and feel, das Interface. Es geht darum, dass es intuitiv zu bedienen ist. Also wie funktioniert dieser Look and Feel? Aber im Endeffekt ist es das Ergebnis von einem Solution Design. Also das heißt, wie ist die Lösung überhaupt Design und wie sind wir überhaupt zu diesem Lösungsdesign gekommen? UX Design beschäftigt sich damit, wie ich dem Nutzer die bestmögliche Lösung zu einem Problem bereitstelle. Und da gibt es eine verschiedenste Methoden, die, die wir benutzen im UX Design. Eine sehr prominente Methode ist z.B. das ganze Thema Research Interviews, einfach den das Problem und den User verstehen, klar einzugrenzen, welches Problem gelöst werden soll und dann eine Lösung dafür zu entwickeln.

Wolfi Gassler (00:08:13 - 00:08:27)

Wenn du Solution Design sagst, dann verstehst du da jetzt darunter die Lösung an sich auch? Also ist es dann ein reiner Design Aspekt oder studiert das eigentlich auch den Weg und was man vielleicht macht dann?

Robin Titus (00:09:32 - 00:11:46)

Und da steckt natürlich auch der technische Aspekt drin. Also das ist immer ein kollaborativer Prozess. Oder sollte immer ein kollaborativer Prozess sein. Das heißt Produktmanager, Designer und Entwickler sollten immer zusammen am Solution Design arbeiten. Und dann am Schluss wird natürlich der Designer das Interface dafür bereitstellen, der Entwickler wird die technische Lösung dafür bereitstellen. Aber sie haben gemeinsam diese Lösung entwickelt mit dem Fokus ein Problem zu lösen. Es gibt verschiedenste Methoden, die wir einsetzen, z.B. um das Problem einzugrenzen. Das nennt sich dann Problem Framing ist da so der Oberbegriff und da da tragen wieder verschiedene Dinge dazu bei. Also ich muss verstehen, wer hat das Problem? Das heißt, ich muss ich muss den User verstehen, Interviews führen, den User einfach beobachten. Was macht der User heute? Welche Alternativen nutzt er, um dieses Problem zu lösen? In welchem Kontext tritt ein Problem, das wir hier lösen wollen, überhaupt auf? Wie oft tritt das Problem auf? Wie intensiv ist das Problem? Also wie wichtig ist es denn, dieses Problem auch zu lösen? Weil am Schluss wollen wir irgendeinen Wert herstellen für den Nutzer. Die technische Lösung muss einen Wert generieren und wie können wir das am besten transportieren? Da ist natürlich die technische Lösung das Fundament dafür. Aber wie mache ich es dann so intuitiv und wie supporte ich diesen ganzen Prozess mit allem, was außen herum ist auch? Also nicht nur die Lösung an sich, sondern auch der Support z.B. den ich dazu anbiete. Wie spreche ich mit dem Nutzer? Wie ist die Kommunikation hier geregelt auf der Support Seite? Wie ist es dokumentiert? Das gehört alles im Endeffekt zur Experience, die der Nutzer dann mit dem Produkt hat oder mit dem Service hat. Gehört alles dazu. Und im Idealfall schaut man auf all diese Themen und eben nicht nur auf okay, wir bauen hier dieses Feature und das ist das Interface dazu und so ist es zu bedienen, sondern auch um all diese Aspekte aussenrum und das macht dann eine gute Experience aus.

Wolfi Gassler (00:11:46 - 00:12:07)

Das klingt danach, wenn ich jetzt in an kleine Startup denke, wo jetzt keinen dedizierten UX Researcher habe, sind alles Themen, die dann aber auch von Entwicklerinnen oder von anderen Leuten Product was auch immer übernommen werden müssen. Also ich habe das inhärent eigentlich immer in der Produktentwicklung mit drinnen. Einmal wahrscheinlich schlechter und einmal besser.

Robin Titus (00:12:07 - 00:14:07)

Absolut. Also bei Startups ist es eigentlich so, dass das schöne an Startups ist, dadurch, dass die Teams so klein sind am Anfang und jeder alles irgendwie macht und weiß und und auch oft ganz klar, dass das Ziel vor Augen hat, welches Problem hier gelöst werden soll, passieren diese Dinge relativ auf eine natürliche Art. Die sind überhaupt nicht, also die sind nicht organisiert da brauche ich keinen Prozess dafür, da brauche ich nicht irgendwie einen eigenständigen Research Team, um sowas zu machen. Der CEO spricht mit den ersten Nutzern und hat im Endeffekt dieses Insight Entwickler werden mit in den Prozess reingeholt und sprechen mit Nutzern. Und Startups haben dieses Problem oft nicht. Also es gibt natürlich das dann auch wieder schlechter machen, aber in der Regel sind Startups sehr gut darin. Also ich habe selber ein Startup gehabt und habe auch da den ganzen Prozess durchlaufen. Das Schöne war damals, ich habe am Anfang, als wir angefangen haben, ein Produkt zu entwickeln, habe ich auch dann den den Customer Support übernommen. Also ich habe Custom Support und Product gemacht und dadurch hatte ich im Endeffekt, ich hatte täglichen Kontakt zu unseren ersten Nutzern und im Endeffekt all das, was wir dort gelernt haben, ist dann auch in unsere Entwicklung dann eingeflossen oder in das Produkt eingeflossen. Ja, es war eigentlich ein sehr, sehr guter Prozess und es war null geregelt. Also wir haben, ich war mir dessen gar nicht so bewusst. Das ist eigentlich erst so im Nachhinein, wenn ich so zurückschaue, was haben wir da eigentlich gemacht und warum waren wir, wir waren auch sehr erfolgreich mit dem Produkt auf dem Markt. Wie haben wir das denn eigentlich geschafft? Weil wir hatten alle, also wir waren vier Gründer damals und wir hatten alle keine Ahnung von von Unternehmensgründung oder wie man ein Produkt in den Markt einführt. Aber es hat sehr, sehr gut funktioniert. Und ich glaube, es hat ja, es hat einfach dadurch gut funktioniert, wenn wir eine extreme Nähe zum zum Nutzer hatten.

Andy Grunwald (00:14:07 - 00:15:55)

Wenn ich, wenn ich mir dich so anhöre, dann kommt bei mir gerade so ein negatives Bild auf, weil du hast gerade die Komplexität von UI und UX beschrieben, wie viele Aktivitäten da drin sind und so Buzzword oder Stellenbeschreibung wie UX Designer, UX Researcher, Product Designer, User Researcher, Usability Analyst, hast du noch einen Frontend Developer und dann gibt es da noch Design Thinking und so weiter. Und du hast auch gerade schon von User Research Team gesprochen und dann das andere extrem aufgemalt, dass in Startups die Leute das alles irgendwie ganz naturell machen und diese ganzen Fachwörter vielleicht auch gar nicht kennen, weil sie wollen einfach nur ein tolles Produkt schaffen. Da frage ich mich, ist das nicht ein riesen Wasserkopf? Weil ich meine, klar, es ist ein Experte, Expertenfeld für sich allein, aber User research, ich stelle mir das so vor und zugegeben, wir hatten bei Trivago damals auch einen User Research Lab. Das bedeutet, es war ein eigener Raum, da war ein Computer drin mit Mikrofon, mit Kamera und so ähnlich wie so beim FBI, wo man auch durch so eine Glasscheibe gucken konnte. Und dann wurde das wirklich aufgenommen und dem der Benutzerin und der Benutzer wirklich über die Schulter geguckt. Das wird gefilmt und so. Wie wird das Produkt benutzt? Und dann kannst du bitte dein Gedankengang laut sprechen und so weiter, um wirklich zu verstehen, ob die Filter jetzt bei einer Hotelsuchmaschine, die ja sehr komplex sind, reise ich mit Hunden, reise ich mit drei Familien und so weiter. Also ist ja alles brauche ich ein Einzelzimmer, ein Gruppenzimmer, bin ich auf einem Business Trip und so weiter. Ja, ganz andere Anforderungen, als wenn ich mit der Familie zum Strand war. Und da frage ich mich kann jede Firma diesen Wasserkopf überhaupt stemmen, dieses Wissen überhaupt aufbauen? Oder macht es da nicht wirklich Sinn, sowas einfach an Experten auszusourcen? Oder vielleicht einfach versuchen, das kleine Startup innerhalb des Konzerns zu bauen und die Leute gar nicht wissen lassen, dass es diese Fachbegriffe alles gibt, dass die es alles naturell machen.

Robin Titus (00:15:56 - 00:16:08)

Ja, also ich meine, sagen wir so, diese ganzen Rollen oder Positionen, die da entstanden sind, das ist natürlich alles so ein bisschen geprägt von den von den ganz großen Startups. Also wenn wir überhaupt sind keine Startups mehr.

Wolfi Gassler (00:16:08 - 00:16:12)

Also Facebook, die ehemaligen Startups. Die ehemaligen Startups, die erfolgreichen Startups.

Robin Titus (00:16:12 - 00:18:09)

Exakt. Also natürlich kann eine, eine Google, eine Facebook, ein Airbnb, können die sich leisten, diese Departments zu betreiben, die dann wirklich nur ja, okay, wir sind nur für Research da. Wir sprechen nur mit Nutzern. Wir machen diese, benutzen all diese fancy Setups mit Kameras und was weiß ich, Eye Tracking und die wildesten Dinge, die da unterwegs sind. Man muss immer das machen, was, was zur Größe des Unternehmens passt. Bei unserem momentanen Arbeitgeber. Wir heißen alle Product Designer und wir, wir machen, wir machen auch nicht all das, was man machen könnte, aber wir machen das, was ich sag mal so, was auch finanziell vertretbar ist für die Größe des Unternehmens und für die für die Größe der Produktabteilung, was man so liest, wie so ideale Setups sind. Das ist auch immer ein bisschen misleading aus meiner, aus meiner Sicht. Ein guter Produktdesigner oder UX Designer ist, sollte in der Lage sein, die wichtigen Dinge zu tun, um die Entwicklung der Lösung zu unterstützen. Und natürlich sollten, wenn es ein kleines Team ist, gibt es da Dinge, die auch Entwickler machen können, die der Produktmanager übernimmt. Was der UX Designer in dem Fall leisten kann, ist im Endeffekt einfach das ganze vielleicht ein bisschen zu steuern, zu fazilitieren. Hier sind Methoden, so macht man das. Das sind gute Fragen, die man in einem Interview mit einem User stellt. Einfach im Endeffekt die, ich sag mal so, wir kennen halt die ganzen Tool Sets, die es gibt und ich glaube so ein bisschen unsere in unserer Verantwortung ist ein bisschen auszuwählen, was sind, was macht in dem Fall am meisten Sinn, was können wir uns leisten? Und dann können wir das entweder selber machen oder eben anderen helfen, das zu tun.

Wolfi Gassler (00:18:10 - 00:18:44)

Jetzt hast du schon gesagt, es können mehrere Personen übernehmen, diese ganzen Tätigkeiten und die vielen Job Descriptions, die es so gibt. Gibt es da überhaupt Unterschiede oder kann du uns das mal aufdröseln, was jetzt ein UX Designer macht, ein UX Researcher und Product Designer? Gibt es da überhaupt einen Unterschied? Weil in der Tech Welt gibt es ja auch DevOps und SRI und es hassen mich jetzt vielleicht viele Leute, aber im Endeffekt ist eh alles dasselbe und der Andy lacht schon, aber gibt es da Unterschiede oder gibt es da so Strömungen oder zumindest große Unterschiede von Tätigkeitsbereichen?

Robin Titus (00:18:44 - 00:21:17)

Ja, also UX Design und UX Research ist tatsächlich etwas, das kann man relativ klar differenzieren. Es sind auch andere Backgrounds oder die die Leute haben, die mitbringen. Also im Bereich UX Research findet man oft sehr, sehr viele Leute, die aus dem Bereich Psychologie kommen oder auch ganz verschiedensten Bereichen. Die kommen nicht unbedingt, es sind keine Designer im Sinne von okay, ich kann auch Visual Design, die bringen einfach andere Qualitäten mit, die sind sehr gut in Kommunikation, die sprechen gerne mit mit fremden Leuten, was auch nicht, sage ich mal so ist, je nachdem was man für ein Typ ist. Ihr kennt das wahrscheinlich, es gibt halt introvertierte und extrovertierte Entwickler und manche sind total begeistert davon an irgendwelchen Kunden calls und User Calls teilzunehmen und für andere ist es allerschlimmste, was überhaupt passieren kann. Und das ist hier, ich sag mal so, das ist da genauso bei UX Designer, die kann man auch noch mal so in zwei Gruppen ein bisschen unterteilen. Da gibt es mehr die die wirklich gerne im, ich sage es immer so, es gibt so zwei Räume, in denen wir arbeiten. Wenn ihr, wenn ihr mal googeln wollt, da gibt es den Double diamond. Das ist so der Prozess, der immer ist kein Prozess, im Endeffekt ein Framework oder einfach ein Schaubild, das im Endeffekt den die Entwicklung eines Produktes aufteilt in zwei Räume. Es gibt den Problemraum und es gibt den Lösungsraum. Es gibt UX Designer, die sich sehr gerne in diesem Problemraum aufhalten und da eben sehr gut sind in den Methoden, die dort verwendet werden, um das Problem und den also das Problem klar zu definieren, den User klar zu verstehen. Da spielt Research als so eine unterstützende Rolle mit rein. Und dann in dem Lösungsraum, da geht es dann eher an, da brauche ich dann eher auch die visuellen Design skills. Also da wird dann sehr viel experimentiert mit Prototypen. Da geht es dann darum, okay, kann ich sehr schnell einen Prototypen herstellen? Wie mache ich das? Und dann eben am Schluss auch das high fidelity Design. Also das ist das, was dann im Endeffekt implementiert wird. Das sind dann meistens manchmal, manchmal sind das auch dann Leute, die eigentlich lieber UI Designer genannt werden möchten, weil die eigentlich mit dem, die arbeiten gerne in Figma oder in den Tools, in denen das dann eben umgesetzt wird. Ja, das sind so ein bisschen die, wie sich das ganze so aufteilt.

Wolfi Gassler (00:21:17 - 00:21:22)

Also das wäre dann der Schritt von Wireframes auf high fidelity.

Robin Titus (00:21:22 - 00:21:27)

Genau, das ist so, das findet in diesem Lösungsraum dann statt.

Andy Grunwald (00:21:27 - 00:21:51)

Jetzt hatte ich in der Intro schon Airbnb erwähnt. Airbnb, das Businessmodell war nicht neu, als Airbnb auf den Markt kam. Für uns Europäer war das Fewo direkt oder ähnliches. Ja gut, vielleicht war das oder Couchsurfing, irgendwie so ein Mix. Auf jeden Fall ist aus meiner Sicht Airbnb so erfolgreich, weil das so eine Design First company ist. Ja, die, die packen da. Ich glaube, die, ich glaube, das Ziel Level hat auch sehr viel mit Design zu tun.

Robin Titus (00:21:51 - 00:21:55)

Also der Gründer ist Designer, wieder was gelernt.

Andy Grunwald (00:21:55 - 00:22:31)

Und jetzt arbeiten wir beide ja für ein hochtechnisches Produkt mit der Zielgruppe für Softwareentwickler, Systemadministratoren und so weiter und so fort. Nämlich wir hosten Datenbanken, damit wir unsere Miete zahlen können. Und jetzt stelle ich mir natürlich die Frage bei Produkten, die für Entwickler oder backend lastigere Leute da sind, wie beeinflusst das deine Arbeit im UI UX Design? Ich meine, offen gesprochen, du hast ja im Endeffekt jetzt keine Webseite mit Bildern und also, weil du hast in der Regel jemanden, der technisch mit einem anderen Computer spricht, um eine Datenbank hochzufahren und Co.

Robin Titus (00:22:31 - 00:24:46)

Genau. Der Nutzer kommt zu uns, um genau mit diesem Ziel genau das zu tun. Aber wie bringen wir ihn dorthin? Und das ist, ich sage mal so, genau, da geht es um, wie ist die Experience für den Nutzer, bis er dorthin kommt? Wie einfach machen wir ihm das? Wie unterstützen wir ihn dabei? Wie kommunizieren wir mit ihm? Wie schnell kann er starten? Kann er Dinge ausprobieren, bevor er sie dann in seinem Live Environment oder in seiner Umgebung nutzt? Also was z.B. bei in unserem Bereich ganz wichtig ist, ist das Onboarding. Wir nennen das, also gibt es auch so einen Begriff dafür, the first mile, also die erste Mi, das geht auf der Webseite los oder wie wird der angesprochen? Das kann, da kann man schon irgendwelchen Konferenzen, wo jemand von uns, ein Entwickler von uns einen Talk hat zu einem bestimmten Thema. Wie wie leiten wir ihn von dort sozusagen in das Produkt und wie schnell kann er dann im Endeffekt, wie schnell kann er starten? Wie einfach machen wir es ihm? Was geben wir ihm für einen Support an die Hand, dass er, dass er versteht, was er hier machen kann? Gerade in so einem technischen Bereich ist es ja oft so, dass es unendlich viele Möglichkeiten gibt, die hier gemacht werden können. Also gerade im Bereich Datenbanken. Wir wissen nicht genau, was er machen möchte mit dieser Datenbank, weil im Endeffekt jeder, der eine Applikation baut, kann z.b. unseren Service nutzen und wir können ihm auch nicht im ersten Schritt vielleicht alles sagen, was hier möglich ist, weil es vielleicht tausend Möglichkeiten sind, aber auszufinden, was sind denn die Dinge, die ein Nutzer, die für den ersten Nutzer, der das erste Mal sozusagen unsere Applikation nutzt, was möchte der wissen? Was was ist relevant genau in diesem Schritt und wie schnell bringe ich ihn im Endeffekt dann dahin, dass er arbeiten kann und dass er dann vielleicht ja das Interface gar nicht mehr nutzt, aber dann mit APIs agiert und oder mit mit anderen Tools, Terraform oder anderen anderen Tools, mit denen er eben, die in seinem Ökosystem wichtig sind. Und das kann man natürlich, das kann man auch unterstützen.

Andy Grunwald (00:24:46 - 00:24:52)

Gesehen sprechen wir da unter anderem von so Elementen wie ich registriere mich und dann kommt erst mal so eine Tour.

Robin Titus (00:24:53 - 00:25:10)

Durchs Produkt oder das könnte eine Möglichkeit sein. Es kann aber auch einfach sein. Okay, z.B. was wir z.B. herausgefunden haben, ist das so, dass viele Entwickler diese Touren nicht machen, sondern einfach im Endeffekt am liebsten reingehen und ausprobieren.

Andy Grunwald (00:25:10 - 00:25:11)

Kann ich bestätigen.

Robin Titus (00:25:12 - 00:26:17)

Jetzt haben wir z.B. aber auch Nutzer interviewt, die schon Applikationen mit unserer Plattform gebaut haben, haben rausgefunden, dass die Dinge, die wir denken, die klar sind, z.b. dass ich auch alles mit, was weiß ich, dass wir Terraform unterstützen, war denen nicht bewusst, weil wir in unserem Interface einfach nicht klar darauf hinweisen. Das sind oft so einfache Sachen. Natürlich haben wir das irgendwo in unserer Dokumentation haben wir eine volle Dokumentation. Wie arbeite ich mit Terraform? Aber für jemanden, der einfach nur in das Tool reingeht und ausprobiert und dann anfängt zu bauen und im Endeffekt einfach auch die Dokumentation nur dann liest, wenn er irgendwie ein Problem hat, dem ist überhaupt nicht bewusst, was er alles machen kann. Das sind das sind Dinge, die kann man eben über über ein user experience Design steuern und zu schauen okay, wie kann ich die all die guten Dinge, die wir hier tun, wie kann ich die sozusagen ans Tageslicht bringen, den Nutzer überhaupt darauf aufmerksam machen?

Wolfi Gassler (00:26:17 - 00:26:56)

Jetzt, wenn ihr das so hört, es klingt ja teilweise so für mich so, das sind dann die, wenn man an die 80 20 % Regel denkt, das sind dann so eher die, die 20 %, sage ich jetzt mal einfach so provokant. Wie würdest denn du einschätzen, wie wichtig das ganz allgemein ist für für ein Produkt und für den Erfolg von einem Produkt? Ich weiß, es ist schwierig, da irgendwie eine Metrik zu finden oder sowas, aber wie wichtig empfindest du das für ein Produkt, ob ein Produkt angenommen wird, erfolgreich ist und wie sehr bewegen wir uns da in der Optimierung von den letzten 20 % oder bewegen wir uns da deiner Meinung nach in den 80?

Robin Titus (00:26:56 - 00:28:14)

%? Aus meiner Sicht bewegen wir uns da immer noch in den 80 %. In den 20 %, da sehe ich eher, eher dann, man kann immer Dinge, die die schon funktionieren, noch versuchen, noch besser zu machen, noch schöner zu machen, das noch vielleicht noch irgendwie mit toller zu illustrieren, den am Look and feel zu arbeiten. Und so weiter. Also wenn wir, wenn man am Look and Feel arbeitet, dann ist man in den 20 %. Ja, in den 80 %. Da geht es darum, die Kernfunktionalitäten des Produkts wirklich visibel und nutzbar zu machen. Z.B. ich setze eine Datenbank auf und möchte diese Datenbank jetzt integrieren. Das sind Dinge, die funktionieren alle, auch jetzt in unserem Produkt. Aber das ist z.B. ein Prozess, der das einfach, da sehen wir einfach, da passieren, da passieren einfach noch sehr viel. Da passieren Fehler, da passieren, da sind sehr viele Nachfragen. Diese Experience können wir einfach besser machen, weil dadurch entsteht Vertrauen zu dem Produkt und dann, dann kaufen die Leute auch das Produkt oder investieren mehr in das Produkt. Es geht, es geht wirklich darum, es geht darum, Vertrauen aufzubauen. Und das mache ich, das mache ich nicht mit dem Look in Feed. Das ist dann eher so, dass wenn wir uns nur noch darum kümmern, dann sind wir aus meiner Sicht auch auf dem falschen Pfad.

Andy Grunwald (00:28:14 - 00:28:32)

Wenn ich dir jetzt so zuhöre, dann ist es ja so, du möchtest dem Benutzer oder der Benutzerin eigentlich nahebringen, was man hier alles machen kann. Und oft sind ja Produkte sehr komplex. Sehe ich das richtig, dass es eigentlich darum geht, herauszufinden, welche Informationen man eigentlich weglassen kann? Also die Kunst des Weglassens sozusagen.

Robin Titus (00:28:32 - 00:29:54)

Genau, das ist extrem wichtig. Idealerweise sollte man für ein user Interface keine Dokumentation brauchen. Es sollte so einfach wie möglich sein. Es sollte klar sein, was kann ich hier tun und was ist das nächste, was ich hier tun kann? Was sind was. Also es ist dann immer so, wir sprechen dann immer so primary secondary actions, also z.b. wenn auf eine, wenn ich eine Seite öffne und ich habe drei oder vier oder fünf primary actions, das sind, um primary action zu definieren, das sind im Endeffekt z.B. buttons, die jetzt in einer bestimmten Farbe rausgehoben sind. Also was ich habe hier einen grünen Button, so und wenn ich aber jetzt fünf davon habe, dann führe ich den Nutzer nicht wirklich in eine gewisse Richtung. Das heißt, was ist die, das hat, das ist die eigentliche Sache, die ich hier tun kann. Das ist der primary action und was ist secondary? Und dann kann man sich überlegen, okay, und was von diesen secondary actions muss ich, soll sichtbar sein und was kann durchaus in einem Menü verborgen sein? Z.B. das wäre jetzt so ein ganz einfacher, einfaches Beispiel. Und ja, man sollte immer versuchen, ja möglichst viel wegzunehmen und damit eben auf die, auf die wirklich wichtigen Dinge der Fokus fällt.

Andy Grunwald (00:29:55 - 00:30:27)

Du hast gerade gesagt, wenn man sich ums look and Feel kümmert, dann ist man bei den 20 % und wir sprechen ja auch über user experience und du hast auch vorhin schon gesagt, okay, wenn eine Aktion zu lange dauert, das bedeutet, da denke ich in meinem Kopf als mehr backend orientierter Entwickler an Latenz. Also ich klicke auf einen Button und dann dauert das 1 Minute, bis irgendwas hochgefahren ist. Das bedeutet ja eigentlich auch, dass backend Entwickler einen viel größeren Impact auf die UX haben, als wir backend Entwickler eigentlich glauben, oder?

Robin Titus (00:30:28 - 00:31:50)

Darum sollte es ein kollaborativer Prozess sein, wenn man so eine Lösung entwickelt. Also wir entwickeln ein Feature und wir wissen, wir arbeiten zusammen und du sagst okay, wenn wir das, was weiß ich, eine neue Datenbank wird aufgesetzt und das wird jetzt auf jeden Fall so und so lange dauern. Das können wir versuchen zu optimieren, ist aber vielleicht sehr kostspielig, dann, wenn wir das, wenn der, wenn der UX Designer das weiß und darum ist es wichtig, dass man früh darüber spricht. Kann man natürlich etwas auch im Frontend, im Interface tun, um die Experience trotzdem gut zu machen, auch wenn es dauert. Also es ist nicht schlimm, wenn was dauert, wir müssen es nur wissen, weil dann können wir im Endeffekt diese Zeit nutzen, um z.B. den User darauf hinzuweisen, okay, die Datenbank wird gerade generiert, wusstest du, hier ist, hier ist der Code, den du in Terraform nutzen kannst, um dasselbe zu tun, um das Ganze zu automatisieren. Und hier sind vielleicht noch irgendwelche Artikel in unserer Dokumentation dazu. Also es war einfach nur so kann ich dann im Endeffekt diese Zeit nutzen, um trotzdem eine gute Experience für den Nutzer zu erzeugen und ihn nicht einfach auf ein, ja, auf ein sich ewig drehendes Rad schauen zu lassen. Irgendwie eine komische Zeitangabe, die eh nie steht.

Andy Grunwald (00:31:51 - 00:31:56)

Der gute alte Spinner und die Prozessberechnung bei Windows XP.

Wolfi Gassler (00:31:56 - 00:32:36)

Jetzt hast du schon erwähnt, beziehungsweise Andi hat jetzt auch die ganze Dev Seite noch mal ins Spiel gebracht. Engineering. Es gibt ja auch noch den Product Manager oder Product Owner, der auch in irgendeiner Weise verantwortlich ist oder der Product Designer ist, je nachdem, wie man das Ganze sieht. Und dann gibt es die ganzen Designer oder die UX Designer, wie auch immer. Wer ist denn dann für was verantwortlich in der Realität? Weil wenn man auch irgendwie sagt, okay, alle müssen auf alles achten, das funktioniert in der Realität auch nicht. Also wenn, wie ist denn da dein ideales Setup oder dein Bild, was du gerne sehen würdest, damit am Ende ein gutes Produkt rauskommt? Und wie ist da die Zusammenarbeit zwischen den?

Robin Titus (00:32:36 - 00:34:10)

Also ich sag mal so, das ideale Setup ist, wenn genau diese Personen, die du jetzt gerade beschrieben hast, diese Rollen tatsächlich in einem Team arbeiten, also sich als ein Team verstehen, in einem Team arbeiten. Das ist in vielen Organisationen nicht der Fall. Da ist das klar getrennt. Da ist zwar ein Produktmanager, der dann vielleicht für verschiedene Teams zuständig ist und da sind Designer, die dann auch wiederum für verschiedene Teams zuständig sind. Was wichtig ist, dass wenn eine neue Lösung entwickelt werden soll, dass selbst wenn sie nicht alle irgendwie jetzt fest in einem Team sitzen, ideal ist natürlich das startup Szenario, alle sitzen in einem Raum und dann läuft sowas, weil dann dann funktioniert einfach die Kommunikation. Das ist ein Kommunikationsding. Wenn das aber nicht der Fall ist, ist es wichtig, dass wenn eine neue Lösung entwickelt werden sollen, dass genau die drei Parteien zusammenkommen. Wir sprechen einmal von dem Produkt Trio Entwickler, Produktmanager und Designer kommt zusammen, wenn im Endeffekt, wenn das erste Problem beschrieben wird und kommen dann als virtuelles Team sozusagen, sind dann als virtuelles Team zusammen über die gesamte Laufzeit, bis das Ganze in den Händen vom Kunden ist und funktioniert und noch mal getestet wird und so weiter und so fort. Und das Feedback fließt idealerweise auch wieder direkt zurück und es wird auf das Feedback reagiert oder auf die die Dinge, die man gelernt hat aus der ersten Nutzung.

Wolfi Gassler (00:34:10 - 00:34:21)

Das heißt, wenn ich die richtig verstehe, dann willst du auch gar keine klassische Aufgabenverteilung, weil du sagst, jeder bringt seine Expertise ein von den Gruppen und dann entwickelt sich das schon irgendwie.

Robin Titus (00:34:21 - 00:35:14)

Natürlich haben die verschiedenen Rollen verschiedene Verantwortungen. Also z.B. der Produktmanager ist definitiv die Schnittschnelle zum Business und auch die Schnittstelle zum Produkt Marketing, das auch das ganze muss vermarktet werden muss. Vielleicht gibt es gewisse Aktivitäten, um das Ganze schon voranzukündigen, auf irgendwelchen Konferenzen oder mit irgend mit Press Releases und so weiter. Also da hat schon jeder seine seine speziellen Aufgaben. Aber es gibt diesen, ich sage mal so, aber sie überschneiden sich alle in der Entwicklung der Lösung und da müssen sie einfach zusammenarbeiten und es funktioniert auch. Aber das ist genau so ein, ich sag mal so ein kultureller Aspekt in guten Produktorganisationen ist. Wie stark wird auch das sozusagen durch das ganze Mindset, die Prinzipien, die Kultur, wie stark wird das gefördert? Das ist extrem wichtig.

Andy Grunwald (00:35:14 - 00:36:22)

Ich meine, das, was du gerade beschreibst mit Mindset. Ich stelle mir gerade so die Frage, wie funktioniert das denn in der Praxis? Weil denn die Firma muss ja eine sehr starke Produktkultur haben. Ich habe schon Leute in meiner Karriere getroffen, die sagen pass mal auf, mit dem ganzen Quatsch links und rechts möchte ich nichts zu tun haben. Ich möchte jetzt einfach hier meinen schönen Code schreiben. Ja, und lass mich bitte mit dem Rest in Ruhe. Aber das, was du ja beschreibst, da stelle ich mir gerade so eine kleine Revolution vor, wo jeder im Produktteam eine Flagge fürs eigene Produkt hochhält. Also die die Identifikation muss ja schon sehr stark sein, damit jeder sagt oh, okay, mir ist da jetzt was aufgefallen und ich gehe jetzt die extra mi. Ich bespreche das jetzt mit der Produktmanagerin und mit dem mit dem Designer durch, ob das Sinn macht oder ähnliches. Und das zeugt ja schon sehr von einem eher Senior Team, würde ich mal sagen. Leute, die nicht nur an ihre kleine Bubble denken, nicht nur an ihren Code, sondern wirklich okay, wir sehen jetzt ein Team, wir sind jetzt das Produkt Trio, hast du es genannt und wir ziehen es an einem Schrank und machen das wirklich in Erfolg. Also wirklich mit sehr viel Stolz und Identifikation fürs Produkt verbunden, oder?

Robin Titus (00:36:22 - 00:36:27)

Absolut, das ist perfekt zusammengefasst.

Wolfi Gassler (00:36:27 - 00:37:28)

Aber wenn wir jetzt mal in die Realität blicken und Andi hat ja da immer seine seine rosa Brille teilweise auf. In der Realität funktioniert es ja oft auch weniger gut, muss man ja ganz klar sagen, gerade wenn es so um Verantwortlichkeiten geht. Wir haben ja auch die Frage in unserer Community gestellt, ob es irgendwie Fragen gibt an dich und und ein Kommentar, was eher gekommen ist. Aber es passt gerade gerade sehr gut. Aber von Björn, dass der Product Owner eher das größere Problem in seiner Erfahrung öfter war, weil der halt genau irgendwas wollte und der Prozess muss genau so aussehen, aber dann von der UX Seite ist gekommen, ist aber Bullshit und es macht absolut keinen Sinn. Und wer hat dann recht? Also wie kommt man da sinnvoll auf einen grünen Zweig? Ist die UX Seite wichtiger? Ist die Product Seite wichtiger? Ganz oft gibt es da so Konflikte, weil die Product Seite einfach vielleicht irgendwie einen Kunden im Genickratar und der will irgendwas spezielles, aber es macht halt von der UX Seite wenig Sinn. Es gibt auf der technischen Seite natürlich genauso dieses Problem.

Robin Titus (00:37:28 - 00:39:24)

Also für mich ist sollte der Produktmanager sollte auf jeden Fall im Lead sein. Also der sollte die die Entscheidung treffen. Aber und da ist das genau das Problem. Also wahrscheinlich das, was da beschrieben wird, da passt wahrscheinlich. Da gibt es einfach verschiedene, verschiedene Mindsets, wie man an das ganze rangeht. Und anscheinend besteht in dem Fall einfach. Das klingt für mich so, dass das so ein bisschen silos sind, in denen die sitzen und da geschehen dann handovers. Ich habe mir jetzt hier mir eine Lösung ausgedacht, dass die gebe ich jetzt an den Designer, der soll das designen. Der Designer gibt es dann in den Entwickler, der soll es entwickeln. Ja, so passiert das in ganz vielen Unternehmen. Aber das ist eben, was extrem erfolgreiche Produkt Companies machen. Die arbeiten halt genau nicht so. Da geht es auch um die Zielsetzung. Also was wird überhaupt vom Leadership in das Team reingegeben? Da gibt es so das Beispiel von also Spotify ist ist einfach ein sehr, sehr prominentes Beispiel, die sehr, sehr gute engineering culture haben, Produktkultur, deren Teams sind, haben eine sehr, sehr hohe Autonomie. Und wenn ich sage Team, ist es jetzt nicht nur Entwickler, Entwicklungsteam, sondern eben dieses Produktteam, dieses Trio. Und die bekommen eine Zielsetzung und kriegen dann den Auftrag, an einer Lösung zu arbeiten, eine Lösung zu finden, bekommen die Lösung aber nicht vorgegeben. Im Fall von Spotify gibt es immer dieses ganz einfache Beispiel. Der Produktmanager sagt okay, wir müssen den unser Ziel ist, wir müssen den Fluss überqueren, baut eine Brücke. Es ist auf jeden Fall eine klare Zielsetzung, aber die Lösung wird bereits vorgegeben. Es muss eine Brücke sein. Es gibt verschiedene Arten im Fluss zu überqueren. Wir können Floß bauen, wir können eine Fähre bauen, wir können was weiß ich mit einem Paddleboard drüber.

Wolfi Gassler (00:39:25 - 00:39:26)

Es ist darüber fliegen.

Robin Titus (00:39:26 - 00:42:27)

Genau. Und im Endeffekt, wenn ich was, was ganz, was natürlich extrem wichtig ist, da ich muss einem Team vertrauen, dass sie eine eine gute, die best, die beste Lösung, die technisch möglich ist, die wir in der Zeit auch umsetzen können, weil es gibt vielleicht gibt es harte Deadlines, vielleicht ist es einfach nicht möglich, innerhalb von drei Monaten die Brücke zu bauen. Das heißt, wir brauchen Alternativen, um die Brücke zu bauen, um über den Fluss zu kommen. Und genau, genau darum geht es. Ich muss das, dass das fordert ein extrem hohen Level an Vertrauen. Und dieses Vertrauen, das ist glaube ich da, wo es am meisten hakt in ganz vielen Unternehmen. Es wird einfach nicht genügend vertraut und die Teams werden nicht so aufgesetzt, dass sie erfolgreich sein können. Weil ich sage mal so, wenn man gemeinsam eine Lösung entwickelt hat, die wirklich auch gut vom Markt und vom Kunden angenommen hat, es ist extrem gut für das Team. Es ist für den Entwickler genauso wie für den Designer und den Produktmanager, dass wenn das Ganze erfolgreich ist, das ist das, was motiviert. Spotify hat es wirklich geschafft, sehr, sehr gut umzusetzen. Das Lustige vielleicht noch ist, dass natürlich viele auf Spotify schauen und versuchen Spotify zu kopieren. Und das ist glaube ich ein anderes. Das war z.B. auch das Thema, als ich über culture eats process for breakfast, als ich über das Thema geredet habe, war genau das Beispiel. Okay, wir, wir nutzen auch den Spotify Prozess. Das ist schon mal allein das Wort, das Prozess zu nennen, ist schon mal falsch, was die meisten Unternehmen dann damit meinen. Ja, wir sind jetzt auch in Squads organisiert und wir haben jetzt auch Chapter und gilt und was auch immer. Ja, das ist so was, das ist, wie Spotify aufgesetzt ist. Aber wenn du dann fragst, wie sie die Zielsetzung für ihre Teams machen und wie autonom die Teams wirklich agieren können an der Lösung eines Problems, dann sieht das leider ganz anders aus und dann funktioniert das auch nicht. Es hilft mir nicht, wenn ich so organisiert bin auf meinem Org Chart wie Spotify. Spotify nutzt auch, arbeitet z.B. mit Scrum, aber die Teams, die können autonom entscheiden, ob sie das ändern. Also das ist einfach nur ein Framework. Das sind gewisse Leitplanken, die vorgegeben werden. Aber wenn sie anders arbeiten wollen, wenn sie das abwandeln, die müssen nicht genau nach den Scrum Ritualen arbeiten. Scrum ist eine sozusagen Okay, wir glauben an Scrum als agile Entwicklungsmethode, aber ihr könnt entscheiden, wie ihr das sozusagen, wie es für euch am besten funktioniert. Und das erfordert natürlich eine hohe. Ja, das erfordert viel Vertrauen. Und das ist genau das, was ich in einer guten Produktkultur funktioniert das. Ich sage nicht, dass es bei uns perfekt funktioniert. Wir versuchen ihn in die in die Richtung zu pushen. Und ja, so sehe ich das jetzt.

Wolfi Gassler (00:42:27 - 00:42:53)

Wenn du die ideale Produktkultur dadurch ansprichst. Es ist immer schwierig, die zu etablieren. Wen siehst du da in der Verantwortung? Ist es ein klassisches Leadership Thema, was von ganz oben kommen muss? Kann ich da im Team auch irgendwas bewirken? Also wie baue ich dieses Vertrauen auf? Bzw. Hast du irgendwelche Tipps, wie man zu so einer Kultur kommt? Weil wenn man mal dort ist, weiß man okay, man ist angekommen, die funktioniert gut, aber der Weg dorthin ist natürlich extrem schwierig.

Robin Titus (00:42:53 - 00:44:07)

Also natürlich, Andy, was du vorhin angesprochen hast, Airbnb, da kam es natürlich von oben, weil wir haben, wir haben im Endeffekt einen erfahrenen Designer als Gründer, der im Endeffekt genau dann auch diese Kultur etabliert hat, die das ermöglicht. Die Teams an sich können auf jeden Fall selber viel tun. Also es muss nicht immer von von oben runterkommen, sondern wenn aber dieses Trio muss zusammenkommen, wenn eine Rolle in diesem Trio Produktmanager, Designer und Entwickler, wenn die an diesem Prozess nicht teilnehmen und sagen nee, wir machen ja, wir machen, wir warten auf Input und produzieren dann Output, dann wird das Ganze nicht funktionieren. Also das heißt, man muss, man kann auf Team Ebene durchaus erfolgreich sein und auch meiner Meinung nach genau so arbeiten, wenn Produkt, wenn die drei zusammenkommen und sozusagen sich auf dieses auf dieses Mindset einigen. Okay, so wollen wir arbeiten. Es hilft nicht, wenn die Entwickler okay, das ist unser Entwicklungsprozess, dann die Designer sagen okay, das ist unser Designprozess und der Produktmanager sagt, das ist der Produktmanagement Prozess. Sie müssen zusammen einen Prozess definieren und sagen okay, so wollen wir arbeiten.

Andy Grunwald (00:44:08 - 00:44:48)

Das klingt so nach diesen klassischen Team Phasen wie Storming, Norming und so weiter und so fort. Also eigentlich, dass die Leute sich mal an den Tisch setzen und sagen hey, pass mal auf, im klassischen Designprozess läuft das so ab und dann sprechen die Softwareentwickler. Im klassischen Softwareentwicklungsprozess läuft das so ab und wo haben wir denn jetzt mal Gemeinsamkeiten? Aber nur mal um eine Sache klarzustellen. Wir reden immer über Produkt Trio. Hier reden wir nicht explizit dann über absolut drei Leute, sondern wirklich drei, ich sag mal Professionen. Und das bedeutet, weil in der Regel ist es ja so, dass in einem Softwareprodukt, einem Tech, man mehr Softwareentwicklerinnen pro Team hat als produktmanager z.B. also natürlich.

Robin Titus (00:44:48 - 00:45:34)

Ist das Entwicklungsteam normalerweise größer. Es sollte aber oft und es kommt ganz darauf an. Also es gibt oft implementieren auch ein Produktteam mehrere, mehrere Dinge gleichzeitig. Es können durchaus mehrere von diesen Trios parallel existieren. Es sollte immer einen Verantwortlichen geben. Wer ist verantwortlich von Produktmanagement für genau das was für genau diese Lösung? Wer ist verantwortlich von Design? Wer ist verantwortlich von der Entwicklung? Wer ist der Lead von den Entwicklern? Da sind mehr Leute involviert, aber einer sollte immer sozusagen die Schnittstelle sein zum Team. Es müssen nicht immer alle in allen Meetings sein, aber es sollten auf jeden Fall diese drei Rollen sollten immer in allen Meetings sein.

Wolfi Gassler (00:45:34 - 00:46:14)

Jetzt aus der Praxis gesprochen, was ganz oft ein Problem ist, wenn so Startups oder Firmen wachsen, irgendwann kommt man an die Position, wo man mal ein Team aufteilen muss, z.B. also wo man nicht mehr nur mal ein Team hat, sondern zwei Teams. Und da ist das erste Problem, man hat zwar wahrscheinlich mehrere Entwicklerinnen, aber nur einen Designer und jetzt hast du plötzlich einen Designer, aber zwei Teams und musst irgendwie einen Weg finden, wie der kann nicht mehr dedicate für für ein Team verantwortlich sein, sondern muss sich irgendwie teilen, was in der Realität oft ein Problem ist. Hast du da irgendwelche die perfekte Lösung aus einen zweiten einzustellen?

Robin Titus (00:46:14 - 00:46:39)

Also ein Senior Designer kann immer auf jeden Fall mit zwei Teams parallel zusammenarbeiten. Ab drei Teams sollte man sich dann überlegen, einen weiteren hinzuzuholen. Was du beschreibst, ist eigentlich fast überall der Fall, außer vielleicht wieder bei den ganz großen. In zwei Produktteams gleichzeitig zu agieren, sollte für einen Designer sowie auch für einen Produktmanager eigentlich kein Problem sein.

Wolfi Gassler (00:46:39 - 00:46:56)

Und mit gleichzeitig meinst du wirklich, wirklich gleichzeitig? Also nicht, dass man sagt okay, von einem Monat mache ich zwei Wochen in diesem Team und zwei Wochen in dem anderen Team, sondern wirklich jederzeit. Also tagtäglich beschäftige ich mich unter Umständen mit mit zwei Produkten und zwei Produktteams.

Robin Titus (00:46:57 - 00:47:41)

Also ich meine, natürlich muss man sich die Zeit dann muss man dann schauen, wie müssen dann die beiden Teams vielleicht schauen, wie sie bestimmte Meetings am besten legen und so weiter, damit das Ganze funktioniert. Natürlich ist es gut, wenn man, wenn man sich einfach seine Fokuszeiten so setzt, dass man okay, was weiß ich, heute kümmere ich mich jetzt speziell um das Thema für das Team. Aber das ist aus meiner Sicht alles möglich. Natürlich Idealfall wäre jeder, jeder hätte genau diese Funktionen an Bord und sind wir sind autonom, wir können im Endeffekt, wir können wie ein kleines Startup agieren, aber das ist in der Realität einfach nicht der Fall. Aber wie gesagt, für mich so die Regel wäre zwei Teams würde das absolut passen. Aber sobald es dann mehr wird, sollte man auf jeden Fall dann auch entsprechend.

Wolfi Gassler (00:47:41 - 00:47:56)

Mehr Ressourcen reinholen und dass eben alle in den Meetings jeweils vorhanden sind, die rollen zumindestens und dann dementsprechend die Meetings so legen, dass halt der Designer die Designerin immer immer entsprechend im Meeting sitzt.

Robin Titus (00:47:56 - 00:48:41)

Ja, im Endeffekt natürlich sagen wir so, wir haben jetzt auch z.B. die Teams haben bei uns haben auch ihre Daily Standups und so weiter. Natürlich bei den Standups ist es so, dass es, dass man vielleicht jetzt nicht bei jedem unbedingt dabei sein muss, aber es sollten halt alle im Team auch immer das Bewusstsein haben. Okay, was weiß ich? Heute diskutieren wir über ein Thema, wo es einfach wichtig ist, dass der Designer mit drin ist. Dann pingen wir ihn noch mal extra an. Er ist immer eingeladen, er kann jederzeit reinkommen, aber wir holen ihn aktiv rein, wenn es, wenn es um was Relevantes geht. Wir diskutieren das nicht dann in unserem Silo und sprechen dann erst später mit ihm. So würde ich das sehen.

Wolfi Gassler (00:48:41 - 00:49:29)

Wenn wir jetzt schon bei der Zusammenarbeit sind, noch eine Frage, die aus unserer Community kam und ich glaube, das ist ja so ein Dauerbrenner eigentlich. Da geht es um jede Position und für uns technische Leute ist es irgendwie immer besonders wichtig. Wie viel technischer Background sollte denn vorhanden sein? Ich glaube, die Frage gibt es bei Product Manager. Ist ein Product Manager mit technischen Background besser für Tech Teams als jemand ohne technischen Background? Und dieselbe Frage stellt sich wahrscheinlich auch bei bei Designern oder UXlern. Franky aus unserer Community hat eben hat da so ein Beispiel gebracht, der wollte mal irgendwie das DOM Modell in Browsern erklären und das war halt extrem schwierig, weil da sehr oder null technischer Background vielleicht vorhanden war. Hast du da eine starke Meinung dazu oder sagst du ist weniger wichtig?

Robin Titus (00:49:29 - 00:50:25)

Es ist auf jeden Fall gerade in ein technischerer Bereich ist, in dem Produkt entwickelt werden, ist es sehr, sehr hilfreich, wenn man einen technischen Background mitbringt. Wir haben ein paar Designer bei uns im Team, die das haben. Die waren zum Teil auch Entwickler und wir haben Designer, die sehr gut im UI Bereich sind, die sich auch extrem gut mit frontend auskennen, was auch extrem hilfreich ist. Wir investieren auf jeden Fall mehr Zeit jetzt in unserem Unternehmen, um Designer für das Onboarding der Designer, weil wir wollen, dass sie sich mit einem gewissen technischen Thema auch wirklich beschäftigen und dort auch Know how aufbauen. Also wir haben z.B. einer unserer Services ist apache Kafka, was durchaus komplexes Thema.

Wolfi Gassler (00:50:25 - 00:50:27)

Ist, würde ich auch mal so sagen.

Andy Grunwald (00:50:28 - 00:50:30)

Ganz klein, ganz klein.

Robin Titus (00:50:30 - 00:52:16)

Und natürlich muss ich versuchen, bis zu einem gewissen Level das zu verstehen. Und dafür also investieren wir, ich sag mal so auf jeden Fall mehr Zeit als als ich das jetzt ansetzen würde. Bei einem Unternehmen, das ein Business Consumer Product bereitstellt, ist einfach die die die Lernkurve ist bei uns definitiv länger. Also was ich sehr schön finde, ich habe ich habe ein bisschen technische Erfahrung, aber auch nicht dieser ganze Bereich war auch komplett neu für mich, als ich, als ich vor knapp drei Jahren dazugekommen bin. AI hilft mir täglich, wöchentlich, um einfach Themen zu verstehen. Also wenn du jetzt z.b. das Dom Beispiel sagt, ich würde ich würde jetzt würde ich einfach sagen okay, würde ich erstmal ChatGPT fragen. Okay, erklär mir Dom, erkläre Dom für einen Zwölfjährigen. So und es funktioniert also extrem gut, um schnellen Einstieg zu haben. Natürlich muss man dann tiefer gehen, aber genau diese Möglichkeiten helfen uns momentan. Also es ist fantastisch, um in gewisse Themen einzusteigen. Wir hatten z.B. vor einer gewissen Zeit hatten wir ein Feature gebaut, das nennt sich Tier Storage. Es ist ein Begriff oder ich hatte keine Ahnung, was es ist. Wirklich 10 Minuten später mit ChatGPT konnte ich mitreden. Ich glaube, da muss man einfach ja, wie gesagt, da geht es dann halt auch darum, wie wie proaktiv sind die Leute um sich, um sich einen gewissen Level an Wissen schnell drauf zu schaffen. Und dann halt natürlich muss man dann einsteigen und sich auch mal das zeigen lassen. Was was was ist denn das? Was macht ihr da? Was was passiert da genau? Ob es, ob es dann uns hilft beim Design ist dann die zweite Frage. Aber man muss in die Themen einsteigen.

Wolfi Gassler (00:52:16 - 00:52:42)

Ich glaube, es hilft alleine schon bei der bei der Kommunikation, weil wenn du die andere Seite einfach besser verstehst, ist es immer ein Vorteil. Und ich glaube, das geht in beide Richtungen natürlich. Also man kann ignorant sein und sagen das ist mein Spezialgebiet, mit dem anderen habe ich nichts zu tun. Aber wie du richtig sagst, wenn du ständig im Team arbeiten sollst und auch willst hoffentlich, dann bist du ja auch interessiert an der anderen Seite. Und das ist natürlich die ideale Besetzung dann würde ich mal sagen für für so eine Konstellation.

Andy Grunwald (00:52:43 - 00:54:25)

Mir geht gerade so ein bisschen das Herz auf, weil das, was der Robin da ja, das, was der Robin da so sagt, so nach dem Motto man muss die andere Person verstehen. Das ist ja auch so ein bisschen das Ziel unseres Podcasts, denn unser Credo ist ja, wir sind zwar ein deutschsprachiger Software Engineering Podcast, aber wir sagen Technologie ist kompliziert, aber gelöstes Problem. Was richtig hart ist, sind die Menschen, die zusammenarbeiten und dann zu verstehen okay, was macht die Person eigentlich links von mir und was ist eigentlich eine first mile, von dem die Person rechts von mir immer so spricht? Ich meine, das ist ja eigentlich genau das, wo du darauf abzielst nach dem Motto sprich doch mal einfach miteinander. Versucht doch mal zu verstehen, weil ob ihr wollt oder nicht, ihr seid beim selben Arbeitgeber und ob ihr wollt oder nicht, ihr seid in einem Team und ob ihr wollt oder nicht, ihr seid alle irgendwie verantwortlich, um einen tollen Outcome ein Ergebnis irgendwie auf die Straße zu bringen, dass dann irgendein Graph oben im Management nach oben geht. Und jetzt, jetzt kann man, jetzt kann man negatives Verhalten an den Tag legen und und motzig sein und sich zurücklehnen und die Arme verschränken, sagen Nee, ich bin hier nur in meinem Java Source Code unterwegs. Oder man kann halt sagen okay, ich frage mal ChatGPT, was ist denn die first mile? Und versuche halt einfach mal die Differenzen abzubauen zwischen den zwei Rollen oder zwischen den zwei Professionen. Versuche halt einfach zu verstehen. Aber das klingt jetzt alles so einfach. Wir sprechen darüber, aber ich glaube, ihr beide, du Robin und du, Wolfgang, ihr stimmt mir zu. Es ist nichts härteres als ich sag mal, Glaubensgrundsätze von Leuten zu brechen. Hört sich total negativ an, aber zu fordern und zu ändern, damit diese, ich sag mal Product Kultur, Designkultur und wir arbeiten alle zusammen, mal wirklich auf die Straße gebracht wird. Also ich meine deswegen, man sagt ja, man sagt ja nicht umsonst Kultur wird über Jahre erstellt und kann innerhalb von Minuten zerstört werden.

Wolfi Gassler (00:54:25 - 00:55:16)

Oder du brauchst natürlich auch die Offenheit einfach bei den Leuten und die richtigen Leute. Und da ist mir auch gerade eine Frage in den Sinn gekommen. Ihr habt ja jetzt beide oder ihr arbeitet beide in einem sehr backend lastigen Produkt, würde ich mal sagen. Wie schwierig ist es denn da überhaupt Designer und UX Leute zu bekommen? Also weil Leute gehen natürlich gerne zu Airbnb oder wo man die Webseite kennt, das Produkt selber benutzt und da die Oberfläche sieht. Jetzt denkt man beim Database as a Service was, was will ich denn da als Designer? Also bewerben sich überhaupt Leute und müsst ihr die irgendwie extrem überzeugen oder sind die schon, kommen die irgendwie aus einem technischen Background und sagen hey, das ist genau das, was sie machen will, weil ich bin ins Design gewechselt. Also welche Leute sprecht ihr denn da an? Ich stelle mir das persönlich extrem schwierig vor.

Robin Titus (00:55:16 - 00:55:21)

Das ist eine sehr gute Frage. Ist nicht sexy, was wir machen. Bitte.

Wolfi Gassler (00:55:22 - 00:55:27)

Zumindest für designer Ecke, für Softwareentwickler ist das Techporn.

Robin Titus (00:55:27 - 00:57:09)

Aber aber es ist nicht schwer. Es gibt genügend Leute, die genau diese Komplexität, mit der wir umgehen müssen, im Endeffekt lieben. Und also wir haben kein Problem, gute Kandidaten für das Design Team zu bekommen. Also das ist absolut nicht der Fall. Das ist aber natürlich etwas, worauf wir genau schauen, wenn sich bei uns ein Designer bewirbt, der jeder Designer hat meistens, bringt meistens so ein Portfolio mit. Also das sind sozusagen dann halt seine Referenzprojekte, die er gemacht hat. Was wir normalerweise machen ist, wir schauen auf die Portfolios und können im Endeffekt relativ schnell sagen, okay, das ist jemand für uns oder nicht. Also so können wir sehr, sehr schnell vorselektieren. Wenn jemand einfach ja z.B. nur mobile Interfaces gebaut hat, ist es wahrscheinlich, sind wir wahrscheinlich nicht der richtige Arbeitgeber für ihn. Wenn Leute ja z.B. in Banking Produkten oder in Procurement Einkauf, Beschaffung, da gibt es, es gibt extrem viele Bereiche, die alle eine hohe Komplexität mitbringen, die vielleicht nicht so, nicht so technisch sind, aber wo man sich extrem in diese Domain reinfuchsen muss. Und manche Leute machen das sehr gerne. Und das Schöne ist auch, dass gerade so diese, diese Methoden, über die wir vorhin gesprochen haben, die im UX Design, in dieser, in der Lösungsfindung stattfinden, die sind eigentlich, eigentlich sehr, sehr gut und sehr gut gemacht dafür, um genau diese Komplexität zu verstehen. Und manche, ja, wie gesagt, es gibt Leute, die mögen das, die mögen Komplexität und die sind genau die richtigen Designer für uns.

Andy Grunwald (00:57:09 - 00:58:13)

Ich hoffe, ihr findet mehr solche Leute, denn für jede Person, die schon mal mit der Amazon Web Service Konsole arbeiten musste oder mit der Azure Cloud Konsole von Microsoft, kann ich mir zeigen, ja, also diese Menschen, also in Bezug auf Informationsdichte und Komplexität und Möglichkeiten, die du alle in diese UI packen musst, da musst du ja ganz knallhart aufpassen, dass du nicht irgendwie eine SAP Oberfläche wirst oder ähnliches. Das ist ja also so viele Einstellungen, wie man bei einem Cloud Service machen kann und so. Ich kann mir schon vorstellen, dass das sehr herausfordernd ist. Wir hatten vorhin so ein bisschen über die Kunst des Weglassens gesprochen, aber auf der anderen Seite habe ich auch so ein Stereotyp in meinem Kopf. Ist das nicht so, dass jeder Designer irgendwie bei Apple arbeiten möchte und neues Design als Standard machen möchte und irgendwie beim nächsten iPhone äquivalent arbeiten möchte oder ähnliches? Also nach dem Motto, ich möchte was Neues schaffen, was die Welt sagt, wow, das ist das neue Design, das ist der neue Design Standard. Verstehst, was ich meine?

Robin Titus (00:58:13 - 00:59:24)

Klar finde ich das auch cool, was Apple macht. Und wie gesagt, glaubt nicht, dass alle bei Apple, ich sage mal so, an so extrem innovativen Sachen arbeiten. Das Endergebnis ist natürlich krass und jeder kennt es, aber ich denke immer, also was, was ich extrem motivierend finde, ist, wenn man für ein Produkt, wenn man ein Produkt designt, das dann Erfolg am Markt hat und dass das die Kunden kaufen, wo ich gutes Feedback von den Usern bekomme. Ich hatte selber ein Startup, ich habe auch für verschiedene Startups, Scale ups gearbeitet. Wir haben an einem Produkt gearbeitet, es extrem schwer war, in den Markt zu bekommen, wo wir einfach so diesen Product Market fit nie so richtig gefunden haben. Und das finde ich, da kann man, da gibt es tolle Produkte, die toll designt sind und so weiter, wo vielleicht alles super shiny ist und so weiter. Aber ja, ich finde, ich finde, ich denke so vom Mindset her ist für mich, wenn, wenn das, was ich, an dem ich mitgebaut habe, wenn das erfolgreich ist, das gibt mir die die Motivation.

Andy Grunwald (00:59:24 - 00:59:44)

Kommen wir zu unserer typischen Abschlussfrage für unsere Podcast Episode. Was würdest du dir von allen anderen Leuten des Produkt Trios, jetzt nicht von UI Designern, denn wünschen? Was können wir, Wolfgang und ich z.b. jetzt mal angenommen, wir wären da jetzt in einem Produkt Trio, denn du sprichst.

Wolfi Gassler (00:59:44 - 00:59:52)

Primär auf die zu einer technischen Audience. Also wir haben wenig Product Owner, glaube ich, in der Audience, aber einige sind es wahrscheinlich auch.

Andy Grunwald (00:59:52 - 01:00:03)

Wenn du, wenn du, wenn du zwei Aktivitäten oder eine Aktivität mitgeben würdest, was können unsere Hörerinnen und Hörer heute starten, um die tech Kultur, das Produkt Trio einfach besser zu gestalten?

Robin Titus (01:00:03 - 01:01:08)

Wie du vorhin auch schon gesagt hast, sprecht miteinander. Es geht aus meiner Sicht geht es einfach darum, also von beiden Seiten die andere Seite besser zu verstehen. Was macht ihr da eigentlich alles? Was, was wir vielleicht nicht sehen. Wenn ich jetzt speziell die Entwickler ansprechen würde, schaut mal wirklich in die Methoden rein, die UX Designer so in ihrem Portfolio haben und besprecht mal mit einem Werksdesigner, wie ihr z.B. so Methoden auch für euch nutzen könnt. Da geht es für mich so um diese ganzen Workshop Formate. Also wir haben, wir haben im UX Design und im Design Thinking gibt es ein riesen Portfolio an Workshop mit Methoden, um Lösungen zu finden, um Dinge besser zu verstehen und so weiter. Und schnappt euch einfach mal einen Designer und organisiert mal einen Entwickler Workshop, wo ihr ein entwicklungsspezifisches Thema besprechen wollt und lasst den Designer sozusagen das ganze mal fazilitieren. Mir fällt das deutsche Wort nicht ein.

Wolfi Gassler (01:01:08 - 01:01:13)

Gute Frage. Leitend, leiten. Ja, keine Ahnung.

Robin Titus (01:01:13 - 01:01:51)

Euch sozusagen durch so eine Methode durchzuführen. Was eine super Methode, die auch, die einfach, die in der Entwicklung natürlich sehr prominent sind, sind die Retros. Ja, ich denke, alle Teams machen, also alle Teams, mit denen ich gearbeitet habe, machen Retros, sind zum Teil auch sehr, sehr kreativ. Also jetzt auch in unserem Unternehmen. Wir haben sehr, sehr kreative Retros gesehen, die dort gemacht werden. Und da gibt es halt einfach noch viel, viel mehr. Da, das wäre z.B. so eine Sache, um einfach mal anzufangen. Was sind so Methoden von Workshops, die man eben auch für ein entwicklungsspezifisches Thema einsetzen kann und sowas einfach mal ausprobieren kann.

Wolfi Gassler (01:01:51 - 01:02:05)

Also dem kann ich nur beipflichten. Design Sprints, jedes Mal, wenn ich die gemacht habe, es war einfach ein voller Erfolg in dem gesamten Team und alle, alle sind irgendwie voll motiviert rausgegangen aus diesem Prozess. Es funktioniert wirklich super.

Andy Grunwald (01:02:05 - 01:02:49)

Jetzt komme ich aus meiner Grumpy Ecke. Ich hasse Menschen und muss jetzt mit Menschen reden. Nein, kleiner Witz. Robin, vielen lieben Dank für diese Podcast Episode und dass du deine Weisheiten, wenn es uns geteilt hast. Ich habe auf jeden Fall ein paar neue Buzzwords aufgeschnappt, die ich jetzt klug verwenden kann. Double Diamond, First Mile und Produkt Trio. Damit kann ich auf jeden Fall wieder glänzen und klug klingen. Danke dir. Und wir verlinken natürlich auch alle Links in den Show Notes, unter anderem auch, wie ihr Robin auf LinkedIn finden könnt, falls ihr da nochmal eine Frage habt. Ansonsten gerne auch Feedback in der Community geben. Das leiten wir natürlich auch an Robin weiter. Ansonsten, Robin, vielen lieben Dank, dass du da warst und dass du die Zeit.

Wolfi Gassler (01:02:49 - 01:03:03)

Mit uns verbracht hast und dass du auf Deutsch das Ganze gemacht hast. Du sprichst ja seit Jahren eigentlich nur mehr Englisch. Wir wissen selber, wie schwierig das ist und wir haben es fast geschafft, ohne zumindest mit wenig Anglizismen durchzukommen. Vielen Dank dafür auch von meiner Seite.

Robin Titus (01:03:03 - 01:03:03)

Danke euch.

Andy Grunwald (01:03:04 - 01:03:04)

Tschüss, bis zum nächsten Mal.