10 nach 10 Podcast

HT: Design Thinking

May 07, 2021 Sigrid Schefer-Wenzl and Igor Miladinovic
10 nach 10 Podcast
HT: Design Thinking
Show Notes Transcript

Design Thinking ist eine systematische Herangehensweise an komplexe Problemstellungen. In Software Projekten fördert Design Thinking eine stetige Rückkopplung zwischen Entwickler*innen einer Software-Lösung und ihrer Zielgruppe. 

In dieser Folge reden wir mit Peter Gerstbach, einem Experten für Design Thinking, über die Potenziale und Einsatzbereiche von Design Thinking. Insbesondere beleuchten wir das Thema Design Thinking in Software Projekten mit dem Ziel Ihnen ein Gefühl zu geben, wann und wie Design Thinking erfolgreich eingesetzt werden kann.

00:00:05
 Intro Speaker: Wissenswertes und Wissen. News aus den Studiengängen der Technik an der FH Campus Wien.

00:00:22
 Igor Miladinovic: Design Thinking ist eine systematische Herangehensweise an komplexe Problemstellungen in Software Projekten fordert DesignThinking, eine stetige Rückkopplung zwischen Entwicklerinnen und Entwicklern, einer Softwarelösung und ihrer Zielgruppe. Lösungen und Ideen werden in Form von Prototypen möglichst früh sichtbar gemacht, was in praxisnahen Ergebnissen resultiert.

00:00:47
 Sigrid Schefer-Wenzl: In dieser Folge reden wir mit Peter Gerstbach, einem Experten für Design Thinking, über die Potenziale und Einsatzbereiche von Design Thinking. Insbesondere beleuchten wir das Thema Design Thinking in Software Projekten mit dem Ziel, Ihnen ein Gefühl zu geben, wann und wie Design Thinking erfolgreich eingesetzt werden kann. Im Studium setzen wir Design Thinking unter Anleitung von Peter Gerstbach in mehreren Lehrveranstaltungen ein, um Studierende bei Software Projekten zu unterstützen.

00:01:22
 Igor Miladinovic: Die Entwicklung der Informatik und digitalen Kommunikation war nie so schnell wie heute

00:01:28
 Sigrid Schefer-Wenzl: und sie wird nie so langsam sein wie heute.

00:01:34
 Igor Miladinovic: In diesen Podcast stellen wir wichtige Themen rund um unsere Informatik Studiengänge der FH Campus Wien vor,

00:01:42
 Sigrid Schefer-Wenzl: die Sie optimal für diese Entwicklung vorbereiten werden.

00:01:48
 Igor Miladinovic: Willkommen zu dieser Folge von unserem Podcast 10 nach 10. Mein Name ist Igor Miladinovic und ich bin der Studiengangsleiter der Studiengänge: Computer Science and Digitial Communikations und Software Design and Engineering.

00:02:01
 Sigrid Schefer-Wenzl: Willkommen auch von meiner Seite. Mein Name ist Sigrid Schefer-Wenzel und ich unterrichte in diesen beiden Studiengängen.

00:02:07
 Igor Miladinovic: Heute reden wir über das Thema Design Thinking. Und als Gast haben wir in dieser Sendung Petra Gerstbach. Der arbeitet im Bereich Unternehmensberatung, wo er Firmen hilft Projekte mit Design Thinking Methoden erfolgreich umzusetzen und am Anfang würde ich Peter gleich bitten, dass er sich kurz vorstellt.

00:02:29
 Intro Speaker: Ja Hallo, danke für die Einladung. Mein Name ist Peter Gerstbach. Ich freue mich, dass ich auch an der FH als Lektor tätig sein kann. Aber meine Hauptaufgabe ist: ich bin Geschäftsführer einer Unternehmensberatung Gerstbach Business Analyse und wir helfen dabei Unternehmen, kreativer zu sein, in der Analyse ihrer Probleme besser zu werden. Und sind eben fokussiert auf die Themen Business Analyse und Design Thinking.

00:02:56
 Sigrid Schefer-Wenzl: Kannst du uns kurz verraten? Was versteht man denn unter Design Thinking und woher kommt dieser Begriff?

