UX beyond Design - Warum man UX ganzheitlich angehen muss


Ashley: Willkommen zur nächsten Ausgabe der Taktsoft Campus Podcast der Podcast für Software und IT Professionals. Mein Name ist Ashley Steele und heute habe ich Daniel Ley bei mir. Hallo, Daniel. Grüß dich.


Daniel: Hallo, grüße ich ebenso.


Ashley: Ashley und alles klar bei dir heute?


Daniel: Ja, der Start in die Woche war ein bisschen holprig, aber ansonsten alles ganz gut.


Ashley: Das freut mich. Daniel Ja, bei mir auch. Danke, danke. Ja, du bist bei Amadeus. Ich sag mal so ein bisschen so Der Hidden Jam Amadeus steckt hinter die ganzen ist umso Reise Ökosystem eigentlich im Hintergrund und die Leute sehen das nicht. Aber dort bist du als Manager in dem Innovations Team tätig und so wie ich das verstanden habe, es geht wirklich darum, dass du das Thema UX, neue Geschäftsideen und und diese Sachen mal so auszuprobieren mit dem Lean Startup Prinzip. Und ich denke von daher, wenn wir jetzt gleich in das Thema einsteigen zum Thema UX User Experience, dass du wirklich eine Menge Erfahrung aus diesem Job und auch aus deiner Vergangenheit in dem in dem Travel Bereich, dass du wirklich viel Erfahrung mitbringen kannst. Und da freuen wir uns auch auf das Gespräch. Lass uns mal gleich gleich mal einsteigen. Ich sag mal so häufig denken Leute über das Thema User Interface, wenn es um das Thema Design geht. Aber ich glaube es gibt bzw wir wissen das. Es gibt viele andere Faktoren in diesem Design Prozess, User Experience, Usability. Und so weiter. Aber meine erste Frage wäre es Sind das da wirklich nur Buzzwords? Spielen die da eine Rolle und was steckt eigentlich hinter User Experience?


Daniel: Ja, also man kann das sehr schnell leider als Buzzwords missverstehen. Aber grundsätzlich steckt hinter dieser Experience eine ganze Menge an Inhalt und auch an Methodik, wie man an Sachen, an Produkte oder an Services heutzutage herangehen kann. Leider wird es immer noch total oft auch fälschlicherweise irgendwie verstanden als UX. Das ist irgendwie eine gut nutzbare Usability. Das ist sehr stark noch geprägt von dem Terminus Design. Und bei Design geht es immer irgendwie um das, was letztendlich zu sehen ist und was man bedienen kann. Und das Interface ist halt eben nur in diesem ganzen Spektrum ein Element, was man gut beherrschen muss, eben mit UI Design. Also bei UX geht es eben weitaus tiefer. Da betrachtet man nämlich eigentlich alle Erwartungen oder Wahrnehmungen und natürlich auch Reaktionen, die ein Nutzer Anwender mit einem Produkt oder Service halt eben hat. Und. Und eben nicht nur während der Nutzung. Da spielt nun mal das Thema Usability eine große Rolle, sondern auch schon vor der Benutzung und im Produkt während und auch nach der Benutzung. Also wenn ich eben nur hohe Erwartungen erzeuge, durch eine tolle Verpackung, eine tolle Optik von einem von einem Telefon und ich dann bediene und total enttäuscht werde, dann habe ich halt hintenraus eine eher negative Erfahrung.


Ashley: Das heißt es.


Daniel: Und die ist letztendlich prägend.


Ashley: Und das gesamtheitlich betrachten und nicht nur, ich sag mal so, dass das ein Element oder das oder das andere Element.


Daniel: Ganz genau das ist immer so ein populistisches Zusammenspiel.


Ashley: Wenn. Wenn wir das Thema Agile uns mal anschauen häufig gibt es die Diskussion okay, wem gehört dann zum Entwicklungsteam? Es gibt dann der Entwickler, es gibt der Produkt einer, es gibt dann einen Tester oder im Release Manager, aber spielt dann mal so UX oder Data der Designer eine integrierte Rolle in diesen Entwicklungs oder Gesamt Entwicklungsprozess? Oder ist es etwas, was man rausnimmt und vorher macht, sozusagen bevor die Entwicklung anfängt? Sind die Sachen dann eng miteinander verzahnt oder nicht?


