User (Flow + Customer) Journey?

Die Geschichte eines Reisenden

In einem Kommentar zu Julians erstem Blogpost der User-Centered-Design-Serie (hier) erreichte uns folgende Frage:

„Wäre es sinnvoll [..] neben Customer Journeys noch User Flows zu machen?“

In meinen, Julians, Augen eigentlich eine klare Sache: Customer Journeys und User Flows gehören in verschiedene Phasen unseres User-Centered-Design-Zyklus‘. Er kam mit mir, Victoria, ins Diskutieren. Wir merkten, dass es sich lohnt, ein bisschen weiter auszuholen. Denn manchmal kann es durchaus sinnvoll sein, User Flows in Customer Journeys zu integrieren. Doch eins nach dem anderen.

Customer Journeys umfassen also mehr als die eigentliche Systembenutzung. Genau das ist ihre Stärke: In kleinen „Geschichten“ lernen wir mehr über das Davor und Danach rund um unsere Anwendung – kurzum: den Nutzer*innenkontext. In ganz frühen Phasen der Visionsgestaltung ermöglicht uns eine solche Betrachtung überhaupt erst, die Einsatzmöglichkeiten (Touchpoints) einer App oder einer Software zu identifizieren. Vertiefend verwenden wir sie aber auch, um genauer zu verstehen, was eine Persona zu diesem Zeitpunkt in einem System wirklich erreichen will.

Customer Journeys für den Nutzer*innen-Kontext

Unter einer Customer Journey verstehen wir in der Regel eine visuelle Darstellung verschiedener „Stationen“ aus dem Alltag einer unserer Nutzer*innen. Was hier Alltag bedeutet und wie weit wir rein- oder rauszoomen, variiert dabei von Projekt zu Projekt. Wir haben mit Kunden Customer Journeys erstellt, bei denen es tatsächlich um eine ganz konkrete Zugreise von Altenbeken nach Kiel ging. Für einen anderen Kunden haben wir eine typische Arbeitswoche für einen Disponenten von Frachtschiffen modelliert.

Überraschendes Lernen

Auf den ersten Blick ist es dabei nicht immer ersichtlich, warum es sinnvoll sein könnte, auch den Kauf von Semmeln während der Zugfahrt nach Kiel, genauer: beim Umstieg in Hannover, mit zu modellieren; oder für eine unternehmensinternen Anwendung den Abteilungs-Jourfixe der Disponenten. Und doch können daraus sehr spannende Fragen erwachsen, die uns helfen, ein Produkt noch besser auf die zukünftigen Nutzer*innen zuzuschneiden: Wäre es nicht schick, wenn die App auch den Weg zum Bäcker im Bahnhof Hannover kennen würde? Oder wenn bekannt wäre, welche Kennzahlen im Abteilungs-Jourfixe der Frachtschiff-Disponenten regelmäßig präsentiert werden?

Um es zusammenzufassen: Wir nutzen Customer Journeys also vor allem in der Phase „Nutzer*innenkontext verstehen“ (mehr dazu in diesem Blogbeitrag), mit dem Ziel sowohl den Kontext als auch mögliche versteckte Anforderungen genauer zu ergründen.

User Flows…

Der User Flow dagegen kommt in einer viel späteren Phase zum Tragen: Beim Ideen entwickeln helfen uns User Flows detailliert festzulegen, wie der Ablauf in einer Applikation erfolgt. Es werden fertige Wireframes einzelner Screens durch alle für den Nutzer möglichen Interaktionen miteinander in Verbindung gebracht. Für unsere Reisenden-App haben wir also zunächst festgelegt, welche Elemente auf einem Startscreen angezeigt werden sollen. Anschließend haben wir uns überlegt, welche Absprungpunkte zu anderen Screens für den Nutzer oder die Nutzerin sinnvoll sind, und wie er oder sie diese erreicht.

Möchte unsere Kiel-Reisende nun direkt ein Ticket für die Rückfahrt nach Altenbeken kaufen, auf die Rechnung der Hinreise zugreifen oder doch etwas ganz anderes tun? Das halten wir dann in einer „großen Tapete“ fest, auf der die verschiedenen Screens mit Pfeilen verbunden werden. Wir versetzen uns anhand dieser User Flows in die Lage des Nutzers. Was möchte er oder sie in der App tun? Wie können wir die Elemente anordnen, damit er oder sie dieses Ziel möglichst intuitiv erreichen kann?

… für den Gesamtüberblick

So setzt sich Stück für Stück die ganze Applikation zusammen und ein Gesamtbild entsteht, das sowohl die Struktur als auch die Abläufe in einer Anwendung gemeinsam visualisiert. Das hilft uns zum einen, den Überblick zu behalten, und zum anderen, unsinnige Bedienschritte, etwa Zirkel oder lange Verschachtelungen, zu entdecken. Nicht nur wir Konzipierenden ziehen uns durch User Flows die Schuhe des Nutzers an. Auch für Nutzertests können die entstandenen User Flows eine gute Grundlage sein.

