Session-Timeout: Dekonstruktion einer gut gemeinten, aber schlecht designten Mikrointeraktion

Session expired

Die American-Airlines-Kundin starrte die Meldung auf dem Bildschirm an: Ihre Sitzung ist abgelaufen. Sie war vorher nicht da gewesen, aber jetzt war sie es. Und die Kundin wusste nicht, was sie damit tun sollte.

Ein paar Momente vorher, nachdem sie gedacht hatte, sie hätte ihre Flugtickets gekauft, öffnete sie ein neues Tab, um ihre Hotelzimmer für die Reise zu buchen. Dann mietete sie ein Auto. Sie kam zurück zum American-Airlines-Tab, um ihre Buchungsnummer in ihren Kalender einzutragen.

Statt der Nummer fand sie die Timeout-Meldung. Alle bestätigten Transaktionen seien gespeichert, aber sie müsse alle Suchen und nicht komplettierten Transaktionen neu starten. War die Transaktion komplett gewesen? Sie war ziemlich sicher, dass sie Tickets gekauft hatte, aber war das bestätigt worden? Sie wusste nicht, was nun als nächstes von ihr erwartet wurde.

Ein kanonisches Sicherheits-Designmuster

Die UX-Designer bei American Airlines haben viele Gründe für einen Session-Timeout. Ein Kunde, der sich noch nicht sicher ist, ob er fliegen will (oder zwischen Konkurrenten hin und her springt), könnte einen zur Hälfte gebuchten Flug offen lassen, ohne ihn je abschließen zu wollen. Die Designer wollen die Flüge zurück in den offenen Bestand bringen, sodass andere Kunden diese Plätze buchen können.

Ebenso könnte sich nach dem Kunden jemand anderes an den Rechner setzen, der im nicht geschlossenen Browser Zugriff auf Details und Daten erhalten würde, die der Kunde eigentlich nicht teilen wollte. Das Ablaufen der Sitzung verhütet eine unschöne Situation in der Zukunft.

Session-Timeouts sind keine American-Airlines-Spezialität. Banken-Websites, Business-Tools und andere Anwendungen loggen jemanden aus, wenn er zu lange braucht, um die Transaktion zu vervollständigen, oder wenn er in der Applikation für längere Zeit ohne Aktivität ist.

Oft beinhalten Session-Timeouts ein Ihre-Sitzung-ist-abgelaufen-Muster. Die Meldung poppt nach einem willkürlich festgelegten Zeitraum auf. Für den Nutzer ist diese Offenbarung selten eine gute Nachricht. Entweder ist er bei einer wichtigen Aufgabe unterbrochen worden oder er sieht sich einfach einer verwirrenden Störung gegenüber.

Eine schlechte Mikrointeraktion, die gut gemeint ist

Das Design-Muster Ihre Sitzung ist abgelaufen ist eine Mikrointeraktion, eine Interaktion im UX-Design, die klein und funktional ist. Mikrointeraktionen machen in jedem Design viel aus, und sie leiden unter einem Mangel an Aufmerksamkeit seitens des Design-Teams. Dieses Design-Muster ist keine Ausnahme.

Die UX-Designer von American Airlines wollen ihre Kunden vor Bösewichten oder Plätze-Hamsterern beschützen. Ein nobles Ziel. Allerdings scheint es, als hätten sie dem Nutzererlebnis keine Aufmerksamkeit gewidmet, das sie durch den plötzlichen Timeout der User-Session erzeugt haben. Wenn er mit der Meldung konfrontiert wird (die eine Form der Fehlermeldung ist), hat der Nutzer nur wenige Möglichkeiten, wie er weitermachen kann.

In der realen Welt passieren Session-Timeouts nicht oft. Im Lebensmittelgeschäft leert sich unser Einkaufswagen nicht plötzlich, wenn wir längere Zeit nichts mehr hineingetan haben. Unser Fernseher gibt nicht alle 15 Minuten eine Meldung aus, die von uns wissen will, ob wir noch im Zimmer sind.

Session-Timeouts sind banal, ein Artefakt dessen, wie mies unsere digitale Welt mit unserer realen Welt interagiert. Wenn unser Laptop akkurat sagen könnte, dass sich jemand anderes vor ihn hingesetzt hat, könnten wir unsere Nutzer besser vor Bösewichten schützen.

Es ist eine gute Intention. Wir schützen die Business-Bedürfnisse.

UX-Design betreiben wir, wenn wir unsere Intentionen in die Welt übersetzen. Der Session-Timeout von American Airlines frustriert die Nutzer, etwas, das wahrscheinlich nicht der Intention der Designer der American-Airlines-Website entspricht. Wie hätten sie das besser machen können?

Besseres UX-Design mit dem Mikrointeraktions-Framework

In den letzten Jahren hat Dan Saffer das Design von Mikrointeraktionen studiert und ein Buch zum Thema geschrieben, das – Festhalten jetzt! - Microinteractions heißt. Dan bricht Mikrointeraktionen in vier Komponenten auf: Feedback, Modi und Loops, Trigger sowie Regeln. Wir können diese vier Komponenten nutzen, um zu schauen, wo wir die Sitzung-abgelaufen-Mikrointeraktion von American Airlines verbessern könnten:

