Bild: Mit KI generiert

Die meisten App-Onboarding-Flows erklären. Sie zeigen Screens, beschreiben Funktionen, listen Vorteile auf. Das Problem: Nutzer:innen, die eine App installieren, wollen in diesem Moment keine Erklärung. Sie wollen den Moment erleben, für den sie die App installiert haben.

77 % der täglich aktiven Nutzer:innen verlassen eine App innerhalb der ersten drei Tage nach der Installation. Das ist kein Nutzungsproblem, sondern ein Onboarding-Problem. Und es entsteht häufig nicht, weil das Design schlecht ist, sondern weil das Ziel des Onboardings falsch definiert wurde.

In diesem Artikel erfährst du, warum Feature-Erklärung als Onboarding-Strategie scheitert, was Time-to-Value als Designprinzip bedeutet, welche Onboarding-Muster wann funktionieren und warum Progressive Disclosure in den meisten Fällen dem statischen Welcome Flow überlegen ist.

Was Onboarding wirklich leisten soll

Onboarding ist in vielen Teams als Produktvorstellung definiert: Die App erklärt sich selbst, bevor Nutzer:innen anfangen zu tippen. Dieses Verständnis führt zu Feature-Tours: Sequenzen von Screens, die Funktionen erklären, bevor jemand einen konkreten Anlass hat, sie zu nutzen.

Das Problem ist strukturell: Feature-Tours liefern Informationen im falschen Moment. Eine Funktion, die erklärt wird, bevor die Nutzer:in einen Bedarf erlebt hat, erzeugt keine Erinnerung — sie erzeugt kognitive Last. Nutzer:innen tippen sich durch Screens, die ihnen etwas zeigen, das sie noch nicht brauchen, und erreichen das Interface, das sie eigentlich wollten, erst nach mehreren Klicks.

Das alternative Verständnis: Onboarding ist nicht die Einführung in die App. Es ist der Weg zum ersten Moment, in dem die App ihren Kern-Wert liefert — dem sogenannten Aha-Moment. Dieser Moment ist verschieden für jede App, aber seine Logik ist konsistent: Nutzer:innen verstehen im Erleben, nicht im Erklären, warum eine App es wert ist zu bleiben.

Spotify: Der Aha-Moment ist das erste Mal, dass eine Empfehlung spielt, die sich persönlich richtig anfühlt.
Duolingo: Der Aha-Moment ist das erste abgeschlossene Lernmodul: eine konkrete Erfahrung von Fortschritt.
Notion: Der Aha-Moment ist das erste Mal, dass eigene Inhalte in einem sinnvollen Struktur-System existieren.

Onboarding, das auf diesen Moment hinführt statt ihn aufzuschieben, hat eine grundlegend andere Struktur als eine Feature-Tour.

Time-to-Value als Designprinzip

Time-to-Value beschreibt, wie schnell Nutzer:innen nach dem ersten App-Start ihren ersten wahrgenommenen Wert erleben. Es ist keine technische Metrik, es ist ein Designprinzip, das die Struktur des gesamten Onboarding-Flows bestimmt.

Die Konsequenz für das Design: Jeder Schritt im Onboarding-Flow, der nicht direkt auf den Aha-Moment hinführt, ist ein potenzieller Absprungpunkt. Registrierungsformulare, Permissions-Requests, Onboarding-Tutorials und Welcome Screens stehen strukturell zwischen dem Moment der Installation und dem Moment des ersten wahrgenommenen Werts.

Das bedeutet nicht, dass diese Elemente eliminiert werden sollten; sie haben legitime Funktionen. Es bedeutet, dass ihre Reihenfolge und Notwendigkeit aktiv hinterfragt werden sollten:

Braucht es eine Registrierung vor dem ersten Aha-Moment? Für viele Apps ist die Antwort nein. Eine Banking-App braucht Authentifizierung vor dem ersten Feature-Zugriff. Eine Wetter-App braucht sie nicht. Die Entscheidung, wann ein Account wirklich notwendig wird, ist eine der wirkungsvollsten Time-to-Value-Entscheidungen im Mobile App Design.

Braucht es einen Permission-Request vor dem ersten Aha-Moment? Ein Standort-Request vor der ersten Nutzung einer lokalen Suche ist verfrüht: der Kontext für die Permission fehlt. Derselbe Request, ausgelöst in dem Moment, in dem die Nutzer:in erstmals eine Standort-Funktion aufruft, hat einen verständlichen Anlass und wird häufiger genehmigt.

Braucht es eine Feature-Erklärung vor der ersten Nutzung? In den meisten Fällen ist die Antwort nein — weil Erklärungen am wirkungsvollsten sind, wenn die Nutzer:in gerade einen Bedarf erlebt, nicht bevor er entstanden ist.

