Transkript

Software is for Humans

Was ist eigentlich UX?

Dahin gehen, wo es brennt: Robert Glaser und Leonardo Ramirez sprechen in dieser Folge über die Interaktion zwischen Mensch und Maschine und darüber, was User Experience eigentlich bedeutet. Dabei streifen sie etliche Methodiken und diskutieren, welche davon konkret in Projekten einsetzbar sind und welche neue Brände verursachen.

Zurück zur Episode

Transkript

Robert Glaser: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Ich bin Robert und sitze hier mit Leo, meinem lieben Kollegen, in unserem Berliner Büro. Der letzte Podcast, den ich aufgenommen habe, ist jetzt leider schon ein bisschen her, das war im Sommer. Wir sitzen im selben Konfi, wo wir auf den Landwehrkanal gucken können. Im Sommer sind da noch schön die Schwäne vorbei geschwommen, jetzt sind sie wahrscheinlich erfroren, hier sieht man überhaupt keine Lebewesen mehr, auch keine Menschen. Das Wetter ist echt zum Kotzen gerade. Nichtsdestotrotz haben wir uns jetzt zurück gezogen, die Heizung auf 5 gedreht und werden heute mal über was ganz interessantes und anderes reden, als was es sonst bei uns im Podcast zu hören gibt, nämlich: Software und Menschen. Das ist ein riesiges Thema, und wie bereits gesagt, ich habe heute Leo zu Gast. Leo, vielleicht kannst du dich kurz vorstellen?

Leonardo Ramirez: Ja, hallo Robert, danke, es freut mich, mit dir hier beim Podcast zu sitzen, an diesem kalten Tag, wo alles gefroren ist auf dem Kanal. Ich bin Senior Consultant bei INNOQ, ich bin seit drei Jahren unterwegs, ich habe einen relativ langen Background, habe vieles im Leben gemacht.

Robert Glaser: Du bist drei Jahre bei INNOQ unterwegs, du bist ja schon viel länger dabei.

Leonardo Ramirez: Ja, also ich habe schon Mitte der 90er engineering mit Interesse an Informatik studiert. Ich habe in Chile studiert, aber dort gab es nicht die Möglichkeit Informatik als eine einzelne Sache zu studieren, sondern das war zusammen mit dem electrical engineering gekoppelt. Das heißt, man musste da alles Mögliche lernen, harte Mathematik und Calculus und alles. So drei oder vier Jahre, dann konnte ich endlich Informatik machen, was mich mehr interessiert hat. Ich habe also einen ziemlichen technical background, aber gleichzeitig ist diese ganze Dotcom-Blase und so weiter entstanden, und ich hatte immer Interesse an diesem human aspect. Ich dachte, ja, Informatik ist etwas alltägliches, etwas, das in einem human context eingebettet ist.

Robert Glaser: Sie dient ja eigentlich auch dem Menschen, das vergisst man leider irgendwie zu oft.

Leonardo Ramirez: Genau, und es ist ein trockenes technisches Thema, das mitten im Kontext menschlicher Umwelt zu einem Artefakt geworden ist, und das fand ich interessant. Und deswegen bin ich nach Deutschland gekommen.

Robert Glaser: Ah ok!

Leonardo Ramirez: Ich wollte in dem Bereich forschen und ich habe mich auf eine Stelle in einem Frauenhofer Institut beworben und auch begonnen, wo ich zu human computer interaction geforscht habe, etwa acht, neun Jahre. Dort habe ich auch promoviert, in einem Bereich, wo normalerweise nicht viele Computer waren, wie emergency response, Feuerwehr im Einsatz im Feuer.

Robert Glaser: Was war das Thema deiner Promotion?

Leonardo Ramirez: Ich habe zusammen mit anderen Kollegen in Sankt Augustin bei Bonn ein Navigationssystem für Feuerwehren entwickelt, nämlich für die Feuerwehr, die Erkundungsmissionen macht, also diejenigen, die ins Feuer gehen, also in ein brennendes Haus rein und Leute retten. Und das ein ziemlich komplizierter Kontext für die Informatik: alles brennt, das heißt Rechner müssen feuerfest sein, und es ist auch eine sehr komplexe -

