Wie viel Nutzerforschung ist vor dem Bau von Software genug?

Mit Entscheidungen statt einer Zahl beginnen

Es gibt keine allgemeine Zahl von Interviews, die Software sicher baubar macht. Fünf Gespräche können in einem engen Segment ein klares Muster zeigen, während zwanzig Gespräche nichts entscheiden, wenn die Teilnehmer nicht passen. Die bessere Frage lautet nicht „Wie viele Interviews brauchen wir?“, sondern „Welche Entscheidung soll die Forschung unterstützen?“

Notiere Entscheidungen, die das Projekt verändern könnten. Tritt das Problem häufig genug auf? Ist die Zielgruppe erreichbar? Erzeugt der heutige Workaround echte Kosten? Würden Nutzer ihr Verhalten ändern und wer bezahlt? Passt eine App besser zur Situation als eine Website oder ein Service? Forschung ist für den nächsten Schritt ausreichend, wenn diese Unsicherheiten akzeptabel reduziert sind.

Schreib Annahmen vor Beginn auf. Sonst wirkt ein Gespräch informativ, bestätigt aber nur bestehende Überzeugungen. Markiere Annahmen als bekannt, unsicher oder riskant. Konzentriere dich auf Annahmen, die das Produkt unnötig, schwer verkäuflich oder nicht umsetzbar machen könnten.

Menschen mit dem Problem befragen

Die Relevanz der Teilnehmer bestimmt die Qualität. Sprich mit Menschen, die zum Kontext gehören und das Verhalten kürzlich erlebt haben. Allgemeines Technikinteresse reicht nicht. Jemand kann das Konzept mögen, ohne das Problem je zu haben, das Budget zu kontrollieren oder den Kauf zu beeinflussen.

Frag nach einer konkreten letzten Situation. Was geschah zuerst? Was wurde danach getan? Welche Werkzeuge, Personen oder Dokumente waren beteiligt? Wo gingen Zeit, Geld oder Vertrauen verloren? Wie wurde die Situation gelöst? Geschichten über echtes Verhalten zeigen mehr als Vorhersagen.

Bezieh mehrere Rollen ein, wenn das Produkt mehrere hat. Kunde, Verwaltung und Entscheider erleben denselben Ablauf verschieden. Mittle diese Bedürfnisse nicht zu früh. Markiere Überschneidungen und Unterschiede bei Inhalten, Rechten und Support.

Fragen, die Verhalten zeigen

Vermeide Fragen wie „Würden Sie eine App mit Erinnerungen nutzen?“ Sie führen zu höflicher Zustimmung und verleiten Menschen dazu, die Lösung für dich zu entwerfen. Frag, was heute getan wird, wie oft das Problem auftritt, was bereits versucht wurde und was ohne Lösung passiert. Hake bei Details nach.

Achte auf Prioritätssignale. Wer eine Tabelle erstellt, für einen Workaround bezahlt, den Anbieter gewechselt oder einen manuellen Prozess gebaut hat, zeigt Aufwand. Wer ein Problem interessant findet, aber nichts tut, hat möglicherweise zu wenig Dringlichkeit. Beide Antworten sind wertvoll, wenn sie richtig gelesen werden.

Zeig ein Konzept erst nach dem Verständnis der heutigen Situation. Lass einen Prototypen ausprobieren und beobachte Erwartungen. Miss nicht nur Zustimmung, sondern ob die Aufgabe gelingt, ob der Nutzen erklärt werden kann und was Nutzung verhindern würde.

Muster und Unterschiede erkennen

Dokumentiere jede Runde nach derselben Struktur: Kontext, Problem, Workaround, Häufigkeit, Folge, gewünschtes Ergebnis und Belegstärke. Trenn wörtliche Aussagen von Interpretation. So wird erkennbar, ob etwas ein Muster oder nur ein einprägsamer Kommentar ist.