Daniel: Im besten Falle sind sie auch hier ganzheitlich verzahnt. Und leider erlebe ich noch allzu oft im Alltag, bei, bei, bei Kollegen aus dem Fachbereich, bei uns in Amadeus, aber auch in anderen Firmen nach wie vor, dass UX sozusagen ein bisschen vorgelagert wird. Da wird dann im Voraus getestet und da werden vielleicht auch die USA Requirements gesammelt und die werden dann eben ein agiles Team weitergegeben. Und meines Erachtens macht man heutzutage aber nur eine erfolgreiche, erschafft man erfolgreiche Erfahrungen, in dem halt alle Parteien, alle Stakeholder eng verzahnt miteinander zusammenspielen. Ich sage da mal gerne Wix ist ein Teamsport, weil es halt eben total wichtig ist für die gesamte Erfahrung. Da kann man jetzt ein sehr komplexes UI haben, was vielleicht sehr stark auf den Nutzer eingeht, was aber zwei Minuten zum Laden braucht. Und dann ist die Erfahrung eigentlich schon nie mehr so gut, weil da muss ich sehr lange warten, bis halt irgendwelche Requests verarbeitet werden. Und da spielt halt eben auch sowas wie Dev OPs mit rein, dass man schaut, wird das da genauso betrachtet und ist das auch gut zu entwickeln? Und da ist der grundsätzlich der agile Ansatz, wenn man schon eine gewisse Reife hat, eigentlich genau der richtige. Also erst mal, dass alle ihre Perspektive mit an den Tisch bringen und man gemeinsam überlegen kann Wie schaffen wir denn hier eine richtig gute Erfahrung? Und vielleicht muss da die UI auch mal an der einen oder anderen Stelle zurückstecken. Und auf der anderen Seite hat man durch dieses iterative Herangehen, dass man halt möglichst früh diese Experimente schafft, eigentlich die perfekte Basis, UX zu testen, dass man sagt Okay, dann lass doch jetzt mal schauen, wir haben hier schon was bedienbar, es gebaut. Wie, wie empfindet das denn unser Nutzer?


Ashley: Wir kommen dann zu diesem die die Frage Wie empfindet man oder wie findet der Nutzer diese Sachen und wie man das, ich sage mal so testen kann? Gleich. Aber du hast gesagt, im besten Fall sind die Sachen verzahnt. Es gibt natürlich so Teams in einem Startup, wo da ist vielleicht eine andere Dynamik als beim Agil Team, in einem, in einem Großkunden, sei es E.ON oder oder Amadeus. Als Beispiel gibt es dann irgendwelche, sage mal so Projekt, Größen oder Themen, wo du sagst, okay, da macht es keinen Sinn, dann, dass diese enge Verzahnung da ist, gibt oder oder ist das grundsätzlich für jede Art von Projekt, egal ob klein oder groß, dann sinnvoll, das so zu machen?


Daniel: Ich denke, da gibt es nicht so die, die eine Regel für große oder kleine Projekte. Ich kann immer nur empfehlen und empfehle das auch den Projektteams bei uns. Wenn man mit etwas relativ neu startet, egal ob klein oder groß, dass man halt eben so eine User Research Phase vorweg schiebt, dass man möglichst viele Daten sammelt, um um im besten Falle schon validiert zu haben, ist das, was wir bauen, denn das, was auch mein Anwender braucht? Und dazu kann ich natürlich so qualitatives Research machen und Interviews mit Nutzern führen. Ich kann aber auch bestehende Systeme einfach prüfen. Und ich kann aber auch einfach mal ausgiebig mit dem Kundensupport sprechen. Was kommen denn hier für Anfragen rein? Also ich habe ganz viele Datenquellen eigentlich, derer ich mich sehr einfach bedienen kann, bei kleinen wie auch bei großen Projekten. Aber je größer das Projekt wird und damit auch das verbundene Budget, desto ratsamer ist es natürlich, möglichst früh mit dieser Validierung anzufangen. Dann sind wir hier und.


