Wie gestaltet man ein gutes Onboarding?

Kurz gesagt

Alita Kendrick von NN/g definiert Onboarding als Abläufe, die neben der normalen Oberfläche der App stehen und den Nutzer an die App gewöhnen. Dazu gehören Einrichtung und Anleitung. Auch bestehende Nutzer können Onboarding sehen, wenn eine neue Funktion erscheint.

Kendricks Empfehlung mag überraschen: Wenn möglich, verzichten Sie auf Onboarding. Denn Onboarding kostet Aufmerksamkeit und Mühe, und das Gedächtnis ist begrenzt. Meiner Meinung nach sollte diese Mühe zuerst in eine einfachere Oberfläche fließen.

In Audits sehe ich am häufigsten Folgendes: Statt einen verwirrenden Screen zu verbessern, stellt das Team eine Einführungstour davor. Die Tour endet, der Screen bleibt gleich. Laut Kendrick sollte Anleitung nicht dazu dienen, schlechtes Design zu flicken.

Wann man es einsetzt

Laut Kendrick brauchen die meisten mobilen Apps kein Onboarding, weil Nutzer die App beim Benutzen lernen. Sie nennt Situationen, in denen Onboarding helfen kann:

• Die App braucht zum Start Informationen. Ein Konto eröffnen oder sich in einer Banking-App identifizieren sind Beispiele dafür.
• Das Produkt hängt von der Situation des Nutzers ab. Eine Diät-App fragt vor dem Start nach Ihrem aktuellen Gewicht.
• Die Hauptfunktion ist neu oder ungewohnt. Kendricks Beispiel ist die Scheckeinreichung per Handy. Als sie neu war, war sie eine Alternative zur Einzahlung am Geldautomaten.

In diesen Fällen sollten Sie innehalten, bevor Sie Onboarding einbauen:

• Sie haben den Screen noch nicht mit Nutzern getestet. Kendrick will, dass Sie die App zuerst ohne Onboarding testen. Den Ablauf bauen Sie erst ein, wenn der Test ein echtes Problem zeigt. Wie ich den Test aufsetze, steht im Ratgeber zum Usability-Test.
• Sie wollen ein Element erklären, das jeder kennt. Page Laubheimer von NN/g rät, Offensichtliches wie das Zahnrad für Einstellungen nicht zu erklären.
• Das eigentliche Ziel ist, neue Funktionen zu vermarkten. Kendrick empfiehlt, beim ersten Start auf Funktionswerbung zu verzichten. Solche Werbescreens gehören ihr zufolge auf die Seite im App Store. In der App zeigen Sie die Funktion in dem Moment, in dem sie nützt.

Arten von Onboarding

Laubheimer teilt Hilfe in zwei Arten. „Push“-Hilfe kommt beim Start der App oder zu einem beliebigen Zeitpunkt, losgelöst vom Kontext. „Pull“-Hilfe erscheint, wenn die App den Moment erkennt, in dem der Nutzer sie braucht. Die Arten unten liegen zwischen diesen beiden Polen.

Einführungstour

Das sind Karten, die beim ersten Start nacheinander erscheinen. NN/g nennt diese Form „deck-of-cards“, also ein Karten-Tutorial. Jede Karte erklärt eine Funktion, am Ende geht der Nutzer in die App.

In Kendricks NN/g-Studie las eine Gruppe von Teilnehmenden diese Touren, die andere übersprang sie. Wer die Tour gelesen hatte, war bei den Aufgaben nicht erfolgreicher. Diese Gruppe fand die Aufgaben sogar schwerer.

Laubheimer erklärt das mit dem „Paradox des aktiven Nutzers“: Nutzer wollen sofort loslegen und überspringen die Tour. Und Informationen ohne Kontext erinnert man nicht, wenn man sie braucht.

Manchmal passt eine Tour trotzdem. In Laubheimers Forschung halfen Einführungsabläufe, an eine neue Interaktionsform wie Augmented Reality heranzuführen. Eine ungewohnte Interaktion vorab zu zeigen, finde ich dort sinnvoll.

Beim Benutzen lernen

Ein Tipp erscheint, sobald der Nutzer zu einer Funktion kommt, und zwar direkt neben dieser Funktion. Laubheimer nennt das kontextuelle Hilfe. Tooltips, die beim Darüberfahren erscheinen, und sogenannte Coach Marks gehören zu dieser Gruppe.

Aurora Harley von NN/g stellt klare Regeln für Coach Marks auf. Jeder Tipp sollte eine einzige Interaktion erklären, und die Tipps sollten einzeln kommen, wenn sie nützen. Ketten von Tipps, die nacheinander aufgehen, sollten Sie vermeiden.

Harley warnt außerdem: Nutzer können einen Tipp für einen klickbaren Teil der Oberfläche halten. Deshalb muss sich der Tipp optisch von den Elementen der App abheben.

Mit leerem Zustand starten