Robert Glaser: - und Menschen wahrscheinlich auch!

Leonardo Ramirez: Ja genau! Also, es ist eine sehr komplexe Aufgabe, sich in so einem Kontext zu orientieren. Ich bin rein gegangen, wie komme ich jetzt wieder raus. Und da haben wir Systeme entwickelt, die diese Navigation unterstützt haben.

Robert Glaser: Quasi indoor navigation?

Leonardo Ramirez: Genau. Wir haben ein System entwickelt, wo etwas, dass du dir wie so eine Perlenkette oder breadcrumbs vorstellen musst, deployed worden sind. Wir haben diese breadcrumbs mit Mesh-Netzwerken augmentiert, sozusagen, damit sie miteinander kommunizieren können und unterschiedliche Information nach außen bringen können oder auch unterstützend für die Kommunikation der Feuerwehr geholfen haben.

Robert Glaser: Das ist mega interessant. Wann war das, wie viele Jahre ist das her?

Leonardo Ramirez: Das habe ich zwischen 2006 und 2010 gemacht.

Robert Glaser: Okay, lange her. Das ist interessant, weil heute ja die großen Konzerne erst – ich will nicht sagen tröpfchenweise, aber stufenweise – mit so Sachen um die Ecke kommen. Apple, Google, die machen jetzt alle indoor maps für Malls und Flughäfen. Und die Navigation in Indoor-Räumen kann ja nicht rein über GPS laufen, sondern muss ja auch irgendwie über meshing und beacons und was weiß ich augmentiert werden, und dann ist das ja quasi die Grundlage, die du dafür damals gemacht hast.

Leonardo Ramirez: Genau, also das war ein Großprojekt, da gab es – also mein Ziel war eher der human aspect, da habe ich mit der Feuerwehr Köln und dem Institut der Feuerwehr Nordrhein-Westfalen gearbeitet, um diesen human aspect in das Projekt zu bringen. Andere Partner, die auch Forschung im Bereich Sensornetzwerke gemacht haben, oder auch Meshnetworks, indoors position und diese Themen, das war alles zusammen gekoppelt.

Das heißt, wo wir wieder in dieses Thema software is for humans rutschen, wir haben schnell bemerkt, dass dieses indoor mapping oder indoor localisation nicht genug war für die komplexe Aufgabe der Feuerwehren. Die ersten Ideen waren natürlich sehr träumerisch. Wir dachten, ok, wir machen so eine Karte, die auf einem head-mounted display alles zeigt, wo man hin muss, und mit Pfeilen zeigt, in welche Richtung man muss. Wenn man mit den Feuerwehrleuten spricht, merkt man ganz schnell: „Ja, das klingt auch super, das ist so auch sehr cool, aber ich habe so eine Maske, die ziemlich klein ist. Ich da in diese Maske eingeschlossen. Wenn du mir zusätzlich noch so einen Bildschirm da dran bringst, dann habe ich so 30% von meinem vision field überdeckt.“ Und da habe ich damit angefangen, dass man eigentlich erst verstehen müsste, was die machen und wie die das machen. Und dann kann man erst mit Design und mit Konzeptideen kommen und ganz langsam von diesen futuristischen Ideen, mit Input von der Feuerwehr und Input von Experten, zurück zu sehr einfachen Systemen kommen, die tatsächlich besser waren für die Aufgabe, die uns präsentiert wurde.

