Persona- und Task-Flow-Denken: Alan Coopers einfache Methode

Warum Funktionslisten nicht automatisch zu guten Bildschirmen führen

Eine lange Funktionsliste kann sich wie Fortschritt anfühlen. Du kannst auf sie zeigen und sagen: „Wir wissen, was wir bauen.“ Dann versuchst du, den ersten Bildschirm zu skizzieren, und merkst, dass die Liste dir nicht sagt, was der Nutzer gerade tut, was er fertigbringen will oder was die App zuerst zeigen sollte.

Funktionslisten verbergen Prioritäten. „Benachrichtigungen“, „Suche“, „Profile“ und „Einstellungen“ klingen alle wichtig, also landen am Ende alles auf derselben Ebene. Sie verbergen auch die Absicht. Menschen stehen nicht auf und wollen „Filter“ oder „Admin‑Rollen“. Sie wollen einen Termin buchen, bezahlt werden, eine Lieferung verfolgen oder Fotos mit der Familie teilen.

Deshalb ist der Gegensatz Funktionsliste vs. Nutzerziele nicht nur eine Planungsdebatte. Er verändert die Bildschirme. Wenn das Ziel „einen Haarschnitt für Freitag buchen“ ist, braucht der erste Bildschirm Zeitfenster und einen klaren nächsten Schritt, nicht ein Menü mit zehn Funktionen.

Funktionslisten ziehen Teams auch zu früh in UI‑Debatten. Leute streiten über Button‑Platzierung, Tab‑Namen, Dark Mode und wie viele Einstellungsseiten es geben sollte. Diese Entscheidungen fühlen sich konkret an, sind aber Vermutungen, getroffen bevor ihr euch auf die Aufgabe geeinigt habt, die die App jemandem helfen muss zu erledigen.

Ein besserer Anfang ist simpel: Wähle einen realen Nutzer, wähle einen Job, den er in einer Sitzung erledigen will, und mappe die kleinste Menge an Schritten, die ihn zum Ziel bringt. Sobald du das tust, entstehen Bildschirme fast von selbst. Jeder Bildschirm verdient seinen Platz, weil er einen Schritt im Flow unterstützt.

Alan Coopers Kernidee: am Ziel orientieren, nicht an Features

Alan Cooper popularisierte eine Verschiebung, die heute noch gilt: Hör auf, Software wie einen Haufen Features zu behandeln, und beginne sie als Interaktion zu betrachten. Es geht nicht darum, was deine App kann. Es geht darum, was eine Person erledigen möchte und ob die App ihr dabei mit minimaler Reibung hilft.

Diese Denkweise ist das, was viele heute unter Alan Cooper Interaktionsdesign verstehen. Fokussiere dich auf Absicht und Reihenfolge. Wenn du die Reise klar beschreiben kannst, entwerfen sich die Bildschirme fast von selbst. Wenn nicht, rettet dich eine längere Funktionsliste nicht — sie schafft meist Unordnung, weil jedes Feature Entscheidungen, Buttons und Randfälle hinzufügt.

Coopers praktisches Werkzeug besteht aus zwei Teilen:

• Personas (wer): Wähle einen konkreten Nutzertyp und mach ihn real genug, dass du vorhersagen kannst, was er tun wird.
• Task Flows (wie): Mappe die kleinste Menge an Schritten, die diese Persona von der Absicht zum Ergebnis bringt.

Ein Flow zwingt dich, Fragen zu beantworten, die eine Funktionsliste vermeidet: Was löst die Aufgabe aus, wie sieht „Erfolg“ aus, welche Entscheidungen muss der Nutzer jetzt treffen und welche Informationen brauchst du wirklich in jedem Schritt.

Selbst wenn du mit einer chat‑basierten Vibe‑Coding‑Plattform wie Koder.ai bauen willst, brauchst du diese Klarheit. Andernfalls erzeugst du viele Bildschirme, die plausibel aussehen, aber nicht zu einer befriedigenden Start‑bis‑Ende‑Erfahrung verbinden.

Personas: Wähle einen realen Nutzer, für den du zuerst designst

