Das teuerste Research ist das, das die falsche Frage beantwortet. Nicht weit dahinter: gar keins. Wenn kein Research vorliegt, entscheidet meist der lauteste Meinungsträger im Raum — in Produktteams auch bekannt als HiPPO-Problem (Highest Paid Person's Opinion). Der Tagesordnungspunkt "Was will der Nutzer?" wird dann mit Bauchgefühl abgehakt, und drei Monate später scheitert das Feature am Produktlaunch still und heimlich in der Analytics-Kurve.
User Research ist keine akademische Übung. Es ist das Werkzeug, mit dem du sicherstellst, dass dein Team das Richtige baut — bevor das Budget aufgebraucht ist. Die Frage ist nicht ob, sondern welche Methode wann.
Jede User-Research-Methode lässt sich auf zwei Achsen verorten. Diese Einordnung kommt aus der Denktradition der Nielsen Norman Group und gilt als Grundgerüst der angewandten Nutzerforschung:
Achse 1 — Einstellung vs. Verhalten: Was sagen Menschen vs. was tun sie? Das klingt trivial, ist es nicht. In Interviews sagen Nutzer häufig, sie würden einen Schritt problemlos ausführen — und scheitern im Usability-Test an genau dieser Stelle. Einstellungen sind selbstberichtetes Erleben, Verhalten ist das, was tatsächlich passiert.
Achse 2 — Qualitativ vs. Quantitativ: Das Warum verstehen vs. das Wie viel messen. Qualitative Methoden liefern Tiefe und Kontext. Quantitative Methoden liefern Gewissheit über Ausmaß und Verbreitung. Beide sind notwendig — allein sind sie unvollständig.
Aus der Kombination beider Achsen entstehen vier Quadranten:
| Qualitativ | Quantitativ | |
|---|---|---|
| Einstellung | Nutzerinterviews, Tagebuchstudien | Umfragen, Zufriedenheitsskalen |
| Verhalten | Usability-Tests, Contextual Inquiry | Analytics, A/B-Tests |
Bevor du eine Methode wählst, frag dich: Will ich verstehen oder messen? Und geht es um das, was Menschen denken, oder um das, was sie tun? Die Antwort führt dich in den richtigen Quadranten.
Was es ist: Ein moderiertes Einzelgespräch mit einem Zielgruppenvertreter, typischerweise 45–60 Minuten. Kein Fragebogen — offene Fragen, aktives Zuhören, Nachfragen.
Wann einsetzen: Früh im Projekt, wenn du die Zielgruppe noch nicht wirklich kennst. Auch sinnvoll nach quantitativen Befunden, die du nicht erklären kannst ("Warum brechen 40% der Nutzer auf Seite 3 ab?").
Was es liefert: Motivationen, mentale Modelle, Frustrationen, den Kontext der Nutzung — Dinge, die in keiner Analytics-Tabelle stehen.
Typischer Aufwand: 5–8 Gespräche für erste stabile Muster. Recruiting, Moderation, Auswertung: 2–4 Arbeitstage insgesamt.
Häufigster Fehler: Leading Questions — also Fragen, die die Antwort bereits enthalten ("Findest du auch, dass der Checkout zu lang ist?"). Gute Interviewfragen beginnen mit "Erzähl mir von…" oder "Wie gehst du vor, wenn…".
Was es ist: Du beobachtest einen Nutzer bei seiner echten Arbeit in seiner echten Umgebung — kein Labor, kein aufgeräumter Schreibtisch. Die Methode wurde von Karen Holtzblatt und Hugh Beyer entwickelt und verbindet Beobachtung mit gezieltem Nachfragen.
Wann einsetzen: Wenn du Software für komplexe Arbeitsabläufe baust (Buchhaltung, Lagerverwaltung, Produktionssteuerung) und nicht weißt, wie der Job tatsächlich erledigt wird — nicht wie die Prozessdokumentation sagt, dass er erledigt wird.
Was es liefert: Undokumentierte Workarounds, echte Kontextfaktoren (Lärm, Unterbrechungen, Parallelwerkzeuge), die mentale Landkarte hinter dem Arbeitsablauf.
Typischer Aufwand: 3–5 Besuche à 90–120 Minuten. Reisezeit einkalkulieren.
Häufigster Fehler: Ins Produkt-Demo-Modus wechseln und anfangen zu erklären, wie man es "richtig" machen würde.
Was es ist: Strukturierter Fragebogen an eine größere Nutzergruppe, online ausgefüllt. Von kurzen In-App-Micro-Surveys (3 Fragen, 2 Minuten) bis zu umfangreichen Zufriedenheitsbefragungen.
Wann einsetzen: Wenn du bereits weißt, was du fragen willst, und es auf Ausmaß ankommt. "Wie viele unserer Nutzer haben dieses Problem?" ist eine quantitative Frage — richtig für eine Umfrage.
Was es liefert: Verteilungen, Häufigkeiten, Segmentierungen. NPS, CSAT, CES als bekannte Kennzahlen.
Typischer Aufwand: 50–200 Antworten für stabile Aussagen (je nach Segmentierungstiefe). Fragebogen-Design unterschätzt — schlechte Fragen liefern unbrauchbare Daten.
Häufigster Fehler: Umfragen zu früh einsetzen, bevor qualitative Erkenntnisse vorliegen. Du kannst nur nach Dingen fragen, die du bereits konzeptuell verstehst.
Was es ist: Echte Nutzer führen definierte Aufgaben mit einem Produkt oder Prototyp aus, während du beobachtest (und protokollierst). Moderiert bedeutet: ein Moderator ist live dabei und stellt Verständnisfragen. Unmoderiert bedeutet: die Session läuft automatisiert (Tools wie Maze, Lookback, UserTesting.com), der Nutzer nimmt den Bildschirm auf.
Wann einsetzen: Sobald es etwas zum Testen gibt — auch frühe Clickdummies. Moderierte Tests wenn du tiefes Verständnis brauchst, unmoderierte wenn du Geschwindigkeit und Skalierung brauchst.
Was es liefert: Konkreter Befund: "4 von 5 Testpersonen finden den Abonnement-Kündigen-Link nicht." Keine Interpretation nötig.
Typischer Aufwand: 5 moderierte Teilnehmer identifizieren nach Nielsens bekannter Faustregel den Großteil der schwerwiegenden Usability-Probleme — als Faustregel zu verstehen, nicht als Naturgesetz. Unmoderierte Tests: 20–50 Teilnehmer für quantitative Aussagen.
Häufigster Fehler: Den Test erst kurz vor Launch machen. Dann sind die Befunde zu spät, um die Architektur zu ändern — es bleiben nur kosmetische Fixes.
Was es ist: Teilnehmer ordnen vorgegebene Inhaltskarten in selbst gewählte Gruppen und benennen die Gruppen. Offenes Card Sorting (freie Gruppenbildung) vs. geschlossenes Card Sorting (vordefinierte Kategorien zum Einsortieren).
Wann einsetzen: Wenn du eine Navigation, eine Informationsarchitektur oder eine Kategorienstruktur entwirfst oder überarbeitest.
Was es liefert: Das mentale Modell der Nutzer für deine Inhalte — welche Dinge zusammengehören, wie sie benannt werden sollten.
Typischer Aufwand: 15–30 Teilnehmer für stabile Cluster. Remote per Optimal Workshop oder Maze in ca. 20 Minuten pro Person durchführbar.
Häufigster Fehler: Card Sorting mit zu vielen Karten überladen (mehr als 40 Karten überfordern Teilnehmer und liefern Rauschen statt Signal).
Was es ist: Das Gegenstück zum Card Sorting. Teilnehmer sehen nur die Text-Navigation (ohne visuelles Design) und sollen Inhalte darin finden. Kein Scrollen, keine Bilder — nur die Hierarchie.
Wann einsetzen: Direkt nach dem Card Sorting, um die ausgearbeitete Informationsarchitektur zu validieren. Auch sinnvoll vor einem Relaunch, um die bestehende Navigation zu benchmarken.
Was es liefert: Messbares "Findability"-Ergebnis pro Navigationsknoten. Du siehst, wo Nutzer abbiegen und wo sie verloren gehen.
Typischer Aufwand: 20–50 Teilnehmer. Remote-Tool (Optimal Workshop, Treejack) läuft unmoderiert. Auswertung zeigt Success Rates und Direktheit-Scores.
Häufigster Fehler: Tree Testing einsetzen, ohne zuvor Card Sorting gemacht zu haben — dann testest du eine Struktur, die du nie auf Basis von Nutzerdaten gebaut hast.
Was es ist: Auswertung von Nutzungsdaten aus Tools wie Google Analytics 4, Matomo, Hotjar oder Mixpanel. Funnels zeigen, wo Nutzer in einem definierten Ablauf (Checkout, Registrierung, Onboarding) abspringen.
Wann einsetzen: Immer, wenn du ein laufendes Produkt analysierst. Analytics sind das Basisinstrument jedes UX-Audits — sie zeigen dir, wo du hinschauen solltest.
Was es liefert: Quantitative Beschreibung von Verhalten: Absprungraten, Verweildauer, Klickpfade, Konversionsraten. Zeigt das Was, nicht das Warum.
Typischer Aufwand: Kontinuierlich laufend. Eine gezielte Funnel-Analyse für eine spezifische Fragestellung: halber bis ganzer Tag.
Häufigster Fehler: Analytics als einzige Forschungsquelle behandeln. Die Zahl sagt dir, dass 60% abspringen — nicht, warum.
Was es ist: Zwei (oder mehr) Varianten einer Seite oder eines Elements werden gleichzeitig an unterschiedliche Nutzergruppen ausgespielt. Gewinner ist die Variante mit der besseren Zielmetrik (Klickrate, Conversion, Abbruchrate).
Wann einsetzen: Wenn du eine konkrete Hypothese hast ("Ein roter CTA-Button konvertiert besser als ein grauer") und genug Traffic, um statistische Signifikanz zu erreichen. Faustregel: mindestens einige hundert Konversionen pro Variante pro Woche.
Was es liefert: Kausale Aussage über die Wirkung einer Designänderung — unter gleichbleibenden Bedingungen.
Typischer Aufwand: Tool-Setup einmalig (Google Optimize wird nicht mehr weiterentwickelt — Alternativen: VWO, AB Tasty, Optimizely). Laufzeit je nach Traffic: 2–6 Wochen pro Test.
Häufigster Fehler: Tests zu früh stoppen ("Der rote Button liegt vorn!") oder zu viele Variablen gleichzeitig testen — dann weißt du, dass etwas besser war, aber nicht, was den Unterschied gemacht hat.
| Situation | Empfohlene Methoden-Kombi | Warum |
|---|---|---|
| Wir bauen etwas Neues und kennen die Zielgruppe kaum | Nutzerinterviews + (ggf.) Contextual Inquiry | Erst verstehen, dann strukturieren. Quantitative Methoden jetzt einsetzen hieße, die falschen Dinge zu messen. |
| Unsere Conversion ist schlecht, wir wissen nicht warum | Analytics-Funnel-Analyse → Usability-Testing (moderiert) | Analytics zeigt, wo das Problem liegt. Usability-Testing zeigt, warum es dort liegt. |
| Wir streiten im Team über die Navigation | Card Sorting + Tree Testing | Bringt Nutzerdaten in die Diskussion statt Meinungen. Endet Streit durch Evidenz. |
| Wir haben zwei Design-Varianten und müssen uns entscheiden | Unmoderiertes Usability-Testing oder A/B-Test (je nach Traffic) | Wenig Traffic / kein laufendes Produkt: Usability-Test. Viel Traffic, klare Metrik: A/B-Test. |
| Relaunch steht an, Bestandssite analysieren | Tree Testing der alten IA + Analytics-Audit + 5 Nutzerinterviews | Benchmarkt, was kaputt ist; liefert Priorisierung. Bestandteil eines vollständigen UX-Audits. |
| Wir wollen wissen, ob unsere Nutzer zufrieden sind | In-App-Micro-Survey (CSAT/CES) + NPS-Befragung | Schnell skalierbar; zeigt Trends über Zeit. Qualitative Ergänzung wenn Scores sinken. |
| Neue Funktion, nach dem Launch Wirkung messen | A/B-Test (wenn Traffic) oder Analytics-Funnel vor/nach + kurze Nutzerinterviews | Verhindert, dass der Erfolg einer Funktion nur auf Schulterklopfen basiert. |
1. Freunde und Kollegen befragen Das Netzwerk ist immer zu nah am Produkt oder an der Agentur. Kollegen sagen, was sie für sinnvoll halten, nicht was echte Nutzer erleben. Recruiting echter Zielgruppenvertreter ist aufwendiger — aber der Unterschied in der Datenqualität ist enorm.
2. Leading Questions stellen "Würdest du dieses Feature nutzen?" — fast jeder sagt Ja. Menschen sind höflich, besonders Fremden gegenüber, die ihnen erklären, was sie gebaut haben. Die Frage muss das konkrete Verhalten in der Vergangenheit oder in einer Aufgabe erheben, nicht die hypothetische Zukunft.
3. Quantitative Schlüsse aus kleinen qualitativen Stichproben ziehen
5 Usability-Test-Teilnehmer sind gut genug, um gravierende Probleme zu finden. Sie sind nicht gut genug für die Aussage "80% unserer Nutzer finden X schwierig". Diese Zahl aus n=5 zu ziehen ist ein Kategorienfehler.
4. Research ohne Entscheidungsanbindung betreiben Research, dessen Ergebnisse in einem PDF landen und nie eine Designentscheidung beeinflussen, ist rausgeworfenes Geld. Bevor du ein Research-Projekt startest, sollte klar sein: Wer entscheidet auf Basis dieser Ergebnisse was? Sonst wird das Dokument archiviert und nichts ändert sich.
5. Research erst nach dem Launch machen "Wir testen nach dem Launch" ist die verbreitetste Ausrede, um Research zu vermeiden. Nach dem Launch ändern sich teure Architekturentscheidungen nicht mehr. Research lohnt am meisten früh im Prozess, wenn noch alles veränderbar ist — auch ein grober Papierprototyp ist testbar.
Die kurze Antwort: weniger als du denkst, aber öfter als du es tust.
Nielsens bekannte Faustregel besagt, dass 5 Nutzer im moderierten Usability-Test den Großteil der schwerwiegenden Probleme identifizieren. Das ist eine Faustregel — kein Gesetz —, aber sie befreit von dem Gedanken, für jeden Test hunderte Teilnehmer zu rekrutieren. Besser: 5 Teilnehmer jetzt, weitere 5 nach dem nächsten Iterationsschritt.
In unseren Projekten sehen wir immer wieder dasselbe Muster: Teams, die ein großes Jahres-Research-Projekt planen, kommen seltener zu Erkenntnissen als Teams, die alle vier Wochen zwei Interviews führen. Research wirkt am stärksten, wenn es zum Rhythmus des Produktteams gehört — nicht wenn es ein einmaliges Ereignis ist.
Pragmatische Grundausstattung für ein Mittelstands-Projekt:
Das sind insgesamt vielleicht 8–12 Arbeitstage über ein Projekt verteilt. Verglichen mit dem Aufwand, eine falsch konzipierte Funktion nach dem Launch zu überarbeiten, ist das günstig.
Wie das alles im Zusammenhang steht — welche Research-Erkenntnisse sich in eine Customer Journey übersetzen lassen — zeigen wir im Artikel über User Journey Mapping als Synthese-Werkzeug.
Wer eine fundierte UX-Design-Begleitung sucht, bei der Research nicht als separates Dokument endet, sondern direkt in Designentscheidungen fließt, findet bei uns den entsprechenden Prozess.
User Research ist kein akademisches Anhängsel, sondern die Grundlage für Designentscheidungen, die nicht auf Meinungen basieren. Die zwei Achsen (Einstellung vs. Verhalten, qualitativ vs. quantitativ) helfen dir, die richtige Methode für die richtige Frage zu wählen. Wenige, gezielte Studien früh im Prozess haben mehr Wirkung als ein großes Research-Projekt am Projektende. Der häufigste Fehler ist nicht die falsche Methode — es ist Research, dessen Ergebnisse keine Entscheidung beeinflussen.
Guter Research braucht keinen großen Apparat — aber eine klare Fragestellung und den Willen, die Ergebnisse auch zu nutzen. In einem kostenlosen 30-minütigen Erstgespräch klären wir, welche Research-Methoden für dein Projekt sinnvoll sind und wie sie in einen schlanken UX-Prozess passen.