00:03:02
 Peter Gerstbach: Naja, Design Thinking, der Begriff hat er schon im Namen des Design und das Denken. Und das könnte man auch so übersetzen, dass man dabei denkt wie ein Designer. Und der Begriff kommt an sich aus dem Silicon Valley. Also es gab auch schon ein Buch davor, wo es irgendwie darum gegangen ist, dass Designer eine eigene Art zu denken haben und zwar weniger analytisch. Analyse heißt ja auf Altgriechisch zerlegen und beim analytischen Denken versucht man ein Problem solang zu zerlegen, bis man es in seinen Grundelemente verstanden hat. Aber das geht bei komplexen Problemen nicht. Und deswegen nimmt man sich im Design Thinking so Anlehnungen an, ja an anderen Designprozessen. Und da ist es eher so, dass viel ausprobiert wird, prototyping macht, nicht versucht, alles zu verstehen, sondern eher mal beobachtet und tatsächlich Erfahrungen macht. Das was funktioniert, das wiederholt man. Und das, was nicht funktioniert, das lässt man halt. Und daher kommt dieser Begriff Design Thinking und das wurde dann zu einer Methode zusammen gebaut. Vor allem eben im Silicon Valley. Die Firma Idea ist da ganz bekannt und die haben das sozusagen in die Wirtschaft gebracht. Aber es ist jetzt nicht ein abgeschlossenes Konzept, wo es ein Buch gibt, das erklärt, wie das funktioniert. Es hat sich über die Jahrzehnte und Jahre, insbesondere die letzten Jahre in viele Richtungen entwickelt und ist deswegen ein Sammelsurium unterschiedlicher Methoden.

00:04:27
 Igor Miladinovic: Danke! Und du kommst aus dem IT-Bereich, das ist also aus einem technischen Bereich, aus einem analytischen Bereich. Wie bist du dann zu dem Thema Design Thinking gekommen?

00:04:37
 Intro Speaker: Also tatsächlich über meine Frau. Und das ist ein typischer, ein weiblicher Einfluss. In meinem Fall würde ich sagen Ja, ich habe eben Informatik studiert und Wirtschaftsinformatik und habe aber eigentlich auch schon während dem Studium erkannt, dass dieser kommunikative Teil in der Softwareentwicklung oder in der System Entwicklung allgemein, dass der häufig zu kurz kommt. Natürlich, in der Informatik wird natürlich viel Wert gelegt auf die technischen Aspekte und wie es uns Software, System oder ein IT System programmiert wird und wie die Software Architektur aussieht. Aber es ist halt enorm wichtig, dass die Software oder die Lösung tatsächlich die Bedürfnisse erfüllt, der Nutzer und das ist oft nicht der Fall. Und ich hab das schon während des Studiums gemerkt und hab mich da viel für das Thema Requirements Engineering interessiert. Aber das stand zumindest damals gar nicht so im Vordergrund. Ich habe mich damit beruflich beschäftige. So nach dem Studium habe ich es als Anforderungs Analytiker und später auch als Business Analyst. Also mehr noch in die Business Richtung hab ich mich mit den Themen beschäftigt, aber trotzdem noch gemerkt, da gibt's noch so viel zu entdecken. Was betrifft und was brauchen eigentlich Menschen? Und hat auch sehr oft erlebt in Projekten, dass Dinge gemacht werden, neue Systeme geschaffen werden und die dann aber nicht angenommen werden oder vielleicht das eigentliche Problem nicht lösen. Das fand ich immer sehr schade und ich fand es auch immer deprimierend, wenn man sein Herzblut in ein Projekt steckt und da tolle technische Lösungen schafft, aber sie eigentlich an dem eigentlichen Ziel vorbeigehen. Und dann hab ich mich von meiner Frau inspirieren lassen, die eben eigentlich schon seit vielen Jahren in der Beratung ganz anders gearbeitet hat und dann eben auch auf Design Thinking gestossen ist. Und das ist mein Ansatz, der den Menschen sehr stark in Fokus legt und das wahrnimmt. Auch das, was meiner Meinung nach auch in den Projekten, die ich gemacht habe, tatsächlich gefehlt haben. So haben wir uns dann mehr mit Design Dingen beschäftigt. Insbesondere meine Frau hat Bücher geschrieben, viele Bücher über Design Thinking, mittlerweile über die einzelnen Methoden, aber vor allem über das Mind Set von Design Thinking und das ganz wichtig ist, weil mit dem richtigen Mind Set is es dann noch möglich, genau diese Probleme zu lösen, dass man eben nicht etwas löst, was eigentlich gar nicht dem Bedürfnis entspricht. Gerade mit diesem Mind Set hilft es eben dann dabei, dass ich ein Problem zuerst wirklich verstehe, bevor ich in eine Lösung gehe. Und das ist, glaube ich ganz, ganz wichtig und das hat uns dazu geführt, und da hab ich mich dann auch einfach wiedergefunden.