Eine Persona ist eine kurze, glaubwürdige Beschreibung der Person, für die du zuerst entwirfst. Sie ist keine vollständige Biografie. Sie ist nur so detailliert, dass du Entscheidungen treffen kannst, ohne ständig „kommt drauf an“ zu hören.

Beginne mit Zielen und Kontext, nicht mit Demografie. Dieselbe „beschäftigte Elternperson“ verhält sich anders, je nachdem, wo sie ist, welches Gerät sie nutzt und unter welchem Zeitdruck sie steht. Gute Personas für Produktdesign machen diese Einschränkungen konkret, damit deine Bildschirme einen klaren Zweck haben.

Ist deine Persona zu vage, merkst du das sofort. Sie klingt nach „alle“, wird hauptsächlich demografisch, listet Vorlieben ohne klares Ziel und kann nicht erklären, warum diese Person die App heute nutzen würde.

Halte die Persona leichtgewichtig. Ein paar Zeilen genügen:

• wer sie sind (Rolle),
• wann und wo sie die App nutzen (Kontext),
• ihr oberstes Ziel (in einfachen Worten),
• was sie heute verlangsamt (Schmerzpunkt),
• wie „Erfolg“ aussieht (ein einfacher, testbarer Gewinn).

Beispiel: „Mina, eine Zahnarztrezeptionistin, nutzt ihr Telefon zwischen Patienten. Ihr Ziel ist, die Termine für morgen schnell zu bestätigen. Ihr Problem ist, dass sie Leuten hinterherrennen muss, die nicht antworten. Erfolg ist, eine Erinnerung zu schicken und in unter einer Minute einen klaren ‚bestätigt‘‑Status zu sehen."

Eine weitere Regel: Eine Persona ist ein Design‑Werkzeug, kein idealer Kundenprofil. Du kannst später viele Zielgruppen haben, aber jetzt brauchst du eine primäre Persona. Wenn Leute über einen Bildschirm streiten, bring es zurück zu Mina: Hilft das ihr, ihr Ziel in ihrem realen Kontext zu erreichen, oder ist es nur ein weiteres Feature?

Task Flows: Mappe die Schritte, die zählen

Ein Task Flow ist die kleinste Menge an Schritten, die eine Person braucht, um ein klares Ziel zu erreichen. Es ist keine Sitemap, keine Funktionsliste und keine komplette Journey‑Map. Es ist ein Weg von „Ich will X tun“ bis „X ist erledigt“.

Ein guter Flow beginnt mit einem Auslöser und endet mit einem Erfolgszustand. Der Auslöser ist das, was den Nutzer beginnen lässt: ein Bedürfnis, eine Nachricht, ein Button oder ein Problem. Der Erfolgszustand ist, wie „fertig“ in einfachen Worten aussieht: „Termin gebucht und bestätigt“, „Rechnung gesendet“ oder „Passwort geändert und ich bin eingeloggt“. Wenn du beides nicht in je einem Satz beschreiben kannst, ist der Flow noch verschwommen.

Start, Ende und die Entscheidungen dazwischen

Die meisten Flows sind einfach, bis eine Entscheidung auftaucht. Entscheidungen sind die Gabelungen, die den weiteren Verlauf verändern, z. B. „Hast du schon ein Konto?“ oder „Ist dieser Artikel auf Lager?“ Diese Gabeln früh zu benennen verhindert, dass du einen perfekten Happy Path entwirfst, der beim ersten realen Fall zusammenbricht.

Um einen Flow zu formen, ohne ihn zu überdenken, beantworte fünf Fragen:

• Was startet die Aufgabe?
• Was ist der einzelne Erfolgsmoment?
• Welche Informationen sind erforderlich (und was ist optional)?
• Welche Entscheidungen können den Pfad verändern?
• Was kann schiefgehen und was soll der Nutzer dann sehen?

Wo Nutzer Bestätigung brauchen

Menschen brechen ab, wenn sie unsicher sind. Dein Flow sollte die Momente markieren, in denen Beruhigung zählt: Fortschritt, Status, Bestätigung und klare Fehler.

