Wir haben kürzlich wieder mal einen Usability-Test auf einem iPhone durchgeführt. Getestet wurde der Prototyp für eine iPhone App. Wieder mal war ich – geschieht auch nach vielen vielen Tests immer wieder – erstaunt, was sich da abspielte.

Die versteckten Features

Erstens gibt es so einige iPhone-Standard-Funktionalitäten, die anscheinend auf vielen Geräten brach liegen. Nicht weil es schlechte Funktionalitäten wären oder Features, die niemand braucht. Sondern weil viele Benutzer sie einfach nicht finden (es sind eben doch nicht alle Menschen «Ausprobierer»). So konnte ich Nutzer – die schon über ein Jahr ein iPhone besitzen – beglücken, indem ich ihnen gezeigt habe, dass man auf dem iPhone doch ein «ü» schreiben kann (Taste «u» lange gedrückt halten). Um das rauszufinden habe ich übrigens auch mehr als 2 Monate gebraucht. Oder dass man aus der Mailbox ein einzelnes Mail ganz einfach löschen kann mit der Swipe-Funktion (Mail nach links aus dem Bildschirm schieben). Oder dass man in den SMS suchen kann, wenn man die Nachrichten-Liste nach unten scrollt. Dies nur um einige Beispiele zu nennen.

Der fehlende Back Button

Zweitens konnten wir kürzlich in einem Usability Test mit 8 Testpersonen bei 3 Testpersonen beobachten, dass sie wiederholt die iApp verliessen, weil sie auf den Home Button drückten.

Sie taten dies nicht, weil sie wirklich aus der Applikation raus wollten. Was sie eigentlich vor hatten, war einen Schritt zurück zu navigieren. Da diese Funktionalität (Back Button) aber nicht vorhanden ist und sie nirgends einen Zurück-Button fanden, klickten sie wiederholt auf Home und starteten die Applikation wieder neu.

Auf Websites und in Webapplikationen ist der Back Button heilig und wird so häufig geklickt wie kaum ein anderes Interaktionselement. Mittlerweilen halten sich – zum Glück – die meisten Websites an die Regel «Never break the back button». Wie sieht es aber bei Apps aus? Das iPhone und die «Mobile Human Interface Guidelines» von Apple kennen keinen wirklichen Back Button.

Gemäss den Apple Guidelines wird ein Zurück-Button (links oben) nur eingesetzt, um bei hierarchisch aufgebauten Applikationen wieder eine Ebene nach oben zu navigieren. Navigiere ich also aus einer Liste zu einer Detailseite ist ein Back Button vorhanden. Es gibt aber auch Fälle, in denen dies nicht der Fall ist.

Zur Illustration zwei Beispiele:

1. Der Benutzer befindet sich auf einer Detailseite.
Er klickt dann aus Versehen auf einen Hauptnavigationspunkt in der Tab Bar (z.B. weil der Busfahrer gerade abrupt gebremst hat). Nach Apple Guidelines gibt es keinen direkten Weg zurück zur Detailseite.

2. Der Benutzer befindet sich auf einer Detailseite.
Er klickt dann aus Versehen auf einen Hauptnavigationspunkt in der Tab Bar (z.B. weil der Busfahrer gerade abrupt gebremst hat). Nach Apple Guidelines gibt es keinen direkten Weg zurück zur Detailseite.

Guideline oder nicht Guideline?

Nach unseren Beobachtungen differenzieren nicht alle iPhone User, ob sie sich jetzt auf einer Website (in einem Browser) befinden oder in einer iApp und ob dementsprechend ein Back Button angeboten wird oder nicht. Vielmehr haben sie sich einfach daran gewöhnt, dass man auf Computern und Geräten usw. immer zur zuletzt aufgerufenen Seite zurück kann.

Wir sehen immer wieder, dass sich Entwickler beim Mobile Design ganz auf die Apple-Vorgaben verlassen. Wie auch Web-Usability-Regeln nur die Spitze des Eisbergs zu einer guten User Experience treffen, scheinen diese Vorgaben aber nicht auszureichen –

Wie seht ihr das, liebe Leser: Soll man sich jetzt an die Apple Guidelines halten oder…

Und wie erhält mein Projekt eine gute User Experience? Mit Zeix.

Expertisen und Content

fallback image

Design ohne Inhalt? Nur leere Hülle. Wir helfen Ihnen, Content für Websites und Webapps so zu gestalten, dass Nutzer:innen fehlerfrei navigieren und Sie von höheren Conversions profitieren. Nutzen Sie unsere Erfahrung, um Ihr digitales Angebot kontinuierlich zu verbessern.