iPhone-Apps brauchen niedrige Starthürden

Die meisten Mobil-Applikationen werden nur sporadisch genutzt, deshalb müssen sie bei der ersten Nutzung besonders einfach sein. Insbesondere sollte keine Vorab-Registrierung erforderlich sein, bevor die Nutzer den Nutzen der Anwendung kennen gelernt haben.

 

by Jakob Nielsen (deutsche Übersetzung) - 10.02.2010

 

In Vorbereitung auf unser Seminar zur Usability von iPhone-Apps war ich bei zahlreichen Testsitzungen dabei und habe beobachtet, wie iPhone-Besitzer Hunderte von Anwendungen genutzt haben.

Auf Grundlage dieser Sitzungen haben wir viele spezifische Usability-Richtlinien identifiziert, die es den Leuten erleichtern sollen, Apps auf einem kleinen Touchscreen zu bedienen.

Eines ist klar: Zurzeit sind Apps weit vom Nirvana einer guten User Experience entfernt.Auf manche Weise haben mich diese Testsitzungen daran erinnert, wie wir 1986 frühe Macintosh-Anwendungen getestet haben, als die Interaktions-Designer noch nicht richtig herausgefunden hatten, wie man die Maus und eine grafische Nutzeroberfläche (GUI) mittlerer Grösse am besten einsetzt. Jetzt müssen sie noch einiges hinzulernen, wenn es darum geht, Fingerarbeit auf einer winzigen Nutzeroberfläche zu unterstützen. Es gibt eine ganze Menge von Richtlinien für das Seminar - und es ist mir noch nie schwer gefallen, genug Material für einen reichhaltigen Tag zusammenzustellen, wenn wir eine neue Generation von Nutzeroberflächen getestet haben.

Die Basis-Richtlinie bleibt die gleiche wie 1986: Übertragen Sie eine Nutzeroberfläche nicht von einem alten UI-Paradigma in ein neues. In der Vergangenheit bedeutete das, nicht einfach eine grafische Nutzeroberfläche über etwas zu stülpen, das im Kern immer noch ein Mainframe-Ablauf war. Heute bedeutet das, nicht einfach einen Touchscreen-Zugang an ein PC-orientiertes Design mit direkter Manipulation anzuflanschen: Die Nutzer können mit den Fingern nicht so genau sein, wie sie mit einer Maus klicken können, deshalb sollte die Anzahl der manipulierbaren grafischen Objekte viel kleiner sein (so dass das einzelne Objekt entsprechend grösser sein kann).

Doch trotz dieser Schwächen schliesse ich aus meinen Beobachtungen der iPhone-App-Nutzer, dass sie deutlich weniger leiden als Nutzer mobiler Websites. In der Tat: Die Testergebnisse der iPhone-Apps sind erheblich besser als die Ergebnisse der Website-Nutzung auf dem gleichen Gerät.

Auf mobilen Geräten sind Applikationen einfacher zu nutzen als Websites. (Dies ist der Stand der Dinge; Browser-basierte Websites wären einfacher zu nutzen, wenn die Designer die bestehenden Usability-Richtlinien besser umsetzen würden.)

Warum funktionieren Apps im mobilen Einsatz besser als Websites? Weil folgendes gilt: je grösser die Einschränkungen eines Gerätes sind, desto mehr muss ein Design auf die konkreten Bedingungen der Plattform hin optimiert werden; es genügt nicht, sich auf einen gemeinsamen Nenner für mehrere Plattformen zu verlassen.

Mobile Apps sind Apps für sporadischen Gebrauch

Eine sehr wichtige Schlussfolgerung aus unserer iPhone-Studie lautet, dass die Leute viel mehr Apps installieren, als sie schlussendlich wirklich nutzen.

Im ersten Teil jeder Sitzung haben wir die Nutzer gebeten, mit uns zusammen ihre eigenen iPhone-Apps durchzugehen. Dabei haben wir oft Kommentare gehört wie: "Das habe ich herunter geladen, weil [es sich cool anhörte/mir ein Freund das empfohlen hat], aber ich hatte noch keine Zeit es auszuprobieren." Und oft haben die Nutzer so etwas gesagt wie: "Das habe ich ein paar Mal benutzt, nachdem ich es herunter geladen hatte, aber jetzt nutze ich es nicht mehr - ich bin bloss noch nicht dazu gekommen, es wieder zu löschen."