Ein einfaches Beispiel ist „mein Passwort zurücksetzen“. Auslöser: „Ich kann mich nicht einloggen.“ Erfolg: „Ich bin wieder in meinem Konto.“ Entscheidung: „Hast du Zugriff auf deine E‑Mail?“ Beruhigungs‑Punkte: „E‑Mail gesendet“, „Link abgelaufen“, „Passwort geändert“, „du bist eingeloggt“. Sobald diese Punkte aufgeschrieben sind, sind die Bildschirme offensichtlich, weil jeder Schritt einen Ort zum Stattfinden und eine Nachricht braucht, die Zweifel beseitigt.

Eine leichte Methode: von vagen Ideen zu einem klaren ersten Flow

Die meisten App‑Ideen beginnen als Haufen Substantive: Dashboard, Chat, Kalender, Zahlungen. Der schnellere Weg zur Klarheit ist, die Idee in ein Versprechen, eine Person und eine Schrittfolge zu pressen.

Beginne mit einem Satz, der auf eine Startseite könnte. Mach ihn spezifisch genug, dass jemand nickt oder sagt: „Nein, das bin nicht ich.“ Beispiel: „Hilf freiberuflichen Designer:innen schneller bezahlt zu werden, indem du in unter 2 Minuten eine saubere Rechnung sendest und Kartenzahlungen annimmst."

Dann wähle eine primäre Persona für Version eins. Nicht „alle“, nicht „kleine Unternehmen“. Wähle eine Person, die du dir an einem normalen Dienstag vorstellen kannst. Wenn du für drei verschiedene Personen gleichzeitig designst, fügst du Bildschirme hinzu, die niemandem wirklich helfen.

Als Nächstes wähle ein Ziel, das du zuerst designst, idealerweise das, das den Hauptwert schafft. „Sich organisiert fühlen“ ist vage. „Eine Rechnung senden und bestätigen, dass sie angesehen wurde“ ist klar.

Ein wiederholbarer Prozess sieht so aus:

1. Schreibe das Ein‑Satz‑Versprechen (wer + Ergebnis + Zeit/Aufwand).
2. Definiere die primäre Persona und eine Schlüsselbeschränkung (Zeit, Gerät, Fähigkeit).
3. Entwirf den Happy Path als kurze Verben (wählen, eingeben, prüfen, bestätigen, bezahlen).
4. Füge 2–3 realistische Fehlerfälle hinzu, damit der Flow nicht bricht.

Schreibe erst eine Funktionsliste, wenn der Flow auf eine Seite passt. Halte sie kurz und priorisiert: die wenigen Features, die die Schritte möglich machen, plus das Minimum, um aus Fehlern zu retten.

Wenn du ein Build‑Tool wie Koder.ai verwendest, ist dies auch der Punkt, an dem der Planungsmodus hilft. Füge das Versprechen, die Persona und den Flow an einem Ort ein und halte das Team auf Kurs, bevor Bildschirme und Code sich vermehren.

Einen Flow in Bildschirme und Aktionen überführen (ohne UI zu überdenken)

Ein Task Flow ist eine Abfolge von Absichten. Verwandle nun jeden Schritt entweder in einen Bildschirm, auf dem der Nutzer landet, oder in eine einzelne Aktion, die er auf einem bestehenden Bildschirm ausführt.

Halte es direkt: ein Schritt = ein klares Ergebnis. Hat ein Schritt zwei Ergebnisse, sind es meist zwei Schritte.

Nenne Bildschirme nach Zweck, nicht nach Layout‑Teilen. „Uhrzeit wählen“ ist besser als „Kalender‑Screen“. „Details bestätigen“ ist besser als „Formularseite“. Zwecknamen halten dich beim, was passieren muss, nicht beim Aussehen.

Wenn du einen Flow in Bildschirme übersetzt, entscheide für jeden Schritt drei Dinge: was der Nutzer sehen muss, was er wählen muss und was er eingeben muss. Dann wähle die nächste offensichtliche Aktion (meist ein primärer Button). Entferne alles, was nicht hilft, diesen Schritt zu beenden.

Navigation sollte langweilig sein. Jeder Bildschirm sollte beantworten: „Was mache ich als Nächstes?“ Wenn jemand ein Menü braucht, um den nächsten Schritt zu finden, versucht der Bildschirm zu viel.