Robert Glaser: Das ist interessant, weil das im Prinzip nichts anderes ist, als was heute oftmals leider noch viel zu oft passiert, nämlich – wir sind ja beide Techniker, wir bewegen uns ja jetzt nicht über irgendjemanden hinweg, wenn wir das sagen, aber ich finde schon, dass unsere Branche zu großen Teilen immer noch dazu tendiert, Hypothesen, die sie hat, für gegeben hinzunehmen, ohne das mit Nutzern zu validieren. Und das, was du gesagt hattest, ist ja ein super Beispiel: Ihr hattet eine visionäre Idee, dachtet aus eurer Perspektive heraus, denn ihr ward ja keine Feuerwehrleute, „das braucht man, das brauchen die“. Wenn man einfach mal mit denen spricht, da braucht man ja wahrscheinlich noch gar keine gigantischen Forschungsarbeiten zu leisten, und Recherchearbeit zu machen, dann erfährt man sehr schnell „Ja, wäre schön, aber unser Alltag sieht folgendermaßen aus … Also was wir eigentlich brauchen ist ganz anders“. Das ist ja jetzt schon länger her und eigentlich ist es ähnlich in allen Kontexten, in die man so reinguckt.

Leonardo Ramirez: Ja. Also, ich denke, dass, wenn man so als Informatiker in einem gewissen Maße von technischem Wissen fasziniert [ist], und man träumt natürlich davon, alle Technologien da rein zu bringen. Dieser Traum ist natürlich häufig übertrieben –

Robert Glaser: Meint du, das ist häufig egoistisch, wie wir sind, oder hat das andere Gründe?

Leonardo Ramirez: Es kann vielleicht auch sein, dass es so einen spielerischen Aspekt birgt. Es gibt Technologie, die ist grundsätzlich cool, ja, also wo man denkt, das ist schön gebaut und cool oder –

Robert Glaser: Ich will das mal ausprobieren.

Leonardo Ramirez: Ja, ich will es ausprobieren oder es ist elegant, wie das gebaut ist, es toll und so weiter, ich würde das gerne im Einsatz sehen.

Robert Glaser: Glaubst du, uns interessiert oft mehr das Werkzeug an sich als das Problem, das wir damit lösen wollen?

Leonardo Ramirez: Ja, vielleicht, kann sein, aber ich will nicht sagen, dass wir so egoistisch sind, sondern dass wir so fasziniert davon sind. Dann vergisst man ganz schnell, dass wir als Designer unterwegs sind und nicht nur im Sinne vom visual oder product design, sondern Technologie-Design wird hier auch gestaltet. Und eigentlich sind wir eine Stellvertretung von unseren Nutzern. Und bei dieser Aufgabe, die wir erfüllen, sollte man immer wieder denken, „ja, das Ding hier ist, so cool wie ich das finde, ist nicht für mich, es ist für andere Menschen“. Und deswegen muss man immer diese Nutzer- und Zielgruppe im Auge behalten, weil letztendlich, am Ende des Tages, wenn ich fertig mit der Technologie bin, dann gebe ich das an den Benutzer, und der muss damit klar kommen. Und das so einen menschlichen Aspekt, den man beachten muss.

Robert Glaser: Was glaubst, warum das immer so selten passiert, dass wir mit dem Benutzer in Kontakt kommen, um das zu validieren? Ist uns das zu anstrengend? Ist das nicht in unserem Interessengebiet? Oder wissen wir vielleicht einfach nicht, was Methodiken und Mittel sind, mit denen man das sinnvoll tut?

Leonardo Ramirez: Also es gibt wahrscheinlich mehrere unterschiedliche Gründe, und je nach Kontext ändern sich diese Gründe, aber ich glaube, man unterschätzt die Rolle, die diese Aspekte im Erfolg einer Technologie spielen. Man denkt, „ja, ich bin auch selber Benutzer, also kann ich einschätzen, was die brauchen“. In dieser Perspektive verpasst man ganz viele Sachen und Aspekte, die beim Benutzer stattfinden, wie social context, oder eben die Umstände der Benutzung. Die werden auch vergessen. Man denkt, man versteht das, aber es ist häufig nicht der Fall, und dadurch unterschätzt man, welche Rolle das alles spielt.