00:07:04
 Sigrid Schefer-Wenzl: Dankeschön. Design Thinking als Mind Set bedeutet ja dann auch, dass es quasi unabhängig jetzt von der konkreten Anwendungs Domäne ist. Was sind eure Erfahrungen? Wo kann man Design Thinking gut einsetzen.

00:07:18
 Peter Gerstbach: Also wir erklären das in unseren Trainings meistens so, dass es von der Art des Problems abhängt. Und was meine ich mit Art des Problems? Es gibt ganz einfache, triviale Probleme, wo man nicht lang überlegen muss und man weiß, was ist das Problem, es ist so offensichtlich, und da hilft Design Thinking nicht wirklich. Es gibt auch komplizierte Probleme, wo diese Analyse tatsächlich sehr wichtig ist und wirklich dabei hilft. Aber es gibt auch komplexe Problem und das sind besonders die Systeme, wo man wirklich von einem systemischen Problem ausgehen kann. Das heißt, wenn viele Menschen involviert sind und die unterschiedliche Ziele haben, dann kann man das nicht durchs Analysieren, durch Zerlegen lösen. Und genau da ist Design Thinking gut geeignet. Das heißt, wenn man eigentlich gar nicht genau weiß, was das Problem ist, oder wenn man die vielen Stakeholder in einem Projekt, die vielen unterschiedlichen Ziele gar nicht so auseinander trennen kann. Wenn man wirklich Erfahrungen machen muss, bevor man überhaupt versteht, was ist eigentlich das Problem, das ich lösen muss? Das kann man nicht am Papier planen. Und genau da ist es an sich besonders gut geeignet. Das kann z.B. sein in der Softwareentwicklung, wenn man etwas ganz Neues macht vielleicht, eine neue App in einem Markt, den so jetzt mal noch nicht gibt, wo es noch keine Erfahrungswerte gibt. Aber das kann auch in Firmen sein, wenn es um Prozess Veränderungen geht, wo viele unterschiedliche Abteilungen involviert sind. Und eine sehr häufige Anwendung von Design Thinking ist auch so im sozialen Bereich gesellschaftlichen Bereich, um wirklich große Probleme zu lösen, in der Fachwelt wird das dann auch so rigged problems genannt, das ist eine Definition von Horst Drittel, der eben eine Art von Problemen erkannt hat, die so verzwickt sind, dass sie einfach schwer zu lösen sind und bei solchen Problemen da überall hilft Design Thinking.

00:09:11
 Igor Miladinovic: Vielen Dank, d. h. für Probleme, wo die Komplexität fehlt ist Design Thinking eher nicht gut geeignet. Selbst wenn die Probleme kompliziert sind, z.B. wenn ich jetzt einen komplizierten Drucker installieren will. Da wird wahrscheinlich Design Thinking wenig helfen. Hast du Beispiele für Software Projekte, wo Design Thinking gut eingesetzt werden kann?

