Berechtigungs- und Benachrichtigungsscreens: wann und wie fragen?

Kurz gesagt

In einer mobilen App braucht es für Standort, Kamera, Mikrofon oder Benachrichtigungen eine Berechtigung. Den Berechtigungsdialog öffnet das Betriebssystem des Telefons. Die Dokumentation für Android-Entwickler schreibt das klar: Die App kann diesen Dialog nicht anpassen.

Dieselbe Dokumentation weist auf eine Lücke hin. Der Systemdialog sagt, welche Berechtigung angefragt wird, aber nicht, warum. Diese Lücke schließen zwei Dinge: der richtige Moment und bei Bedarf eine kurze Erklärung vor dem Systemdialog.

Auf Englisch heißt das „Permission Priming“, ich nenne es Erklärscreen. Hier beschreibe ich den Platz dieses Screens im Ablauf. Den Text für den Screen finden Sie im Abschnitt zu Berechtigungen der Microcopy-Beispiele.

Was sagen iOS und Android zur Benachrichtigungsberechtigung?

Auf beiden Plattformen dürfen Sie ohne Zustimmung des Nutzers keine Benachrichtigungen senden. Der Unterschied liegt darin, wie oft und wann der Dialog erscheint. Die Punkte unten stammen aus den Entwicklerdokumentationen von Apple und Android.

• iOS

  • Vor der ersten Benachrichtigung braucht es die Zustimmung des Nutzers. Den Dialog zeigt das System.
  • Bei der ersten Anfrage fragt das System den Nutzer und speichert die Antwort. Spätere Anfragen öffnen keinen Dialog.
  • Sie können eine vorläufige Berechtigung (provisional) anfragen. Benachrichtigungen kommen dann leise und nur in die Mitteilungszentrale. Dort entscheidet der Nutzer, ob er sie behält oder ausschaltet.
  • Der Nutzer kann die Berechtigungen der App jederzeit ändern.

• Android

  • Mit Android 13 (API 33) wurde die Benachrichtigungsberechtigung zur Laufzeitberechtigung POST_NOTIFICATIONS.
  • In neu installierten Apps sind Benachrichtigungen standardmäßig aus.
  • Zielt Ihre App auf Android 13 oder höher, wählen Sie den Zeitpunkt des Dialogs selbst. Zielt sie auf 12L (API 32) oder niedriger, fragt das System meist beim Start.
  • Wischt der Nutzer den Dialog weg, ändert sich der Stand der Berechtigung nicht. Eine zweimal abgelehnte Berechtigung gilt als dauerhaft abgelehnt.

Bei Android gibt es noch eine Falle. Zielt Ihre App auf 12L oder niedriger und sagt der Nutzer einmal „Nicht erlauben“, fragt das System nicht noch einmal. Das gilt, bis die App gelöscht und neu installiert wird oder ein Update kommt, das auf Android 13 zielt.

Auf Telefonen, die auf Android 13 aktualisiert werden, bekommen passende ältere Apps die Berechtigung automatisch. Hat der Nutzer Benachrichtigungen vorher ausgeschaltet, gilt diese Ablehnung auch nach dem Update. Zu Unterschieden bei Navigation und Dialogen schauen Sie in den Ratgeber Unterschiede zwischen iOS und Android.

Fragen Sie im Kontext

Die Datenschutzseite von Apple sagt, man solle Berechtigungen beim Start vermeiden. Die einzige Ausnahme: Die App funktioniert ohne diese Berechtigung nicht. Als Beispiel nennt sie eine Navigations-App, die ohne Standort nutzlos ist.

Für Benachrichtigungen nennt die Entwicklerdokumentation von Apple eine Aufgaben-App als Beispiel. Die Berechtigung wird angefragt, nachdem der Nutzer seine erste Aufgabe geplant hat. Laut Dokumentation sieht der Nutzer so, wofür die Benachrichtigungen gut sind.

Auch die Android-Seite zur Benachrichtigungsberechtigung empfiehlt, dem Nutzer zuerst Zeit zu geben, die App kennenzulernen. Als gute Momente nennt sie: Der Nutzer drückt auf eine Glocke, folgt einem Konto oder bestellt Essen. Auch auf den dritten oder vierten Start der App zu warten, nennt sie als Möglichkeit.

In einer App zur Sendungsverfolgung ist dieser Moment klar. Öffnet der Nutzer eine Sendung und schaut auf ihren Stand, ist die Frage „Sollen wir Bescheid geben, wenn sie in Zustellung ist?“ sofort verständlich. Beim Start ist dagegen unklar, worüber Bescheid gegeben werden soll.