Robert Glaser: Ja, das kann ich mir vorstellen. Du hast gesagt, du hast damit jetzt schon vor vielen Jahren begonnen. Welche Methodiken gab es denn damals – damals, es sind ja jetzt auch keine Jahrzehnte, aber in IT-Jahren ist es ja schon ganz schön lang – welche Methodiken gab es damals und welche gibt es heute? Und was davon ist vielleicht noch gleich, was kann man heute weglassen, weil man weiß, das funktioniert nicht so gut oder das ist zu viel Arbeit, kannst du dazu was sagen?

Leonardo Ramirez: Ich denke, was das Interessante ist, oder wie man das zusammenfassen könnte, ist das Entstehen vom X in UX, und das ist eine schöne Entwicklung. Am Anfang hatten wir Benutzer, die waren auch Techniker, die haben selbst die eigenen Werkzeuge entwickelt, wie die command line und so weiter, die kannten eins zu eins die Maschine, die wussten, woran es liegt, wenn etwas nicht klappt. Die waren sehr nah am System.

So langsam merkte man, es gibt viele Fehler, die statt finden, die man vermeiden könnte, wenn man ein bisschen auf diesen human aspect achten würde. Und dann sind die ganzen human factor Aspekte wie Ökonomie – wie zum Beispiel, Kommentare sollten eigentlich knapp, kurz, intuitiv sein, damit man nicht so viele additional flags oder sowas hat. Also, das war so ein erstes Paradigma, eine auf ökonomische Aspekte hin definierte Interaktion. Dann ist durch die Entstehung von KI, also die erste Welle von artificial intelligence, da hat man angefangen, die Rechner als kognitive Systeme zu verstehen, also als ein System, das eine eigene Welt und Kontext hat, und dass die Benutzung von Rechnern eigentlich die Interaktion zwischen zwei kommunikativen Systemen ist. Also, ich bin als Benutzer ein kommunikatives System und der Rechner ist das andere kommunikative System und wir interagieren miteinander. Und human computer interaction war das Konzept für die Interaktion zwischen den zwei Systemen und es wurde ganz viel Energie –

Robert Glaser: Das kam damals raus, dieses Konzept?

Leonardo Ramirez: Ja, das CHCI. Und dann hat man relativ viel Energie in die Optimierung dieser Interaktion investiert. Also Stichwort Oberflächen, da ist auch das Konzept der Interfaces entstanden. Also, das Interface zwischen beiden Systemen sollte optimiert werden. Und da wurde auch ganz viel über Usability gemacht. Denn wenn man auf Usability achtet, dann macht man auch diese Interaktion effizienter. Wenn das System usable und einfach zu bedienen ist, wird diese ganze Interaktion effizienter und dadurch auch den Umtausch von Daten zwischen Maschine und Mensch, und umgekehrt. Der funktioniert flüssiger und besser und so weiter.

Und irgendwann haben die Forscher und auch die Industrie bemerkt: Ja, das ist interessant was man mit Usability machen kann, auch mit diesen ganzen naturwissenschaftlichen Methoden wie Statistik und mit Experimenten zu Messbarem, aber das vermisst auch ganz viele Aspekte, die nicht messbar sind, aber die trotzdem eine wichtige Rolle spielen.

Robert Glaser: Diese Aspekte wurden zu der Zeit in der Forschung noch gar nicht berücksichtigt.

Leonardo Ramirez: Ja, also man hat sich dann gefragt, was ist mit Aspekten wie happiness? Also, Aspekte die mit der Attitüde des Benutzers zu tun haben, also, „bin ich glücklich“, „bin ich cool“, also den joy of use. Also, mit den iPhones ist es ein wichtiger Aspekt, dass es cool ist, ja, also, dass Leute iPhones deswegen, weil sie cool sind, haben wollen. Und dann verkauft man natürlich mehr davon. Und da ist wohl langsam dieses X entstanden, im Sinne von experience. Es geht um viel mehr als eine Kopplung zwischen zwei Systemen, es geht um ein Erlebnis: Ich benutze das System in einem gewissen Kontext, in einer gewissen social environment, und da will man auch diese experience gestalten. Und dadurch, dass das X in UX entstanden ist, ist nicht nur wichtig, dass ich das System effizient benutze, sondern dass das ganze Erlebnis von der Benutzung dieses Artefakt.

