Ein User Flow bildet die Schritte und Entscheidungen ab, die nötig sind, um ein Ziel innerhalb eines Produkts zu erreichen. Er zeigt, was eine Person tut, wie das System reagiert und an welchen Stellen sich der Weg verzweigen kann. Teams nutzen Flows, um ein Erlebnis zu durchdenken, bevor sie es bauen – und um den geplanten Weg mit dem abzugleichen, was Nutzer*innen tatsächlich tun.
Die wirklich nützlichen Details zeigen sich oft abseits des Idealfalls (dem Happy Path). Eine Einladung läuft ab, ein Konto existiert bereits oder jemand bricht mittendrin ab und kehrt auf einem anderen Gerät zurück. Wenn man diese Bedingungen visualisiert, läuft man weniger Gefahr, eine Abfolge schicker Screens mit einer vollständigen Interaktion zu verwechseln.
Anfang und Ziel klar definieren
Nehmen wir als fiktives Beispiel eine Nachbarschafts-App zum Verleihen von Werkzeug. „Eine Bohrmaschine leihen“ könnte mit einer Suche beginnen, mit einem Link von nebenan oder einer unbeantworteten Anfrage vom Vortag. Der Flow könnte enden, sobald die Anfrage abgeschickt wurde, wenn die Eigentümerin zustimmt oder wenn feststeht, wie die Abholung abläuft. Ein Flow braucht klare Grenzen, damit alle im Team wissen, welches Ergebnis er abbildet.
Startet beim Ziel der Person und den relevanten Ausgangsbedingungen. Haltet fest, was sie bereits weiß, ob sie eingeloggt ist und welche Berechtigungen oder Angaben nötig sind. Vermeidet es, genau an dem Screen anzusetzen, den das Team gerade zufällig überarbeitet, wenn ein vorheriger Schritt das Erlebnis maßgeblich beeinflusst.
Der Vergleich von User Journeys und User Flows der Nielsen Norman Group unterscheidet eine fokussierte Interaktion von einem umfassenderen Erlebnis. Eine Journey Map deckt vielleicht den gesamten Weg über verschiedene Kanäle hinweg ab – vom Bedarf über Absprachen bis hin zur Abholung und Rückgabe der Bohrmaschine. Der Flow hingegen beleuchtet einen bestimmten Teil dieses Erlebnisses im Detail.
Entscheidungen und Systemzustände sichtbar machen
Zeigt sinnvolle Verzweigungen: Das Gerät ist verfügbar oder nicht; die Besitzerin sagt zu oder ab; die anfragende Person hat die nötigen Infos angegeben oder nicht. Plant Lade-, Bestätigungs- und Fehlerzustände dort ein, wo sie die nächste Handlung oder das Verständnis der Person beeinflussen.
Das Ganze kann ein einfaches Diagramm sein oder ein Wireflow, der Miniaturansichten der Screens miteinander verknüpft. Wählt das Format, das Entscheidungen am besten verständlich macht. Eine komplizierte Notation ist überflüssig, wenn schon ein paar beschriftete Schritte das Verhalten erklären. Bei komplexeren Interaktionen helfen separate, verlinkte Flows, um den Überblick zu behalten.
Unterscheidet klar zwischen einem beobachteten und einem geplanten Flow. Eine Aufgabenanalyse (Task Analysis) hilft dabei, aktuelle Abläufe zu erfassen – inklusive der Schritte außerhalb des Interfaces. Ein Design-Flow zeigt dann den Vorschlag, wie das Produkt diesen Ablauf unterstützen könnte. Wer diesen Unterschied deutlich benennt, verhindert, dass eine bloße Annahme fälschlicherweise als gesicherte Erkenntnis gilt.
Den tatsächlichen Weg testen
Nutzt realistische Aufgaben beim Prototypen-Testing, um zu sehen, wie die Teilnehmenden vorgehen. Ein Umweg deutet vielleicht auf ein verwirrendes Label hin, auf ein ungelöstes Bedürfnis oder auf eine absolut nachvollziehbare Alternative. Gleicht das Verhalten immer mit dem eigentlichen Ziel ab, bevor ihr eine Abweichung vom Diagramm als Fehler abstempelt.
Sobald das Produkt live ist, können Behavioral Analytics helfen, Wege und Drop-offs in größerem Umfang zu analysieren. Prüft dabei genau das Tracking und die Bedeutung der einzelnen Events: Ein geöffnetes Anfrageformular ist noch keine abgeschickte Anfrage, und ein späterer Wiedereinstieg bedeutet nicht immer einen Abbruch. Manchmal braucht es Session-Recordings oder qualitative Interviews, um das Muster wirklich zu verstehen.
Den Flow nah am Produkt halten
Aktualisiert das Diagramm, wenn sich Entscheidungen ändern, und macht kenntlich, welche Version es beschreibt. Ein Flow, der einen neuen Berechtigungsschritt oder einen Recovery-Pfad unterschlägt, führt Design, Development und Research schnell in die Irre – jedes Team auf andere Weise.
In unserem Verleih-Beispiel bedeutet Erfolg mehr als eine schnurgerade Linie von der Anfrage zur Bestätigung. Nutzer*innen müssen verstehen, was passiert ist, was noch von der anderen Person abhängt und was sie als Nächstes tun können. Ein Flow beweist seinen Wert genau dann, wenn er dem Team hilft, solche Abhängigkeiten zu erkennen und zu lösen, bevor die Kundschaft darauf stößt.