Ashley: Wenn ich nicht die Mittel Mittel, sei es dann Geld oder sei es dann Leute, wenn ich diese Mittel nicht haben, um genau diese ist immer so diese intensive use research zu machen. Gibt es dann Alternativen? Kann man sagen okay, 80 20 Regel ich ich mache nur ein Teil mehr gut, wenn du dann echt, wenn nicht Antwort ja ist, welche Zahl wäre das? Oder ist das eher oder ist das so wirklich ein ein Muss? Weil wie gesagt, nicht jede Firma hat dann genug Mittel zur Verfügung oder gegebenenfalls genug Zeit Fragezeichen, um diese intensive Recherche zu machen.


Daniel: Auch das ist ein zweischneidiges Schwert. Ich glaube, je nachdem, was man bauen will, kann man schon sich an Best Practices bedienen. Dann gibt es bestimmte Interaction Architekturen, Menüführung, was weiß ich. Sag jetzt mal Kauf, Formularen, Buchungen, das Formular oder ein Kaufprozess im eCommerce, das ist schon weitestgehend. Gibt es da gute Best Practices, da kann man sich daran orientieren, da macht man schon mal grundsätzlich nichts falsch. Und dann hat man vielleicht diese 80 % erreicht, von denen du sprachst. Aber ansonsten, wenn man sich scheut, Geld in die Hand zu nehmen, bezahlt man in der Regel für Themen, wo es keine Best Practices gibt, vor allem im B2B Umfeld oder so wenn ich einen Experten Nutzergruppe habe und ich baue einfach mal aus dem Bauch heraus, dann bezahle ich in der Regel das hinten immer doppelt drauf, weil dann muss ich anfangen zu ändern oder aber es geht online und naja die Nutzer haben Probleme damit zu nutzen. Dann muss es muss ich irgendwie Hilfe Schulungen anbieten, dann laufen viel mehr Fragen beim Kundensupport auf. Das sind alles zusätzliche Kosten. Habe ich vielleicht am Anfang eingespart, aber die muss ich hinten raus wieder bezahlen.


Ashley: Ja, ich denke auch kommt die Frage. Ich sage mal so, dann ich sag mal so, ich gebe dir dann das Mittel, du hast das Geld bekommen von mir, um das alles, alles dann zu recherchieren. Wie macht man es dann messbar? Wie, wie kann man wirklich sagen okay, wir haben dieses Geld in dieses Zeit investiert, um frühzeitiger rechtzeitig diese Analysen, diese Recherchen zu machen. Gibt es dann Methoden, Möglichkeiten, das dann messbar zu machen, dass man wirklich sehen kann, okay, diese Investition hat sich gelohnt.


Daniel: Wie? Ja, natürlich. Das ist eigentlich auch essenziell in dem ganzen UX Bereich, das man eben von Anfang an misst und seine Entscheidung letztendlich auf den gemessenen Daten oder auf den gemessenen Daten beruht. Also ich kann natürlich was bauen und sagen okay, ich mache einen schnellen Usability Tests, da reichen vielleicht schon drei Nutzer, um die groben mangels Mängel zu beseitigen. Wenn ich eine größere Nutzergruppe habe, dann kann ich natürlich mit Tracking, Daten und Analytics sehr gut arbeiten. Man muss sich halt im Klaren sein wie wie sieht der Erfolg aus? Also geht es da um ein Geschäfts Ziel? Geht es darum, dass ich irgendwie Verkauf steigern will? Oder geht es einfach darum, dass ich meine meine Nutzer, dass sie effizient mit einer Software arbeiten? Und vielleicht nur je nachdem gibt es für alles passende Metriken, die man zugrunde legen kann und wo man halt dann auch die entsprechenden Daten für schöpft. Also ich empfehle da auch immer möglichst eine gute Mischung aus qualitativer Testung mit den Nutzern und später halt eben quantitativ nochmal zu belegen. Läuft das wirklich in die Richtung?


Ashley: Das heißt, man macht das nicht nur einmal und das war's dann. Aber dass man dann kontinuierlich hinterher das misst und dann gegebenenfalls Feintuning macht, falls dann die, die die Resultate dann zeigen, dass es doch nicht so läuft oder funktioniert wie erwartet. Genau. Ähm, hast du dann Beispiele, die du erzählen kannst, was passiert, wenn man keine oder nicht genug Zeit rechtzeitig in das Thema User Experience investiert? Bzw. Auch positive Beispiele?