Halte zudem grundlegende Zustände als Notizen, nicht als vollständige Designs: Laden, leer, Erfolg, Fehler und wann die Hauptaktion deaktiviert sein sollte. Du willst, dass das Team diese Zustände beim Bauen im Kopf behält, nicht Tage mit Farbdebatten verbringt.

Tools wie Koder.ai können dir helfen, Bildschirme aus deinem Flow‑Text zu entwerfen, aber die Klarheit kommt weiterhin von dir: Zweck, benötigte Infos und die nächste Aktion.

Beispiel: Wie aus „einer Buchungs‑App" zusammenhängende Bildschirme entstehen

Stell dir vor, du willst eine einfache App, mit der Leute einen lokalen Kurs (Yoga, Nachhilfe, Haarschnitt) buchen. Eine Funktionsliste könnte „Suche, Kalender, Zahlungen, Erinnerungen“ sagen. Das sagt immer noch nicht, was der erste Bildschirm ist oder was passiert, wenn jemand „Buchen“ antippt.

Beginne mit einer Persona: Sam, ein beschäftigter Elternteil mit dem Telefon im Auto, der in unter 60 Sekunden einen Platz buchen will. Sam möchte kein Konto erstellen, nicht 20 Optionen vergleichen und keine langen Beschreibungen lesen.

Schreibe dann den Happy Path als kurze Geschichte: Sam öffnet die App, findet schnell den passenden Kurs, wählt eine Zeit, gibt einen Namen ein, bezahlt und bekommt eine klare Bestätigung.

Füge zwei Randfälle hinzu, um den Flow ehrlich zu halten: Der Kurs ist ausverkauft, während Sam eine Zeit antippt, und die Zahlung schlägt fehl.

Die daraus resultierenden Bildschirme sind einfach:

• Kurs finden: nahe/kommende Optionen mit einfachem Tag/Tag‑Filter und klaren Karten (Titel, Startzeit, Preis, verbleibende Plätze).
• Kursdetails: nächste verfügbare Zeiten zuerst, Basisinfos wie Dauer und Ort, und eine primäre Aktion: Zeit wählen.
• Zeit wählen: verfügbare Slots, klare „ausverkauft“‑Markierungen und schnelle Möglichkeit, das Datum zu wechseln.
• Deine Angaben: ein oder zwei Felder (Name, eventuell Telefon/E‑Mail für eine Quittung) und ein Weiter‑Button.
• Bezahlung: Gesamtpreis, Zahlungsmethode und eine einzige Zahlungsaktion.
• Bestätigung: Buchungsdetails und ein nächster Schritt (in Kalender hinzufügen oder Buchung ansehen).

Bei „ausverkauft“ handhabe es im Zeitwähler: erklär es schlicht, schlag den nächsten passenden Slot vor und halte Sam auf dem selben Bildschirm. Bei fehlgeschlagener Zahlung behalte die eingegebenen Daten, erkläre normal, was passiert ist, und biete „erneut versuchen“ und „andere Methode verwenden“ an.

Wenn du das in Koder.ai baust, kannst du es bitten, diese Bildschirme aus dem Flow‑Text zu generieren und dann Texte und Felder so lange zu straffen, bis das 60‑Sekunden‑Ziel echt wirkt.

Übliche Fallen, die Flows zum Scheitern bringen

Flows scheitern meistens aus einem Grund: Du designst für eine Menge, nicht für eine Person. Wenn die Persona „alle“ ist, wird jede Entscheidung zum Kompromiss. Der eine Nutzer will Geschwindigkeit, der andere Führung, der dritte totale Kontrolle. Das Ergebnis ist ein Flow, der versucht, allen gerecht zu werden, und niemanden wirklich bedient.

Die Lösung ist, die Persona so weit einzuschränken, bis Entscheidungen offensichtlich werden. Nicht „beschäftigte Berufstätige“, sondern „eine Rezeptionistin, die zwischen Telefonaten Termine bucht“ oder „ein Elternteil, der auf einem rissigen Handy einen Haarschnitt für sein Kind bucht“. Sobald du ihren Alltag vor Augen hast, kannst du entscheiden, was wegfällt.