Feedback ist, wie der Nutzer von der Mikrointeraktion lernt. In diesem Fall ist es eine Dialogbox, die ihn informiert, dass seine Sitzung abgelaufen ist, ihm aber nicht sagt, was das bedeutet. Sie erklärt, dass "bestätigte Transaktionen gespeichert sind", ohne zu erklären, was eine bestätigte Transaktion ist oder was Gespeichert-Sein heißt. Ist ein gebuchter Flug eine bestätigte Transaktion?

Würde es Usern helfen, eine Terminologie zu nutzen, mit der sie vertraut sind? (Eine Nachricht wie "Ihr Flug nach Peoria wurde verbucht und eine Bestätigung wurde an Ihre E-Mail-Adresse geschickt" würde mehr Sicherheit dahingehend bieten, dass die Buchung nicht verloren gegangen ist.)

Die Bezeichnung des einzigen Buttons lautet Back to home. Führt er zurück zur Homepage zur wahrscheinlich nächsten Aktion, die der Nutzer vornehmen würde? Was sind die wahrscheinlich nächsten Aktionen? Könnte die Dialogbox dem User eine Liste von Dingen zeigen, die er als nächstes tun könnte (und ihn dann bitten, sich neu zu authentifizieren, um sicherzustellen, dass es wirklich derselbe User ist)?

Modi sind das, wie das System entscheidet, worauf der Nutzer Zugriff hat. Auf der American-Airlines-Website scheinen sie eine binäre Authentifizierung zu nutzen – entweder hat der User Zugriff oder nicht. Wenn die Sitzung abläuft, ändert das System den Status von authentifiziert auf nicht authentifiziert.

Im Hinblick von den nächsten wahrscheinlichen Aktionen: Wäre es für die Designer sinnvoll gewesen, über mehr als zwei Authentifizierungs-Modi nachzudenken?

Trigger bestimmen, wann das UX-Design die Mikrointeraktion aufruft. Es sieht so aus, als würde American Airlines die Session-Timout-Mikrointeraktion anstoßen, wenn ungefähr 15 Minuten seit dem letzten Page-Load vergangen sind.

Ist das Laden der Seite der richtige Startpunkt für die Uhr? Wenn der User an der Tastatur aktiv ist oder den Mauszeiger bewegt, sollte dann der Countdown neu starten?

Warum sind es 15 Minuten? Warum nicht 20? Oder 40? Woher kommen die 15 Minuten und welche Untersuchungen zeigen, dass das das beste Zeitfenster ist?

Sollte für Inaktivität nach der erfolgreichen Flugbuchung derselbe Zeitraum angesetzt werden wie vor der Buchung? Schließlich mag ein nicht gebuchter Flug heiß begehrte Plätze blockieren, aber nach der Buchung sind diese definitiv nicht mehr verfügbar.

Sollte der Trigger überhaupt zeitbasiert sein? Gibt einen besseren Weg, um festzustellen, das der User das Interesse verloren oder den Rechner verlassen hat, wodurch eine Sicherheitslücke entstanden ist?

Was, wenn der Trigger auf der nächsten Aktion basieren würde? Wenn der Bildschirm unberührt bleibt, wird die Mikrointeraktion nicht ausgeführt. Aber wenn der Nutzer versucht, nach dem Timeout etwas zu tun – was wäre, wenn die Mikrointeraktion ihn informiert, dass er sich neu anmelden oder er erneut prüfen muss, ob die Plätze noch verfügbar sind?

Regeln lenken das Verhalten der Mikrointeraktion. Die Regel für den Sitzungsablauf besagt, dem User Feedback zu geben und seinen Modus von authentifiziert auf nicht authentifiziert zu ändern, um weiteren Zugriff zu verhindern. Sagen wir dem Nutzer, dass seine Sitzung abgelaufen ist? Letztlich kann er mit dieser Information nicht viel anfangen. Was wäre stattdessen, wenn wir das UX-Design verharren ließen, bis der User etwas zu tun versucht, das authentifizierten Zugriff voraussetzt, um dann eine Mikrointeraktion zum Einloggen anzustoßen?

Mikrointeraktionen mit Intention designen

Müssen Business-Anforderungen wie die Durchsetzung von Sicherheit und das Bestandsmanagement immer zulasten eines tollen Nutzererlebnisses gehen? Ein Session-Timeout löst ein Problem, aber ist das UX-Design das bestmögliche?

Viele Mikrointeraktionen wie Fehlermeldungen und Alarme sind ohne Intention designt. Oft ist es ein Entwickler, der sich angesichts einer Deadline sputen muss und eine Lösung baut, die eine erkannte Randbedingung abdeckt, ohne einen Gedanken an das Erlebnis der Nutzer zu verschwenden.

Teams, die solchen kleinen Details Beachtung schenken und Fragen stellen, werden bessere Nutzererlebnisse erschaffen. Dans Framework für Mikrointeraktionen hilft uns, uns auf die richtigen Fragen auszurichten, was im Gegenzug dazu führt, dass wir bessere UX-Designs entwickeln.

Dieser Artikel wurde im Original am 14. Januar 2016 unter dem Titel Deconstructing the Poor Design of a Well-Intentioned Microinteraction 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.