Daniel: Ähm, absolut. Also da gibt es relativ viele. Ich hatte das glaub ich schon mal erwähnt, dass man sagt, okay, wir bauen was, releasen das und letztendlich habe ich einige Nutzbarkeit Probleme mit verbaut. Die habe ich halt vorher nicht frühzeitig erkannt und die erkenne ich jetzt erst. Habe vielleicht sogar schon in die Werbung investiert und dann läuft die Support Hotline voll. Es lohnt sich halt immer den Nutzer der Anwendung und nicht nur den Kunden, der vielleicht letztendlich für die Anwendung bezahlt. Gerade in diesem B2B Umfeld eben einfach mal kennenzulernen. Da gibt es halt verschiedene Methoden. Eine sehr gute Methode in einem Profi Umfeld ist, wenn man einfach mal zu dem Kunden fährt. Da habe ich ein Beispiel aus junger Vergangenheit. Da gab es sozusagen die ersten ersten Entwicklungen in Richtung einer neuen Lösung, auch für ein Callcenter im Preisbereich und wie halt so Entwickler typisch man arbeitet auf großen Monitoren und da war halt auch schon mal die UI so abgebildet. Und letztendlich konnte ich das Team davon zu überzeugen, mal gemeinsam mit in dieses Kundensupport Zentrum zu fahren. Erstens um mit den Menschen zu sprechen, aber auch deren Arbeitsplatz und Arbeitsalltag kennenzulernen. Und dann war sehr schnell klar okay, die haben ja nur die haben zwar zwei Monitore, aber kleine. Und die Rechner, die die haben, die sind ja gar nicht so leistungsstark. Die sind schon ein bisschen in die Jahre gekommen und die telefonieren, machen teilweise 150 Telefonate am Tag, das mal mitzuerleben. Die haben gar nicht so viel Zeit, lange irgendeine Suche zu bedienen, sondern es muss ultra effizient sein. Und wir müssen vielleicht eher viel weniger Inhalt am Bildschirm darstellen, damit das viel einfacher zu verarbeiten ist, wie eben von den Menschen da und von den Anwendern. Und das hat dann schon sozusagen dazu geführt, dass das ganze Team das ganz anders wahrgenommen hat und auch selber immer wieder sich diese Situation vor Augen gerufen hat und sich selber versucht hat, in diese Perspektive zu setzen. Okay, ich sitze jetzt hier und wie fühlt sich das denn jetzt an, wenn man meinen, die neue Funktionalität, die ich gerade im UI abgebildet habe, baut oder bedient?


Ashley: Das heißt wirklich, ich sage mal so, in den Sitzplatz des Kunden zu sitzen, sozusagen, wenn ich das so übertragen darf, um wirklich zu sehen, wie ist es tatsächlich draußen bei dem Kunden? Gibt es da irgendwelche irgendwelche Zeiten, wo du richtig so ein Aha Effekt gehabt hast? Das war ein gutes Beispiel da mit dem mit dem Bildschirm Monitor. Aber irgendwelche Aha Effekte, wo du, wo du dann so Rapid Prototyping oder ähnliches gemacht hast und komplett anderen Feedback und wo du schon mit dem Kunden gesprochen hast bzw vor Ort warst, wo du wo du sagst Mensch, das hatte ich nicht erwartet, dass diese Art von Feedback zum Usability kam.


Daniel: Ja, wir hatten auch bei. Bei einer Sache waren wir uns sehr sicher, dass das, was wir da gebaut haben, auch schon auch basierend aus aus Gesprächen. Da ging es um eine Software für Reisebüros, halt eben das, dass wir auf der richtigen Fährte sind. Und dann haben wir aber eben schon auch noch mal wirklich so eine Prototyp Phase vorgeschoben, wo wir teilweise, also wirklich ganz rau, ein paar paar Gedanken, die der Product Owner hatte, wirklich einfach nur auf Papier visualisiert haben und dann aber auch schon die Sachen, wo wir uns so sicher waren, eben wirklich so als Prototyp gebaut haben, als Click Dummy. Und damit sind wir dann noch mal zu den Reisebüro Agenten gefahren und haben dann festgestellt, dass das eben die Ideen, die wir da auf Papier visualisiert haben, einfach überhaupt gar keinen, gar kein Bedürfnis, gar keinen Nutzen erfüllen würden. Und bei dem anderen hat es eine sehr gute Konversation ausgelöst über Ist das jetzt wirklich effizient oder nicht? Und so sind wir dann wieder nach Hause gefahren, gespickt mit ein paar neuen Ideen und dem Wissen, dass wir echt quasi mit einem sehr geringen Zeit Invest sehr viel Informationen gewonnen haben, um jetzt wirklich bestimmte Sachen in die Entwicklungen weiterleiten zu können, also letztendlich auch viel Geld gespart.