Die Android-Dokumentation beschreibt auch die Seite der Transparenz. Ihr Beispiel ist eine E-Mail-App: Dort wählen Sie, ob Sie für jede neue E-Mail eine Benachrichtigung wollen oder nur für E-Mails, deren einziger Empfänger Sie sind. Zu sagen, wofür Sie Benachrichtigungen senden, erhöht die Wahrscheinlichkeit, dass der Nutzer zustimmt.

Der Erklärscreen (Permission Priming)

In den meisten Fällen braucht es keinen eigenen Erklärscreen. Laut Apple ist ideal, dass der aktuelle Kontext die Berechtigung von selbst erklärt. Hat der Nutzer im Screen der Sendung auf „Bescheid geben“ gedrückt, ist klar, was er will.

Braucht es einen eigenen Screen, gelten auf beiden Plattformen andere Regeln:

• iOS: Die HIG verlangt einen einzigen Button, der den Systemdialog öffnet. Sein Name sollte etwa „Weiter“ lauten, nicht „Erlauben“. Die HIG sagt, man solle keine zusätzliche Aktion wie Schließen oder Abbrechen anbieten. Einzige Ausnahme: Es ist nötig, um eine rechtliche Einwilligung einzuholen.
• Android: Die Dokumentation verlangt im Erklärablauf immer eine Möglichkeit abzubrechen. Im Beispielcode erscheint dieser Erklärscreen nur, wenn shouldShowRequestPermissionRationale() true liefert.

Mit dieser Regel will Apple verhindern, dass sich der Nutzer täuscht. Ähnelt der Button auf dem Erklärscreen dem Erlauben-Button im Systemdialog, drückt der Nutzer ihn womöglich, ohne es zu merken. Bei der Tracking-Berechtigung ist Apple noch deutlicher. Ein Bild des Systemdialogs zu zeigen oder auf den Erlauben-Button hinzuweisen, zählt zu den Designs, die zur Ablehnung führen. Solche Tricks habe ich im Ratgeber zu Dark Patterns gesammelt.

Zeigen Sie den Erklärscreen auf beiden Plattformen mit demselben Code, trennen Sie die Buttons nach Plattform. Für die Reihenfolge im Ablauf schauen Sie auch in das Muster Onboarding. Binden Sie die Berechtigung nicht an Schritte des Onboardings, sondern an die erste echte Aufgabe des Nutzers.

Ausprobieren: beim Start fragen, im Kontext fragen

Öffnen Sie dieselbe Paket-App mit zwei verschiedenen Zeitpunkten. Lehnen Sie zuerst mit „Beim Start fragen“ ab, öffnen Sie dann die Sendung und drücken Sie auf die Glocke. Machen Sie danach dasselbe mit „Im Kontext fragen“.

Beim Start oder im Kontext?

Dieses Beispiel läuft mit JavaScript. Ohne JavaScript lesen Sie den Unterschied der beiden Abläufe im Text darüber und darunter.

Die App Beispiel Paket, ihre Texte und die schlichte Darstellung des Systemdialogs sind meine. Der Dialog kopiert weder die Oberfläche von Apple noch von Google. In der Demo wird nur einmal gefragt. Unter iOS öffnet eine zweite Anfrage keinen Dialog, unter Android gilt eine zweimal abgelehnte Berechtigung als dauerhaft.

Wer beim Start ablehnt, hat Ihre einzige Chance verbraucht, ohne zu sehen, wofür die Glocke gut ist. Wer im Kontext ablehnt, weiß, was er ablehnt. Der Stand der Sendung bleibt in beiden Abläufen auf dem Screen.

Was passiert, wenn der Nutzer ablehnt?

Die kurze Antwort: Die App funktioniert weiter, nur diese Funktion fehlt. Die Android-Dokumentation nennt fünf Grundsätze nach einer Ablehnung. Ich übertrage sie so auf den Screen:

1. Verluste klein halten. Ohne Benachrichtigung bleibt der Stand der Sendung in der App trotzdem aktuell.
2. Die Aufmerksamkeit an die richtige Stelle lenken. Zeigen Sie die Meldung dort, wo das Ergebnis der Funktion erscheinen würde. Im Paketbeispiel ist das der Kasten mit der Glocke.
3. Konkret sein. Schreiben Sie statt „Manche Funktionen funktionieren eventuell nicht“, welche Funktion nicht geht.
4. Die Oberfläche nicht blockieren. Halten Sie den Nutzer nicht mit einer Warnung im Vollbild auf.
5. Die Entscheidung respektieren. Die Dokumentation hält es für respektlos, ständig daran zu erinnern, die Meinung zu ändern.

Auch ein Hinweis im Beispielcode ist wichtig. Die Dokumentation sagt, man solle nach einer Ablehnung nicht auf die Systemeinstellungen verlinken, um den Nutzer zu überzeugen. Deshalb erscheint der Weg in die Einstellungen in der Demo nicht im Moment der Ablehnung, sondern erst, wenn der Nutzer erneut auf die Glocke drückt.

