Transkript
Lucas: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts. Heute sprechen wir über User Experience Design. Dafür habe ich mir den Andreas eingeladen. Hallo, Andreas.
Andreas: Hey.
Lucas: Andreas ist ein Experte für User Experience Design. Er hat sich damit schon in seiner Promotion beschäftigt. Das war sein Promotionsthema. Er arbeitet als Requirements und Usability Engineer bei uns und beschäftigt sich eigentlich schon seit seinem Studium damit, wie man Software für Benutzer:innen besser gestalten kann. Und deswegen ist er, glaube ich, die perfekte Person, um mir alle meine Fragen zu diesem Thema zu beantworten. Aber bevor wir das machen, wir haben drei Worte da stehen: User Experience Design. Wir fangen erst mal mit dem ersten Teil an, User Experience. Was ist denn überhaupt User Experience?
Andreas: User Experience macht eigentlich aus einem guten Produkt ein sehr gutes Produkt. User Experience macht mehr als das, was man als Usability Design vielleicht kennt. Wir haben als Usability Design Dinge, die ein Produkt können muss. Die Fragestellung: Warum gibt es überhaupt ein Produkt? Kann mein Nutzer das erreichen, wofür er das Produkt eigentlich gekauft hat oder überhaupt nutzt? Kann der Nutzer effizient mit dem Produkt arbeiten? Muss er sich viele Gedanken machen, um das nutzen zu können? Braucht er viele sonstige Ressourcen? Kann er sich gut daran erinnern, wie er mit dem Tool arbeitet oder muss er ständig in einem Handbuch nachschauen oder sich zeigen lassen, wie es geht? Das sind diese harten Kriterien, die eigentlich jedes Produkt mitbringen muss. Das erwarten Nutzer auch, sonst suchen sie sich ein Konkurrenzprodukt. Und die User Experience geht darüber hinaus und sagt: Gut, der Nutzer hat bestimmte Erwartungen, die ein Produkt erfüllen muss. Eben so was wie Effektivität, kann er sein Ziel erreichen? Und Effizienz, kann er es schnell und ohne viel Aufwand erreichen? Die User Experience spricht darüber hinaus die emotionale Ebene an. Man hat sich irgendwann gedacht: Okay, es steckt in Software generell mehr als nur diese Zweckmäßigkeit oder die Gebrauchstauglichkeit. Benutzer wie du und ich haben nicht einfach einen normalen technischen Eindruck von Produkten. Wir haben irgendwelche Emotionen, ob wir das wollen oder nicht. Und genau die Gestaltung von diesen Emotionen, natürlich die positive Gestaltung von den Emotionen, das ist, was User Experience Design macht oder versucht. Und wenn man es gut macht, macht man den Nutzer einfach glücklich. Beim Usability Design haben wir das Problem, der Nutzer kann eigentlich nur schlecht gelaunt werden, auch wenn wir gute Usability herstellen. Der Nutzer erwartet gute Usability. Wenn die nicht gegeben ist, ist er sauer oder einfach unzufrieden. Wenn alles gut da ist, an Usability, dann ist er aber nicht glücklich, er sieht nur seine Erwartungen erfüllt und das kann uns nicht reichen.
Lucas: Das bedeutet, Usability ist quasi die Grundschwelle, über die wir drüber müssen, weil wenn wir drunter sind, dann sind die Leute unzufrieden.
Andreas: Richtig.
Lucas: Okay, gut. Und du hast dich auch schon an der Universität damit beschäftigt. In welchem Bereich ist denn User Experience angesiedelt? Ist das ein Teilgebiet der Informatik oder wo muss ich das einordnen?
Andreas: Das ist ein ziemlich querschnittliches Thema. Ursprünglich, das ist schon ausgehend von 1986 und noch früher. Ein Psychologe, Don Norman, hat diesen Begriff entwickelt, identifiziert oder einfach so genannt. 1986 war aber so, wo man gesagt hat: Softwareentwickler entwickeln nicht für sich selbst. Sie entwickeln auch nicht für andere Informatik Experten oder für technisch-denkende Leute. Nutzer sind die, für die Software entwickelt wird. Und es war damals eine Revolution zu denken: Okay, wir Entwickler müssen eigentlich während unserer Entwicklung die komplette Zeit den Nutzer im Kopf haben, für den wir das Ganze tun und nicht denken, wie wir das toll finden oder wie wir das gut nutzen können, kann das jeder gut nutzen. Und wir sollten dann nicht erstaunt sein, wenn das nicht so ist, weil der Nutzer einfach nicht der Experte für das Tool ist, das wir entwickeln. Er ist jemand, der ganz anders denkt, ganz anders handelt und für den das Produkt einfach was völlig Neues ist. Nach 1986 hat sich diese ganze Denkweise weiterentwickelt. Das wurde User-centered Design einfach genannt, weil eben wichtig war, dass der Nutzer derjenige ist, der im Zentrum der Entwicklung steht. Dann hat man angefangen, Personas zu entwickeln, also fiktive Darstellungen von Nutzern, für die wir entwickeln. Und dann kam diese ganze Emotionalität mit rein, 1994, 1995. Don Norman war auch da der ausschlaggebende Mensch. Er hat für Apple gearbeitet, er war Vizepräsident für die Advanced Technology Group bei Apple. Er war Manager bei HP und er ist auch heute noch Professor für Kognitionswissenschaften. Er hat in Psychologie promoviert, er ist Informatiker und Berater, Mitbegründer der Nielsen Norman Group. Er hat genau diese Schnittstelle zwischen Informatik und Psychologie. Und deswegen hat er sich auch sehr früh Gedanken gemacht, wie man beides zusammenbringt bzw. dass es ganz viele psychologische Aspekte innerhalb der Informatik bzw. innerhalb der Nutzung von Software gibt.
Lucas: Du hast jetzt gerade schon den Begriff Human-centered Design erwähnt. Ich kenne jetzt auch noch die Begriffe User-centered Design. Magst du einmal kurz erklären, was das beides ungefähr ist?
Andreas: Ich habe den Begriff User-centered Design benutzt. Das ist nur diese Denkweise. Wir denken an den Nutzer und nicht an technisch versierte Leute. Das ist noch kein Prozess. Das ist einfach diese andere Perspektive, die wir als Entwickler einnehmen sollten, um gute Produkte zu entwickeln mit einer hohen Usability. Human-centered Design ist das, was eigentlich lange nachdem der Begriff User Experience Design in der Welt war, entstand. Einfach um noch mal klar zu machen: User Experience ist etwas, das wir gestalten können. Und wenn wir etwas gestalten wollen, sollte es eine Art Rahmen geben, in dem wir uns bewegen können. Das ist kein zwangsläufiger Prozess. Diesen Rahmen hat man human-centered Design genannt, weil es auch einfach nicht nur um User geht, für die wir arbeiten. Es geht auch um das gesamte Team, mit dem wir arbeiten, um am Ende den Nutzer zu begeistern. Das ist das Ziel. Wir stellen ihn nicht nur zufrieden wie beim Usability Design. Wir begeistern Nutzer, indem wir ihn auch auf emotionaler Ebene abholen.
Lucas: Auf die emotionale Ebene wollen wir noch mal ein bisschen später drauf eingehen. Aber bevor wir das machen, würde ich gerne noch mal über ein paar Missverständnisse reden. Da kommen mir viele so bekannt vor aus meinem Alltag als Consultant. Wie zum Beispiel hatte ich ein Projekt, in dem der Auftraggeber mir sagte, dass wir keine User Tests durchführen müssen, weil er ganz genau weiß, was die Leute wollen. Was würdest du dem denn entgegnen?
Andreas: Das ist ein klassisches Beispiel, das wir auch immer wieder erleben. Ich glaube, das kommt daher, dass User Experience einfach immer noch ein Begriff ist, mit dem wenige Leute was anfangen können, weil das einfach nicht greifbar ist. Experience ist etwas, das wir auch ständig haben. Wir können nicht sagen, wir haben keine Experience. Wir haben im Deutschen den Vorteil, das noch aufspalten zu können. Wir haben Erfahrung als Experience und Erlebnis als Experience. Wir machen bei jeder Nutzung eine Erfahrung, und wenn es gut ist, haben wir ein Erlebnis, über das wir dann auch reden. Das ist ein Erlebnis, das wir mit anderen teilen, wo wir vielleicht auch andere überzeugen, die gleiche Software mal auszuprobieren oder zu kaufen. Und wenn Kunden oder Leute, mit denen wir über UX reden, denken, sie wüssten genau, was die Nutzer ihrer Software brauchen oder wollen, kann das überhaupt nicht sein, weil die User Experience einfach so individuell ist, dass man sich eigentlich in jeden einzelnen Nutzer hineinversetzen müsste, um zu wissen oder um sagen zu können: Ich weiß, was der will und braucht. Das geht nicht.
Lucas: Okay. Das heißt also, eine einzelne Person kann niemals diese Aussagen treffen?
Andreas: Genau. User Experience ist hoch individuell, hoch subjektiv. Es ist so, dass wir uns beeinflussen lassen können von Gruppen, vor allem von Freunden, aber auch von Werbung, von anderen Leuten, mit denen wir aus irgendwelchen Gründen über ein Software Produkt reden. Und ganz wichtig: User Experience ist eben kein reines Informatik Thema. Es ist auch nicht immer nur bei Produkten der Fall, dass wir eine Experience haben, mit denen wir tatsächlich auf technischer Ebene interagieren. Wenn wir Knöpfe drücken oder auch nur irgendwas in die Hand nehmen. User Experience haben wir auch, wenn wir nur eine Informationstafel lesen, zum Beispiel. Weil da kommt eine Information zu uns. Wir müssen diese Information wahrnehmen, interpretieren. Für uns entscheiden: Ist die wichtig für mich oder nicht? Und all das gehört dazu. Wir haben eine Experience, wenn wir diese Wahrnehmung für uns interpretieren und entscheiden, ist das wichtig für mich oder nicht. Auch daran müssen wir denken. Es geht nicht nur um technisch interaktive Produkte.
Lucas: Ein verwandtes Thema dazu ist, etwas, was ich auch im Projekt schon erlebt habe, wo ich gesagt habe, wir bräuchten jetzt eigentlich hier einen UX Experten oder eine Expertin. Und dann wurde mir entgegnet: Wir haben schon einen Designer oder eine Designerin. Kannst du das auch nochmal abgrenzen, was diese Begriffe bedeuten? Vielleicht auch noch mal UX und UI vielleicht so ein bisschen voneinander abgrenzen, auch wenn es vielleicht jetzt schon den meisten klar sein sollte.
Andreas: Ja, UX, eine positive Experience gestalten wir eigentlich nicht durch Visual Design. Es ist zwar wichtig, dass ein Produkt gut aussieht, vor allem die Nutzungsoberfläche, mit der Nutzer zu tun hat, wenn er das Produkt nutzt. Aber User Experience ist mehr als nur einfach UI Design. Zum UI Design gehört neben Visual Design auch das Screen Design. Das ist alles wichtig, aber eben eigentlich wieder auf der Usability Ebene. User Experience, auch das ist noch mal eine wichtige Unterscheidung zur Usability. Bei User Experience geht es nicht um die eigentliche Nutzung, so wie bei Usability. Zwar auch, aber eigentlich eher untergeordnet. User Experience ist viel wichtiger in den Phasen davor. Was hat der Nutzer für einen Eindruck von dem Produkt, bevor er damit wirklich arbeitet? Wie kommt ein Nutzer überhaupt an dieses Produkt ran? Wie weckt man das Interesse an diesem Produkt? Wie ist die Journey eines Nutzers vom ersten Wahrnehmen eines Produktes bis zur Nutzung? Und User Experience beschäftigt sich auch hinterher noch damit, wie ein Produkt auf einen Nutzer gewirkt hat. Wie die Emotionen wirklich. entstanden sind. Und auch, wie diese Emotionen oder der Eindruck der Nutzung über die Zeit erhalten bleibt. User Experience hat genauso wie Usability einfach viel mit Erwartungshaltung zu tun. Und sobald ich anfange, mit einem Produkt zu arbeiten, habe ich eine gewisse Erwartungshaltung an das Produkt und ich stelle mir vor, wie es sein wird, wenn ich damit arbeite. Und dann gleiche ich immer wieder ab: Ist es wirklich so, wie ich es mir vorgestellt habe oder nicht? Wenn es nicht so war, bin ich vielleicht unzufrieden. Wenn es so war, bin ich aber zufrieden, aber das war’s dann. Es ist einfach da und ich habe damit interagiert und gut. Bei der User Experience schaue ich eben: War der Nutzer wirklich super zufrieden mit der Nutzung? Waren da vielleicht Dinge dabei, die er nicht erwartet hat und trotzdem toll fand? Und wie ist das dann hinterher? Der Nutzer hat nach jeder Interaktion eine neue Erwartung. Er hat einen neuen Status quo. Er kennt dann vielleicht Dinge, die er wirklich besser fand als erwartet. Nur beim nächsten Produkt erwartet er genau dieses Bessere. Das heißt, mit dem gleichen Produkt, mit der gleichen Technik oder dem gleichen Feature stelle ich ihn nicht mehr so toll zufrieden, weil die Erwartung höher geschraubt wurde. Die User Experience ist da nicht mehr ganz so positiv wie vorher. Die verändert sich über die Zeit und ich muss neu überlegen: Wie gestalte ich die jetzt wieder positiver als vorher? Das ist ein ganz spannendes Feld und es ist rein subjektiv. Ich muss immer wieder verstehen, wie der Nutzer tickt, wie er wirklich Dinge wahrnimmt, was er für neue Erwartungen hat.
Lucas: Du hast damit eigentlich auch schon ein bisschen angedeutet oder vielleicht sogar ausgeführt, dass es eben nicht so ist, dass wir einmal UX machen und dann sind wir fertig. Sondern wir müssen das als ständigen Prozess von Anfang bis Ende verstehen, der immer weitergeht, richtig?
Andreas: Genau. Auch das macht es so spannend. Ganz wichtig ist, die Leute in ihrem Kontext kennenzulernen. Auch da geht es darum, dass wir als Entwickler uns nicht vorstellen können, wie so ein Produkt wirklich genutzt wird, wo es genutzt wird, wie ein Benutzer das Produkt wahrnimmt, wie er Dinge findet, mit denen er agieren kann und wie er mit dem Produkt wirklich hinterher arbeitet. Weil auch hier sind Nutzer einfach zu individuell und haben zu subjektive Wahrnehmungen und Reaktionsweisen. Wir können nicht von uns auf andere schließen. Und deswegen ist es ganz wichtig, so früh wie möglich Nutzer zu beobachten, wie sie in der Umgebung, in der das Tool später benutzt werden soll, arbeiten. Einmal ohne Tool, wenn es das noch nicht gibt oder mit verwandten Produkten. Man muss den späteren Nutzer echt so gut wie möglich kennenlernen. Man muss feststellen: In welchem Kontext braucht der Nutzer wirklich Unterstützung durch ein Produkt? Nur so können wir hinterher sagen: Gut, wir machen uns jetzt Gedanken, was der Nutzer in diesem Kontext braucht. Wir entwickeln etwas, das diese Unterstützung bietet. Und dann ist es aber ganz wichtig, wieder mit dem Nutzer zu klären, ob das wirklich das ist, was ihm hilft. Auch da dürfen wir nicht mit der Erwartung drangehen, dass wir auf jeden Fall Recht hatten.
Lucas: Okay, also wenn wir uns noch mal unser Thema von heute anschauen, reden wir über User Experience Design. Du hast jetzt gerade schon viel über Benutzer und Benutzerinnen gesprochen. Über deren Fähigkeiten, Bedürfnisse. Was muss ich denn noch über meine User verstehen? Was muss ich noch für User in meinem Kontext von meinem System wissen? Was ist da noch wichtig?
Andreas: Dieser ganze Bereich oder die Technik, die da wichtig ist, ist User Experience Research oder auch nur User Research. Wir müssen echt eigentlich in den Kopf von Nutzern reinschauen. Dazu gehört auch nicht nur eine Beobachtung von dem, wie der Nutzer arbeitet oder wo er Produkte nutzt, wo er Schwierigkeiten hat. Es ist wichtig, mit dem Nutzer wirklich tiefgehend zu sprechen. Interviews in dem Kontext, in dem das Produkt später genutzt werden soll, Interviews zu führen. Von dem Nutzer selbst zu hören, wo er für sich vielleicht Schwierigkeiten sieht. Und das kann völlig davon abweichen, was wir vorher vielleicht beobachtet haben. Das kann auch völlig davon abweichen, was wir uns gedacht haben. Der Benutzer hat eine ganz andere Vorstellung von dem Produkt als wir und hat auch eine ganz andere Vorstellung von dem, wie er mit dem Produkt arbeitet, wo er es vielleicht sonst noch benutzt. Er kommt mit Erwartungen, aber mit ganz vielen Vorerfahrungen auch in dieses Interview rein. Er hat Dinge im Kopf, die er uns erzählen kann und will. Aber was er wirklich braucht, kann er uns normalerweise gar nicht sagen, weil er unbewusst so mit dem Produkt interagiert, wie er es dann auch tut. Man sollte sich nicht Stunden, Tage, Wochen lang Gedanken machen müssen, wie man jetzt ein Produkt in einer bestimmten Umgebung benutzen kann. Man macht es einfach. Und das macht man, weil man eine bestimmte Vorerfahrung mit ähnlichen Produkten hat und einfach weiß, wie das bei denen funktioniert. Das heißt, auch wenn wir mit völlig neuen Dingen kommen, mit ganz neuen Techniken, mit neuen Features, die auf dem Markt noch gar nicht irgendwo vorhanden sind, dann haben wir auch keine positive Experience erzeugt, weil der Benutzer da vielleicht überfordert ist. Der Benutzer hat sich vorgestellt und erwartet, dass er ein Produkt bekommt mit Elementen, die er schon kennt. Er kann nicht intuitiv mit diesem Produkt arbeiten, weil es zu neu ist. Und das ist nicht das Ziel von User Experience Design. Wir müssen wirklich diese Erwartungshaltung und die Vorerfahrungen herausfinden und dann für uns auf technischer Ebene schauen: Wie erfüllen wir diese Erwartungen? Und zusätzlich: Wie erzeugen wir diese positiven Emotionen beim Nutzer? Die Auswirkungen von der Nutzung des Produkts ist dann wieder nämlich vielfältig. Der Nutzer bewertet für sich einmal: Gefällt mir das Produkt oder nicht? Finde ich das gut oder nicht? Er merkt aber natürlich auch, was es bei ihm auslöst. Sind das positive Emotionen oder eher negative Emotionen? Wir wollen natürlich positive Emotionen erzeugen. Aber ob das so ist, kann uns auch wieder nur der Nutzer sagen. Und je nachdem, wie er das bewertet, wird er eben auch wieder anders mit dem Produkt umgehen. Er wird es beibehalten oder er hat negative Erfahrungen gemacht und wird sich um eine Alternative kümmern. Es gibt, gerade im App Store zum Beispiel jede Menge Alternativen, die ich nehmen kann, die ich auch schnell finde und die auch nichts kosten. Das heißt, ich kann schnell ganz viele Angebote anschauen, sie wieder runter schmeißen und das Nächste ausprobieren. Wenn er positive Erfahrungen gemacht hat, führt das auch dazu, dass mein Nutzer loyal gegenüber meinem Produkt und am Ende auch loyal gegenüber meiner Firma und Marke ist. Das heißt, beim nächsten Mal wird er vielleicht eher in meinem Unternehmen, unter meiner Marke schauen, ob ich da nicht Produkte habe, die sein neues Problem lösen können.
Lucas: Ich glaube, da sollte schon dem einen oder anderen die Ohren klingeln von dem ganzen, was man da an Kundenbindung generieren kann. Wir waren gerade noch ein bisschen in dem Bereich. Wir haben über User gesprochen, du hast jetzt auch schon den Teil Experience angesprochen. Da wollte ich aber noch mal auf eine Sache zurückkommen, die du jetzt mehrfach erwähnt hast. Das war das Thema Emotionen. Wenn ich jetzt daran denke, mein Produkt erzeugt Emotionen, dann denke ich vielleicht so was wie Wut. Dann ist vielleicht jemand enttäuscht von meinem Produkt, das wären so Emotionen. Was für eine Art von Emotion meinst du jetzt? Meinst du, die Leute lieben das Produkt oder ist das gar nicht wünschenswert? Wie siehst du das?
Andreas: Das kann tatsächlich passieren. Wir sind hier auf einer wirklich stark psychologischen Ebene unterwegs. Das ist ein Wort, das gerade Informatiker vielleicht abschreckt. Aber wir müssen uns immer wieder bewusst machen, Informatik und gerade interaktive Produkte sind auf der emotionalen Ebene, ob wir das wollen oder nicht. Wir haben auf psychologischer Ebene immer bestimmte Bedürfnisse, die wir erfüllt haben wollen, auch wenn wir uns dessen gar nicht bewusst sind. Als Mensch wollen wir autonom sein, als Mensch wollen wir Dinge lernen. Wir wollen anderen zeigen, dass wir Dinge können, die nicht jeder kann. Wir wollen uns mit anderen verbunden fühlen, weil wir zum Beispiel Produkte derselben Marke haben. Weil wir Dinge haben, die sich nicht jeder leisten kann, weil wir Dinge haben, mit denen nur wir uns unterhalten können, über ein Messenger oder über ein Forum oder wie auch immer. Unbewusst wollen wir das alles. Wir können es aber vielleicht nicht sagen, dass wir das wollen. Das ist grundsätzlich ein Problem, wenn wir mit Nutzern reden. Wir bekommen erzählt: Okay, ich will mit dieser Software effizient sein. Effizienz ist eine Worthülse. Niemand kann damit was anfangen, wenn man das hört. Wir wollen ein gutes Gefühl haben, wenn wir das Produkt benutzen, ist genauso. Das können Nutzer sagen, das stimmt auch, aber wir können damit als Entwickler nichts anfangen. Wir wollen andere Leute treffen, wir wollen in Kontakt stehen mit anderen Leuten. Nützt uns auch nichts. Wir müssen hinterfragen, warum das so ist. Und dann können wir Lösungen entwickeln, um das zu erlauben. Und dann kommt vielleicht was heraus, was über ein Forum, über einen Messenger hinausgeht.
Lucas: Wo ich ein bisschen unruhig werde bei deiner Beschreibung, ist, dass es mich auch so ein bisschen auch an solche Dark Patterns erinnert. Wir alle haben uns wahrscheinlich schon damit beschäftigt, dass vielleicht bestimmte Apps vielleicht eine Sucht hervorrufen bei Leuten, dass sie vielleicht auch Bestätigung brauchen durch mehr Likes und mehr Retweets oder was auch immer in der App da ist. Ist damit so etwas gemeint oder ist das auch damit gemeint, dass man so etwas verhindert? Wie ordnest du das denn ein?
Andreas: Dark Pattern ist dafür vielleicht wirklich ein guter Begriff, aber das basiert auch wieder auf diesen psychologischen Bedürfnissen, weil gerade das basiert darauf, dass ich Anerkennung haben möchte. Jeder Mensch braucht eine Art von Anerkennung, jeder braucht Respekt, jeder muss in irgendeiner Weise zeigen, dass er entweder dazugehört oder eben besser ist, dass er jemand ist, der anderen was erklären kann, weil das nicht jeder weiß, dass er etwas kann, das nicht jeder kann. Und wenn jemand viele Likes bekommt oder viele Herzchen oder was auch immer, dann kriegt er diesen Respekt. Ob das jetzt ernst genommene und echte Likes sind oder nicht. Aber allein diese Rückmeldung „Ich mag, was du jetzt gesagt oder getan hast“, das erfüllt dieses Bedürfnis.
Lucas: Und ist das dann etwas, womit wir im User Experience Design dann aufpassen müssen, dass wir die Leute nicht in irgendeine Art von Abhängigkeit von unserem Produkt treiben?
Andreas: Jein. Wir müssen den Benutzer selbst respektieren, wir müssen ihn ernst nehmen und wir müssen dem Nutzer zeigen, dass wir ihn verstanden haben. Und allein durch ein Like schaffen wir das nicht. Das ist eine sehr leichte Möglichkeit, ihn da zufriedenzustellen. Aber das Produkt selbst unterstützt ihn vielleicht gar nicht so sehr. Und deswegen ist es für uns viel wichtiger, das Produkt so zu gestalten, dass er das Gefühl hat: Das ist wirklich das, was ich will und brauche. Die Likes kommen vielleicht dann automatisch, wenn er über dieses Produkt mit anderen redet und sagt: Hier, guck mal, das habe ich gefunden. Das ist voll cool. Probier’s doch mal aus. Dem anderen gefällt einfach, dass er diesen Tipp bekommen hat. Und der fragt vielleicht auch nach: Erklär mir doch mal, wie ich das und das tue. Erklär mir doch mal, was das Tool alles noch Tolles kann. Allein darüber zu reden und sich wohl zu fühlen, weil man anderen helfen kann. Oder weil man ein Tool gefunden hat, das besser ist als andere. Das erfüllt das Bedürfnis. Einen Like zu kriegen, das tut es eigentlich nicht.
Lucas: Okay, gut. Und dann schauen wir uns noch das letzte Wort von unserer Überschrift an. Das Wort Design. Ich glaube, die meisten Menschen schalten da direkt zu Grafik Design. Was ist denn mit Design gemeint? Kannst du das noch einmal kurz erklären?
Andreas: Ja, das Problem, dass darunter visuelles Design gemeint ist, das haben wir in Deutschland, weil einfach der Begriff, ich will nicht sagen verbrannt ist. Aber ganz viele Leute denken da direkt an Design, weil viele Firmen auch vor allem aus dem Spielebereich einfach von Design reden, wenn es um Spiele Design geht, wo alles bunt ist und blinkt, wo ganz viel Wert auf visuelle Gestaltung gelegt wird. Design ist im Deutschen einfach Gestaltung und es geht, wie gesagt darum, diese Emotionen zu gestalten. Und deswegen heißt es User Experience Design. Wir gestalten die Experience. Wenn wir es gut machen, wird es eine gute Experience, eine positive. Wenn wir es schlecht machen, wird nicht unbedingt eine negative Experience daraus, sondern wird einfach wie beim Usability Design eine neutrale Erfahrung daraus und nichts, was den Nutzer begeistert und an das Produkt bindet.
Lucas: Das heißt also, es ist nicht eine optische Wahrnehmung gemeint, es ist auch noch nicht mal Wahrnehmung gemeint, sondern es ist wirklich eine Gestaltung von einer Benutzung gemeint.
Andreas: Wahrnehmung nicht auf Sinnesebene. Klar, Aussehen ist auch wichtig, aber ein Aussehen alleine gestaltet die User Experience nicht unbedingt positiv. Das kann passieren, wenn das wirklich eine innovative Gestaltung ist. Wenn es wirklich ein Tool ist, das ich aufgrund des Aussehens besser benutzen kann, das kann schon auch ein Bedürfnis stillen. Wir haben ein Bedürfnis, neuartige Sachen zu entdecken, Dinge wahrzunehmen, die anders sind, aber trotzdem gut und nützlich. Das kommt aber eigentlich selten vor. Es ist wichtig, gut zu gestalten, aber beim User Experience Design geht es viel weiter und wir betrachten einfach alles. Alle Sinneswahrnehmungen, alle Bedürfnisse, die wir erfüllen können. Alle emotionalen Dinge, die wir durch Software ansprechen können. Das alles designen wir, das alles gestalten wir.
Lucas: Okay, gut. Dann lasst uns doch jetzt mal zum Thema Human Design übergehen, um darauf noch mal zu fokussieren. Du hast mir gesagt, dass es im Human-centered design vier Aktivitäten gibt. Die wollen wir gleich mal durchgehen. Aber bevor wir das machen, wenn man an so Aktivitätenphasen und so was denkt, ist es bei vielen Leuten im Kopf eine Reihenfolge, die man abarbeitet. Muss man Human-centered design als einen Arbeitsprozess verstehen oder wie muss man das einordnen?
Andreas: Einmal noch kurz: Human-centered design heißt eben nicht mehr User-centered design, sondern wir betrachten alle Rollen. Wir betrachten nicht nur die Nutzer, die am Ende mit dem Produkt arbeiten. Wir betrachten auch Entscheidungsträger in Firmen, weil wir können nicht einfach wirklich alles auf den Nutzer ausrichten, was hinterher der Firma zu viel Geld kostet oder was einfach technisch nicht möglich wäre. Wir unterhalten uns und kommunizieren einfach immer auch mit den Entscheidungsträgern, mit den Geldgebern, aber auch mit zum Beispiel dem technischem Support. Wir können nichts auf den Markt werfen, was hinterher nicht gewartet werden kann. Wir können auch nichts auf den Markt werfen, was Sicherheitslücken aufweist. Das heißt auch hier, Gesetzeslagen müssen wir betrachten. Wir müssen Rechtsabteilungen mit einbeziehen, aber auch andere Disziplinen aus der Informatik. Wir müssen tatsächlich die wirklichen Experten im Visual Design einbeziehen. Damit die uns rückmelden können: Können wir das, was ihr euch überlegt habt, überhaupt so darstellen, dass der Benutzer einen Vorteil damit hat? Dass er schnell Elemente findet, die er braucht, dass er auf den ersten Blick eigentlich erkennen kann, was er tun kann. Und welche Ziele er erreichen kann, welche Aufgaben er durchführen kann. Tester sind ganz wichtig. Im Human-centered Design geht es darum, möglichst schnell zu testen. Aber damit wir irgendwas testen können, müssen wir wissen, was das ist, was wir testen können oder wollen und auch, wie wir testen. Klar, die technische Prüfung, die Tests, Unit Tests, Integration Tests sind wichtig. Aber am Ende geht es darum, dass der Nutzer selbst testet, ob das, was wir für ihn gebaut haben, auch wirklich das ist, wie er sich das vorgestellt hat. Diese interdisziplinären Teams, in denen wir Produkte entwickeln, die sind extrem wichtig, weil jeder dabei sein muss, um dieses Produkt zu entwickeln. Weil jeder von Anfang an mitentscheiden muss, ob das ein Produkt ist, das er selbst auch, unabhängig davon, ob er Nutzer ist, nutzen kann, in dem Sinn, dass es eben auch diese anderen Arten von Nutzung gibt, als die, die ein Endnutzer wirklich hat. Wie gesagt: Wartungen, Testen.
Lucas: Aber genau noch mal zurück zu der Reihenfolge. Wir haben verschiedene Aktivitäten, aber wir müssen das nicht als ein Vorgehensmodell betrachten, sondern eher als eine Art Framework, das Human-centered Design, wenn ich das richtig verstehe.
Andreas: Richtig. Ich muss sagen, Human-centered Design hat vier Aktivitäten. Es ist ein Framework, in dem die vier Aktivitäten eingebunden sind. Die erste ist: Wir brauchen einfach einen Überblick über den Kontext, in dem das Produkt genutzt wird, das wir entwickeln sollen oder wollen. Das heißt, das kriegen wir über Beobachtungen mit, wie ich es vorhin schon gesagt habe, wir lernen den Kontext kennen, in dem Nutzer mit dem Produkt interagieren, und das kann ein anderer Kontext sein, als wir uns ursprünglich vielleicht vorgestellt haben. Busfahrt zum Beispiel: Wie viele nutzen ein Handy während der Busfahrt, um Blogbeiträge zu lesen oder um Podcasts zu hören? Wir haben uns vielleicht vorher vorgestellt, dass jemand im Bett liegt und das tut. Auch das ist vielleicht ein Kontext, den wir uns nicht vorstellen konnten, weil wir selbst kennen das vielleicht. Wir liegen abends im Bett und schlafen während des Podcasts ein. Uns nützt das wenig. Wir wollen Wissen vermitteln und versuchen, den Nutzer auch wach zu halten, dass er dieses Wissen von vorne bis hinten hält. Klar, das kann passieren. Das ist ein Kontext, über den wir auch nachdenken müssen. Es ist vielleicht bei weitem nicht der einzige und wir versuchen in dieser Aktivität einfach möglichst viele verschiedene Kontextinformationen zu sammeln. Und danach die Aktivität kommt dann, dass wir aus diesen Kontext-Informationen die Anforderungen ableiten. Auch hier fragen wir nicht.
Lucas: Darf ich kurz unterbrechen, bevor wir da rein kommen. Ich würde gerne noch eine andere Frage dazu fragen. Gerade wenn ich über User Research höre, ist das in vielen Vorträgen das, was ich dazu oft erst noch höre, ist diese Geschichte: Wenn man die Leute gefragt hätte, was sie wollen, dann hätten sie gesagt: Wir wollen schnellere Pferde und nicht ein Auto. Diese Geschichte höre ich sehr oft in Vorträgen zu diesem Thema. Magst du mal kurz was dazu sagen? Ist das eine sinnvolle Metapher, ein sinnvoller Spruch dazu oder geht das in eine falsche Richtung?
Andreas: Ich hasse das. Das ist meine Emotion dazu. Das ist ein Zitat, das Henry Ford zugeschrieben wird. Es gibt keinerlei Belege, dass das wirklich ein Zitat ist, dass er das jemals gesagt hat. Viel eher ist das etwas, dass eine Marketing Zeitschrift sich überlegt hat, um zu sagen: Hier, du brauchst eigentlich deine Nutzer nicht fragen, wenn du wirkliche Innovation auf den Markt bringen willst. Das stimmt so nicht. Und eigentlich sind auch viele Bestandteile von diesem Zitat einfach falsch, wenn man sich das aus User Experience Sicht anschaut. Zum einen bei Ford ging es nicht um Innovation. Der hat das Auto nicht erfunden. Deswegen wäre es auch komisch, wenn er die Leute gefragt hätte: Willst du etwas, das quasi ein technisches Pferd ist? Es ist auch komisch, davon auszugehen, dass die Leute gesagt hätten: Ich will ein schnelleres Pferd, weil zu dem Zeitpunkt gab es schon Autos. Es gab keinen Grund, dass die Leute sagen: Ich will aber ein schnelleres Pferd. Die sagen vielleicht: Ich will ein billigeres Auto, ich will ein schnelleres Auto, ein sicheres Auto. Wenn man das im Kontext der Zeit sieht, ist dieses Zitat komisch und auch die Aussagen darin. Wenn ich die Leute gefragt hätte. User Experience verlangt, dass man die Nutzer fragt. User Experience, eigentlich macht man sich überhaupt keine Gedanken, sie fragen zu können, sondern man muss das machen. Dann hätten die Leute gesagt: Ich will. Okay, „ich will“ ist eine Aussage, mit der wir als Entwickler und als User Experience Designer nicht viel anfangen können. Weil wir sollten und dürfen einfach nicht genau das umsetzen, was uns die Leute sagen. Das ist auch wieder ein Punkt. Wir müssen diese Interviews führen, um rauszufinden, warum die Leute das wollen. Und wenn wir das wissen, können wir Produkte bauen, die wirklich auf der Ebene soweit unterstützen, dass die Leute hinterher wissen: Cool, das habe ich gemeint, das will ich, das brauche ich. Das ist eine coole Firma, die versteht mich. Und der letzte Teil von dem Zitat, sie hätten sich schnellere Pferde gewünscht. Okay, könnten sie sagen, wenn Ford wirklich das Auto erfunden hätte. Aber das allein ist auch nicht das, was wir als gegeben annehmen. Auch wenn uns jemand sagt: Wir wollen jetzt schnellere Pferde, entwickeln wir nicht einfach schnellere Pferde. Wir fragen die Leute, warum sie die schnelleren Pferde gerne hätten. Und das kann aus ganz verschiedenen Gründen passieren. Die Leute könnten wirklich schneller von A nach B kommen wollen. Sie könnten aber auch sagen: Ich mag es einfach, den Wind um die Ohren zu spüren. Ich mag es einfach, durch die Landschaft zu reiten oder zu fahren oder was auch immer. Sie wollen die Landschaft kennenlernen. Oder: Ich mag es, wie ich von links nach rechts geschaukelt werde, wenn ich auf dem Pferd bin. All das können wir nicht wissen, wenn wir mit den Nutzern nicht sprechen. Und nur so erfahren wir, was unser Produkt liefern sollte, damit der Benutzer wirklich das Gefühl hat, was er im Kopf hatte, wenn er uns sagt, was er will.
Lucas: Ich wollte das einfach noch mal kurz herausheben, bevor wir über die nächsten Phasen reden, weil mein Eindruck ist, dass das das unterschätztere Thema in dem Bereich ist, dass man die Leute auch verstehen muss. Ich finde dein Beispiel auch deswegen gut, weil wenn jemand wirklich das Bedürfnis hat, schnell von A nach B zu kommen oder einfach dieses Gefühl von Schnelligkeit zu haben. Das sind wirklich zwei ganz unterschiedliche Bedürfnisse, die einfach auch unterschiedliche Lösungen bedeuten würden. Wenn ich jetzt Fahrtwind auf mir spüren will, würde ich nicht mit dem ICE fahren. Das ist nicht die richtige Lösung für das Problem.
Andreas: Dann würde ich auch nicht in einer geschlossenen Kutsche fahren, außer ich will diese Vibration spüren oder sonst was. Ich muss einfach die Leute verstehen und nicht nur auf der Ebene, was sie sagen, sondern auch, was sie sich denken.
Lucas: Okay, sehr gut. Wir haben jetzt über die erste Aktivität gesprochen, Kontext identifizieren. Die zweite ist das Ableiten von Anforderungen. Magst du dazu was sagen?
Andreas: Wir haben auch hier, das ist die Aufgabe von dem Experience Experten, die Anforderungen abzuleiten. Der Nutzer sagt uns das nicht, weil er vor allem technische Anforderungen auch nicht kennen kann. Er ist dafür nicht unbedingt der Experte, außer wenn wir für andere Informatiker entwickeln. Die Anforderungen leiten wir ab von den Informationen, die wir aus der vorherigen Aktivität, der Kontextanalyse oder des Kennenlernens von verschiedenen Kontexten, die wir da gesammelt haben. Und wir haben hier auch wieder verschiedene Anforderungen, die wir erfüllen sollten. Wir haben nicht nur die Nutzeranforderungen, also diejenigen Anforderungen, die ein Nutzer braucht, um das Produkt nutzen zu können. Wir haben Anforderungen auf technischer Ebene, Systemanforderungen, die erfüllt sein müssen, damit wir die Nutzeranforderungen überhaupt umsetzen können. Kapazität zum Beispiel, die wir liefern müssen oder Geschwindigkeit oder wie auch immer. Die müssen wir auf technischer Ebene einfach auch erfüllen. Und wir haben rechtliche Anforderungen, irgendwelche Standards, die erfüllt werden sollten oder müssen. Sicherheitsanforderungen, die einfach gesetzlich vorgegeben sind, auch zum Beispiel Anforderungen an die Accessibility, an die Barrierefreiheit von Produkten. Das ist kein Wunsch oder kein Kann, das ist einfach gesetzlich vorgegeben. So was müssen wir kennen und eben auch als Anforderungen formulieren und umsetzen.
Lucas: Ist das dann Requirements Engineering oder ist das noch mal was anderes?
Andreas: Das ist genau das, was Requirements Engineering tut. Anforderungserhebung, Anforderungsmanagement. Auch hier müssen wir wieder versuchen alles zu verstehen, den Nutzer zu verstehen, technische Möglichkeiten zu verstehen, uns weiterbilden, uns einen Überblick verschaffen, was geht und was nicht. Dinge einfach kennen und für uns zu konzipieren. Was wie zusammenpasst, damit am Ende unser Ziel erreicht werden kann, den Nutzer zu begeistern.
Lucas: Aber wichtig dabei, wenn ich dich richtig verstehe, ist dass es jetzt nicht eine Phase innerhalb von unserer Projektentwicklung ist und dann haben wir die Anforderungen abgeleitet und jetzt sind die fertig, sondern das ist auch ein ständiger Prozess der Weiterentwicklung der Anforderungen, wenn ich dich richtig verstehe.
Andreas: Genau, die User Experience, wie ich vorhin auch mal angedeutet habe, die ändert sich mit jeder neuen Erfahrung. Wenn der Benutzer mit irgendeinem Produkt interagiert oder irgendwelche Informationen wahrnimmt und liest, ändert sich seine Erwartungshaltung, sein Wissensstand, seine Gemütslage. Wenn ich den Nutzer zu verschiedenen Zeitpunkten dasselbe frage, gibt er mir unter Umständen ganz andere Antworten. Weil er schlechter drauf ist, weil er gestresst ist, weil er an Dinge denkt, die hier mit jetzt nicht so viel zu tun haben, aber die einfach beeinflussen, wenn er traurig ist, weil seine Katze gestorben ist oder wie auch immer. Und Human-centered Design ist deswegen auch so spannend, weil sich diese Anforderungen und Erwartungen einfach ständig ändern. Und es reicht nicht, nur einmal wenige Nutzer zu fragen. Ich muss das immer wieder machen, alle paar Monate vielleicht. Und ich erfahre immer wieder neue Sachen. Das heißt, ich kann auch immer wieder neue Anforderungen ableiten. Ich entdecke neue Anforderungen. Aber ich merke oft auch, dass Anforderungen sich widersprechen oder dass alte Anforderungen nicht mehr gelten. Dass der Benutzer so viele neue, andere Erfahrungen gemacht hat, dass er andere Wünsche hat, dass er andere Bedarfe hat, zum Beispiel auch wieder auf Usability Ebene. Und es ist wichtig, diese bestehenden Anforderungen auch immer wieder zu prüfen.
Lucas: Okay, gut. Dann lasst uns doch noch über die dritte Aktivität sprechen. Rapid Prototyping. Was verstehen wir denn unter Prototyping und was verstehen wir unter Rapid Prototyping?
Andreas: Prototyping ist eine Methode, die wir auch aus anderen Entwicklungsansätzen kennen. Wir gestalten einen kleinen Teil, eine Vertikale eines Produkts, zum Beispiel einen Idealpfad, den wir mit Nutzern durchspielen und versuchen herauszukriegen: Kommt er mit dem Produkt, wie ich es mir vorstelle, jetzt wirklich so zurecht, wie ich es mir vorstelle? Ich kann das eigentlich beliebig detailliert prototypisieren und vom Nutzer prüfen lassen. Ich kann mit Stift und Papier etwas skizzieren, was der Nutzer dann vorgelegt bekommt und dann sagt: Ja, so sieht das gut aus, so könnt ihr weitermachen. Oder ich mache einen interaktiven Prototypen mit bestimmten Mock up Tools oder auch nur mit Präsentations-Software, die ich Folie für Folie durchklicken kann. Oder ich implementiere wirklich als echten Code etwas, mit dem der Nutzer fast realistisch arbeiten kann. Und am Ende bin ich so nah am Endprodukt, dass der Benutzer nur noch Kleinigkeiten durchspielen muss, um uns Rückmeldung zu geben, ob wir wirklich an alles gedacht haben. Und Rapid Prototyping sagt hier: Mach es so schnell wie möglich. Sobald ich die ersten Anforderungen identifiziert und spezifiziert habe, kann ich anfangen zu prototypen. So früh kann ich auch schon anfangen, mit Nutzern darüber zu sprechen. Und das ist ganz wichtig. Ständig Feedback einholen vom Nutzer. Das ist ein Bestandteil von Human-centered Design, der auch nicht weggelassen werden darf. Das ist ein Konzept, ein Prinzip, das besteht, wenn ich Human-cendered Dnesign machen möchte.
Lucas: Okay. Und damit sind wir eigentlich auch schon bei der vierten Aktivität. Der Evaluation. Wir haben vielleicht einen Prototyp. Jetzt wollen wir wissen, was können wir für Erkenntnisse aus diesem Prototyp gewinnen? Wie muss ich mir diese Evaluation vorstellen? Wie läuft die ab?
Andreas: Wir haben hier verschiedene Möglichkeiten, das zu evaluieren, die idealerweise aufeinander aufbauen. Zum einen können wir eine Expertenevaluation machen, das heißt technische Experten oder vor allem Experten im Usability Design, im User Experience Design schauen sich das Tool an, haben verschiedene Heuristiken, verschiedene Punkte, die erfüllt sein sollten. Minimale Informationen, dass man zum Beispiel nicht alles, was möglich ist, auf einen Screen steckt. Dass man Fehler vermeidet. Dort spielt man alles, was geht, durch. Evaluatoren klicken überall drauf, spielen alles Mögliche durch, haben bestimmte Zielvorgaben und versuchen, ob sie da möglichst einfach hinkommen. Und am Ende ist das eine Evaluationsform, wo wir sagen können: Hier sind mögliche Usability Probleme, hier sind mögliche User Experience Probleme, hier könnte es sein, dass der Nutzer hinterher unglücklich ist. Ob das wirklich so ist, kann man an dem Punkt überhaupt nicht sagen. Das sind wieder unsere Vorstellungen, die wir hier aufbauen und verifizieren können. Und das Ideal, wie man hier evaluiert, ist der Usability Test. Das ist auch nicht einfach nur Test, wie man sich das vielleicht vorstellt, sondern es ist ein definierter Prozess. Es ist umständlich und aufwendig. Wir reden hier davon mit ungefähr 20 Leuten in Einzelsitzungen quasi richtig durchgängig zu evaluieren. Das bedarf einer hohen Vorbereitungszeit. Wir müssen für uns erst mal ein Script schreiben, wo wir die Fragen kennen, die wir stellen wollen, damit wir nichts vergessen. Wir dürfen den Nutzer auf gar keinen Fall in irgendeiner Form beeinflussen. Das geht schon los bei den Klamotten, die wir tragen. Wir dürfen ihm nicht das Gefühl geben, dass wir sowas wie ein Lehrer sind, der jetzt den Nutzer testet. Der Raum muss für jeden der 20 Nutzer gleich gestaltet sein, der muss gleich hell sein, gleich warm. Die Uhrzeit sollte sich nicht unterscheiden. Wir müssen darauf achten, dass der Nutzer nicht gerade aus einem Meeting kommt, wo er zur Sau gemacht wurde oder dass er auch nicht von der Party kommt, egal ob er da Alkohol getrunken hat oder nicht. Die Rahmenbedingungen für diese einzelnen Sitzungen sollten gleich sein. Wir müssen aber auch im Kopf behalten, diese 20 Leute, die sitzen nicht gemeinsam im Raum und testen unser Produkt gleichzeitig oder parallel, sondern wir haben wirklich 20 einzelne Sitzungen. Das kostet Zeit und wir müssen uns am Anfang auch überlegen, zu welchen Zeiten oder in welchem Zeitraum wir das machen. Machen wir das innerhalb von zwei Wochen? Machen wir das in einer Woche? Haben dann vielleicht vier Leute an einem Tag, morgens und abends vier Leute. Das ist ganz wichtig für uns, klar zu werden: Auch hier werden diese Erfahrungen sich ändern. Und wenn ich ein paar Leute testen lasse und einen Monat lasse ich andere Leute testen, da können ganz unterschiedliche Ergebnisse rauskommen. Auch wenn ich dieselben Leute nach 1, 2, 3 Monaten nochmal testen lasse, können die uns ganz andere Sachen sagen und auch ganz anders mit der Software interagieren, als sie es vorher gemacht haben. Weil sich einfach diese Rahmenbedingungen vielleicht geändert haben. Weil aber auch die Erfahrungen, die der Nutzer in der Zwischenzeit gesammelt hat, ganz neu, ganz anders sind, neu interpretiert werden, sich neu verknüpfen. Das ist wirklich auch wieder schwer einen guten Usability Test zu planen und durchzuführen. Man sagt, mit 20 Leuten haben wir statistisch gesehen mehr oder weniger sichergestellt, welche Probleme noch auftreten oder ob unser Tool wirklich eine positive UX erzeugt. Aber schon ein Tag später könnte das anders aussehen. Und deswegen ist bei User Design eben auch wichtig zu wissen, dass es nicht mit der Entwicklung abgeschlossen ist oder mit der Evaluation, sondern es geht immer weiter und wir erfahren bei jedem neuen Test mehr über die Person, für die wir entwickeln. Aber wir erfahren auch jedes Mal, dass sich die User Experience einfach auch stark ändert. Egal ob das jetzt dieselbe Person ist, die testet oder andere Personen, die eine völlig andere Vorerfahrung mitbringen und uns vielleicht genau das Gegenteil sagen, was die emotionale Wirkung von dem Produkt ist, als die Person vorher.
Lucas: Du hast jetzt 20 schon mal als eine Zahl gesagt. Wenn ich mir vorstelle, ich habe jetzt meinen ersten Prototypen gebaut, teste ich den mit 20 Personen. Dann baue ich einen Monat später den nächsten Prototyp. Muss ich dann wieder mit 20 Leuten testen?
Andreas: Das wäre extrem teuer und aufwendig. Ich mache eigentlich einen Usability Test am Ende, wenn ich das Gefühl habe, ich habe jetzt ein Produkt prototypisch entwickelt, das ich so auch auf den Markt bringen könnte. Ich stelle mit dem Test jetzt sicher, dass ich keinen Shitstorm von den Nutzern kriege, weil das Produkt einfach aus deren Sicht zu schlecht ist. Ich will ein Produkt auf den Markt kriegen, das die meisten Nutzer wirklich gerne benutzen und auch positiv darüber reden. Auch zum Beispiel in Foren. Den Usability Test mache ich echt gegen Ende oder kurz vor Release, mit dem Gedanken aber auch, es ist teuer. Ich brauche eine gewisse Zeit, bis ich die 20 Leute rekrutiert habe. Und es dürfen auch nicht Leute sein, die mit diesem Tool sowieso schon viele Erfahrungen gesammelt haben. Es dürfen auch nicht Freunde sein, die uns sowieso positive Rückmeldung geben. Ich brauche wirkliche Repräsentanten der späteren Endnutzer.
Lucas: Aber nur damit da keine Missverständnisse aufkommen Wenn ich jetzt den ersten Prototyp baue, dann mache ich schon einen Test mit Leuten. Aber das ist dann kein Usability Test, sondern eine einfachere Art des Testens.
Andreas: Richtig. Das ist einfach ein Abklären oder sich die Bestätigung holen, auf dem richtigen Weg zu sein. Das ist auch, damit der Nutzer weiß: Wir haben ihn verstanden, wir arbeiten in die richtige Richtung. Aber damit auch er frühzeitig und über die gesamte Entwicklung hinweg die Möglichkeit hat, zu widersprechen oder klarzustellen, was er eigentlich meinte. Das ist hier das Ausschlaggebende. Und auch wir erfahren durch diese schnellen und häufigen Tests der Prototypen, ob wir den Nutzer richtig verstanden haben, ob wir uns in seine Lage versetzen können und verstehen, wofür dieses Produkt, das wir entwickeln, eigentlich später genutzt wird und wie es genutzt wird. Das ist der eigentliche Zweck von diesen Zwischenevaluationen. Deswegen reicht es hier auch aus, das einfach auf einem Blatt Papier zu machen. Später für die Usability Tests reicht es eher nicht.
Lucas: Okay. Nur damit nicht die Leute denken: Das ist zu teuer. Deswegen machen wir nur Prototypen und testen sie gar nicht erst. Das wollte ich nur noch kurz klarstellen. Gut, dann ein Thema, das mich noch beschäftigt in diesem ganzen Themenbereich, ist das Thema Agilität. Ich meine, das ist auch noch mal wahrscheinlich fünf weitere Podcast Folgen wert, aber erst mal nochmal den Zusammenhang zwischen Agilität und User Experience Design. Passt das zusammen oder steht das im Widerspruch, weil das mehr Planung voraussetzt? Wie würdest du diese beiden Sachen in Relation zueinander setzen?
Andreas: Wir haben auch hier leider häufig noch das Missverständnis, dass man sagt: Okay, wir entwickeln jetzt, wir testen vielleicht auch und hinterher, wenn noch Zeit ist oder wenn noch Geld da ist, machen wir User Experience Design. Okay, mach das mal schön. Oder mach das mal so, dass meine Nutzer es lieben. Genau, das geht nicht User Experience Design ist einfach keine eigene Phase. Es ist nicht mal eben so schnell gemacht. Es ist auch nicht nebenbei gemacht und auch nicht von Leuten, die nicht wirklich Experten in dem Bereich sind. Das ist nicht von heute auf morgen gelernt. Man braucht nicht nur theoretische Erfahrung. Man muss es einfach machen. Gerade wenn man versucht, Leute zu verstehen, wenn man deren Bedürfnisse herausfinden will. Das kann man nicht mit fragen und das kann man nicht, indem man sie fragt: Willst du gerne von anderen als kompetent wahrgenommen werden? Solche Fragen stellt man da eher nicht. Und in agilen Entwicklungen ist es einfach wichtig, dass ein UX Experte von Anfang an mit dem Entwicklungsteam ist. Es ist ein Entwicklungs-Framework User Experience Design. So baut man die gesamte Produktentwicklung auf. Es ist nicht so, dass man es erst am Ende macht. Es ist auch nicht so, dass man zum Beispiel einen Sprint voranstellt, wo es darum geht, User Experience Anforderungen zu identifizieren und zu spezifizieren. Und hinterher denkt man: Okay, ich habe verstanden, was Nutzer wollen. Oder Ich denke mir, was Nutzer wollen. Ihr baut das jetzt bitte, ihr Entwickler. Ich bin raus. Mein Print ist vorbei. Und dann denken alle: Cool, jetzt habe ich ein Produkt. Da hat mir der UX Experte gesagt: Das sind die Anforderungen an das Tool, die dann dazu führen, dass meine Nutzer das toll finden. Dann kommt es auf den Markt und es ist überhaupt nicht so. Die Nutzer beschweren sich darüber. Die Nutzer sagen: Hey, da gibt es doch schon ein Tool, das kann das genauso oder besser. Und dann wird es einfach nicht gekauft und genutzt. Und das liegt daran, dass User Experience einfach nicht einmal besteht und Anforderungen dazu entworfen werden, die dann nicht weiter betrachtet werden. Sondern User Experience ist die Entwicklung. Wie gesagt, wir haben den Anspruch, dass wir auch spätere Nutzer mit im Team haben. Wir haben den Anspruch, früh zu evaluieren. Und auch hierfür braucht es jemanden, der weiß, wie das geht und wie man das durchführt. Und das ist eben auch der User Experience Experte.
Lucas: Für mich ist das vor allem auch noch mal eine Erinnerung daran. Dieses, was schon fast ein Buzzword ist von cross-funktionalen Teams, was wir mittlerweile irgendwie in vielen Projekten hören. Wir brauchen cross-funktionale Teams. Darunter wird oft verstanden, wir haben Ops-Leute, Entwicklermenschen, vielleicht auch noch Grafikdesigner:innen im Team. Das ist eigentlich, das ist noch nicht cross-funktional genug. Wir müssten eigentlich noch weitergehen, richtig?
Andreas: Aus meiner Sicht ist es zwingend erforderlich, einen UX Experten mit im Team zu haben. Das ist kein: Ich mache mal oder wenn ich ihn nicht habe, auch gut. Sobald ich ein interaktives Produkt entwickle, brauchst du aus meiner Sicht einen UX Experten, der immer wieder dafür sorgt, dass es wirklich das Produkt ist, was die Nutzer mögen und darüber hinaus auch schaut, dass diese komplette Entwicklung mit den vier Phasen: Kontext verstehen, Anforderungen ableiten, Prototypen erstellen, evaluieren, dass das alles gemacht wird und dann auch überprüft ist, dass es richtig gemacht wurde und dass wir auf dem richtigen Weg sind. Eigentlich ist der User Experience Experte aus meiner Sicht natürlich subjektiv, weil ich einer bin. Aus meiner Sicht nicht wegnehmbar, auch nicht verhandelbar, ob er jetzt im Team ist oder nicht. Das Problem ist natürlich, dass es nicht in jedem Unternehmen Experten dafür gibt. Das sehe ich ein. Das ist einfach auch so, aber es gibt immer mehr Universitäten und Hochschulen, die das inzwischen anbieten. Immer mehr Psychologie Studiengänge, die darauf Wert legen, User Experience auch mitzubetrachten. Und nach und nach kommen einfach mehr und mehr User Experience Designer auf den Markt. Und wir alle zusammen haben einfach das Problem, Jobs zu finden als User Experience Experten, weil diese Vorurteile noch bestehen und so kräftig sind. Weil man immer wieder auch als Bewerber hört: Warum brauchen wir dich denn? Wir haben doch schon einen User Experience Experten. Das stimmt einfach nicht. Und Leute davon zu überzeugen, dass man User Experience Experten braucht, damit auch der Markterfolg später da ist, ist eine schwierige Angelegenheit und das versuche ich seit langem. Ziemlich fruchtbar ist es noch nicht.
Lucas: Okay, ich habe die Hoffnung, vielleicht haben wir jetzt die eine oder den anderen vielleicht überzeugt, dass es doch vielleicht ein Thema ist, mit dem man sich beschäftigen sollte, wo man sich vielleicht mal ein bisschen reindenken sollte und dann jemanden mit dazu nimmt in sein Projekt oder in sein Unternehmen, um sowas besser zu gestalten.
Andreas: Zumindest mal ausprobieren, wie viel besser das Produkt am Ende ist und wie viel mehr Geld man damit verdient.
Lucas: Absolut. Da bezahlt es sich von selbst.
Andreas: Richtig.
Lucas: Gut. Andreas, ich danke dir ganz herzlich für die lange Zeit, die du in diese Podcastfolge investiert hast. Ich danke auch den Hörerinnen und Hörern fürs Zuhören und sage auch schon mal bis zum nächsten Mal. Tschüß.
Andreas: Tschüß!