Die erste Schlussfolgerung daraus ist: Die Zahl der Downloads ist offenbar irrelevant. Um den Erfolg Ihrer Apps zu messen, müssen Sie den wirklichen Gebrauch messen. Und wenn Sie herausfinden wollen, ob Sie wirklich die Bedürfnisse der Nutzer getroffen haben, müssen Sie sogar noch weiter gehen und den nachhaltigen Gebrauch messen. Wenn Leute eine App nur ein paar Mal nutzen und dann wieder aufgeben, dann liegt ein mobiles Design vor Ihnen, das versagt hat.

Ein paar mobile Apps werden häufig genutzt, darunter Facebook und der Wetterkanal. Aber die meisten Anbieter müssen sich von der Hoffnung verabschieden, diese Kategorie erreichen zu können; mobile Apps haben andere Usability-Kriterien als die Kern-Anwendungen im PC und andere als die für tägliche Geschäftsprozesse unerlässliche Software, die die Leute jeden Tag während der Arbeit nutzen.

Mobile Anwendungen werden meist nur sporadisch verwendet. Dies deuted auf eine tiefere Bindung zur App hin als wir bei Websites oft sehen, welche von einer kurzlebigen Bindung geprägt sind.

Ein Beispiel für kurzlebige Internet-basierte Apps sind die Individualisierungs- und Konfigurations-Elemente auf Auto-Websites. Bei solchen Apps zeigen die Nutzer keinerlei persönliche Bindung und erreichen den ersten Bildschirm mit keinerlei Vorwissen über dessen Funktionalitäten ausser dem wenigen, das sie beim Überfliegen der zuerst betrachteten Seiten jener Website mitgenommen haben. (Und wir wissen nur zu gut, wie wenig die Nutzer bei den meisten Website-Besuchen lesen.)

Mobile Apps schneiden ein bisschen besser ab als kurzlebige Website-Apps, weil sich die Nutzer aktiv entschieden haben, sie zu installieren. Dadurch entsteht ein Engagement, die App auszuprobieren - das allerdings oft, wie wir herausgefunden haben, ziemlich niedrig ist. Immerhin ist das Engagement grösser als Null.

Ausserdem erzeugt das Icon der App auf dem Handy eine kontinuierliche Präsenz, die wie eine nagende kleine Stimme sagt: "Probier’ mich aus!" Doch auch dies ist vergänglich, da Nutzer Meister der selektiven Wahrnehmung sind. Grundsätzlich blenden Nutzer nämlich alles aus, das keine Aufmerksamkeit verdient, so dass die Augen der Nutzer sehr schnell über ungebrauchte Icons hinweggleiten.

Dies sind schlichte Fakten in den umfassenden iPhone-Nutzererlebnissen: Eine App ist sehr leicht vom App-Store herunterzuladen, und sozialer Druck sorgt dafür, dass viele "Fun"-Apps rasch in einem grossen Nutzer-Pool kursieren. Das führt dazu, dass das "Sprungbrett" (auf dem die installierten Apps landen) schnell überladen wird mit Icons, die die Nutzer nicht wirklich brauchen und die sie auch nicht mehr nutzen, sobald sie die Kneipe an jenem Abend verlassen haben.

Wenn Sie eine "seriöse" Geschäfts-App gestalten, von der Sie denken, dass sie Ihren Kunden einen realen Nutzen bringt, dann glauben Sie vielleicht, dass Sie über diesem Getümmel der Catch-as-catch-can-Apps stehen. Stehen Sie aber nicht. Regelmässige Leser dieser Kolumne erinnern sich vielleicht an das Jakobsche Gesetz des Nutzererlebnisses im Internet: Die Nutzer verbringen die meiste Zeit auf anderen Websites (und nicht auf Ihrer Website). Ihre Website ist Teil des Ökosystems Internet, und die Usability Ihrer Website wird diktiert vom übergreifenden Nutzererlebnis Internet, das von der Summe aller anderen Websites bestimmt wird, die die Leute besuchen.

