Plane Nutzerinterviews mit einem funktionierenden Prototyp in 48 Stunden: schnell rekrutieren, Tasks schreiben, Notizen erfassen und Feedback in klare Build‑Requests umwandeln.
Ein funktionierender Prototyp beendet die meisten Diskussionen schnell. Wenn jemand versucht, eine echte Aufgabe zu erledigen, hörst du auf zu raten und siehst, was die Person tatsächlich tut. Darum sind Nutzerinterviews mit einem funktionierenden Prototyp besser als Ideen-Debatten im Chat, selbst wenn der Prototyp grob ist.
Mit 3 bis 6 Sessions kannst du viel lernen, solange du den Umfang eng hältst. Du bekommst keine perfekten Statistiken, aber wiederkehrende Muster, die du diese Woche beheben kannst.
In 48 Stunden kannst du zuverlässig herausfinden, wo Leute hängenbleiben oder zurückspringen, welche Labels sie verwirren, was sie zuerst versuchen (und was sie ignorieren), was fehlt, bevor sie dem Flow vertrauen, und welche Momente Zweifel erzeugen — etwa Preisgestaltung, Berechtigungen oder das Speichern von Fortschritt.
Dieser Ansatz vermeidet große Forschungsprojekte, lange Umfragen und offene Fangfahrten. Du willst nicht den ganzen Markt abbilden. Du willst die größte Reibung in einem wichtigen Flow entfernen.
Definiere ein einziges Lernziel, bevor du jemanden einplanst. Ein einfaches Format funktioniert gut: „Kann ein erstmaliger Nutzer X in unter Y Minuten ohne Hilfe erledigen?“ Wenn du ein einfaches CRM baust, könnte das lauten: „Kann ein neuer Nutzer einen Kontakt anlegen, taggen und wiederfinden?“
Wenn du deinen Prototyp schnell in einem Tool wie Koder.ai gebaut hast, bleibt das Ziel gleich: wähle einen Flow, beobachte reale Nutzer beim Ausprobieren und erfasse genau, was geändert werden muss.
Eine 48‑Stunden‑Runde funktioniert nur, wenn du den Scope reduzierst. Wähle einen konkreten Nutzertyp und ein Szenario, das sie bereits verstehen. Wenn du Onboarding, Preisgestaltung, Einstellungen und Edge‑Cases in einer Session unterbringen willst, bekommst du Meinungen statt Beweise.
Schreibe ein Ein‑Satz‑Ziel wie: „Kann ein erstmaliger freiberuflicher Designer eine Rechnung erstellen und in unter 3 Minuten ohne Hilfe versenden?“ Dieser Satz sagt dir, wer die Person ist, was sie tun muss und wie „gut“ aussieht.
Entscheide, was du messen willst, bevor du mit jemandem sprichst. Halte es einfach und während der Session sichtbar. Für die meisten Teams ist das eine Mischung aus Geschwindigkeit (Zeit bis zum Abschluss), Reibung (wie oft sie hängenbleiben oder „und jetzt?“ fragen), Navigationsproblemen (Zögern, nochmal lesen, Zurückspringen) und Vertrauenssignalen (Sorgen um Zahlung, Privatsphäre oder Fehler).
Schreibe dann 3 bis 5 Fragen, die du bis zum Ende der Runde beantwortet haben musst. Beispiele:
Interview nicht endlos weiter, nur weil du könntest. Entscheide vorher, wann Schluss ist, damit du wieder mit dem Bauen weitermachen kannst. Eine praktische Regel: stoppe nach fünf Sessions, oder früher, wenn die gleichen zwei Hauptprobleme in drei aufeinanderfolgenden Sessions wiederholt auftreten.
Beispiel: Wenn drei von fünf Teilnehmern „Erstelle Rechnung“ nicht finden, weil es unter „Abrechnung“ versteckt ist, hast du bereits eine klare Build‑Anforderung: Beschrifte das Label um, verschiebe den Einstiegspunkt und teste die eine Änderung erneut.
Du kannst nützliche Nutzerinterviews mit einem funktionierenden Prototyp in zwei Tagen durchführen, wenn du es wie einen kurzen Sprint behandelst: rekrutieren, vorbereiten, durchführen und dann sofort synthetisieren. Ziel: 3 bis 5 Sessions. Drei sind das Minimum, um die größten Probleme zu erkennen. Fünf zeigen meist Muster.
Ein realistischer Plan sieht so aus:
Wenn die Rekrutierung langsam läuft, warte nicht. Reduziere den Scope und erweitere die Verfügbarkeit. Biete mehr Zeitfenster an (auch früh morgens oder abends), verkürze Sessions auf 15 Minuten oder rekrutiere aus einem näheren Kreis, der trotzdem zu deinem Nutzertyp passt.
Um organisiert zu bleiben, richte vor dem ersten Call ein kleines Ordnersystem ein:
01_Recruiting02_Recordings03_Notes04_Synthesis05_TicketsBenenne Dateien wie P01_2026-01-16_Record.mp4 und P01_Notes.md. Diese kleine Gewohnheit macht spätere Reviews des Prototyp‑Usability‑Tests einfacher.
Geschwindigkeit ist wichtiger als Perfektion. Dein Ziel ist keine statistisch perfekte Stichprobe. Es sind 5 bis 8 echte Personen, die ungefähr zu deinen Nutzern passen und innerhalb eines Tages gebucht werden.
Beginne mit den schnellsten Pools, dann erweitere. Starte bei Leuten, die bereits nach dem Produkt fragen (Kunden, Trial‑Nutzer, Warteliste), dann zu jüngsten Gesprächen (Support‑Threads, Demo‑Anfragen, E‑Mail‑Antworten). Wenn du mehr brauchst, suche Communities, in denen das Problem diskutiert wird, bitte um Einführungen über Freunde‑von‑Freunden (nicht um Meinungen) und sprich ehemalige Kollegen oder Kunden mit ähnlichem Workflow an.
Halte die Einladung kurz und konkret. Mach klar, dass es kein Sales‑Call ist und dass du das Produkt testest, nicht die Person. Nenne, was du baust und für wen, die Bitte (20 Minuten per Video oder Audio), was sie tun werden (2–3 Tasks am Prototyp) und ein einfaches Dankeschön wie eine kleine Geschenkkarte, einen kostenlosen Monat oder eine Spende. Biete zwei Zeitoptionen heute oder morgen an.
Wenn du einen schnellen internen CRM‑Prototyp (z. B. in Koder.ai) für Freelancer gebaut hast, lade sowohl „chaotische Spreadsheet“-Nutzer als auch Menschen ein, die bereits ein CRM nutzen. Diese Mischung verhindert, dass du nur Feedback von Power‑Usern bekommst. Verlass dich nicht nur auf enge Freunde — die wollen meist nett sein.
Anreize sollten normal wirken, nicht peinlich. Ein kleiner fixer Betrag funktioniert besser als „zahl, was du willst“. Wenn du einen kostenlosen Monat anbietest, sorge dafür, dass dafür kein Kauf nötig ist.
Buch immer Extras. Rekrutiere zwei Personen mehr als nötig. No‑Shows passieren; Backups halten deinen Zeitplan intakt.
Spare Stunden, indem du Screening, Terminvereinbarung und Einverständnis in einem schnellen Ablauf erledigst. Bestätige, dass sie wie dein echter Nutzer aussehen, buche die Zeit und mache Aufnahme und Notizen vor dem Treffen klar.
Ein leichtes Screener‑Formular kann drei Fragen haben:
Achte auf Warnsignale, die Sessions verschwenden. Leute, die weit von deinem Ziel entfernt sind, liefern selbstbewusstes Feedback, das nicht passt. Übermäßig engagierte Personen (enge Freunde, Partner, Wettbewerber) verfolgen oft eine persönliche Agenda. Sehr beschäftigte Leute werden hetzen, multitasken oder nicht erscheinen.
Für die Planung halte es eng: 30‑minütige Sessions mit 15 Minuten Puffer. Der Puffer ist für saubere Notizen, das Benennen von Aufnahmen und das Zurücksetzen des Prototyps. Wenn du Calls ohne Pause hintereinandersetzt, werden die Notizen schlampig und Muster gehen verloren.
Das Einverständnis reicht als kurze Nachricht: frage um Erlaubnis zu aufnehmen, erkläre, dass Notizen zur Produktverbesserung genutzt werden und dass Zitate anonymisiert werden. Biete eine einfache Opt‑out‑Option: Sie können die Aufnahme ablehnen und du machst stattdessen Notizen.
Sende eine kurze Vorab‑Nachricht mit Zeit, erwarteter Länge, Agenda (5 Minuten Intro, 20 Minuten Tasks, 5 Minuten Abschluss) und was sie brauchen (Laptop vs. Handy, Login falls nötig, ruhiger Ort). So verhinderst du Überraschungen wie „Ich bin mobil eingestiegen“, die den Prototyp‑Usability‑Test stören.
Ein gutes Interview kann trotzdem scheitern, wenn der Prototyp chaotisch ist. Ziel ist nicht, mit Breite zu beeindrucken. Ziel ist, dass Nutzer die Tasks versuchen können, ohne an Sackgassen zu stoßen oder dass du erklären musst.
Halte den Prototyp klein. Zeige nur die Bildschirme und Pfade, die deine Tasks benötigen, und verstecke alles andere. Ein kürzerer Pfad schlägt eine „vollständige App“, die halb‑fertig ist.
Lass den Inhalt echt wirken. Ersetze lorem ipsum durch glaubwürdige Texte und Daten, damit Nutzer natürlich reagieren. Wenn du einen CRM‑Flow testest, zeige 6–10 Kontakte mit Namen, Firmen und ein paar Notizen. Beim Checkout: realistische Preise und Lieferoptionen. Gefälscht, aber konkret, ist besser als generisch.
Entscheide vor Sessions, was du jedes Mal beobachtest und notierst: wo sie zuerst klicken, Momente der Verwirrung (was sie sagen und was sie danach tun), wo sie in Schleifen geraten oder zurückspringen, die Begriffe, die sie für Funktionen verwenden, und Fragen, die fehlende Informationen offenbaren.
Richte ein dediziertes Testkonto und eine Reset‑Routine ein, damit jeder Teilnehmer vom gleichen Zustand startet. Wenn der Prototyp Datensätze erstellt, halte eine kurze Reset‑Checkliste bereit (Warenkorb leeren, zuletzt erstelltes Element löschen, zur Startseite zurückkehren, aus- und wieder einloggen).
Wähle Erfassungswerkzeuge vor dem ersten Gespräch. Nimm den Call auf, wenn möglich, und habe eine einfache Notizvorlage mit drei Spalten: Aufgabe, Beobachtungen (was passierte) und Zitate (wortwörtlich). Wenn du Koder.ai nutzt, macht ein Snapshot vor der ersten Session das Zurückrollen einfacher, falls du etwas versehentlich mitten am Tag änderst.
Ein gutes Task‑Skript bringt Leute dazu, sich wie im echten Leben zu verhalten, nicht wie bei einer Prüfung. Halte es kurz, wiederholbar und an einem Hauptszenario ausgerichtet. Für einen funktionierenden Prototypen reichen meist 2 bis 4 Tasks, um Muster zu erkennen, ohne zu hetzen.
Beginne mit dem Hauptszenario in einfachen Worten (z. B.: „Ich will mein erstes Projekt einrichten und einen Kollegen einladen“). Wähle dann Tasks, die Momente repräsentieren, in denen ein Fehlschlag besonders schadet: Erstkonfiguration, Finden einer Schlüssel‑Funktion und das Abschließen einer bedeutenden Aktion.
Verwende die gleiche Struktur in jeder Session, damit Ergebnisse vergleichbar sind:
Formuliere jede Aufgabenbeschreibung so, dass sie nicht den Button‑Namen oder den genauen Pfad verrät. Schlecht: „Klicke Snapshots und rolle zurück.“ Besser: „Du hast einen Fehler gemacht und möchtest zur Version von gestern zurück. Zeig mir, was du tun würdest.“
Nach jedem Task stelle eine kurze Frage. Vor dem Klick: „Wo würdest du anfangen?“ Danach: „Warum hast du diesen Weg gewählt?“ Wenn sie steckenbleiben, frage „Worauf suchst du gerade?“ statt „Hast du das Menü gesehen?“
Wenn dein Prototyp in Koder.ai gebaut wurde, halte Tasks an Ergebnissen orientiert (eine App erstellen, Quellcode exportieren, eine eigene Domain setzen) statt an Plattform‑Begriffen. So lassen sich deine Notizen leichter in Build‑Requests übersetzen.
Beginne jede Session auf die gleiche Weise. Das senkt Nervosität und erleichtert Vergleiche.
Starte mit einem kurzen Skript: danke, erkläre, dass du das Produkt testest (nicht die Person) und dass es keine falschen Antworten gibt. Bitte sie, laut zu denken und zu teilen, was sie erwartet, bevor sie klicken.
Gib einen Task nach dem anderen und schweige dann. Deine Hauptaufgabe ist zu beobachten, wo sie zögern, und kurze, neutrale Fragen zu stellen wie „Woran denkst du gerade?“ und „Was hast du erwartet zu sehen?“ Vermeide Erklären, Lob oder Verteidigung des Prototyps.
Wenn sie feststecken, stups kurz an, bevor du rettest. Ein guter Stups bezieht sich auf ihr Ziel, nicht auf die Oberfläche: „Was würdest du als Nächstes probieren?“ oder „Wo würdest du danach suchen?“ Wenn sie länger als eine Minute wirklich blockiert sind, geh weiter und notiere es als hoch‑kritisches Problem. Widerstehe dem Drang, den Prototyp während des Calls zu reparieren. Erfasse das Problem und halte die Session am Laufen.
Feature‑Wünsche sind nützlich, aber debattiere sie nicht. Parke sie mit einer Frage: „Welches Problem würde das für dich lösen?“ Dann kehre zur aktuellen Aufgabe zurück.
Beende ebenfalls konsistent. Frage, was ihnen gefallen hat, was frustrierend war, ob sie bezahlen würden (und was fair erscheint) und ob du sie nach dem nächsten Update noch einmal kontaktieren darfst.
Gute Notizen sind nicht „alles, was passiert ist“. Sie sind kleine, konsistente Einheiten, die du später sortieren kannst. Wenn du die Struktur in allen Sessions gleich hältst, zeigen sich Muster ab der dritten Interviewrunde.
Wähle ein Notiz‑Dokument oder eine Tabelle, die alle Beobachter verwenden. Erstelle pro Task‑Versuch eine Zeile und schreibe kurze, sachliche Notizen an den gleichen Stellen. Einfaches Layout:
Zeitstempel erlauben es, schnell zu Aufnahmen zurückzuspringen und Wortwahl zu prüfen. Task‑Nummern verhindern, dass du Probleme zwischen Flows vermischst.
Wenn etwas schiefgeht, schreibe es als einen einfachen Satz, den ein Kollege ohne Kontext verstehen würde. Nenne den Moment, nicht deine Interpretation.
Beispiel: „T2 06:14: Klickte ‚Speichern‘ und erwartete eine Bestätigung, aber nichts änderte sich; sie fragte, ob es funktioniert hat."
Füge ein Zitat hinzu, wenn es die Aussage stärkt, besonders bei Vertrauens‑ oder Verwirrungsfragen („Ich bin mir nicht sicher, ob das sicher ist“ oder „Wo fange ich an?“). Zitate erleichtern die Priorisierung, weil sie die Wirkung zeigen.
Halte Tags klein, damit du schnell filtern kannst:
Wenn dein Prototyp in Koder.ai gebaut wurde, konzentriere Notizen auf Nutzer‑ und Produktverhalten, nicht darauf, wie der Prototyp entstanden ist.
Eine letzte Regel: Wenn du eine Notiz nicht in einen Ticket‑Titel umwandeln kannst, schreibe sie neu, bis du es kannst.
Der schnellste Weg, Momentum zu verlieren, ist, Feedback als Zitate und Eindrücke zu belassen. Formuliere, was du gesehen hast, als Build‑Requests, die ein Entwickler ohne Rätselraten umsetzen kann.
Beginne damit, Probleme nach Task zu gruppieren, nicht nach Person. Wenn drei Leute beim „Konto erstellen“ Probleme hatten, ist das ein Problem mit mehreren Datenpunkten, nicht drei separate Meinungen.
Nutze ein einheitliches Request‑Format, damit jedes Issue vergleichbar ist:
Trenne „Formulierungs‑ und Klarheits“-Fixes von „Scope“-Änderungen. „Ich weiß nicht, was dieser Button macht“ ist oft ein Label‑ oder Platzierungs‑Fix. „Ich brauche Exporte, Rollen und Genehmigungen“ ist eine größere Produktentscheidung. Beides zu vermischen führt zu aufgeblähten Tickets.
Entscheide dann für jedes Problem: jetzt fixen, erneut testen oder parken. Eine einfache Ordnungsmethode ist, Nutzer‑Impact, Aufwand, Confidence (wiederholt?) und die nächste Aktion (bauen, retesten, parken) zuzuweisen.
Wenn du in Koder.ai arbeitest, schreibe die Akzeptanzprüfung in klarem Deutsch, damit du sie direkt in deinen Build‑Chat als testbare Anweisung einfügen kannst.
Ein nicht‑technischer Gründer baut einen einfachen CRM‑Onboarding‑Flow in Koder.ai und führt am nächsten Tag Nutzerinterviews durch. Das Ziel ist eng: Kann ein Vertriebsmitarbeiter ohne Hilfe bis zum „erstes Deal erstellt“ kommen?
Die Rekrutierung ist schnell: Er kontaktiert sein Netzwerk und lokale Sales‑Communities, bietet eine kleine Geschenkkarte. Fünf Vertriebsmitarbeiter buchen 20‑minütige Slots an einem Nachmittag.
Jede Session nutzt dieselben drei Tasks, Wort für Wort gelesen:
In fünf Sessions protokollieren sie wiederkehrende Probleme und ein paar Blocker. Zwei Vertriebsmitarbeiter finden die Import‑Funktion nicht. Drei glauben, „Reminder“ sei eine Benachrichtigungs‑Einstellung, nicht eine Follow‑up‑Funktion.
Am Ende des Tages werden diese Beobachtungen zu sofort umsetzbaren Build‑Requests:
Darum geht es: konsistente Tasks, wiederkehrende Muster und Tickets, die so klar geschrieben sind, dass sie noch am selben Tag gebaut werden können.
Die meisten schlechten Interviewergebnisse kommen von wenigen kleinen Fehlern, nicht vom Prototyp selbst.
Suggestivfragen wie „Das ist doch sinnvoll, oder?“ erzeugen höfliches Einverständnis. Nutze neutrale Aufforderungen wie „Was denkst du, was das macht?“ und schweige dann.
Zu viel in einer Session testen führt zu oberflächlichen Kommentaren und schwachen Signalen. Wähle 2–3 Kern‑Flows.
Das Script unterwegs ändern zerstört die Vergleichbarkeit. Parke neue Ideen in einem Backlog und halte Tasks stabil.
Unordentliche Notizen sind ein stiller Fehlschlag. Wenn du dich auf Erinnerung verlässt, merkst du meist die lustigen Stellen, nicht die schmerzhaften. Schreibe den genauen Schritt auf, an dem sie hängenblieben und was sie danach versucht haben.
Ein einfacher Realitätscheck: Wenn ein Teilnehmer „Sieht gut aus“ sagt, aber 90 Sekunden braucht, um den nächsten Button zu finden, sind seine Aktionen die Daten. Das Kompliment ist Rauschen.
Eine laute Meinung kann zum Plan werden. Behandle starke Meinungen als Hypothese, bis du dasselbe Problem in mehreren Sessions siehst.
Wenn du große Änderungen vornimmst, teste schnell nach. Schon zwei kurze Sessions können bestätigen, dass du das Problem wirklich gelöst hast, statt es nur verschoben zu haben.
Bevor du den ersten Call buchst, sichere die Basics:
Direkt nach jeder Session mache einen Drei‑Minuten‑Check, solange es frisch ist: schreibe deine drei wichtigsten Probleme und eine Überraschung auf. Wenn du sie nicht benennen kannst, sind deine Tasks zu breit oder deine Notizen zu vage.
Am selben Tag mache eine kurze Zusammenfassung, die rohe Notizen in Entscheidungen verwandelt. Gruppiere ähnliche Probleme, wähle, was am wichtigsten ist, und definiere, was du als Nächstes ändern wirst.
Plane dann ein Retest innerhalb von 72 Stunden nach dem Ausrollen der Fixes. Schon drei schnelle Sessions können bestätigen, ob die Änderung gewirkt hat.
Wenn du in Koder.ai iterierst (koder.ai), kann Planning Mode helfen, Erkenntnisse als konkret abgegrenzte Aufgaben zu formulieren ("Ändere X, damit Nutzer Y ohne Z tun können"), und Snapshots machen es einfach, Fixes schnell auszuprobieren, ohne eine stabile Version zu verlieren.
Ziele für 3 bis 5 Sessions. Drei zeigen meist die größten Blocker, fünf reichen oft aus, um Muster zu bestätigen. Hör früher auf, wenn dieselben zwei Hauptprobleme in drei Sessions hintereinander auftauchen, und wechsle dann zum Fixen und Retesten.
Formuliere einen Ein-Satz-Ziel, das Nutzer, Aufgabe und ein messbares Kriterium nennt. Gutes Format: „Kann ein erstmaliger [Nutzertyp] [Aufgabe] in unter [Zeit] ohne Hilfe erledigen?“ Das hält die Session auf beobachtbares Verhalten konzentriert.
Wähle 2 bis 4 Tasks, die die wichtigsten Momente eines Flows abdecken, z. B. Erstkonfiguration und eine sinnvolle Aktion. Formuliere die Aufgaben outcome-basiert: du testest, ob Leute erfolgreich sind, nicht, ob sie einen bestimmten Button finden.
Beginne bei den schnellsten Quellen: Leute, die dem Produkt bereits nah sind (Trial‑Nutzer, Warteliste), zuletzt geführte Support‑Unterhaltungen oder Demo‑Anfragen. Halte die Einladung kurz, sage klar, dass es kein Sales‑Call ist, und biete zwei konkrete Zeiten heute oder morgen an.
Frag drei kurze Dinge: Was nutzt du heute dafür? Was ist beim letzten Mal passiert? Welche Rolle beschreibt dich am besten (und warum)? Vermeide Leute, die weit vom Ziel entfernt, zu engagiert (enge Freunde, Wettbewerber) oder zu beschäftigt sind, um aufmerksam teilzunehmen.
Bitte um Erlaubnis, aufzunehmen; erkläre, wofür Aufnahme und Notizen verwendet werden (Produktverbesserung) und dass Zitate anonymisiert werden. Biete eine einfache Option an, die Aufnahme abzulehnen – sie können trotzdem teilnehmen und du machst Notizen.
Beschränke den Prototyp auf die Bildschirme, die deine Tasks benötigen, und fülle Inhalte mit realistischen Daten, damit Nutzer natürlich reagieren. Lege ein Testkonto an und eine Reset‑Routine, damit jede Person vom gleichen Zustand startet.
Führe jede Session gleich durch: gleiche Einleitung, gleiche Aufgaben, und bleibe größtenteils still, während sie arbeiten. Stelle neutrale Fragen wie „Wonach suchst du gerade?“ und vermeide Belehrungen oder Verteidigungen des Designs.
Schreibe kurze, konsistente Notizen pro Task‑Versuch: was sie versucht haben, was sie erwartet haben und was passierte; füge ein Zitat hinzu, wenn es relevant ist. Vergib eine einfache Schwere‑Einstufung (Blocker, verlangsamt, gering), damit du schnell priorisieren kannst, während die Belege frisch sind.
Formuliere wiederkehrende Probleme als Build‑Requests mit fünf Teilen: Problem, Beleg (Beobachtung oder Zitat + Ort), Auswirkung, vorgeschlagene Änderung und eine einfache Akzeptanzbedingung, die du im nächsten Test überprüfen kannst. Gruppiere Probleme nach Task, nicht nach Teilnehmer.