Robert Glaser: Also, das X bezieht ja viel mehr Aspekte ein, als die reine Benutzbarkeit des Systems, sondern auch noch eben weiche Kriterien, wie: sind die Nutzer glücklich, empfinden sie etwas, sind sie ästhetisch angesprochen von einem System, wie wirkt dieses System indirekt in ihrem privaten und beruflichen Umfeld auf sie und auf andere. Also, dieses X macht das alles mit einem Mal viel größer.

Leonardo Ramirez: Ja genau, richtig. Da ist dieser experience aspect rein gekommen. Diese Evolution der Paradigmen der Benutzung von Systemen hat letztendlich eine Entwicklung von verschiedenen Methoden gebracht, die heute noch eine Rolle spielen. Also, man darf nicht alle trennen nach entweder-oder, sondern es geht um das verschiedene Verständnis von human computer relation sozusagen, und da kommt alles zusammen. Es gibt Methoden, die den Fokus auf den Usability-Aspekt legen, mit klassischen Usability-Labor-Experimenten, bei denen Benutzer eine Aufgabe bekommen. Da wird gemessen, wie schnell das Erledigen dauert, oder ob die das schaffen oder nicht.

Und es gibt auch Methoden, die direkt in die experience greifen, wie zum Beispiel partizipatives Beobachten, wo überwacht wird, wie Benutzer die Technologie benutzen, und zusammen mit user research dann Notizen machen und analysieren und Interviews durchführen, wo zum joy of use gefragt wird. Also eine ganze Reihe von Methoden sind durch diese Entwicklung entstanden, die alle interessant sind und eine Rolle spielen.

Robert Glaser: Also, zusammenfassend kann man sagen, es gibt sehr viele Methoden. Es gibt einen Bereich von Methoden der sehr datenorientiert ist, sehr hart datenorientiert ist und einfach reine Ergebnisse beobachtet, wie zum Beispiel eine Zeitmessung, also, wie lange braucht diese Person für die Aufgabe, die mit dieser Software zu lösen ist. Und das ist immer die gleiche Aufgabe und damit kann man wahrscheinlich statistische Verfahren dann anwenden aufgrund dieser Datenmenge.

Dann gibt es, hast du gesagt, weichere Verfahren, die ich aber auch brauche, um bestimmte Aspekte eben einzufangen, für die mir diese datengetriebenen harten Verfahren nicht ausreichen würden. Ich kann zum Beispiel mit datengetriebenen Messungen oder mit Eye-Tracking – oder was auch immer, es gibt ja ganz viele, da würden wir wahrscheinlich den Rahmen sprengen wenn wir auf diese Verfahren alle eingehen – aber die helfen mir ja nicht dabei, Dinge heraus zu finden wie joy of use, richtig? Die Person, wie findet die das denn gerade, was die da sieht? Spricht die das ästhetisch an? Ist die „glücklich“, das zu benutzen? Dafür sind eher weiche Methodiken wie zum Beispiel Interviews wahrscheinlich gut.

Leonardo Ramirez: Ja, richtig. Es gibt qualitative Methoden, also Methoden, die auch die Qualität der experience erfassen. Und es gibt quantitative Methoden, die Daten sammeln und die auch einen globalen Überblick schaffen können. Es gibt auch unterschiedliche Momente im Entwicklungsprozess eines Systems, wo diese Methoden relevant sind, und da gibt es Methoden, die eher so eine generative Rolle spielen. Also solche, die eher Ideen fördern, die bei der Suche nach mögliche Lösungen von einem System helfen, wo Brainstorming oder auch focus groups benutzt werden, wo man die User befragt.