00:09:32
 Peter Gerstbach: Ich komme gleich nochmal auf dein Drucker Beispiel zurück. Ein Drucker, wenn da etwas nicht funktioniert, wenn er normal funktioniert, dann gibts halt eine Checkliste. Die kann ich sozusagen abarbeiten. Und da hat sich ein Experte hingesetzt und sich überlegt okay, was sind die besten Schritte? Dass das inklusive aller Sonderfälle am besten funktioniert. Das alles, was man so Checklisten abarbeiten kann oder wo man auch einfach Experten braucht, die gewisse Probleme lösen, da benötige ich eigentlich nicht Design Thinking. Aber überall dort, wo das nicht der Fall ist, wo ich noch nicht einmal so recht weiß, was das Problem ist. Da hilft mir eher Design Thinking und in SoftwareEntwicklungsprojekten ist das natürlich auch der Fall. Da gibt's ja auch viele Situationen, gerade am Anfang eines Projekts, wo eigentlich noch nicht ganz klar ist, was man lösen möchte. Und da ist Design Thinking eigentlich sehr gut geeignet, in sehr frühen Phasen, bevor ich sozusagen überhaupt noch beginne, bevor ich eigentlich noch ein Projekt hab, kann ich mit Design Thinking mal herausfinden, sozusagen eine Hypothese erstellen: Was würde meinen Nutzern, den späteren Nutzern dieser Software, was würde denen helfen? Und im Design Thinking gibt's mehrere Phasen. Also meine Frau beschreibt in ihren Büchern vier Phasen und auch in unserem Buch über über Design Thinking in IT-Projekte beschreiben wir vier Phasen. In den ersten zwei Phasen geht es einmal darum, das Problem zu verstehen. In den nächsten beiden Phasen das Problem zu lösen. Bei diesen ersten beiden Phasen, beim Problem verstehen, nutzen wir zum Beispiel Beobachtung, unterschiedliche Methoden aus der Beobachtung. Eine Methode nennen wir z.B. empathisches Gespräch, wo man einfach mit dem potenziellen Software Nutzern Gespräche führt, was sie sich erhoffen von dieser Software. Wir reden da nicht eigentlich über Features, über Funktionen, sondern wir reden eigentlich über Bedürfnisse. Wir versuchen zu verstehen, was will er eigentlich machen mit der Software? Wie wird es das Leben oder die Arbeit oder was auch immer damit erreichen werden will, wie wird das besser? Daraus versuchen wir, diese Bedürfnisse abzuleiten. Und das ist etwas, was die Menschen oder die Kunden, die Nutzer können üblicherweise nicht sagen, was eine Software können soll. Die können das schon sagen, aber ob es dann tatsächlich stimmt, ist wieder etwas anderes. Es heißt gerade in der Softwareentwicklung in sehr frühen Phasen kann man mit Design Thinking wirklich herausfinden, welche Anforderungen an eine Software bestehen. Und zwar eben nicht auf diesee analytischen Weise, sondern wirklich verbunden mit Bedürfnissen der Menschen und der zukünftigen Nutzung dieser Software.

00:12:05
 Sigrid Schefer-Wenzl: Vielen Dank! Genau das haben wir ja auch schon mit dir gemeinsam in Workshops mit unseren Studierenden gemacht. Also am Beginn eines Software Projektes den Studierenden geholfen eben sich einzufühlen, quasi in das Projekt und die Anforderungen zu erheben. Und das hat immer sehr viel positive Resonanz ausgelöst. Kannst du uns vielleicht, damit sich unsere Hörerinnen und Hörer da noch mehr drunter vorstellen können, kannst du uns vielleicht ein konkretes Software Projekt idealerweise nennen oder uns kurz erzählen, wie das gelaufen ist, wo du oder ihr Design Thinking angewendet habt?