Ein weiterer Fehler ist, vom Speichern auszugehen statt von dem, was jemand tun will. Wenn dein erster Entwurf auf Datenbankfeldern und internen Admin‑Schritten basiert, verwandelt sich das Produkt in lange Formulare und die Hauptaufgabe verschwindet. Menschen wollen nicht „Felder ausfüllen“. Sie wollen eine Buchung bestätigen, bezahlen, eine Erinnerung bekommen.

Eine dritte Falle ist „Extras zuerst“‑Denken. Einstellungen, Präferenzen, Rollen, Tags und Anpassung sind leicht aufzuzählen, also schleichen sie sich früh ein. Wenn die Kernaufgabe wackelig ist, fügen Extras nur mehr Pfade und Verwirrung hinzu.

Wenn du schnell Bildschirme mit einem Tool wie Koder.ai generierst, gilt dasselbe Risiko: Geschwindigkeit ist nur nützlich, wenn du den Flow ehrlich hältst — eine Persona, ein Ziel, ein klarer nächster Schritt auf jedem Bildschirm.

Schnelle Checkliste bevor du baust

Bevor du ein Design‑Tool öffnest oder zu programmieren beginnst, mach eine Runde, um sicherzugehen, dass deine Idee tatsächlich in Bildschirme übersetzbar ist, die Menschen fertigbringen.

Du solltest das Ziel der primären Persona in einem Satz mit einem klaren Endpunkt sagen können: „Buche einen Haarschnitt für Samstag um 11 Uhr und erhalte eine Bestätigung.“ Der Happy Path sollte auf eine Seite passen. Wenn er sich ausdehnt, hast du wahrscheinlich zwei Aufgaben vermischt oder für mehrere Personas gleichzeitig gelöst.

Prüfe, dass jeder Bildschirm nach Zweck benannt ist und mit einem Flow‑Schritt verknüpft ist (Zweck schlägt Widgets). Triff Entscheidungen und Bestätigungen explizit, nicht implizit. Wenn der Nutzer etwas wählen muss, zeig die Wahl. Wenn etwas Wichtiges passiert ist, zeig eine Bestätigung oder eine klare Fehlermeldung.

Streich dann alles, was die Aufgabe nicht voranbringt. Wenn ein Bildschirm dem Nutzer nicht hilft zu entscheiden, Informationen einzugeben, zu bezahlen oder zu bestätigen, ist er für die erste Version meist Rauschen.

Lies den Flow laut wie eine Geschichte: „Ich will X, ich mache A, dann B, dann bestätige ich, dann bin ich fertig.“ Wo du stockst, ist das Designproblem.

Wenn du Koder.ai benutzt, ist das auch ein starker Prompt‑Starter: Füge das Ein‑Satz‑Ziel und die Happy‑Path‑Schritte ein und bitte um die minimalen Bildschirme und Aktionen.

Nächste Schritte: Plane Version eins und beginne zu bauen

Wähle den einzelnen Flow, der am besten beweist, dass deine Persona ihr Ziel erreichen kann. Behandle ihn als Rückgrat. Alles andere ist optional, bis das Ende‑zu‑Ende funktioniert.

Mach aus diesem Flow einen kleinen Build‑Plan: die Handvoll Bildschirme, die die Persona besucht, die Aktionen, die sie auf jedem ausführt, die minimalen Daten, die das System wissen muss, eine kurze Liste von Fehlerfällen, die du abfangen musst, und den Erfolgszustand, der „fertig“ bestätigt.

Entscheide dann, was du kürzt. Kürzen ist nicht Minimalismus um des Minimalismus willen. Es geht darum, ein Hauptziel mühelos zu machen. Wenn ein Feature der Persona heute nicht hilft, das Flow‑Ziel zu erreichen, kommt es auf ‚später‘.

Validiere den Plan, indem du ihn vorspielst. Lies die Persona und geh dann die Schritte durch, als wärst du sie. Fehlende Informationen zeigen sich schnell: Woher kommt das Datum? Wie ändere ich meine Wahl? Was passiert, wenn ich einen Fehler mache?

Wenn du schneller vorankommen willst, nutze Koder.ai Planungsmodus, um Persona und Flow im Chat zu iterieren, bevor du Bildschirme generierst. Sobald du baust, helfen Features wie Snapshots und Rollback, Änderungen mutig zu testen und schnell zurückzudrehen, wenn ein „kleiner“ Tweak den Pfad bricht.