Robert Glaser: Oder man konfrontiert die Nutzer mit einem sehr frühen Entwurf, vielleicht ist das noch gar keine echte Software, oder was auch immer, und ich weiß, ich habe eine Hypothese und ich will einfach mal gucken, wird die erfüllt, oder sagen die Nutzer: was macht das denn da, ich würde das so und so machen, das geht so viel einfacher, und warum muss ich denn jetzt hier das und das machen? Um sowas abzuklopfen.

Leonardo Ramirez: Ja, und vielleicht schon zuvor. Wir haben hier einen context of use, wir haben eventuell ein Problem, wir haben keine Ahnung was welche Lösung bieten kann –

Robert Glaser: Wir haben noch nicht einmal eine Lösungsidee?

Leonardo Ramirez: Ja genau, aber es gibt trotzdem ganz viel implizites Wissen, das diese Gruppe von Menschen hat. Und es gibt Strategien, wie zum Beispiel experience prototypes, wo man ein Artefakt einbringt, das einen Anreiz birgt und wo die Leute sich sagen, das und das könnte man anders machen. Das produziert Ideen. Und es gibt Verfahren, die eher so evaluativ sind, wie zum Beispiel iterative prototyping. Dabei bringt man ein ganz frühes Konzept in einen Kontext und dann beobachtet oder benutzt man das zusammen mit der Zielgruppe, und entwickelt das Konzept daraus weiter. Es gibt diese generative bis generative Art von Methoden, die auch da zum Einsatz kommen, je nachdem, welche Probleme man lösen will.

Robert Glaser: Und weil es eben so viele Methodiken in so vielen unterschiedlichen Punkten in der Zeit gibt, hat unsere Branche wahrscheinlich auch so ein paar Methodiken mal verbunden, und Ansätze versucht zu schaffen, die vielleicht auch wirtschaftlich sind, nicht wahr? Die Erfolg versprechen und nicht wahnsinnig viel Geld und Zeit kosten. Wahrscheinlich sind Methoden aus dem Design Thinking oder Design Sprints vielleicht solche Ansätze, wo man sagt, wir vermeiden die ganz frühen Methoden, wo wir noch keine Idee haben, weil uns das zu viel Aufwand, zu viel Zeit kostet noch nach Ideen mit den Nutzern zusammen zu suchen. Sondern wir entwerfen selbst eine Idee, benutzen verschiedene Methodiken, um diese Idee wirklich zu einer guten Idee zu machen, wie das Team denkt, und werfen die dann aber möglichst früh den Nutzern vor, damit wir eben ganz früh – also so früh wie möglich – feststellen, taugt die was, oder nicht. Aber der Design Sprint ist ja nur eine Möglichkeit, sowas zu tun, man könnte auch viel früher, oder viel später ansetzen. Man muss immer einen Kompromiss finden.

Leonardo Ramirez: Ich habe das auch erlebt, dass man mit frühen Ideen, egal wie reif die sind, die funktionieren immer so wie ein triggering artefact. Also, wir haben das auch mit den Feuerwehrleuten gemacht am Anfang, wir dachten, ok, die Idee wäre so eine Perlenkette: Wie können wir die Feuerwehrleute dazu bringen, dass sie in diesem Konzept denken? Was wir gemacht haben – ich weiß nicht, ob du das noch kennst – da gab es sogenannte throwies, so eine Uhrbatterie, so eine runde Batterie mit Knopfzellen.

Robert Glaser: Ein wunderbares deutsches Wort!

Leonardo Ramirez: Und, genau, mit einer LED, du kannst die direkt mit Klebeband zusammen kleben, das leuchtet, ja? Mega einfaches Design. Wir haben so eine Kiste mit durchsichtigen Plastikkugeln gemacht, etwa 200 davon in verschiedenen Farben. Und dann sind wir zu einer Trainingshalle, ein leeres Gebäude, wo verschiedene Übungen gemacht werden, und haben dort Feuerwehreinsätze simuliert, und sind einfach mit dieser Kiste durch die Gegend gelaufen. Und die haben das einfach verwendet -