00:12:41
 Intro Speaker: Da hab ich ein Beispiel, das hier vielleicht ganz gut passt. Und zwar ging es hier um eine Software und der Auftrag den wir für einen Kunden durchgeführt haben, ist ein besseres User Interface für eine Software zu finden. Die Software hat schon existiert und zwar war das eine Software, die auf einem Touchscreen gelaufen ist, eigentlich auf einem Automaten. Das war nämlich so ein Ticket Dispenser. Ja, so ein Automat. Also man geht in einer Dienststelle und das kennt man ja, da muss man gleich auf unterschiedlichen Stockwerken in unterschiedlichen Zimmer hinein. Je nachdem, was für eine Anfrage man hat . Auf diesen Touchscreen konnte man sagen, was man eigentlich möchte. Dann hat man ein Ticket gezogen bekommen, da stand dann eine Nummer drauf war, wann man dran ist und bei welcher Tür man sozusagen warten sollte. Der Auftrag war, dieses System zu verbessern. Die hatten eine interne Reorganisation und hatten außerdem das Problem, dass die Kunden, also die Bürger, die dorthin gekommen sind, dass die sich nicht zurechtgefunden haben. Die haben da was falsch bedient und dann haben sie beim falschen Zimmer gewartet. Und das wussten die schon so, dass da wohl irgendwas nicht ganz so funktioniert wie geplant. Und das Ziel war eben diese Software zu verbessern. Und was wir gemacht haben, im Design Thining die erste Phase, die heißt einfühlen. Und da geht es eben darum, dass man mal überhaupt versteht, was ist das Problem. Und wir haben uns eigentlich gar nicht am Anfang die Software angesehen, sondern wir haben uns die Situation angesehen und haben uns dort vor diesen Automaten gestellt und geschaut, was passiert. Und da sind halt die Leute reingekommen und uns ist ziemlich schnell aufgefallen, dass die den Automaten mal gar nicht finden. Die haben ja gesucht. Okay, wo muss ich hin und haben den erstbesten Bereich angesteuert und wollten dort die Auskunft haben. Und wie sind also darauf gekommen, dass dieser Automat gar nicht am richtigen Ort steht. Der muss irgendwie ganz zentral stehen, dass man gar nicht woanders vorbeikam. Das hat dazu geführt, dass die Bürger da immer rein sind und hin und hergeschickt worden sind, so etwa wie bei Asterix und Obelix. Und das Zweite, was uns aufgefallen ist, wenn die Leute diesen Automaten bedient haben, dass sie dann Laufzettel nicht gefunden haben. Da war nämlich so ein großer Pfeil und er hat dann nach rechts geführt. Dann sind die Leute, einen Schritt nach rechts gegangen und da stand ein zweiter Automat, der an sich genauso bedient werden konnte. Aber nachdem der Pfeil nach rechts gegangen ist, haben die Leute dann auf diesen zweiten Automaten geschaut. Dort war wieder ein Pfeil nach rechts und sie wollten eigentlich nur diesen Zettel, der da rausgekommen ist, abziehen. Da war der nächste Pfeil nach rechts, hat wieder zu einem Automaten geführt. Das war ein Cola Automat. Da haben sie sich dann doch gedacht Nee, das kann jetzt nicht sein. Und in Wahrheit gingen diese Zettel so auf dem rechten Rand dieses Automaten raus. Da hat man einfach schon gesehen, da ging es nicht um Software, da ging es um so viel mehr. Natürlich war die Software für sich gesehen auch nicht perfekt. Die hatte auch ihre Schwächen. Aber was man im Design Thinking immer betrachtet, ist das gesamte System und hier haben wir einfach viele Beobachtungen gemacht. Wir haben gar nicht mit den Leuten gesprochen, haben nur beobachtet, was passiert. Und dann gibt's im Design Thinking unterschiedliche Wege. Wir haben uns einfach hingestellt, in einem kleinen Team so in die eine Ecke, sodass man nicht irgendwie selbst gesehen wird und haben geschaut, was die Leute machen und haben einfach an ihrem Augenbewegungen, an ihren Geste gemerkt, dass sie zuerst einmal sich nicht auskennen, wo sie eigentlich hinwollen. Dann entdeckten sie diesen Automaten und gehen dorthin und dann tippen sie eben herum und dann suchen sie diesen Zettel. Das alles hat uns schon viel, irrsinnig viel Information gegeben, was wir eigentlich verbessern können, ohne dass wir die Software überhaupt mal anrühren müssen. Und das ist sehr häufig so, dass man Lösungen in der Technik sucht, in dem Fall halt in der Software und vergisst, das gesamte System zu betrachten. Und das ist ein ganz wichtiger Aspekt im Design Thinking, dass wir eigentlich mal ganz unabhängig von der Lösung einfach uns die Situation anschauen. Das versteht man doch unter einer systemischen Herangehensweise. Ich betrachte das ganze System und mach das System auch größer. Also man könnte das System dieser Software betrachten. Man könnte das System größer machen und diesen Automaten samt der Hardware betrachten. Oder wir haben das noch Größe gemacht, haben diesen ganzen Raum betrachtet. Wir haben ein System sogar dann noch größer gemacht und sind raus auf die Gasse gegangen und haben geschaut, ob da überhaupt ein Schild draußen steht, wo die Leute hin müssen und haben auch entdeckt, dass da sozusagen auch schon Probleme bestehen. Das heißt im Design Thinking betrachten wir eigentlich, entscheiden eigentlich relativ rasch auch, wie groß das System sein muss und gehen möglicherweise ein, zwei oder drei Schritte rückwärts, um das Ganze zu sehen, was wirklich relevant ist. Ja, da haben wir dann eigentlich schon gleich viele Verbesserungsvorschläge gemacht. Da kommen wir eigentlich schon so in diese dritte und vierte Phase, wir haben Ideen gesammelt, wie man z.B. das verbessern kann und das dann auch gleich ausprobiert. Da waren viele Plakate und Pfeile und Beschriftungen in dem ganzen Raum. Und die, die nicht so wichtig waren, die haben wir entfernt und einfach neue angebracht. Das kann man durch Prototyping machen, es muss es nicht schön ausgedruckt sein, wir haben einfach ein A4 Papier genommen und mal beschriftet und geschaut, ob das funktioniert. Diesen ganzen Ansatz haben wir dann auch noch wiederholt. Bei der eigentlichen Software und haben getestet, wie die Leute die Software tatsächlich nutzen. Und mit denen haben wir dann zum Beispiel auch Gespräche geführt, indem wir z.B. die Leute gefragt haben Haben sie sich ausgekannt? Wir haben sie nachher befragt: Was haben sie eigentlich gesucht und hat sozusagen das eigentlich zu einem Ergebnis geführt? Wir sind draufgekommen, dass z.B. viele die deutsche Sprache nicht so gut kannten, sich damit schwer getan haben, weil die Begriffe für nicht deutsch Sprechende schwer zu erklären waren. Das hat uns dann zur Idee gebracht, dass wir eigentlich unterschiedliche Texte ausprobieren können. Und auch hier haben wir wieder Prototypen gemacht. Wir haben nicht diese Software verändert. Das wäre gar nicht mal so einfach gewesen, sondern wir haben statt diesem Touchscreen haben wir einfach ein Blatt Papier darüber gelegt. Und mit der Hand eingezeichnet haben wir sozusagen neue Fragen, ein neues User Interface entworfen. Wenn jemand reingekommen ist, musste er sozusagen auf dem Blatt Papier sagen: Wo würde er jetzt klicken? Dann hat er sozusagen geklickt und dann haben wir mal ein anderes Blatt Papier hingehalten. Und das sind halt ganz einfache Varianten, ein User Interface zu testen. Nein, da muss man nichts programmieren, da muss man nur ein Blatt Papier und Bleistift haben und dann hat man eine Version, die ganz gut funktioniert hat. Und die haben wir dann mit einem Klick Dummy umgesetzt. Das heißt, der erste Schritt ist eigentlich immer ein ganz, ganz einfacher Prototyp, derdabei helfen kann, besser zu verstehen, was könnte eigentlich funktionieren? Und doch nochmal herauszufinden, was vielleicht noch für Probleme bestehen könnten. Und im Endeffekt wurde das dann natürlich schon auch noch in eine richtige Software gegossen, aber das ganze war eben schon validiert. Und dann ist auch das Investment, das man ja tätigt, wenn man eine Software programmiert, ausrollt, auf mehreren Automaten, dann ist das Investment auch irgendwie besser gesichert. Das zeigt irgendwie ganz schön, wie man mit Design Thinking eigentlich an so ein Problem herangehen kann.

