Wenn alles wie vorgesehen läuft, können unabhängige Systeme korrekt miteinander interagieren und zu einem reibungslosen Gesamtprozess führen. Was aber, wenn eine Randbedingung eintritt, die diese Interaktion stört, wie sie der Autor im ersten Teil des Artikels am Beispiel der Wartungsverzögerung eines Fluges beschrieben hat? Wie kann ein UX-Team in so einem Fall für ein angenehmes, flüssiges Kundenerlebnis sorgen? Dazu muss es über ein geeignetes Instrumentarium verfügen! Dieser zweite Teil knüpft nahtlos an die vorangegangenen Überlegungen an.
Sich in ein komplexes Problem verlieben
Es gibt eine alte Redewendung: Großartige Designer verlieben sich nicht in ihre Lösung. Großartige Designer verlieben sich in das Problem.
Man kann sich leicht ein kollaboratives Tool für Smartphones oder andere portale Geräte vorstellen, das ein jedes Team nutzt. Mechaniker könnten beschreiben, worin das Problem besteht. Sie könnten eine Schätzung eingeben, wann die Maschine voraussichtlich repariert sein wird. Piloten und Gate-Betreuer würden diese Informationen sehen und sie an die Passagiere weitergeben. Oder die Informationen könnten ihren Weg direkt auf die Smartphones der Fluggäste finden.
Wir müssten auch beim Umbuchungsproblem helfen. Wie kriegen wir die Passagiere bei einer Minimierung der Störungen auf den Weg? Passagiere en masse umzubuchen, erzeugt ein weiteres Kommunikationsproblem (Woher weiß ein Passagier, dass er zu einem anderen Gate laufen muss?) und belastet das System. Außerdem sind Schätzungen von Mechanikern bekanntlich nicht unfehlbar. Ein Problem, das zunächst ernst aussieht, kann oft durch einen einfachen Neustart der Maschine behoben werden. (Beruhigender Gedanke, nicht?)
Wenn das Design-Team sich auf Lösungen für Passagiere, die Verspätungen ausgesetzt sind, fokussiert, ehe es aufdeckt, wie die unabhängigen Systeme funktionieren, wird es scheitern. Sie müssen Zeit investieren, um die unabhängigen Systeme zu untersuchen, damit sie sehen, wo es Schwachstellen gibt, und ein reiches Verständnis der Beschränkungen und Interaktionen aufbauen. Sie müssen sich in jedes der unabhängigen Systeme und in jedes der Probleme, die diese erzeugen, verlieben.
Beobachtungen und Interviews bringen uns hier nicht weiter
Unsere Tools für die Nutzerforschung sind die guten alten Standards der Beobachtung und der Interviews. Wir marschieren ins Feld und sehen die Probleme, wenn sie auftreten. Wir interviewen die beteiligen Leute, um ihren Kontext (und wie sie darüber denken) zu verstehen.
Bei Randbedingungen ein auftretendes Problem zu sehen, ist, nun ja: ein Problem. Das JetBlue-Team könnte einfach in einer Flughafenhalle warten, bis bei einem der Flüge eine Wartungsverzögerung auftritt, aber das ist kostentechnisch ineffizient. Dort zu sein, um das Problem zu beobachten, wenn es gerade auftritt, ist fast unmöglich.
Wenn sie die Situation verstanden haben, könnten sie die Mechaniker, Piloten, Gate-Betreuer und das Betriebspersonal nach den Fakten befragen. Allerdings bringt das wiederum eigene Probleme mit sich. Es ist schwierig, die richtigen Fragen zu stellen, die zu einem tiefen Verständnis führen, wenn wir nicht wissen, welche Fragen wir stellen müssen.
Die altbewährten Methoden der Bobachtung und der Interviews werden es nicht bringen. Wir brauchen etwas anderes, das uns zu tiefen Einsichten führt, die uns sagen, wie wir Design betreiben im Hinblick auf komplexe, unabhängige Systeme, die vereinzelten Randbedingungs-Problemen ausgesetzt sind.
Kollektive Story-Ernte
Marc Rettig hat Herausforderungen wie dieses JetBlue-Problem schon vorher gesehen. Im Rahmen seiner Arbeit bei Fit Associates arbeitet er regelmäßig mit Organisationen zusammen, die krasse Interaktionsprobleme zwischen unabhängigen Systemen lösen müssen. Seine Kunden haben ein gutes Händchen dafür, die Dinge am Laufen zu halten, wenn alle Systeme normal funktionieren. Es sind die Randbedingungen, die sie plagen, und hier kommt Marc ins Spiel.
Ich fragte ihn, wie er versuchen würde zu verstehen, was bei diesem Problem passiert. Er sagte mir, dass er eine seiner Lieblingstechniken einsetzen würde: eine kollektive Story-Ernte.
Wenn Marc diese Technik moderiert, lädt er alle, die das Projekt beeinflussen, ein, inklusive des Design-Teams, der Stakeholder, des Umsetzungsteams und anderer Leute, die ein Wörtchen dabei mitzureden haben, wie die finale Lösung aussehen wird. Dann lädt er Geschichtenerzähler ein – Leute, die die Probleme erlebt haben, die die Gruppe zu lösen versucht. Bei dem JetBlue-Problem wären Geschichtenerzähler Mechaniker, Piloten, Gate-Betreuer, Flugbetriebs-Mitarbeiter und sogar Passagiere, die eine Wartungsverzögerung mitmachen mussten.
Schließlich teilt Marc die Gruppe der Projektbeeinflusser in kleinere Gruppen ein, mit einem Geschichtenerzähler in jeder. Er bittet jeden der Beeinflusser, sich eine Linse zu nehmen und durch sie zu lauschen. Eine Linse könnte die Wiedergabe der Geschichte sein, eine andere die Momente des Durchbruchs und eine dritte die Prinzipien, die man aus der Geschichte lernen könnte.
Wenn die Geschichtenerzähler ihre Erlebnisse während der Wartungsverzögerung nachvollziehen, hört jedes Gruppenmitglied bewusst zu, während es sich auf seine zugewiesene Linse fokussiert. Sind die Geschichtenerzähler fertig, reflektiert die Gruppe, was sie gehört hat, und wiederholt die wichtigen Elemente gegenüber dem Erzähler.
Als nächstes bittet Marc jedes Projektmitglied, dem eine Linse zugewiesen ist, seine Notizen mit allen anderen zu vergleichen, die ebenfalls durch diese Linse lauschen. Die Leute mit der Wiedergabe-Linse teilen die unterschiedlichen Erzählungen miteinander, die sie gehört haben, während die Leute, die nach Momenten des Durchbruchs gehorcht haben, ihre Aufzeichnungen vergleichen. Jedes Teammitglied teilt die Story, die es gehört hat, mit dem Rest, und sie suchen nach Gemeinsamkeiten und Unterschieden sowie nach deutlich erkennbaren Mustern.
Was aus einer kollektiven Story-Ernte hervorgeht, ist ein tiefes, reiches Verständnis des Problems. Nachdem sie gehört haben, was das Team gelernt hat, berichten auch die Geschichtenerzähler, dass sie neue Aspekte im Hinblick auf ihre Erlebnisse kennengelernt haben. Und die Projektbeeinflusser haben viel besser verstanden, welche Dimensionen es im Zusammenhang mit dem Problem gibt und wie die unabhängigen Systeme miteinander interagieren (oder nicht), wenn eine Randbedingung auftritt.
Storytelling: Die Macht der Retrospektion entfesseln
In User Research 101 haben wir gelehrt, dass wir nicht auf unsere User hören sollten. Das, was unsere Nutzer sagen, ist nicht so wichtig wie das, was sie tun. Deshalb fokussieren wir uns auf die Beobachtung ihres Verhaltens.
Aber wenn wir es mit Randbedingungen zu tun haben, werden unsere Beobachtungen nicht funktionieren. Aus diesem Grund sind Techniken wie die kollektive Story-Ernte so wichtig. (Und es gibt einen Haufen Techniken, die so ähnlich wie die Story-Ernte sind.)
Diese Techniken bitten nicht den User, das Problem zu lösen. Stattdessen nutzen die Techniken die Macht einer Geschichte, um auseinanderzunehmen, was dieses Problem so schwierig macht. Wenn wir einen Geschichtenerzähler bitten, ein schwieriges Erlebnis nochmals zu durchleben, hören wir es aus seiner Sicht der Dinge.
Wenn wir beginnen, die Blickwinkel der unterschiedlichen Geschichtenerzähler miteinander zu vergleichen, erkennen wir, wie sich Muster abzeichnen. Wenn wir Leute bitte zu reflektieren, was passiert ist, und verschiedene Linsen einsetzen, während wir zuhören, erschaffen wir eine Umgebung der Retrospektion, die sehr mächtig ist. Aus dieser Umgebung treten Details, Facetten und Nuancen hervor, die uns dabei helfen, zu einem gemeinsamen Verständnis des Problems zu kommen, das wir zu lösen versuchen.
Wir bitten unsere Teilnehmer nicht darum, uns zu sagen, was wir bauen sollen. Wir integrieren die Geschichten, die sie von ihren Erlebnissen erzählen, in unser kollektives Problemverständnis. Dann sind wir auf dem Weg, das Problem mehr zu lieben, als wir die Lösung je lieben könnten.
Dieser Artikel wurde im Original am 2. Dezember 2015 unter dem Titel For an Edge Condition, Seeing the Problem is a Problem von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.