Robert Glaser: Die haben die ausgelegt auf den Boden, damit die den Weg zurück finden?

Leonardo Ramirez: Genau. Aber einfach sich Benutzungen für dieses Konzept überlegen – am Anfang gab es natürlich keine Ideen. Da meinte ich, man könnte erstmal alle durchsuchten Zimmer markieren. Und dann haben wir das probiert, das funktioniert gut, da könnten wir vielleicht verschiedene Farben für verschiedene Situationen benutzen. Und dann hat sich so langsam eine Idee entwickelt wo wir Namen und Situationen für diese Markierungen gefunden haben. Und dieser extrem einfache erste Prototyp hat uns eine Grundlage für Ideen gegeben, woher wir später die Konzepte für das System entwickelt haben.

Robert Glaser: Ist das so ein participatory design, wenn man quasi eine ganz frühe Idee möglichst früh ins Spiel bringt mit den Nutzern, und die Nutzer dann teilhaben an der Weiterentwicklung dieser Idee?

Leonardo Ramirez: Ja genau. Dann ist der Benutzer nicht nur eine Quelle von Informationen, sondern auch Designer, der auch hilft, Ideen einbringt. Und das war für uns auch wichtig, denn das war ein Kontext, wo wir eigentlich nicht viel über die Benutzer – also ich könnte nicht sagen, „ich als Feuerwehr würde es so und so machen“, weil ich keine Feuerwehr bin. Und deswegen muss man den Benutzer auch in den Designprozess als Designer bringen. Nicht nur als Quelle von Informationen, nur als morschen Gegenstand, sozusagen, sondern auch als berechtigten Designer.

Robert Glaser: Auf jeden Fall. Das ist aber natürlich wieder eine Kunst für sich, den Nutzer so einzubringen, dass man nicht nur seine Ideen bekommt, sondern dass man seine Reaktionen bekommt, die sind auch extrem interessant – also daran bin ich auch hauptsächlich interessiert – aber auch in den gestalterischen Prozess einzubeziehen, ohne dass die Nutzer in diesen ästhetischen Designmodus abdriften. Denn gerade an User Interfaces, und auch digitale User Interfaces, sind ja viele Nutzer auch automatisch ästhetisch interessiert. Weil, wenn Menschen etwas vor sich haben, reden die darüber. Und die Kunst ist es ja, irgendwie mit dem Nutzer so darüber zu reden, dass ich möglichst funktionale Reaktionen oder funktionalen Input von ihnen bekomme. Aber nicht „ja ich mag die Farbe Blau nicht, könnte man das nicht grün machen, Grün gefällt mir besser“. Sowas ist dann wahrscheinlich die Kunst das weg zu moderieren, weil das andere Feedback ist viel essentieller für uns.

Leonardo Ramirez: Ja und ich finde, dass da auch wieder irgendwo dieses Menschliche eine Rolle spielt, weil, damit der Benutzer das erlaubt, da braucht man ein großes Vertrauen. Und das wird auch aufgebaut. Es gibt auch Methoden womit man so eine Community, wo Benutzer und Designer zusammen arbeiten, wo es genug Vertrauen gibt, sodass man dem Benutzer zeigen kann: „pass auf, es ist eigentlich besser, wenn wir es so machen“. Und durch dieses Vertrauen ist er auch bereit zu sagen: „wahrscheinlich hast du recht“!

Robert Glaser: Ja, das absolut. Das Vertrauen der Nutzer, also es gibt ja auch negative Methodiken, um das Vertrauen der Nutzer zu missbrauchen, das führt uns ein bisschen in die Richtung dark patterns: Wie bekomme ich Dinge von Nutzern, ohne dass sie wissen, dass sie mir die geben? Aber ich glaube, da können wir noch einmal zu vielen der Themen, die wir jetzt besprochen haben, eigene Folgen machen – sollten wir vielleicht auch tun, hast du Lust?

Leonardo Ramirez: Es ist ein extrem breites und komplexes Thema, wenn es um Menschen und Technologie zusammen geht, und es gibt hunderte von interessanten Themen, die man besprechen kann.