00:19:44
 Igor Miladinovic: Vielen Dank für dieses aussagekräftiges Beispiel. Da hat man Design Thinking auf einem System oder auf einem Produkt angewendet, wo man beobachtet hat, dass das System nicht die Ergebnisse bringt, die man erwartet. Man kann aber auch Design Thinking von Anfang an anwenden. Und da würde mich interessieren: Was ist die Beziehung oder wo ist die Abgrenzung? Oder Wie greift das ineinander zusammen, zwischen Design Thinking und Innovation?

00:20:17
 Peter Gerstbach: Ja, also Design Thinking wird unterschiedlich definiert. Die einen sagen, es ist eine Innovations Methode, die anderen sagen, es ist eine Problemlösung Methode in Wahrheit ist es beides. Also ich kann damit Probleme lösen, so wie jetzt in diesem Beispiel von diesem Automaten irgendwie. Das funktioniert nicht so, wie ich mir das erhofft habe. Aber auch eine Innovation geht eigentlich zurück auf ein Problem. Ich will irgendetwas besser machen. Wenn ich etwas so großartig verbessere, dass es fünf Mal besser ist oder zehnmal besser ist, dann habe ich wirklich eine disruptive Änderung. Aber auch das basiert immer auf einem Problem. Weil wenn alles perfekt ist, ja, dann brauche ich auch keine Innovation. Dann wird sich niemand hinsetzen und sich Überlegen etwas anders zu machen. Ein Beispiel, was mir noch stark in Erinnerung ist, das war bei einem Aufenthalt in Silicon Valley. Da waren wir am Weg davor in Las Vegas unterwegs. Und da kann man in Wahrheit nur mit dem Auto fahren, wenn man irgendwohin will, weil die großen Straße nicht besonders Fußgänger freundlich sind, außer auf dem Strip da kann man am Rand entlang gehen. Aber wenn man etwas weiter raus will, braucht man ein Auto. Naja, und wir wollten uns ein Taxi rufen und unser Hotelangestellte hat uns erklärt Na vergesst das Taxi, nehmt ein Uber, weil da kann man, wenn man Pech hat und gerade eine große Konferenz ist, kann man Stunden warten, bis das Taxi kommt. Und ja, bei Uber ist es ja bekannt, dass es das der Preis damit fluktuiert mit der Nachfrage und dem Angebot, dadurch sorgt es eigentlich dafür, dass immer genug Angebot da ist. Das heißt, was Uber in Amerika gelöst hat, ist ein nicht funktionierendes Taxigewerbe. Das funktioniert in Amerika nicht so gut. In Europa haben wir das Problem nicht und das sieht man auch wie wichtig das ist, dass es bei einer Innovation, in diesem Fall diese Uber Taxi App, dass es da immer darum geht, wirklich ein Problem zu lösen, ist auch der Grund, warum so etwas z.B. in Amerika begonnen wurde und nicht in Europa. Weil in Europa funktioniert das ich kann mich in jeder Hauptstadt hinstellen und habe wahrscheinlich in 5 Minuten ein Taxi. Soll so ein Beispiel sein, wie wichtig es ist, dass tatsächlich ein Problem gelöst wird. Das ist auch Design Thinking, wenn ich es anwende, für Innovationen, muss ich zuerst einmal verstehen, was ist eigentlich das Problem, das ich lösen möchte. Und das muss ich wirklich verstehen, dieses Problem. Da muss ich wirklich Erfahrungen sammeln, da muss ich viel ausprobieren, weil nur dann kann ich auch meine Lösungen und also meine Softwarelösung so bauen, dass sie dieses Problem löst und dass sie tatsächlich auch wirklich innovativ ist.