Ashley: Hat, immer sehr gut ist. Ja, ja. Gibt es irgendwelche andere? Ich sage mal so wichtige Punkte, die du dann erwähnen würdest. Wir haben über das Thema kontinuierliche Prozess, dass es durchs Design wirklich mit eingebunden werden muss in das gesamte Entwicklungsprozess. Und wie du so schön gesagt hast, das ist ein Teamsport, nicht nur Entwicklung, sondern auch, dass das wirklich aller aller, ich sage mal so, Facetten berücksichtigt werden können. Und auch dieses Thema GEMA früh raus zu dem Kunden und Versteher, wirklich wie der Kunde arbeitet und und und macht das ja mit mit Click Dummys Prototyps oder auch Skizzen wie du gesagt hast gibt, gibt es dann irgendwelche andere Details, die du dann unsere Zuhörer auf dem Weg geben möchtest?


Daniel: Was man auf jeden Fall sagen kann, dass das Ganze wirklich wahnsinnig viel Spaß macht. Und jedem Einzelnen, das ist oft nicht so bewusst. Das klingt immer nach Anstrengungen und zusätzlichen Kosten und es dauert ja auch viel länger, wenn man das vorher macht. Aber meine Erfahrung ist Egal mit wem ich Research gemacht habe, egal in welcher Art und Weise, letztendlich hatten alle da sehr viel Spaß dran. Und nicht zuletzt, weil weil man wirklich den Anwender kennenlernt, für den man das baut. Und selbst auch die Anwender, wenn man mal auf die zugeht. Die haben auch das Gefühl, Teil dieses Prozesses zu sein. Gerade im B2B Umfeld, da habe ich heute häufig so Töne wie Wunderbar, dass ich jetzt hier meinen Alltag mit mitgestalten kann und mit verbessern kann. Und dann glaube ich, wenn das alles zusammenkommt und wenn man dann sieht, dass das, was man gebaut hat, halt auch genau den Nutzen erfüllt, den es erfüllen soll und im besten Falle noch irgendwie den Umsatz bringt, den es bringen soll. Dann hat man eben diese Win Win Situation aus alten Perspektiven.


Ashley: Es hat Spaß gemacht, einen Gewinn für die Entwicklungs Mannschaft oder die gesamte Mannschaft, aber auch ein Gewinn für für den Endkunden auch. Wie du sagst auch dieser, dass der Kunde auch mit einbezogen wird in dem Prozess. Ja genau. Und ich denke dann ja, ich sag mal so ein bisschen, dann das abschließende Zusammenfassung, dass ich so investiere. Zeit für die UX, um wirklich, wenn man zum Thema oder zum Punkt des Austausches kommt, dass man ein Produkt hat, was wirklich relevant ist, nutzbar ist von den Endkunden und dass der Endkunde auch sich mit eingebunden gefühlt hat während dieses Prozesses, dass keiner so große Überraschungen kommen, zum Tag des Launch sozusagen, wäre das fair? Auch sozusagen. Ich sage mal so als abschließender Zusammenfassung.


Daniel: Ja, absolut. Das kann ich gut mitgehen.


Ashley: Ja, super. Daniel, ich bedanke mich recht herzlich für das Gespräch. Ich glaube, du hast nicht. Ich glaube nicht. Ich weiß, du hast da wirklich viele, viele, sehr, sehr gute Punkte erwähnt. Und dass unsere Zuhörer wirklich mal drüber nachdenken können oder mehr drüber nachdenken können, wie und was es ist und wie man dieses Prozess und ich glaube die Betonung da ist wirklich auf das Wort Prozess verfeinern und nutzen kann. Vielen, vielen herzlichen Dank für deine Zeit und ich würde es mal sagen bis die Tage.


Daniel: Ich danke dir auch ganz herzlich.


Ashley: Ciao.


Daniel: Ciao.


Ashley: Taktsoft Campus Podcast! Der Podcast für Software und IT Professionals! Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass er dabei wart. Euer Taktsoft Campus Podcast Team.