Ein Muster bedeutet nicht gleiche Wörter. Menschen können denselben Auslöser, Umweg oder Schaden beschreiben. Unterschiede sind ebenfalls wichtig. Ein Problem kann für ein Segment dringend und für ein anderes nebensächlich sein. Eine Funktion kann Kunden helfen und intern zusätzlichen Aufwand erzeugen. Segmentiere deshalb die Ergebnisse, statt einen einzigen Durchschnittsnutzer zu erzwingen.

Nutz eine einfache Evidenzübersicht. Markiere Annahmen als bestätigt, widerlegt oder offen. Das Ziel ist kein schönes Dokument, sondern ein gemeinsamer nächster Beschluss statt einer Roadmap nach der lautesten Meinung.

Eine Stopregel setzen

Definiere vor der nächsten Runde, was für den Start genügt. Das kann ein wiederholtes Problem in einem Segment, ein klarer Workaround, ein glaubwürdiger Käufer und ein erfolgreicher Test der Kernhandlung sein. Die Schwelle hängt vom Risiko ab. Ein günstiger Prototyp braucht weniger Sicherheit als ein regulierter Ablauf oder ein großes Integrationsprojekt.

Beobachte sinkenden Zusatznutzen. Wenn mehrere passende Gespräche denselben Auslöser und Workaround zeigen, liefern weitere Interviews vielleicht nur Details. Wechsle dann zu Prototyp, Pilot oder Preistest. Wenn jedes Gespräch ein anderes Problem bringt, sind Zielgruppe oder Frage möglicherweise zu breit.

Stoppen heißt nicht, dass jede Annahme gelöst ist. Halte Risiken fest und entscheide, ob Design, Pilot oder Messung nach dem Start sie adressiert. Forschung soll einen verantwortbaren nächsten Schritt ermöglichen, keinen Anspruch auf Gewissheit.

Beweise in einen Bauplan übersetzen

Fass die Forschung als Produktentscheidungen zusammen: erste Zielgruppe, Problem, Kernverhalten, Beleg, Risiken und nächster Test. Entfern Funktionen, die nicht zum bewiesenen Ergebnis beitragen. Formuliere beobachtbare Abnahmekriterien, damit das Team erkennen kann, ob die erste Version funktioniert.

Plane Lernen nach dem Start. Analytics zeigt Aktivierung, Abschluss, Fehler und Wiederkehr. Supportgespräche zeigen Verwirrung und fehlende Inhalte. Ein Pilot prüft Belastung und Integrationen. Vor- und Nachstartlernen gehören zusammen, dürfen aber nicht zu dauerhaftem Aufschub führen.

Genug Forschung ist erreicht, wenn das Team das Problem versteht, eine enge erste Zielgruppe bestimmen kann und Belege für den nächsten Schritt hat. Ziel ist begründetes Handeln statt perfekter Gewissheit.

Quellen

• User interviews · Nielsen Norman Group
• Events · Google Analytics

Häufige Fragen

Wie viele Interviews sind genug?

Genug Gespräche zeigen wiederkehrende Muster bei passenden Teilnehmern und reduzieren entscheidende Risiken. Die Zahl hängt von Zielgruppe, Variation und Risiko ab.

Soll ich die App-Idee sofort zeigen?

Versteh zuerst das heutige Problem, ohne die Lösung zu zeigen. Teste danach mit einem Prototyp Verständnis und Verhalten, nicht nur Zustimmung.

Was ist bei völlig unterschiedlichen Antworten zu tun?

Prüf, ob die Zielgruppe zu breit, die Frage unklar oder das Problem nicht geteilt ist. Segmentiere die Ergebnisse, bevor du die Forschung als erfolglos ansiehst.

Kann Forschung den Bau zu lange verzögern?

Ja. Setz eine Stopregel und wähl das günstigste Experiment für die nächste Frage. Forschung und Bau sollten eine Lernschleife bilden statt getrennter, endloser Phasen.