00:22:47
 Sigrid Schefer-Wenzl: Vielen Dank! Was jetzt vielleicht für unsere insbesondere Studierenden interessant sein könnte, wäre: wie kann man denn diese Methode Design Thinking im Studium einsetzen? Jetzt mal losgelöst von IT Problemen, sondern eher auf einer abstrakteren Ebene vielleicht.

00:23:07
 Peter Gerstbach: Also im Grunde lässt sich Design Thinking wirklich bei jeder Art von Problemen einsetzen, die eben komplexer Natur sind. Das heißt ja zum Beispiel auch im normalen studentischen Ablauf kann ich mir vorstellen, dass es gut funktionieren kann. Es braucht halt immer ein Team dazu. Also es ist jetzt keine Methode, die üblicherweise alleine mach, sondern Design Thinking lebt doch vom Team. Darüber haben wir noch gar nicht gesprochen. Ich brauche ein Team von unterschiedlichen Leuten. Deswegen ist es auch eine gute Idee, wenn Studenten etwas im Rahmen des Studiums lösen wollen, dass sie nicht nur mit anderen Studenten reden, sondern dass sie auch immer ein breiteres Blickfeld sozusagen einnehmen und auch andere Leute mit anderen Background oder anderen Situationen mit einbeziehen. Das ist vielleicht wichtig zu beachten, aber prinzipiell lässt sich Design Thinking wirklich für alle Art von Problemen einsetzen.

00:23:59
 Igor Miladinovic: Dankeschön! Und wir kommen jetzt zu der letzten Frage, und zwar ihr habt auch viele Bücher geschrieben. Mehr als 5 Ich glaube, 6 7 Bücher habt ihr schon geschrieben.

00:24:12
 Peter Gerstbach: Genau.