Statisches Onboarding vs. Progressive Disclosure

Statisches Onboarding — Sequenzen von Screens vor dem ersten App-Zugriff — hat einen einzigen Vorteil: Es ist strukturell einfach umzusetzen und gibt dem Team das Gefühl, Nutzer:innen vorbereitet zu haben. Die Nachteile sind vielfältiger:

Nutzer:innen überspringen statische Onboarding-Screens häufig, weil sie in den meisten Apps ähnlich aufgebaut sind und selten relevante Informationen für den aktuellen Moment enthalten. Was nicht angewandt werden kann, wird nicht erinnert. Und jeder statische Screen verlängert die Time-to-Value.

Progressive Disclosure als Alternative bedeutet: Informationen und Hilfestellungen erscheinen kontextuell, in dem Moment, in dem sie relevant werden. Statt alle Funktionen vorab zu erklären, erklärt das Interface sich selbst im Moment der Nutzung.

Konkrete Muster, die Progressive Disclosure im Mobile App Context umsetzen:

Tooltips und Coachmarks erscheinen beim ersten Aufrufen einer Funktion, nicht vorher. Sie sind klein, kontextuell und verschwinden nach der ersten Interaktion.

Empty States als Onboarding-Moment. Der leere Zustand einer App — ein Dashboard ohne Daten, eine Liste ohne Einträge — ist einer der wertvollsten Onboarding-Momente und wird am häufigsten verschenkt. Ein leerer State, der erklärt was dieser Bereich leisten wird und wie man ihn füllt, ist substanziell effektiver als eine abstrakte Feature-Beschreibung auf einem Welcome Screen.

Checklist-basiertes Onboarding für Apps, bei denen Nutzer:innen mehrere Einrichtungsschritte brauchen, um den vollen Wert zu erleben. ClickUp nutzt dieses Muster: Nutzer:innen sehen eine übersichtliche Liste mit nächsten Schritten, die sich sukzessive abhaken lässt. Das erzeugt Fortschrittsgefühl und orientiert ohne zu überfordern.

Wann statisches Onboarding sinnvoll ist

Progressive Disclosure ist nicht in jedem Kontext die überlegene Strategie. Statisches Onboarding hat legitime Anwendungsfälle:

Apps mit komplexer Ersteinrichtung, die vor der ersten sinnvollen Nutzung zwingend abgeschlossen werden muss. Banking-Apps oder Gesundheits-Apps, bei denen Sicherheits- und Datenschutzinformationen rechtlich oder ethisch geboten sind. Apps, deren Kernwert nicht ohne eine kurze Erklärung des Interaktionsparadigmas verständlich ist: etwa AR-Apps oder ungewöhnliche Interaktionsmuster.

Das entscheidende Kriterium: Statisches Onboarding ist dann gerechtfertigt, wenn die Informationen, die es vermittelt, tatsächlich notwendig sind, um den ersten Aha-Moment zu ermöglichen — nicht um das Team zu beruhigen, dass Nutzer:innen vorbereitet sind.

Onboarding und Navigation: Ein unterschätzter Zusammenhang

Onboarding-Design und Navigation Patterns sind enger miteinander verbunden als es zunächst scheint. Die Informationsarchitektur einer App — welche Bereiche existieren, wie sie erreichbar sind und in welcher Reihenfolge sie genutzt werden — bestimmt, welcher Onboarding-Ansatz überhaupt funktioniert.

Eine App mit flacher Navigation und drei Hauptbereichen lässt sich anders einführen als eine App mit tiefer Hierarchie und zwanzig Funktionsbereichen. Wer Onboarding als eigenständige Design-Aufgabe behandelt, ohne die Informationsarchitektur zu berücksichtigen, optimiert einen Symptom statt eine Ursache.

Die praktische Konsequenz: Onboarding-Design gehört in dieselbe Designphase wie Navigation-Design. Nicht als nachgelagerter Schritt, sondern als integraler Bestandteil der Informationsarchitektur-Entscheidungen.

Take Away Message

App Onboarding scheitert häufig nicht an schlechter Ausführung, sondern an einer falschen Ausgangsfrage. Wer fragt „Wie erklären wir alle Funktionen?", baut Feature-Tours. Wer fragt „Wie bringen wir Nutzer:innen so schnell wie möglich zu ihrem ersten Aha-Moment?", baut Onboarding, das Retention erzeugt. Progressive Disclosure, kontextuell platzierte Hilfestellungen und durchdachte Empty States sind die Werkzeuge — aber das Prinzip dahinter ist einfacher: Erleben ist wirkungsvoller als Erklären.