Bei Apple ist die Regel kürzer. Laut Dokumentation speichert das System die Antwort bei der ersten Anfrage, spätere Anfragen fragen den Nutzer nicht. Wer seine Meinung ändert, dem zeigen Sie den Weg in den Bereich Mitteilungen der Einstellungen.

Der Weg in die Einstellungen

Nach einer Ablehnung dürfen Sie auf die Einstellungen verlinken, aber achten Sie auf den Zeitpunkt. Zeigen Sie den Weg, wenn der Nutzer dieselbe Funktion selbst erneut anfragt. Gleich beim Betreten des Screens ein Band „Schalten Sie Benachrichtigungen ein“ zu zeigen, ist dagegen Drängeln.

Beide Plattformen haben einen direkten Weg zu den Benachrichtigungseinstellungen. Unter iOS kam UIApplication.openNotificationSettingsURLString mit iOS 16 und öffnet die Benachrichtigungseinstellungen der App. Unter Android kam Settings.ACTION_APP_NOTIFICATION_SETTINGS mit API 26 und zeigt die Benachrichtigungseinstellungen einer einzelnen App.

Schreiben Sie neben den Link in einem Satz, was der Nutzer dort tun soll. Prüfen Sie die Berechtigung auch erneut für Nutzer, die aus den Einstellungen zurückkommen. Die Dokumentationen von Apple und Android erinnern daran, dass der Nutzer die Berechtigung jederzeit ändern kann. Fragen Sie deshalb vor jeder Benachrichtigung den Stand ab: unter iOS mit notificationSettings(), unter Android mit areNotificationsEnabled().

Nachdem Sie die Berechtigung haben

Die Berechtigung bekommen Sie einmal, der Nutzer kann sie aber jederzeit zurücknehmen. Die Android-Dokumentation schreibt, dass der Nutzer sehen kann, wie viele Benachrichtigungen die App pro Tag sendet, und die Berechtigung jederzeit entziehen kann.

Auch die Seite zu Benachrichtigungen von Apple empfiehlt, für dieselbe Sache nicht mehrere Benachrichtigungen zu senden. Die Begründung: Die Mitteilungszentrale füllt sich, und der Nutzer kann alle Benachrichtigungen der App ausschalten. Haben Sie für die Sendung zwei Benachrichtigungen versprochen, „in Zustellung“ und „zugestellt“, fügen Sie keine Werbung hinzu.

Meine Notiz

Das häufigste Berechtigungsproblem in Audits mobiler Apps ist der Startscreen. Die App öffnet, und noch bevor der Nutzer das Logo sieht, kommen Dialoge für Benachrichtigungen, Standort und Tracking hintereinander. Der Nutzer schließt alle drei mit demselben Reflex.

Auf Platz zwei steht das Schweigen nach der Ablehnung. Wird die Berechtigung abgelehnt, verschwindet die Funktion still, auf dem Screen bleibt keine Erklärung. Der Nutzer erfährt nie, warum er keine Benachrichtigung zur Sendung bekommt.

Probieren Sie in Ihrem eigenen Produkt Folgendes. Löschen Sie die App, installieren Sie sie neu und lehnen Sie jede Berechtigung ab. Notieren Sie dann auf jedem Screen, was nicht funktioniert und ob der Screen es Ihnen sagt.

Wollen Sie diesen Ablauf in Ihrem Produkt neu aufbauen: Der Design & Ship Sprint deckt Berechtigungsscreens vom Design bis zum Code ab.

Checkliste

• Die Berechtigung wird angefragt, wenn der Nutzer die Aufgabe beginnt, die sie braucht.
• Wird beim Start gefragt, funktioniert die App ohne diese Berechtigung wirklich nicht.
• Erklärt der Kontext die Berechtigung nicht, gibt es vor dem Systemdialog eine kurze Erklärung.
• Auf dem iOS-Erklärscreen gibt es einen einzigen Button mit dem Namen „Weiter“.
• Auf dem Android-Erklärscreen gibt es eine Möglichkeit abzubrechen.
• Der Erklärscreen ahmt den Systemdialog nicht nach und zeigt nicht auf den Erlauben-Button.
• Nach einer Ablehnung funktioniert die App und nennt die fehlende Funktion beim Namen.
• Der Link in die Einstellungen erscheint nur, wenn der Nutzer die Funktion erneut anfragt.
• Vor jeder Benachrichtigung wird der Stand der Berechtigung geprüft.
• Für dasselbe Ereignis wird nicht mehr als eine Benachrichtigung gesendet.