00:24:13
 Igor Miladinovic: Es ist immer zu unterschiedlichen Themen und in einem Buch ist es darum gegangen, viele Methoden vorzustellen. Ich glaube, 77 Methoden im Design Thinking oder Tools, was wären eure Favoriten, was diese Tools betrifft? Gibt es für bestimmte Problembereich unterschiedliche Tools oder gibt es Tools, die man immer gut anwenden kann? Was sind da eure Erfahrungen?

00:24:36
 Peter Gerstbach: Es gibt schon ein paar Fix-Starter, als in diesem Buch 77 Tools beschreibt eben Ingrid, meine Frau, 77 Tools. Wobei man jetzt, um Design Thinking machen zu können, wirklich nicht siebenundsiebzig Tools können muss. Es hilft aber schon dabei, dass man die Tools situativ einsetzt. Das heißt, je mehr Tools man kann, in der Praxis, desto besser kann man das aussehen, was jetzt gerade passt. Ich kann eigentlich gar nicht sagen, das es sozusagen ein Lieblings Tool von mir gibt, was ich gerne einsetze, weil es bisher von der Situation abhängt. Weil es gibt z.B. die dritten Phase beim Ideen generieren geht es darum, möglichst viele Ideen auf ein mögliches Problem zu finden. Und da gibt's z.B. Methoden, die sind eher raumgreifend. Also da bewegt man sich im ganzen Raum und es ist laut und es soll Spaß machen. Und dann gibt's auch Methoden, die sind ein bisschen eher analytischer. Da geht man ein bisschen in Kategorien vor und versucht dann zu jeder Kategorie Ideen zu finden. Und in einer Workshop Situation muss ich als Design Thinking Moderater darauf achten, dass ich das Team richtig einschätze und denen auch diese Tools gebe die ihnen jetzt am meisten helfen. Je nachdem müssen die aufgeweckt werden? Brauchen die jetzt was wilder oder würde sie das vielleicht sogar überfordern? Im ersten Schritt ist es besser vielleicht eine Methode zu wählen, die sie bereits kennen oder die nicht so unkonventionell ist. Und deswegen ist es wichtig, diese Methoden so auszuwählen, dass sie wirklich auch auf das Team passen. Und da hilft es natürlich, wenn man viele kennt. Aber generell ist was bei uns sozusagen immer ein Fix Starter ist, sind so so Methoden, die in Richtung Beobachtung oder empathisches Gespräch gehen, also wirklich tiefgehende Gespräche mit den potenziellen Kunden, mit den Nutzern der Software zu führen, weil man eigentlich nur so herausfinden kann, was die Leute wirklich wollen. Also wenn es sozusagen eine Methode gibt, die Fix-Starter ist, dann sind es auf jeden Fall Beobachtungen und empathisches Gespräch. Das sind wirklich so ganz zentrale Methoden. Ohne die gibt's bei uns fast keinen Workshop.

00:26:40
 Igor Miladinovic: Vielen Dank, Peter, für diese Einblicke in Design Thinking und auch, dass du einige von deinen Erfahrungen von dir und deiner Frau mit uns geteilt hast. Mehr über das Thema kann man auch auf der Website von Ingrid und Peter finden. Das ist gerstbach.at. Dort kann man auch alle diese Bücher anschauen. Für unsere Studierenden bietet sich das Buch Design Thinking in IT Projekten an. Wir haben auch einige Exemplare im Sekretariat die man sich ausleihen kann und was ich noch empfehlen kann, es gibt auch einen Podcast zum Thema Design Thinking von Ingrid und Peter. Es gibt sehr viele Folgen, vielmehr als von diesem Podcast. Es gibt eine sehr angenehme Vorstellung von Themen auch eine sehr angenehme Länge. Ich glaube so im Schnitt 20 bis 30 Minuten pro Folge. Es freut mich, Peter, dass du heute mit uns warst. Und es freut mich auch, dass viele unseren Zuhörerinnen und Zuhörer dabei waren. Und wir hören uns wieder in der nächsten Folge.

00:27:40
 Peter Gerstbach: Ja, vielen Dank fürs Einladen. Und ja, wenn es Fragen zu Design Thinking gibt, können sich gerne auch eure Hörer bei uns melden.

00:27:48
 Sigrid Schefer-Wenzl: Vielen Dank. Bis zum nächsten Mal.