Eine Research-Funktion ist wert, was sie verändert
Discovery-Infrastruktur und ein Designsystem sind teuer, und beide verliert man leicht gegen Feature-Arbeit. Das Argument, das gewinnt, ist das in der Währung, die das Geschäft ohnehin benutzt. Also muss die Arbeit ausgeliefert und die Veränderung gemessen werden.
Zwei Unternehmen, derselbe Test
Conrad Electronic. Zehn Initiativen, 2025 ausgeliefert und EU-weit über ihre ersten zwölf Monate gemessen, die 30,3 Mio. € Umsatzwirkung tragen. Neun der zehn sind A/B-Test-Ergebnisse. Dahinter fünf Entscheidungen, die die Funktion mit Evidenz gestützt hat und die auf Jahre keine saubere Zahl liefern werden.
FTI Group. Homepage und Vergleichsseite, die den größten Teil des Traffics und der Schulden trugen, neu gebaut auf Next.js und dem Sunscreen-Designsystem. Gestartet in Österreich mit 9 Prozent höherer Klickrate und halbierter Entwicklungszeit für spätere Features, drei Monate später von einer Insolvenz gestoppt.
Vor beiden vier Jahre Produkt- und User-Experience-Verantwortung für den Versicherungsvergleich bei CHECK24, Deutschlands größtem Vergleichsportal, wo jede Änderung an der Conversion gemessen wird und A/B-Testing längst die Muttersprache des Hauses war. Die Arbeit dort bestand darin, qualitative Kundenevidenz zu denselben Bedingungen antreten zu lassen wie die Zahlen, in einer Kultur, die mühelos messen konnte und keine Gewohnheit hatte zu fragen, warum.
Was jedes Mal gleich ist
Eine Hypothese, bevor die Arbeit beginnt. Der One-Pager bei FTI, die repository-gestützte Hypothese bei Conrad. Nichts kommt aus einem Bauchgefühl in ein Backlog.
Eine Kontrollgruppe. Eine Variante gegen eine Kontrolle ist die einzige Aussage, die eine Nachprüfung übersteht. Wo das unmöglich ist, wie beim Einwilligungsdialog, gehört dazu, welche Zahl modelliert ist und wer sie modelliert hat.
Die Kennzahl, die das Geschäft ohnehin benutzt. Umsatz pro Besuch, Klickrate, Bestellungen. Designqualitätswerte überzeugen nur Designer.
Getrennte Oberflächen, getrennt gemessen. Drei Änderungen an einer Seite, jede für sich getestet, schlagen ein Redesign von allem mit einem einzigen Vorher-Nachher.
Zuschreibung dort, wo sie hingehört. Die Funktion liefert die Evidenz und das Design. Die Teams liefern aus, und andere verantworten die Entscheidungen.
Ich hätte den Ist-Zustand bepreisen sollen, bevor ich den Ersatz vorgeschlagen habe
Was ich anders machen würde, ist die Reihenfolge: Ich hätte eine Zahl auf die Kosten des Ist-Zustands gesetzt, bevor ich die Infrastruktur vorgeschlagen habe, die ihn ersetzt. Infrastruktur-Argumente verliert man leicht gegen Feature-Arbeit, und die Zahl, die sie gewinnt, sind die gemessenen Kosten des Nichtstuns. Bei FTI hat genau deshalb ein Return-on-Investment-Modell die Budgetentscheidung getragen. Hier habe ich zu bauen begonnen, bevor ich die entsprechende Zahl hatte, und ein Quartal aus Prinzipien argumentiert, wo ich aus Arithmetik hätte argumentieren können.