UX-Design: Wenn Randbedingungen herrschen, ist es ein Problem, das Problem zu sehen (Teil 1)

Plötzlich war ein kollektives Stöhnen von den Leuten hinter mir zu hören. Ich wusste sofort, dass es eine Störung der Macht gegeben hatte.

Ich drehte mich um und stellte fest, dass die anderen rund 50 JetBlue-Passagiere aus dem Fenster des Flughafens starrte, ihre Blicke auf ein Flugzeug – unser Flugzeug – gerichtet, das gerade vom Gate wegfuhr, ohne dass jemand von uns drin saß. Ich wandte mich wieder dem Gate-Betreuer vor mir zu und sagte: "Unser Flugzeug setzt zurück."

"Ja", antwortete er und sah von seinem Bildschirm auf. "Die Maschine ist auf dem Weg in den Wartungs-Hangar. Wir müssen diesen Gate-Bereich für den 8-Uhr-Flug bereitmachen, der gerade gelandet ist."

Nichts davon überraschte mich. Um 7:15 Uhr, als der Kapitän und die Crew des 7-Uhr-Flugs – des Flugs, auf den die anderen Passagiere und ich gebucht waren – kurzerhand durch die Fluggasttür kamen und vom Gate weggingen, wurde mir klar, dass wir nirgendwohin fliegen würden. Während ich ihren stillen Abgang bemerkte, bekamen die meisten anderen Passagiere davon nichts mit. Es gab keine weiteren Durchsagen vonseiten der Gate-Betreuer, und alle tappten im Dunkeln, ob der 7-Uhr-Flug irgendwann stattfinden würde. Nun schien die wegfahrende Maschine ihre schlimmsten Befürchtungen zu bestätigen.

Ich fragte mich: Könnte das Design-Team von JetBlue eine Lösung entwickeln, die mit der Situation hätte umgehen können? Wie würde man ein großartiges Kundenerlebnis um ein Flugzeug herum designen, das plötzlich in die Wartung muss?

Kleine Prozentsätze und die Regel der großen Zahlen

Wie jede andere Airline wird uns JetBlue sagen, dass das selten vorkommt. Sie werden sagen, dass 99% ihrer Flüge pünktlich abheben, ohne irgendwelche Wartungsverzögerungen.

Und sie haben recht. An einem normalen Tag bringt JetBlue tausend Maschinen in die Luft. An diesem Tag gibt es vielleicht zehn Mal Wartungsprobleme, die eine ernsthafte Verspätung von mehr als ein paar Minuten auslösen. (Wenn wir von verspäteten Flügen sprechen, ist der Start nicht so wichtig wie die Landung. Eine Verzögerung ist dann ernsthaft, wenn für die Passagiere das Risiko besteht, einen Anschlussflug oder ein anderes wichtiges Ereignis zu verpassen.)

Aber übers Jahr gesehen sind das 3.650 ernsthaft verspätete Flieger. Mit im Schnitt 170 Passagieren pro Flug sind das 620.500 Leute pro Jahr, die wahrscheinlich ein wenig erstrebenswertes Kundenerlebnis haben. JetBlue ist nur eine Airline, eine, die zu denen mit den wenigsten Flügen und der neuesten Flotte gehört (was zu mehr Zuverlässigkeit führen sollte).

Wenn wir mit großen Zahlen hantieren, sind auch kleine Prozentsätze große Zahlen. (Das ist die Regel der großen Zahlen.) Ein Prozent Wartungsausfälle auf alle Passagiere und alle Flugzeuge angewandt, ergibt immer noch eine große Zahl an Reisenden.

Es macht Sinn, dass das Design-Team der Airline ihren 620.500 Kunden zu einem besseren Erlebnis verhelfen will, wenn aus einer Wartungsverzögerung Probleme entstehen. Es ist nicht schwer zu erkennen, wo man ansetzen könnte, um die Dinge zu verbessern. Wir könnten eine bessere Kommunikation bieten, was vor sich geht, automatische Umbuchungen zum Endziel der Reise (auch wenn das über eine andere Airline sein muss), die automatische Lenkung des Gepäcks und die automatische Abwicklung der Unterbringung und Verpflegung der armen Passagiere (wozu die Airline verpflichtet sein kann). Computer könnten diese Dinge erledigen, sofern jemand ein System designt und umgesetzt hat, das dies alles übernimmt.

Wie würden diese Lösungen aussehen? Wie könnten die ohnehin schon schwer beanspruchten IT-Systeme der Airline wissen, dass sie diese Arrangements und diese Kommunikation durchführen müssen?

Komplexität von Systemen

Ich habe es in die 8-Uhr-Maschine geschafft. Andere Passagiere hatten nicht so viel Glück. Ein Check des Flugstatus' ergab, dass der ursprüngliche 7-Uhr-Flug den Airport schließlich um 9:42 Uhr verließ.

In diesen Flug waren diverse Gruppen von JetBlue-Leuten involviert: die Gate-Betreuer, die Piloten und die Flugbegleiter, die ich gesehen hatte. Auch die Leute von der Wartung und die Teams des Flughafenbetreibers waren eingebunden. Das Flugbetriebs-Team von JetBlue versuchte, die unausweichliche Kettenreaktion zu beherrschen, die die Verzögerung ausgelöst hatte. Und da waren (nicht zu vergessen) die Passagiere.

Teil dessen, was zu einem frustrierenden Kundenerlebnis der Fluggäste geführt hatte, war, dass diese Gruppen nicht miteinander redeten. Der Pilot und die Crew verließen die Maschine, ohne mit den Gate-Betreuern ein Wort zu wechseln. Auf der digitalen Anzeigetafel stand auch 20 Minuten nach der geplanten Startzeit, dass der Flug um 7 Uhr gehen würde. Niemand vom Flugbetrieb hatte die Anzeige zwischenzeitlich aktualisiert.

Jede Gruppe ist ein unabhängiges System, das sein eigenes Ding macht, um den Flug abzuwickeln. Die Mechaniker haben ihr Set an Prozeduren, Regeln und Beschränkungen. Die Piloten haben das ihre, und ebenso ist es bei den Gate-Betreuern und dem Flugbetriebs-Team. Alle diese unabhängigen Systeme waren fein koordiniert und funktionierten, solange alles wie geplant lief.

Diese unabhängigen Systeme sind nicht mehr fein koordiniert, wenn sie es mit einer Wartungsverzögerung zu tun haben. Bei dieser handelt es sich um eine Randbedingung, einen Vorgang der Systemkoordination außerhalb der Norm. Während es relativ einfach ist, Prozesse, Prozeduren und unterstützende Tools für unabhängige Systeme zu designen, die zusammenarbeiten, hat das Design im Hinblick auf Randbedingungen ein Level an Komplexität, für das die meisten Teams nicht gerüstet sind. Noch wichtiger: Sie haben nicht die Werkzeuge dafür.

Und was nun? Dazu mehr im zweiten Teil des Artikels.

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.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar