Usability – Telekom, Deutsche Bahn und wie es nicht geht

Die Tage habe ich mir mal wieder ein paar Gedanken zum Thema Usability gemacht. Anstoß dafür waren 2-3 Erlebnisse mit den Apps der Telekom sowie der Deutschen Bahn. Bei der Wahl des Smartphones gibt es eine große Auswahl und viele Vergleichportale wie handypreisvergleich.de, die einem bei der Auswahl helfen. Ist das Smartphone erstmal angeschafft, müssen passende Apps her.

Bei der Wahl der Apps, vorallem je spezieller sie sind, ist die Auswahl dann jedoch teils wesentlich geringer. Im Falle der in diesem Artikel besprochenen Bahn-App, ist sie leider die einzige Wahl. Eine wirklich Alternativ-App gibt es nicht. Umso ärgerlicher ist es, wenn dann genau diese einzig existierende App auch noch gravierende Mängel aufweist. Gleich vorneweg, beide genannten Apps haben klar Ihre guten Seiten und dennoch beinhalten sie ein paar Mängel, die in meinen Augen durch durchdachte Konzeption, Usability- und Abnahmetests hätten vermieden werden können.

Doch eins nach dem anderen. Beginnen wir mit der App der Deutschen Bahn und einem Szenario welches vielleicht nicht nur mir bekannt sein dürfte.

40km Strecke, geplante Reisezeit 8 Stunden

Lassen wir uns die obige Zwischenunterschrift auf der Zunge zergehen. Die durchschnittliche Reisegeschwindigkeit beträgt laut Zwischenüberschrift 5km/h, also in etwa dem Tempo eines Nordic Walkers. Leider geht es hier nicht um eine Nordic Walking Tour, sondern um die einzige Bahnverbindung, die mir die App der Deutschen Bahn letzte Woche ausgespuckte. Und das bei einer Verbindung zwischen zwei Großstädten und deren Randgebieten (Essen > Düsseldorf > Meerbusch) um 18:00 während der Woche.

Der Knackpunkt war folgender: Die App hat so reagiert, wie sie reagieren soll. Ich war lediglich zu “doof” sie richtig zu bedienen. Schließlich habe ich als Zielpunkt eine Haltestelle angegeben, die an diesem Tag nicht mehr angefahren wurde.

Gute Usability sieht in meinen Augen dennoch anders aus. Schließlich befand sich in unmittelbarer Nähe eine U-Bahn-Haltestelle, die noch angefahren wurde. Dumm nur, wenn man sich am Zielort nicht auskennt und nicht weiß, dass es a) solch eine Haltestelle gibt, noch b) den Namen der Haltestelle kennt. Für mich also ein unüberwindbares Problem, was ich ohne Hilfe anderer Personen nicht lösen konnte.

Sicher ans Ziel, ohne den exakten Ort zu kennen

Die logische Konsequenz aus dieser Problematik wäre in meinen Augen ein Feature, welches wie folgt aussehen könnte.

• Ist die Reisezeit der nächstmöglichen Verbindung mehr als doppelt so lang, wie die durchschnittliche Reisezeit dieser Verbindung, so muss es sich um einen Sonderfall handeln. (z.B. dass die letzte Verbindung für diesen Tag bereits erreicht ist.)
• Gibt es eine Haltestelle in unmittelbarer Nähe (z.B. im Radius von 500m) und eine Verbindung die diese Haltestelle schneller anfährt, als die eigentliche Verbindung, so schlage dem Nutzer vor, diese Haltestelle anzufahren.

Eigentlich kein großes Ding aus Entwicklerperspektive. Für den einzelnen Nutzer jedoch ein Feature, dass ihm das Leben wesentlich erleichtern würde.

Live-Auskunft vs. Wo ist meine Verbindung hin?

Ein zweiter Punkt, der die App für mich zu einem Hindernisparkour machte, ist die sogenannte Live-Auskunft. Im Menüpunkt “Reiseauskunft” gibt es sowohl ein Select-Menü mittels dessen man die gewünschte Abfahrts- bzw. Ankunftszeit angeben kann, als auch 3 Buttons, mit denen man die Zeitpunkte “Jetzt”, “In 15 min” und “In 1 Std.” festlegen kann. Knapp darunter befindet sich ein blasser, grauer Text mit Auswahlbox, über den man die sogenannte Live Auskunft anwählen kann. Ist diese aktiviert, so lassen sich keine Zugverbindungen anzeigen, die in der Vergangenheit liegen.

Folgendes Beispiel soll zeigen, weshalb dies zu einem Problem in Sachen Nutzerfreundlichkeit werden kann bzw. schon geworden ist.

Ich suche meine Verbindung. Der Zug kommt um 16:00. Ich erreiche den Zug, steige ein und fahre los. Nun öffne ich nach einiger Zeit erneut die App, um zu schauen, wann und auf welchem Gleis ich ankomme. Leider zeigt mir die App nicht mehr meine ausgewählte Verbindung an, sondern leitet mich wieder zum Reise-Auskunfts-Dialog weiter. Warum dies so ist und warum dies scheinbar nur sporadisch bzw. willkürlich geschieht, kann ich mir nicht erklären.

Der Auskunftsdialog zeigt mir nun die aktuelle Uhrzeit an. Ich suche ja aber eine bereits abgefahrene Verbindung, sprich jenen Zug, in dem ich just in diesem Moment sitze. Als Abfahrtszeit wähle ich nun also 16:00 aus. Dies ist ohne Probleme möglich. Möchte ich aber nun die Auswahl bestätigen, so springt die Abfahrtszeit wieder auf die aktuelle Uhrzeit. Ohne jeglichen Hinweis oder einer Begründung.

Bis man dann erst einmal raus hat, dass man das vorangewählte “Live Auskunft”-Feature abwählen muss, damit man Zugverbindungen auswählen kann, die in der Vergangenheit liegen, vergeht schon mal einige Zeit. Auch hier behaupte ich, dass Benutzerfreundlichkeit anders aussieht.

Wie auch schon beim ersten Szenario hätte ich auch hierfür einen Lösungsansatz:

• Variante 1: Wählt der Nutzer eine Abfahrtszeit in der Vergangenheit aus, dann wähle die Option “Live-Auskunft” automatisch ab
• Variante 2: Wählt der Nutzer eine Abfahrtszeit in der Vergangenheit aus und die Option “Live Auskunft” ist angewählt, dann gebe eine Meldung aus à la “Es besteht ein Interessenkonflikt. Bitte entscheiden Sie sich für eine Live-Auskunft oder eine Abfahrtszeit in der Vergangenheit.

Und wenn ihr schon dabei seid, liebe Bahn-Informatiker, dann entfernt doch auch bitte, bitte diesen Bug, der eine bereits ausgewählte Verbindung beim erneuten Öffnen der App wieder schließt.

T-Mobile Hotspot App und warum Usability auch Grenzen haben darf

Das zweite Beispiel, welches ich in diesem Artikel bringen möchte, ist die “HotSpot Login”-App der Deutschen Telekom AG. Diese App, im Speziellen die iOS-Variante bringt ein vermeintliches Feature mit, bei dem sich mir die Nackenhaare im Akkord aufstellen. Es geht darum, dass die App es ermöglicht, sich automatisch an den Hotspots der Telekom anzumelden.

Der Clou dabei – die App ist dermaßen “benutzerfreundlich”, dass dieser nicht einmal mehr seine Zugangsdaten eingeben muss. Richtig gehört, nicht mal nach einer frischen Installation. Die App greift die Zugangsdaten über einen Webservice der Telekom ab und macht sich dabei der Funknummer des Teilnehmers sowie eines in der App hinterlegten Secrets zu nutze. (Wer mehr zu der Technik erfahren möchte, sollte sich diesen Artikel und seine Quellen durchlesen.)