Dabei erleben wir immer wieder große Überraschungen: Was uns vorher super logisch erschien und auf dem Papier ganz prima aussah, fällt schon beim ersten Guerilla-Test mit Kolleg*innen durch. Und ein anderes Feature, was wir für eher nebensächlich gehalten haben, entpuppt sich als das wichtigste Hilfsmittel für eine bestimmte Nutzergruppe. So iterieren wir Stück für Stück zwischen Konzeption und Test, bevor User Flows zum zentralen Teil des Übergabepakets an Entwickler*innen werden. Bei der Implementierung nutzen wir sie dann zusammen mit einem Design-System als lebende Spezifikation und als entscheidende Orientierungshilfe.

Alles klar, oder?

Wir nutzen User Flows also in einer späteren Phase im User-Centered-Design-Zyklus, nämlich im „Ideen entwickeln“, und sind auch deutlich detaillierter unterwegs, als mit Customer Journeys. Ein weiterer Unterschied ist die Frequenz, mit der wir die beiden Artefakte nutzen. Customer Journeys sind langlebiger und im späteren Projektverlauf erstellen wir nur gelegentlich neue oder ändern sie. User Flows sind durch die entwicklungsnähere Ausrichtung deutlich schnelleren Zyklen unterworfen. Hier fließen neue Erkenntnisse und Änderungen täglich ein.

Basierend auf diese Erläuterung scheint die Differenzierung nun eindeutig zu sein. Die Artefakte werden zu unterschiedlichen Zeitpunkten erstellt und verfolgen verschiedene Ziele. Gemeinsam ist ihnen die Nutzerperspektive und die Modellierung eines zeitlichen Ablaufs. Die Customer Journey fokussiert dabei auf den Nutzer*innen-Kontext und die User Flows auf die Abläufe innerhalb der Applikation. Eigentlich alles klar, oder?

Oder doch nicht?

Bei genauem Hinsehen und in unserer Diskussion fällt aber auf, dass es Situationen gibt, in denen es sehr direkte Einflüsse des Kontextes auf die App-Nutzung gibt. Beispielsweise ist es für Reisende wesentlich, ob sie sich gerade auf der Reise befinden oder die Reise bereits abgeschlossen haben. Je nachdem stehen andere Funktionen im Vordergrund: Unterwegs interessiert mich, ob mein Zug Verspätung hat und ob der Anschluss in Hannover klappt. Nach der Reise will ich vielleicht komfortabel ein Rückfahrtticket buchen oder eine Rechnung einsehen.

In einem User Flow alleine würden wir diese wichtige Kontextinformation schnell übersehen. Es lohnt sich also zumindest, wesentliche Stationen einer Customer Journey als Strukturierungsmerkmal in den User Flow zu integrieren. So könnte es sein, dass der zentrale Übersichts-Screen einer Reisenden-App tatsächlich zwei unterschiedliche Wireframes hat, je nachdem, wo wir uns gerade befinden.

Der umgekehrte Fall ist uns auch schon untergekommen. Basierend auf Nutzungsanalysen haben wir festgestellt, dass wir Nutzer*innen immer wieder an einer bestimmten Stelle in der Bedienung verlieren. Rein aus Usability-Gesichtspunkten, also auf Basis des User Flows, konnten wir nichts feststellen, das auf eine besondere Schwierigkeit hindeutet. Auch die Nutzer*innentests haben keine größeren Probleme aufgeworfen. Erst die Betrachtung der Customer Journey hat uns auf die richtige Fährte gebracht:
Im Labortest lösten die Tester*innen die Aufgabe, einen Kauf, lediglich mit unserer App. Im echten Leben prüfen Nutzer*innen an dieser Stelle gerne zum Vergleich andere Optionen außerhalb unserer App, zum Beispiel Preise oder Daten. Sie kehren zum Teil erst später wieder zurück, und vollenden dann den Kauf. Entsprechend hatten wir es hier häufig mit „scheinbaren“ Abbrüchen zu tun: Die (in unserem Fall) Tickets wurden erworben, nur eben zu einem späteren Zeitpunkt. Uns war also ein reales Verhaltensmuster nicht bewusst, das in unseren Labortests schlicht und einfach nicht aufgetreten war und nicht auftreten konnte. Dem Team hat diese Erkenntnis geholfen, eine „Rückkehrfunktion“ neu zu priorisieren.

User (Flows + Customer) Journeys

Aus einem klaren „das ist was ganz anderes” zu Beginn des Blogbeitrags wird also ein „…kommt darauf an“. In jedem Fall lohnt es sich, den User-Centered-Design-Zyklus zumindest gelegentlich wirklich wieder vollständig zu durchlaufen und auch frühe Artefakte wie eine Customer Journey wieder gegen zu checken. Darüber hinaus gibt es Situationen, in denen es wertvoll und sogar notwendig ist, User Flows in Customer Journeys zu integrieren. Und zwar nicht nur im Kopf, sondern ganz explizit in den Dokumenten. So können wir die Stärken aus beiden Welten – der „echten“ in den Customer Journeys und der In-App-Welt in den User Flows gemeinsam nutzen.

---

Über den Autor