In einem neuen Konto sind Liste, Dashboard oder Favoriten leer. Kate Kaplan von NN/g will, dass dieser Bereich nicht völlig leer bleibt. Ein komplett leerer Screen lässt Nutzer zweifeln, ob das System überhaupt funktioniert.

Laut Kaplan sagt ein guter leerer Zustand zuerst, wie es um das System steht. Dann erklärt er, was in diesen Bereich kommt, und verlinkt direkt die Aufgabe, die ihn füllt.

Kaplan schreibt, dass dieser Ansatz meist besser funktioniert als Touren, die beim ersten Start erzwungen werden. Der leere Zustand hilft, wenn der Nutzer zu diesem Bereich kommt. Er ist also Pull-Hilfe.

Tun und lassen

Die meisten Punkte unten stammen aus den NN/g-Artikeln zu Onboarding, Coach Marks und leeren Zuständen. Einige kommen aus Fehlern, die ich in Audits immer wieder sehe.

Live-Beispiel: eine App, drei Onboardings

Stellen Sie sich eine erfundene Ausgaben-App namens Sparschwein vor. Unten startet dieselbe App mit drei verschiedenen Onboardings. Wählen Sie eine Art und probieren Sie den Ablauf mit Weiter und Überspringen.

Fragen Sie sich nach allen drei Durchgängen: Bei welcher Art erinnern Sie sich, wo Sie das Budgetlimit setzen? In der Einführungstour kam die Information, bevor Sie die App überhaupt gesehen hatten. Beim leeren Zustand stand sie genau in diesem Feld.

Achten Sie in der Demo auch darauf, dass Überspringen bei jeder Art etwas anderes bewirkt. In der Tour kommt die übersprungene Information nicht wieder. Beim Tipp bleibt der Hilfe-Link. Beim leeren Zustand gibt es nichts zu überspringen.

Unterschied zwischen Mobil und Desktop

Auf dem Handy ist der Bildschirm klein, und die Aufmerksamkeit wird oft unterbrochen. Laut Harley haben mobile Nutzer wenig Zeit. Deshalb lesen sie Anleitungen noch weniger gern als Webnutzer.

Auf dem Handy halte ich mich deshalb kurz. Ein Tipp ist ein Satz und verdeckt nicht das Element, auf das er zeigt. Für den Rest des Screens lesen Sie den Ratgeber zum App-Design.

Am Desktop ist der Bildschirm breit, und die Anwendungen sind oft komplexer. Auch Kaplans Artikel zu leeren Zuständen handelt von komplexen Anwendungen. Dashboard, Benachrichtigungen und Favoriten sind am ersten Tag leer, und jeder Bereich kann mit seinem eigenen leeren Zustand anleiten.

Laubheimer zeigt zwei Beispiele aus Desktop-Designtools. Im einen erscheint ein Tipp nur, wenn er mit der aktuellen Aufgabe des Nutzers zu tun hat. Im anderen öffnen sich Details erst, wenn der Nutzer sie anfordert. Laubheimer nennt das schrittweise Offenlegung (progressive disclosure).

Weil es am Desktop eine Maus gibt, liegt es nahe, Tipps beim Darüberfahren zu zeigen. Das ist bei mir nie der einzige Weg. Auf Touchscreens und mit der Tastatur gibt es kein Darüberfahren.

Hinweis zur Barrierefreiheit

Onboarding öffnet sich oft als Ebene oder Dialog. In Barrierefreiheitsprüfungen sehe ich bei diesen Ebenen vor allem Probleme mit Fokus und Ansagen. Ich schaue zuerst auf diese Kriterien der WCAG 2.2.

• 2.4.3 Fokus-Reihenfolge (Stufe A). Laut W3C bleibt der Fokus bei offenem modalem Dialog im Dialog, und Inhalte außerhalb bekommen keinen Fokus. Schließt sich der Dialog, kehrt der Fokus zu dem Element zurück, das ihn geöffnet hat, oder zum direkt folgenden.
• 2.2.2 Pausieren, beenden, ausblenden (Stufe A). Bewegung, die von selbst startet, länger als fünf Sekunden dauert und neben anderem Inhalt erscheint, muss der Nutzer anhalten können. Laufen Tour-Karten von selbst weiter und treffen diese Bedingungen zu, verfehlen sie das Kriterium.
• 4.1.3 Statusmeldungen (Stufe AA). Meldungen wie „Schritt 2 / 3“ oder „Tipps geschlossen“ müssen beim Screenreader ankommen, ohne dass der Fokus verschoben wird.

Deshalb wird die Schrittinfo in der Demo in einer aria-live-Region angesagt. Nach Überspringen geht der Fokus nicht verloren, sondern springt auf den Button Von vorn. Die Buttons zur Wahl der Art melden ihren Zustand mit aria-pressed.