Das mag zwar alles unheimlich praktisch klingen, aber im Endeffekt ist es nicht mehr oder weniger als eine Schnapsidee im Rahmen der Softwareentwicklung. Dass man das Secret aus der App auslesen kann und dann mit Kenntnis einer Funknummer beliebige Zugangsdaten abrufen kann, ohne dass der eigentliche Inhaber des Hotspot-Accounts etwas davon mitbekommt, ist schlichtweg fahrlässig.

Usability hin oder her, es sollte in meinen Augen niemals solch ein Datenleck geschaffen werden, nur um die Usability bis aufs letzte zu steigern. Sicher, vorher mussten die Nutzer bei jedem Loginvorgang die vollständigen Daten eingeben, was sicher auch keine dauerhafte Lösung sein konnte. Aber warum implementiert man nicht einfach den goldenen Mittelweg? Dieser könnte doch so einfach sein:

• Bei der Erstinstallation gibt der Nutzer seine Zugangsdaten einmalig an.
• Die Zugangsdaten werden nun mittels einem in der App hinterlegtem Secret, welches gerätespezifisch ist, verschlüsselt und auf dem Endgerät abgelegt

Aus diese Art und Weise könnte man auf den unsicheren Webservice verzichten und hätte immer noch eine enorme Usability-Steigerung. Statt die Zugangsdaten jedes Mal erneut eingeben zu müssen, müssten die Nutzer diese nur ein einziges Mal in die App eingeben. Ich behaupte, dass die Nutzer diesen einmaligen Aufwand sehr gut verkraften könnten in Anbetracht des Nutzens, den sie dadurch erhalten.

Um das auszunutzen muss man böse sein

Die Telekom wurde übrigens über die Schwachstelle in Ihrem Konzept informiert, weigert sich aber eine alternative Lösung zu implementieren. Die Benutzerfreundlichkeit stehe an erster Stelle und zur Ausnutzung des Webservice bräuchte es “besondere Expertise und kriminelle Energie”.

Schade, da haben die Damen und Herren wohl etwas Grundsätzliches nicht verstanden. Als spezielle Expertise reichen erweiterte Kenntnisse am Computer aus, die zumindest jeder ausgebildete Fachinformatiker mit sich bringt. Und von denen bilden wir jedes Jahr nicht nur eine Handvoll aus.

Das zweite Argument ist die kriminelle Energie. Na klar, jemand der die Lücke ausnutzen möchte, hat so oder so eine gewisse kriminelle Energie in sich. Ergo behauptet die Telekom, platt gesagt, dass das Sicherheitsrisiko zu vernachlässigen sei, weil dafür erst mal kriminelle Fachinformatiker da sein müssten, die die Lücke ausnutzen würden.

Herrlich, lange nicht mehr so gelacht! Dass die Lücke mit böswilliger Absicht genutzt wird, kann also nur noch eine Frage der Zeit sein.

Also noch mal liebe Telekom – bitte, bitte überdenkt euer Usability-Konzept und nehmt euch die Vor- und Ratschläge aus der Community zu herzen.

Fazit

Im Endeffekt ist es doch ganz einfach. Im Falle der Deutschen Bahn haben wir eine solide App, bei der leider vergessen wurde, das Ganze einmal im Feldtest aus Endanwender-Sicht zu betrachten. Im Falle der Telekom, sorgt man sich hingegen um den Endanwender bis aufs letzte und lässt dabei Datensicherheit und Datenschutz links liegen.

Was können wir daraus lernen? Nachfolgend mal ein Leitsatz, den ich aus den obigen Erkenntnissen geformt habe.

Usability im Konzept mit einplanen, durch Test evaluieren, Nutzen maximieren und dabei Datenschutz & -sicherheit nicht verletzen.

Wie seht Ihr das? Ich freue mich auf Kommentare, sowohl aus der Endanwender- als auch aus der Entwicklersicht.

P.s.: Liebe Telekom, liebe Deutsche Bahn,
auch Ihr seid herzlich zum Dialog eingeladen. Die obigen Lösungsansätze dürft ihr gerne jederzeit implementieren und für eure Apps nutzen. Ich freue mich, von euch zu hören!

 

Das Artikelbild steht unter CC-Lizenz und stamm von dariuszka.