Wenn Sie zum Beispiel geschäftliche Informationen in sozialen Medien platzieren, dann müssen diese Informationen in einem Raum existieren, der von den Familienangehörigen und Freunden Ihrer Follower geprägt wird. Auf ähnliche Weise ist eine iPhone-App nur ein kleiner Teil des gesamten Apps-Nutzererlebnisses.

Das mag fair sein oder nicht, aber so ist das Leben. Gehen Sie damit um. Gestalten Sie entsprechend.

Die Vorab-Registrierung muss verschwinden

Das Ergebnis, dass iPhone-Apps Apps nur eine sporadische Verwendung mit sich bringt, zieht eine Menge Design-Richtlinien nach sich. Hier möchte ich eine Schlüssel-Richtlinie für das Anfangs-Nutzererlebnis diskutieren:

• Zwingen Sie die Nutzer nicht, als ersten Schritt durch einen Registrierungs-Dialog zu gehen.

Bei unserem Test haben wir zahllose Apps gesehen, die die Nutzer aufgefordert haben sich zu registrieren, noch bevor sie ihren Wert auch nur im Mindesten bewiesen hätten. Das ist falsch. Denken Sie daran: Wenn die Nutzer Ihre App zum ersten Mal öffnen, starten sie auf einem sehr geringen Niveau des Engagements. Wenn Ihre App nicht wirklich grossartig und von immensem Wert ist, verwenden die Nutzer sie nicht oft genug, um zu denken, dass eine Registrierung den Zeitaufwand lohnen könnte.

Eine Registrierung kann sicherlich Ihren Kunden zusätzlichen geschäftlichen Wert und zusätzliche Bequemlichkeit bei der Nutzung verschaffen. Aber das gilt nur dann, wenn die Leute die Registrierung wirklich abschliessen. Leider verlassen viele Nutzer eine App sofort wieder, wenn ihnen als erstes eine Registrierung vor die Nase gesetzt wird, bevor sie vom Wert Ihrer App genügend überzeugt sind, und versuchen es auch nie wieder. In solchen Fällen haben Sie die einzige Chance verspielt, die Sie jemals hatten, einen ersten Eindruck zu erzielen (genau genommen: irgendeinen Eindruck).

Die Warnung vor einer frühen Registrierung ist nichts Neues. Seit 1999 ist es eine Schlüssel-Usability-Richtlinie für die Einkaufskörbe und Checkout-Prozesse von Online-Shops, es den Nutzern zu erlauben, ohne Registrierung einzukaufen. Websites, die einen Gäste-Checkout erlauben, haben viel höhere Konversionsraten als Websites, die von ihren Nutzern verlangen, einen Benutzernamen und ein Passwort einzugeben, bevor ihnen das seltene Privileg erteilt wird, dort ihr Geld loszuwerden. Wir können doch nicht einfach jedermann erlauben, auf unserer Website einzukaufen - so jedenfalls erscheint diese Denkweise nach aussen.

Registrierungsformulare kosten Sie auf PC-gestützten Websites Geschäfte, wo sie den Leuten bloss ein bisschen lästig sind. In der mobilen Umgebung stellen sie eine bedeutend grössere Belästigung dar. Ausserdem zeigen die Nutzer gegenüber einer App, die sie gerade erst heruntergeladen haben, ein geringeres Engagement als gegenüber einem Online-Shop, auf dem sie bereits einige Zeit verbracht haben, um sich umzuschauen und Dinge in ihren Einkaufskorb zu legen.

Wenn Sie folgendes miteinander kombinieren:

• mehr Belästigung
• weniger Engagement

dann sehen Sie schnell, warum eine Vorab-Registrierung Sie im mobilen Umfeld noch mehr Geschäfte kostet als im PC-Umfeld.

Zum Beispiel: eine Pizza-Bestell-Applikation