Alle Kriterien stehen im WCAG-Ratgeber. Wie ich einen Ablauf Schritt für Schritt prüfe, beschreibe ich im Ratgeber zur Barrierefreiheitsprüfung.

Hinweis zur Umsetzung

Unten sehen Sie schlichtes HTML für einen leeren Zustand und einen Tipp, der mit seinem Feld verbunden ist. Darunter ein kleines Skript, das die Tour einmal öffnet und sie aus den Einstellungen zurückholt.

<!-- Leerer Zustand: echte Überschrift und Link zur Aufgabe, die den Bereich füllt. -->
<section class="leerer-zustand" aria-labelledby="leer-titel">
  <h2 id="leer-titel">Noch keine Ausgaben</h2>
  <p>Fügen Sie Ihre erste Ausgabe hinzu, dann erscheint hier die Summe dieses Monats.</p>
  <a class="btn btn--primary" href="/ausgaben/neu">Erste Ausgabe hinzufügen</a>
</section>

<!-- Tipp: neben dem Feld, mit dem Feld verbunden. -->
<label for="kategorie">Kategorie</label>
<select id="kategorie" aria-describedby="tipp-kategorie">...</select>
<p id="tipp-kategorie" class="tipp">Die Kategorie können Sie auch später ändern.</p>

<script>
  // Die Tour öffnet sich einmal von selbst und lässt sich in den Einstellungen jederzeit neu öffnen.
  if (!nutzer.tourGesehen) tourOeffnen();
  einstellungen.querySelector('#tour-zeigen').addEventListener('click', tourOeffnen);
</script>

Die Überschrift des leeren Zustands ist ein echtes Überschriften-Element, der Button ein echter Link. So finden auch Screenreader-Nutzer den leeren Zustand, wenn sie über Überschriften navigieren.

Der Tipp ist per aria-describedby mit dem Feld verbunden. Kommt der Nutzer zum Feld, liest der Screenreader den Tipp mit vor. Ein eigener Dialog für den visuellen Tipp ist dann nicht nötig.

Die Option „Tour erneut anzeigen“ setze ich an eine leicht auffindbare Stelle, in die Einstellungen oder ins Hilfemenü. Laubheimer erzählt, dass er in einer Fahrrad-App nach der Tour keinen Weg fand, sie erneut zu öffnen. Deshalb ist es wichtig, dass geschlossene Hilfe zurückkommen kann.

Ob die Tour gesehen wurde, speichere ich lieber im Konto des Nutzers. Eine Information im Browser zeigt derselben Person die Tour auf einem anderen Gerät noch einmal. Wenn ich den Ablauf vom Design bis zum Code bauen soll, fällt das unter den Design-und-Ship-Sprint.

Checkliste

Bevor ein Onboarding-Ablauf live geht, gehe ich diese Liste durch. Wenn ich den ersten Start Ihrer App prüfen soll: Der UX Audit deckt diese Punkte ab.

• Ich habe die App zuerst ohne Onboarding getestet.
• Ich kann in einem Satz sagen, warum jeder Schritt da ist.
• Beim ersten Start wird nur abgefragt, was zum Loslegen nötig ist.
• Jeder Schritt, der Daten abfragt, nennt den Grund.
• Überspringen ist in jedem Schritt sichtbar und funktioniert.
• Eine geschlossene Tour oder ein geschlossener Tipp lässt sich wieder öffnen.
• Tipps erscheinen einzeln und neben dem betreffenden Element.
• Ein Tipp sieht nicht aus wie ein klickbarer Teil der Oberfläche.
• Jeder leere Screen sagt, was er ist und was der erste Schritt ist.
• Keine Karte läuft von selbst weiter.
• Öffnet sich ein Dialog, geht der Fokus hinein und beim Schließen zurück.
• Wechselt der Schritt, hört der Screenreader das.

Meine Notiz

Onboarding betrachte ich am Ende der Designarbeit, nicht am Anfang. Zuerst teste ich die Screens ohne Ablauf. Wo der Nutzer hängen bleibt, verbessere ich zuerst.

Bleibt eine Stelle, die ich nicht verbessern kann, setze ich dort einen Tipp oder einen leeren Zustand. Einen Vollbild-Ablauf nutze ich meist nur für Pflichtschritte wie die Kontoeröffnung.

Denken Sie an eine Banking-App. Dass sie beim ersten Start eine Identifizierung verlangt, ist einer der berechtigten Fälle, die Kendrick nennt. Kommen aber Aktionskarten in denselben Ablauf, kommt der Nutzer später zu seiner eigentlichen Aufgabe. Ich trenne diese Karten ab und verlege sie in den leeren Zustand des passenden Screens oder in einen Tipp.

Passt der Screen zum mentalen Modell im Kopf des Nutzers, muss man kaum etwas erklären. Wenn Sie das Onboarding immer weiter verlängern müssen, erklärt sich die Oberfläche nicht selbst. Das sehen Sie schnell mit einer heuristischen Evaluation.