Ich wollte eine Treiberanalyse bauen. Dafür brauchte ich eine Matrixfrage – mehrere Aspekte als Subquestions, einheitliche Skala. Dazu eine separate Gesamtbewertung als Zielgröße. Erst nachdem diese Struktur stand, habe ich überlegt, welche Aspekte ich überhaupt abfragen wollte.
Irgendwann fiel mir auf:
Ich entwerfe gar keine Umfragen mehr. Ich entwerfe Reports.
Das Problem mit der klassischen Reihenfolge
Der übliche Weg beim Fragebogendesign: Was wollen wir wissen? Welche Fragen stellen wir? Welcher Fragetyp passt? Der Report kommt am Ende – als Auswertung dessen, was die Daten hergeben.
Das Problem ist nicht die Absicht, sondern die Reihenfolge. Wer zuerst fragt und dann auswertet, endet oft bei zwanzig Balkendiagrammen, die korrekt sind, aber nichts entscheiden. Die Daten sind da. Die Richtung fehlt.
Wie Test-driven Development den Test vor den Code stellt, stellt Report-driven Survey Design den Report vor den Fragebogen.
Was das bedeutet
Report-driven Survey Design – kurz RDSD – ist eine Entwurfsmethodik für Umfragen, bei der nicht die Frage am Anfang steht, sondern das Ergebnis. „Report" meint dabei jede strukturierte Auswertung, die eine Entscheidung vorbereitet: eine Kennzahl, eine Prioritätsmatrix, ein Ranking, eine Treiberanalyse.
Die Designreihenfolge kehrt sich um:
Welchen Report brauche ich?
↓
Welche Daten braucht dieser Report?
↓
Welche Fragetypen liefern diese Daten?
↓
Welche Fragen stelle ich?
Eine Umfrage ist in diesem Ansatz keine Erkenntnisquelle, die man anschließend auswertet. Sie ist die Datenquelle eines Reports, der bereits vor dem ersten Frageentwurf in seiner Grundstruktur feststeht.
Survey Recipes als Bausteine
Aus diesem Entwurfsprozess entstehen wiederkehrende Muster – Kombinationen aus Fragetypen und Auswertungsregeln, die einen bestimmten Report ermöglichen. Ich nenne sie Survey Recipes.
Ein Survey Recipe beschreibt, welche Fragen, Fragetypen und Bedingungen erforderlich sind, um einen bestimmten Report zu erzeugen. Es hat drei Bestandteile:
Das Ergebnis – der Report oder die Kennzahl die am Ende stehen soll.
Die Zutaten – welche Fragetypen in welcher Kombination.
Die Bedingungen – was vorausgesetzt sein muss damit das Recipe funktioniert: gleiche Skala für alle Items, eine separate Zielgröße, ausreichend Antworten für statistische Belastbarkeit.
Ein Recipe ist kein Vorschlag. Es ist ein Design Constraint: Wenn du Report X möchtest, musst du Survey Y bauen. Wer ein Recipe kennt, weiß exakt welche Eingaben welches Ergebnis erzeugen – und was nicht fehlen darf.
Ein Beispiel: das Priority Matrix Recipe
Zwei unabhängige Dimensionen – das ist der Kern des Priority Matrix Recipe. Nicht zwei Aspekte einer Frage, sondern zwei vollständig getrennte Bewertungen desselben Objekts. Erst diese Trennung erlaubt eine Verortung auf zwei Achsen.
Ein Backlog mit vierzig Items lässt sich so priorisieren: Alle Stakeholder bewerten jeden Eintrag auf zwei Dimensionen – Wichtigkeit und Dringlichkeit. Aus den aggregierten Bewertungen entsteht eine Prioritätsmatrix: vier Quadranten, jedes Item verortet nach dem Durchschnitt der Stimmen, nicht nach einer Einzelmeinung.
Das Recipe dahinter: eine Dual-Array-Frage in LimeSurvey (Fragetyp 1) mit zwei frei benennbaren Antwortskalen – Skala A und Skala B. Die Skalen können heißen wie der Anwendungsfall es verlangt: Wichtigkeit und Zufriedenheit für eine Mitarbeiterbefragung, Wichtigkeit und Dringlichkeit für ein Produkt-Backlog.
Der Report wird vor der Umfrage konfiguriert – nicht danach. Eine Eisenhower-Matrix für ein Backlog sieht im ReportPlugin so aus:
$s->priorityMatrix('aufgaben')
->title('Eisenhower-Matrix')
->scale0Label('Dringlichkeit')
->scale1Label('Wichtigkeit')
->quadrantLabels([
'topLeft' => 'Delegieren', // dringend, aber nicht wichtig
'topRight' => 'Sofort tun', // dringend und wichtig
'bottomLeft' => 'Eliminieren', // weder dringend noch wichtig
'bottomRight' => 'Planen', // wichtig, aber nicht dringend
])
->col(12);
scale0 und scale1 entsprechen direkt den zwei Skalen der Dual-Array-Frage. Die Quadrantennamen sind frei – sie beschreiben die Interpretation, nicht die Datenstruktur. Wer diesen Code schreibt, weiß bereits welche Frage er bauen muss. Das ist RDSD in der Praxis.
Die Trennung in zwei Skalen ist keine technische Konvention – sie ist inhaltlich notwendig. Jede Achse der Matrix misst eine unabhängige Dimension. Wer beide Aspekte in einer einzigen Skala kombiniert, verliert diese Unabhängigkeit und kann keine Matrix mehr erzeugen. Das ist kein Werkzeug-Detail – das ist eine Anforderung die sich aus dem gewünschten Report ergibt.
Das Ergebnis verändert nicht nur die Darstellung. Eine aggregierte Stakeholder-Matrix ist eine andere Grundlage für Priorisierungsentscheidungen als eine Einzelmeinung – unabhängig davon wie überzeugend diese Meinung vorgetragen wird.
Was RDSD nicht ist
RDSD ist keine Garantie für bessere Fragen. Die Qualität der Erkenntnisse hängt weiterhin davon ab, ob die richtigen Dimensionen erhoben werden und ob die Befragten verstehen was gefragt ist.
RDSD ist auch kein starres Verfahren. Es gibt Umfragen wo der Erkenntnisbedarf diffus ist und erst durch explorative Auswertung schärfer wird. Für diese Fälle ist die Methodik weniger geeignet.
Wo RDSD funktioniert, ist dort wo das Ziel der Umfrage klar ist: eine Priorisierungsentscheidung, eine Treiber-Einordnung, ein Handlungsranking. Wer weiß was der Report leisten soll, kann rückwärts entwerfen.
Warum das mehr ist als eine Designentscheidung
Der klassische Survey-Ansatz behandelt den Report als Nebenprodukt der Umfrage. RDSD dreht diese Beziehung um: Die Umfrage ist die Datenquelle des Reports – nicht umgekehrt.
In der Praxis bedeutet das: Fragebögen werden kürzer, weil keine Fragen mehr gestellt werden die keinen Report-Beitrag leisten. Fragetypen werden nicht nach Formulierungskomfort gewählt, sondern nach dem was die Auswertung verlangt. Und der Report entsteht nicht am Ende des Projekts, sondern am Anfang – als Entwurf, der den Rest des Prozesses steuert.
Die Survey Recipes, die sich aus diesem Ansatz ergeben, sind das Thema einer eigenen Serie. Das Driver Recipe, das Priority Matrix Recipe, das Priority Recipe – jedes beschreibt eine konkrete Kombination aus Fragetypen und Auswertungsregeln und den Report, den sie ermöglichen.
Wenn ein Report eine konkrete Entscheidung unterstützen soll, dann bestimmt sein Datenmodell den Fragebogen – nicht umgekehrt. Genau diese Umkehrung beschreibt Report-driven Survey Design.
Ein guter Fragebogen beginnt nicht mit einer Frage. Er beginnt mit der Entscheidung, die der Report später ermöglichen soll.