Wir haben bei unseren iPhone-Tests viele Beispiele für zu frühe Registrierungen und zu lästige Bildschirmdialoge gesehen.

Diese Registrierung-Anforderung trifft die Nutzer zu einem Zeitpunkt, an dem sie sich einfach nur eine Auswahl leckerer Pizzen anschauen möchten. Das wirkte auf unsere Test-Nutzer sehr abschreckend.

So wäre die richtige Abfolge:

1. Sie zeigen die Liste der Basis-Pizzen.
2. Sie lassen die Nutzer ihre Bestellung individualisieren.
3. Sie zeigen den Preis an, dazu alle notwendigen Informationen fürs Bestellen (vielleicht nachdem die Nutzer ihre Postleitzahl eingegeben haben, um Lieferzeiten u. ä. anzeigen zu können).
4. Sie nehmen die Bestellung auf. An dieser Stelle ist der richtige Zeitpunkt, nach persönlichen Daten zu fragen, weil die Nutzer jetzt stark genug engagiert sind.

Um die tatsächliche Applikation zu testen, haben wir die Nutzer aufgefordert, sich durch das Registrierungsformular zu kämpfen; im realen Leben ausserhalb des Labors wären sie nie weit genug gegangen, um eine Pizza sehen zu können.

Innerhalb der App gab es einige kleinere Probleme des Interaktionsdesigns, aber die Firma könnte die Anzahl ihrer mobilen Pizza-Bestellungen nur dadurch glatt verdoppeln, dass sie die Vorab-Registrierung am Anfang weglässt und die Nutzer erst dann nach persönlichen Daten fragt, wenn ihre Geschmackspapillen durch den Anblick der Pizzen feucht geworden sind.

Übrigens: Keiner der Nutzer hat den Button mit der Aufschrift "Not ready to order? Demo the app" (etwa: Nicht zur Bestellung bereit? Demomodus der App) angeklickt.

Als wir diesen Knopf zum Zweck des Experiments ausprobiert haben, lieferte uns Pizza Hut genau jenes Nutzererlebnis, das oben in den Schritten 1-4 empfohlen wird. Die Designer wussten also, wie man es machen muss. Nur nicht auf der richtigen Nutzeroberfläche :(

Warum probieren Nutzer die Demo-Funktion nicht aus? Weil sie keine Demo haben möchten. Sie wollen die Pizzen sehen, die im Angebot sind. "Sich mal umzuschauen" ist zwar eine klassische Einkaufsstrategie, aber niemand sagt zu einem Verkäufer im Kaufhaus, er sei gerade nicht dazu bereit, sich einen neuen Sweater zu kaufen, wolle aber einen als Demo sehen. Nein - man geht ins Kaufhaus, schaut sich die Sweater an (die dort genau für diesen Zweck alle auf der Stange hängen), und probiert diejenigen an, die einem am besten gefallen. Nur aus der Perspektive des Kaufhauses könnte dieses Szenario als "Demo" betrachtet werden. Aus der Perspektive des Kunden ist es einfach "Einkaufen", und man braucht dafür keine Erlaubnis in dreifacher Ausfertigung.

Auch wenn ich es schon tausendmal gesagt habe, muss ich es anscheinend ein weiteres Mal sagen, damit es auch der letzte Hornochse bei Pizza Hut begreift: Sprechen Sie auf der Nutzeroberfläche die Sprache der Nutzer.

IPhone-Apps bilden offensichtlich eine eigene Klasse der Nutzeroberflächen, so dass es keine Überraschung sein sollte, wenn auf sie allgemeine Richtlinien für Nutzeroberflächen zutreffen, zusätzlich zu den speziellen Richtlinien für mobile Einsätze. Der Unterschied zwischen iPhone-Apps und PC-Apps liegt darin, dass diese Richtlinien, zusammen mit den früheren, noch viel entscheidender sind, weil mobiler Gebrauch normalerweise sporadisch erfolgt. Deshalb müssen die anfänglichen Hürden sehr niedrig liegen und leicht übersprungen werden können, weil die Nutzer sonst niemals Gelegenheit bekommen, sich an Ihre App zu gewöhnen.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.