Robert Glaser: Ja eben, es gibt so viele interessante Themen, und für mich ist auch immer sehr interessant und vor allem auch wichtig – viele unserer Hörer arbeiten ja auch in Projekten – wie kriegen wir das so destilliert, dass wir die Sachen, die wirklich Erfolg versprechen, für uns nutzen können, und wie erkennen wir Dinge, die vielleicht viel zu aufgeblasen sind? Die im typischen Projektalltag vielleicht nicht so zweckdienlich sind, wie können wir ein Kunst entwickeln, die wegzulassen.

Leonardo Ramirez: Das ist tatsächlich eine Kunst, denn genauso, wie wir von Technik fasziniert sind, ist user research auch faszinierend, bei allen möglichen Aspekten, die sowas anbietet, wie die experience. Da muss man an irgendeinem Punkt abwägen, denn user research kann relativ teuer werden: Man muss ganz viel aufsetzen, user groups finden, und es gibt auch Methoden, die gigantisch vorbereitet werden, wo ganze Familien monatelang interviewt werden. Aber ich glaube, die Kunst ist, dieses Gleichgewicht zu finden, wo man im Team jemanden hat, der immer für den Benutzer spricht. Der erkennt, genau hier gibt es eine Lücke, hier muss man mit einer von diesen Methoden zum Benutzer gehen und die Information holen, die jetzt für diese Frage oder für diese Hypothese noch fehlt.

Robert Glaser: Und dass die anderen im Team, Techniker, Administratoren, Designer, dann auch den Mehrwert direkt sehen, das schafft ja auch Verständnis im Team für UX, warum das wichtig ist und was das vor allen Dingen bringt, wenn man sofort sieht: oh krass, daran habe ich gar nicht gedacht, und das Feedback der Nutzer haben wir jetzt in drei Stunden bekommen, nicht in drei Jahren.

Leonardo Ramirez: Ich denken das ist auch wichtig, dass dieses UX ein Teil vom ganzen Team sein muss, das zu Entwickler, PO auch UX researcher dabei sind, denn es ist dieser daily exchange bei dem der Entwickler eine wichtige Frage hat, wo man nicht mit den existierenden Informationen arbeiten kann, sondern zum researcher geht und fragen kann und dann auch schnell eine Antwort erhält. Das finde ich wichtig, dass es so ein Teil des ganzen Teams ist.

Robert Glaser: Und diese Methodiken kann man ja auch prima verteilen im Team, das muss ja gar nicht die research person geben im Team, das kann ja auch einer der Techniker, der interessiert ist, übernehmen. Das kriegt man ja recht schnell erklärt, das Konzept eines Nutzerinterviews beispielsweise, oder was auch immer. Am wichtigsten ist, glaube ich, immer, dass die Leute Interesse daran haben, und wenn die Interesse daran haben, dann ist es egal, wo die herkommen oder was die für eine Ausbildung haben, das kann „jeder“.

Leonardo Ramirez: Ja, ich glaube, das kann man auch lernen und ein bisschen verteilen.

Robert Glaser: Ich glaube das ist ein schönes Schlussfazit. Wir haben so viele Themen jetzt leider nur angerissen, wir könnten noch bestimmt 60 Folgen dazu drehen. Vielleicht sollten wir aber mindestens 30 mal ins Auge fassen.

Leonardo Ramirez: Ja, ich denke, wir könnten noch eine Nach-Folge machen.

Robert Glaser: Super, dann lass uns das mal festhalten, und dann machen wir an dieser Stelle einfach mal Schluss für heute, und bewegen uns Richtung Mittagessen würde ich sagen, oder?

Leonardo Ramirez: Ja, das ist eine gute Idee!

Robert Glaser: Alles klar. Dann danke dir und bis bald!

Leonardo Ramirez: Es hat mich gefreut!

Robert Glaser: Tschüss!

Leonardo Ramirez: Tschau!