Früher war ich Software-Entwickler, heute bin ich Survey-Entwickler.
Als Software-Entwickler schreibe ich Code. Ich committe ihn, ich reviewe ihn, ich rolle ihn zurück wenn etwas schiefgeht. Jede Änderung hat eine Historie. Jede Funktion lässt sich wiederverwenden.
Als Survey-Entwickler klicke ich Dropdown-Menüs.
Das war zumindest bis vor kurzem so.
Das Problem mit dem Klicken
Eine LimeSurvey-Umfrage entsteht klassisch im Browser. Frage anlegen, Antwortoptionen eintippen, Fragengruppe verschieben, Bedingung setzen. Das funktioniert – bis die Umfrage zum zweiten Mal gebraucht wird.
Dann beginnt das eigentliche Problem.
Keine Versionierung. Wer hat wann welche Frage geändert? Warum wurde die Antwortskala von vier auf fünf Stufen erweitert? Die Antwort liegt – wenn überhaupt – in einer E-Mail oder im Gedächtnis einer Person.
LimeSurvey bringt zwar ein AuditLog-Plugin mit, das seit 2013 zum Core gehört. Es protokolliert administrative Vorgänge – Logins, Benutzeränderungen, das Anlegen von Antworten. Was es nicht liefert, ist ein Diff der Umfragestruktur selbst: dass aus „Stimme zu" plötzlich „Stimme voll zu" wurde, lässt sich daraus nicht ablesen. Im Forum finden sich seit Jahren Nachfragen wie man überhaupt an die protokollierten Daten kommt – ein Hinweis darauf, dass das Plugin in der Praxis selten zum Einsatz kommt.
Keine Wiederverwendbarkeit. Dieselbe Zustimmungsskala – „stimme voll zu" bis „stimme gar nicht zu" – wird in jeder neuen Umfrage erneut eingetippt. Mit der Zeit entstehen Varianten: einmal „Stimme zu", einmal „Stimme voll zu". Niemand hat das beabsichtigt. Es ist einfach passiert. Die Arbeit verschiebt sich dadurch nie von „Fragen wiederholt eintippen" zu „aus einer kuratierten Bibliothek auswählen" – sie bleibt beim Eintippen, jedes Mal neu.
Kein Review-Prozess. Bevor eine Mitarbeiterbefragung an dreihundert Personen geht, sollte jemand außer dem Ersteller draufschauen. In der Praxis heißt das: Bildschirm teilen, gemeinsam durchklicken, hoffen dass nichts übersehen wird.
Das ist kein LimeSurvey-spezifisches Problem. Es ist das Problem jeder Software die man durch Klicken statt durch Beschreiben konfiguriert.
Ist eine Umfrage nicht ohnehin schon Text?
Der naheliegende Einwand: LimeSurvey kann Umfragen bereits als .lss-Datei exportieren – ein XML-Format. Technisch ist eine Umfrage also längst eine Textdatei.
Nur ist .lss kein Format das man von Hand schreibt. Es ist ein internes Austauschformat – generiert von LimeSurvey, gedacht für LimeSurvey, mit IDs, Tabellenstrukturen und Redundanzen die für eine Maschine sinnvoll sind, für einen Menschen aber nicht. Eine einzelne Antwortoption von Hand in .lss zu ändern ist möglich, aber fehleranfälliger als der Weg übers Backend zu klicken – falsche ID erwischt, falsche Sprachversion getroffen, eine Tabellenreferenz übersehen.
Der Unterschied zwischen .lss und einer YAML-Spezifikation ist also nicht „Text versus Klicken". Es ist der Unterschied zwischen einem Format das eine Maschine für eine andere Maschine schreibt, und einem Format das ein Mensch für eine Maschine schreibt. .lss bleibt das Zielformat – aber als Ausgabe, nicht als Eingabe.
Die Lösung kennt man bereits – aus einer anderen Branche
Server wurden früher auch geklickt. Ein Admin loggte sich ein, installierte Pakete, änderte Konfigurationsdateien händisch. Funktionierte – bis der Server neu aufgesetzt werden musste, oder ein zweiter Server genauso konfiguriert werden sollte.
Die Antwort darauf heißt heute Infrastructure as Code. Terraform, Ansible, Kubernetes-Manifeste. Die Infrastruktur wird nicht mehr geklickt, sondern beschrieben – als Textdatei, versioniert in Git, reviewbar wie jeder andere Code.
Dieselbe Idee lässt sich auf Umfragen übertragen. Ich nenne es Survey as Code.
Wie das konkret aussieht
Eine Umfrage wird als YAML-Datei beschrieben:
baseLanguage: de
title: Kundenbefragung
groups:
- title: Allgemeine Angaben
questions:
- code: Q1
type: shorttext
text: Wie heißen Sie?
- code: Q2
type: radiolist
text: Wie alt sind Sie?
answers:
A1: Unter 18
A2: 18–34
A3: 35–54
A4: 55 oder älter
Diese Datei ist der einzige Wahrheitspunkt der Umfrage. Sie liegt in einem Git-Repository. Jede Änderung erzeugt einen Diff:
answers:
A1: Unter 18
- A2: 18–34
- A3: 35–54
+ A2: 18–24
+ A3: 25–34
+ A4: 35–44
+ A5: 45–54
- A4: 55 oder älter
+ A6: 55 oder älter
Jeder der Git lesen kann, sieht sofort: die Altersgruppen wurden feiner unterteilt. Keine Vermutung, keine Nachfrage – der Diff ist die Dokumentation.
Mein Plugin Forge übernimmt die Übersetzung dieser Datei in eine echte LimeSurvey-Umfrage:
./forge validate --file=umfrage.yaml
./forge create --file=umfrage.yaml
Validieren prüft die Struktur, bevor irgendetwas importiert wird. Erstellen erzeugt die Umfrage – inklusive aller Fragengruppen, Fragetypen und Antwortoptionen. Im Hintergrund landet dabei genau dort, wo man es erwarten würde: bei einer .lss-Datei, die Forge aus der YAML-Spezifikation generiert. Der Mensch schreibt YAML, die Maschine erzeugt daraus das .lss-Zielformat – nicht umgekehrt.
Forge schreibt bewusst nicht direkt in die LimeSurvey-Datenbank. Stattdessen erzeugt es eine valide .lss-Datei und nutzt den bestehenden Importmechanismus von LimeSurvey. Dadurch profitiert Forge von einem seit Jahren erprobten Importprozess, ohne eine eigene Persistenzschicht pflegen zu müssen.
Der eigentliche Mehrwert: wiederverwendbare Bausteine
Der stärkste Effekt zeigt sich nicht bei einer einzelnen Umfrage, sondern bei wiederkehrender Forschung.
Eine jährliche Mitarbeiterbefragung verwendet üblicherweise dieselben Zustimmungsskalen über Jahre hinweg. Bei Forge wird diese Skala einmal definiert:
# components/labelsets.yaml
labelSets:
zustimmung_5:
labels:
1: Stimme voll zu
2: Stimme eher zu
3: Teils / teils
4: Stimme eher nicht zu
5: Stimme ganz und gar nicht zu
Und in jeder Umfrage referenziert statt neu eingetippt:
imports:
- components/labelsets.yaml
questions:
- code: Q1
type: matrix
text: Bitte bewerten Sie die folgenden Aussagen.
answers:
use: zustimmung_5
Wenn sich die Skala einmal ändert – eine Stufe wird umformuliert – ändert sich das in der Komponente. Jede Umfrage die diese Komponente importiert, übernimmt die Änderung automatisch. Keine Inkonsistenz mehr zwischen der Umfrage von 2024 und der von 2026.
Der nächste Schritt: ganze Fragen und Fragegruppen als Komponenten
LabelSets sind erst der Anfang. Konsequent weitergedacht, müssen nicht nur Antwortskalen wiederverwendbar sein, sondern ganze Fragen und Fragengruppen – eine NPS-Frage mit immer demselben Wortlaut, oder eine komplette Demografie-Sektion mit Alter, Geschlecht und Region:
questions:
- use: nps_standard
groups:
- use: demografie_standard
Eine gemeinsame, versionierte Quelle für Standardfragen statt zehn leicht unterschiedlichen Varianten derselben Frage über zehn Umfragen verteilt.
Was sich dadurch wirklich ändert
Es geht nicht nur um Zeitersparnis beim Anlegen. Es geht um eine andere Art zu arbeiten.
Review wird möglich. Ein Kollege kann eine Pull-Request-artige Durchsicht der YAML-Datei machen, bevor die Umfrage live geht – ohne Bildschirm-Sharing, ohne gemeinsames Durchklicken.
Rollback wird trivial. Wenn eine Änderung sich als Fehler herausstellt, ist git revert die Lösung – nicht die mühsame Rekonstruktion des vorherigen Zustands aus dem Gedächtnis.
Konsistenz wird erzwingbar. Eine zentrale Komponentenbibliothek mit Standard-Skalen verhindert dass „Stimme zu" und „Stimme voll zu" in derselben Organisation parallel existieren.
Automatisierung wird denkbar. validate → build → create ist eine Pipeline. Nichts hindert daran, das in eine CI/CD-Kette einzubauen – jede Änderung an der YAML-Datei wird automatisch validiert, bevor sie auf den Produktionsserver kommt.
Was das in der Praxis bedeutet
Meine eigene Mitarbeiterbefragung umfasst rund 45 Variablen, aufgeteilt auf mehrere Fragengruppen, mit wiederverwendeten Zustimmungsskalen über die gesamte Umfrage hinweg. Früher hätte jede Anpassung – eine neue Frage, eine geänderte Skala, eine zusätzliche Sprache – direkt im LimeSurvey-Backend stattfinden müssen, mit allem was dazugehört: Durchklicken, Hoffen, dass nichts übersehen wird.
Heute genügt eine Änderung an der YAML-Spezifikation. Sie lässt sich versionieren, von einem Kollegen reviewen, bei Bedarf zurückrollen – und am Ende reproduzierbar in eine neue LimeSurvey-Umfrage übersetzen. Nicht weniger Aufwand beim ersten Mal. Aber deutlich weniger Risiko bei jedem Mal danach.
Was Forge bewusst nicht macht
Forge ersetzt nicht den Fragebogen-Designprozess. Die methodische Arbeit – welche Frage misst was, wie viele Stufen braucht die Skala, wo brauchen wir Filterfragen – bleibt menschliche Arbeit. Forge übersetzt eine fertige Spezifikation in eine LimeSurvey-Umfrage. Es ersetzt nicht das Denken davor.
Und nicht jede Umfrage braucht das. Eine einmalige Ad-hoc-Befragung mit zehn Fragen profitiert kaum von Versionierung und Wiederverwendung. Der Mehrwert entsteht bei Umfragen die wiederholt, variiert oder im Team gepflegt werden.
Vom Klicken zum Beschreiben
Früher war ich Software-Entwickler. Heute bin ich Survey-Entwickler. Der Unterschied ist kleiner als der Titel suggeriert – beides bedeutet: eine Spezifikation schreiben, sie versionieren, sie reviewen, sie reproduzierbar machen.
Survey as Code macht Umfragen reproduzierbar, reviewbar und wiederverwendbar – Eigenschaften, die in der Softwareentwicklung selbstverständlich sind, in der Umfrageentwicklung jedoch bislang meist fehlen.
LimeSurvey selbst ändert sich dadurch nicht. Aber wie ich damit arbeite, schon.